# Implementing Siem Use Cases For Detection

> 通过设计映射到 MITRE ATT&CK 技术的关联规则、阈值告警和行为分析， 在 Splunk、Elastic 和 Sentinel 中实施 SIEM 检测用例。 适用于 SOC 团队需要扩展检测覆盖范围、规范用例生命周期管理， 或构建与组织威胁画像对齐的检测库时。

- Skill: `killvxk/implementing-siem-use-cases-for-detection` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add killvxk/implementing-siem-use-cases-for-detection`
- Raw SKILL.md: https://api.skillmd.com/api/skills/killvxk/implementing-siem-use-cases-for-detection/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: Apache-2.0
- Author: killvxk (https://skillmd.com/u/killvxk)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/killvxk/implementing-siem-use-cases-for-detection

---

# 实施 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 并识别缺口：

```python
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：设计用例规格

使用标准化模板记录每个用例：

```yaml
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 关联搜索：**
```spl
| 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 数据：
```spl
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 规则：**
```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 规则：**
```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 验证检测规则：

```bash
# 安装 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 中验证检测：
```spl
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：部署并监控用例健康状态

追踪检测规则效能：

```spl
-- 用例触发频率
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 条（被改进版本替代）
```