building-soc-metrics-and-kpi-tracking について
SOCの責任者やチームが運用指標を定義、計測、報告するためのスキルです。対応時間、アラート品質、ATT&CKカバレッジ、業務量、経営層向けダッシュボードの例を扱います。
主な機能
- 01SOC主要指標の枠組み
- 02MTTDとMTTRの計測
- 03アラート品質と業務量の分析
- 04ATT&CK検知カバレッジの追跡
- 05経営層向けダッシュボードと推移報告
活用シーン
- 01四半期報告でのSOC実績レビュー
- 02業務量データに基づく人員配置の検討
- 03ツール変更前後のアラート・対応指標の比較
- 04監査向け運用実績の記録
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ mukul975/ anthropic-cybersecurity-skills --skill building-soc-metrics-and-kpi-trackingインストール後、Claude Code で/building-soc-metrics-and-kpi-trackingを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
LICENSEreferences/api-reference.mdscripts/agent.py詳細
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 分 | Detect |
| MTTA | アラートからアナリストによる確認までの時間 | <5 分 | Respond |
| MTTI | 確認から調査開始までの時間 | <10 分 | Respond |
| MTTC | 調査から封じ込めまでの時間 | <1 時間 | Respond |
| MTTR | 検知から完全な解決までの時間 | <4 時間 | Recover |
| FP 率 | 誤検知アラートの割合 | <30% | Detect |
| TP 率 | 真陽性アラートの割合 | >40% | Detect |
| カバレッジ | 有効な検知が設定された ATT&CK の手法 | >60% | Detect |
| 滞留時間 | 検知されるまでの攻撃者のネットワーク内滞在時間 | <24 時間 | Detect |
| エスカレーション率 | Tier 2/3 にエスカレーションされた Tier 1 アラートの割合 | 15-25% | Respond |
ステップ 2:MTTD/MTTR の測定を実装する
平均検知時間(MTTD):
index=notable earliest=-30d status_label="Resolved*"
| eval mttd_seconds = _time - orig_time
| where mttd_seconds > 0 AND mttd_seconds < 86400 --- Exclude data quality issues
| 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):
index=notable earliest=-30d status_label="Resolved*"
| eval mttr_seconds = status_end - _time
| where mttr_seconds > 0 AND mttr_seconds < 604800 --- <7 days
| 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 の傾向:
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:アラートの品質とアナリストの生産性を測定する
アラート処理結果の分析:
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
アナリストの生産性メトリクス:
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
シフト別の作業負荷分布:
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 カバレッジスコア:
| 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
データソースのカバレッジ:
| 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 月次エグゼクティブサマリー:
--- Incident summary by category
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
--- Month-over-month comparison
index=notable earliest=-60d
| eval period = if(_time > relative_time(now(), "-30d"), "This Month", "Last Month")
| stats count by period, urgency
| chart sum(count) AS incidents by urgency, period
--- Top 5 incident categories
index=notable earliest=-30d status_label="Resolved - True Positive"
| top rule_name limit=5
| table rule_name, count, percent
セキュリティ態勢スコアカード:
| 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:継続的改善の追跡を実装する
改善施策とその影響を追跡します。
--- Improvement initiative tracking
| 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
施策の例:
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 | 平均確認時間。アラート生成からアナリストへの割り当てまでの平均時間です |
| シグナル対ノイズ比 | 真陽性アラート数とアラート総数の比率です。高いほど良好です |
| 滞留時間 | 環境内で攻撃者が検知されずにとどまる期間です。検知の有効性を示す重要な指標です |
| アナリスト稼働率 | アナリストの時間のうち、付随業務ではなく生産的な調査に費やされる割合です |
ツールとシステム
- Splunk Dashboard Studio:インタラクティブな SOC メトリクスダッシュボードを構築するための高度な可視化フレームワークです
- Grafana:複数のデータソースに対応したオープンソースの分析・可視化プラットフォームです
- Power BI:経営層向けのレポートや傾向分析に使用する Microsoft のビジネスインテリジェンスツールです
- ATT&CK Navigator:検知カバレッジをレイヤー化されたヒートマップとして可視化する MITRE のツールです
- ServiceNow Performance Analytics:インシデントのライフサイクルメトリクスを追跡する ITSM 分析モジュールです
一般的なシナリオ
- 四半期ビジネスレビュー:MTTD/MTTR の傾向、検知対象範囲の拡大、アラート品質の改善を提示します
- 人員配置の正当化:業務量の指標を用いて、アナリストの増員やシフト調整の必要性を説明します
- ツールの ROI 評価:新しいツールの導入前後で、アラート品質と対応時間を比較します
- コンプライアンスの証拠:ISO 27001 または SOC 2 の監査向けに、文書化された SOC パフォーマンス指標を提示します
- ベンダーの比較:調査(SANS、Ponemon)を利用して、SOC 指標を業界の同業他社と比較評価します
出力形式
SOC PERFORMANCE REPORT — March 2024
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
KEY METRICS:
Metric Current Target Trend Status
MTTD 8.3 min <15 min -12% GREEN
MTTR 3.2 hrs <4 hrs -18% GREEN
FP Rate 27% <30% -5% GREEN
TP Rate 41% >40% +3% GREEN
ATT&CK Coverage 64% >60% +3% GREEN
Alerts/Analyst/Day 24 <50 -84% GREEN
INCIDENT SUMMARY:
Total Incidents: 147 (Critical: 3, High: 23, Medium: 78, Low: 43)
Avg Resolution: 3.2 hours (Critical: 1.8h, High: 2.9h, Medium: 4.1h)
SLA Compliance: 94% (Target: >90%)
IMPROVEMENT HIGHLIGHTS:
[1] RBA deployment reduced daily alerts from 1,847 to 287 (-84%)
[2] New Sigma rules added 12 ATT&CK techniques to coverage
[3] SOAR phishing playbook reduced phishing MTTR by 60%
AREAS FOR IMPROVEMENT:
[1] Lateral movement detection coverage at 58% (below 60% target)
[2] Night shift MTTD 23% slower than day shift
[3] 4 critical vulnerability scan tickets overdue on SLA
コメント
Markdown 対応