---

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

# 加载已映射到 ATT&CK 的当前检测规则
current_rules = [
    {"name": "Brute Force Detection", "techniques": ["T1110.001", "T1110.003"]},
    {"name": "Malware Hash Match", "techniques": ["T1204.002"]},
    {"name": "Suspicious PowerShell", "techniques": ["T1059.001"]},
]

# 加载 ATT&CK Enterprise 技术
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)*100:.1f}%)")
print(f"Gaps: {len(gaps)}")

# 按威胁相关性排列缺口优先级
priority_techniques = [
    "T1003", "T1021", "T1053", "T1547", "T1078",
    "T1055", "T1071", "T1105", "T1036", "T1070"
]
priority_gaps = [t for t in priority_techniques if t in gaps]
print(f"Priority gaps: {priority_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 的防病毒产品
  - CrowdStrike Falcon 传感器
  - Windows Defender ATP
  - SCCM 客户端
tuning_notes: >
  为合法访问 LSASS 的已知安全工具维护排除列表。
  每季度审查排除列表，检查新部署的安全产品。
sla: 检测后 5 分钟内告警
owner: detection_engineering_team
status: Production
created: 2024-03-15
last_tested: 2024-03-15

步骤 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 验证检测规则：

# 安装 Atomic Red Team
IEX (IWR 'https://raw.githubusercontent.com/redcanaryco/invoke-atomicredteam/master/install-atomicredteam.ps1' -UseBasicParsing)
Install-AtomicRedTeam -getAtomics

# 执行 T1003.001 - 凭据转储
Invoke-AtomicTest T1003.001 -TestNumbers 1,2,3

# 执行 T1053.005 - 计划任务
Invoke-AtomicTest T1053.005 -TestNumbers 1

# 执行 T1547.001 - 注册表运行键
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 条（被改进版本替代）