| name | implementing-siem-use-cases-for-detection |
| description | 通过设计映射到 MITRE ATT&CK 技术的关联规则、阈值告警和行为分析， 在 Splunk、Elastic 和 Sentinel 中实施 SIEM 检测用例。 适用于 SOC 团队需要扩展检测覆盖范围、规范用例生命周期管理， 或构建与组织威胁画像对齐的检测库时。
|
| domain | cybersecurity |
| subdomain | soc-operations |
| tags | ["soc","siem","use-cases","detection-engineering","mitre-attack","splunk","elastic","sentinel"] |
| version | 1.0 |
| author | mahipal |
| license | Apache-2.0 |
实施 SIEM 检测用例
适用场景
以下情况使用本技能：
- SOC 团队需要从头构建或扩展其 SIEM 检测库
- 威胁评估识别出需要新检测规则的 ATT&CK 技术覆盖缺口
- 检测工程师需要结构化流程用于用例设计、测试和部署
- 合规要求强制要求特定检测能力（PCI DSS、HIPAA、SOX）
不适用于即席狩猎查询——用例是经过规范化、测试和维护的检测规则，而非探索性搜索。
前置条件
- 具有生产数据的 SIEM 平台（Splunk ES、Elastic Security 或 Microsoft Sentinel）
- ATT&CK Navigator 用于覆盖缺口分析
- 日志源已规范化为 CIM/ECS 字段标准
- 用例文档框架（Wiki、Git 仓库或检测工程平台）
- 具有攻击模拟工具的测试环境（Atomic Red Team、MITRE Caldera）
工作流程
步骤 1：评估检测覆盖缺口
将当前检测规则映射到 ATT&CK 并识别缺口：
import json
current_rules = [
{"name": "Brute Force Detection", "techniques": ["T1110.001", "T1110.003"]},
{"name": "Malware Hash Match", "techniques": ["T1204.002"]},
{"name": "Suspicious PowerShell", "techniques": ["T1059.001"]},
]
with open("enterprise-attack.json") as f:
attack = json.load(f)
all_techniques = set()
for obj in attack["objects"]:
if obj["type"] == "attack-pattern":
ext = obj.get("external_references", [])
for ref in ext:
if ref.get("source_name") == "mitre-attack":
all_techniques.add(ref["external_id"])
covered = set()
for rule in current_rules:
covered.update(rule["techniques"])
gaps = all_techniques - covered
print(f"Total techniques: {len(all_techniques)}")
print(f"Covered: {len(covered)} ({len(covered)/len(all_techniques)*:f}%)")
()
priority_techniques = [
, , , , ,
, , , ,
]
priority_gaps = [t t priority_techniques t gaps]
()
步骤 2：设计用例规格
使用标准化模板记录每个用例：
use_case_id: UC-2024-015
name: 通过 LSASS 访问进行凭据转储
description: 检测访问 LSASS 进程内存以提取凭据的工具
mitre_attack:
tactic: Credential Access (TA0006)
technique: T1003.001 - LSASS Memory
data_sources:
- Process: OS API Execution (Sysmon EventCode 10)
- Process: Process Access (Windows Security 4663)
log_sources:
- index: sysmon, sourcetype: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational
- index: wineventlog, sourcetype: WinEventLog:Security
severity: High
confidence: Medium-High
false_positive_sources:
- 扫描 LSASS
步骤 3：在各平台实施检测逻辑
Splunk ES 关联搜索：
| tstats summariesonly=true count from datamodel=Endpoint.Processes
where Processes.process_name="lsass.exe"
by Processes.dest, Processes.user, Processes.process_name,
Processes.parent_process_name, Processes.parent_process
| `drop_dm_object_name(Processes)`
| lookup lsass_access_whitelist parent_process AS parent_process OUTPUT is_whitelisted
| where isnull(is_whitelisted) OR is_whitelisted!="true"
| `credential_dumping_lsass_filter`
或使用原始 Sysmon 数据：
index=sysmon EventCode=10 TargetImage="*\\lsass.exe"
GrantedAccess IN ("0x1010", "0x1038", "0x1fffff", "0x40")
NOT [| inputlookup lsass_whitelist.csv | fields SourceImage]
| stats count, values(GrantedAccess) AS access_flags by Computer, SourceImage, SourceUser
| where count > 0
Elastic Security EQL 规则：
process where event.type == "access" and
process.name == "lsass.exe" and
not process.executable : (
"?:\\Windows\\System32\\svchost.exe",
"?:\\Windows\\System32\\csrss.exe",
"?:\\Program Files\\CrowdStrike\\*",
"?:\\ProgramData\\Microsoft\\Windows Defender\\*"
)
Microsoft Sentinel KQL 规则：
DeviceProcessEvents
| where Timestamp > ago(1h)
| where FileName == "lsass.exe"
| where ActionType == "ProcessAccessed"
| where InitiatingProcessFileName !in ("svchost.exe", "csrss.exe", "MsMpEng.exe")
| project Timestamp, DeviceName, InitiatingProcessFileName,
InitiatingProcessCommandLine, AccountName
步骤 4：使用攻击模拟进行测试
使用 Atomic Red Team 验证检测规则：
IEX (IWR 'https://raw.githubusercontent.com/redcanaryco/invoke-atomicredteam/master/install-atomicredteam.ps1' -UseBasicParsing)
Install-AtomicRedTeam -getAtomics
Invoke-AtomicTest T1003.001 -TestNumbers 1,2,3
Invoke-AtomicTest T1053.005 -TestNumbers 1
Invoke-AtomicTest T1547.001 -TestNumbers 1,2
在 SIEM 中验证检测：
index=sysmon EventCode=10 TargetImage="*\\lsass.exe"
earliest=-1h
| stats count by Computer, SourceImage, GrantedAccess
| where count > 0
记录测试结果：
测试结果 — UC-2024-015
Atomic 测试 T1003.001-1（Mimikatz）： 已检测（47 秒内触发告警）
Atomic 测试 T1003.001-2（ProcDump）： 已检测（32 秒内触发告警）
Atomic 测试 T1003.001-3（任务管理器）：漏报（被白名单排除 — 预期行为）
误报率（7 天回测）： 2 个事件（CrowdStrike 扫描 — 已添加到白名单）
步骤 5：部署并监控用例健康状态
追踪检测规则效能：
-- 用例触发频率
index=notable
| stats count AS fires, dc(src) AS unique_sources,
dc(dest) AS unique_dests
by rule_name, status_label
| eval true_positive_rate = round(
sum(eval(if(status_label="Resolved - True Positive", 1, 0))) /
count * 100, 1)
| sort - fires
| table rule_name, fires, unique_sources, unique_dests, true_positive_rate
-- 检测延迟监控
index=notable
| eval detection_latency = _time - orig_time
| stats avg(detection_latency) AS avg_latency_sec,
perc95(detection_latency) AS p95_latency_sec
by rule_name
| eval avg_latency_min = round(avg_latency_sec / 60, 1)
| sort - avg_latency_sec
步骤 6：维护用例库
为所有检测用例建立生命周期管理：
用例生命周期
━━━━━━━━━━━━━━━━━━
1. 提议 → 识别新检测需求（威胁情报、缺口分析、事件发现）
2. 开发 → 编写查询、误报分析、调优
3. 测试 → Atomic Red Team 验证，7 天回测
4. 预发布 → 以仅告警模式部署（不创建事件）14 天
5. 生产 → 全面生产，包含事件创建和 SOAR 集成
6. 审查 → 每季度审查效能、误报率、相关性
7. 弃用 → 技术不再相关或被更好的检测所替代
核心概念
| 术语 | 定义 |
|---|
| 用例（Use Case） | 具有文档化逻辑、测试、调优和生命周期管理的规范化检测规则 |
| 检测工程（Detection Engineering） | 将 SIEM 检测规则的设计、测试和维护作为软件开发规范的实践 |
| 关联搜索（Correlation Search） | 结合来自多个来源的事件以识别攻击模式的 SIEM 查询 |
| 误报率（False Positive Rate） | 属于良性活动的告警比例——生产用例目标 <20% |
| 检测延迟（Detection Latency） | 事件发生到告警生成之间的时间——关键检测目标 <5 分钟 |
| ATT&CK 覆盖率（ATT&CK Coverage） | 至少有一条生产检测规则的相关 ATT&CK 技术比例 |
工具与系统
- Splunk ES：具有关联搜索、基于风险告警和事件审查功能的企业级 SIEM
- Elastic Security：具有检测规则、EQL 序列和基于 ML 异常检测的 SIEM
- Microsoft Sentinel：具有 KQL 分析规则、Fusion ML 引擎和 Lighthouse 多租户的云 SIEM
- Atomic Red Team：用于根据 ATT&CK 技术测试检测规则的开源攻击模拟框架
- ATT&CK Navigator：用于跨技术映射和追踪检测覆盖范围的 MITRE 可视化工具
常见场景
- 事件后用例：勒索软件事件后，根据调查发现的初始访问向量构建检测
- 合规驱动：PCI DSS 要求检测管理账户滥用——为 4672/4720/4732 事件构建用例
- 威胁情报驱动：新 APT 组织针对您所在行业——根据其记录的 TTP 构建用例
- 红队发现：紫队演练识别盲区——将发现转化为生产检测规则
- SIEM 迁移：从 QRadar 迁移到 Splunk——在新平台上转换和验证所有现有用例
输出格式
用例部署报告
━━━━━━━━━━━━━━━━━━━━━━━━━
季度： 2024 年第一季度
用例总数： 147 条（生产：128 条，预发布：12 条，开发中：7 条）
本季度新部署：
UC-2024-012 Kerberoasting 检测（T1558.003） — 生产
UC-2024-013 DLL 侧加载（T1574.002） — 生产
UC-2024-014 计划任务持久化（T1053.005） — 生产
UC-2024-015 LSASS 内存访问（T1003.001） — 预发布
ATT&CK 覆盖率：
整体： 67% 的相关技术（从 61% 提升）
初始访问： 78%
执行： 82%
持久化： 71%
凭据访问： 65%
横向移动： 58%（优先缺口领域）
健康指标：
平均真阳性率： 74%（目标：>70%）
平均检测延迟： 2.3 分钟（目标：<5 分钟）
已弃用用例： 3 条（被改进版本替代）
