mcpField
B
building-soc-metrics-and-kpi-tracking

building-soc-metrics-and-kpi-tracking

github.com/mukul975セキュリティ35.2k178 回インストール8 週間前に更新
リポジトリ

building-soc-metrics-and-kpi-tracking について

SOCの責任者やチームが運用指標を定義、計測、報告するためのスキルです。対応時間、アラート品質、ATT&CKカバレッジ、業務量、経営層向けダッシュボードの例を扱います。

主な機能

  1. 01SOC主要指標の枠組み
  2. 02MTTDとMTTRの計測
  3. 03アラート品質と業務量の分析
  4. 04ATT&CK検知カバレッジの追跡
  5. 05経営層向けダッシュボードと推移報告

活用シーン

  1. 01四半期報告でのSOC実績レビュー
  2. 02業務量データに基づく人員配置の検討
  3. 03ツール変更前後のアラート・対応指標の比較
  4. 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 と一緒にインストールされる参考資料やスクリプト。

LICENSE
references/
api-reference.md
scripts/
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

コメント