📚 课程目录第1章 SOC安全事件自动化调查工程导论

1. SOC安全事件自动化调查工程导论

安全运营中心（SOC）每天面对的不是"有没有告警"，而是"告警太多、人手太少、判断太慢"。一个中等规模企业的SIEM每天可能产生数千到数万条告警，其中真正需要人工深入调查的可能只有几十条，但分析师必须先把大量噪声筛掉才能找到它们。自动化调查工程要解决的，正是这个"从海量告警到可处置结论"的转化效率问题。

课程目标与自动化调查的边界

本课程的目标不是教大家写一个"万能告警机器人"，而是建立一套可落地、可维护、可度量的调查自动化工程方法。学完之后，你应该能够：把一条原始告警拆解成可自动获取的证据项；设计调查剧本（Playbook）的输入、判断分支与输出结论；用编排工具把EDR、SIEM、威胁情报、资产库、身份系统串成一条调查链；并对自动化结论做质量评估与人工兜底设计。

但必须先把边界说清楚。自动化调查擅长的是确定性高、重复性强、数据可编程获取的环节，例如：提取告警中的IP/域名/哈希、查询威胁情报信誉、拉取进程树、比对资产归属、判断是否命中已知白名单。它不擅长的是：需要业务上下文推断的模糊判断、涉及跨部门沟通的处置决策、以及证据链存在矛盾时的最终定性。换句话说，自动化负责"把事实摆到桌面上"，人负责"在事实基础上做价值判断"。把这两者混为一谈，是很多SOC自动化项目失败的根本原因。

一个实用的边界判断标准：如果一名初级分析师按照固定步骤、查固定系统、看固定字段就能得出结论，这个环节就适合自动化；如果结论依赖"我觉得这个行为很可疑"这类经验直觉，就应保留人工介入点。

SOC工作流中的调查环节

典型的SOC事件处理流程可以概括为：检测（Detection）→ 分诊（Triage）→ 调查（Investigation）→ 响应（Response）→ 复盘（Lessons Learned）。自动化调查工程主要作用于分诊与调查这两个阶段，同时为响应阶段提供结构化输入。

分诊阶段要回答"这条告警值不值得查"；调查阶段要回答"这到底是什么、影响范围多大、是否仍在活动"。两者对自动化的要求不同：分诊追求快和准，通常用规则+情报富化即可；调查追求全和深，需要多源数据关联、时间线重建和证据固化。本课程后续章节会分别展开这两类剧本的设计方法。

下面这张图展示了自动化调查在SOC工作流中的位置，以及它与人工环节的交接关系。图中把"告警进入"到"结论输出"的关键节点、自动化可覆盖的部分和必须人工介入的部分做了区分，便于理解工程化的作用范围。

工程化视角与核心术语

把调查当"工程"而不是"手艺"，意味着我们要用可版本化、可测试、可观测的方式管理调查逻辑。核心术语包括：

告警（Alert）：检测规则命中的原始事件，是调查的输入单元。
事件（Incident）：经过分诊确认需要跟踪的告警或告警簇，是调查和响应的管理单元。
剧本（Playbook）：定义调查步骤、判断条件、数据源调用和输出格式的可执行流程。
富化（Enrichment）：为告警补充上下文，如IP归属、文件信誉、资产负责人、历史告警次数。
证据（Evidence）：调查过程中获取的、可支撑结论的结构化数据片段。
置信度（Confidence）：自动化结论的可信程度，通常用高/中/低或0-100分表示，决定是否需要人工复核。
误报（False Positive）：检测规则错误命中，实际无安全风险。
漏报（False Negative）：真实威胁未被检测到，是自动化调查需要反向验证的重点。

工程化的关键动作是把上述概念落到具体实现上。例如，一条"可疑PowerShell执行"告警进入后，剧本可以这样设计：第一步从告警字段提取主机名、用户名、命令行；第二步调用EDR接口获取该进程的完整进程树和父进程；第三步查询该主机近7天是否有同类告警；第四步比对命令行是否命中已知的合法运维脚本白名单；第五步根据前三步结果计算置信度并输出结论。每一步的输入、输出、超时和失败处理都要在剧本中明确定义，而不是靠分析师临场发挥。

自动化调查最常见的陷阱是"只做富化，不做判断"。把情报查询结果堆在告警旁边并不等于调查完成，必须定义清楚：什么条件下自动关闭、什么条件下升级为事件、什么条件下必须转人工。没有判断分支的剧本只是数据搬运工。

一个可参考的调查剧本骨架

下面给出一个简化的剧本结构示例，用于说明工程化调查的字段组织方式。实际落地时可根据所用编排平台（如SOAR、XSOAR、Shuffle等）的语法调整，但核心字段和判断逻辑是通用的。

playbook: suspicious_powershell_investigation
trigger: alert.rule_name == "Suspicious PowerShell Execution"
steps:
  - id: extract
    action: parse_alert_fields
    output: [hostname, username, command_line, parent_process]
  - id: enrich_edr
    action: edr.get_process_tree
    input: {host: "${hostname}", pid: "${alert.pid}"}
    timeout: 30s
    on_failure: mark_manual_review
  - id: check_history
    action: siem.query
    query: "host=${hostname} AND rule_group=execution AND time_range=7d"
    output: historical_count
  - id: whitelist_check
    action: lookup
    table: approved_admin_scripts
    key: "${command_line}"
    output: is_whitelisted
  - id: decide
    condition:
      - if: is_whitelisted == true AND historical_count == 0
        then: close_as_benign, confidence=high
      - if: is_whitelisted == false AND historical_count >= 3
        then: escalate_to_incident, confidence=high
      - else: route_to_analyst, confidence=medium

这个骨架体现了几个工程原则：每个步骤有明确的输入输出；外部调用有超时和失败兜底；判断分支覆盖了"自动关闭""自动升级""转人工"三种出口；置信度与出口绑定，避免自动化越权做高风险决策。后续章节会逐步把每个步骤展开为可落地的实现细节，包括数据源接口、字段映射、异常处理和效果度量。

最后需要强调：自动化调查的价值不在于"替代分析师"，而在于把分析师从重复劳动中释放出来，让他们把时间花在真正需要判断力的事情上。衡量一个自动化调查工程是否成功，看的不是自动化率有多高，而是平均调查时间（MTTI）是否下降、误报处理成本是否降低、真实威胁的发现率是否提升。这三个指标，将贯穿本课程后续所有章节的设计与评估。