🔥 🚒 レッドチーム演習の計画
このドキュメントは、Red Teams で説明されている非常に特殊なレッドチームスタイルと対比することで、レッドチーム計画を立てる際の参考になります。この手法は、ブルーチームの価値と熱意を最適化するためのいくつかのバイアスを表現しています。具体的には、レッドチームへの罰を与えることで動機付ける試みを避けます。
以下の質問を見直して、レッドチームの計画がブルーチームの価値のために十分に検討されているかを確認してください。
❌ 否定的な動機
以下は、レッドチーム演習を実施する一般的な理由ですが、士気やチームの結束に悪影響を及ぼす性質があります。演習があなたの目標に対して間違ったツールである可能性があります。
- 別の組織の非安全性を証明する
- あるグループの人々に対して支配力を示す
- 衝撃と畏怖によって証明したり、主張を通したりする
- できるだけ多くの脆弱性を列挙して発見する
- 単純な検知メカニズムが機能しているかどうかをテストする
👍 ステークホルダー
リーダーシップや影響力のある人々からのスポンサーシップやフォローアップがない演習ほど無駄なものはありません。演習の学びが熱心なステークホルダーのグループによって推進されるようにしてください。このグループが情報を得て、勢いを生み出せるようにしてください。
- 演習の成果を推進するための期待値と、既知の責任者・持ち主を設定する
- 変化を受け入れる姿勢があることを確認し、変化を推進するためのスポンサーシップを準備する
- 組織はこの演習に自発的に参加しているか?
- 参加者はリスクに対するいかなる調整や、現在のロードマップの見直しに対してオープンか?
- レッドチームの調査結果よりも優先される重大な負債があるか?
- レッドチームの調査結果があまりにも予測可能で、そもそも演習が必要なかったのではないか?
📅 時間の見積もり
この計画フェーズから対策フェーズの終了まで、またはその中間のどこかまでに割り当てる時間を予測できます。時間の期待値は、各フェーズで下される決定に大きく依存します。
- 計画 (数週間/数ヶ月): 全体的な実行の計画、このドキュメントのギャップを埋める。
- 攻撃 (数分/数週間): レッドチームのオンボーディングとインシデントの能動的な作成。
- 対応 (数時間/数週間): インシデントが発見された場合の即時対応の長さ。
- 机上演習 (Tabletop) (数日/数週間): インシデントが発見されなかった場合の、強制的な対応または机上演習の長さ。
- インシデント対応(短期的) (数日/数週間): レッドチームのアクセスを除去し、発見された脆弱性を塞ぎ、敵対者を排除する時間。
- レッドチーム公開 (数時間): インシデント対応の現実を調整するために、レッドチームの行動を公開する。
- インシデント対応(事後検証) (数時間/数日): 学んだ教訓の整理と広範なプレゼンテーション。
- 長期的な緩和策 (数週間/数ヶ月): 次のレッドチームを検討する前に、より困難な教訓、リファクタリング、成長を完了する。
👪 人々
レッドチームの計画や秘密を知る必要がある可能性のあるすべての人を特定します。ここで「緊急時破壊 (Break Glass)」リスクを軽減し、緊急時に演習から方向転換するための連絡先を準備しておくとよいでしょう。
- コンサルティング会社: 外部の第三者をレッドチームとして雇いますか?
- 内部リソース: 内部の従業員がレッドチームを務めますか?
- (この場合、)警察への通報を差し控える責任者は誰ですか?
- 対外広報・コミュニケーションの責任者は誰ですか?
- 顧客とのやり取りの責任者は誰ですか?
- 不正アクセス通知のリソースは誰ですか?(社内 / 社外弁護士)
- 問題を導き、最終的な良識の源となる全体的な「ゲームマスター」は誰ですか?
📉 戦略
この経験からどこに価値を蓄積するかを決定します。どこにでもトレードオフがあり、それが演習で解決したい課題に一致しない可能性があります。
- 潜在的な防御側は、いつかレッドチームが来ることを認識していますか?
- 認識すべきでしょうか?その期待を設定する必要がありますか?
- レッドチームが来るであろう期間も発表しますか?
- それは健全な興奮と準備のスプリントを生み出しますか?
- 攻撃者は不正行為によって強力にガイドされますか、それとも自由形式ですか?
- このトレードオフは、インシデント対応の価値と脆弱性の発見に関するものです。
- チームは、非難に関する厳格なルールがあることを通知されていますか?
- これがセキュリティの悪さに対する罰であるという感覚を避けたいものです。
- チームは、これがブルーチームへの贈り物であり、悪いセキュリティを罰するものではないと通知されていますか?つまり、これはテストではなく、スパーリングです。
- この点を強調します。これは貴重なフィードバックループであり、従業員の業績評価サイクルではないことを周知してください。
- 演習を構成するための特定の方法 または現実的な「キルチェーン」が選択されていますか?
- あなたの目標は、高度に緩和されたリスク、またはテレメトリ/予防策がはるかに少ないリスクでインシデントをシミュレートすることですか?
- 各フェーズにおける「緊急時破壊 (break glass)」は何ですか?レッドチームが暴走して障害を引き起こした場合に、真実と次にすべきことを広く告知するにはどうすればよいですか?
- どのような状況でレッドチームを「中止」したいですか?
- 自然に完了したとき、外部からの干渉で停止が必要なとき、または参加者にとってもはや価値がなくなったときを考慮してください。
🔧 攻撃設計
攻撃は、緩和しようとしているリスク、対処しようとしているインシデント、または対応に参加させたい個人を表します。これらの決定にはすべて計画上の負担が伴い、できるだけ早く特定することが役立ちます。
- 攻撃は実際に多くの専門知識と労力を必要としますか、それとも攻撃の単純な再現で発見できますか?外部の当事者はそもそも必要ですか?
- 攻撃はキルチェーンのどこから開始すべきですか?(例:初期のスピアフィッシング、または後期のドメイン管理者による横展開)
- 攻撃の開始をサポートするために必要な資格情報/物理アクセス/文書は何ですか?誰がそれらを提供しますか?後でフォローアップが必要なセキュリティ上の影響はありますか?
- レッドチームが早期に成功した場合、ペネトレーションテストや脆弱性評価を開始すべきですか?発見されることを試みるべきですか?
- 攻撃者は特定の敵対者や攻撃方法を偽装すべきですか?
- レッドチームが検知された場合、バックアッププランや2回目の攻撃はありますか?レッドチームはペネトレーションテストに頼ることになりますか?
- レッドチームはどこでどのように行動を記録しますか?これらは、その後の机上演習や、是正と教訓の確認のために取得する必要があります。bash履歴、TCPダンプ、手動メモを収集できますか?
- レッドチームの方法は現実に基づいていますか?現実的な攻撃者が利用できない方法を使用していますか?
🚨 インシデント対応
対応プロセスがどれほど成熟しているかを予測できれば、対応を操作してより大きな利益を得られます。未熟な対応チームはゲームマスターが強力にガイドでき、成熟した対応チームは、調整とコミュニケーションにおける摩擦点を特定するために放置できます。
- インシデント対応が従うべき特定の調整方法や計画はありますか?たとえば、Security Breach 101 や An Incident Response Plan for Startups で説明されている議題と方法です。
- インシデント対応は自然にまとまる必要がありますか?そうすれば、そのプロセスにおける摩擦を取り除くことができます。
- 意図した対応を練習として強制するために、インシデント対応を人為的にまとめますか?
- インシデント対応を制御するために、インシデントを人為的にエスカレーションしたいですか?
- ブルーチームからの正直な質問がある場合、誰がレッドチームとのコミュニケーションを橋渡ししますか?(例:「私たちは別の侵害を見つけたと思います」)
- ブルーチームが緩和策を講じる際に、誰がレッドチームの痛点を記録しますか?(「あなたは私たちのビーコンを何度も削除し続け、戻るのが大変でした。まさか一度に全部見つけるとは思いませんでした!」)
- インシデント対応がタイムリーに進まない場合、誰がどのように指標をブルーチームに漏らしますか?
- 短期的な緩和策/長期的な予防策は、インシデント対応の一部として収集されていますか?
🔍 レッドチーム公開
ブルーチームはレッドチームに対してあらゆる種類の質問を持っています。正しく行われれば、これは興奮の瞬間になり得ます。この関係を健全に保つことは非常に重要です。レッドチームは貴重なスパーリングパートナーと見なされるべきです。さらに言えば、追いかけるべきウサギです。
- 攻撃フェーズ中のレッドチームの行動は非常によく文書化され、理解されていますか?
- インシデント対応プロセスは、レッドチームの重要な行動を見落としていませんか?
- 将来もビーコンを発信したり、発見可能なままのIOCやアーティファクトはありますか?
- バックドアやその他のリスクのある変更がインシデント対応を生き延びていますか?
- ブルーチームの調査と封じ込めはどの程度徹底していましたか?
💀 事後検証 (Post Mortem)
質の高い事後検証は、数ヶ月分のロードマップ化されたセキュリティ作業に情報を提供し、共通の経験を通じて全員をミッションに合わせて調整します。
- 演習のすべての参加者に対して徹底的なインタビュープロセスまたはデブリーフィングが行われましたか?
- すべてのフォローアップ緩和項目は中央に収集され、参加者の価値感に基づいて優先順位付けされましたか?
- これらの所見は結論付けられ、参加者に提示されていますか?
- それらを提示するための会議は予約されていますか?
- 誰がそれらを提示しますか?
- レッドチームはこれらの所見にコメントしたり、質問に答えたりできますか?
- 参加者は参加に対して報酬を得ていますか?
- 彼らにはデブリーフィングと討論のための十分な時間が与えられていますか?
- これは実践的なリスクに向けた貴重な調整ですか?
👶 小規模な演習
演習を小さく保ち、他の人の関与を最小限に抑えることができます。創造的になりましょう。
単純に、対応に成功すると思われるインシデントをチームメンバーにシミュレートさせます。たとえば、自動更新機能を持つソフトウェアをインストールし、それがマルウェアであるふりをします。そして、その「C&C」を「ハント」します。それは単にその更新ビーコンです。たとえば、それがこのホストにのみ隔離されており、他のホストには拡散していないことを証明できますか?
または、チームメンバーに「不正な変更」を行わせ、そのイベントと重要となるフォローアップを文書化したインシデントタイムラインを作成させます。
調査結果、教訓、フォローアップを文書化して、他の人に提示するようにしてください。レッドチームは、その教訓が孤立している場合には価値がなく、複雑である必要もありません。