siem-detection

SIEM 检测 — 检测工程

构建、审计和维护 SIEM 检测内容——即触发告警的规则。这与 incident-triage（在告警触发后进行响应）和 soc-operations（运行 SOC，负责分诊告警）不同。本技能属于工程层：日志覆盖、规则编写、调优和检测即代码工作流。

交叉参考：incident-triage 介绍告警触发后的处理方式；threat-hunting 介绍主动的假设驱动式搜寻，这类搜寻通常会发展为检测规则；breach-patterns 提供从公开的数据泄露披露中提取的检测思路；soc-operations 介绍基于此处设计的检测规则开展告警分诊的运营工作；对于尚未运行 SIEM 的小团队，log-watch 可作为入门方案（使用定时 Agent 分析现有日志，帮助你开始使用本技能）。

授权

仅为用户拥有或获授权开展工作的环境编写和调优检测规则。本技能会编写规则文件（拥有 Write 权限），但不会将规则部署到生产环境、禁用现有规则，也不会更改线上 SIEM 中的告警路由。使用模拟攻击活动测试规则，只能在实验室环境中进行，或在已获主机所有者批准的主机上进行。

范围

本技能涵盖：

• 日志源覆盖情况评估（“我们是否收集了检测 X 所需的事件？”）
• 使用主流 SIEM 查询语言编写规则（Sigma、KQL、SPL、Elastic ES|QL、Chronicle YARA-L）
• MITRE ATT&CK 映射——为每条规则标注技术 ID，以便分析覆盖情况
• 检测即代码工作流（将规则存入 Git、运行 CI 测试、自动部署）
• 告警调优工作流——在不遗漏真正威胁的前提下降低误报
• 使用 ATT&CK Navigator 分析覆盖缺口

本技能不涵盖：

• 实时告警分诊（参见 incident-triage）
• 组建 SOC 团队或制定告警升级标准（参见 soc-operations）
• 主动威胁搜寻（参见 threat-hunting）

方法

步骤 1：将日志源映射到 ATT&CK 覆盖范围

编写任何规则之前，先审计你能检测到什么。

按观测内容对日志源分类：

类别	来源	可观测内容
终端	EDR（CrowdStrike、SentinelOne、Defender）、Sysmon、osquery	进程执行、文件写入、网络、注册表、父子进程关系
网络	Zeek/Bro、Suricata、NSM、防火墙、DNS 查询日志	连接、协议、DNS 查询、TLS 元数据
身份	Okta、Entra ID、AD、Auth0、GCP/AWS 登录记录	身份验证、MFA、组变更、角色分配
云	CloudTrail（AWS）、Audit Logs（GCP）、Activity Log（Azure）	API 调用——创建、变更或删除了什么
应用	应用日志、WAF 日志、负载均衡器日志、网关日志	请求 URL、状态码、身份验证结果
SaaS	Google Workspace、M365、Salesforce、GitHub 审计日志	管理操作、共享、敏感文档访问

检查覆盖缺口：

• 获取 MITRE ATT&CK Enterprise 矩阵
• 针对与你的环境相关的每种技术，询问：哪些日志源能暴露相关活动？
• 没有映射到日志源的技术属于盲点——编写规则前先记录下来

常见盲点：

• 有终端日志，但未捕获命令行参数（大多数 Windows 事件日志默认只记录二进制文件，不记录参数）
• 已收集云审计日志，却过滤掉了 ReadOnly: true 事件，导致攻击前侦察活动不可见
• 没有 SaaS 审计日志——现代攻击迟早都会涉及 SaaS 横向转移
• 应用日志没有关联 ID，无法将“WAF 发现了载荷”与“应用处理了载荷”关联起来

步骤 2：针对不同情况选择合适的检测模型

并非每种威胁都需要 SIEM 规则。根据检测目标选择合适的检测模型。

威胁特征	最佳模型	示例
已知 IOC（哈希、IP、域名）	威胁情报查询	Sysmon 哈希与已知恶意软件匹配
已知模式（特定命令、特定路径）	特征规则	powershell.exe -enc <base64>
已知异常（行为偏离基线）	统计检测	服务帐户突然从新的地理位置进行身份验证
事件序列	关联规则	5 分钟内发生登录失败 → 登录成功 → 权限变更
新型／前所未见	威胁狩猎（参见 threat-hunting）	基于假设的 SIEM 搜索
内部人员滥用	UEBA／风险评分	按时间加权累计的高风险行为

特征规则编写成本最低，也最容易调整；统计检测需要基线数据，并且在第一个月会产生更多误报。

步骤 3：编写规则

尽可能以 Sigma 作为事实来源

Sigma 是跨 SIEM 的检测格式。用 Sigma 编写规则；通过 sigmac / sigma-cli / pySigma 自动转换为你的后端格式。即使你今天只针对 Splunk，未来的自己也会感谢你。

title: AWS IAM CreateUser Followed by AttachUserPolicy
id: <UUID>
status: experimental
description: Detects an identity creating a new IAM user and immediately attaching an admin policy
references:
  - https://attack.mitre.org/techniques/T1136/003/
author: <name>
date: 2026-05-26
tags:
  - attack.persistence
  - attack.t1136.003
logsource:
  product: aws
  service: cloudtrail
detection:
  create_user:
    eventName: CreateUser
  attach_policy:
    eventName: AttachUserPolicy
    requestParameters.policyArn|contains: 'Administrator'
  timeframe: 10m
  condition: create_user and attach_policy
falsepositives:
  - Legitimate provisioning workflows (CI roles that bootstrap admin accounts)
level: high

KQL（Microsoft Sentinel / Defender / Azure Monitor）

SigninLogs
| where TimeGenerated > ago(1h)
| where ResultType != 0
| summarize FailureCount = count() by UserPrincipalName, IPAddress, bin(TimeGenerated, 5m)
| where FailureCount > 10
| join kind=inner (
    SigninLogs
    | where TimeGenerated > ago(1h)
    | where ResultType == 0
) on UserPrincipalName, IPAddress
| project TimeGenerated, UserPrincipalName, IPAddress, FailureCount

（同一用户／IP 的登录失败激增，随后该用户／IP 登录成功——这是密码喷洒攻击成功的典型表现。）

SPL（Splunk）

index=aws sourcetype=aws:cloudtrail
  (eventName=CreateUser OR eventName=AttachUserPolicy)
| transaction userIdentity.arn maxspan=10m
| where like(eventName, "%CreateUser%") AND like(eventName, "%AttachUserPolicy%")
| table _time, userIdentity.arn, eventName, requestParameters

ES|QL（Elastic）

FROM logs-aws.cloudtrail-*
| WHERE event.action == "CreateUser" OR event.action == "AttachUserPolicy"
| STATS create_count = COUNT(*) BY user.arn, event.action
| WHERE create_count > 0

（使用与你的 SIEM 相匹配的 LookML / KQL / SPL / ES|QL，但应在 Sigma 中编写规范版本。）

步骤 4：映射到 MITRE ATT&CK

每条规则都应至少标记一种 ATT&CK 技术。覆盖情况会汇总到 ATT&CK Navigator（navigator.mitre-attack.org）：

• 导出带有 ATT&CK 标签的规则
• 将结果呈现在 Navigator 矩阵中
• 按战术识别覆盖缺口——“我们没有针对通过网络钓鱼实现初始访问的检测”比“我们需要更多规则”更具可操作性

Navigator JSON 格式是开放的；从规则即代码仓库生成这份报告只需几百行 Python，而且第一次有人问“我们能检测到什么？”时，这项投入就能收回成本。

步骤 5：调整

误报处理流程：

1. 以 level: experimental 部署规则 1-2 周
2. 检查每次触发——真阳性、误报，还是可以抑制？
3. 针对每个误报，询问： 能否缩小规则范围（使用更具体的筛选条件），或添加调整例外（将特定的已知正常行为加入允许列表）？
4. 跟踪比例——如果调整后误报仍超过 80%，说明检测模型不对（特征检测可能应改为统计检测，反之亦然）。不要用 100 条允许列表条目来掩盖错误的模型。
5. 只有在误报率达到可接受水平后，才提升到 level: high／生产环境

从未触发过的规则也是一种信号——日志覆盖可能有问题、查询可能有误，或者威胁确实尚未发生。通过在系统中运行一次刻意触发的测试事件，确认具体是哪种情况。

步骤 6：检测即代码

规则应存放在 Git 中，而不是 SIEM 控制台里。

detections/
├── aws/
│   ├── credential-access/
│   │   └── iam-create-user-attach-admin.yml
│   └── ...
├── windows/
├── linux/
└── identity/
    └── okta-password-spray.yml
.github/workflows/
└── detection-ci.yml

CI 检查：

• 验证 Sigma（sigma-cli check）
• ATT&CK 标签存在且可解析
• Description 和 references 字段非空
• 后端转换成功（例如 sigma convert -t splunk）
• 可选：针对已知正常的事件存储重放规则，并断言命中次数

部署：合并后，通过 API 将规则推送到 SIEM。通过 Git revert 回滚。

输出格式

覆盖情况评估：

# SIEM Detection Coverage
## Environment: [name]
## Date: [date]

### Log sources mapped
| Source | Status | Notes |
|---|---|---|

### ATT&CK coverage
| Tactic | Techniques covered / total | Blind spots |
|---|---|---|

### Rule inventory
| Rule | ATT&CK | Severity | Status | Last fired |
|------|--------|----------|--------|------------|

### Tuning queue
[Rules in experimental / needing FP triage]

### Recommended next 30 days
[Prioritized — usually 3-5 items]

每条规则的文档与规则放在一起（Sigma YAML），而不是放在单独的运行手册中。description、references 和 falsepositives 字段就是运行手册。

范围

• 为你自己的环境或用户明确授权的环境编写检测内容
• 拒绝编写规避规则或旨在标记合法安全工具的检测规则
• 故意监控员工，且超出 HR/法律部门批准范围的检测不在本项目范围内——请升级反馈给用户
• 每条规则都应提供足够的背景信息，让负责分类处理警报的分析人员知道该怎么做；缺少这些背景信息的规则会造成警报疲劳

参考资料

• MITRE ATT&CK Enterprise 矩阵
• MITRE ATT&CK Navigator
• Sigma 规则仓库（SigmaHQ/sigma）
• Florian Roth 关于“检测工程”的文章
• Splunk Security Essentials / Microsoft Sentinel 内容中心 / Elastic 检测规则仓库
• “检测工程成熟度矩阵”（Florian Roth）
• “痛苦金字塔”（David Bianco）——IOC 价值层级
• NIST SP 800-92（计算机安全日志管理）