metrics-analysis

セキュリティ運用指標の分析

概要

このスキルでは、ServiceNow の主要なセキュリティ運用指標を分析するための構造化されたアプローチを提供します。SOC マネージャーやアナリストが、検知と対応の有効性を測定し、傾向を特定し、リソース配分を最適化できるようにします。

主な機能：

• インシデント全体の平均検知時間（MTTD）と平均対応時間（MTTR）を算出する
• カテゴリ、優先度、期間別にインシデント件数の傾向を追跡する
• 誤検知率とアナリストの生産性への影響を測定する
• アナリストの作業負荷の分布を分析し、ボトルネックを特定する
• 現在のパフォーマンスを過去のベースラインや業界目標と比較する
• 経営層のレビュー用に指標ダッシュボードとレポートを作成する

使用する場面： 定期的な SOC パフォーマンスレビュー（週次、月次、四半期ごと）、経営層向けレポート、キャパシティプランニング、または検知と対応のプロセスを最適化する際に使用します。

前提条件

• ロール： sn_si.manager、sn_si.admin、report_admin
• アクセス権： sn_si_incident、sn_si_task、sn_ti_observable、sys_audit テーブルへの読み取りアクセス権、および Aggregate API へのアクセス権
• プラグイン： Security Incident Response（sn_si）、Performance Analytics（任意ですが推奨）
• データ： 十分なインシデント履歴（傾向分析には最低 30 日分を推奨）

手順

ステップ 1：期間別にインシデント件数を算出する

期間別にインシデント件数を照会し、件数の傾向を把握します。

MCP を使用：

Tool: SN-Query-Table
Parameters:
  table_name: sn_si_incident
  query: opened_atONLast 30 days@javascript:gs.daysAgoStart(30)@javascript:gs.daysAgoEnd(0)
  fields: sys_id,number,category,subcategory,priority,state,opened_at,resolved_at,closed_at,close_code,assignment_group
  limit: 1000

REST を使用（件数の集計 API）：

GET /api/now/stats/sn_si_incident?sysparm_query=opened_atONLast 30 days@javascript:gs.daysAgoStart(30)@javascript:gs.daysAgoEnd(0)&sysparm_count=true&sysparm_group_by=category

GET /api/now/stats/sn_si_incident?sysparm_query=opened_atONLast 30 days@javascript:gs.daysAgoStart(30)@javascript:gs.daysAgoEnd(0)&sysparm_count=true&sysparm_group_by=priority

ステップ 2：平均検知時間（MTTD）を算出する

MTTD は、脅威が最初に出現してから検知されるまでの経過時間を測定します。observable の first_seen タイムスタンプをインシデントの opened_at と比較します。

MCP を使用：

Tool: SN-Execute-Background-Script
Parameters:
  script: |
    var gr = new GlideRecord('sn_si_incident');
    gr.addQuery('opened_at', '>=', gs.daysAgo(30));
    gr.addQuery('state', 'IN', '6,7'); // resolved or closed
    gr.query();
    var totalDetectTime = 0;
    var count = 0;
    while (gr.next()) {
      var obs = new GlideRecord('sn_ti_observable');
      obs.addQuery('security_incident', gr.sys_id);
      obs.orderBy('first_seen');
      obs.setLimit(1);
      obs.query();
      if (obs.next() && obs.first_seen) {
        var firstSeen = new GlideDateTime(obs.first_seen);
        var opened = new GlideDateTime(gr.opened_at);
        var diff = GlideDateTime.subtract(firstSeen, opened);
        totalDetectTime += diff.getNumericValue();
        count++;
      }
    }
    var avgMs = count > 0 ? totalDetectTime / count : 0;
    var avgHours = (avgMs / 3600000).toFixed(2);
    gs.info('MTTD: ' + avgHours + ' hours (based on ' + count + ' incidents)');

REST を使用（手動で算出）：

GET /api/now/table/sn_si_incident?sysparm_query=opened_atONLast 30 days@javascript:gs.daysAgoStart(30)@javascript:gs.daysAgoEnd(0)^stateIN6,7&sysparm_fields=sys_id,number,opened_at,resolved_at&sysparm_limit=500

# For each incident, query earliest observable:
GET /api/now/table/sn_ti_observable?sysparm_query=security_incident=[SYS_ID]^ORDERBYfirst_seen&sysparm_fields=first_seen&sysparm_limit=1

ステップ 3：平均対応時間（MTTR）を算出する

MTTR は、インシデントの作成から解決までの経過時間を測定します。

MCP を使用：

Tool: SN-Execute-Background-Script
Parameters:
  script: |
    var gr = new GlideRecord('sn_si_incident');
    gr.addQuery('opened_at', '>=', gs.daysAgo(30));
    gr.addQuery('resolved_at', '!=', '');
    gr.query();
    var totalResponseTime = 0;
    var count = 0;
    while (gr.next()) {
      var opened = new GlideDateTime(gr.opened_at);
      var resolved = new GlideDateTime(gr.resolved_at);
      var diff = GlideDateTime.subtract(opened, resolved);
      totalResponseTime += diff.getNumericValue();
      count++;
    }
    var avgMs = count > 0 ? totalResponseTime / count : 0;
    var avgHours = (avgMs / 3600000).toFixed(2);
    gs.info('MTTR: ' + avgHours + ' hours (based on ' + count + ' incidents)');

REST を使用（集計 API）：

GET /api/now/stats/sn_si_incident?sysparm_query=opened_atONLast 30 days@javascript:gs.daysAgoStart(30)@javascript:gs.daysAgoEnd(0)^resolved_atISNOTEMPTY&sysparm_avg_fields=business_duration&sysparm_count=true

ステップ 4：誤検知率を測定する

誤検知またはインシデントではないものとしてクローズされたインシデントの割合を算出します。

MCP を使用：

Tool: SN-Query-Table
Parameters:
  table_name: sn_si_incident
  query: closed_atONLast 30 days@javascript:gs.daysAgoStart(30)@javascript:gs.daysAgoEnd(0)^close_code=false_positive
  fields: sys_id,number,category,subcategory,assignment_group,closed_at
  limit: 500

Tool: SN-Query-Table
Parameters:
  table_name: sn_si_incident
  query: closed_atONLast 30 days@javascript:gs.daysAgoStart(30)@javascript:gs.daysAgoEnd(0)
  fields: sys_id
  limit: 1

REST を使用：

# Total closed incidents
GET /api/now/stats/sn_si_incident?sysparm_query=closed_atONLast 30 days@javascript:gs.daysAgoStart(30)@javascript:gs.daysAgoEnd(0)&sysparm_count=true

# False positives
GET /api/now/stats/sn_si_incident?sysparm_query=closed_atONLast 30 days@javascript:gs.daysAgoStart(30)@javascript:gs.daysAgoEnd(0)^close_code=false_positive&sysparm_count=true

ステップ 5：アナリストの作業負荷の分布を分析する

アナリストと割り当てグループ全体におけるインシデントの分布を測定します。

MCP を使用：

Tool: SN-Query-Table
Parameters:
  table_name: sn_si_incident
  query: opened_atONLast 30 days@javascript:gs.daysAgoStart(30)@javascript:gs.daysAgoEnd(0)^assigned_toISNOTEMPTY
  fields: assigned_to,assignment_group,priority,state
  limit: 1000

REST を使用（集計 API）：

GET /api/now/stats/sn_si_incident?sysparm_query=opened_atONLast 30 days@javascript:gs.daysAgoStart(30)@javascript:gs.daysAgoEnd(0)^assigned_toISNOTEMPTY&sysparm_count=true&sysparm_group_by=assigned_to

GET /api/now/stats/sn_si_incident?sysparm_query=opened_atONLast 30 days@javascript:gs.daysAgoStart(30)@javascript:gs.daysAgoEnd(0)&sysparm_count=true&sysparm_group_by=assignment_group

ステップ 6：インシデントカテゴリの傾向を追跡する

カテゴリの分布を比較し、攻撃の種類が時間の経過とともにどのように変化したかを特定します。

MCP を使用：

Tool: SN-Query-Table
Parameters:
  table_name: sn_si_incident
  query: opened_atONLast 90 days@javascript:gs.daysAgoStart(90)@javascript:gs.daysAgoEnd(0)
  fields: sys_id,category,subcategory,priority,opened_at
  limit: 2000

REST を使用：

# Current month
GET /api/now/stats/sn_si_incident?sysparm_query=opened_atONLast 30 days@javascript:gs.daysAgoStart(30)@javascript:gs.daysAgoEnd(0)&sysparm_count=true&sysparm_group_by=category

# Previous month
GET /api/now/stats/sn_si_incident?sysparm_query=opened_atBETWEENjavascript:gs.daysAgoStart(60)@javascript:gs.daysAgoEnd(30)&sysparm_count=true&sysparm_group_by=category

ステップ 7：タスク完了の効率を測定する

セキュリティインシデントのタスクがどれだけ速やかに完了するかを分析します。

MCP を使用：

Tool: SN-Query-Table
Parameters:
  table_name: sn_si_task
  query: closed_atONLast 30 days@javascript:gs.daysAgoStart(30)@javascript:gs.daysAgoEnd(0)
  fields: sys_id,number,short_description,state,priority,assigned_to,opened_at,closed_at,work_duration
  limit: 500

REST を使用：

GET /api/now/stats/sn_si_task?sysparm_query=closed_atONLast 30 days@javascript:gs.daysAgoStart(30)@javascript:gs.daysAgoEnd(0)&sysparm_avg_fields=work_duration&sysparm_count=true&sysparm_group_by=priority

ステップ 8：指標レポートをまとめる

包括的な指標の概要を作成します。

=== SECURITY OPERATIONS METRICS REPORT ===
Period: 2026-02-19 to 2026-03-19 (30 days)
Generated: 2026-03-19

VOLUME METRICS:
Total Incidents: 156 (prev period: 142, +9.8%)
  - Critical/P1: 4 (2.6%)
  - High/P2: 18 (11.5%)
  - Medium/P3: 67 (42.9%)
  - Low/P4: 67 (42.9%)

By Category:
  - Phishing: 52 (33.3%) ↑ from 28.2%
  - Malware: 28 (17.9%) ↓ from 22.5%
  - Unauthorized Access: 24 (15.4%) → stable
  - Data Loss: 12 (7.7%) → stable
  - Vulnerability Exploit: 18 (11.5%) ↑ from 8.5%
  - Other: 22 (14.1%)

RESPONSE METRICS:
Mean Time to Detect (MTTD): 4.2 hours (target: <2h, prev: 5.1h)
Mean Time to Respond (MTTR): 18.6 hours (target: <24h, prev: 22.3h)
Mean Time to Contain (MTTC): 2.8 hours (target: <4h, prev: 3.5h)

QUALITY METRICS:
False Positive Rate: 23.1% (target: <20%, prev: 25.6%)
Reopened Incidents: 3 (1.9%)
Escalation Rate: 14.1%

WORKLOAD DISTRIBUTION:
| Analyst | Incidents | Avg Resolution | Utilization |
|---------|-----------|----------------|-------------|
| T. Williams | 32 | 14.2h | 85% |
| K. Chen | 28 | 16.8h | 78% |
| A. Johnson | 31 | 19.1h | 82% |
| M. Davis | 25 | 21.5h | 70% |
| L. Park | 22 | 15.3h | 65% |
| Unassigned | 18 | N/A | - |

KEY OBSERVATIONS:
1. MTTD improved 18% but still above 2-hour target
2. Phishing volume increasing - consider enhanced email filtering
3. False positive rate improving but above 20% threshold
4. Workload imbalance: T. Williams carrying 20% of all incidents
5. 18 unassigned incidents need immediate attention

RECOMMENDATIONS:
1. Tune phishing detection rules to reduce false positives
2. Rebalance workload: redistribute from T. Williams to L. Park
3. Investigate MTTD gap: review SIEM alert correlation rules
4. Staff augmentation may be needed if volume trend continues

ツールの使用

ツール	目的
SN-Query-Table	指標算出用にインシデントおよびタスクのレコードを取得する
SN-Execute-Background-Script	複雑な指標算出のためにサーバーサイドスクリプトを実行する
SN-Add-Work-Notes	関連レコードに指標の分析結果を記録する

ベストプラクティス

• 目標を設定する前にベースラインを確立します。最低 90 日分の過去データを使用します
• P1 と P4 のインシデントでは許容される対応時間が大きく異なるため、優先度別に指標を分類します
• 単一期間のスナップショットに注目するのではなく、時間の経過に伴う傾向を追跡します
• 定期実行するバックグラウンドスクリプトまたは Performance Analytics の指標を使用して、データ収集を自動化します
• 平均値の算出時には外れ値を除外します。1 件のインシデントが 1 か月続くと、MTTR が大きく歪む可能性があります
• ソース別に誤検知率をレポートし、調整が必要な検知ルールを特定します
• MTTD／MTTR をビジネスへの影響時間と関連付け、指標をビジネス成果に結び付けます
• アナリストの燃え尽きを防ぎ、公平な割り当てを確保するため、毎月、作業負荷の分布を確認します

トラブルシューティング

MTTD の計算結果がゼロになる

原因： first_seen タイムスタンプを持つオブザーバブルがインシデントに関連付けられていないか、タイムスタンプがインシデントより前になっています。 解決策： 脅威インテリジェンスの統合機能によって、オブザーバブルに first_seen が設定されていることを確認してください。first_seen が opened_at より後の場合、MTTD が負の値になることがあります。その場合は、インシデントの opened_at を検知時刻として使用してください。

集計 API で想定外の件数が返される

原因： エンコードされたクエリが想定される日付範囲に一致していないか、表示値と保存値が異なっている可能性があります。 解決策： まず ServiceNow の UI リストフィルターでクエリをテストしてください。日付形式がインスタンスのタイムゾーンと一致していることを確認してください。

ワークロードのメトリクスですべてのインシデントが未割り当てと表示される

原因： インシデントが解決またはクローズされた際に、assigned_to フィールドがクリアされている可能性があります。 解決策： sys_audit を使用して、クローズ前に最後に割り当てられていたアナリストを確認してください。または、sysparm_display_value=true を指定して assigned_to フィールドをクエリし、表示名を取得してください。

パフォーマンスアナリティクスとメトリクスが異なる

原因： PA インジケーターでは、異なるデータ収集スケジュール、フィルター、または計算方法が使われている可能性があります。 解決策： クエリフィルターを PA インジケーターの定義に合わせてください。PA データ収集ジョブのスケジュールを確認し、最近実行されていることを確かめてください。

例

例 1：月次 SOC パフォーマンスレポート

1. 過去 30 日間のインシデント件数を算出します。全カテゴリ合計で 156 件です
2. MTTD（4.2 時間）、MTTR（18.6 時間）、MTTC（2.8 時間）を計算します
3. 誤検知率を算出します。全 156 件中 36 件が誤検知です（23.1%）
4. 5 人のアナリストのワークロードを分析し、偏りを特定します
5. すべてのメトリクスを前の期間および目標と比較します
6. 傾向を示す矢印と推奨事項を含むレポートを作成します

例 2：四半期ごとの経営層向けダッシュボード

1. グラフで傾向を示すため、過去 90 日間のインシデントデータを月別に取得します
2. 前月比の MTTD 改善を算出します：6.3 時間 → 5.1 時間 → 4.2 時間
3. 件数増加の主な要因となっている上位 3 カテゴリを特定します
4. MTTR を業界平均（中規模組織では 24 時間）と比較します
5. 件数の傾向（毎月 +9.8%）に基づいて必要な人員を予測します
6. 追加のアナリスト人員に必要な予算を推奨事項として示しながら、調査結果を提示します

関連スキル

• secops/correlation-insights - 相関の有効性を検知メトリクスとして測定します
• secops/incident-summarization - インシデントの要約にメトリクスのコンテキストを含めます
• secops/post-incident-analysis - PIR データを使用して検知メトリクスを改善します
• secops/shift-handover - 引き継ぎレポートにシフト単位のメトリクスを含めます
• reporting/trend-analysis - ServiceNow の一般的な傾向分析手法