前置き
案件の中で災害時本番を想定したセキュリティカオスエンジニアリングをシステムオブシステムズ(SoSと略)スケールで扱ってきた。
サンプルモデル程度なので、あくまでもアーキテクチャ構築のプロセスや運用の方法論的なものを構築するにとどまってしまうものの、RedチームとBlueチームに分けてモデルを考え、回復力のある組織的アーキテクチャを構築することに焦点を当てられるという、
アーキテクトとしてもだし、セキュリティに対する考え方のスキルアップにもなった。
ここで書く内容は、書籍で書かれていた内容を自分が案件で体験した内容と照らし合わせてみて、これが私なりの方法論ですといった感じにまとめたものです。
以下のリスクベースアプローチと組み合わせて考えないといけないものなので、
是非以下の記事も読んでみてください。
UAFを使った設計
案件の中では、主にUAFという枠組みを用いて
RedチームとBlueチームそれぞれのワークフローを考え、
「相手がこんな振る舞いをしたらどうする？」
「戦略を途中で変えてきたら？ それを類推するにはどうしたら？」
ということを考えてきた。
ちなみに規模が大きくなるほどRedチームとBlueチーム両方の各階層のモデルを作成するとなると、結構な時間がかかってしまう。
それにRedチーム目線になれるセキュリティエンジニアさんなどがいないと、
そのモデルの作成時間は有意義なものにはなれないと実体験から感じている。
リソースレベルからボトムアップ式に
Operationalビューなどは１段階抽象的な概念の設計を行うビューなので、
そのビューで議論しても有機的な情報を得られなかったりする。
なので、自分が案件の中でファシリテートする際に意識していたのは、
まずは必ず具体的にイメージしやすい【Resourceビュー】で議論することである。
その上でリソースに依存しない１段階抽象的なOperationalワークフローなどを抽象化して明らかにするのだ。
そして最終的にStrategicビューでの要素であるビジネスケイパビリティで定義された、
満たすべき防御や攻撃能力を下位の具体的なワークフローで実現できているかな？とチェックする。
個人考察
コンテストマップを使用した個人考察
もっとも守るべき対象である価値を生むコアドメイン領域を外部からの攻撃や、
内部的事情による障害から守って継続的に価値を生み続けるためには、
どの領域を特に重点的にセキュリティ高めないといけないのか？
その守るべき領域が突破される → コアドメインが攻撃される
という因果関係の成立するような場所を探し、
さらにその領域が突破されてしまう原因を辿るためにもコンテストマップは必須だと思う。
つなぎ目には脆弱性が潜みやすいので。
・コンテストマップがあること
・１次リスク、２次リスク、３次リスクの因果関係マップ
の２つがセットであることによって、
定性的にでも各信頼境界において、どの程度のトラストレベルが最低限必須なのか？
も判明しやすい。
ビジネスサイドを巻き込んだ継続的サイクル
また継続的にこの実験は繰り返さなくてはいけない。
BizSecOpsとはまさにそういうことだと思っている。
「こんな脅威は絶対に起きてほしくない。なぜなら～」という目的から考える。
目的に対してたいしてインパクトのない脅威なんて向き合うだけコストの無駄だ。
セキュリティテストでは、すでにチェックする対象領域が分かっている。
一方でカオス実験では、新規の洞察やまだ知られていない情報を集めようとするもの。
問題のある主論点となる部分を継続的に探しつづける。
このサイクルが回っているとチームのセキュリティの成熟度は高いといえる。
セキュリティカオスエンジニアリング
以下のチームは互いに密な戦略的コラボレーションをしなくてはいけない。
実際の災害時を想定した訓練の仕組身がどの程度有効なものなのかを継続的に学べるようにするという狙いがあるからだ。
下記の×印には、各チームの陥りやすいアンチパターンな行動を示す。
Redチーム
攻撃する側の立場のチーム
Blueチームが取りこぼしている重大な脆弱性を発見する。
より広範囲の脆弱箇所を見つけようとしてしまいがち
Blueチームを出し抜くことが目的と化してしまう
これは出し抜くことでインセンティブが入るという評価制度であったりすれば起こってしまう現象でしょう。
また
悪意のある攻撃者や行為というものに注目し、システム自体の脆弱性(組織構造というシステムも含む)に関心がいかない
これは完全に、
自分たちでコントロールできる変数であるシステム自体の脆弱性に向き合わず、
コントロールできない実質定数である外部要因を頑張って調整しようとしている試みです。
これはRedチームだけでなく、あらゆるロールの人が陥りがちなことです。
何が変数で、何が定数扱いなのか？
そして「前は変数だったけど今は定数」といった
時間経過に伴う変数か定数の変化にも目を光らせましょう。
こういったマインドの話は、識学の 「数値化の鬼」という書籍にも出てきます。
是非読んでみてください。
Blueチーム
上記のRedチームの攻撃から身を守るチーム
Redチームからのフィードバックをもとに守りとしてどこに重きを置くのか？を考える。
すべて防御しようとしがち
本当に大事なのは【選択と集中】です。
すべてを守ろうとするのは、結果的に何も守れていないことと同じことです。
これはバスケで守備を主な責務としていた自分もよくわかります。
超大事な思考プロセス(我流)
RedチームでのモデルをもとにBlueチームの戦略や戦術ワークフローを検討しますので、その際Redチームの戦略などはBlueチームにとっては【定数扱い】です。
昔、数学で「その定数がa>0であればこう。a≦0であればこう。」
といった感じの場合分けを解答で考えないといけない例を何度か見たことある人がいると思います。
これと同様の考え方で、
「相手(Redチーム)の戦略指標がこうであれば、自分達(Blueチーム)はこの戦略を取り、
戦術としてこんなワークフローを取る。」というように考えます。
あくまでも相手の戦略などはコントロールできない定数扱いで、
場合分けによって自分たちのケイパビリティなどの変数としてどの程度求められるか？を考えるのです。
そして、このBlueチームのモデルをもとに再度Redチームで同様にして、
今度はRedチーム側の視点になって、Blueチームを定数扱いにして同じように考えます。
このサイクルを回し続けることで、定数の値が未知数であるものを中心に優先度付けて、
自分たちでコントロールできる変数をどの程度調整したらいいのか？を継続的に考えます。
以下、バスケの話がガンガン出ます。
すべてのボールをリバウンド取ろうとしたりすることは、無駄に体力を消費することにも繋がります。
それに過剰なリバウンドファウルをもらってファウル貰いまくっては意味がないです。
退場となるのは、ある意味自分というリソースが欠けることを意味しますので。
こんな感じで、このカオスエンジニアリング思想は、
自分がバスケ時代に1on1なり、チームに分かれて練習する際にやっていた攻防と全く一緒の考え方でもある。
バスケ試合を例に
たとえばトーナメント票が出るまでは、どこの競合と当たってもいいように、
再利用性のあるケイパビリティ部分を継続的に練習しておく。
またチームに強者がいようとも、
「仮にこのメンバーが5ファウルをもらって退場になったら」
「もしも怪我をして思うようなパフォーマンスを発揮できなかったら」
「２日試合が続いて、スタメンの能力が本来の半分も出せなかったら」
という考えられる最悪なシナリオを想定しておいて、
その際に素早く回復させて勝利するためにはどうすればいいか？
または最悪「スタメンや強いメンバーが回復しなかったら」ということを事前に想定して
日々トレーニングをする。
トーナメント票が出たら、事前にマネージャーなどが下調べしていた相手の性質、
つまり強みとするケイパビリティと、その裏にある脆弱性に対して
もっとも守備と攻撃のバランスをどう調整するのか？をシミュレーションしておく。
その上で試合当日になったら監督やマネージャーは試合の全体像を俯瞰した上で、
再利用性のあるもともと継続的に磨いていた部分以外のメインの論点、
つまり現状の相手の脆弱性をつくのに適した自分たちの強みと、
自分たちの脆弱性の守りを固めるために適したリソースは誰なのか？
を継続的に考え続ける。
ハーフタイムなどで戦略の切り替えを選手たちに伝えていると考えれば、
無意識に自分たちはカオスエンジニアリングを身体で体感してきている。
汎用的に使える思想
これは他の場面でも使える思想だが、ドメインサービスを開発する人々が見たことある、
SOLIDなどの設計原則の思想が結構セキュリティ面においても使いまわせる。
不確実な攻撃者からの狙われる箇所を局所的にするという【開閉原則】ぽいものや、
継続的なフィードバックループによる変更のしやすさですとか。
あと、インシデント起きた際の容易に原因箇所を特定できるようなログを取れるか？とかにも。
ボトムアップからもInformationビューへ反映
UAFではビジネスアーキテクチャのInformationビューにて、データになる前のたたき台としての情報を考えるようにしています。
システムを使って集めるデータなのか？
ヒト系でアナログに集めるものなのか？
といったことは、OperationalビューのInformationではまだ考えません。
Resourceビューではヒト系かデジタルかの区別をする層なので、
ResourceビューのInformationで定義された情報群が、
ドメインモデルの土台となる、情報モデルのWhyに相当します。
Informationには、具体的なエンティティの属性などは定義しません。
あくまでも業務の流れの中で必要なエンティティなどのラベルだけを定義します。
その際にも、まずはステークホルダーにとっての価値を起点に情報観点の要求を抽出します。
障害時の情報として何が求められるかを考える際にはどうしたらいいでしょう？
リスクポイントの高い問題が発生したことを想定したシナリオを考え、
次にステークホルダーがどんな行動をとればいいのか？を速やかに考えられるよう、
その人が求める※【必要十分な情報】を速やかに届けなくてはならないです。
その際最初は仮説ベースでInformationにて考えていた「きっとこんな情報が必要であろう」というものをカオス実験室での実験を通して検証しなくてはいけません。
・本当にその情報だけで意思決定するのに足りるのか？
・情報に不足はないけど、余計な情報も混ざっていて意思決定の邪魔にならないか？
この２つを検証しなくてはならないのです。
GQMワークショップ
情報を集める際には、道具となるデータが必要になります。
どんな情報、どんなデータが必要か分析
GQMワークショップと同じノリで、対象の情報をステークホルダーに無事に届けるのに必要なデータを過不足なく考えます。
ここですでに検証が、２種類あることがお分かりかと思います。
①欲しい情報を集めるためにデータは必要十分か
②その情報は意思決定に必要十分か
の２点です。
これでまずは機能的な情報、データを定義がいったん完了です。
ただし注意したいのは、意思決定のためにより効率的な情報が他にもあるかもしれません。
そして対象の情報を集めるのに、より少ないコストといった よりベターなデータがあるかもしれません。
それを継続的に探索しなくてはなりません。
それだけは忘れてはならないことです。
データの品質を考察
今度はデータ品質を考えます。
検証を通してそのために必要と思われたデータが意味をなさないことや、
集めるのにとても時間がかかるといったことなどが明らかになれば、
そのフィードバック内容をInformationへボトムアップ式に反映させます。
それによって当初のInformationに求められる品質指標(加工のしやすさや収集するのにかかる時間など)を満たせているかのチェックをします。
満たせているのにも関わらず、意思決定ができないということは情報に過不足ある可能性が高い。
こんな感じで仮説検証サイクルを回しながら、品質面も徐々に精度をあげていく。
大事なこと
「この情報のために必要なデータを集めたり運用するのにめちゃくちゃコストかかる」て判明したら、すぐにBA層のInformationに反映するのです。
丁度下図のようなイメージです。
