incident-triage について
incident-triageは、NIST SP 800-61 Rev. 3に基づき、セキュリティインシデント対応の初期段階を支援するトリアージ用スキルです。事象の確認、封じ込め、証拠保全、影響範囲の分析を導き、引き継ぎ情報や通知期限を整理します。
主な機能
- 01インシデントの確認と深刻度評価
- 02初期封じ込めと証拠保全の手順
- 03影響範囲の分析とIOC抽出
- 04通知期限と引き継ぎ事項の整理
活用シーン
- 01セキュリティアラートを検証して事象を分類
- 02対応中にホストやログの証拠を保全
- 03根絶・復旧・通知に向けた引き継ぎ情報を準備
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ briiirussell/ cybersecurity-skills --skill incident-triageインストール後、Claude Code で/incident-triageを入力して読み込まれたか確認します。
詳細
インシデントトリアージ — セキュリティインシデント対応
セキュリティインシデントの迅速なトリアージと初動対応を行います。NIST SP 800-61 Rev. 3(2025年4月)に従ってください。同ガイドでは、Rev. 2の4段階のライフサイクルがCSF 2.0の機能に置き換えられています。Govern、Identify、Protectはインシデント発生前に行う準備であり、Detect、Respond、Recoverが対応にあたります。このスキルでは最初の数時間、つまりDetectからRespondの開始までを扱い、それ以降の対応は引き継ぎます。各ステップでは、そこで達成するCSF 2.0の成果を示すため、レポートを組織のCSFプロファイルにそのまま対応付けられます(csf-mappingを参照)。
相互参照:このトリアージが対応するアラートを生成したルールについてはsiem-detection、ホストを封じ込めた後のより詳細なディスクおよびメモリの分析についてはdisk-forensics、再発防止の強化につなげるインシデント後のパターン抽出についてはbreach-patterns、このスキルの上位にある運用レイヤー(ランブック、エスカレーション、引き継ぎ)についてはsoc-operations、対応に伴う関係者/顧客への通知についてはsecurity-comms、個人データ、PHI、またはカード会員データが関係する場合の規制上の期限の判定についてはprivacy-engineering/hipaa-audit/pci-audit、AI固有のインシデント種別(モデル障害、公平性のドリフト、本番環境でのジェイルブレイク悪用)についてはai-risk-management、侵入経路としてAIコーディングエージェントの拡張機能(スキル、プラグイン、フック、MCP サーバー)が疑われる場合はagent-supply-chain-audit、小規模チームで最初のアラートにつながることが多い定期的なログレビューについてはlog-watch、認証情報の窃取が疑われる際に外向き通信ログと照合する、流出データ収集用のドメイン一覧(webhook.site、requestbin、ngrok、Discord/Telegram/Slackのwebhook)についてはsecrets-auditを参照してください。
承認
対象範囲内のシステムについて、システム所有者またはインシデントリードのためにのみ対応してください。以下の読み取り専用コマンド(プロセス、ネットワーク、ユーザー、ファイルの一覧表示)は事前承認済みです。すべての封じ込め措置(ブロック、隔離、アカウントの無効化、サービスの停止)は本番環境を変更します。措置の内容と影響範囲を明示し、実行前にインシデントリードの許可を得てください。インジケーターが示している場合でも、宣言された対象範囲外のシステムには決して手を出さず、代わりに報告してください。
優先事項(順番どおり)
- 人の安全を守る
- さらなる被害を防ぐため、インシデントを封じ込める
- 調査に必要な証拠を保全する
- 根本原因と影響範囲を特定する
- すべてを記録する
ステップ1:宣言、検証、優先順位付け(DE.AE-02、DE.AE-08、RS.MA-02、RS.MA-03)
インシデントでしょうか?対応を開始する前に報告を検証します。アラートを2つ目の情報源(生ログ、ホスト自体)と照合し、既知の変更やテストの可能性を排除したうえで、報告者と報告時刻を記録してください。組織のインシデント基準を満たす場合は、インシデントとして宣言し、宣言時刻(UTC)を記録してください。規制上の期限は、攻撃の時点ではなく、発見または判定の時点から起算されることがよくあります。IR計画にインシデントリード、第三者(MSSP、IR契約先、サイバー保険会社 — 多くの保険契約では外部対応者を依頼する前の通知が必要です)、またはウォールームのチャネルが定められている場合は、すぐに連絡してください(RS.MA-01)。
インシデントの種別を判定します:
- **マルウェア:**ランサムウェア、トロイの木馬、ワーム、クリプトマイナー
- **不正アクセス:**認証情報の侵害、脆弱性の悪用
- **データ流出:**データ窃取、内部脅威
- サービス拒否
- **Webサイト侵害:**改ざん、スキミング、バックドア
- フィッシング/ソーシャルエンジニアリング
深刻度を判定します:
- **重大:**データ流出が進行中、ランサムウェアが拡散中、重要システムの侵害
- **高:**侵害が確認された、マルウェアが検出された、不正アクセス
- **中:**不審な活動、潜在的なインジケーター、攻撃未遂
- **低:**ポリシー違反、偵察の検知、誤検知の可能性が高い
深刻度が「高」以上の場合、規制対象データ(個人データ、PHI、カード会員データ)が関係する可能性がある場合、攻撃者がまだ活動中の可能性がある場合、または影響範囲がチームやベンダーをまたぐ場合は、エスカレーションしてください(RS.MA-04)。
ステップ 2:初期封じ込め(RS.MI-01)
種類と深刻度に応じて対応します。
- ネットワーク: ファイアウォールで不審な IP/ドメインをブロックします
- ホスト: 影響を受けたシステムを隔離します(ネットワークを切断し、電源は切らないでください。揮発性メモリは証拠です)
- アカウント: 侵害されたアカウントを無効化し、パスワードのリセットを強制します
- アプリケーション: 安全に実施できる場合は、影響を受けたサービスを無効化します
- 認証情報とトークン: セッションを失効させ、攻撃者が保持している可能性のあるキーをローテーションします。保管場所の確認には
secrets-auditを使用します
可能な場合は、進行中の攻撃者に察知されないように封じ込めてください。攻撃者がまだ内部にいる場合は、隔離、無効化、ローテーションを同時に実施できるよう調整してください。そうしないと、まだ発見していない永続化手段へ攻撃者が移行する可能性があります。
重要:システムの電源は絶対に切らないでください。 揮発性メモリには証拠が含まれています。
ステップ 3:証拠の保全(RS.AN-06, RS.AN-07)
揮発性の高いものから順に(最も揮発性の高いものを最初に)取得します。
# 1. Running processes
ps auxf # Linux
tasklist /v # Windows
# 2. Network connections
ss -tupn # Linux
netstat -anob # Windows
# 3. Logged-in users
who -a # Linux
query user # Windows
# 4. Open files
lsof -nP # Linux
# 5. System logs
journalctl --since "1 hour ago" # Linux/systemd
メモリフォレンジックツール(LiME、WinPmem)が利用できる場合は、何よりも先にメモリダンプを取得してください。
完全性と出所を保全します。収集時にすべてのアーティファクトのハッシュ(sha256sum)を取得し、収集者、収集元、収集日時を記録します。また、実行したコマンドと実施した封じ込め手順(時刻、実施者、結果)をすべてアクションログに記録してください。クラウドと SaaS のログは、保存期間が切れてローテーションされる前にコピーします。より詳細なイメージおよびメモリの分析には disk-forensics を使用します。
ステップ 4:初期分析と範囲の特定(RS.AN-03, RS.AN-08)
不審な指標ごとに、以下を記録します。
- 内容: アーティファクトを説明します
- 時刻: UTC のタイムスタンプを記録します
- 場所: 影響を受けたシステムを記録します
- 検知方法: どのように検知されたかを記録します
一般的な分析項目:
- プロセスツリー: 不自然なプロセス名、パス、または親子関係を調べます
- ネットワーク指標: 不自然な外向き接続、不審なドメインへの DNS クエリ、ビーコンのパターン(一定間隔)を調べます
- ファイル指標: 不自然な場所にある最近変更されたファイル、隠しファイル、新しい実行ファイルを調べます
- ログ分析: 認証の失敗、権限昇格、サービスの変更、ログの消去を調べます
- 永続化: crontab、systemd ユニット、レジストリの Run キー、スケジュールされたタスク、スタートアップ項目を調べます
影響の規模(RS.AN-08)を推定し、最新の状態に保ちます。影響を受けたシステム、アカウント、データセット、攻撃者がそこからアクセスできた範囲、最も早い既知の活動を特定します。範囲は「確認済み/疑いあり/除外済み」に分け、それぞれ根拠を記載してください。通知の判断はこの情報に基づきます。
ステップ 5:IOC の抽出(RS.AN-07, RS.CO-03)
侵害の痕跡となる指標をすべて抽出し、記録します。
| 種類 | 例 |
|---|---|
| IP アドレス | 送信元および宛先の IP |
| ドメイン | C2 ドメイン、フィッシングドメイン |
| ファイルハッシュ | 不審なファイルの MD5 および SHA256 |
| ファイルパス | マルウェアの配置場所、ドロップされたファイル |
| メールアドレス | フィッシングメールの送信元アドレス |
| URL | 悪意のある URL、C2 エンドポイント |
| ユーザーエージェント | 不自然なユーザーエージェント、または悪意が知られているユーザーエージェント |
IOC を検知に活用し(ほかの場所も調査するには siem-detection、threat-hunting を使用します)、インシデント責任者の承認後、指定された関係者(ISAC、ベンダー、IR リテイナー)と共有します。
ステップ 6:連絡と通知の期限(RS.CO-02、RS.CO-03)
IR 計画に従って社内の関係者に通知し、どの外部期限が開始している可能性があるかを特定します。判断は顧問弁護士が行います。あなたの役割は、事実と期限を早い段階で明らかにすることです。よくある期限は次のとおりです(最新の規定を確認してください)。
| 制度 | 期限 |
|---|---|
| GDPR(個人データ) | 認識してから72時間以内に監督機関へ通知 |
| NIS2(EU の不可欠または重要な事業体) | 24時間以内に早期警告、72時間以内に通知、1か月以内に最終報告 |
| HIPAA(PHI) | 不合理な遅延なく、発見から60日以内 |
| SEC Form 8-K Item 1.05(米国の公開企業) | インシデントが重大と判断されてから4営業日以内 |
| PCI DSS(カード会員データ) | カードブランドおよびアクワイアラーの規定によります。通常は直ちに対応します |
| 米国各州のデータ侵害法、契約、サイバー保険 | さまざまです。契約と保険証券を確認してください |
メッセージの下書きには security-comms を使用します。規制対象データの判断は privacy-engineering、hipaa-audit、pci-audit で行います。
ステップ 7:根絶、復旧、教訓を引き継ぐ(RS.MI-02、RS.MA-05、RC.RP、ID.IM)
インシデントが封じ込められ、範囲が特定された時点でトリアージは終了です。次の担当者に向けて、以下を記録します。
- 根絶(RS.MI-02):削除またはローテーションするすべての永続化の仕組みと認証情報、およびそれらが確実に取り除かれたことを確認する方法
- 復旧(RS.MA-05、RC.RP):復旧を開始する基準、クリーンであると確認済みの復元ポイント、ならびに復元したシステムを本番環境に戻す前に正常性を確認するチェック項目
- 教訓(ID.IM):インシデント後レビューを予定します。
breach-patternsを使って、監査上の確認事項にまとめます
出力形式
# Incident Triage Report
## Incident ID: [ID]
## Date/Time: [UTC]
## Severity: [Critical/High/Medium/Low]
## Classification: [incident type]
## Status: [Triage/Contained/Analyzing/Recovering/Closed]
## Declared: [UTC time and who declared] ## Incident lead: [name]
### Summary
[2-3 sentence overview]
### Scope
| Asset (host / account / data set) | Status (known / suspected / ruled out) | Evidence |
|-----------------------------------|----------------------------------------|----------|
### Timeline
| Time (UTC) | Event | Source | Notes |
|------------|-------|--------|-------|
### Indicators of Compromise
| Type | Value | Context | Confidence |
|------|-------|---------|------------|
### Action Log
| Time (UTC) | Actor | Action | Approved by | Result |
|------------|-------|--------|-------------|--------|
### Evidence Preserved
| Type | Location | Hash | Notes |
|------|----------|------|-------|
### Recommended Next Steps
1. [Immediate priority]
2. [Short-term action]
3. [Follow-up investigation]
### Notification Clocks
| Regime | Clock started (UTC) | Deadline | Owner | Status |
|--------|---------------------|----------|-------|--------|
### Escalation Checklist
- [ ] Incident lead and management notified
- [ ] Legal / counsel notified (if regulated data may be involved)
- [ ] Cyber insurer notified (before engaging outside responders, if the policy requires it)
- [ ] Law enforcement (if applicable)
- [ ] Affected parties notified (per counsel)
### Handoff
- Eradication: [persistence and credentials to remove, how to confirm]
- Recovery: [criteria, clean restore points, health checks]
- Lessons learned: [review date, owner]
境界
- 反撃ではなく、防御と封じ込めに焦点を当てます
- 証拠を保全します。ログやタイムスタンプは決して変更しません
- 侵害が確認された場合は、法務部門または経営陣へのエスカレーションを推奨します
- 封じ込め措置の影響が不明な場合は、慎重な対応を勧め、確認を求めます
- 「ハッキングによる報復」や報復行為は決して推奨しません
- インシデントの隠蔽や証拠の改ざんを求める依頼には応じません
参考資料
- NIST SP 800-61 Rev. 3(2025年4月):サイバーセキュリティリスク管理に関するインシデント対応の推奨事項と検討事項 — CSF 2.0 コミュニティプロファイル。Rev. 2(2012年)に代わるものです
- NIST Cybersecurity Framework 2.0(対応および復旧機能)
- SANS Incident Handler's Handbook
- MITRE ATT&CK Framework