building-soc-metrics-and-kpi-tracking
构建 SOC 绩效指标和 KPI 跟踪仪表盘,使用 SIEM 数据衡量平均检测时间(MTTD)、 平均响应时间(MTTR)、告警质量比率、分析师生产力和检测覆盖率。适用于 SOC 领导层 需要运营可视化、持续改进跟踪或高管级安全运营效能报告的场景。
Best use case
building-soc-metrics-and-kpi-tracking is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
构建 SOC 绩效指标和 KPI 跟踪仪表盘,使用 SIEM 数据衡量平均检测时间(MTTD)、 平均响应时间(MTTR)、告警质量比率、分析师生产力和检测覆盖率。适用于 SOC 领导层 需要运营可视化、持续改进跟踪或高管级安全运营效能报告的场景。
Teams using building-soc-metrics-and-kpi-tracking should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/building-soc-metrics-and-kpi-tracking/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How building-soc-metrics-and-kpi-tracking Compares
| Feature / Agent | building-soc-metrics-and-kpi-tracking | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
构建 SOC 绩效指标和 KPI 跟踪仪表盘,使用 SIEM 数据衡量平均检测时间(MTTD)、 平均响应时间(MTTR)、告警质量比率、分析师生产力和检测覆盖率。适用于 SOC 领导层 需要运营可视化、持续改进跟踪或高管级安全运营效能报告的场景。
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# 构建 SOC 指标与 KPI 跟踪
## 适用场景
以下情况使用本技能:
- SOC 领导层需要对运营绩效进行数据驱动的可视化分析
- 持续改进计划需要基准测量和趋势跟踪
- 高管报告要求量化安全态势和 ROI 指标
- 人员配置决策需要客观的工作负载与容量数据
- 合规审计需要有文档记录的 SOC 绩效证据
**不适用于**将指标作为针对分析师的惩罚性措施——指标应推动流程改进,而非个人绩效考核。
## 前置条件
- 具备 90 天以上事件和告警处置数据的 SIEM
- 包含事件生命周期时间戳数据的事件工单系统(ServiceNow、Jira)
- 分析师轮班计划和人员配置数据
- 用于追踪检测覆盖率的 ATT&CK Navigator
- 仪表盘平台(Splunk、Grafana 或 Power BI)
## 工作流程
### 步骤 1:定义核心 SOC 指标框架
建立与 NIST CSF 功能对齐的关键指标:
| 指标 | 定义 | 目标值 | NIST CSF |
|--------|-----------|--------|----------|
| MTTD | 从威胁发生到 SOC 检测的时间 | <15 分钟 | 检测 |
| MTTA | 从告警到分析师确认的时间 | <5 分钟 | 响应 |
| MTTI | 从确认到调查开始的时间 | <10 分钟 | 响应 |
| MTTC | 从调查到遏制的时间 | <1 小时 | 响应 |
| MTTR | 从检测到完全解决的时间 | <4 小时 | 恢复 |
| 误报率(FP Rate) | 误报告警的百分比 | <30% | 检测 |
| 真报率(TP Rate) | 真实告警的百分比 | >40% | 检测 |
| 覆盖率(Coverage) | 具有主动检测的 ATT&CK 技术 | >60% | 检测 |
| 驻留时间(Dwell Time) | 攻击者在网络中被检测前的时间 | <24 小时 | 检测 |
| 升级率(Escalation Rate) | 一级告警升级至二/三级的比例 | 15-25% | 响应 |
### 步骤 2:实施 MTTD/MTTR 测量
**平均检测时间(MTTD):**
```spl
index=notable earliest=-30d status_label="Resolved*"
| eval mttd_seconds = _time - orig_time
| where mttd_seconds > 0 AND mttd_seconds < 86400 --- 排除数据质量问题
| stats avg(mttd_seconds) AS avg_mttd,
median(mttd_seconds) AS med_mttd,
perc90(mttd_seconds) AS p90_mttd,
perc95(mttd_seconds) AS p95_mttd
by urgency
| eval avg_mttd_min = round(avg_mttd / 60, 1)
| eval med_mttd_min = round(med_mttd / 60, 1)
| eval p90_mttd_min = round(p90_mttd / 60, 1)
| table urgency, avg_mttd_min, med_mttd_min, p90_mttd_min
```
**平均响应时间(MTTR):**
```spl
index=notable earliest=-30d status_label="Resolved*"
| eval mttr_seconds = status_end - _time
| where mttr_seconds > 0 AND mttr_seconds < 604800 --- <7 天
| stats avg(mttr_seconds) AS avg_mttr,
median(mttr_seconds) AS med_mttr,
perc90(mttr_seconds) AS p90_mttr
by urgency
| eval avg_mttr_hours = round(avg_mttr / 3600, 1)
| eval med_mttr_hours = round(med_mttr / 3600, 1)
| eval p90_mttr_hours = round(p90_mttr / 3600, 1)
| table urgency, avg_mttr_hours, med_mttr_hours, p90_mttr_hours
```
**MTTD/MTTR 随时间趋势:**
```spl
index=notable earliest=-90d status_label="Resolved*"
| eval mttd_min = (_time - orig_time) / 60
| eval mttr_hours = (status_end - _time) / 3600
| bin _time span=1w
| stats avg(mttd_min) AS avg_mttd_min, avg(mttr_hours) AS avg_mttr_hours,
count AS incidents by _time
| table _time, incidents, avg_mttd_min, avg_mttr_hours
```
### 步骤 3:衡量告警质量和分析师生产力
**告警处置分析:**
```spl
index=notable earliest=-30d
| stats count AS total,
sum(eval(if(status_label="Resolved - True Positive", 1, 0))) AS tp,
sum(eval(if(status_label="Resolved - False Positive", 1, 0))) AS fp,
sum(eval(if(status_label="Resolved - Benign", 1, 0))) AS benign,
sum(eval(if(status_label="New" OR status_label="In Progress", 1, 0))) AS pending
| eval tp_rate = round(tp / total * 100, 1)
| eval fp_rate = round(fp / total * 100, 1)
| eval signal_noise = round(tp / (fp + 0.01), 2)
| table total, tp, fp, benign, pending, tp_rate, fp_rate, signal_noise
```
**分析师生产力指标:**
```spl
index=notable earliest=-30d status_label="Resolved*"
| stats count AS alerts_resolved,
avg(eval((status_end - status_transition_time) / 60)) AS avg_triage_min,
dc(rule_name) AS unique_rule_types
by owner
| eval alerts_per_day = round(alerts_resolved / 30, 1)
| sort - alerts_resolved
| table owner, alerts_resolved, alerts_per_day, avg_triage_min, unique_rule_types
```
**班次工作负载分布:**
```spl
index=notable earliest=-30d
| eval hour = strftime(_time, "%H")
| eval shift = case(
hour >= 6 AND hour < 14, "Day (06-14)",
hour >= 14 AND hour < 22, "Swing (14-22)",
1=1, "Night (22-06)"
)
| stats count AS alerts, dc(owner) AS analysts by shift
| eval alerts_per_analyst = round(alerts / analysts / 30, 1)
| table shift, alerts, analysts, alerts_per_analyst
```
### 步骤 4:追踪检测覆盖率
**ATT&CK 覆盖率得分:**
```spl
| inputlookup detection_rules_attack_mapping.csv
| stats dc(technique_id) AS covered_techniques by tactic
| join tactic type=left [
| inputlookup attack_techniques_total.csv
| stats dc(technique_id) AS total_techniques by tactic
]
| eval coverage_pct = round(covered_techniques / total_techniques * 100, 1)
| sort tactic
| table tactic, covered_techniques, total_techniques, coverage_pct
```
**数据源覆盖率:**
```spl
| inputlookup expected_data_sources.csv
| join data_source type=left [
| tstats count where index=* by sourcetype
| rename sourcetype AS data_source
| eval status = "Active"
]
| eval source_status = if(isnotnull(status), "Collecting", "MISSING")
| stats count by source_status
| table source_status, count
```
### 步骤 5:构建高管报告仪表盘
**月度 SOC 高管摘要:**
```spl
--- 按类别统计事件摘要
index=notable earliest=-30d status_label="Resolved*"
| stats count by urgency
| eval order = case(urgency="critical", 1, urgency="high", 2, urgency="medium", 3,
urgency="low", 4, urgency="informational", 5)
| sort order
--- 与上月对比
index=notable earliest=-60d
| eval period = if(_time > relative_time(now(), "-30d"), "本月", "上月")
| stats count by period, urgency
| chart sum(count) AS incidents by urgency, period
--- 前 5 位事件类别
index=notable earliest=-30d status_label="Resolved - True Positive"
| top rule_name limit=5
| table rule_name, count, percent
```
**安全态势记分卡:**
```spl
| makeresults
| eval metrics = mvappend(
"MTTD: 8.3 min (Target: <15 min) | STATUS: GREEN",
"MTTR: 3.2 hours (Target: <4 hours) | STATUS: GREEN",
"FP Rate: 27% (Target: <30%) | STATUS: GREEN",
"Detection Coverage: 64% (Target: >60%) | STATUS: GREEN",
"Analyst Utilization: 78% (Target: 60-80%) | STATUS: GREEN",
"Incident Backlog: 12 (Target: <20) | STATUS: GREEN"
)
| mvexpand metrics
| table metrics
```
### 步骤 6:实施持续改进跟踪
跟踪改进举措及其效果:
```spl
--- 改进举措追踪
| inputlookup soc_improvement_initiatives.csv
| eval status_color = case(
status="Completed", "green",
status="In Progress", "yellow",
status="Planned", "gray"
)
| table initiative, start_date, target_date, status, metric_impact, baseline, current
```
举措示例:
```csv
initiative,start_date,target_date,status,metric_impact,baseline,current
Risk-Based Alerting,2024-01-15,2024-03-15,Completed,Alert Volume,-84%,287/day
Sigma Rule Library,2024-02-01,2024-04-01,In Progress,ATT&CK Coverage,61%,64%
SOAR Phishing Playbook,2024-02-15,2024-03-30,In Progress,Phishing MTTR,45min,18min
Analyst Training Program,2024-01-01,2024-06-30,In Progress,TP Rate,31%,41%
```
## 核心概念
| 术语 | 定义 |
|------|-----------|
| **MTTD** | 平均检测时间——从威胁发生到 SOC 产生告警的平均时间 |
| **MTTR** | 平均响应时间——从检测到事件解决的平均时间 |
| **MTTA** | 平均确认时间——从告警生成到分析师分配的平均时间 |
| **信噪比(Signal-to-Noise Ratio)** | 真实告警与总告警数之比——越高越好 |
| **驻留时间(Dwell Time)** | 攻击者在环境中未被检测的持续时间——检测有效性的关键指标 |
| **分析师利用率(Analyst Utilization)** | 分析师用于有效调查的时间占比(相对于管理性事务) |
## 工具与系统
- **Splunk Dashboard Studio**:用于构建交互式 SOC 指标仪表盘的高级可视化框架
- **Grafana**:支持多数据源的开源分析和可视化平台
- **Power BI**:用于高管级报告和趋势分析的微软商业智能工具
- **ATT&CK Navigator**:MITRE 工具,用于以分层热图方式可视化检测覆盖率
- **ServiceNow Performance Analytics**:用于跟踪事件生命周期指标的 ITSM 分析模块
## 常见场景
- **季度业务评审**:展示 MTTD/MTTR 趋势、检测覆盖率增长和告警质量改善
- **人员配置论证**:使用工作负载指标为增加分析师人数或调整班次提供依据
- **工具 ROI 评估**:比较新工具部署前后的告警质量和响应时间
- **合规证据**:为 ISO 27001 或 SOC 2 审计提供有文档记录的 SOC 绩效指标
- **供应商对比**:使用行业调查(SANS、Ponemon)将 SOC 指标与同行基准对比
## 输出格式
```
SOC 绩效报告 — 2024 年 3 月
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
关键指标:
指标 当前值 目标值 趋势 状态
MTTD 8.3 分钟 <15 分钟 -12% 绿色
MTTR 3.2 小时 <4 小时 -18% 绿色
误报率 27% <30% -5% 绿色
真报率 41% >40% +3% 绿色
ATT&CK 覆盖率 64% >60% +3% 绿色
每分析师每日告警 24 条 <50 条 -84% 绿色
事件摘要:
总事件数: 147(关键: 3,高: 23,中: 78,低: 43)
平均解决时间: 3.2 小时(关键: 1.8h,高: 2.9h,中: 4.1h)
SLA 合规率: 94%(目标: >90%)
改进亮点:
[1] RBA 部署将每日告警从 1,847 条降至 287 条(-84%)
[2] 新增 Sigma 规则为覆盖率新增 12 项 ATT&CK 技术
[3] SOAR 钓鱼响应手册将钓鱼 MTTR 降低 60%
待改进领域:
[1] 横向移动检测覆盖率为 58%(低于 60% 目标)
[2] 夜班 MTTD 比白班慢 23%
[3] 4 个关键漏洞扫描工单超过 SLA 期限
```Related Skills
tracking-threat-actor-infrastructure
威胁行为者基础设施追踪涉及使用被动 DNS、证书透明度日志、Shodan/Censys 扫描、WHOIS 分析和网络指纹技术,对对手控制的 C2 服务器、钓鱼域名和暂存服务器等资产进行监控、映射和持续追踪
building-vulnerability-scanning-workflow
使用 Nessus、Qualys 和 OpenVAS 等工具构建结构化的漏洞扫描工作流, 对基础设施中的安全漏洞进行发现、优先级排序和修复跟踪。适用于 SOC 团队 需要建立定期漏洞评估流程、将扫描结果与 SIEM 告警集成,以及构建 修复跟踪仪表盘的场景。
building-vulnerability-exception-tracking-system
构建具有审批工作流、补偿控制文档和到期管理功能的漏洞例外与风险接受跟踪系统。
building-vulnerability-dashboard-with-defectdojo
部署 DefectDojo 作为集中式漏洞管理仪表盘,支持扫描器集成、去重、指标跟踪和 Jira 工单工作流。
building-vulnerability-aging-and-sla-tracking
实施漏洞老化仪表盘和 SLA 跟踪系统,根据基于严重性的时间线衡量修复绩效,并推动问责制落地。
building-threat-intelligence-platform
构建威胁情报平台(TIP)涉及将多个 CTI 工具部署和集成到统一系统中,用于收集、分析、富化和分发威胁情报,包括 MISP、OpenCTI、TheHive 和 Cortex 的开源工具集成。
building-threat-intelligence-feed-integration
构建自动化威胁情报(Threat Intelligence)源集成管道,将 STIX/TAXII 源、 开源威胁情报和商业 TI 平台接入 SIEM 和安全工具,实现实时 IOC 匹配和告警。 适用于 SOC 团队需要通过自动化源接入、标准化、评分和分发到检测系统来 将威胁情报付诸实践的场景。
building-threat-intelligence-enrichment-in-splunk
使用查询表、模块化输入和威胁情报框架,在 Splunk Enterprise Security 中构建自动化威胁情报富化流水线
building-threat-hunt-hypothesis-framework
构建系统化的威胁狩猎假设框架,将威胁情报、攻击模式和环境数据转化为可测试的狩猎假设。
building-threat-feed-aggregation-with-misp
部署 MISP(恶意软件信息共享平台)来聚合、关联和分发来自多个来源的威胁情报推送,用于集中式 IOC 管理和自动化 SIEM 集成。
building-threat-actor-profile-from-osint
使用开源情报(OSINT)技术构建全面的威胁行为者档案,记录对手的动机、能力、基础设施和 TTP,用于主动防御。
building-soc-playbook-for-ransomware
构建结构化的 SOC 勒索软件攻击事件响应手册,涵盖检测、遏制、根除和恢复阶段, 包含特定的 SIEM 查询、隔离流程和决策树。适用于 SOC 团队需要符合 NIST SP 800-61 和 MITRE ATT&CK 勒索软件技术的规范化响应流程时。