PRATIK-DHARME/incident-response-commander

GitHub: PRATIK-DHARME/incident-response-commander

基于 IBM watsonx Orchestrate 构建的受治理多代理 SOC 助手,通过固定的证据收集→评分→遏制→报告流程自主完成安全告警分诊与分级遏制操作。

Stars: 0 | Forks: 0

# Incident Response Commander 一个基于 **IBM watsonx Orchestrate** 构建的、受治理的多代理安全运营中心(SOC)助手。 它接收安全告警,自主跨日志、身份、威胁情报、影响范围以及数据分类源进行调查,通过确定性评分准则推导严重程度,自主执行可逆的遏制操作,同时将破坏性操作限制在人工审批步骤之后,在遏制 API 性能下降时进行自适应调整,并生成一份带有不可篡改的哈希链审计追踪记录、符合合规要求的突发事件报告。 ## 面临的问题 SOC 分析师不缺告警——他们缺的是时间。一个中型企业的 SOC 每天大约要处理上千条告警。其中有 46% 到 83% 最终被作为误报关闭(来源:[Secure.com SOC 研究](https://www.secure.com/blog/soc/soc-alerts))。 据估计,分析师有 52% 的时间都花在证明告警是无害的,而不是去调查真正的威胁(来源:[Secure.com](https://www.secure.com/blog/soc/how-ai-enhances-soc-alert-investigation-and-reduces-mttr))。 而且,当凌晨 3 点确认了真实的入侵事件时,遏制操作却只能等待可能正在熟睡的人员来执行。 上下文整合是其中的瓶颈。每个告警都需要在 SIEM、身份提供者、威胁情报、云控制台、EDR 和工单队列中进行相同的排查——每次都要在五到六个系统中执行完全相同的步骤。Incident Response Commander 自动化了这一排查过程,以确定性的方式对证据进行评分,立即执行可逆的遏制操作,通过一个单一的审批问题提出破坏性动作建议,并生成包含检测调优建议的完整 IR 报告。 ## 架构 ``` alert (untrusted text) │ ▼ incident_commander ── supervisor, no direct tools │ ├──▶ investigator_agent (Phase 1: evidence) │ search_security_logs · lookup_user_identity · check_threat_intelligence │ assess_blast_radius · classify_data_exposure · correlate_prior_incidents │ ├──▶ reporting_agent (Phase 2: scoring + Phase 4: report) │ score_incident_severity · generate_incident_report │ store_incident_record · voice_briefing │ └──▶ containment_agent (Phase 3: action) execute_containment_action · request_human_approval │ ▼ IBM Cloudant: cases DB + audit_log DB (hash-chained) ``` 阶段顺序是固定且不可协商的:**证据收集 → 评分 → 遏制 → 报告**。 指挥官绝不会在评分前进行遏制;也绝不会在遏制解决前出具报告。 ### 四大代理 | 代理 | 角色 | 工具 | |-------|------|-------| | **`incident_commander`** | 监督者。负责告警接收、阶段排序、严重程度把关、人工审批对话以及状态报告。没有直接的工具——所有工作均被委派执行。 | — | | **`investigator_agent`** | 证据收集专家。运行全部六种证据收集工具,评估所有无害假设,并将每项发现归因于其数据源。 | 6 | | **`reporting_agent`** | 评分和报告专家。被调用两次:一次在遏制前对严重程度进行评分,一次在遏制后生成并持久化报告。 | 4 | | **`containment_agent`** | 受治理的操作专家。执行层级排序、幂等性、自适应切换和升级。 | 2 | 所有四个代理均使用 `groq/openai/gpt-oss-120b` 运行,采用 `react_core` 风格。 ## 遏制层级模型 每个遏制操作都根据其影响范围和可逆性进行分类。该层级绝不是在运行时分配的——它被编码在 `data/containment_policy.json` 中。 | 层级 | 授权者 | 操作 | |------|---------------|---------| | **A — 自动** | 代理立即执行 | `revoke_sessions`, `force_reauth`, `require_mfa_reregistration`, `add_ioc_watchlist`, `isolate_host_from_prod`, `preserve_evidence` | | **B — 审批** | 需要 `approved=True`;代理首先展示具体的调用及证据 | `disable_account`, `block_ip_perimeter`, `revoke_oauth_grant`, `disable_service_principal`, `quarantine_mailbox`, `apply_ca_block` | | **C — 绝不** | 代理仅提供建议;由人工在系统外执行 | `rotate_break_glass_credentials`, `domain_wide_policy_change`, `host_reimage` | 没有 `approved=True` 的层级 B 调用将返回 `status="approval_required"`,并且不会执行任何操作。 ### 遏制顺序(针对受损的云身份) 正确的顺序是固定的: 1. `preserve_evidence` — 在任何信息被销毁前,快照会话元数据 2. `revoke_sessions` — **首先**使刷新和会话 token 失效 3. `force_reauth` 4. `require_mfa_reregistration` — 如果怀疑 MFA 方法遭到篡改 5. `disable_account` — 仅在确有必要且获得层级 B 批准时执行 首先禁用账户是一个常见的错误。处于非活跃状态的账户并不能可靠地使有效的 OAuth 刷新 token 失效;在账户显示为已禁用的状态下,攻击者仍然保留 API 访问权限。 ### 防护栏 | 防护栏 | 规则 | |-----------|------| | 禁止阻断的 CIDR | RFC 1918 地址范围 + 企业出口白名单。返回 `status="refused"` | | 影响范围上限 | 一个突发事件中涉及超过 5 个目标则需要人工审批 | | 受保护的主体 | 应急和 `tag:critical` 身份始终路由到层级 B/C | | 幂等性 | 每次调用都接受一个 `idempotency_key`;重放将返回原始结果 | | 演练运行 | `dry_run=True` 返回原本将要触发的调用,但不执行任何操作 | | 可逆性 | 每个操作都会返回一个记录在审计日志中的 `rollback` 指令 | ## 安装与部署 ### 前置条件 - Python 3.11+ - `ibm-watsonx-orchestrate` ADK 2.13.0 (`pip install ibm-watsonx-orchestrate==2.13.0`) - 处于活跃状态的 watsonx Orchestrate 环境(SaaS 或通过 `orchestrate env add` 添加的本地环境) - 可选:用于持久化案例存储的 IBM Cloudant 实例 ### 1. 克隆并配置 ``` git clone cd incident-response-commander # Create and activate virtual environment python -m venv venv .\venv\Scripts\Activate.ps1 pip install ibm-watsonx-orchestrate==2.13.0 ``` 将 `.env.example` 复制为 `.env` 并填入您拥有的任何凭据。所有的集成都能优雅降级:当缺少 Cloudant 凭据时,工具会回退到本地 JSON 文件;当缺少 TTS 凭据时,`voice_briefing` 会返回文本记录。 ``` Copy-Item .env.example .env # Edit .env — CLOUDANT_APIKEY and TTS_APIKEY are optional for a demo ``` ### 2. 激活您的 watsonx Orchestrate 环境 ``` orchestrate env list # confirm your environment is listed orchestrate env activate -n my-wxo ``` ### 3. 按要求的顺序导入 始终按照 连接 → 工具 → 协作代理 → 最后是监督者 的顺序进行导入。 ``` # Connections (optional — configured via CLI, not YAML files) # Cloudant: # orchestrate connections add -a cloudant_db # orchestrate connections configure -a cloudant_db --env draft --type team --kind api_key --url $env:CLOUDANT_URL # orchestrate connections set-credentials -a cloudant_db --env draft -k $env:CLOUDANT_APIKEY # # IBM TTS: # orchestrate connections add -a ibm_tts # orchestrate connections configure -a ibm_tts --env draft --type team --kind api_key --url $env:TTS_URL # orchestrate connections set-credentials -a ibm_tts --env draft -k $env:TTS_APIKEY # Tools — import all twelve orchestrate tools import -k python -f tools/search_security_logs.py orchestrate tools import -k python -f tools/lookup_user_identity.py orchestrate tools import -k python -f tools/check_threat_intelligence.py orchestrate tools import -k python -f tools/assess_blast_radius.py orchestrate tools import -k python -f tools/score_incident_severity.py orchestrate tools import -k python -f tools/execute_containment_action.py orchestrate tools import -k python -f tools/generate_incident_report.py orchestrate tools import -k python -f tools/store_incident_record.py orchestrate tools import -k python -f tools/request_human_approval.py orchestrate tools import -k python -f tools/classify_data_exposure.py orchestrate tools import -k python -f tools/correlate_prior_incidents.py orchestrate tools import -k python -f tools/voice_briefing.py # Collaborator agents (any order) orchestrate agents import -f agents/investigator_agent.yaml orchestrate agents import -f agents/containment_agent.yaml orchestrate agents import -f agents/reporting_agent.yaml # Supervisor last orchestrate agents import -f agents/incident_commander.yaml ``` 验证所有内容是否就绪: ``` orchestrate tools list orchestrate agents list ``` ### 编辑后重新导入 ``` orchestrate agents import -f agents/incident_commander.yaml # upserts by name # If the upsert errors on a stale definition: orchestrate agents remove -n incident_commander orchestrate agents import -f agents/incident_commander.yaml ``` ## 运行三个演示场景 在 watsonx Orchestrate 聊天界面中打开 `incident_commander` 代理。 ### 场景 A — P1 紧急:包含数据泄露的账户入侵 粘贴以下告警文本: ``` Anomalous authentication for john.smith@company.com from 185.220.101.45 at 2026-07-28T22:12:00Z — legacy_basic_auth, MFA=false, country=RU, followed by role grant and bulk export of 14,208 records from customer-data-lake. ``` 预期结果: - 阶段 1 发现 Tor 出口节点、MFA 绕过、不可能的旅行(基线印度 → 俄罗斯登录)、通过收件箱转发规则实现的持久化、导出了 14,208 条 PII 记录 - 阶段 2 评分得出 risk_score ≥ 90 → `P1_CRITICAL`,`HIGH` 置信度 - 阶段 3 自动执行 `revoke_sessions` + `force_reauth`;请求分析师批准 `disable_account`;在遇到永久性失败(`403`)时,在继承的批准权限下切换至 `apply_ca_block` - 阶段 4 生成包含 ATT&CK 映射、Sigma 规则、GDPR 第 33 条通知标志以及语音简报的 13 部分 IR 报告 ### 场景 B — 无害:合法旅行自动关闭 ``` Login for priya.nair@company.com from 103.21.244.12 at 2026-07-25T14:30:00Z — MFA satisfied via push authenticator, device registered, location Singapore. ``` 预期结果: - 阶段 1 找到涵盖该日期的 HR 旅行记录、满足 MFA 要求、已注册的设备、企业出口 ASN - 阶段 2 评分得出 risk_score = 0 → `BENIGN` - 阶段 3 被跳过(对 BENIGN 状态不执行遏制) - 阶段 4 记录带有理由的自动关闭 ### 场景 C — 层级 B 防护栏拒绝 在任何实时的突发事件聊天中,请求执行: ``` Block IP 10.20.30.40 at the perimeter. ``` 预期结果:`status="refused"`,`refused_rule="never_block_cidr"`。代理解释 RFC 1918 地址位于禁止阻断列表中,并将此次拒绝视为正确的结果,而非错误。 ## 测试套件 在项目根目录下(激活虚拟环境)使用一个命令运行所有四个套件: ``` $env:PYTHONIOENCODING = "utf-8" .\run_all_tests.ps1 ``` 或者运行单个套件: ``` # Quick functional check — all 8 Tier-1 tools (18 checks) python tests/run_tool_tests.py # Five scenario integration checks covering severity scoring and # the full containment state machine (Scenarios A–E) python tests/verify_scenarios.py # End-to-end report generation + hash-chain audit trail verification python tests/test_report_tools.py # Four Tier-2 tools: request_human_approval, classify_data_exposure, # correlate_prior_incidents, voice_briefing python tests/test_tier2_tools.py ``` 所有测试均完全在离线状态下运行——无需 Orchestrate 运行时,不进行网络调用。测试通过垫片(shim)修补了 `@tool` 装饰器,使得每个工具文件都能在 ADK 外部正常导入。 ### 验证内容 | 测试文件 | 检查内容 | |-----------|----------------| | `run_tool_tests.py` | 所有层级 1 工具的返回结构、已知用户查找、Tor IP 分类、影响范围、严重程度算法、遏制层级、幂等性、演练运行、RFC 1918 拒绝、受保护主体拒绝 | | `verify_scenarios.py` | 场景 A:6 个加重信号 → risk_score 120,P1_CRITICAL。场景 B:5 个减轻信号 → 0,BENIGN,auto_close。场景 C:429 重试 → 403 永久失败 → 切换(无第三次尝试)。场景 D:RFC 1918 阻断被拒绝。场景 E:未获批准的层级 B 操作带着 proposed_code 停止。 | | `test_report_tools.py` | 13 部分报告结构、语音简报 ≤ 60 词、通知目标(P1+PII → 法务/隐私)、Sigma 规则、GDPR 合规标志、端到端 SHA-256 哈希链验证 | | `test_tier2_tools.py` | 层级 2 工具:批准提示格式、数据暴露分类、既往突发事件关联、语音简报降级路径 | ## 模拟数据 **本存储库中的所有日志、用户记录、威胁情报和突发事件数据均为完全虚构。** 具体如下: - `data/mock_logs.json` — 虚构的 OCSF 对齐安全事件,日期为 2026-07-28。 攻击窗口被压缩至大约 18 分钟以配合演示节奏;真实的凭据滥用攻击通常持续数小时至数天。 - `data/mock_users.json` — 虚构身份(`john.smith@company.com`, `priya.nair@company.com` 等)。不代表任何真实人物。 - `data/mock_threat_intel.json` — `185.220.101.45` 取自真实的 `185.220.101.0/24` Tor 出口节点范围,用以说明正确的基础设施分类。不暗示或断言任何特定个人具有恶意活动行为。 - `data/mock_containment_responses.json` — 用于遏制状态机的确定性模拟 API 响应。 HTTP 状态码(`429`、`403`)被预设用于演练重试和切换逻辑;它们不代表真实的 API 调用。 - 在任何模拟数据中均未将任何真实的威胁行为者、APT 组织或民族国家归因为攻击源。 Campaign 字段为 `null`;在测试中出现的任何 campaign 标签均使用 `SIMULATED-` 前缀,或明确标示为虚构。 - Tor 范围之外的 IP 地址尽可能使用 RFC 5737 文档地址范围 (`192.0.2.0/24`、`198.51.100.0/24`、`203.0.113.0/24`)或企业出口 ASN 白名单。 - 监管时间线(GDPR 第 33 条的 72 小时倒计时)仅用于说明目的;模拟数据中的日期 与任何真实事件无关。 ## 项目结构 ``` incident-response-commander/ ├── agents/ │ ├── incident_commander.yaml # supervisor — import last │ ├── investigator_agent.yaml │ ├── containment_agent.yaml │ └── reporting_agent.yaml ├── tools/ # 12 Python tools, one function per file │ ├── search_security_logs.py │ ├── lookup_user_identity.py │ ├── check_threat_intelligence.py │ ├── assess_blast_radius.py │ ├── score_incident_severity.py │ ├── execute_containment_action.py │ ├── generate_incident_report.py │ ├── store_incident_record.py │ ├── request_human_approval.py │ ├── classify_data_exposure.py │ ├── correlate_prior_incidents.py │ └── voice_briefing.py ├── data/ # mock datasets — see Simulated Data above │ ├── mock_logs.json │ ├── mock_users.json │ ├── mock_threat_intel.json │ ├── mock_containment_responses.json │ └── containment_policy.json ├── tests/ │ ├── run_tool_tests.py │ ├── verify_scenarios.py │ ├── test_report_tools.py │ └── test_tier2_tools.py ├── scripts/ # operational helpers │ ├── setup_cloudant_dbs.py │ ├── verify_cloudant.py │ └── verify_tts.py ├── docs/ │ ├── DEMO.md # step-by-step judge walkthrough │ ├── Project_Plan.md │ └── SUBMISSION.md ├── .env.example # copy to .env; never commit .env ├── wxo-implementation-guide.md # tool contracts and deployment spec └── workspace_config.yaml ``` ## 参考 - IBM Cost of a Data Breach 2025 — https://www.ibm.com/reports/data-breach - SOC alert false-positive rate research — https://www.secure.com/blog/soc/soc-alerts - MITRE ATT&CK — https://attack.mitre.org - NIST SP 800-61 Computer Security Incident Handling Guide - OCSF Schema — https://schema.ocsf.io - IBM watsonx Orchestrate ADK — https://developer.watson-orchestrate.ibm.com
标签:AI大模型应用, 多智能体, 威胁情报, 安全运营中心(SOC), 开发者工具, 网络安全审计, 自动化应急响应, 逆向工具