プレイブック設計

プレイブックとは、コード化された対応ワークフローです。トリガーされるとSOARプラットフォームが実行する、順序付けられた分岐可能な手順の集合です。かつてWikiに置かれていたランブックを、実行可能な形にしたものです。

ランブックにIPのレピュテーションを調べると書かれている場合、プレイブックは実際にレピュテーションAPIを呼び出し、結果を解析し、スコアに応じて分岐します。プレイブックを適切に設計することは、SOCにおける自動化エンジニアリングの中核スキルです。

抽象的な状態でプレイブックを設計してはいけません。まず、アナリストが現在そのアラートを実際にどのように処理しているかを、意思決定の内容や確認するデータも含めて、手順ごとに文書化します。

各手順を、次の3つのカテゴリのいずれかに分類します。

• 決定論的なアクション — 同じ入力から常に同じ出力が得られます（安全に自動化できます）。
• 情報補強 —副作用を伴わずにデータを収集します（安全に自動化できます）。
• 判断 — 文脈または説明責任を必要とします（人間を関与させたままにします）。

すべてのプレイブックには、正確なトリガーが必要です。広すぎるとノイズで起動し、狭すぎると実際のケースを見逃します。

トリガーは通常、SIEMの相関ルール、EDRの検知カテゴリ、またはメールゲートウェイの判定に紐付けます。開始条件を明確に定義します。

プレイブックはアーティファクトを処理します。アーティファクトとは、トリガーとなったイベントから抽出される指標であり、IPアドレス、ファイルハッシュ、ユーザーアカウント、URL、ホスト名などです。

適切な設計では、早い段階でこれらを一貫したコンテキストオブジェクトに正規化します。これにより、イベントを生成したツールがどれであっても、後続の各手順が同じフィールド名を参照できます。

• アーティファクトは最初に一度だけ抽出します。
• 型を検証します（これは本当に有効なIPv4ですか）。
• フロー全体で共有コンテキストを引き回します。

実際のワークフローには分岐があります。情報補強の後、証拠に基づいて進む経路を判断します。どのイベントも未処理のまま抜け落ちないよう、分岐を明示的かつ網羅的に保ちます。

破壊的、元に戻せない、または影響範囲が大きいアクションの前に、人間による承認ゲートを挿入します。プレイブックが証拠を集めて提示し、判断が届くまで処理を停止します。

タイムアウト時に安全なデフォルトとなるようにゲートを設計します。封じ込めの場合、応答がないときは処理を黙って続行したりケースを黙って破棄したりするのではなく、オンコールのエンジニアへエスカレーションするようにします。

• アカウントの無効化：ゲートを設けます。
• 大規模なサブネットのブロック：ゲートを設けます。
• インジケーターの情報補強：ゲートは必要ありません。

インテグレーションは失敗します。APIではレート制限やタイムアウトが発生し、不正な形式のデータが返されることもあります。すべての呼び出しが成功すると仮定したプレイブックでは、インシデントが途中までしか処理されないままになります。

次の仕組みを組み込みます。

• バックオフ付きリトライ：一時的なエラー（HTTP 429、503）に対応します。
• フェイルセーフなデフォルト値：エンリッチメントに失敗した場合は、自動クローズではなく、担当者へのエスカレーションをデフォルトにします。
• デッドレター処理：処理できないイベントを、アナリストが確認するキューへ振り分けます。

重複アラートやリトライによって、同じイベントに対してプレイブックが2回実行されることがあります。アクションは冪等でなければなりません。つまり、2回実行しても被害が二重に発生しないようにします。

すでに隔離されているホストを隔離する処理は、エラーではなく何もしない処理にすべきです。チケットを作成する前に、同じ重複排除キーを持つ既存のチケットがないか確認すべきです。

インシデントの種類ごとに巨大なプレイブックを1つ作るのは避けます。再利用できるサブプレイブックに分割します。たとえば、エンリッチメント用、封じ込め用、通知用のサブプレイブックです。

これは優れたソフトウェア設計と同じ考え方です。フィッシング、ブルートフォース、C2の各プレイブックから呼び出せる再利用可能なIPエンリッチメントブロックがあれば、脅威インテリジェンスAPIの変更時に修正する場所を1か所にできます。

新しいプレイブックは、まずドライラン／シミュレーションモードで実行します。エンリッチメントとログ記録は実行しますが、破壊的なアクションはスタブに置き換えます。プレイブックが提案するアクションを、過去の事例でアナリストが実際に行った対応と比較します。

過去の実際のインシデントで意思決定ロジックが正しいと確認できてから、ライブアクションを有効にします。その場合も、まずはすべてのアクションに承認ゲートを設けます。

プレイブックはコードであり、コードと同じ規律で管理する必要があります。すべての変更をレビュー可能で、追跡可能かつ元に戻せるように、バージョン管理下に置きます。

• 変更履歴があれば、なぜ先月とこのプレイブックの動作が違うのかが分かります。
• ピアレビューによって、本番環境に到達する前に危険なロジックを見つけられます。
• 想定するトリガー、判断、担当者を文書化しておけば、担当者が入れ替わってもプレイブックを保守できます。

誰も理解していない文書化されていないプレイブックは、誤作動した瞬間に負債になります。

障害シナリオにプレイブック設計の原則を適用します。

プレイブック設計の要点：

• プレイブックは実行可能で分岐する対応ワークフローです。実際の手作業プロセスをもとに設計します。
• 手順を決定論的なアクション、エンリッチメント、判断に分類し、判断には人による承認を必須にします。
• 正確なトリガーを定義し、アーティファクトを共有コンテキストに正規化し、すべての分岐を網羅します。
• リトライと安全なデフォルト値でエラーに対応します。エンリッチメントに失敗した場合は、自動クローズではなくエスカレーションします。
• アクションを冪等にし、再利用可能なサブプレイブックでプレイブックをモジュール化します。本番稼働前に、過去のインシデントを使ってドライランでテストします。