背景

以下のイベントに参加してきました。
今回は司会ファシリテーターとして参加してきました。

そこで得た新たな知見や気付きをここに残します。

司会でありながら、マイペースに登壇した方にがつがつ質問させていただきました。

クラウドエース

なぜSIerで脅威モデリング？

多くは開発者　であり現場からすると要求が抽象的でどう対応したらいいかわからない。

開発現場とセキュリティ担当でやりたいことがズレている。
リスクへの解像度の差や感度に差がある。
リスクへの認知領域の差が理由。

このギャップを埋めてくれるものとして、脅威モデリングをやってみることにした。
丁度いい運用負荷。

実際にやってみてわかったこと

手法の課題として、かなり細かいこと考えがちで木を見て森を見ず状態になりがち。

ここは過去の脅威モデリングイベントに参加していても感じたものです。
あと、DDDやってるときにもすぐ詳細にはしてつぃまう方は一定います。

これらを解決するためにEBIOS Risk Managerを参考にした。

攻撃パスを考えてから、具体的シナリオモデルを作成

　各抽象度に応じてリスク方針が固まる　抽象から具体までの脅威モデリング　DDD×脅威モデリング

　アウトプットの利用例
　　保護が外れるようなボトルネックもどきな部分に集中できる。

(Q & A
運用の組み立てに困ってるとこに脅威モデリングを支援する形で入った。すでに困ってるとこにやって、最初の０のとこ(速さ重視のとこ)にはやってない。

エビオスによっての効果や負荷は？
→負荷は上がる。意味のあるアウトプットを行うためには前段の投資が必要。
導入するにあたってどう使える状態にキャッチアップした？　STRIDEでうまくいかないと判明した時点で
セキュリティバイデザイン指南書などを参考にした。

チェックリストの方が効率的になる部分は？使い分けのやり方。
チェックシートは個々の固有のドメインではない汎用部分へのリスク対策として　工数かかるものなのでイシュー部分のみ
テンプレート箇所はあえてやらない。

解像度の低い資料しか開発サイドから出てこなかった。どのようにインプットしてるか？
インシデントをつくる
困っているところに導入する。

脅威モデリングのための事前準備は？
どのくらいの工数が必要？　規模によるがそんなに大きくはない。半日かからないくらい。
リード側があらかじめやっておいてから半日ワークショップ。　３、４時間モブ脅威モデリング→半日ワーク

どういう体制でワークショップ？
２人がイネイブラーになって、ストリームアラインドに対してサポート　ロジカル＆クリティカルファシリテーションを行う

脅威モデリングにおける失敗とは

個人補足) クリティカルシンキングで前提の信頼境界位置の検証を必ず行うことって思ってる。

・脅威モデリングの理想形

・脅威モデリングやるにあたって何が失敗？
モデリングするときの撤退条件をやる前に決めておく。

ビジネス方針の取り決めを行わない状態でのモデリング
チームビルディング　評価観点の偏りが起こりやすいチームにしちゃうとか

価値の循環のための循環モデルが理想形

明文化されずに特定のチームにとどまってしまうのは失敗であり、組織のナレッジにもならない。

セキュリティエンジニアに意見が左右されてしまうと逆にチームに対して脅威モデリングがマイナス作用してしまう。

「各面で多角的評価を行うことでどのくらい成功したのか？
各面でわかれてることで、どこの部分が自分たちの脆弱さがある部分化が明確になると感じた。
脅威モデリングの工数つめよ！と」

セキュリティ対策のDRY原則違反とかもツール面における失敗としてある。
再利用されずに無駄がたくさんでて、セキュリティ軸での技術的負債が大きくなってしまう。

プロセス面における問題として、実施タイミングによっては点と点がつながらない。あらゆる箇所で行うことでサイクルが回りやすい。

競争優位性を脅かす部分に対してのみ行う。

RDRA×DDD× 脅威モデリング　×ICONIX　×OODA思考

ADR的にモデルの意思決定を残しておく。あとはアジャイルモデリング
脅威モデルの軌跡をアジャイルモデリング原則に沿って残していく。ADR的になる

それがデータマネジメントのピラミッドと対応した　メカニズム運用にも繋がってくる。

脅威モデリングワークの振り返りに使える

脅威モデリングワークショップの最後の振り返りで、なんでうまくいかなかったのか？の原因解析にも循環モデルが使えそう！　という話を阿部さんと小笠さんとしてきました。

逆になぜうまくいったのか？というKPTでいうところの、Keepになる行動習慣も浮き彫りにしやすいとも感じました。

さらにこの循環モデルは、脅威モデリングだけではなく、
ドメイン駆動型で行った際にできた業務モデルやシステム内のドメインモデルを通しても
再利用できそうな考えだと感じた。

組織に持ち込む脅威モデリング

概要

これから組織に持ち込むためにワークやったという話でした。
脅威モデリングをいきなりセキュリティ側が率先して開発組織に導入は無理だから、こうしたらいいよという工夫。

なぜどうやって組織に脅威モデリングを持ち込むのか？

背景

脆弱性診断かけたら全体の7割くらいのシステムに脆弱性ありであった。
その内容のほとんどはチェックリストに書かれていたのにも関わらず。

本来の脅威モデリングの理想形

最小限の労力でセキュリティ対策実現のために脅威モデリングがある。
セキュリティコストの選択と集中ということ。

やれる仕組みが５個あってそのうちの1つが脅威モデリングという立ち位置。
開発者自身が脅威を考えられるように

主観：チェックリストプロセスについては、ECRSが適用できそう。間違いなく。

組織に脅威モデリング持ち込むための戦術

無理に脅威モデリングを導入すると、ただめんどいプロセスが組み込まれることになるので、じわじわ浸透させる。
チェンジマネジメントのADKARモデル　を採用した。　セキュリティへの意識改革

・約３０名集めて、２時間開催　
基礎力向上のために、あえて超シンプルな架空のシステムを題材にした。

脅威モデリングはセキュリティ担当ではなく、開発者が率先して行うことの方が〇(×〇表)

必ずと言っていいほど、議論が止まるときが来るので、ワークが止まったら生成AI使ってプロンプトを提供し、また議論に戻る　というようにした。

チェックリストと脅威モデリングは補完関係にある。
チェックリスト項目と要求のマッピングが開発者目線では難しい。腹落ちのためにの脅威モデリングでもある。

・結果　気づき
脅威の洗い出しの後に、すぐに対策に行くのではなく、脅威の具体化の時間を設けた方がいいかも。

STRIDEだけでは粗い内容なので、MITRE　で具体例上げてみる。

脅威モデリングを行うことで、共通基盤のやってくれる対策、やってくれない対策の理解に役立ちそう。
オンプレからクラウドに移行する際に、構成がガラッと変わるから変更箇所に特化して脅威モデリングを行う価値がありそう。

DFDの方を見てるチームの方が具体的かつ数多くの脅威を洗い出せたので、DFDを中心としてモデリングを行う方がいい。　セキュリティにおける関心の分離を行っている

・次のステップ
４月以降に実システムで試行を予定

実際に脅威モデリングをやってくれた時のインセンティブ設計も必要。←面白いと思ってもらってもその方が実際にはめんどくさがってやらないから

マトリクス図でどこは外部委託していいかっていうのを明らかにして、外部ベンダーと協力して脅威モデリングを行う。

Q & A
どんなベンダーがいいと思うか？
脆弱性診断されている方々が望ましい。いかに脆弱性をシステムにマッピングしていくか？が大事だから。

ファシリテーションは自社で行って、ベンダーに知見を借りるってする。でないとベンダーさんにやってもらう脅威モデリングになっちゃう。

今回はどの辺の肩を中心に行ったか？
　各開発部などの部門から代表者数名を選定してまんべんなく社内勉強会をやっているので、全社向けな勉強会になってる。
　できれば親会社の開発者チーム（業務要件握ってる人）には来てほしくて、共通基盤の人々は呼べない。そこはセキュリティ担当がある程度抑えてるから。

社内政治との相関関係をみて脅威モデリングを行うことが重要