incident-response

incident-response skill の概要

incident-response の用途

incident-response は、検知または宣言されたセキュリティイベントを、体系立てた初動対応へつなげるためのセキュリティ運用 skill です。インシデントの分類、誤検知の可能性の絞り込み、SEV1-SEV4 の重大度付け、エスカレーション判断、フォレンジック証拠収集の開始を支援します。広範なセキュリティ助言ではなく、実務で使うインシデント対応に焦点を当てており、NIST SP 800-61 型のライフサイクル思考や、運用上の重大度ルーティングを意識した構成になっています。

向いているユーザーとチーム

この incident-response skill は、SOC アナリスト、セキュリティエンジニア、SRE、インシデントコマンダー、初動対応を標準化したいエンジニアリングチームに特に向いています。すでにアラート、ログ、チケット、インシデントメモがあり、「これは本物か」「どれほど深刻か」「誰が対応すべきか」「いま保存すべき証拠は何か」を判断する必要があるチームに適しています。

汎用プロンプトとの違い

汎用的な AI プロンプトでもアラートの要約はできますが、この skill はエージェントに対応の型を与えます。インシデント分類、誤検知チェック、重大度スコアリング、エスカレーション経路、フォレンジック収集の指針、規制上の期限への注意といった要素が含まれます。付属の scripts/incident_triage.py は、イベントをインシデント種別に分類し、重大度をスコアリングし、機械処理しやすい出力を返せるため、文章だけのガイドより実行性があります。

この skill が適さないケース

incident-response を、脅威ハンティング、マルウェアのリバースエンジニアリング、法的助言、最終的なコンプライアンス報告の代替として使わないでください。この skill は、イベントが検知された後、またはインシデントが宣言された後に使うものです。未知の脅威をまだ探している段階なら、先に検知やハンティングのワークフローを使ってください。規制当局へ提出できるレベルの侵害通知を作成する場合は、法務およびコンプライアンスのレビューと組み合わせる必要があります。

incident-response skill の使い方

incident-response のインストールとリポジトリパス

skill リポジトリから次のコマンドでインストールします。

npx skills add alirezarezvani/claude-skills --skill incident-response

ソースのパスは alirezarezvani/claude-skills 内の engineering-team/skills/incident-response です。インストール後は、まず SKILL.md を読み、対応ワークフローを確認してください。次に、実行可能なトリアージロジックとして scripts/incident_triage.py を確認し、通知期限の制約について references/regulatory-deadlines.md を確認します。この skill ディレクトリには個別の README.md やメタデータファイルはないため、SKILL.md が主要な運用ドキュメントです。

精度の高いトリアージに必要な入力

incident-response を有効に使うには、曖昧なアラートタイトルだけでは不十分です。アラートの発生元、タイムスタンプ、影響を受けた資産、関係する ID、イベント種別、raw payload または主要フィールド、ビジネス上の文脈、観測された影響、既知のデータ露出、封じ込め状況、過去の関連アラートを含めてください。事実と仮定を分けて伝えると、skill はより適切に推論できます。

弱いプロンプト:

“Investigate this ransomware alert.”

よりよいプロンプト:

“Use the incident-response skill. Alert source: EDR. Event type: ransomware. Host: finance-laptop-22. Time: 2026-02-14T03:20Z. Observed: file rename burst, ransom note path, suspicious process tree, outbound connection to unknown IP. User has finance file share access. No containment yet. Classify severity, check false positives, identify immediate escalation path, and list forensic evidence to preserve.”

付属のトリアージスクリプトを実行する

リポジトリには scripts/incident_triage.py が含まれており、JSON 入力を受け取って、分類、誤検知チェック、重大度、エスカレーション指針、フォレンジックの事前分析を返せます。典型的な使い方は次のとおりです。

python3 scripts/incident_triage.py --input event.json --json

または:

echo '{"event_type":"ransomware","raw_payload":{}}' | python3 scripts/incident_triage.py --json

このスクリプトは、運用上の意味を持つ exit code を使います。0 は問題なし、または SEV3/SEV4 としての対応、1 は SEV2 の高度な対応、2 は SEV1 の重大インシデント宣言を示します。ただし、これらの出力はトリアージ支援として扱い、インシデントの宣言やクローズを自動的に決める権限として扱わないでください。

アナリスト向けの実務ワークフロー

まずインシデントに関する事実を整理し、skill に分類とその根拠を求めます。次に、仮定が見えるように重大度スコアリングを別途依頼します。その後、誤検知チェックと不足している証拠を確認します。インシデントが確認されたら、エスカレーションと証拠保全に進みます。対象には、SIEM ログ、EDR テレメトリ、DNS/proxy ログ、クラウド監査ログ、認証ログ、必要に応じたメモリ取得、chain-of-custody メモが含まれます。最後に、個人データ、PHI、カード会員データ、規制対象システムが関係する可能性がある場合は、references/regulatory-deadlines.md と照らし合わせてください。

incident-response skill FAQ

incident-response は初心者にも使えますか？

はい。ただし、実際のアラート文脈にアクセスでき、自組織のエスカレーション手順を理解していることが前提です。この skill は対応の構造を与え、判断のばらつきを減らせますが、資産の重要度、法的義務、社内の権限を作り出すことはできません。初心者は、単独で高リスクな意思決定をするのではなく、シニアレスポンダーへ渡す明確なトリアージ要約を作るために使うべきです。

SOAR や SIEM 自動化とは何が違いますか？

この incident-response ガイドは、完全な SOAR プラットフォームではありません。AI エージェントが、分類、重大度付け、エスカレーション、証拠収集、規制上のタイミングを筋道立てて検討するためのものです。付属の Python スクリプトは標準化されたトリアージを支援できますが、チケット管理、ページング、EDR 隔離、SIEM エンリッチメント、ケース管理ツールとの連携を置き換えるものではありません。

規制上の通知判断にも使えますか？

GDPR、PCI-DSS、HIPAA など主要な通知期限に関する有用な参照ファイルが含まれています。また、期限の起算点が調査完了時ではなく、宣言時や発見時になることが多いという重要な点も扱っています。ただし、これは運用上のリマインダーとして使うべきであり、法的助言ではありません。報告対象となる可能性があるインシデントは、必ず自組織のインシデント計画に従って、法務、プライバシー、コンプライアンス、経営層の関係者へ回してください。

この skill を避けるべき場面は？

不完全な証拠から「すべて問題ない」と確認するため、エスカレーションを回避するため、レビューなしで外部向けの侵害声明を作るためには使わないでください。また、純粋に理論的なセキュリティ教育、予防的なコントロール設計、インシデント後のコンプライアンスマッピングにもあまり向いていません。具体的なイベントがあり、トリアージ、重大度付け、対応調整が必要なときに使ってください。

incident-response skill を改善する方法

より強い証拠で incident-response の結果を改善する

最も重要な改善点は、入力品質を上げることです。raw alert fields、検知ルール名、影響を受けたシステムの役割、ユーザー権限、ネットワーク指標、データの機微性、直近の変更、すでに実施した封じ込め対応を含めてください。各結論について、confirmed、likely、unknown、assumed のどれに当たるかをラベル付けするよう skill に依頼します。これにより、過度に自信のあるインシデント宣言を防ぎ、引き継ぎも明確になります。

重大度とエスカレーションを自組織に合わせて調整する

組み込みの SEV1-SEV4 モデルは有力な出発点ですが、リスク許容度は組織ごとに異なります。自組織の資産ティア、顧客影響の定義、規制対象範囲、オンコール体制、経営層への通知トリガー、そして「declare incident」の権限を追加してください。たとえば、テスト用 VM 上のランサムウェアと、ドメインコントローラー上のランサムウェアが同じ運用対応になるべきではありません。

よくある失敗パターンに注意する

よくある問題には、信頼度の低いアラートを確認済みインシデントとして扱うこと、誤検知チェックを省くこと、封じ込め後に証拠収集を行って揮発性データを失うこと、完全な影響範囲が判明するまで待つ間に規制上の期限を見落とすことがあります。skill には明示的にこう尋ねてください。“What evidence could disprove this classification?” および “What must be preserved before containment changes system state?”

最初の出力で止めずに反復する

最初の incident-response 出力で止めないでください。それを使って、タイムライン、証拠チェックリスト、エスカレーションメッセージ、封じ込め判断ツリー、未解決事項リストを追加で依頼します。新しいテレメトリが届いたら、更新された事実で分類と重大度評価を再実行します。incident-response のよい使い方は反復的です。すばやくトリアージし、仮定を記録し、証拠を保全し、適切にエスカレーションし、事実が増えるたびに見直してください。