PeteAndrews1289/aws-automated-soar-playbook

# AegisSOAR：事件驱动的云安全剧本 ## 概述 AegisSOAR 是一个无服务器的安全编排、自动化与响应（Security Orchestration, Automation, and Response, SOAR）实验室，展示了如何将云告警转化为由分析师审查的隔离操作。它解决了一个常见的 SOC 自动化难题：完全自动化的修复可能存在风险，但在云身份或工作负载疑似遭到入侵时，纯人工响应往往速度较慢。 该项目接收来自 Splunk 的告警遥测数据，通过 AWS API Gateway 和 Lambda 进行路由，将事件状态存储在 DynamoDB 中，生成简短的 AI 辅助威胁描述，并发送交互式 Slack 消息以供人工审批。如果分析师批准隔离操作，第二个 Lambda 函数会更新事件状态，并将拒绝策略附加到目标 IAM 角色。 最终系统展示了一个包含状态跟踪、AI 辅助摘要、Slack 交互以及 AWS IAM 隔离逻辑的人机协同（human-in-the-loop）SOAR 工作流。它属于实验室级别的实现，而非生产级的 SOAR 平台。 ## 核心功能 - 使用 AWS API Gateway 和 Lambda 构建了事件驱动的事件接收器。 - 将事件状态存储在 DynamoDB 中。 - 根据告警字段生成 AI 辅助的 SOC 叙述。 - 向安全运营频道发送交互式 Slack Block Kit 消息。 - 在执行隔离操作前加入人工审批环节。 - 在选择批准或误报后更新 Slack 消息。 - 通过向目标角色附加拒绝策略来执行 AWS IAM 隔离。 - 使用 Terraform 配置无服务器技术栈。 - 包含 Kubernetes 隔离策略说明和截图证据。 ## 架构 Splunk 将告警遥测数据发送到 AWS API Gateway 端点。Lambda 解析告警，将事件记录写入 DynamoDB，生成 AI 叙述，并发布交互式 Slack 告警。人工分析师选择是批准隔离还是将该事件标记为误报。Slack 将按钮操作发送给第二个 Lambda 接收器，后者更新 DynamoDB 并执行已批准的隔离操作。 ``` flowchart LR Attack[Simulated Attack] --> Splunk[Splunk SIEM Alert] Splunk -->|Webhook| APIGW[AWS API Gateway] APIGW --> Brain[Lambda SOAR Playbook] Brain --> DB[(DynamoDB Incident Table)] Brain --> OpenAI[OpenAI API] Brain --> Slack[Slack SecOps Channel] Slack -->|Analyst Button Click| Receiver[Lambda Slack Action Receiver] Receiver --> DB Receiver --> IAM[AWS IAM Containment Action] IAM --> Deny[Deny Policy Attached to Target Role] ``` ## 工具与技术 ### 云 / 基础设施 - AWS API Gateway - AWS Lambda - Amazon DynamoDB - AWS IAM - Terraform ### 安全工具 - Splunk webhook 告警 - SOAR 式隔离工作流 - 用于分析师审批的 Slack Block Kit - IAM 拒绝策略隔离 ### 编程 / 脚本 - Python 3.10 - Boto3 - Terraform HCL - JSON 告警解析 ### 监控 / 日志记录 - DynamoDB 中的事件记录 - Slack 告警消息 - Lambda 执行日志 - 基于截图的验证 ### 自动化 / CI/CD - 由 Terraform 管理的部署 - 此代码仓库中不包含 CI/CD pipeline ## 涉及的安全概念 该项目展示了 SOAR 设计、事件状态管理、人机协同修复、云隔离、IAM 响应操作、AI 辅助告警摘要以及安全自动化的权衡。 人工审批步骤是一个重要的设计决策。系统没有立即执行破坏性的隔离操作，而是暂停等待分析师审查，然后将最终状态记录为“已隔离”或“误报”。 该项目还展示了云响应自动化在具备窄权限、状态跟踪、可审计性和回滚规划之后，才能被视为达到生产可用标准。 ## 实施步骤 1. 定义了一个模拟的 Splunk 告警 payload，包含告警名称、攻击者 IP、主机和 IAM 角色等字段。 2. 构建了一个 Lambda 剧本来解析告警并创建事件 ID。 3. 添加了用于存储事件状态的 DynamoDB。 4. 添加了 AI 辅助叙述生成功能，为分析师提供上下文。 5. 发送了带有批准和误报操作的 Slack Block Kit 消息。 6. 构建了一个用于处理按钮回调的 Slack 操作接收器 Lambda。 7. 根据分析师的操作更新了 DynamoDB 状态。 8. 添加了 IAM 隔离逻辑，在批准后将拒绝策略附加到目标角色。 9. 使用 Terraform 配置了 API Gateway、Lambda 函数、DynamoDB 表、IAM 策略和函数 URL。 10. 通过本地告警模拟和截图验证了工作流。 ## 结果 / 发现 该项目产出了一个有效的人机协同响应流程。截图展示了 Terraform 部署、交互式 Slack 审批以及自动隔离的证据。该实验室展示了如何将原始告警转化为带有 AI 摘要、分析师决策点和云隔离操作的跟踪事件。 主要发现是，响应自动化在保留分析师对高影响操作的控制权时最为有用。该工作流可以加快分流和执行速度，同时在更改 IAM 权限之前仍然要求必须由人工做出决策。 ## 证据 / 产物 本代码仓库中的现有证据： - `docs/screenshots/human-in-the-loop-success.png` - `docs/screenshots/interactive-slack-ui.png` - `docs/screenshots/automated-pod-quarantine.png` - `docs/screenshots/terraform-apply-success.png` - `docs/incident-workflow.md` - `lambda_soar/soar_playbook.py` - `lambda_soar/slack_action_receiver.py` - `terraform/main.tf` - `k8s_quarantine/quarantine_policy.yaml` ## 挑战与经验教训 - SOAR 工作流需要状态跟踪，以便分析师能够查看事件是处于待处理、已隔离还是作为误报关闭的状态。 - 人工审批降低了破坏性自动隔离操作的风险。 - Slack 交互性需要谨慎处理回调并保证快速响应。 - IAM 隔离逻辑在应用于实验室环境之外之前，应严格限制其作用域。 - AI 摘要对于提供上下文很有用，但原始告警字段和确定性操作仍需保持可见。 ## 对安全职位的适用性 该项目契合安全工程师、云安全工程师、SOC 自动化工程师、检测工程师和事件响应等职位。它展示了告警接入、工作流编排、云响应自动化、IAM 隔离以及以分析师为中心的响应设计。 它同样适用于 AI 安全和 SecOps 相关职位，因为它使用了 LLM 来辅助分析师沟通，同时不允许模型直接做出隔离决定。 ## 未来改进 - 将 IAM 权限范围限定为特定的实验室角色，而不是使用宽泛的隔离权限。 - 为公开的 webhook 端点添加请求签名或身份验证。 - 为每个事件状态的转换添加结构化的 CloudWatch 日志记录和指标。 - 添加回滚逻辑，以便在审查后解除隔离状态。 - 为 Slack 回调解析和事件状态更新添加测试。 - 添加 Terraform 变量和示例，以实现更安全的部署。 - 导出一份示例 Splunk 告警配置。 - 为一次模拟事件生成完整的事件时间线报告。

标签：AWS, DPI, PB级数据处理, Petitpotam, SOAR, 人工智能, 安全运维, 用户模式Hook绕过, 网络调试, 自动化, 逆向工具