Errorx202/aws-automated-threat-response

# AWS 自动化威胁检测与事件响应 使用 **Amazon GuardDuty** 实时检测威胁，并利用 **Lambda** 自动隔离受损 EC2 实例的无服务器安全自动化 pipeline —— 将事件响应时间从数小时（手动 SOC 分诊）缩短至几秒钟。 ## 解决的问题 在传统的 SOC 工作流中，分析师必须注意到告警，对其进行调查，然后手动隔离受影响的资源。检测与隔离之间的这段空档期正是攻击者造成最大破坏（数据泄露、横向移动、C2 通信）的时候。本项目通过自动化、策略驱动的修复来填补这一空白，同时通过即时通知保持“人在回路”。 ## 架构 ``` ┌────────────────┐ finding ┌──────────────────┐ │ Amazon │ ─────────────────▶│ EventBridge │ │ GuardDuty │ (severity >= 7) │ Rule │ └────────────────┘ └─────────┬─────────┘ │ invokes ▼ ┌───────────────────┐ │ Lambda │ │ (remediate.py) │ └─────────┬──────────┘ ┌────────────────────┼────────────────────┐ ▼ ▼ ▼ ┌────────────────────┐ ┌──────────────────┐ ┌──────────────────┐ │ EC2: swap to │ │ SNS: email/Slack │ │ Security Hub: │ │ quarantine SG │ │ alert to SOC │ │ mark as NOTIFIED │ │ (isolate instance) │ │ team │ │ │ └────────────────────┘ └──────────────────┘ └──────────────────┘ ``` **流程：** 1. GuardDuty 持续分析 VPC Flow Logs、DNS 日志、CloudTrail 和 S3 数据事件，以发现恶意活动（例如，受损的 EC2 实例与已知的 C2 服务器通信、端口扫描、凭据泄露）。 2. 高于可配置严重性阈值的 Findings 会通过 **EventBridge** 规则直接路由到 **Lambda** 函数 —— 无需轮询，几乎瞬时触发。 3. Lambda 识别受影响的 EC2 实例，并将其安全组替换为严格锁定的 **隔离安全组**（零入站/出站规则），从而阻止威胁扩散，同时保留实例以进行取证分析。 4. **SNS** 通知会立即发送至 SOC 团队/邮箱，其中包含 finding 详情及已执行的操作。 5. 该 finding 会在 **Security Hub** 中更新，为分析师提供统一的可视化视图，清晰展示哪些已被自动修复，哪些需要人工审查。 ## 技术栈 | 层级 | 服务 | |---|---| | 威胁检测 | Amazon GuardDuty | | 事件路由 | Amazon EventBridge | | 修复逻辑 | AWS Lambda (Python 3.12) | | 通知 | Amazon SNS | | Findings 聚合 | AWS Security Hub | | 基础设施即代码 | Terraform | ## 仓库结构 ``` aws-threat-response/ ├── terraform/ │ ├── main.tf # GuardDuty, EventBridge, Lambda, SNS, IAM, Security Hub │ ├── variables.tf # configurable inputs (region, severity threshold, email) │ └── outputs.tf # resource IDs/ARNs after deployment ├── lambda/ │ └── remediate.py # auto-isolation + notification logic └── docs/ └── README.md ``` ## 部署 **前置条件：** 允许启用 GuardDuty 的 AWS 账户、已有的 VPC、Terraform >= 1.5、已配置的 AWS CLI。 ``` cd terraform terraform init terraform plan -var="quarantine_vpc_id=vpc-xxxxxxxx" -var="alert_email=you@example.com" terraform apply -var="quarantine_vpc_id=vpc-xxxxxxxx" -var="alert_email=you@example.com" ``` 执行 apply 后，请确认 SNS 邮件订阅（检查收件箱），然后触发 GuardDuty 的内置示例 findings（Console → GuardDuty → Settings → Generate sample findings），以查看完整 pipeline 的端到端触发过程。 ### 清理 ``` terraform destroy ``` ## 设计决策 / 权衡 - **选择安全组替换而非实例终止**：保留实例及其内存/磁盘状态以供取证调查，而不是破坏证据。 - **选择 EventBridge 而非 Lambda 轮询 GuardDuty**：事件驱动，近乎零延迟，避免无效调用。 - **严重性阈值可配置**：允许团队调整对误报的容忍度（例如，仅在 High 严重性时自动隔离，在 Medium/Low 时仅通知）。 - **Security Hub 集成**：避免“自动化黑盒”——每一个自动操作都是可见且可审计的，并与手动 findings 并列展示。 ## 可能的扩展 - 使用 Slack/MS Teams webhook 替代（或附加）SNS 邮件通知 - 使用 Step Functions 进行多阶段响应（创建快照 → 隔离 → 通知 → 在 Jira 中创建工单） - 如果 finding 涉及受损的 access key，则自动撤销 IAM 凭据 - 使用 CloudWatch dashboard 监控 MTTR（平均修复时间）指标 ### 简历要点（可直接复制粘贴） **AWS 自动化威胁检测与事件响应** - 使用 GuardDuty、EventBridge 和 Lambda 构建了无服务器的 SOAR 风格 pipeline，可在识别到威胁后的几秒钟内自动检测并隔离受损的 EC2 实例。 - 设计了 IAM 最小权限策略和网络隔离策略（隔离安全组），在不破坏取证证据的情况下遏制威胁。 - 集成了 Security Hub 和 SNS，让 SOC 分析师能够实时查看自动化和手动修复操作。 - 使用 Terraform 以基础设施即代码的方式配置整个 pipeline，实现可重复、可审计的部署。

标签：AWS, DPI, Serverless, 安全运营, 扫描框架, 自动化响应, 逆向工具