前置き

脅威モデリングとの出会いは、去年の7月か8月に埼玉で開催された小笠さん主催のイベントです。
その時は、あまり普段DFDを描いていないことと、Web系サービスの知見があまりないことから、ただ見ているだけでした。

しかしながら、実際に自分が担当する防衛系のDX案件の業務内容が、
まさに脅威モデリングの数々であること、
それだけでなく、私たちが普段システムに暗黙的に求めている保証されていてほしい非機能面が、脅威モデリングベースで明らかにできると回数を重ねるうちに気が付いていき、
それによってデータに求められる品質なども脅威モデリングベースで明らかにできる。
と気が付いてからは、アーキテクチャの検討には、ステークホルダーが懸念点に感じることを脅威モデリングベースで明らかにし、その要求の因果関係を要求(不安要求)分析ツリーで
可視化する体制が必要と感じ始めました。

ただ、まだまだセキュリティ以外の畑では「脅威モデリングなにそれ？おいしいの？」
という風潮が強く感じるために、セキュリティ以外の開発者たちにも布教したくて、
今回のイベントでは、国内の脅威モデリング布教者であるフットワーク軽い小笠さんにぜひお越しいただきたいと思い、声をかけた次第なんです。

日常の脅威モデリング

実は私たちは、日常の中で脅威モデリングを普段から行っている。
たとえば、「空が曇っているから雨降って洗濯物濡れそう。だから今取り込んじゃおう」
とか「雨降りそうだから傘を持っていこう」とか。

目の前で今起きている事実の現象(空が曇っている)に対して、いろんな情報(空が曇っていると雨が降る可能性があるという前提条件)から未来に起こり得る脅威を予知して、対策(今洗濯物を取り込むや傘を持っていく)を立てることで、日常的に脅威モデリングを使っている。

これをもっとシステムを取り巻く環境下で議論しやすくするための思想が脅威モデリング。

脅威モデリングにおける定義

「"モデル"を作成して、脅威と対策を理解すること」

ここでいうモデルとは、アクティビティ図を用いてのミスユースケース分析や、
リレーショナルモデルやクラス図を用いた静的解析、など何でもいい。
用途に応じて適切な図を用いて脅威を特定すればいい。

脅威とは何か

そもそも脅威とは何なのか？
セキュリティエンジニア的な視点で考えると、攻撃者がいることを想定してしまうが、
そのような狭い範囲での意味ではなく、
【ステークホルダーにとって起こると困ること】が脅威。
そのため、システムの停止や値の不整合など起こると困ることはすべて脅威。

TOCの思考ツリーで使うUDEがまさにここでいう脅威に近いものだが、
厳密には違うものである。理由は後述の「脅威とリスクの違い」で明らかになる。

そのため脆弱性だけではなく、システムや情報に起こり得る起こると困ることが脅威。
それをステークホルダー間で話し合って考察していくことが脅威モデリング。

現状の課題点

セキュリティエンジニアだけで脅威モデリングが行われがちなのが現状。
セキュリティの人間だけで脅威モデリングを行ってしまうと、
どうしても「攻撃者がどう」とか「それに対する守りが～」みたいな議論になりがち。
これでは、個別最適な視野における脅威に限定されてしまい、木を見て森を見ず状態。
システム全体という広い範囲で脅威とそれに対する対策を話すべきであるため、

データとプロセスの両側面からの脅威モデリングを開発者たちも交えたステークホルダー間で協力しながら行っていく。そしてそのような組織体制も必要。

脅威とリスクの違い

実は脅威とリスクは明確に分けて考えなくてはならない。
復習だが、

脅威とは、起こると困ること

対して、

リスクとは、発生する可能性やインパクト、どのくらいの影響範囲があるか、
どの程度の再現性があるのか？　といったことを考慮して出たものがリスク。

この２つを明確に分離しておかないと、次の【対策】という工程にいけない。

脅威を洗い出した後で、可能性など考慮したフィルターを通して、
実際にリスクとして考えるのかどうか？　
リスクとして考えた場合の対策コストなどはどのくらいか？
対策に必要なリソースは必要なだけあるのか？　などを考慮した上で、
対策を取るべきなのか？　取らない方がいいのか？　定量評価も交えながら検討する。

つまり、

UDEとは、発生可能性などを考慮したリスクの方がより近いものである。

工程の流れをまとめると、

脅威分析　→　リスク定義　→　対策検討　という流れになっている。
依存関係の向きは、当然前工程に依存する形である。

対策検討フェーズであまりにもコストがかかり過ぎるといったことが判明したら、
前工程のリスク定義に対して、
いまは「コストの制約から、リスクとして認識しないものとする」というように
フィードバック内容を反映する。

脅威モデリングにおける手順

モデルとは、システムを目的に合わせてラフに表現したものである。
一般的な脅威モデリングでは、DFDを用いられることが多いが、
脅威を考察できれば用いる図は何でもいい。
ステークホルダー間でコミュニケーションしやすい図を用いればいいだけの話。

プロセスに関心のあるアプリケーションエンジニアに対して、
見慣れないDFDを見せながらでは議論ができない場合には、フローチャートなどを
用いながらの脅威分析にしてみるとか、状況に合わせてカスタマイズ。

システムを図にして、それをもとにしながら以下の4つの質問をしながら脅威を洗い出す。

どんなシステムに取り組んでいるのか？

取り組んでいる対象をモデル図を使って可視化する。
これはDDDでよく用いる、コンテキストマップなどでもいい。
静的な側面と動的な側面、両方を使って取り組むべきシステムを可視化する。

これは、個人的に聞いていてシステム内部の全体像のデータモデルや、
全体を俯瞰したコンテキストマップや
サービス間連携のフロー図などを必要なだけ用いればいい。

一番いいのは、上図のように4+1ビューで理解を進めるやり方がいいと感じる。

何が起こると困るのか？

上記で理解した内容をもとに、実際にどこで、どんな形で何が起こると困るのか？
6W2Hを意識しながらエンドユーザーなどのシステム外部から見たものと、
メンテする者という内部からの両方で考察していく。

その際に、最終的な完成形として、
エンドユーザーにとって困ることという結果は、システム内部のこんな困ることが原因で起こるといいう因果関係モデルとして可視化する。

丁度以下のような要求分析ツリーのように、各ステークホルダーの関心のある抽象度ごとに
起こると困ることが配置され、その原因がシステム内部のどんな困ることによって起こるのか？を図で共通認識取れるようにしていく。

ここで大事なのは、モデル図を用いてステークホルダー間で議論すること

どう対策を取るのか？

ここで、上記で明らかにした脅威に対して、
・発生可能性
・インパクトの大きさの定性評価
・影響度合い
・かかりうるコスト
などのフィルターを通して、リスク評価をする。

そしてそれに対する対策を考える。
このあたりの考え方は、以下の本にあるイシューの考え方とそっくりである。

本当に対策を取るべきリスクなのか？　実現手段はあるのか？
といったように考えるその考え方は、まさにイシュー考察と一緒。

本当にうまく実行できているのか？

最後に振り返りを行う。上記までの工程はあくまでも仮説の範疇であるため、
本当にリスクに対応できているのか？　
そもそもそれはイシューとして対策の必要なリスクであったのか？
などの検証を振り返りで行う。

脅威モデリングは、あくまでも実物がない状態で仮説ベースで行うため、
机上の空論の範疇でしかない。
そのためこの工程で、エンドユーザーからのフィードバック内容や、ログデータなどから
クリティカル思考なども用いて検証を行うことで、新たな気づきを得られる。

次のサイクルへ

上記の４つのステップを経て得た知見をもとに、もう一度次の脅威モデリングのプロセスへ入ることになる。
この流れは非常にスクラムなどと相性がいい。

また不確実性が高い、ミッションクリティカルなドメインが対象であればあるほど、
市谷さんが提唱している【仮説検証型アジャイル】との親和性も非常に高い。

脅威モデリングのメリット

早期のセキュリティ要件定義可能

セキュアなシステム開発で、脅威モデリングの恩恵は非常に発揮される。
特に、要件定義や設計段階での早期のセキュリティ要件の定義が可能になる。
そのため、不要な後工程のテストコストも抑えられることに繋がる。
なぜならモデルベースで対策したいリスクを定義しているから。

脆弱性診断との比較

脆弱性診断は現物のシステムが必要。
つまり開発をしていないと動くコードないので、脅威モデリングをやらない場合と比較して
非常にコストがかかりやすくなってくる。

ステークホルダー間でのセキュリティの深い理解促進

ある意味、開発エンジニアっぽく言うとDDDモデリングによって、業務理解を促進するみたいなもの。
それのセキュリティという横断的関心の領域バージョン。

役割横断で脅威モデリングは行う

上記でも触れたが、セキュリティエンジニアだけで脅威モデリングを行うものではない。
DDDモデリングなどを用いて業務理解が深まった開発エンジニアなどと、
密にコラボしながら脅威モデリングを行わないと、
攻撃者が～といったセキュリティに関心ある者にとっての脅威にどうしても注目行かない。
そして本当に対策すべきリスクを見落とすことに繋がってしまう。

ステークホルダー間の連携と合意形成

開発エンジニアだけではなく、QAだったり、PM、ビジネスサイドのマーケティングなど
それぞれ起きたら困ることは異なるものだし、その関心の抽象度も異なる。
それらの関係を可視化した上で本当に向き合うべきリスクを選択集中してあぶり出しやすく、しかもそれによってシステムを導入したのに、それによって部門間の対立を深めるという事態を未然に防ぐことにもつながる。

チェックリスト丸投げからの脱却可能

思考停止した、その対策によって何のリスクを防ぎたいの？という状態から脱却。
チェックリストを鵜吞みにしてセキュリティ要件考えても、無駄な脆弱性対策に繋がる。

組織全体で何を本当に向き合うべきリスクとして認識し、それに対してどんな対策を自分たちがすべきなのか？
それによってどんな嫌なことを防げるのか？を継続的に明らかにしやすい。

どのタイミングでも可能

脆弱性診断は現物ができないとできないので、後工程にならないと実行できないが、
脅威モデリングは開発工程喉のフェーズでも実行可能。

できれば前工程で行っておいた方が、無駄な手戻りリスクを予防できる。
なんならビジネス要件とか考えている企画フェーズから導入していた方がいい。

情報を外部公開しやすい

脆弱性診断の結果は、機密情報がたくさんあるため、絶対に外部公開できない。
すべての部分に対策を取っていないケースの方が多いため、
外部からの攻撃を誘発しないためにも外部には絶対に診断結果は公開してはならない。

しかしながら、脅威モデリングの成果物は、外部にある程度公開しても問題ない。
自分たちがどういった形で脅威やリスクを議論したか？というドキュメントになるため
外部公開しやすいという、脆弱性診断結果とは大きな差がある。

これは、システムオブシステムズのような組織の壁を越えたシステム間連携では、
非常に大きなメリットである。

主張 -メリットを発揮するための心得-

上記の恩恵を得るためには、開発者たちが能動的にセキュリティ要件を考えるチームをリードしていく体制が求められる。

チームトポロジーの設計思想による脅威モデリングを協同で行う領域、
独立してそのチーム内で脅威モデリング可能な領域などを明らかにするような体制。
密なコラボレーション連携や、疎なXaaS連携を状況に合わせて使い分けながら、
他チームと一部協同して継続的に脅威モデリングを行わないといけない。

そして、それをファシリテートできるイネイブラーがいなくては回らない。

ようは、文化構築・連携パス設計などの組織づくりと同時並行

バグバウンティング

自分たちのシステムに対して、自分たちで認知できていない脆弱性がないかを
一般の人に見てもらい、バグを発見してくれたら懸賞金を払うという試み。

セキュリティの専門性の高さ×対象システムに対する専門性の高さの２軸グラフ
で考えた際に、重要なバグは意外と図の領域に集中しやすいことがわかっている。

バグバウンティングの懸賞金の高いものは、セキュリティ知見が高い人だけでは見つけられない領域に集中分布している。

そのため、セキュリティ浅い人なども混ぜて多様に脅威を出していくスタイルが大事。

得られた新たな気付き

チートポ × 脅威モデリング

招待LT一発目の米久保さんの発表に合ったチートポ、
そのチームのコミュニケーションパス設計と脅威モデリングの組み合わせによる、
継続的セキュリティ要件と設計。

TOC × 脅威モデリング

ステークホルダー間のリスクの関係性つまり、ステークホルダーマッピングとの
関係性とそれによる、本当に対策しなくてはならないリスクへの選択と集中という
TOC(制約理論)と脅威モデリングの考え方。

ファシリ・思考系 × 脅威モデリング

検証時のクリティカルシンキングを用いてのモデルの検証、
サイクルを再度回す際の新たな脅威を考えるためのラテラルシンキングを用いた
ファシリテーターによる問いかけ。

これらの考え方は、非常にDDDと親和性も高く、横展開できるアイデアも非常に多いと感じた。

既存の設計原則の思想 × 脅威モデリングの相性の良さ

KISSやら、YAGNIといった設計原則。
また、ステークホルダーごとのリスクを抽象度を揃えて階層化するSLAPなど。
リスクも複数のリスクが混在した状態ではなく、あくまでも単一のリスクになるよう
単一責務を意識した設計や、
リスコフの置換原則を用いたセキュリティポリシー設計など。

既存の開発者が通る設計原則の数々が脅威モデリングの方にも横展開できる。
そりゃそうだ。横断的関心事なのか、そうでないかの違いなだけなんだから。

開発者体験品質 × 脅威モデリング

PMさんやEM視点での脅威をいくつか挙げる際に、納期遅延などのリスクをあげ、
それはそのような原因から生じるのか？
チームのモチベーション低下というリスクやその原因分析など。

それらを可視化しておくことで、そのチームの開発者やチーム全体の脅威モデリングを継続的に行うことで得られる体験の品質のデザインなどにも応用できると確信している。
それによって、全体が一体となってより協同的に脅威モデリングに取り組んでくれるだろう。

継続学習する組織 × 脅威モデリング

また、学習する組織を実現するためには、この部門横断的な脅威モデリングの継続的実行
はマストであり、これはDXプロジェクトにおいて必須な手法と言ってもいいと感じる。

書いていて思い出したのが、freeeさんでやっているテストコンポーネントの再利用文化。
あれは継続的な脅威モデリングを恐らく継続的に行い、
自分たちが事業横断的に対策したい共通のリスクというものを明らかにし、
その結果他の事業でも対策手段を再利用しようという文化があるように感じた。
テストアーキテクチャの一部を他の事業でも使いまわせるようにして、
品質保証コストを抑えている取り組みとして、

・事業ごとの固有のリスク対策
・事業横断で共通化されたリスク対策

とに分離し、後者にはテスト再利用パターンを用いる。

こういった設計パターンとの組み合わせが、学習する組織のとして必要に感じた。

私なりの研究補足事項

私は前職でシステムオブシステムズという超大規模なエンタープライズアーキテクチャを扱った経験があるため、そこでの経験と照らし合わせた際に、絶対に組織の壁を越えた脅威モデリングがマストだと感じていた。

というのも、システムオブシステムズでは、独立して運用される個々のシステムが
同じ組織内ではなく、時として別の組織で運用されている。
それらがネットワーク通信などを介して繋がるIoT社会。
そこでは、システムオブシステムズのアーキテクチャを考えるスキルが求められる。

システムズエンジニアリング × 脅威モデリング

１つのシステムにおける脅威モデリングだって結構大変だが、
システムオブシステムズにおいては、不正なデータが時として組織の壁を越えた先にあるシステムと繋がってしまう以上、今まで以上の越境した脅威モデリングの体制が求められる。
しかもそれを一度だけではなく、継続的にアジャイルに。

そうなると、チーム全体でPDCAサイクルを回すだけではなく、
OODAループ志向を用いて素早く意思決定しながら脅威モデリングを継続的に行い、
しかもシステムオブシステムズの性質上、どうしても分散チームで対応しないといけない部分があるため、自律駆動可能な単位でスクラムオブスクラムチームを構築し、適切に連携しながらでないといけない。

そのためには、

仮説思考
OODAループ思考
アジャイルメトリクス
設計原則の理解

などの幅広いスキルセットが各スクラムチームに求められる。

データスペース×脅威モデリング

ある大規模プロジェクトでは、データメッシュの規模がさらに大きい版の
データスペースというものが企画されてすでに動き出している。

しかも動向を見ていると、十分に脅威を考察することなく、
分断された組織体制で行い、分散されたデータプロダクトを連携した際の恩恵にばかり
注目が集まっているように感じる。

既存のシステムオブシステムズが、そもそも適切にコンテキスト境界が切られた設計
ではない以上、当然データプロダクトの境界の位置も適切に議論されているとは到底感じない。
モノリスからマイクロサービスへの移行のように、
本来はデータメッシュも最初はデータを1箇所で中央集権的に管理した状態から、
徐々にコンテキスト境界が明らかになり安定した境界を持つデータプロダクトから
可逆性を担保しつつ小さく分散化していく流れがもっともリスクを抑えられる。