背景
案件でシステムオブシステムズという複数のシステムを連携した全体のアーキテクチャを扱ってきた。
その特性上、単体システムでは存在しなかった脆弱性などが必ず発生し、
セキュリティを超重視視して考えないといけないものに入っていたこともあり、
去年からちょいちょいOWASPのイベントやゼロトラストのイベントに参加してきた。
その中で具体的な実装スキル以前に思考として必ず持っておくべきものが、
自分が去年からめっちゃ読んできたビジネス書と関連づいて、
「ああ、こう考えるのか」という汎用的思考プロセスとして徐々にまとめってきた。
今回はそんなセキュリティ要件を考える際に大事な、リスクベースアプローチに必要な思考を一通り列挙する。
必要な思考一覧
私はこのリスクベースアプローチのスキルを上げるためっていうのもあり、
去年から以下のスキルをセットで上げることをしてきました。
脅威モデリング
OWASPでは主に脅威モデリングのワークショップでは、
DFDデータフロー図における脅威を発見するという際に、
このモデリングをSTRIDEなどのフレームワークを用いて行っていますが、
ぶっちゃけた話、プロセス面の業務フロー図における脅威分析も大事ですし、
プロジェクト遅延などの脅威というビューでも使える汎用的な可視化手法です。
後述のTOCなどとセットでお使いいただくことにより、
無駄なコストをかけずにもっとも重要なリスクを見つけやすくなります。
そうすることで、対象領域全てに対してゼロトラストを実施するのではなく、
戦略的に重要部分にのみ選択集中してゼロトラストを実施する計画も立てやすくなります。
便利なフレームワークを使った脅威モデリングは以下の記事をご覧ください。
視点の切り替え
セキュリティ＝f(外部の脅威 , システムそのものの脆弱性) という大事な関数がある。
すべての脅威に対して対策を立てるのは無理だし、コストの無駄遣い。
そこで
①悪意ある攻撃者や、悪意なくシステムトラブルを引き起こす外部要因
②自分たちの構築した仕組みそのものの脆弱性という内部要因
の２つに分解して両方考えられないといけない。
②は自分たちでコントロールできる変数である。
チーム全体でスキルを成長させたり、優秀なセキュリティエンジニアをビジネスサイドからアサインさせてBizSecOps体制を組織の常識とするなどしていかんようにも底上げできる。
(勿論、コストとの兼ね合いがあるが)
しかしながら①に関しては、自分達ではコントロールできない変数である。
悪意ある攻撃者どもがどんな攻撃をしてくるのか？は、
セキュリティエンジニアさんたちが詳しい【攻撃する側】の視点になって考えないといけない。
そして自分たちはそれに対する【守る側】の視点になって考えないといけない。
この使い分け、内側と外側とを行き来する思考が必須になってくる。
内側から考えるのはボトムアップな思考プロセス、
外側から考えるのはトップダウンな思考プロセスに近しいものを感じる。
ちなみにこの外側と内側の視点の切り替えは、
利用者目線のサービス全体の品質と、システム内部品質という行き来でも必ず使う。
利用者の求めていないサービス品質をいくら内部で改善しても意味がない。
攻撃者の主な関心の整理は後述の論点・目的思考と組み合わせて考える。
個人的にはこの視点の切り替えの際に、無意識にできるようになるまでは
クリティカルシンキングを意識して使うようにすることをオススメします。
そうすることで自分たちの視えていない脆弱性の発見にも貢献します。
TOC
制約理論のことで、ボトルネックになっている所のみに注力せよって思考です。
全体が最適化されていないからという理由で、各工程を最適化してもコストの無駄遣いになります。
これは品質改善においても同様な考え方です。
プロセスの流れの中で滞っているがゆえに、全体としての流れが悪くなっている部分のみに注目し、そこが細くなってしまっている原因を仮説ベースで解明し、そこに合わせた方針を立てなおします。
さらにそれは一度で終わらず、次はまた別のボトルネックが発生します。
継続的にサイクルを回す中でどんどん仮説の精度が上がっていき、
もっとも全体へのマイナスインパクトの大きいリスクが明らかになってきやすい。
そこフォーカスを当てて、そこの改善としてどの品質に向き合うべきか？を考えます。
このTOCはパフォーマンス面のボトルネックを特定したりする際にも、
他の品質やプロセスの流れの中で滞っているがゆえに、全体としての流れが悪く大切なものですので、
是非ともものにすることをオススメします。
論点・目的思考・仮説思考
攻撃者視点でのトップ目的から逆算して考える【アタックツリー】というものがあります。
この目的と手段の階層モデルを作成する際に、論点思考と目的思考がセットで必須になってきます。
最上位目的からSLAP原則に従って、【※単一目的となるよう】分割していき、
「各小目的は何だろうか？」→ 「きっとこんな攻撃をしてくるであろう」
という仮説をで攻撃者になったつもりで立てていきます。
その指標は最初の段階では定性ポイント的でも大丈夫です。
SLAP原則・・・抽象度を揃えよという原則
このツリーをもとに継続的に内側でどのようにこの外的要因に対して守るのか？
を同様にして
「こんな脅威から身を守りたい」という目的に対して
「そのためにはどんな手段があるのか」という構造ツリーを考えていきます。
勿論その際に優先順位を考えなくてはいけません。
なので下図のリスクマトリクスをここで用いて定性評価をした上で、優先度の高い脅威のみに対するディフェンスを考えます。
もちろんその際には実際の経験を踏まえた仮説をベースにしてマトリクスにプロットして評価します。
それを継続的に行いながら、実際に起きた問題の事実データと照らし合わせて、
検証のフィードバックを反映させた最新のマトリクス状態にしておくのが望ましいです。
その評価の上で実際のワークフローモデルやDFDなどを作成し、プロセスとデータの両側面から、もっとも優先的に対処したい脅威に対するディフェンスを考えます。
KPIマネジメント
KRIは、Key Risk Indicatorの略であり、 重要リスク指標のことで、KPIのリスク版のことです。
不確実性が高い領域に関しては最初から指標管理する必要はないです。
まずはざっくりとした定性的な指標からで充分でしょう。
その上で、何度かサイクルを回す中で徐々に指標化した方が良くなってきたら
大目的から階層化したKPIツリーを作成し、継続的にモニタリングできるようにしましょう。
ボトムアップ式に前提となる上位指標を変えなくてはいけないこともあるため、
このKPIマネジメントは常に演繹法などとセットで使います。
推論思考
帰納法、演繹法、アブダクションの３つからなります。
帰納法は異なる具体な事象から抽象化して一般法則を見つけるテクニック。
演繹法はテスト設計者の方々が無意識に用いている前提に当てはめて未来を予測するテクニック。
アブダクションはメカニズムを仮説ベースであきらかにするもの。
すべて組み合わせて使います。詳しくはこちらの書籍をお読みください。
これは無駄な手戻りのない要求定義の際にも必須の推論テクニックです。
１次リスク→２次リスク という因果関係を予測する際などにも必ず用います。
まとめ
上記で列挙したのは、あくまでも私が案件の中で意識的に使っていたもので、もっとあるかもしれません。
そして、単体で使用するよりも、セットで使うことの方が多いです。
それは複雑系システムになればなるほど、よりセットで使わないといけなくなると感じます。
応用
先程論点思考のところで
【※単一目的となるよう】分割と記載しましたが、これはSOLID原則の
単一責任原則やinterface分離原則の理解を深めることで、その妥当な粒度の制度が向上します。
セキュリティ面を考える際にも是非とも意識してみることをオススメします。
もしも迷ったら以下のようにシーケンス図をラフでいいので描いてみましょう。
