既存の脅威モデリング実施における 新たな脅威とその対策に必要な思考

Transcript

1. 既存の脅威モデリング 実施における 新たな脅威とその対策 に必要な思考法 ゆめみ ビジネスアーキテクト クドウ ユミ
2. 前提条件の共有 • 前置き • 前提知識 • 誰に向けてなのか? • どうなってほしいのか? • 何を伝えるのか? • 私の根底価値感 2025/8/2
3. 前置き これから話すことは、今まで脅威モデリングワークショップに参加しながら、周りを観察していく中で、 「ここ、もっとこうしたら議論が変に発散しなくて済むんじゃない?」 「え、その描き方、多目的になってるから、、、すんごい見づらい 」 「そもそもペルソナ像や事業の特性、全員の認識って揃ってるの? 」 というワーク中のモヤモヤから得た、 今後、脅威モデリングの質・効果をより良くしていくためのポイント です。 決して、ディスってるとかじゃない! 2025/8/2
4. 前提知識 因果ループ図 推論、演繹法(別名、三段論法) といった用語が出てきます。 これらは、脅威モデリングで暗黙的に使われてる。 推論は、右の書物か、4月の私の登壇記事を参照ください。 https://www.slideshare.net/slideshow/ai-_2025_04_22_- pm-pptx/278268943 2025/8/2
5. 誰に向けてのメッセージなのか？ 前提として、 すでに脅威モデリングできる人。 その中で、右図の上２つの層に向けて。 2025/8/2
6. どうなってほしいのか？ 2025/8/2
7. 私の根底価値観 セキュリティ対策が、以下のようなことを生んではダメ。 開発スピードを遅く・エンドユーザー目線でも利便性を悪化させてしてしまう その結果、開発と運用の間に分断を生んでしまう これでは、セキュリティが害悪になりかねない 理想形は、以下のような状態。 安全至上主義ではなく、機能性やビジネス性を高める一つの手段として安全性を決める 2025/8/2
8. 何をメッセージとして伝えるのか？ STRIDE PASTA DREAD などの既存の脅威モデリング手法への改善点。 新たな副作用があること。 2025/8/2
9. 既存の脅威モデリング手法の先に 別の新たな脅威はないのだろうか？ これが、今回の最大の問い です。
10. 自己紹介 所属:某ゆめみ 職位:ビジネスアーキテクト、PdM 脅威モデリングの扱ってきた領域:  大規模エンタープライズのSTAMP/STPA、CASTなど安全性分析  がちのやり合いの防衛案件での組織設計 好き:赤ちゃん 、モデリング、推論、抽象化、こう見えてお勉強＆すぐ実践 趣味:抽象化して他の文脈とつなぐこと、常識を疑い破壊すること マジ嫌い:歩道を走るチャリンコ、うるさい選挙活動  論外:たまに「どけよあぶねーだろ」とかヌカス奴 もちろん、、、 2025/8/2
11. 2025/8/2 脅威モデリングとの出会いの時系列 2022 年11月 防衛案件etc案件に入る。 初のアーキテクト案件 2023 年5月 品質を考慮する際にリスクベース で考慮した方がいいと気づく。 2023年7月末 脅威モデリング初対面 「DDDっぽい!」と感動 2023 年10月～ 脅威モデリングの考えを 案件に取り入れてみる 2024 年 2月 チートポと無意識に組み合わせて 使っていて効果を感じ始めた。 価値を支えるものとして 脅威モデリングという価値観 品質シナリオは脅威ベースで考察
12. アジェンダ ① コンテキスト思考 ② モデリング対象範囲の絞り込み 未完 ③ リスク緩和策実施後の新たな脅威 ④ まとめ ⑤ 今後の展望 2025/8/2
13. コンテキスト思考 2025/8/2 文脈の共通認識を揃えよ!
14. コンテキスト思考 の3Sの説明 • 施策を実施前の状態 • 他視点文脈を図解すれば共通認識 が取りやすい • コンテキスト思考を構成する3S • ①コンテキストマップで環境の可視化 • ②コンセプト記述で価値観の可視化 • ③バリューグラフでビジョンの可視化 2025/8/2
15. 施策を実施前の状態 ワーク中にあれもこれ脅威分析が否めず、論点もチームで揃ってないことが毎回 攻撃者の目的や、守る側の死守したい資産も、共通認識が毎回ズレてしまう DREAD評価は主観と言えども、明らかにチームでズレまくっていた 「え、、、なんかセキュリティ文脈の人たちで、共通認識が勝手に取れてる?」 という置いてけぼり状態 2025/8/2
16. 他視点文脈を図解すれば共通認識が 取りやすい 自社 サービスを利用する悪意のないエンドユーザー 悪意のあるユーザーつまり敵 のそれぞれの視点でコンテキストを考察する。 これによって、 エンドユーザさんが、実際に守ってほしいもの 敵が実際に価値を感じて盗もうとするもの の理解が圧倒的に向上するのでは、と考えた。 2025/8/2
17. そこで コンテキスト思考を構成する3S コンテキスト思考を使って、3つのSの側面で文脈を多面的に捉える。 Surroundings（環境）:いま置かれてる状況 Soil（土壌）:環境に左右されない自分たちの価値観、自分軸 Sun（太陽）:目的ビジョン、なりたい姿 (※売上を2倍とかは目標で目的ではない) ※背景に関しては、原因と結果を表すモデルの話を過去にしているので、 そちらを参照ください。 https://www.youtube.com/live/hTc_3B7CZIk?si=hlbAZfklEshp29Lf 2025/8/2
18. ①-aコンテキストマップで Surroundings(環境)の可視化 2025/8/2
19. ①-bコンテキストマップで Surroundings(環境)の可視化 たとえば、自社の事業環境を表すものとして、 プロダクトライフサイクル中のいまどのフェーズにいるか? 既存顧客はどの程度付いているのか? 従業員数とスキルレベルはどの程度か? 今手元にあるお金はいくらか? といった各論点に答えることで、 環境の認識のズレを最小化できる。 2025/8/2
20. ②コンセプト記述でSoil(価値観)の 可視化 前提条件: ターゲット顧客の現在の環境を可視化してること その上で、ターゲット顧客の脅威を抽出していること 「私たちは誰々(ターゲット顧客)の抱える～～という脅威を解決する」 というコンセプト記述式で書く。 参考元:事業構想を書くの【事業構想フレームワーク】より抜粋 2025/8/2
21. ③バリューグラフでSun(ビジョン)を可視化 前提条件:①②の図が完成してること 各資産に対して「なぜそのデータを守りたいのか?」と 上位目的を抽出していく。 攻撃者目線なら、「なぜそのデータをつつきたいのか?」 と上位目的を出す。これをもとにAttackツリー作成可。 サービスを使う側の視点と攻撃者の視点の2つにわけて、 このバリューグラフを定義しておくと、 どの悪意行動を最優先で監視すべきか?が明確になる。 2025/8/2
22. 実験の効果 • 3月のワークの成果物 • 実際の効果 • この発見から得た更なる仮説 2025/8/2
23. 3月のワークの成果物の一部 3月の脅威モデリングワークショップで、 右図のような サービスを提供する側のコンテキスト サービスを利用する側のコンテキスト をストーリー形式で共通認識揃えてから、 STRIDE分析に入った。 ※今考えると、図の文脈では脅威モデリングを実施しなくてもいい導入 フェーズだけど、、、 2025/8/2
24. 実験の効果から得たもの 主張:3Sフレームワークを用いてることで、以下の効果が得られるはずだ。 どの情報資産を守るべきなのか?の優先順位付けで迷いにくい DREADの評価も、より明確な根拠をもって行える 敵の文脈モデルがあることで、アタックツリーを描きやすい 根拠:3Sを取り入れる前後で、STRIDE分析で悩む時間が約1/3まで減少。 最初に議論に時間を他チームより割いてはいたが、後から回収できた。 メンバーのスキル要件が異なるという差分はあれど、この雑なA/Bテストで効果を肌でも実感した。 ※まあ、ただまだ根拠が浅いのは否めないので、今後のワークで皆さん検証を重ねてください。 2025/8/2
25. この発見から得た更なる仮説 新たな仮説: 3S情報をさらに絞り込むことで、DREADの評価も迷わなくなるはずだ セキュリティログとして、何を監視すべきか?が定義できるはずだ 脅威モデリングの対象範囲の優先度付けを明確にできるはずだ 理由:自分と相手側(敵)の両方の立場の文脈情報が、より明らかになるから。 薄めの根拠: 土壌と太陽情報のみでも、DREADのD・Aの絞り込みはスムーズにできたから。 どの資産を最優先で守らなあかんのか?がより明確になったから。 2025/8/2
26. チラ)コンテキストマップを描く 脅威モデリングの最も優先すべき対象箇所は、 ドメイン駆動設計の中核領域。 その中でさらに優先順位をつける。 これだけで1時間話せるから、 次回話すね! 2025/8/2
27. モデリング対象 箇所の絞り込み • コンテキストマップ • 制約理論 2025/8/2
28. ドメインモデルと脅威モデリング データ境界 2025/8/2
29. どこに注力するのかを定義 セキュリティ上もっとも弱いと思われる所を選定する。 CIAのトレードオフは意識 図あった方がいいかも この際に参考になるのが、制約理論です。初回の脅威モデリングでは、制約は意図的につくるもんです。 何を強めたいのか??そのトレードオフの副特性 2025/8/2
30. トレードオフを把握する この後につづく、脅威分析を注力して行う箇所特定のためには、 セキュリティを構成する、品質副特性同士のトレードオフを把握しないといけない。 どんな情報資産をどの副特性軸で死守したいのか?というコンテキスト分析が浅いなら、 先ほどの工程に戻る ストーリー式にして、定性的な重みづけを行う 2025/8/2
31. リスク緩和策実施後 の新たな脅威 既存の脅威モデリングの脆弱さ 2025/8/2
32. 脅威モデリング後の新たな問題 ① STRIDEで脅威分析する ② アタックツリー作成する ③ DREAD評価でイシューリスクを特定する ④ イシューリスクである、ハイリスクへの緩和策を考える ⑤ 対策を適用後、リスクがどの程度下がるか?予測する この後に、すぐにリスク緩和策を実行する 、、、、、、、しないですよね? もちろん。 当然他に考えるべきことあります。 はい、なんでしょうか? (挙手 クイズ) 2025/8/2
33. 安全性の追求の先の脅威 組織には、 人・設備系リソースのできることの制約(ワークロード) どれだけお金・時間があるか?の制約(経済性) があります。 どれだけ、安全性を高めたくても、 常に右図の他２つの項目への影響を考えないといけない。 (図の引用元:オライリー カオスエンジニアリング) 2025/8/2
34. 1月の登壇内容の復習 2025/8/2
35. 経済性の脅威 DREADで考えたリスク緩和で安全性を追求 かつ 従業員労働時間などのワークロード制約を追求 上記２つを追い求めると、経営破綻の脅威が浮上する。 2025/8/2
36. ワークロードの脅威 DREADで考えたリスク緩和で安全性を追求 かつ 企業のお金の制約を追求 その結果、 従業員にとって過剰な労働による健康状態低下 それでいて安い給料 →エンゲージメント低下→離職 →リソース損耗という脅威が浮上する。 より詳しく見てみましょう。 2025/8/2
37. ワークロードの具体例) 従業員への健康リスク 2025/8/2
38. 過重労働における法律違反の脅威 2025/8/2
39. 負の因果ループ図 前提条件:推論の演繹法を使って原因と結 果の連鎖関係を描く。 安全性の要件と お金の制約のみを意識しすぎた結果、 結果的にワークロードが悪化し、 経済性も安全性も満たせなくなる。 結果的に、セキュリティ要件も満たせなくなる。 2025/8/2
40. ようはネガティブ・ブランチを描け 何かを実施すれば、必ず副作用が生まれる。 それを図解で事前に予測しておくこと。 運用要件を最初の段階で考えておくとかも 実はこの図をベースにすると良き。 当たり前に推論が使われてるので、 推論を常識にしといた方が良き。 2025/8/2
41. 3柱のバランスを満たすのマジ大事 DREADで対策するにしても、 必ずお金やワークロード制約の観点からの 評価を批判的にかけた上で、 できる策を実行する。 よって、右図の案②は秒で却下。 実行後の3柱への影響を 因果関係で事前に必ず出しておく。 2025/8/2
42. セキュリティ戦略ロードマップを 前提条件ツリーで図解せよ セキュリティ含む安全性の要件の水準を上げるためには、 現状の従業員の労働面の余裕 会社のキャッシュ に対する相互作用を右図のような図解で表現し、 ロードマップの共通認識を合わせないとマジダメ 当然、スクラムとの相性良きだから、 3月の阿部さんの内容、金原さんのアジャ脅と相性良き。 2025/8/2
43. 正の因果ループ図を描く 2025/8/2
44. 負→正への循環になる場所を探す 2025/8/2
45. らせん状に軌跡を描く 細かい範囲で正の循環をしながら、 ロードマップを辿っていく感じ。 小さくセキュリティ水準を上げた際の、 ワークロードと経済への影響を考えながら、 ロードマップを辿っていけてるか検証する。 これがセキュリティアーキテクチャの進化の軌跡となる。 2025/8/2
46. おすすめのパターン PL曲線とセキュリティにかけられるお金は密に関係する。 ① 導入期: ワークロード、お金の制約という力学が強いため、 後から実現可能なセキュリティ水準を考慮する。 ② 成⾧期～成熟期の峠まで: 先にあるべきセキュリティ要件を考えて、後から振るいにかける。 ③ 成熟期:さっさと事業辞める 2025/8/2
47. まとめ と今後の展望 • 今日のまとめ • 今後の展望 • イベントの宣伝 2025/8/2
48. 今日のまとめ 自分たち サービス利用者 攻撃者 3つの視点それぞれの文脈を3Sで図解し、 共通認識合わせると、 脅威モデリングがかなりスムーズに行える。 リスク緩和策を仮に実施したと仮定し、 その後の 企業のお金 ワークロード への副作用を原因と結果のモデルで表現する。 安全性とワークロード、お金の3つの相互作用を 監視せよ! 2025/8/2
49. 今後の展望(この中から次回発表) ドメイン駆動と脅威モデリングの合わせ技→モデルの変更がしやすい 継続的脅威モデリングを行うべき対象箇所の特定 マイクロサービス化検討時の分割することによる事前の脅威モデリング  マイクロサービス化で失敗してる事案では、100%これをやっていない 分析系のデータアーキテクチャ(特に分散化されたデータメッシュなど)に対する脅威モデリング 変更が行いやすいセキュリティアーキテクチャ実現のための設計思想と原則 得た侵入ログをもとに、データ駆動型の継続的脅威モデリング データ利活用×脅威モデリング ← これ、脅威インテリジェンスのことじゃね?  起きてしまった具体な障害の情報から共通メカニズムを帰納法で抽出  推論による、脅威の予測 2025/8/2
50. 制約理論(別名、TOC) 概要:もっとも弱い部分で全体が決まる という考え方。 そこ以外強めても無駄ってこと。 TOCの他の事例: パフォーマンス上の改善 PJ中の作業進捗管理手法のCCPM 開発リードタイムが最も⾧いモジュールのリファクタリング ただし、ボトルネックといっても色々あります。 2025/8/2
51. あざす！6/30にBPStudyでついに！ 2025/8/2