この記事は Safie Engineers' Blog! Advent Calendar の8日目の記事です。

こんにちは、セーフィー株式会社でサイバーセキュリティを担当している金原です。

前回の記事「セーフィーのサイバーセキュリティ戦略の作り方」では、私たちが目指す「セキュリティが当たり前の文化」と「そこに到達するための戦略」についてお伝えしました。今回は、戦略の具体的な打ち手の一つ、「脅威モデリング」 について深掘りします。

「脅威モデリング」と聞くと、専門用語が多くて「難しそう」「時間がかかりそう」と感じてしまうことはありませんか？正直に言うと、私たちも最初はそうでした。

しかし、試行錯誤してたどり着いた結論はシンプルです。脅威モデリングの本質は「関係者同士の対話を促進するコミュニケーションツール」だということ。

今回は、一般的な脅威モデリングの手法を解説しつつ、それを「セーフィーではどう解釈し、運用しているか」という実践的なナレッジ（＝セーフィー流の型）をセットで公開します。これから脅威モデリングを始めたい方、もっと活用していきたい方の「生きた教科書」になれば幸いです。

そもそも「脅威モデリング」って何？
なぜ今、私たちがこれを推すのか
脅威モデリングの進め方（解説とセーフィー流の実践）
- 4つの重要な質問
- セーフィーでの活用事例
さいごに

そもそも「脅威モデリング」って何？

一言でいうと、「システムを作る前に、攻撃者の視点を踏まえ『起きたら困ること』を分析し、対策を考える活動」 です。

通常、開発の現場では「どんな機能を作るか（要件）」や「どうやって作るか（設計）」に集中しがちです。そこに 「何が問題になりうるか（セキュリティリスク）」 という視点をプラスします。

なぜ今、私たちがこれを推すのか

理由は大きく2つあります。

「シフトレフト」の世界標準だから NISTの「SSDF」やOWASPの「SAMM v2」など、主要なガイドラインで推奨されています。設計段階でリスクを潰すことで、手戻りを防ぐためです。
生きたセキュリティ教育になるから（★最重要） 私が特に重視しているのはこちらです。脅威モデリングを行うには、エンジニア、PM、セキュリティ担当者が集まって会話をする必要があります。
- 「ここのデータって、どういう流れでDBに入るんだっけ？」
- 「このAPI、認証なしで叩けたらマズいよね？」
こうした会話自体が、座学の研修よりもはるかに効果的な「生きたセキュリティ教育」になります。ドメイン知識とセキュリティ知識が、対話を通じてチーム全体に染み渡るのです。

脅威モデリングの進め方（解説とセーフィー流の実践）

では、具体的にどう進めればいいのでしょうか？

基本は以下の「4つの重要な質問」に答える形で進めていきます。

ここで大事な心構えは「完璧を目指さない」 こと。セーフィーでは、「間違ってもいいから、まずはホワイトボードに絵を描いて話そう」を合言葉にしています。

4つの重要な質問

【問1】私たちは何に取り組んでいるか？～モデルを作る～

まずは、システムの「形」を可視化します。一般的には、データフローダイヤグラム（DFD）が推奨されます。

■DFDの書き方（いきなり詳細を描かない）

DFDは「データがどこから来て、どこへ行くのか」という流れに注目した図です。

以下の5つの要素で図を表現します。

プロセス (Process)：処理や機能（丸）
データストア (Data Store)：DBやファイルなどのデータが留まるところ（二本線）
外部エンティティ (External Entity)：ユーザーや連携システム（四角）
データフロー (Data Flow)：データの流れ（矢印）
信頼境界 (Trust Boundary)：インターネットと社内LANの間などの境界線（点線）

よくある落とし穴が、「最初から詳細に描こうとして挫折する」ということ。私たちは「抽象から具体へ」という2ステップをおすすめしています。

①コンテキストダイヤグラムでまずは「外」と「中」を分ける

システム全体を1つの「箱」として捉え、外部（ユーザーや連携システム）とのやり取りだけを描きます。これだけで「守るべき範囲」が明確になります。

②レベル0ダイヤグラムで内部構造を分解する

次に、箱の中身を主要なプロセスに分解し、データの保存場所（データストア）を描き足します。ここで最も重要なのが「信頼境界（Trust Boundary）」という点線です。ここをデータがまたぐとき、脅威が発生しやすくなります。

必要に応じて、ここからさらにレベル1…、のように詳細化していきます。

■セーフィー流の実践（厳密さよりも「対話の種」）

教科書通りの記号（丸や二本線など）を使おうとすると「これであってる？」と手が止まりがちです。私たちの現場では、「ホワイトボード（またはMiro）に10分ぐらいで描けるレベルでいい」としています。

厳密な記法より、「データの流れ（線）」が合っていればOK。
詳細な設計図である必要はない。先ほどの「信頼境界（点線）」をまたぐ場所がわかれば、そこが攻撃ポイントだと判断できる。

加えて、一度で終わりにせず、徐々に詳細度を上げていくスタイルを取っています。

📘 もっと学びたい方へ

具体的なDFDの作り方は、書籍『データフローダイアグラムいにしえの技術がもたらすシステム設計の可能性』（大嶋和幸、松永守峰 / 翔泳社）が非常に参考になります。

【問2】何が問題になりうるか？～STRIDEでリスクを見つける～

モデルができたら、次は「ここが攻撃されたらどうなる？」を考えます。

ここでのポイントは、高度なハッキング方法を語るのではなく、「起きたら困ること」を洗い出すことです。攻撃手法の話になると専門家しかわからなくなりますが、「困ること」なら関係者全員で議論できます。

■STRIDEフレームワーク

脅威を見つける切り口として、「STRIDE（ストライド）」 というフレームワークを使うと便利です。以下のような「問いかけ」をしながら問1で作成したDFD上に付箋で書き出していくとスムーズです。

頭文字	脅威の種類	問いかけの例	具体例（Webアプリ）
S	Spoofing (なりすまし)	私たちまたはユーザーは、なりすましが起きて何が困るか？	他人のアカウントでログインされる
T	Tampering (改ざん)	私たちまたはユーザーは、データ改ざんが起きて何が困るか？	DBの値や通信内容を書き換えられる
R	Repudiation (否認)	私たちまたはユーザーは、否認できる状態で何が困るか？	「操作していない」と言い逃れされる
I	Information Disclosure (情報漏洩)	私たちまたはユーザーは、データ漏洩が起きて何が困るか？	個人情報や機密データが漏れる
D	Denial of Service (サービス拒否)	私たちまたはユーザーは、システムの停止/遅延が起きて何が困るか？	システムがダウンして使えなくなる
E	Elevation of Privilege (権限昇格)	私たちまたはユーザーは、権限を越えた操作ができて何が困るか？	一般ユーザーが管理者操作を行う

■セーフィー流の実践：「思考停止を防ぐカンペ」として使う

STRIDEを事前にすべて暗記する必要はありません。私たちは上記のような具体例をいくつか添えた表を「問いを立てるためのカンペ」として使っています。

レビューの場で問いかけるためのトリガーになれば十分です。エンジニアが「あ、それだとこういうことが起きると困りますね」と気づけば、それが立派な脅威分析です。専門用語を覚えるより、「困ること」を言語化できることを重視しています。

📘 もっと学びたい方へ

STRIDEやセキュア設計については、書籍『セキュアなソフトウェアの設計と開発脅威モデリングに基づく普遍的アプローチ』（ローレン・コンフェルダー / 秀和システム）がおすすめです。

【問3】それに対して何をするのか？～リスク評価と対策～

脅威がたくさん出てくると、「全部直すなんて無理！」となってしまいますよね。

大事なのは、「同時にすべてを対策することはできない」という前提に立つことです。リソースも時間も有限ですから、優先順位をつける必要があります。

リスクマップ：「発生確率」×「影響度」で定性的に評価して優先度を決めます。
対策：リスク「高」のものから順にチケット化し、バックログに積みます。

■リスクマップの例

■セーフィー流の実践：必要に応じて評価方法を変える

教科書的には厳密にスコアリングして評価することが推奨されがちですが、全てのリスクでそれをやるとスピードが落ちてしまいます。セーフィーでは、対象システムや情報の重要度に応じて「評価方法（物差し）」を使い分けています。

スピード感や柔軟性が求められる通常の機能は、「定性評価（高・中・低）」でスピーディに判断し、対策の要否を決めます。一方で、決済周りや特に重要な基盤システムは、「定量評価（CVSSやOWASP Risk Rating Methodology等）」を用いて厳密にスコアリングし、監査にも耐えうる根拠を残します。もちろん、2つを組み合わせるケースもあります。

「スピード重視」と「厳密さ」のメリハリをつけること。これを私たちは大切にしています。

📘 もっと学びたい方へ

リスク評価の深掘りには、書籍『脅威インテリジェンスの教科書』（石川朝久 / 技術評論社）が参考になります。

【問4】十分にうまくできたか？～ふりかえり～

このふりかえりは飛ばされがちですが、実は脅威モデリングを組織やチームに浸透させるためには、とても重要な問いになります。

対策が妥当かどうかの評価も大事ですが、「脅威モデリングの進め方自体がどうだったか」のふりかえりで経験学習のサイクルを回します。

■セーフィー流の実践（10分で終わらせる「タイムボックス」）

ふりかえりの手法は多数ありますが、セーフィーでは軽量に実施できる「＋/Δ（プラス/デルタ）」を採用して、「10分間」という時間を区切って実践しています。理由は、重くすると続かないからです。継続性が大事。

「DFDのスコープが広すぎて議論が発散したね」
「××さんが詳しいから、次は呼ぼう」

こうした小さな改善の積み重ね（アジャイルなアプローチ）が、チームのセキュリティ筋肉を育てていきます。

📘 もっと学びたい方へ

ふりかえりの手法や有用性を学ぶなら、書籍『アジャイルなチームをつくるふりかえりガイドブック始め方・ふりかえりの型・手法・マインドセット』（森一樹／翔泳社）がおすすめです。

セーフィーでの活用事例

ここまで脅威モデリングの手法とセーフィー流の実践をお伝えしました。では、これを具体的にどのように現場に落とし込んでいるのか？私たちの現在の取り組みを紹介します。

1. セキュリティレビューへの「部分導入」

これまでチェックリストベースで行っていたセキュリティレビューの一部に、脅威モデリングを取り入れ始めています。

開発者から説明を受ける際、セキュリティチームが手元で簡易的なモデルを作り、「ここのデータの流れ、信頼境界またいでるけど大丈夫？」といった対話をします。

チェックリストだけでは見えない重要箇所のレビューができますし、静的なアーキテクチャ図よりもデータやプロセスの流れが整理できるので、開発者からも好評です。私自身も、多くのセキュリティレビューを実施する中で、「あれどうなってたっけ？」となったときに、レビュー時に作成したモデルを見ることで思い出すことができて助かってます。