"脅威モデリング"のイベント参加レポート＆JDDでの取り組み
本記事は、Japan Digital Design Advent Calendar 2024 の18日目の記事になります。
はじめまして。三菱UFJフィナンシャル・グループ（以下MUFG）の戦略子会社であるJapan Digital Design（以下JDD）で、Security Engineerとしてプロダクトセキュリティを担うR.Inoueです。
2024/12/6(金)開催の「脅威モデリングナイト #5 in Tokyo」と、翌日7(土)開催の「TMC Tokyo Meetup x ZANSIN」にダブル参加してきましたので、本記事ではその参加レポートをお届けします。
併せて、JDDでの脅威モデリングの取り組みについてもご紹介します。
なお、各レポートがかなり重厚なものになっているため、以下の目次で必要なパートだけを読むのがおすすめです。
また、もし脅威モデリングについて馴染みの薄い方は、末尾の「参考；脅威モデリングとは」を先にご覧いただけると本記事のニュアンスが伝わると思います。
「脅威モデリングナイト #5 in Tokyo」と「TMC Tokyo Meetup x ZANSIN」は、どちらも「脅威モデリングオープンコミュニティ」として2024年6月に始まったコミュニティが主催のイベントです。12月からは「Threat Modeling Connect Tokyo Chapter（TMC Tokyo）」とコミュニティ名を改称し、グローバルコミュニティの一員として活動していくそうです。
脅威モデリングナイト #5 in Tokyo
LT＝Lightning Talk形式で、各20分程度の発表が3セッション行われました。どの登壇者も、共通するテーマは「脅威モデリングを社内でどのように活用しているのか」という実践的な内容で、既存のリスク評価プロセスにある課題に対し、脅威モデリングをどのように活用・取り入れながら解決したのかを発表してくださりました。
以下、発表タイトル順に記します。
脅威分析の実務への応用
トップバッターは国内有数のセキュリティベンダー「株式会社セキュアスカイ・テクノロジー」のCTOはせがわようすけさん。
通常、システムやプロダクトに対して行われることが多い脅威モデリングを、社内の実務（業務プロセス）に対して適用したという内容です。
セキュリティベンダーであっても、業務プロセスのDFD作成には苦労されているようで、「エレメント（システムと登場人物の構成要素）の洗い出しや、システム自体の粒度を分ける基準が不明瞭」という登壇者の課題意識には、発表後の質疑でも「同じ課題がある」という声が聞かれました。
しかし登壇者は
最終的なゴール（なぜ脅威モデリングを行うのか）に立ち返れば、ゴールは「脅威分析」ではなく「リスクの把握」である
「最初の一歩ができないくらいなら、リスクを把握できる方が良い」
という考えのもと、超簡易なDFDで業務プロセスに脅威モデリングを行ってみたそうです。かけた時間は、DFDの作図のみならず、STRIDEとリスク評価も含めて、なんと1〜2時間！小規模なプロダクトでも半日〜丸1日程度の工数をかけている筆者からすると、驚異的なスピードです。
確かに筆者の経験的にも、DFDが複雑すぎると細部ばかりに目がいきがちとなり、全体感の把握が難しくなる印象があります。あえてDFDをシンプルにすることで、全体の把握が素早く、単純に、柔軟にできる点で優位性のある手法だと感じました。これは、"Threat Modeling Manifesto"の5つの価値観の1つ：
Doing threat modeling over talking about it.
（筆者訳：脅威モデリングについて、話すよりもやってみる）
をまさに体現していると思いました。
また、業務プロセスのモデリングでは、いわゆる「サイバー攻撃」のみならず「セキュリティ事故」も射程に入れ、攻撃よりも事故のほうが発生可能性が高い という想定で、事故も含めた脅威をSTRIDEで洗い出すことを意識されたそうです。
サイバーセキュリティチームとプライバシーチームを繋ぐリスク分析の展望
続いては、株式会社マイナビにて「セキュリティ」と「プライバシー」の2つのチームを抱える部の部長 下別府遼さん。後者のプライバシーチームは、業務オペレーション（業務に潜むリスク）に責任を持つ部署で、いわゆる個人情報管理を担当するチームだそうで、これが部としてはセキュリティ側と一体となっている組織体制が特徴的です。
発表では、PIA：Privacy Impact Analysisというプライバシーに関するリスク分析手法を、個人情報に限らず情報資産全体に適用するという独自の拡張を紹介いただきました。プライバシーチームが同じ組織にあるからこそ着想を得られたであろうアプローチです。
脅威モデリングの課題として「リスクの判断基準が蓄積されておらず、担当者の能力依存」が挙げられていました。これは個人的には非常に共感できる話で、各リスク評価担当者は、自身の頭の中で"仮想"リスク評価責任者を立てて「責任者ならどんな疑義を持つだろうか」と想像して評価を実施する節が少なからずあると思います。責任者が1人のうちは良いですが、複数の事業領域で別々の責任者を立てるような組織規模になると、判断基準がブレるというのは容易にあり得る話です。
PIAでは、個人情報のライフサイクルを収集、保有、利用、提供、廃棄という5つのフェーズに分けます。これを個人情報に限定せず、情報資産全体で「各フェーズに存在するリスク」と「どのような対策を取っていたら、どの程度の影響度と考えるのか」を検討した結果が、例とともに示されました。
会場ではここが一番盛り上がった部分で「すごい！！」「誰もが夢見て挫折する基準作成」「スケールメリットが凄そう」といった数々の驚きが寄せられました。
なお登壇者が「大前提」として挙げていたのが"All models are wrong, but some are useful"（筆者訳：全てのモデルは間違っているが、いくつかは役に立つ）というGeorge Box氏の言葉で、何も基準がないよりは、基準を言語化して判断を属人化させない取り組みそのものに価値があると感じました。1つ前でも挙げた"Threat Modeling Manifesto"の価値観、"Doing threat modeling over talking about it."がここにも現れていると思います。
また筆者としては、発表後のモデレーターからのコメントである、
「基準をどこからか持ってくるのは簡単。自社にとって最適を目指すのが大変」
「網羅的よりは横断的に。対話して、いろんな立場・部門の視点を取り入れてより良くしていくべきもの」
という講評が印象的でした。実は、"Threat Modeling Manifesto"にも
People and collaboration over processes, methodologies, and tools.
（筆者訳：プロセス、方法論、ツールよりも、人と協働を重視する）
という価値観が書かれており、ここに通じる話だと思います。
"再現性"を重視した脅威モデリングベースのセキュリティリスクアセスメント
最後は、"黒豆"のアカウント名で情報発信をされている、某大手HR Tech企業でセキュリティマネージャを務める方の発表です。
発表タイトルの「脅威モデリングベースのリスクアセスメント」とは、黒豆さんが立案した、トリアージ済みのリスク評価が得られるリスク評価手順です。
脅威モデリングに倣ってDFDを作成
事前に整理したリスク評価責任者の思考・リスクへの考え方が提示された選択肢に適用
「評価者がシステムとリスクを全部把握」という属人的な体制から、「システム担当はDFD」「リスク評価担当は攻撃シナリオの整理」という分業体制に移行でき、結果として評価結果の再現性が向上したそうです。
この手順が解決したい課題として登壇者が挙げた「日によって判断根拠が違う」「過去の判断根拠を覚えていない」といった課題は、会場からも「あるある」として共感の嵐でした(笑)
この手順の特徴は、黒豆さん独自の考えが2つ取り込まれている点です。
「情報資産ごと」ではなく、「攻撃シナリオごと」のリスク評価
情報資産ごとでは、同じデータを扱うシステムや業務プロセスが何箇所もあると、反復になってしまう
リスク評価軸が「侵入しやすさ」と「"情報のCIA"への影響」の2つある
「侵入対策はガチガチだが、漏えい対策はできてない」例では、ひとたび侵入を許してしまうと大規模な情報漏えいが簡単に起こることを反映している
特に2は、多層防御の考え方をリスク評価に濃く反映させる1つの方法だと感じました。全ての企業・ケースで適用できる汎用的なモデリング・評価基準は存在しないからこそ、各社・各責任者が自身の考えを定性的にアウトプットすることに意義がありそうです。
TMC Tokyo Meetup x ZANSIN
このイベントは土曜日の朝9時から夜9時まで、休憩も含め12時間という長丁場でした。 朝起きられるか不安でしたがなんとか無事に会場入りしました。
※タイムテーブルの通り、9時は受付開始の意味で実際には9:30スタートだったのですが、もし9:30と書かれていたら9:35に会場入りしていたと思うのでこれで良かったです(笑)
1グループ4人が即席のチームを組み、計20グループに分かれて以下に取り組みました。
午前：脅威モデリングのワークショップを通じて、午後のハードニング※対象となるシステムに存在する脅威を認識する
午後：実際にシステムをハードニングし、脅威への対策を実施する
システムの設計と運用の両面を通じて、リスク評価とセキュリティ対策への理解を深めることができるイベント構成でした。
※ハードニングとは、脆弱なシステムを堅牢化することです。今回は、4時間という制限時間の中で、不要なサービス・APIを閉じたり、アプリケーションコードを修正したりして自分たちの環境をセキュアにしていき、現役のペネトレーションテスターからの攻撃を凌ぐという競技内容でした。
タイムテーブル
一見、長時間でキツそうに見えるイベントですが、体感的には全くそんなことはなかったです。実際に手を動かす時間が大半だったことに加えて、「リアルタイムで受ける攻撃（インシデント）に対応する」というハードニングの非日常性からアドレナリンが大量放出されたのか、「あっという間だった」という印象さえ持ちました。
脅威モデリング（ワークショップ）
午前は、脅威モデリングの基礎知識と、DFD作成、STRIDEによる洗い出し、Attack Treeの作成といった、脅威モデリングの一般的なフローを、チームメンバーと協働してホワイトボードと付箋に描いていきました。なお筆者は、登壇者の主催する別のワークショップに参加したこともあるため、初対面のメンバーと脅威モデリングを通じて認識合わせするプロセス自体は経験したことがありました。また、今回のイベントでは全体的に参加者のレベルが高く、システム構成やデータ処理の考え方に特に認識のズレなく会話が弾みました。このため、基本的な脅威についてはすんなりと洗い出せたように午前の段階では思っていました。（過去形な理由は後述します）
ハードニング（競技）
筆者はハードニングの存在は知っていたものの、競技参加は初めてでした。
JDDでプロダクトセキュリティ担当ということもあり、即席のチームにおいて「脆弱なプログラムの修正」を担当しました。対象システムはPHPで書かれていて、JDDではTypeScriptとPythonがメインだったのでPHPを拝むのは2年ぶりくらいでしたが、会場では試験導入されたAIチャットボットが稼働しており、これに多いに助けられました(笑)
SQLインジェクションやアプリケーションロジックの問題などの脆弱性を特定・修正していきました。
しかし、修正が間に合わず、不正なスクリプトを設置されたり、サイトを改ざんされたりといったインシデントが発生してしまいました。いざ攻撃を受けてみると、脅威モデリングで想定していた箇所ではない脅威が現実には発生したり、逆に設計資料への理解不足からシステムでは想定不要な脅威を洗い出していたことがここで分かりました。
そんなときに、チームのメンバーが不正アクセスされていそうなエンドポイントのURLをアクセスログから抽出したり、改ざんされたファイルをサーバ内のファイル更新日時から特定したりと、素早く攻撃の兆候を発見してくれました。ログを即時に分析して脅威の動向を掴むことが、インシデントレスポンスにおいて如何に重要かがよく分かりました。
イベントに参加してみて
筆者はこれまでセキュリティ関連のイベントに参加する機会が乏しかったため、今回のようなイベントで社外のたくさんの方と交流できたこと自体が、とても刺激的でした。
今回2つのイベントを踏まえて、JDDに取り入れたい内容が2点ありました。
判断基準の言語化
筆者はリスク評価責任者ではないため、あくまで責任者が判断しやすい形でリスクを整理する部分までが今の責任範囲です（本記事執筆時点）。しかし今後組織が大きくなり、自分がリスク評価責任者となる場面が出てくることもあると思います。（なれるように精進します。。笑）
来るそのときに、これまでの責任者の判断基準が言語化されていることは、過去判断の説明責任を引き継ぎ、筆者の考えを反映させていく上で、筆者にとっても会社にとっても重要なことだと考えます。自社内でのレッドチーム演習
JDDのプロダクトの各種ログは、Microsoft Sentinelへ集約され、分析しています。また、筆者はセキュリティチームという立場上、自社プロダクトの開発環境に対して攻撃できます。
ハードニングで筆者が体験したように、万が一脅威が発現したときに、発見的対策が有効に機能するのかの演習（訓練）は、いざというときに備え行うべきだと強く思いました。
午後のハードニングがあったからこそ、午前に想定した脅威を「現実のもの」として捉える勘所が生まれたように思います。このため、自社でもこれを行うことで、脅威モデリングを机上の空論で終わらせず、精度の高いモデリングができるようになることに繋がると思います。
JDDでの脅威モデリングの取り組み
実は、JDDでの脅威モデリングの歴史は（創業7年という社歴の割には）比較的長く、2020年から徐々に取り組み始め、今では社内に閉じた技術検証（PoC）を除く全ての開発プロジェクトで運用しています。
本記事執筆時点では、JDDでの運用手順は以下の通りです。Security Engineerが主体となりつつも、開発サイドの懸念点や意見を取り入れて、双方の認識齟齬が無いように進めています。
【ヒアリング】GitHubやConfluenceなどの開発資料と、開発サイドへのヒアリングを通じて、プロジェクトや開発機能の概要、ユースケース、利用データ、開発サイドとしての懸念点などを確認する
【DFD】PowerPointを用いてDFDを作成する
【ヒアリング】完成したDFDをチーム内＆開発サイドに確認してもらい、必要に応じて修正する
【STRIDE】全てのエレメントとデータフローで、STRIDEによる脅威分析を行う。このとき1のヒアリングで出てきた懸念点も含める
洗い出した脅威に対して、資料やヒアリングで判明している対策を「予防的対策」と「発見的対策」の観点で入力する
【レビュー】対策が不明な脅威についてはヒアリングを行いつつ、脅威に対して対策が必要か・どのような対策を行うか（リスク評価）をその場で開発サイドと議論する
議論の結果、対策を取るべき（リスク低減が必要）と判断した脅威については、開発サイドが持ち帰り追加で実装・確認したり（予防的対策）、脅威の検出のためにセキュリティチームでログアラートルールを追加したりする（発見的対策）
お気づきかもしれませんが、一般的な脅威モデリングの工程全てを取り入れているわけではありません。一般的な手順では、上記4の後に「Attack Treeの作成」や「DREADによるリスク評価」といった工程があります。しかし、JDDではスピーディな意思決定と運用工数の削減を目的に、あえて省略しています。
その代わり、6のタイミングで開発サイドとも認識を合わせながら対策を決めており、実効性のある対策を開発サイドが納得感を持って実装しています。開発組織の中に、開発エンジニアとセキュリティチームが同居しており、いわゆるDevとSecが融合しているJDDだからこそできるスピードとセキュリティ品質の両立手法かもしれません。
まとめ
この記事では、「脅威モデリングナイト #5 in Tokyo」と「TMC Tokyo Meetup x ZANSIN」の参加レポートをお届けしました。
脅威モデリングナイト #5 in Tokyoでは、脅威モデリングに取り組む各社の応用事例が紹介されました。
社内の実務（業務プロセス）に対して適用した事例
PIAの考え方を、個人情報に限らず情報資産全体に適用したモデリング手法
事前に整理したリスク評価責任者の思考・リスクへの考え方が提示された選択肢に適用することで、DFD由来の攻撃シナリオに対してトリアージ済みのリスク評価が得られる手順
TMC Tokyo Meetup x ZANSINでは、1日がかりの参加型イベントを体験しました。
午前：脅威モデリングのワークショップを通じて、午後のハードニング対象となるシステムに存在する脅威を認識する
午後：実際にシステムをハードニングし、脅威への対策を実施する
JDDでは、金融業界によくあるチェックリストによるベースラインアプローチだけでなく、脅威モデリングというリスクベースのアプローチも取り入れて、セキュアなアプリケーション開発に取り組んでいます。今回、脅威モデリングのイベントに参加して得られた新たな知見は、早速JDDの運用に取り入れていきたいと思います。
よく「正解は無い」と言われるセキュリティの世界ですが、「絶対に守るべきこと」や「ベストプラクティス」は存在します。今後もイベント参加などを通じて最新のセキュリティ動向をキャッチアップし、JDD社内の取り組みに還元することで、セキュア開発プロセス・運用のさらなる高度化を進めていきます。
JDDのセキュリティチームの取り組みについて興味を持っていただけた方は、ぜひ以下の記事もご覧ください。
参考；脅威モデリングとは
脅威モデリングとは、システム開発においてそのシステムの脅威を効果的に洗い出すための手法です。
セキュリティ用語で「脅威」とは、平たく言えば「ビジネスにとってマイナス要因となる事象」を指します。
脅威の例：
外部からのサイバー攻撃（不正アクセス、フィッシング、マルウェア、DDoS攻撃など）
内部不正（従業員による情報の持ち出し、職権の悪用など）
操作ミス
システムの故障
天災
1や2は代表的ですが、3〜5は一見するとセキュリティとは関係のないように思えるかもしれません。しかし、ビジネスへの悪影響があれば「脅威」と捉えます。
とはいえ、現実には無数の脅威があり、それら全てに対応するとなると金銭的にも時間的にもコストが膨大になってしまいます。そこで、
想定すべき脅威を洗い出し
各脅威に対して「その脅威が起こり得る可能性」と「本当に起きてしまったときのビジネスへの影響」の2軸で、脅威の大きさ（リスク）を分析
分析に基づき、対応すべき脅威の優先順位と、対応の中身＝対策を判断
というアプローチを取ります。これをリスク評価と呼びます。
上記の通り、適切な対策を判断するためには、まずは脅威を洗い出すことが欠かせません。しかし、何でもかんでも脅威を羅列していけばよいのかというと、そうではありません。
例えば「AWS上で構築する生成AIによる検索システム」というシステムに対して
「AWSのデータセンターに強盗が押し入る」という脅威は、そのシステムではどうすることもできませんので、あまり想定する意味がありません。（責任共有モデルに則り、AWS側の責任です）
「AIモデルのデータセットが改ざんされる」という脅威はありえそうですが、構築済みのモデルを参照する構成なのか、システム上でデータのインプットも行えるのかで想定すべきか変わりそうです。
といった具合に、そのシステムが想定すべき脅威を効果的に洗い出すことが重要です。
脅威モデリングでは、システム構成図（正確にはDFD=Data Flow Diagram：データフロー図、システム間のデータの流れを表す図）を利用することで、データの流れに着目して体系的に脅威を認識（モデリング）することができます。Microsoft社が、自社製品の脅威を"STRIDE"に分類したのが始まりとされます（→参考）。
さらに詳しく知りたい方はOWASPのThreat Modeling Processをご覧ください。
Japan Digital Design株式会社では、一緒に働いてくださる仲間を募集中です。カジュアル面談も実施しておりますので下記リンク先からお気軽にお問合せください。
この記事に関するお問い合わせはこちら
Technology & Development Div.
R.Inoue