Webエンジニアでもわかるセキュリティ、設計原則で考える「脅威モデリング」

GIFTechで開発エンジニアをしている佐藤です。

セキュリティに興味があったのですがなかなか踏み込めずにいたので、解像度を高めるために思い切って昨日開催されたセキュリティイベントに参加しました。
ただイベントに参加するだけではなく、セキュリティ初学者として何をインプットして挑み、何を得られたかをご紹介します。
セキュリティに関して知りたい方はもちろん、新たに学びたいことができた時どう動くといいかの参考にもなれたら嬉しいです。

参加前の事前知識としてインプットしたこと

まず、今回のテーマである「脅威モデリング」について。
イベント参加前に、LLMでイベントURLを読み込ませ、アプリケーションエンジニア（セキュリティ初学者）が事前に知っておくべきポイントは何かをききました。

結論、インプットしてよかったポイントをご紹介します。

脅威モデリングを「設計のデバッグ」と捉える

Webエンジニアにとって、脅威モデリングは「セキュリティの勉強」というより、「設計段階で行うバグ出し（デバッグ）」と考えると親しみやすくなります。
セキュリティ担当者は「何が危ないか」を知っていますが、エンジニアは「データがどう流れるか」を知っています。この2つが合わさる場所が脅威モデリングです。

これだけは知っておきたい「STRIDE」

イベントで頻出するキーワードに STRIDE（ストライド） があります。これは脅威を6つに分類したフレームワークで、Webアプリの脆弱性と直結しています。

脅威の種類 (STRIDE)	Webアプリでの具体例
Spoofing (なりすまし)	セッション乗っ取り、パスワードの使い回しによるログイン
Tampering (改ざん)	パラメータの書き換え、SQLインジェクション
Repudiation (否認)	「やっていない」と言い張られる（ログがない状態）
Information Disclosure (情報漏洩)	エラーメッセージからの技術スタック漏洩、PIIの露出
Denial of Service (サービス拒否)	ReDoS（正規表現による負荷）、大量リクエスト
Elevation of Privilege (権限昇格)	一般ユーザーが他人のデータを操作できる（IDORなど）

信頼境界（Trust Boundary）

「ここから先のデータは信頼できるか？」という境界線。ブラウザとサーバーの間、公開APIと内部マイクロサービスの間など。

シフトレフト

セキュリティ対策を「実装のあと」ではなく、より「左側（設計・要件定義）」に寄せること。

特にSTRIDEモデルは、脅威モデリングの代表的な手法として頻出単語でした。
これらをインプットした上で、以下スピーカー登壇をきき、学びのインプット・満足度も高く参加できたのではないかと思います。

脅威モデリングの手法

上記のSTRIDE以外にも複数あるためご紹介します。

• STRIDE
  なりすまし、改ざん、否認、情報開示、サービス拒否（サービス拒否）、特権昇格
• DREAD
  損害の可能性、再現性、エクスプロイト可能性、影響を受けるユーザー、発見可能性
• PASTA
  目標の定義、プロジェクトの技術的範囲の定義、分解、脅威の分析、弱点と脆弱性の分析、攻撃モデリング、リスクとビジネスへの影響の分析（7段階の手法）
• VAST
  ビジュアル、アジャイル、シンプル脅威のモデリング
• OCTAVE
  Operationally Critical Threat（運用上重要な脅威）、Asset（資産）、Vulnerability Evaluation（脆弱性）

設計から考えるセキュリティ

知っている原則の説明でインプットしやすかった登壇です。
クリーンアーキテクチャやSOLID原則などから設計の仕方を知ることで、セキュリティの視点でも当てはまる考え方ができるという点や、考えうる脆弱性などを洗い出そう、ということなのかなと受け取りました。

▽ スピーカー情報

タイトル：脅威モデリングの質を高めるドメイン駆動設計 —— 堅牢なシステム構築のための設計原則と実践

​スピーカー： 工藤由美さん
トーク概要：生成AIの普及により開発スピードが加速する今、アプリケーション設計とセキュリティの分断は、かつてない速さで大量の「負の遺産」を生み出すリスクを孕んでいます。本来、ビジネスドメインを起点とする「ドメイン駆動設計（DDD）」と「脅威モデリング」は不可分な関係にありますが、現場ではアーキテクトとセキュリティ担当者の乖離により、互いの重要な文脈が欠落しがちです。そこで本セッションでは、この悪循環を断ち切るため、脅威モデリングの前提となるドメインモデリングの手法、そして設計の強力な指針となる原則を体系的に解説します。設計とセキュリティ、二つの領域が融合することで生まれる「奇跡の組み合わせ」とその真価を、ぜひ体感してください。

SOLID原則で守りやすい構造を作る

オブジェクト指向を学ぶ際に誰もが通るのではないでしょうか。身近な原則が登場して驚きました。
セキュリティ観点で得られる効果をご紹介いただきました。
SOLIDの詳細は以下の記事などを参考にしてみてください。

• 単一責任の原則
  得られる効果→監査容易性
• オープンクローズド原則
  　得られる効果→安定性
• 依存関係逆転の原則
  得られる効果→ポータビリティ
• 閉鎖性共通の原則（CCP）
  得られる効果→修正漏れ防止
• 全再利用の原則（CRP）
  得られる効果→アタックサーフェス縮小
• 再利用・リリース等価原則（REP）
  得られる効果→追跡可能性

その他の原則

• DRY
  得られる効果→堅牢性の統一
• KISS
  得られる効果→バグの排除
• PIE原則
  得られる効果→インジェクション対策など
• SLAP
  得られる効果→監査容易性と認知負荷の低減（KISSにもつながる）

SOLIDで守りやすい構造を作ることが大切である。
コンポーネントでリスクの境界をひくこと。
これらの原則は「綺麗なコードを書くためだけのものではなく、守るための戦術に変換できる。」
とご説明されていました。

ビジネスイベントを起点として洗い出す

Event Storming（ビジネスイベントを洗い出す手法）を行う際、ハッピーパスだけでなくSecurity Pointを定義します。

認証失敗、アカウントロック、決済エラーなど、ビジネス上の重要な事実として捉えることで、脅威への耐性が格段に上がります。

信頼境界、責任境界を正しく引こう

• セキュリティアーキテクト・システムアーキテクト・経営者（ビジネス）の誰が責任を持つのか
• QAが担保するべきセキュリティポイントもある

質疑応答ではこのような議論もあり、現場の視点をもった質問だなと感じました。プロダクト開発をしているとエンジニアとしてもPM/EM/QA/データサイエンス/デザイナーなど役割と領域の境界を（いい意味で）領域侵犯していく必要もある場合があり、イメージしやすかったです。

コードが読みやすいことは脆弱性を見つけやすいことと同義

保守性の高いコードとは、そのまま脆弱性の入り込みにくいコード。

• Structure: クリーンアーキテクチャで守る場所を隔離
• Model: DDD/GRASPでデータをカプセル化
• Attack: 脅威モデリングで死角を見つける
• Refine: 原則で構造強化

参考文献

以下の書籍をおすすめされていました。

• 実践UML

• プリンシプルオブプログラミング

• デザインパターン入門

• チームトポロジー

ハードウェア設計に学ぶ要素分解

セキュリティの権威、はせがわようすけさんのお話で印象的だったのは、ハードウェアの世界のFMEA（故障モード影響解析） との類似性です。

ハードウェアの世界では、「電池が破裂する」「スイッチが戻らない」といった故障を設計段階でシラミ潰しに予測します。

• 要素を分ける: 部品単位まで分解する。
• 挙動を予測する: その部品がどう壊れ、全体にどう影響するか考える。

これはソフトウェアでも同じです。「このライブラリが落ちたら？」「このAPIが改ざんされたら？」と、構成要素を分解して「死角」をなくすプロセスこそが、脅威モデリングの本質なのだと学びました。

▽ スピーカー情報

タイトル：ハードウェア設計における脅威モデリングの類似的手法

スピーカー：はせがわようすけさん
トーク概要：https://www.docswell.com/s/hasegawa/KPGNR2-tmc-tokyo
​スピーカープロフィール：株式会社セキュアスカイ・テクノロジー 取締役CTO 一般社団法人セキュリティ・キャンプ協議会代表理事、千葉大学非常勤講師、セキュリティ・キャンプ協議会ステアリングコミッティ(2018～2021年)、セキュリティ・キャンプ講師(2008～2015年)、OWASP Kansai Board member、OWASP Japan Board member、CODE BLUE Review board member。 Internet Explorer、Mozilla FirefoxをはじめWebアプリケーションに関する多数の脆弱性を発見。 Black Hat Japan 2008、韓国POC 2008、2010、OWASP AppSec APAC 2014、CODE BLUE 2016他講演多数。

故障モード影響解析とセキュリティ

ハードウェア設計での手法

• FMEA
• FTA

特に今回は、FMEAが脅威モデリングとどう関係しているのか、をミニ四駆の具体例とともにご紹介いただきました。

FMEAと脅威モデリングの比較

構成要素の洗い出しから、発生しうる故障モードを検討、原因、影響、重要度、対策と検討していくことはインプットしていった脅威モデリングについての考えにも当てはめてイメージすることができてとてもわかりやすかったです。

脅威モデリングでは、システムに与える影響の検討がない点で、ハードウェアとは異なるミクロの視点で発生時の影響を見つけることは難しいのでは？と、差分の考えもご共有いただきました。

ソフトウェアとハードウェアそれぞれの手法からみた脅威モデリング

工藤さん、はせがわさん、そしてTMC Tokyoの運営の皆様に感謝いたします。
工藤さんはソフトウェア開発設計手法、
はせがわさんはハードウェア設計手法、
それぞれの観点をセキュリティ（脅威モデリング）に当てはめて考えるきっかけとなりました。

セキュリティエンジニアとともに、良いプロダクトを作っていくための設計を考えるきっかけになれば幸いです。
また、ぜひイベントに参加することをひとつのきっかけとして新たな学びのチャレンジとしてみてもいいのではないでしょうか！

モノ創りの本質の挑戦を発信中...！

Youtubeにて、伝統工芸の職人と挑んだAIエージェントマーケティングの開発ドキュメンタリームービー公開中！

ぜひチェックしてみてください！