情报驱动的检测工程

01 · 情报到检测的转化链路

情报驱动检测的目标链路是：情报入库（STIX/IOC）→ 富化（Enrichment）→ 规则生成（Sigma）→ 目标平台转换（Backend/Pipeline）→ 自动部署（SIEM/EDR）→ 持续验证。每一环都有明确的耗时预算，全链路以"情报到检测"（Intel-to-Detection）时长作为核心度量指标。

1.1 环节耗时的可观测性要求

• 流水线每个环节输出结构化日志：情报ID、环节名、开始/结束时间戳、处理结果、失败原因——这是"情报到检测时长"指标的唯一可信数据源。
• 任一环节失败须自动重试（幂等设计），重试两次仍失败则进入人工队列并保留原始输入，杜绝"静默丢弃情报"。
• 每月按情报来源统计各环节P50/P95耗时，定位瓶颈环节（经验上瓶颈最常出现在字段映射管道与灰度观察期的人工确认）。

02 · Sigma规则体系

2.1 Sigma是什么

Sigma是面向SIEM系统的通用日志检测签名格式（Generic Signature Format for Log Events），2016年由Florian Roth与Thomas Patzke发起，现由SigmaHQ社区维护，可视为"日志检测领域的Snort/YARA"。它的核心价值在于：检测逻辑写一次（YAML），通过转换器输出为Splunk SPL、Microsoft Sentinel KQL、Elasticsearch查询、Microsoft 365 Defender KQL、EQL等多种后端格式，从而把检测规则从厂商锁定中解放出来。当前sigma-cli命令行工具基于pySigma库实现转换，各SIEM后端以插件形式安装（如pySigma-backend-splunk、pySigma-backend-elasticsearch）。

2.2 规则结构

Sigma规则为YAML格式，核心字段包括：title、id（UUID）、status（experimental/test/stable等）、description、logsource（产品/服务/类别）、detection（selection与condition布尔表达式）、falsepositives、level（informational/low/medium/high/critical）以及tags（通常映射MITRE ATT&CK技术编号）。

title: Suspicious PowerShell Download Cradle
id: 8d105af4-0000-4a7b-9c3e-example000001
status: experimental
description: 检测使用PowerShell下载执行远程代码的可疑命令行
logsource:
    category: process_creation
    product: windows
detection:
    selection_img:
        Image|endswith: '\\powershell.exe'
    selection_cli:
        CommandLine|contains:
            - 'IEX'
            - 'Invoke-Expression'
            - 'DownloadString'
            - 'bypass'
    condition: selection_img and selection_cli
falsepositives:
    - 管理员授权的远程管理脚本
level: high
tags:
    - attack.execution
    - attack.t1059.001

2.3 与既有检测生态的关系

• 与YARA/Suricata互补：YARA面向文件/内存样本特征，Suricata面向网络流量特征，Sigma面向主机与日志遥测，三者覆盖不同检测面，共用同一情报库。
• 与SIEM原生规则的关系：Sigma解决"规则可移植"，落地时仍需按各SIEM字段映射（Pipeline）调整数据模型差异，例如Windows事件需经Sysmon或ECS（Elastic Common Schema）管道映射字段名。
• 规则规模：SigmaHQ官方仓库维护数千条社区检测规则并持续更新，是自建规则库的高质量起点（具体条数随版本变化，以仓库实时状态为准）。

2.4 规则质量与元数据规范

• 状态生命周期：规则必须携带status字段并遵循experimental（新规则观察期）→test→stable→deprecated（退役）的流转，状态变更与理由记录在提交历史中。
• ATT&CK标注纪律：tags中必须标注攻击技术（如attack.t1059.001），可选标注攻击战术、CVE编号与CAR分析编号，保证规则可机器化地纳入覆盖度统计；v19版战术名变更的标注迁移见本节"版本更新提示"。
• 级别与处置分级映射：level字段（informational/low/medium/high/critical）应对应组织内告警分级与响应时限（如critical级映射15分钟内响应），映射表在管道配置中统一定义。
• 误报声明：falsepositives字段必填，写清已知误报场景与豁免条件——这是后续规则调优与SOAR分级处置的依据。
• 时效字段：date/modified字段记录创建与修改日期，支持按"长期未命中规则"做定期复审与退役。
• 关联规则（Correlation Rules）：Sigma规范自2023年起引入关联规则能力（temporal、ordered_temporal等类型），支持将多条单事件规则按时间窗与顺序组合为序列检测（如"多账号连续登录失败后成功"），弥补单事件规则对慢速低频攻击的盲区（示例见第06节）。

2.5 后端转换对照

同一条Sigma规则经sigma-cli转换后的后端输出形态如下（教学示意，具体输出随版本与管道配置变化）：

2.6 规则评审准入清单

• 元数据完备：id（UUID唯一）、status、date/modified、level、falsepositives、ATT&CK tags七项缺一不可。
• 可转换性：CI中对全部目标后端执行转换，任一后端失败即退回修改。
• 可验证性：level≥medium的规则必须附验证用例（Atomic Red Team编号或自编导出的样本回放脚本）。
• 可运维性：说明字段写清"检测什么、为什么、误报了先查什么"，使值班分析师无需询问作者即可处置。
• 去重检查：与现有规则库做逻辑相似度比对，避免同义规则堆积抬高告警量。

03 · STIX到Sigma的映射

情报层的STIX 2.1对象需映射为Sigma的日志源与匹配条件。下表给出常见可观测对象（SCO）类型的映射关系：

3.1 IOC归一化规范

映射前的归一化是低误报的前提，本课题规定：域名统一转小写并按IDNA/Punycode规范解析同形异义字符；URL去除默认端口与末尾斜杠、统一百分号编码大小写；哈希统一大写十六进制；IP压缩CIDR重叠段并剔除保留地址段（RFC 1918等）后再进入封禁/检测规则。归一化函数须经单元测试覆盖已知边界样例。

04 · 检测工程CI/CD流水线

检测规则应像代码一样管理：Git版本控制、Pull Request评审、自动化转换与校验、灰度发布、可回滚。业界通行的流水线设计如下：

• 版本管理：规则仓库按平台/战术目录组织；每条规则带UUID、状态与变更历史，状态流转（experimental→test→stable→deprecated）有据可查。
• 提交校验：提交触发sigma语法校验与格式检查；CI中使用sigma-cli批量转换变更规则到全部目标后端，任一后端转换失败即阻断合并。
• 字段映射管道：将管道配置（如sysmon、ecs_windows）与规则一同入库版本化，保证日志源差异可追溯。
• 测试：对规则执行转换正确性测试与样本回放测试；新增规则须附攻击仿真用例（见第07节）。
• 部署：通过各SIEM API（如Splunk Saved Search、Sentinel Analytics Rules API）自动下发；先部署至低敏或镜像环境观察误报，再全量灰度。
• 回滚：每次部署生成版本快照，命中异常或误报飙升时可一键回退。

name: sigma-ci
on: [pull_request]
jobs:
  convert-and-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: pip install sigma-cli
      - run: sigma plugin install splunk elasticsearch sentinel
      # 将变更规则转换到全部目标后端，任一失败即阻断合并
      - run: sigma convert --pipeline sysmon,ecs_windows --target splunk rules/ --output-format json
      - run: sigma check rules/   # 规范与元数据检查

4.1 告警预算与规则性能门

检测工程最常见的失败不是"规则不命中"，而是"告警淹没分析师"。本课题设定：

• 单规则告警预算：stable级规则日均告警量设上限（建议≤5条/日），连续3日超限自动降级为observation并触发调优任务。
• 规则查询成本门：转换后的查询在SIEM沙箱执行基准测试，扫描数据量超阈值的规则须优化索引/过滤条件后方可投产。
• 告警分级配比监控：high+critical级告警占总量比例持续监控，异常升高说明前置过滤失效，优先排查而非继续叠加规则。
• 数据质量门：规则依赖的日志源断供超1小时即告警（"检测建立在数据上，数据消失=检测失明"，见第5页日志可见性）。

05 · 常见反检测手法与检测对策

规则设计必须假设攻击者会主动规避检测。下表汇总当前高频反检测手法及其日志检测切入点（ATT&CK技术编号已标注）：

06 · 从IOC到TTP：行为检测的必要性

6.1 金字塔之痛（Pyramid of Pain）

David Bianco于2013年提出的"Pyramid of Pain"模型指出：防御方掐断不同类型的攻击指标，给攻击者造成的"痛苦"不同——哈希值最廉价（攻击者一改了之），TTP（战术技术过程）最难改变（改变TTP等于改变攻击者的作战方式）。CrowdStrike《2026全球威胁报告》的数据为此提供了现实注脚：2025年其检测案例中82%为无恶意软件（malware-free）入侵，该比例2020年仅为51%（五年序列：51%→62%→71%→75%→79%→82%），攻击者大量滥用合法凭证与原生工具——纯哈希与文件IOC的检测覆盖存在结构性盲区。

6.2 TTP检测的落地方式

• ATT&CK映射：每条行为检测规则标注战术与技术编号（如T1059.001 PowerShell），使告警可直接归入ATT&CK矩阵做覆盖度盘点；v19拆分后须分别盘点Stealth与Defense Impairment两组覆盖。
• 检测覆盖率管理：使用DeTT&CT等开源工具把现有规则/数据源映射到ATT&CK技术，输出覆盖度热图，指导狩猎与规则补充优先级。
• 狩猎假设驱动：威胁狩猎（Threat Hunting）以假设为起点（"本季度重点排查凭证滥用与LOLBins"），在数据上验证后固化为检测规则。

6.3 Sigma关联规则示例

title: Multi-Account Failed Logons Followed by Success
id: 7c305af4-2222-4a7b-9c3e-example000062
status: experimental
description: 关联分析：同一源在15分钟内对3个以上账号登录失败后，至少一个登录成功
correlation:
    type: temporal
    rules:
        - failed_logon    # 引用既有单事件规则
        - successful_logon
    group-by:
        - SourceIp
    timespan: 15m
    condition:
        gte: 3
level: high
tags:
    - attack.credential_access
    - attack.t1110.001

关联规则的价值在于把"弱信号×频次×时序"组合成强信号，是覆盖慢速低频攻击（长驻留威胁，见第7页案例三）的关键手段。

07 · 验证与对抗仿真

规则上线不代表有效。本课题要求每条高危规则配套可重复的验证手段：

7.1 验证覆盖要求

• 强制配对：level≥high的规则在投产前必须完成至少一次原子测试命中验证，验证记录（测试用例编号、执行时间、命中截图/SPL结果）附在规则PR中。
• 回归机制：日志管道或EDR版本升级后，对全量stable规则自动执行一轮回归测试，防止"升级即失明"。
• 季度覆盖盘点：用DeTT&CT输出覆盖度热图，对本季度情报重点关注技术做差距分析，结果直接生成下一季度规则开发任务。

检测工程加固项

A. ATT&CK v18/v19 双标注过渡规范

• 存量规则tags允许过渡期同时保留v18与v19编号（如 attack.t1562.001 与 attack.t1685），但必须在modified字段注明迁移日期；新规则只标注v19。
• 覆盖度热图分别输出Stealth（TA0005）与Defense Impairment（TA0112）两张视图，避免沿用旧的单一“防御规避”口径造成重复计数。
• 对DET0317/DET0239等被替换的检测策略引用，统一改引新的Defense Impairment检测策略，并在规则库CI中加入“过期编号告警”。

B. 检测规则失效与降级处理

C. 告警抑制与去重纪律

同一实体（用户/主机/会话）在滑动窗口内重复命中同一规则时，SOAR侧做去重合并而非规则侧简单丢弃；抑制必须带原因码与到期时间，禁止无期限静默。所有抑制动作纳入月度审计抽样。

本节参考来源（第2页）