Chike-dev/CloudSentinel-SOC-Project

# CloudSentinel — AWS 威胁检测与响应流水线      ## 执行摘要 CloudSentinel 是一个小型 AWS 安全运营流水线，旨在模拟云安全团队如何收集遥测数据、检测高可信度威胁、路由发现结果并启动响应工作流。 该系统使用 CloudTrail 进行审计日志记录，使用 S3 和 CloudWatch Logs 保存证据，使用 GuardDuty 进行托管威胁检测，使用 Security Hub 聚合发现结果，使用 EventBridge 路由事件，使用 SNS 通知分析师，并使用 Lambda 记录结构化的事件响应日志。 该流水线分两个阶段进行了验证： 1. **综合集成验证** — 生成 GuardDuty 样本发现，以确认 EventBridge、SNS 和 Lambda 已正确连接。 2. **真实检测验证** — 针对实验环境的 EC2 实例执行了授权的凭据外泄场景。GuardDuty 独立生成了严重性为高的 `UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS` 发现，并触发了告警和响应路径。 ## 架构  ### 数据流 ``` AWS account activity │ ├── CloudTrail → S3 + CloudWatch Logs │ └── audit evidence and investigation logs │ └── GuardDuty └── managed threat detection from AWS telemetry │ ├── Security Hub → centralized findings dashboard │ └── EventBridge rule: severity >= 7 ├── SNS → SOC analyst email alert └── Lambda → incident parsing and response logging ``` CloudTrail 和日志存储提供了调查记录。GuardDuty 是主要的托管检测器。Security Hub 集中化可视性。EventBridge 将高严重性的发现路由到响应目标。 ## 设计目标 | 目标 | 实现 | |---|---| | 集中化 AWS 审计遥测数据 | CloudTrail，包含 S3 和 CloudWatch Logs 目标 | | 使用托管云威胁检测 | 在 `us-east-1` 中启用 GuardDuty | | 聚合安全发现结果 | Security Hub 仪表板和发现摄取 | | 自动化高严重性响应路由 | EventBridge 规则匹配严重性 `>= 7` 的 GuardDuty 发现 | | 通知人工分析师 | 订阅 SOC 分析师收件箱的 SNS 电子邮件订阅 | | 保持安全的响应行为 | Lambda 以模拟/日志模式运行，而不是修改基础设施 | | 展示最小权限原则 | 只读的 SOC 分析师 IAM 角色和限定范围的 EC2 侦察角色 | ## 核心组件 | 组件 | 用途 | |---|---| | **CloudTrail** | 记录 AWS API 活动，用于审计和调查。 | | **S3** | 在专用的私有存储桶中存储 CloudTrail 日志证据。 | | **CloudWatch Logs** | 为 CloudTrail 和 Lambda 执行输出提供近实时的日志可见性。 | | **GuardDuty** | 检测可疑的云活动并分配严重性评分的发现结果。 | | **Security Hub** | 将发现结果聚合到集中的 SOC 仪表板中。 | | **EventBridge** | 将高严重性的 GuardDuty 发现路由到下游响应目标。 | | **SNS** | 向分析师收件箱发送实时电子邮件告警。 | | **Lambda** | 解析 GuardDuty 发现，对严重性进行分类，识别受影响的资源，并记录模拟的响应操作。 | | **IAM** | 实施基于角色的访问和最小权限调查权限。 | ## 验证策略 CloudSentinel 采用两阶段方法进行了验证，以便分别评估流水线功能和检测保真度。 ### 阶段 1 — 综合流水线验证 生成了 GuardDuty 样本发现，以在依赖实时攻击者行为之前确认端到端集成路径正常工作。 | 验证点 | 结果 | 证据 | |---|---|---| | GuardDuty 生成发现结果 | 404 个样本发现，包含高和严重级别 | `screenshots/11-guardduty-sample-findings.png` | | Security Hub 聚合发现结果 | 样本发现出现在集中化仪表板中 | `screenshots/12-SecurityHub-sample-findings.png` | | SNS 交付告警 | 收到电子邮件通知 | `screenshots/13-sns-email-alert.png` | | Lambda 执行 | 事件输出出现在 CloudWatch Logs 中 | `screenshots/14-lambda-cloudwatch-logs.png` | 样本发现被记录为**集成测试**，而非真实的攻击证据。 ### 阶段 2 — 真实检测验证 实验室 EC2 实例配置了限定范围的 IAM 角色，并被视为受损的工作负载。初始枚举产生了低信号的侦察活动，但并未可靠地越过高严重性自动化阈值。随后，通过从外部机器使用实例角色凭据，该场景被升级为更高保真度的凭据外泄测试。 | 结果 | 值 | |---|---| | GuardDuty 发现 | `UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS` | | 严重性 | 8 / 10 — 高 | | 区域 | `us-east-1` | | 大致检测时间 | ~24 分钟 | | 流水线响应 | EventBridge 匹配严重性 `>= 7`，SNS 交付电子邮件，Lambda 记录事件 |  *GuardDuty 独立生成了严重性为 8 的 `UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS`。账户、资源和凭据标识符已被隐去。*  *EventBridge 规则通过 SNS 路由了该发现。电子邮件在发现创建后的几秒钟内到达分析师收件箱。* 额外证据： - `screenshots/15-simulation-a-recon-commands.png` — 来自受损实例的内部枚举 - `screenshots/15b-credential-exfiltration-external.png` — 从外部机器使用的实例角色凭据 - `screenshots/18-securityhub-real-finding.png` — 在 Security Hub 中聚合的相同发现 完整报告：[`docs/attack-simulation-report.md`](docs/attack-simulation-report.md) ## 设计决策 | 决策 | 原理 | 权衡 | |---|---|---| | 使用 GuardDuty 作为主要检测器 | 无需部署代理即可提供 AWS 原生托管检测 | 自定义程度不如自定义检测工程 | | 仅在严重性 `>= 7` 时触发自动化 | 减少告警噪音，并将自动化集中在高可信度的发现上 | 中等严重性的发现需要人工审查 | | 在 EventBridge 中直接监听 GuardDuty | 简化路由并避免依赖 Security Hub 的摄取延迟 | Security Hub 仍用于聚合，但不作为自动化源 | | 使用 SNS 电子邮件进行通知 | 简单的 AWS 原生告警路径，设置最少 | 在操作丰富度上不如 Slack、PagerDuty 或 ServiceNow | | 保持 Lambda 处于模拟模式 | 安全地展示响应逻辑，而不会更改实时基础设施 | 尚未执行真正的遏制 | | 在 EC2 上使用 IAM 角色而不是长期密钥 | 建模临时凭据的最佳实践 | 需要设置实例配置文件 | | 在真实攻击之前使用样本发现进行验证 | 安全且可重复地确认集成路径 | 必须与真实检测证据明确区分 | 更多细节：[`docs/design-decisions.md`](docs/design-decisions.md) ## 检测覆盖范围 | 威胁行为 | 来源 | 状态 | |---|---|---| | GuardDuty 高严重性发现路由 | EventBridge | 已通过样本和真实发现验证 | | 电子邮件告警交付 | SNS | 已验证 | | 事件解析和响应日志记录 | Lambda + CloudWatch Logs | 已验证 | | EC2 角色凭据外泄 | GuardDuty | 已通过真实发现验证 | | 来自 EC2 的内部 AWS 枚举 | CloudTrail / GuardDuty 遥测 | 已观察到；但单独并未可靠地越过严重性 `>= 7` | 查看 [`docs/detection-coverage.md`](docs/detection-coverage.md)。 ## 事件响应经验教训 终止受损的 EC2 实例**不会**立即使已经外泄的临时凭据失效。这些凭据在过期之前一直有效，因为它们是 IAM 角色会话凭据，而不是由实例生命周期直接控制的凭据。 完整的响应计划必须考虑到： - 角色会话撤销， - 凭据过期窗口， - IAM 角色审查， - CloudTrail 调查， - 以及对受影响工作负载的遏制。 ## 仓库结构 ``` CloudSentinel-SOC-Project/ ├── README.md ├── architecture/ │ ├── cloudsentinel-architecture.png │ └── cloudsentinel-architecture.mmd ├── docs/ │ ├── attack-simulation-report.md │ ├── cleanup-and-cost-control.md │ ├── design-decisions.md │ ├── detection-coverage.md │ └── operational-runbook.md ├── eventbridge/ │ └── guardduty_high_severity_rule.json ├── lambda/ │ └── incident_responder.py └── screenshots/ └── build and validation evidence ``` ## 限制 - Lambda 目前执行事件解析和模拟响应日志记录；它不会自动隔离基础设施。 - EventBridge 自动化的范围限定为严重性 `>= 7` 的 GuardDuty 发现。 - 该部署是单区域的（`us-east-1`）。生产环境的部署将需要多区域事件路由或集中化聚合。 - Security Hub 用于可见性和聚合；当前的自动化源是直接来自 GuardDuty。 ## 清理和成本控制 临时 EC2 资源在验证后被终止，项目完成后应审查收费的安全服务。查看 [`docs/cleanup-and-cost-control.md`](docs/cleanup-and-cost-control.md)。 由 [Chike-dev](https://github.com/Chike-dev) 在 AWS 实验账户中构建。区域：`us-east-1`。

标签：AMSI绕过, AWS, DPI, PB级数据处理, StruQ, 威胁检测, 安全运维, 自动化响应, 逆向工具