mcpField
I
implementing-siem-use-cases-for-detection

implementing-siem-use-cases-for-detection

github.com/mukul975安全35.2k43 次安装8 周前更新
代码仓库

关于 implementing-siem-use-cases-for-detection

这项技能面向 SOC 和检测工程团队,指导构建、测试、部署和维护 SIEM 检测用例。它结合 ATT&CK 覆盖分析、攻击模拟验证及规则健康监测。

主要功能

  1. 01映射 ATT&CK 覆盖缺口
  2. 02规范化记录检测用例
  3. 03为多种 SIEM 编写检测逻辑
  4. 04用攻击模拟测试规则
  5. 05监测效果并维护用例生命周期

适用场景

  1. 01将威胁评估发现转为检测规则
  2. 02验证合规要求所需的检测能力
  3. 03把红队发现纳入生产检测库
  4. 04迁移 SIEM 时转换并验证用例

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/mukul975/anthropic-cybersecurity-skills --skill implementing-siem-use-cases-for-detection

安装后在 Claude Code 中输入/implementing-siem-use-cases-for-detection确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

LICENSE
references/
api-reference.md
scripts/
agent.py

详细介绍

实施用于检测的 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

# Load current detection rules mapped to 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"]},
]

# Load ATT&CK Enterprise techniques
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)}")

# Prioritize gaps by threat relevance
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: Credential Dumping via LSASS Access
description: Detects tools accessing LSASS process memory for credential extraction
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:
  - Antivirus products scanning LSASS
  - CrowdStrike Falcon sensor
  - Windows Defender ATP
  - SCCM client
tuning_notes: >
  Maintain exclusion list for known security tools that legitimately access LSASS.
  Review exclusions quarterly for newly deployed security products.
sla: Alert within 5 minutes of detection
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 验证检测规则:

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

# Execute T1003.001 - Credential Dumping
Invoke-AtomicTest T1003.001 -TestNumbers 1,2,3

# Execute T1053.005 - Scheduled Task
Invoke-AtomicTest T1053.005 -TestNumbers 1

# Execute T1547.001 - Registry Run Key
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

记录测试结果:

TEST RESULTS — UC-2024-015
Atomic Test T1003.001-1 (Mimikatz):      DETECTED (alert fired in 47s)
Atomic Test T1003.001-2 (ProcDump):      DETECTED (alert fired in 32s)
Atomic Test T1003.001-3 (Task Manager):  FALSE NEGATIVE (excluded by whitelist — expected)
False Positive Rate (7-day backtest):     2 events (CrowdStrike scan — added to whitelist)
步骤 5:部署并监控用例健康状况

跟踪检测规则的有效性:

-- Use case firing frequency
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

-- Detection latency monitoring
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:维护用例库

为所有检测用例建立生命周期管理:

USE CASE LIFECYCLE
━━━━━━━━━━━━━━━━━━
1. PROPOSED    → New detection need identified (threat intel, gap analysis, incident finding)
2. DEVELOPMENT → Query written, false positive analysis, tuning
3. TESTING     → Atomic Red Team validation, 7-day backtest
4. STAGING     → Deployed in alert-only mode (no incident creation) for 14 days
5. PRODUCTION  → Full production with incident creation and SOAR integration
6. REVIEW      → Quarterly review of effectiveness, false positive rate, relevance
7. DEPRECATED  → Technique no longer relevant or replaced by better detection

关键概念

术语定义
用例正式化的检测规则,包含有文档记录的逻辑、测试、调优和生命周期管理
检测工程将设计、测试和维护 SIEM 检测规则作为软件开发规范来实践的学科
关联搜索组合来自多个来源的事件以识别攻击模式的 SIEM 查询
误报率属于良性活动的告警所占百分比 —— 生产用例的目标为 <20%
检测延迟事件发生与告警生成之间的时间间隔 —— 关键检测的目标为 <5 分钟
ATT&CK 覆盖率至少拥有一条生产检测规则的相关 ATT&CK 技术所占百分比

工具与系统

  • Splunk ES:企业级 SIEM,具备关联搜索、基于风险的告警和 Incident Review
  • Elastic Security:具备检测规则、EQL 序列和基于机器学习的异常检测的 SIEM
  • Microsoft Sentinel:云 SIEM,具备 KQL 分析规则、Fusion 机器学习引擎和 Lighthouse 多租户
  • Atomic Red Team:开源攻击模拟框架,用于针对 ATT&CK 技术测试检测规则
  • ATT&CK Navigator:MITRE 可视化工具,用于映射和跟踪各技术的检测覆盖情况

常见场景

  • 事件后用例:在勒索软件事件之后,针对调查期间发现的初始访问途径构建检测
  • 合规驱动:PCI DSS 要求检测管理员账户滥用 —— 为 4672/4720/4732 事件构建用例
  • 威胁情报驱动:新的 APT 组织针对您所在的行业 —— 针对其已记录的 TTP 构建用例
  • 红队发现:紫队演练识别出盲点 —— 将发现转化为生产检测规则
  • SIEM 迁移:从 QRadar 迁移到 Splunk —— 在新平台上转换并验证所有现有用例

输出格式

USE CASE DEPLOYMENT REPORT
━━━━━━━━━━━━━━━━━━━━━━━━━
Quarter:      Q1 2024
Total Use Cases: 147 (Production: 128, Staging: 12, Development: 7)

New Deployments This Quarter:
  UC-2024-012  Kerberoasting Detection (T1558.003)     — Production
  UC-2024-013  DLL Side-Loading (T1574.002)            — Production
  UC-2024-014  Scheduled Task Persistence (T1053.005)  — Production
  UC-2024-015  LSASS Memory Access (T1003.001)         — Staging

ATT&CK Coverage:
  Overall: 67% of relevant techniques (up from 61%)
  Initial Access:      78%
  Execution:           82%
  Persistence:         71%
  Credential Access:   65%
  Lateral Movement:    58% (priority gap area)

Health Metrics:
  Avg True Positive Rate:    74% (target: >70%)
  Avg Detection Latency:     2.3 min (target: <5 min)
  Use Cases Deprecated:      3 (replaced by improved versions)

评论

支持 Markdown