ビジネスアーキテクチャにおける脅威分析

Transcript

1. 業務設計における 脅威モデリング (株)〇〇〇 ビジネスアーキテクト ユミ 駆動(工藤 由美)
2. 自己紹介 遍歴: 得意分野:抽象化、アナロジー、推論 趣味:構造化、アナロジー、パンダ地獄 職位:ビジネスアーキテクト 保有資格:UMLモデリング技能L2、Java言語のなんか 所属コミュニティ:DAMAデータ分科会、脅威モデリング東京(運営) 2025/8/2
3. アジェンダ 大論点 案件の前提条件 脅威モデリングとの出会い～実践 実践後の改善活動 改善後に得た気付き まとめ 2025/8/2
4. 大論点 • お題の概要 • 結論 2025/8/2
5. お題の概要 案件の種別:国防系の案件 何をテーマに話すの?:ビジネスアーキテクチャ上で脅威モデリングを用いた話 詳細:複数の業務システム、および人の集団が複雑に連携し合う、 システムオブシステムズという大規模エンタープライズにおける、 戦争ドンパッチ災害時シーンからの復旧アーキテクチャを考える案件。 誰に向けて:今日ここにいるセキュリティエンジニアさん どうなってほしい:ドメイン駆動もセットで学んでみてほしい 2025/8/2
6. 脅威いたいこと 脅威モデリングとドメイン駆動は 相性が鬼良き。知らんけど 以上でシュ おわりでシュ ユミ 駆動(アジャイル界のハンコックより)
7. 嘘)まじめに、先に主張言います 物理空間におけるセキュリティの知識は、サイバー空間にも横展開できるものがある 根拠:今日話す内容を民間のアーキテクチャのセキュリティにパクれたから セキュリティ上の業務設計には、ドメイン駆動などの横断的関心ではないものの知識をパクれる 根拠:今日の内容は、ドメイン駆動×脅威モデリングだから 2025/8/2
8. 案件の前提条件 • 案件開始状態がすでにカオス • 我々の責務 • やったこと一覧 2025/8/2
9. 案件開始状態がすでにカオスよ 業務は複数の広い文脈が、複雑に連携しあう 規定系のルールは複雑で、設計運用も暗黙的 新しい戦略・戦術の承認プロセスも複雑 超サイロ化型組織 知識の運用なんてされず属人化 アーキテクチャなんて考え方は、一部のチーム以外ほぼない 組織に反復型の仮説検証サイクルなんてない プロジェクト憲章なんてものは存在しない(仕様が超曖昧) 案件で使うアーキテクチャFWの手法は未確立 メンバー全員、分散アーキテクチャ(SystemOfSystem)なんて考えたことない 2025/8/2
10. やったこと一覧 プロジェクト憲章定義として、仮説構造マップ作成 モデリング教育(具体的には、業務モデリングをDDDぽく) アーキテクチャフレームワークを用いたリスク分析と評価の支援 組織のアーキテクチャのToBeとAsIs比較 ロードマップ策定からの企業戦略起点での技術戦略ロードマップの考え方 2025/8/2
11. PJ混乱期の自チームの状態 そもそも陸・海・空・宇宙、どれ取っても難しい業務 どこの脅威分析から開始したらいいか不明 スプーフィング?だのよくわからん用語が毎日出てくる ユビキタスな概念用語はなく、バラバラな言葉が使われていた 各フローの事前・事後条件なんてものは暗黙化 そんな時に、たまたま【脅威モデリング】というものを見つけ、早速埼玉まで行って参加してみた。 2025/8/2
12. 2025/8/2 脅威モデリングとの出会いの時系列 2022 年11月 防衛案件etc案件に入る。 初のアーキテクト案件 2023 年5月 品質を考慮する際にリスク ベースで考慮した方がいいと 気づく。 2023年7月末 脅威モデリング初対面 「DDDっぽい!」と感動 2023 年10月～ 脅威モデリングの考えを 案件に取り入れてみる 2024 年 2月 チートポと無意識に組み合わ せて使っていて効果を感じ始 めた。 価値を支えるものとして 脅威モデリングという価値観へ
13. 確立されたフレームワーク一覧 PASTA・・・脅威モデリングの7つのステップ STRIDE・・・DFD描き、下図の6項目で脅威を抽出する手法 DREAD・・・最近だと古いと言われてるけど、5つの観点からざっくりリスクを評価できる  損害の可能性 Damage potential  再現性の高さ Reproducibility  悪用可能性 Exploitability  影響を受けるユーザー Affected users  発見可能性 Discoverability 「わお!!すでに案件で出てきた用語が、 STRIDEに集約されとるやん!!」みたいになった(warota草) 2025/8/2
14. で、早速使ってみた結果 定性効果:確かにだいぶ脅威分析モデリングは行いやすくなった 定量効果:それまで1つのフロー中の脅威分析にかかっていた時間を6日とすると、3、4日まで短縮 うへ～～～い!!!(*’ω’*) とはならなかった。 まだ何か足りない感が否めなかった。 2025/8/2
15. 実践後の改善 ４つの項目に分類 • DFDの問題と改善 • 脅威洗い出しどこまで問題と改善 • アタックツリー作成時の問題と改善 • ネガティブアクターの抜漏問題と改善 2025/8/2
16. この時点でもまだ否めなかった問題点 以下の４つの問題点が浮上した。 ① いきなりDFDとかだと、利害関係者が見慣れていないからファシリテーションがしにくい DFDだと処理の同期とか、並列とか表現しにくいし ② STRIDEで網羅することが大事みたいになってしまって、選択と集中ができない ③ リスク評価するにも、アタックツリーをいきなり作成するのは、ぶっちゃけ議論が発散してまう ④ 悪意あるネガティブアクターが不足してるの否めない 2025/8/2
17. ①DFDにおける課題点 そもそも重要な情報資産が何なのか不明な状態でDFD描けない 利害関係者があまり馴染みがない すべての範囲においてDFDを描いてる余裕ない 2025/8/2
18. ①の改善策：他の図で共通認識 I. アクティビティ図が一番共通認識とりやすいので、アクティビティ図作成 II. それをもとに情報モデル(概念の洗い出し)作成 III. コンテキストマップ代わりのDFD作成 2025/8/2
19. ②の脅威洗い出しの課題点 いつまででも脅威を洗い出して、どこで止めていいか不明 ⇒そのため、いくらでも発散し続ける ⇒選択と集中ができず、無限に時間とコストを食いつぶす ⇒結果、PJの効果がないと判断され、最悪白紙にされてしまう ⇒組織のアーキテクチャなんて考えはますます軽薄になる 2025/8/2
20. ②の改善策 I. 各情報資産に対して、バリューグラフを作成 なぜその情報を守りたいのか?と上位目的を抽出 II. 各情報(データストアの粒度大)に優先順位をつける III. 優先度の高い情報に対してのみ、STRIDE分析 ※3×3の定性マトリクスで優先度評価し、 右表の〇項目のみ分析。 2025/8/2
21. ③アタックツリー作成時の課題点 アタックツリー作成の際、攻撃者知見ない状態では、 トップダウンでアタックツリーの作成ができない。 ボトムアップにチェックしようにも難しい そもそも、ロジックツリーの作成経験がないメンバーもいた。 てかさ、攻撃者の気持ちわかんなきゃ作れなくね? 2025/8/2
22. ③の改善策 I. DFDを真似て情報とそれを使用するミスユースケース、アクターに分解した図を描く II. ネガティブアクターのペルソナ像を設定  どの情報資産を欲してるのか?  それはどうして?(さっきのバリューグラフ描くでもOK)  そのために、どんなミスユースケースを辿るか? III. ミスユースケースをアクティビティ図でラフ記述 IV. これとアタックツリーをセットで行き来した ※これの嬉しい所は、DREADのA(影響を受けるユーザー) が図を見てぱっと見でわかりやすい点。 2025/8/2
23. ④ネガティブアクターの抜け漏れの課題 ネガティブアクターの抜け漏れによって、以下の脅威が起こる。 攻撃者目線の観点不足による、さらに重大なリスクの考慮し忘れ 脅威モデリングは継続的改善を前提としてるが、 このネガティブアクターの抜け漏れは、早期になんとしてでも発見しておきたいこと!! 2025/8/2
24. ④の改善策 ③では、攻撃者起点でどんな脅威プロセスをしかけてくるか?と考えるトップダウン式アプローチ。 こっちでは、以下のボトムアップ式アプローチ。 I. 情報資産に対するSTRIDE分析を行う II. そのプロセスをミスユースケースとするネガティブアクターをボトムアップに発見 III. このトップダウンとボトムアップ式の両方で挟み撃ち IV. DREAD評価で優先順位付け 2025/8/2
25. ※コンテキスト思考(未発表) バリューグラフでは、せいぜいビジョンしか表現できない。 そこで、このコンテキスト思考を使って、ビジョンを含む3つのS要素で文脈を考える。 Surroundings（環境）:今に至るまでの背景 Soil（土壌）:環境に左右されない自分たちの価値観、自分軸 Sun（太陽）:目的ビジョン、なりたい姿 (※売上を2倍とかは目標で目的ではない) ※背景に関しては、原因と結果を表すモデルの話を過去にしているので、 そちらを参照ください。 https://www.youtube.com/live/hTc_3B7CZIk?si=hlbAZfklEshp29Lf 2025/8/2
26. 実験の効果 主張:3Sフレームワークを用いてることで、以下の効果が得られるはずだ。 どの情報資産を守るべきなのか?の優先順位付けで迷わない DREADの評価も、より明確な根拠をもって行える 根拠:3Sを取り入れる前後で、STRIDE分析で悩む時間が約1/3まで減少。 最初に議論に時間を他チームより割いてはいたが、後から回収できた。 詳細情報: 3月のワークで、3Sのうち土壌と太陽に関する情報の共通認識合わすという実験をした。 メンバー構成が異なるという差分はあれど、この雑なA/Bテストで効果を肌でも実感した。 2025/8/2
27. ここから得た更なる仮説 新たな仮説:3S情報を絞り込むことで、DREAD評価も迷わなくなるはずだ。 理由:自分と相手側の両方の立場の情報が、より明らかになるから。 根拠:土壌と太陽情報のみでも、3月にDREADのD・Aの絞り込みはスムーズにで きたから。 2025/8/2
28. 単一目的を意識せよ Attackツリーの際に、 2025/8/2
29. 改善後に得た 気付き 詳細は、今後のイベントで 今日はざっくり内容のみ 2025/8/2
30. 一連の流れ ※詳細な情報は、秘匿性が高いため公開できません。ここでは、一連の流れや汎用化した内容のみに抜粋してお伝えします。 ① 分析で ② 既存の業務のアーキテクチャを自社と相手(仮置き)両方を可視化 ③ ①②をもとに、SWOTクロス表にプロット ④ 改善の戦略を仮説立てて、結果を予測(ここで標準化部分も可視化) ⑤ 差別化領域のみ具体的戦術に落としていく ⑥ 既存のリソースの中で再利用できるもの、制約条件(自社でいじれる変数)の可視化 ⑦ 技術戦略 ⑧ ①に戻って、 2025/8/2
31. 改善活動 チームでミスユースケース分析がしやすくするため、アクティビティ図の作成 ⇒そこから悪意あるネガティブアクターの特定 & 各STRIDEプロセスの因果関係の明確化 ※アクティビティ図によって、DFDが正確に かつ 抽象度ごとに作成しやすくもなった 2025/8/2
32. 得られた気付き ぶっちゃけモデルを見直す工程が、DDDそっくり!! 詳細は後日のイベントで!w ドメイン駆動設計との相性が良き 境界付けられたコンテキストと、セキュリティの信頼境界は密接に関連している。 ならば、DDDにおけるオブジェクト指向原則なども適用できるのでは?と考えた結果、 どの実験もおおむね仮説通りの結果を得られた。 ビジネスは戦争ゆえに、セキュリティ案件の知識は民間にもアナロジー展開できる 2025/8/2
33. ソフトウェアアーキテクチャの 設計原則やパターンをめっちゃパクれた ソフトウェアアーキテクチャの設計思想をかなりアナロジー展開できた。 設計原則を適用できた デザインパターンのPolicyパターンをセキュリティポリシーに適用できた 閉鎖性共通原則をセキュリティの信頼境界設計へ適用できた 他の境界内に影響でないように、攻撃からの影響範囲を局所化 あとは、今後のイベントでお話ししマシュ ◦ 6/19に脅威モデリング東京 ◦ 7月頭に佐藤さんと小笠さんと３人で主催 2025/8/2
34. まとめ PASTAのプロセスをベースにSTRIDEで脅威を洗い出す際、以下の点に注目する。 モデル図はDFDにこだわる必要はない 重要な情報資産(例:エンドユーザーの個人情報など)を特定する前に、 バリューグラフで上位目的を定義あぶり出し、情報に対して優先順位をつける。 その上で、優先度の高いものに対してSTRIDE分析を行う。 アタックツリーを作成する際にも、ネガティブアクターの上位目的をバリューグラフで定義。 ネガティブアクターの考慮漏れ予防のために、ミスユースケース起点からのアクター抽出も行う。 DDDと脅威モデリングは相性がめっちゃいい。 2025/8/2
35. おぎおぎさんCSIRT入門 クライアントPCから出る通信の監視はNGという企業文化 通信監視に関する規定 というガバナンスの一部 会社の文化に沿ったセキュリティ対策。文化を変えるのは、カオス実験? 2025/8/2
36. クラウドセキュリティ インシデント起きて、サーバーとかがサラちになり、ログがない、サーバーもない。 などの苦があった。 モブさんの得た知見 セキュリティ文化醸成のための活動 セキュリティ情報マネジメントしてる組織ぽい JPCERT 共有時の工夫  誰に重要な情報なのか示しておく 誰が何を読めばいいかわかんないってことにならんようにBIぽいメカニズム  リンク先情報も共有しとく 詳細を知りたい人向けに 情報源のリンク先も  複数チャネルで発信する slackやteams 午前11時ごろに発信すると読んでもらいやすい  セキュリティナレッジの運用サイクル 相互に知識の交換循環で知恵への昇華活動 2025/8/2