はじめに
オライリーの『セキュリティカオスエンジニアリング』は、Kelly Shortridge と Aaron Rinehart による
「セキュリティ・カオス・エンジニアリング（Security Chaos Engineering: SCE）」の体系書です。
一言で表すなら、「サイバーセキュリティの主眼を"防御・予防"から"レジリエンス"に転換せよ」
という主張です。
Netflix 発のカオスエンジニアリングをセキュリティ領域に拡張した本書は、
ソフトウェアエンジニア・セキュリティエンジニア・SRE のいずれにとっても示唆に富む一冊です。
本書の構成
全9章構成で、大きく「思想編」と「実践編」に分かれています。
- 第1〜2章：複雑系・レジリエンス・システム指向セキュリティの思想的基盤
- 第3〜6章：ソフトウェアデリバリーのフェーズ別（設計・構築・運用・対応）の実践ガイド
- 第7章：プラットフォームレジリエンスエンジニアリングの概念と実装
- 第8章：カオス実験の設計・実施・分析の具体的手順
- 第9章：UnitedHealth Group、Verizon、Capital One 等によるケーススタディ
第3〜6章はソフトウェアデリバリーのライフサイクルに沿ったリファレンスガイドとして
構成されており、アーキテクチャ設計・ビルド・運用・インシデント対応の各フェーズで
引き返しながら参照できる作りになっています。
中心的な主張：セキュリティはシステムが「持つ」ものではなく「行う」もの
本書の核心はシンプルです。
現在のサイバーセキュリティは「失敗を防ぐこと」を目標としており、
失敗は避けられないという現実に反している、という批判です。
著者らはこれを「セキュリティ劇場」と呼びます。
攻撃を「阻止」「ブロック」することに集中した現状のセキュリティプログラムは、
失敗しないことを前提にした設計であるため、
実際にインシデントが発生したときの対応力が構造的に育ちません。
対して SCE は、失敗を前提にシステムを設計し、
失敗に備えることで組織の耐性を高めることを目指します。
「セキュリティは、システムが持つものではなく、システムが行うもの」
というフレーズはこの考え方を端的に表しています。
本書が否定する4つの神話
本書は以下の4つのよくある誤解を明確に否定しています。
神話1：堅牢性＝レジリエンス
「攻撃を受けても元の状態に戻る」だけではレジリエンスではありません。
イソップ寓話の樫の木が嵐に立ち向かって折れるように、
堅牢性に偏った設計はむしろ脆さを生みます。
真のレジリエンスは「予測し・観察し・対応し・学習する」能力です。
神話2：失敗は防げるし、防ぐべきだ
複雑系において正確な予測・完全な防御は不可能です。
失敗を防ごうとする試みは、実際には失敗に備えることからリソースを奪います。
SCE は「失敗を想定してシステムを設計し、実験を通じて学習する」という立場です。
「悪者が勝つこともある。コントロールできるのは、どれだけの被害を受けるかだ」
という著者の言葉は、現実的なセキュリティ観を端的に示しています。
神話3：各コンポーネントの安全性の集積がレジリエンスにつながる
レジリエンスはシステムレベルの創発的な特性であり、コンポーネントを分析しても測定できません。
フロントエンドとデータベースをそれぞれ「安全」と評価しても、
それらの相互作用から生じる SQL インジェクションを見逃すことがあります。
「攻撃者はリストではなくグラフで考える」という表現は非常に鋭い指摘です。
神話4：「セキュリティ文化」がヒューマンエラーを解決する
情報漏洩の 80〜90% は「ヒューマンエラー」に帰責されますが、
その内訳を見るとリンクのクリック・コードのプッシュ・ログイン操作といった
日常的に行われている正常な行動が大半を占めています。
「人間をコントロールする」のではなく、
「人間に適合するシステムを設計する」ことが SCE の立場です。
従業員のキーストロークをログしてインサイダー脅威を検知しようとする試みは、
本書によれば問題の解決ではなく、組織のセキュリティの失敗の表れです。
レジリエンスの5つの構成要素
本書はレジリエンスを以下の5要素で定義しています。
1. 重要な関数の定義
「何のための、誰のためのレジリエンスか」を明確にすることが出発点です。
「〈不利なシナリオ〉に対するレジリエンスによって、〈顧客にとって好ましい結果〉をもたらす」
という形で定義することで、リソース配分の優先度が明確になります。
セキュリティチームがサイロ化していると、この定義が組織と乖離しがちです。
2. 安全境界（閾値）の把握
システムはある閾値を超えると、期待された振る舞いとは異なる状態に移行します。
『ジュラシック・パーク』の公園が複数の条件変化の積み重ねで崩壊するように、
いったん閾値を超えると以前の状態に戻るのは困難です（ヒステリシス）。
カオス実験を定期的に実施することで、閾値へのドリフトを早期に検知できます。
3. 時空を超えた相互作用の観察
インシデントには時間的・空間的な広がりがあります。
DDoS 攻撃が特定のサービスに波及する範囲と、
復旧に要する時間の組み合わせによってインパクトが変わります。
この時空間的な視点なしにレジリエンスを評価することはできません。
4. フィードバックループと学習文化
失敗から学ばなければレジリエンスは育ちません。
コンスタンチノープルが繰り返される包囲戦から「生態学的記憶」を蓄積し、
都市設計を適応させていったように、インシデントの知見を組織の設計にフィードバックし続けることが重要です。
インシデント後の投資が時間とともに薄れていく現象は、この記憶の喪失です。
5. 変化への柔軟性
適応能力とは「振る舞い・モデル・手順・プロセスをどれだけ変えられるか」です。
1年前の良い意思決定が今日も有効とは限りません。
「驚かされる用意をしておく」という表現が示すように、
硬直した現状維持の姿勢こそがレジリエンスを損ないます。
「レジリエンスは動詞である」という本書の言葉は、
これらの5要素を能動的に維持し続けることを表しています。
慢性ストレッサーと急性ストレッサー
本書が提示するフレームの中で特に実務的価値が高いのが、
2種類のストレッサーの区別です。
| 種別 | 具体例 |
|---|---|
| 急性ストレッサー（パルス型） | ランサムウェア、新規脆弱性の公開、クレデンシャル盗難、年次監査 |
| 慢性ストレッサー（プレス型） | 技術的負債、ドキュメントギャップ、アラート品質の劣化、チームの疲弊、現状維持バイアス |
インシデントが「急性ストレッサーが引き金を引いた」ものに見えても、
実際には慢性ストレッサーが長期間にわたってシステムのレジリエンスを削っており、
急性の事象がその閾値を超えさせたにすぎない、というケースが多いです。
セキュリティプログラムが急性ストレッサーへの対処に偏ると、
慢性的な脆弱化を見逃すという構造的な問題が生じます。
SCEの実践：カオス実験の設計（第8章）
第8章ではカオス実験の実施手順が体系的に説明されます。
- 仮説の設計 ― 「このシステムは X という攻撃シナリオに対して正常に機能するはずだ」という仮説を立てる
- 実験仕様書の作成 ― 影響範囲・ロールバック条件・成功基準を事前に文書化する
- 実験の実施と証拠収集 ― 本番に近い環境で爆発半径を小さく設定して開始する
- 証拠の分析と文書化 ― 得られた知見をシステム設計とセキュリティプログラムにフィードバックする
ゲームデイ（手作業によるカオス実験）は、
いきなり自動化された実験に抵抗がある組織の入口として有効とされています。
この一連のサイクルは SRE のエラーバジェットやカオスエンジニアリングの原則と本質的に同じ発想で、
セキュリティの文脈に適用したものです。
対応と回復：インシデントレビューのバイアスを手放す（第6章）
第6章では、インシデント後の振り返りにおける認知バイアスを掘り下げます。
- 後知恵バイアス ― 「なぜあのとき気づかなかったのか」という問いの非生産性
- 結果バイアス ― 悪い結果＝悪い判断という短絡的な帰責
- 公正世界仮説 ― 「きちんとやっていればインシデントは起きなかった」という幻想
- 行動バイアス ― 「何かしなければ」という衝動が誤った修正につながる
「根本原因はヒューマンエラー」という結論は、
インシデントレビューとして最も非生産的な終わり方です。
本書はこれを明確に否定し、人間を責めるのではなく、
どのような条件の組み合わせが失敗を引き起こしたかを問うことを推奨します。
プラットフォームエンジニアリングとセキュリティの統合（第7章）
第7章では、セキュリティを「内部顧客向けのプロダクト」として設計するアプローチが紹介されます。
プラットフォームエンジニアリングチームが内部開発者向けに基盤を提供するように、
セキュリティチームも「エンジニアが使いやすいセキュリティのデフォルト」を設計・提供する役割を担います。
「セキュリティソリューションのアイスクリームコーン階層」という概念が紹介されており、
セキュリティが強制とポリシー一辺倒になると開発者体験が損なわれ、
最終的にはセキュリティそのものが迂回されるというアンチパターンを構造的に示しています。
構想の定義・ユーザの問題定義・ソリューション設計・実装というプロダクト開発の流れを
そのままセキュリティの内部サービス設計に適用する、という発想は実践的です。
第9章：実際の導入事例から学ぶ
最終章では以下の組織によるケーススタディが紹介されます。
- UnitedHealth Group
- Verizon
- OpenDoor
- Cardinal Health
- Accenture Global
- Capital One（サイバーカオスエンジニアリング）
いずれも、小さな爆発半径から始め、
実験を繰り返しながら組織のカオス実験への習熟度を高めていったプロセスが描かれており、
「理想論ではなく実際に動いた話」として読めます。
読んで感じたこと
本書は「セキュリティの本」というより、複雑系とシステム思考の本として読めます。
航空・医療・生態学・都市インフラ等の知見を縦横に引用しており、思想的な密度は高いです。
一方で実装の詳細は意図的に省かれており、「考え方のフレームを与える」ことに集中しています。
具体的なツール選定や実装例を期待すると肩透かしになる点は注意が必要です。
設計・アーキテクチャに関心があり、
「なぜうちのセキュリティプログラムは形骸化するのか」という問いを持つエンジニアには、
強くおすすめできます。
まとめ
| 項目 | 内容 |
|---|---|
| 書名 | セキュリティカオスエンジニアリング |
| 著者 | Kelly Shortridge, Aaron Rinehart |
| 出版 | O'Reilly Media |
| 難易度 | 中〜上級（設計思想の素養があると読みやすい） |
| おすすめ読者 | SRE、アーキテクト、セキュリティエンジニア、技術責任者 |
「完璧な防御」という幻想を手放し、
失敗を前提にシステムを設計・観察・学習していくこと ――
それが本書の問いかける姿勢です。
現状のセキュリティプログラムに閉塞感を感じているエンジニアにとって、
視点を組み替えるきっかけになる一冊だと思います。