Communitygithub.com

インシデント対応ダッシュボード構築

Splunk、Elastic、Grafanaなどでリアルタイムのインシデント対応ダッシュボードを構築します。

インシデント対応ダッシュボード構築 とは?

このスキルは、アクティブなインシデント対応中にリアルタイムで状況把握と調整を行うためのダッシュボードを設計・構築する方法を提供します。Splunk Dashboard Studio、Elastic Kibana、GrafanaなどのSIEMプラットフォームを対象としており、インシデントサマリー、影響を受けたシステムの追跡、IOC(侵害指標)の監視、対応タイムライン、SOC運用指標、経営層向けブリーフィング用のビューをステップバイステップで作成するワークフローを解説します。また、ダッシュボードデータを自動更新するためのスケジュール検索の設定方法や、アクティブランサムウェアインシデントやデータ漏洩調査など、一般的なシナリオに適用するためのベストプラクティスも含まれています。IRチーム、SOCリーダー、経営層が状況に応じた適切な情報にアクセスできるよう、多層的なダッシュボード設計が特徴です。

対応~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/mukul975/Anthropic-Cybersecurity-Skills/tree/main/skills/building-incident-response-dashboard

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

インシデント対応ダッシュボードの構築

使用するタイミング

このスキルは以下の場合に使用します:

  • IRチームがアクティブなインシデント中に、調整と追跡のためのリアルタイムダッシュボードを必要とする場合
  • SOCのリーダーシップがインシデントの状況やアナリストのワークロードを示す運用ダッシュボードを必要とする場合
  • インシデント後のレビューで、視覚的なタイムラインと影響評価が必要な場合
  • 経営層へのブリーフィングで、高レベルのインシデント指標と傾向分析が必要な場合

日常的なSOC監視ダッシュボードには使用しないでください(代わりにインシデントレビューを使用してください) — IRダッシュボードは、アクティブなインシデントの調整と管理レポートを目的として設計されています。

前提条件

  • SIEMプラットフォーム(Splunk Dashboard Studio、Elastic Kibana、Grafana)
  • SIEM内の注目イベントおよびインシデントデータ(Splunk ESのincident_review index)
  • チケットシステム統合(ServiceNow、Jira)による修復状況の追跡
  • コンテキスト強化のための資産およびIDルックアップテーブル
  • SOCチームおよび管理層へのダッシュボード公開アクセス権

ワークフロー

ステップ1:アクティブインシデントダッシュボードのレイアウト設計

アクティブなインシデント追跡用のSplunk Dashboard Studioダッシュボードを構築します:

<dashboard version="2" theme="dark">
  <label>Active Incident Response Dashboard</label>
  <description>Real-time tracking for IR-2024-0450</description>

  <row>
    <panel>
      <title>Incident Summary</title>
      <single>
        <search>
          <query>
| makeresults
| eval incident_id="IR-2024-0450",
       status="CONTAINMENT",
       severity="Critical",
       affected_hosts=7,
       contained_hosts=5,
       iocs_identified=23,
       hours_elapsed=round((now()-strptime("2024-03-15 14:00","%Y-%m-%d %H:%M"))/3600,1)
| table incident_id, status, severity, affected_hosts, contained_hosts, iocs_identified, hours_elapsed
          </query>
        </search>
      </single>
    </panel>
  </row>
</dashboard>

ステップ2:リアルタイム影響システムパネルの構築

影響を受けたシステムとその封じ込め状況を追跡します:

| inputlookup ir_affected_systems.csv
| eval status_color = case(
    status="Contained", "#2ecc71",
    status="Compromised", "#e74c3c",
    status="Investigating", "#f39c12",
    status="Recovered", "#3498db",
    1=1, "#95a5a6"
  )
| stats count by status
| eval order = case(status="Compromised", 1, status="Investigating", 2,
                    status="Contained", 3, status="Recovered", 4)
| sort order
| table status, count

--- 詳細ホストテーブル
| inputlookup ir_affected_systems.csv
| lookup asset_lookup_by_cidr ip AS host_ip OUTPUT category, owner, priority
| table hostname, host_ip, category, owner, status, containment_time,
        compromise_vector, analyst_assigned
| sort status, hostname

ステップ3:IOC追跡パネルの構築

環境全体でのIOCの拡散を監視します:

--- インシデント中に特定されたIOC
index=* (src_ip IN ("185.234.218.50", "45.77.123.45") OR
         dest IN ("evil-c2.com", "malware-drop.com") OR
         file_hash IN ("a1b2c3d4...", "e5f6a7b8..."))
earliest="2024-03-14"
| stats count AS hits, dc(src_ip) AS unique_sources,
        dc(dest) AS unique_dests, latest(_time) AS last_seen
  by sourcetype
| sort - hits

--- IOCタイムライン
index=* (src_ip IN ("185.234.218.50") OR dest="evil-c2.com")
earliest="2024-03-14"
| timechart span=1h count by sourcetype

--- 新規IOC発見の追跡
| inputlookup ir_ioc_list.csv
| stats count by ioc_type, source, discovery_time
| sort discovery_time
| table discovery_time, ioc_type, ioc_value, source, status

ステップ4:対応タイムラインパネルの構築

時系列のインシデントタイムラインを作成します:

| inputlookup ir_timeline.csv
| sort _time
| eval phase = case(
    action_type="detection", "Detection",
    action_type="triage", "Triage",
    action_type="containment", "Containment",
    action_type="eradication", "Eradication",
    action_type="recovery", "Recovery",
    1=1, "Other"
  )
| eval phase_color = case(
    phase="Detection", "#e74c3c",
    phase="Triage", "#f39c12",
    phase="Containment", "#e67e22",
    phase="Eradication", "#2ecc71",
    phase="Recovery", "#3498db"
  )
| table _time, phase, action, analyst, details

タイムラインデータの例:

_time,action_type,action,analyst,details
2024-03-15 14:00,detection,Alert triggered - Cobalt Strike beacon detected,splunk_es,Notable event NE-2024-08921
2024-03-15 14:12,triage,Alert triaged - confirmed true positive,analyst_jdoe,VT score 52/72 on beacon hash
2024-03-15 14:23,containment,Host WORKSTATION-042 isolated,analyst_jdoe,CrowdStrike network isolation
2024-03-15 14:35,containment,C2 domain blocked on firewall,analyst_msmith,Palo Alto rule deployed
2024-03-15 15:00,eradication,Enterprise-wide IOC scan initiated,analyst_jdoe,Splunk search across all indices
2024-03-15 15:30,containment,3 additional hosts identified and isolated,analyst_msmith,Lateral movement confirmed
2024-03-15 16:00,eradication,Malware removed from all affected hosts,analyst_tier3,CrowdStrike RTR cleanup
2024-03-15 18:00,recovery,Systems restored and monitored,analyst_msmith,72-hour monitoring period started

ステップ5:SOC運用ダッシュボードの構築

SOC全体のパフォーマンス指標を追跡します:

--- 重要度別インシデント数(過去30日間)
index=notable earliest=-30d
| stats count by urgency
| eval order = case(urgency="critical", 1, urgency="high", 2, urgency="medium", 3,
                    urgency="low", 4, urgency="informational", 5)
| sort order

--- MTTD(平均検出時間)
index=notable earliest=-30d status_label="Resolved*"
| eval mttd_minutes = round((time_of_first_event - orig_time) / 60, 1)
| stats avg(mttd_minutes) AS avg_mttd, median(mttd_minutes) AS med_mttd,
        perc95(mttd_minutes) AS p95_mttd

--- MTTR(平均対応・解決時間)
index=notable earliest=-30d status_label="Resolved*"
| eval mttr_hours = round((status_end - _time) / 3600, 1)
| stats avg(mttr_hours) AS avg_mttr, median(mttr_hours) AS med_mttr by urgency

--- アナリストのワークロード分布
index=notable earliest=-7d
| stats count by owner
| sort - count

--- アラート処分分類
index=notable earliest=-30d status_label IN ("Resolved*", "Closed*")
| stats count by disposition
| eval percentage = round(count / sum(count) * 100, 1)
| sort - count

ステップ6:経営層向けブリーフィングダッシュボードの構築

重大インシデント時にリーダーシップ向けの高レベルダッシュボードを作成します:

--- 経営サマリーパネル
| makeresults
| eval metrics = "Business Impact: 1 file server offline (Finance dept), "
                ."Estimated Recovery: 4 hours, "
                ."Data Loss Risk: Low (backups verified), "
                ."Customer Impact: None, "
                ."Regulatory Notification: Not required (no PII exposure confirmed)"

--- 傾向比較(今月 vs 先月)
index=notable earliest=-60d
| eval period = if(_time > relative_time(now(), "-30d"), "Current Month", "Previous Month")
| stats count by period, urgency
| chart sum(count) AS incidents by period, urgency

--- 上位脅威カテゴリ
index=notable earliest=-30d
| top rule_name limit=10
| table rule_name, count, percent

ステップ7:ダッシュボード更新の自動化

Splunkのスケジュール検索を使用してダッシュボードデータを維持します:

--- 影響システムルックアップを更新するスケジュール検索(5分ごとに実行)
index=* (src_ip IN [| inputlookup ir_ioc_list.csv | search ioc_type="ip"
                    | fields ioc_value | rename ioc_value AS src_ip])
earliest=-1h
| stats latest(_time) AS last_seen, count AS event_count,
        values(sourcetype) AS data_sources by src_ip
| eval status = if(last_seen > relative_time(now(), "-15m"), "Active", "Dormant")
| outputlookup ir_affected_systems_auto.csv

主要概念

用語定義
状況認識インシデントの範囲、影響を受けるシステム、対応の進捗状況をリアルタイムで把握すること
MTTD平均検出時間 — 脅威の発生からSOCアラート生成までの平均時間
MTTR平均対応時間 — アラートからインシデント解決または封じ込めまでの平均時間
封じ込め率封じ込めに成功した影響システムの、侵害された全システムに対する割合
バーンダウンチャートインシデント中、残りの調査タスクの進捗を経時的に視覚化したもの
経営層向けブリーフィングビジネスへの影響、タイムライン、復旧状況を示す非技術的なサマリーダッシュボード

ツールとシステム

  • Splunk Dashboard Studio: ドラッグ&ドロップの可視化とリアルタイムデータを備えた最新のダッシュボードフレームワーク
  • Elastic Kibana Dashboard: Lens、Maps、Canvasを使用したセキュリティダッシュボード用の可視化プラットフォーム
  • Grafana: ElasticsearchやSplunkを含む複数のデータソースをサポートするオープンソースの可視化プラットフォーム
  • Microsoft Sentinel Workbooks: Kustoベースの分析可視化を備えたAzureネイティブのダッシュボードフレームワーク
  • TheHive: ケース追跡と指標ダッシュボードを内蔵したオープンソースのインシデント対応プラットフォーム

一般的なシナリオ

  • アクティブランサムウェアインシデント: 暗号化の広がり、封じ込め状況、バックアップ検証、復旧進捗を示すダッシュボード
  • データ漏洩調査: 影響を受けたデータストア、流出量、通知要件を追跡するダッシュボード
  • フィッシングキャンペーン対応: 受信者数、クリック率、認証情報漏洩、修復状況を示すダッシュボード
  • 月次SOCレポート: インシデント傾向、MTTD/MTTR指標、アナリストパフォーマンスを示すリーダーシップダッシュボード
  • コンプライアンス監査: 検出カバレッジ、応答SLA順守、インシデントクローズ指標を示すダッシュボード

出力形式

INCIDENT RESPONSE DASHBOARD — IR-2024-0450
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

STATUS: CONTAINMENT PHASE (6h 30m elapsed)

Affected Systems:          Containment Progress:
  Compromised:   2         [==========----------] 71%
  Investigating: 1         5 of 7 systems contained
  Contained:     3
  Recovered:     1

IOC Summary:               Response Timeline:
  IPs:      4              14:00 — Alert triggered
  Domains:  2              14:12 — Confirmed malicious
  Hashes:   3              14:23 — First host isolated
  URLs:     5              15:00 — Enterprise scan started
  Emails:   1              15:30 — 3 more hosts isolated

Key Metrics:
  MTTD:    12 minutes
  MTTC:    23 minutes (first host)
  Analysts Active: 3 (Tier 2: 2, Tier 3: 1)

Business Impact: LOW — Finance file server offline, no customer-facing systems affected

Individual skills in this repo

This repo contains 20 individual skills — each has its own dedicated page.

abusing-dpapi-for-credential-access

Extract and decrypt Windows DPAPI-protected secrets (Credential Manager, browser logins/cookies, Wi-Fi credentials, KeePass keys) online or offline using SharpDPAPI, SharpChrome, Mimikatz, or Impacket

abusing-shadow-credentials-for-privesc

Take over Active Directory accounts by writing attacker-controlled public keys to msDS-KeyCredentialLink (Shadow Credentials) with pyWhisker, Whisker, or Certipy, then authenticate via PKINIT to recover the target

achieving-cmmc-level-2-compliance

>-

acquiring-disk-image-with-dd-and-dcfldd

Create forensically sound bit-for-bit disk images with dd or dcfldd on a Linux forensic workstation, preserving evidence integrity through hash verification (MD5/SHA) during acquisition. Use when imaging a suspect drive, USB device, or memory card for investigation, preserving volatile disk evidence during incident response, or producing a verified copy for legal or law-enforcement proceedings before any destructive analysis.

analyzing-active-directory-acl-abuse

Detect dangerous ACL misconfigurations in Active Directory using ldap3

analyzing-android-malware-with-apktool

Perform static analysis of Android APK malware using apktool for resource decompilation, jadx for Java source recovery, and androguard for manifest inspection, dangerous permission-combination detection, and identification of obfuscated code, dynamic code loading, and reflection-based API calls. Use to statically triage a suspicious APK without executing it or to build mobile malware detection rules.

analyzing-api-gateway-access-logs

Parses API Gateway access logs (AWS API Gateway, Kong, Nginx) to detect

analyzing-apt-group-with-mitre-navigator

Query ATT&CK data with attackcti, mitreattack-python, and stix2, then build MITRE ATT&CK Navigator layers and multi-layer heatmap overlays mapping one or more APT groups

analyzing-azure-activity-logs-for-threats

Queries Azure Monitor activity logs and sign-in logs via azure-monitor-query

analyzing-bootkit-and-rootkit-samples

Analyzes bootkit and advanced rootkit malware infecting the Master

analyzing-browser-forensics-with-hindsight

Parse Chromium-based browser databases with Hindsight to extract and correlate browsing history, downloads, cookies, cached content, autofill data, saved passwords, and extensions from Chrome, Edge, Brave, Opera, and Vivaldi into a unified timeline (XLSX, JSON, or SQLite output). Use during incident response, insider-threat investigations, or criminal cases when you need to reconstruct a user

analyzing-campaign-attribution-evidence

Systematically evaluate cyber-campaign evidence to attribute an operation to a threat actor, using the Diamond Model and Analysis of Competing Hypotheses (ACH) to weigh infrastructure overlaps, TTP consistency, malware code similarity, and timing/language artifacts into confidence-weighted attribution assessments. Use when an incident investigation needs a defensible attribution confidence level.

analyzing-certificate-transparency-for-phishing

Monitor Certificate Transparency logs using crt.sh and Certstream to

analyzing-cloud-storage-access-patterns

Detect abnormal access in AWS S3, GCS, and Azure Blob Storage by analyzing CloudTrail Data Events, GCS audit logs, and Azure Storage Analytics for after-hours bulk downloads, new-IP access, and API-call spikes (e.g. GetObject) via statistical baselines and time-series anomaly detection. Use when investigating suspected cloud data exfiltration or building related detection rules.

analyzing-cobalt-strike-beacon-configuration

Extract and analyze Cobalt Strike beacon configuration from PE files

analyzing-cobaltstrike-malleable-c2-profiles

Parse and analyze Cobalt Strike Malleable C2 profiles with dissect.cobaltstrike (profiles and beacon-payload configs) and pyMalleableC2 (AST parsing) to extract HTTP/DNS transforms, URIs, headers, sleep/jitter, and injection behavior, then generate network detection signatures. Use when reverse-engineering a captured malleable profile or building detections against Cobalt Strike Beacon traffic.

analyzing-command-and-control-communication

Analyzes malware C2 communication over HTTP, HTTPS, DNS, and custom

analyzing-cyber-kill-chain

Analyzes intrusion activity against the Lockheed Martin Cyber Kill Chain

analyzing-disk-image-with-autopsy

Perform comprehensive forensic analysis of raw (dd), E01, or AFF disk images with Autopsy and The Sleuth Kit, recovering deleted files, examining metadata and embedded artifacts, keyword searching, and building investigation timelines with visual reports. Use for structured analysis of a forensic disk image or when stakeholders need visual reports from evidence.

analyzing-dns-logs-for-exfiltration

Analyzes DNS query logs to detect data exfiltration via DNS tunneling,

関連スキル