セキュリティカオスエンジニアリング

# セキュリティカオスエンジニアリング (Security Chaos Engineering, SCE) ## 定義セキュリティカオスエンジニアリング(Security Chaos Engineering、SCE)は、本番環境で悪意ある攻撃からシステムを守れる自信がつくように、プロアクティブな実験を通じてセキュリティ制御に関する不具合を特定することと定義される。[[カオスエンジニアリング]]が可用性に関わるインシデントを発生前に検知するプロアクティブな仕組みとして確立されてきた慣習を、サイバーセキュリティの分野へ適用したものである。SCE は、システムに対して客観的に制御されたシグナルを導入することが不確実性を理解する唯一の方法だという立場をとり、これによって異なるタイプのインシデントへの対処力・技術の効果性・手順書やインシデント対応プロセスの実態との一致度を、期間ごとに比較可能にする。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 20 セキュリティカオスエンジニアリングの事例]] 章冒頭の定義, §20.1) SCE の目標は、セキュリティの実践を主観的な評価から客観的な測定に変えていくことにある。意図的に故障モードやその他の事象を導入することで、セキュリティシステムがどれくらい装備され、観測可能で、測定できるものとなっているかを知ることができ、チームはセキュリティの機能が想定どおりに動いているかを客観的に評価したうえで、能力を安定させ弱点を減らしていける。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 20 セキュリティカオスエンジニアリングの事例]] 章冒頭) ## 既存のセキュリティテスト手法との違い SCE は、Red チーム・Purple チームの演習のような従来のセキュリティテスト手法を置き換えるものではなく、これらの手法の価値を見過ごす意図はない。両者は目標とテクニックの面で差があり、組み合わせるとより客観的でプロアクティブなフィードバックの仕組みを提供できる。 | 観点 | Red / Purple チーム | SCE | |---|---|---| | 成果物 | レポート(実行可能なフォローアップに乏しい) | 反復可能な実験結果・継続的なシグナル | | 焦点 | 悪意ある攻撃者・行為 | より一般的なシステムの脆弱性を含む包括的な観点 | | インセンティブ | Blue チームを出し抜くこと(理解の共有より) | 運用上のセキュリティの一貫性への信頼構築 | | 変更規模 | 複雑な攻撃の連鎖(数百〜数千の変更) | シンプル・隔離・制御された実験 | | 頻度・リソース | 年 1 回〜毎月程度、リソース集約的 | CI/CD のペースに追随できる高頻度・低リソース | | 学習形態 | インシデント対応としての評価 | インシデント発生中を避け、平常稼働時の協調的な学習体験 | (Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 20 セキュリティカオスエンジニアリングの事例]] §20.2–§20.2.3) ## ツールの例: ChaoSlingr [[ChaoSlingr]] は [[UnitedHealth グループ]] で [[Aaron Rinehart]] のチームが開発した、カオスエンジニアリングをサイバーセキュリティへ適用する価値を示した最初のオープンソースソフトウェアである。Generatr・Slingr・Trackr・Experiment description という 4 つの基本機能で構成され、ポート設定ミスの実験ではファイアウォールの検知・ブロックが半分のケースで失敗していることを明らかにした。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 20 セキュリティカオスエンジニアリングの事例]] §20.4.1、詳細は [[ChaoSlingr]] を参照) ## 横断的知見 - **SCE が根本原因分析(RCA)を批判する論拠は、本 wiki が既に集約してきた安全科学における RCA 批判と同じ理論的系譜に属する**: 本章(ch.20)は Sydney Dekker の言葉「『根本原因』と呼んでいるものは、単にそれ以上深追いして見るのをやめた地点にすぎない」を引用し、RCA が不必要な非難・エンジニアの孤立・組織内の恐怖の文化をもたらすと批判する。[[Sidney Dekker]] は本 wiki において既に「Old View（人間を問題の原因とする見方）」批判の提唱者として記録されており、[[@2022__SREcon22APAC__A Post Incident Review Review]] はこの Dekker 由来の安全科学に基づき、ANZx が「根本原因なし・アクションアイテムなし・MTTx なし」という PIR 設計を採用し、高度規制産業・1000 人超組織で再発インシデントがまれという実績を得たことを報告する。SCE の RCA 批判(セキュリティ領域)と ANZx の PIR 設計(インシデント対応領域)は、異なる実務領域でありながら同一の Dekker 由来の理論的系譜から独立に類似の処方箋(根本原因という単一の帰属先を求めない)を導いている。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 20 セキュリティカオスエンジニアリングの事例]] §20.1.1, [[@2022__SREcon22APAC__A Post Incident Review Review]]) - **カオスエンジニアリング本体(3章)が示す「カオスエンジニアリングではないもの」という定義上の切り分けは、SCE における Red/Purple チームとの関係にも同型で現れる**: [[カオスエンジニアリング]] 概念ページが集約する 3 章の議論は、カオスエンジニアリングを抗脆弱性(Antifragility)と混同すべきでないと明示的に線引きする(既出)。同様に 20 章は、SCE を Red チーム・Purple チームの演習と「競合するものではない」「これらのプラクティスの価値をいっそう高める」と明示し、置き換えではなく補完の関係として位置づける。カオスエンジニアリングという規律は、汎用領域(3章: 対抗脆弱性)とセキュリティ領域(20章: 対 Red/Purple チーム)の両方で、既存の隣接プラクティスとの境界を明示的に引く同じパターンの論証構成を繰り返している。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 20 セキュリティカオスエンジニアリングの事例]] §20.2.3, [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 3 原則の全体像]] §3.2.1–§3.2.2) - **BSRS ch.16 が挙げる Envoy の fault injection HTTP filter は、SCE が主張する「シンプル・隔離・制御された実験」という設計原則の非セキュリティ領域(可用性・タイムアウト処理)での具体的な実装例であり、SCE のツール系譜(ChaoSlingr)と並ぶもう1つの実例を提供する**: 本章(ch.20)は ChaoSlingr というセキュリティ特化の障害注入ツールを紹介するが、『Building Secure and Reliable Systems』16章はロードバランシング用プロキシ Envoy の fault injection filter(トラフィックの一部にエラーを返す・遅延を挿入する)を、個別チームが依存先を巻き込まずに自チームのシステムだけをテストする例として挙げる。両者はドメイン(セキュリティ対可用性)が異なるが、「シンプルで隔離された実験を高頻度に回す」という SCE の設計原則(§20.2–§20.2.3 の対比表)を体現する点で同型であり、SCE がセキュリティ領域に固有の思想ではなく、より一般的な障害注入の設計原則をセキュリティに適用したものであることを裏づける。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 20 セキュリティカオスエンジニアリングの事例]] §20.4.1, [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 16 Disaster Planning]] §Single system testing/fault injection) ## 未解決の問い - ChaoSlingr のポート設定ミス実験では、実験対象のツールがインシデント発生箇所をセキュリティチームが容易に特定できる形でログを取れていなかったと報告されるが、この検知可能性(observability)のギャップを埋めるためにログ・トラッキングの設計をどう改善すべきかは 20 章に明記がない。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 20 セキュリティカオスエンジニアリングの事例]] §20.4.1) - SCE は「シンプルかつ隔離され、制御された実験」を Red/Purple チームの「複雑な攻撃の連鎖」と対比するが、実際の攻撃者は複数の手近な標的を連鎖させることが多いと同章前半で述べられる(§20.1.2)。単一の隔離された実験の積み重ねが、攻撃者が行う連鎖的な悪用パターンの発見にどこまで到達できるのかは検証されていない。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 20 セキュリティカオスエンジニアリングの事例]] §20.1.2, §20.2.3) - カオスエンジニアリング本体が確立してきた「爆発半径の局所化」(既出、[[ブラスト半径]])は可用性実験における影響範囲の縮小を扱うが、セキュリティ実験で意図的に脆弱性を導入する際の爆発半径(悪用可能な窓が実際に開く時間・範囲)をどう最小化すべきかは 20 章では詳述されない。ChaoSlingr の「緊急停止ボタン」がこの役割を担うと推測されるが、具体的な設計は記されていない。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 20 セキュリティカオスエンジニアリングの事例]] §20.4.1) - セキュリティゲームデーの実施頻度・ガバナンスは、[[GameDay]] 概念が集約する可用性系ゲームデーの実践(DiRT 等)とどこまで共通化でき、どこがセキュリティ固有の追加要件(機密性の高い脆弱性情報の扱い、法規制対応)を必要とするかは 20 章単体では判断できない。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 20 セキュリティカオスエンジニアリングの事例]] §20.3) ## 関連 - 関連しうる隣接領域: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 8 セキュリティ：負の目標]](ChaoSlingrのポート設定ミス実験が明らかにしたファイアウォールの検知失敗は、同章§8.7が論じる従来型ファイアウォールのルール複雑化と問題意識を共有するが、同章は能動的な障害注入実験ではなくアーキテクチャ論として論じており、横断的知見を構成するには至らない) - [[カオスエンジニアリング]] — SCE の理論的基盤。可用性領域からセキュリティ領域への拡張元 - [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 20 セキュリティカオスエンジニアリングの事例]] — SCE を提唱する一次資料 - [[Aaron Rinehart]] — SCE の提唱者。[[Verica]] CTO 兼共同創業者 - [[ChaoSlingr]] — SCE を実装した最初のオープンソースツール - [[UnitedHealth グループ]] — ChaoSlingr の開発組織 - [[Verica]] — Aaron Rinehart が現在在籍するカオスエンジニアリング企業 - [[Sidney Dekker]] — RCA 批判の理論的源泉として本章に引用される安全科学者 - [[複雑システム障害論]] — RCA の社会的構築性を論じる姉妹領域 - [[GameDay]] — セキュリティゲームデーの実施形式 - [[ポストモーテム]] — RCA に代わるインシデント後の学習実践 - [[机上演習とレッドチーム演習]] — 侵襲度で段階配置したテスト手法群。SCE 対 Red/Purple チームの比較軸を包含 - [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 16 Disaster Planning]] — Envoy fault injection filter の実例 ## 出典 - [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 20 セキュリティカオスエンジニアリングの事例]] — Aaron Rinehart, 「セキュリティカオスエンジニアリングの事例」, Casey Rosenthal・Nora Jones 編『カオスエンジニアリング ― 回復力のあるシステムの実践』, オライリー・ジャパン, 2022, 20章. - [[@2022__SREcon22APAC__A Post Incident Review Review]] — Tom Partington, SREcon22 APAC, 2022(Dekker 由来の安全科学に基づく PIR 設計) - [[@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, §Single system testing/fault injection.