# 机上演習とレッドチーム演習 Navigation: [[index]] | [[インシデントシミュレーション]] | [[セキュリティカオスエンジニアリング]] ## 定義 机上演習とレッドチーム演習は、災害・インシデント対応の準備状況を検証するテスト手法を、本番環境への侵襲度(システムを実際に止める/壊すかどうか)という単一の軸に沿って段階的に配置する枠組みである。最も侵襲度の低い非侵襲的な机上演習(tabletop exercise)から出発し、単一コンポーネントへの障害注入、鍵となる担当者の不在を想定する人的リソーステスト、複数コンポーネントの同時故障を想定するマルチコンポーネントテスト、データセンター単位で電源を落とす全系フェイルオーバーテスト、そして事前通知なしで実施されるレッドチーム演習へと、扱う範囲と本番影響の大きさを段階的に引き上げていく。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 16 Disaster Planning]] §Testing Systems and Response Plans, §Testing Response in Production Environments, §Red Team Testing) 机上演習は、信憑性(believability、フィッシングに引っかかったユーザーの端末が侵害される、といった現実味のあるシナリオ)・詳細さ(details、シナリオ作成者が事前にログや顧客報告といったアーティファクトを用意する)・分岐点(decision points、60分の演習で10〜20個程度が目安の「Choose Your Own Adventure」的な分岐)・参加者とファシリテーターの相互作用(実際に手順を実演させ筋肉の記憶を作る)・実行可能な改善提案を伴う結果(outcomes)、という5つの設計要素で構成される。フロントラインのエンジニアだけでなく、シニアリーダーシップ・広報・弁護士まで幅広い役割の参加者を巻き込める点が特徴である。(Source: 同章 §Conducting Nonintrusive Tabletops) 本番環境でのテストでは、Envoy HTTPプロキシのfault injection HTTP filterのような障害注入フレームワークを用いて、依存関係を巻き込まずに個別チームが自分のシステムだけをターゲットにしたテストを実行できる。レッドチーム演習は、Googleの情報セキュリティ保証組織が事前通知なし(シニアリーダーシップを除く)で実施する攻撃的テストで、内部関係者ゆえに標準的なペネトレーションテストより効果が高く、フィッシングやソーシャルエンジニアリングを通じて技術面だけでなく人的側面もテストする。(Source: 同章 §Single system testing/fault injection, §Red Team Testing) テストの最終段階は評価(evaluating responses)であり、各テストの実行時間を測定し、非難のないポストモーテムとアクションアイテムを作成し、そのアクションアイテムをBlue/Redチームに実装させるPurple Teamのような仕組みで実際に脆弱性が塞がれたかを確認する、というフィードバックループを回す。教訓を実装に移さない演習は「単なる娯楽」に過ぎないと本章は明言する。(Source: 同章 §Evaluating Responses) ## 横断的知見 - **本枠組みの「侵襲度で段階配置する」という設計思想は、[[インシデントシミュレーション]] が集約するステージドワールド(staged world)研究の「忠実度(fidelity)」軸と、[[セキュリティカオスエンジニアリング]] が集約するSCE対Red/Purpleチームの比較軸を、1本の連続体として統合する**: [[インシデントシミュレーション]] は Hamed Silatani のステージドワールド研究([[@2024__SREcon24EMEA__Incident Groundhog Day]])が要求する「十分な忠実度」「唯一解なし」「専門性を引き出す設計」という、単一の高忠実度シミュレーション内部の質を論じる。[[セキュリティカオスエンジニアリング]] は SCE(シンプル・隔離・制御された実験、高頻度・低リソース)と Red/Purple チーム(複雑な攻撃連鎖、低頻度・リソース集約的)という、本番環境で実施する2種類のテスト手法を対比する。本章が示す机上演習→単一コンポーネント障害注入→マルチコンポーネント→全系フェイルオーバー→レッドチームという段階配置は、この2つの既存知見を「侵襲度」という共通軸上に並べ直したものであり、机上演習の忠実度要求(Silatani)と本番テストの侵襲度・複雑度の対比(SCE)が、実は同じ準備活動の異なる到達点にすぎないことを示す。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 16 Disaster Planning]] §Testing Systems and Response Plans, [[@2024__SREcon24EMEA__Incident Groundhog Day]], [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 20 セキュリティカオスエンジニアリングの事例]] §20.2–§20.2.3) - **本章のレッドチーム演習は「DiRT演習に類似する」と明記されており、GameDay系の全系テストとレッドチームという異なる侵襲軸の演習が、Google社内では同一の年次サイクルに包含されている可能性を示す**: 本章はDiRT演習(breakglass機構の検証、[[DiRT]])とレッドチーム演習(事前通知なしの攻撃的テスト)をともに「実際の攻撃をシミュレートしてbusiness impactを実証する」目的で類似のものとして並置する。[[GameDay]] 概念が集約する全系フェイルオーバーテストの実践知見と、[[セキュリティカオスエンジニアリング]] が集約するSCEの「本番でのシンプルな実験」という性質は、いずれも「事前通知の有無」という軸では言及がなかったが、本章はレッドチームを唯一の「事前通知なし」テストとして明示しており、通知の有無が侵襲度とは独立したもう1つの分類軸になりうることを示唆する。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 16 Disaster Planning]] §Red Team Testing, §DiRT Exercise Testing Emergency Access) - **第20章は、第16章が演習の一段階として扱う「レッドチーム演習」を、組織内の恒常的な役割区分(Blue Team/Red Team/Purple Team)として定義し直し、脆弱性スキャン・ペネトレーションテストとの境界線を明示する**: 第16章はレッドチーム演習を「事前通知なしで実施される、侵襲度が最も高い演習」という、机上演習から全系フェイルオーバーまでの連続体の最終段階として位置づけるにとどまる。これに対し第20章は、Blue Teamを「防御を担う組織内の全員」という特定チームに限らない概念として定義し、Red Teamについては目標達成型(特定データの窃取)・偵察・標的型攻撃という3種の狙いを整理したうえで、脆弱性スキャンチーム(既知パターンの自動検出、短期間)やペネトレーションテストチーム(特定コンポーネントの網羅的発見、短期間)とは異なり、プロダクト・インフラ・内外の境界を横断しながら数週間かけて活動する点で区別されると明言する。第16章はこの境界線(Red Teamと脆弱性スキャン/ペンテストの違い)には触れておらず、第20章がその欠落を補う。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 20 Understanding Roles and Responsibilities]] ch.20 §Special Teams - Blue and Red Teams, [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 16 Disaster Planning]] §Red Team Testing) - **第20章の「Red Team検知時のデエスカレーションプロトコル」は、第16章が示すRed Team/Blue Team間の情報共有の必要性を、より具体的な失敗シナリオで裏づける**: 第16章はRed TeamとBlue Teamの情報共有について、アクションアイテムの実装確認を担うPurple Teamという仕組みに触れるにとどまるが、第20章は情報を共有しない運用を選んだ場合に必要となる「検知時のデエスカレーションプロトコル」を、顧客データベースへの侵入をBlue Teamが検知して緊急対応手順が発動し、エグゼクティブ・法務・規制当局への通知まで進んでしまう、という具体的な混乱シナリオとともに示す。これは同一書籍内で、Purple Teamという「情報共有する場合」の解決策(第16章)と、情報共有しない場合に備えるべきプロトコル(第20章)という、対になる2つの運用選択肢が別の章に分かれて記録されていることを意味する。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 20 Understanding Roles and Responsibilities]] ch.20 §Special Teams - Blue and Red Teams, sidebar "Detecting Red Teams", [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 16 Disaster Planning]] §Evaluating Responses) ## 未解決の問い - 本章が示す「侵襲度」の単一軸配置と、Silatani(ステージドワールド)が論じる「忠実度」は、同じ演習に対して独立に測定できる別次元なのか、それとも侵襲度が上がるほど必然的に忠実度も上がる従属関係にあるのか。机上演習でも十分な忠実度を達成できるとSilataniは主張するが、本章はそれを本番テストより「侵襲度が低い」段階として位置づけており、両者の関係は明確でない。 - 「事前通知の有無」(レッドチームのみ無通知)という軸を、机上演習・単一/複数コンポーネントテスト・全系フェイルオーバーの各段階に組み合わせた場合(例: 無通知の単一コンポーネント障害注入)、既存の侵襲度ベースの段階配置はどう再構成されるべきか。 - Purple Teamによる「脆弱性が塞がれたことの確認」というフィードバックループの仕組みは、机上演習のアクションアイテム追跡や全系フェイルオーバーテストの改善提案にも同様に適用されているか、それともセキュリティ領域固有の仕組みか。 - 第20章が示すRed Team/Blue Team/Purple Teamという組織上の役割区分と、第16章が示す演習イベントとしてのレッドチーム演習は、同じ書籍内でどこまで統一的に運用されているか(たとえば第20章のBlue Teamは常設の役割だが、第16章の演習は年次サイクルのイベントとして語られる)。両者の関係(常設の役割 対 定期的なイベント)は本concept内で明示的に整理できていない。 ## 関連 - [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 16 Disaster Planning]] — 本概念の一次資料 - [[インシデントシミュレーション]] — 机上演習・ステージドワールドの忠実度設計論 - [[セキュリティカオスエンジニアリング]] — 本番環境での障害注入とRed/Purpleチームの比較軸 - [[カオスエンジニアリング]] — 障害注入フレームワークの一般理論 - [[災害計画]] — 本枠組みが検証する対応計画・プレイブックの設計側 - [[GameDay]] — 全系フェイルオーバーテストの実践形式 - [[DiRT]] — Googleの年次全社演習。レッドチームと類似の目的を持つと本章が明示 - [[ポストモーテム]] — 評価フェーズのフィードバックループの核心 - [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 20 Understanding Roles and Responsibilities]] — Blue/Red/Purple Teamの組織上の役割定義、脆弱性スキャン・ペネトレーションテストとの境界線、検知時のデエスカレーションプロトコル ## 出典 - [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 16 Disaster Planning]] — Michael Robinson・Sean Noonan, "Disaster Planning", in Heather Adkins et al. (eds.), *Building Secure and Reliable Systems*, O'Reilly Media, 2020, Chapter 16. - Heather Adkins, Cyrus Vesuna, Hunter King, Felix Gröbert, and David Challoner, in Heather Adkins et al. (eds.), *Building Secure and Reliable Systems*, O'Reilly Media, 2020, Chapter 20.