【詳細解説】STRIDEおよび主要な脅威分析手法の構造的概要と比較分析

2026.07.30

【詳細解説】STRIDEおよび主要な脅威分析手法の構造的概要と包括的比較分析

2026年7月30日東京都校正
2026年7月29日生成AIにより作成

脅威モデリングの概念的基盤と評価フレームワーク

脅威モデリングは、システムアーキテクチャ、アプリケーション設計、およびデータフロー内に潜在するセキュリティ上の不備や構造的脆弱性を、攻撃者の視点から能動的かつ体系的に特定・評価・緩和するための予防的セキュリティ設計手法である1。
従来型のセキュリティアプローチが実装完了後の脆弱性診断やペネトレーションテストなどの後追い型検証に大きく依存していたのに対し、脅威モデリングはソフトウェア開発ライフサイクル（SDLC）の最初期段階である要件定義・設計フェーズにおいてセキュリティ要件を組み込む「シフト左（Shift-Left）」の思想を体現する3。
設計段階でアーキテクチャの欠陥を発見・修復することは、本番環境適用後の障害対応やコード改修と比較して修正コストを著しく低減させ、システムの根本的なセキュリティレジリエンスを向上させる5。
脅威分析のプロセスを構造化し組織化する基盤として、OWASP（Open Web Application Security Project）が提唱する「4つの質問フレームワーク」が広く共有されている2。
この思考フレームワークは、第一に「我々は何を作成しているのか（What are we working on?）」という問いを通じてシステム境界、コンポーネント構成、依存関係、およびデータの流れをモデル化する段階を定義する2。
第二に「何がうまくいかない可能性があるのか（What can go wrong?）」という問いにより、モデル化されたシステムに対する潜在的な攻撃手法や脅威を洗き出す2。
第三に「それに対して我々は何をするのか（What are we going to do about it?）」という問いによって、特定された脅威に対する技術的コントロールの導入、リスクの受容、転嫁、あるいは排除といった緩和策を策定する2。
最終的に「我々は十分な成果を収めたか（Did we do a good job?）」という問いを通じて、モデルの完全性、分析の品質、ならびに対策の実効性を検証する閉ループを構成する2。
システム構造を可視化・分解する過程において最も中核的な概念となるのが「信頼境界（Trust Boundary）」の概念である4。
異なる特権レベル、異なるアクセス制御ドメイン、あるいは異なる管理主体（例えばインターネットとDMZ、Webアプリケーションとバックエンドデータベースなど）が交差する境界線をデータが通過するポイントこそが、主要な攻撃表面（Attack Surface）を形成する7。
データフロー図（Data Flow Diagram: DFD）等を用いてこれらの信頼境界を明示的に示し、境界を越えるデータと処理の組み合わせを詳細に分析することが、効果的な脅威特定における前提条件となる4。

STRIDE手法のアーキテクチャとエレメント別マッピングメカニズム

STRIDE手法は、1999年にMicrosoftのLoren KohnfelderとPraerit Gargによって提唱され、その後Adam Shostackらによって同社のセキュア開発ライフサイクル（SDL）へ組み込まれることで広く普及した脅威分類フレームワークである1。STRIDEは、コンピュータセキュリティが維持すべき主要な安全属性の裏返しとなる6つの脅威カテゴリーの頭文字から命名されている10。
以下の表は、STRIDEの各脅威カテゴリー、侵害されるセキュリティ属性、攻撃の具体的態様、および標準的な緩和策を整理したものである8。

STRIDEカテゴリー	侵害されるセキュリティ属性	脅威の概要・攻撃例	標準的な技術的緩和策
Spoofing（なりすまし）	認証（Authentication）	攻撃者が正規のユーザー、デバイス、またはシステムコンポーネントのアイデンティティを偽装して不正アクセスを得る行為10。	FIDO2/WebAuthn等の強力なマルチファクタ認証、相互TLS（mTLS）、署名付きセッションID10。
Tampering（改ざん）	完全性（Integrity）	通信経路上のデータ、ストレージ内の保存データ、設定ファイル、またはコードが不法に書き換えられる行為10。	TLSによる全区間暗号化、デジタル署名、HMACによる整合性チェック、厳格な入力値検証8。
Repudiation（否認）	不可否認性（Non-repudiation）	アクターが特定の操作や取引を実行したにもかかわらず、確実なログや証拠が存在しないためにその行動を否定できる状態10。	改ざん耐性のある集中ログ基盤、タイムスタンプ付与、PKIに基づくデジタル署名10。
Information Disclosure（情報漏洩）	機密性（Confidentiality）	機密データやシステム内部構造に関する情報が、閲覧権限を持たない第三者に露出・参照される行為10。	保管時・転送時データの暗号化（AES-256等）、最小権限に基づくアクセス制御、エラー詳細の遮蔽8。
Denial of Service（サービス拒否）	可用性（Availability）	システム資源（CPU、メモリ、ネットワーク帯域）を過大に消費させ、正規ユーザーに対するサービス提供を阻害・停止させる行為10。	レート制限（Rate Limiting）、リソースクォータ設定、DDoS緩和策、オートスケーリング配置10。
Elevation of Privilege（特権昇格）	認可（Authorization）	権限の低いアクターがシステムの脆弱性や設計上の不備を悪用し、高位の管理権限や他者のアクセス権を獲得する行為10。	サーバーサイドでの厳格な認可制御、最小権限の原則の適用、特権分離、パラメータ改ざん対策10。

STRIDEをシステム設計に適用する際、分析者の直感や主観による網羅性の欠如を防ぐため、「エレメント別STRIDE（STRIDE-per-Element）」と呼ばれる構造的マッピングメカニズムが用いられる7。データフロー図（DFD）を構成する4つの基本エレメント（処理、データストア、データフロー、外部エンティティ）は、それぞれの技術的性質と攻撃表面の特性に応じて、検討すべきSTRIDE脅威カテゴリーがあらかじめ理論的に紐付けられている8。
以下の表は、DFDの構成エレメントとSTRIDE脅威カテゴリーの対応関係および構造的理由を示している8。

DFD構成エレメント	DFD上の表現と具体例	適用されるSTRIDEカテゴリー	構造的理由と分析の焦点
External Entity（外部エンティティ）	長方形（エンドユーザー、外部Web API、サードパーティシステム）8	Spoofing, Repudiation8	管理領域外に存在するアクターであるため、内部構造の改ざんは不可。アイデンティティの偽装（S）と「操作を行っていない」という否認（R）が分析対象となる8。
Process（処理）	円または丸角長方形（Webサーバー、マイクロサービス、バックグラウンドジョブ）8	Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege8	コードを実行しデータを変換する最も複雑なコンポーネントであり、攻撃の標的となりやすいため6つの脅威カテゴリーすべてに対して脆弱である8。
Data Store（データストア）	平行線（リレーショナルDB、RDB、ファイルシステム、キャッシュ）9	Tampering, Repudiation, Information Disclosure, Denial of Service9	静的データに対する改ざん（T）、情報漏洩（I）、データの不法消去・破壊による可用性喪失（D）の影響を受ける9。監査ログ等を保持する場合、記録の削除・否認（R）も該当する9。
Data Flow（データフロー）	矢印（HTTP/HTTPSリクエスト、gRPC通信、メッセージキュー）8	Tampering, Information Disclosure, Denial of Service8	信頼境界を跨いで移動中のデータは、中間者攻撃（MitM）による改ざん（T）、盗聴による情報漏洩（I）、および通信の遮断（D）にさらされる8。

実践においては、全エレメントを均一に評価する「STRIDE-per-Element」のほかに、信頼境界を通過するインターフェースの相互作用に着目して脅威を抽出する「STRIDE-per-Interaction」アプローチも採用される7。後者は不要なアラート（偽陽性）を削減し分析時間を短縮できる一方で、モデラーに高度なアーキテクチャ解釈能力を要求する7。Microsoft Threat Modeling ToolやOWASP Threat Dragonといった自動化ツールは、これらのマッピングロジックをエンジン内部に保持しており、ユーザーがダイアグラムを描画することで自動的に脅威リストを算出・提示する機能を備えている9。

多角的脅威分析手法の体系的概要

STRIDEがソフトウェアアーキテクチャの構造的セキュリティ分析において優れた成果を上げる一方で、ビジネスリスクの計量、プライバシー保護要件、アジャイル開発との統合、あるいは組織全体のガバナンスといった異なる要求水準に応えるため、多角的な脅威分析手法が考案・運用されている1。

PASTA（Process for Attack Simulation and Threat Analysis）

2012年にTony UcedaVélezらによって提唱されたPASTAは、ビジネス目標と技術的対策を強固に紐付けることを目的に設計された全7段階のリスク指向型（Risk-Centric）脅威モデリングフレームワークである1。システムに対する技術的な脆弱性抽出にとどまらず、攻撃者の視点（Attacker-Centric）に立った攻撃シミュレーションを行い、脆弱性が顕在化した際のビジネスインパクトに基づいて対策の投資優先順位を決定する点に本質的特徴がある1。
PASTAのプロセスは体系的な7つのステージで構成される5。

ステージ1（Define Objectives）では、保護すべきビジネス目標、コンプライアンス要件、および事業影響度（BIA）を明確化する5。
ステージ2（Define Technical Scope）では、対象システムのスコープ、境界、構成コンポーネント、およびインフラの依存関係を収集する5。
ステージ3（Application Decomposition）では、データフロー図（DFD）の作成を通じて信頼境界、エントリポイント、およびアセットの抽出を行う5。
ステージ4（Threat Analysis）では、外部の脅威インテリジェンスを取り入れ、該当システムを狙う脅威エージェントや最新の攻撃トレンドを整理する5。
ステージ5（Vulnerability & Weakness Analysis）では、既知の脆弱性（CVE）や設計上の弱点（CWE）をマッピングし、システムの不備を洗い出す5。
ステージ6（Attack Modeling）では、攻撃ツリーや攻撃シナリオを用いて実際の攻撃経路をシミュレートする5。
ステージ7（Risk & Impact Analysis）において、成功した攻撃のビジネス被害額やリスク露出度を計量し、最も費用対効果の高い緩和策を選択する1。

LINDDUN

ルーヴェン・カトリック大学（KU Leuven）の研究者らによって開発されたLINDDUNは、セキュリティ脅威ではなく「プライバシー脅威」の特定に特化したフレームワークである19。STRIDEと同様にデータフロー図（DFD）を基盤構造として使用するが、システムのセキュリティ属性破壊ではなく、データ主体（個人）のプライバシー権利に対する侵害リスクを検出することを目的とする17。
LINDDUNの名称は、以下の7つのプライバシー脅威カテゴリーの頭文字に由来する16。

Linkability（紐付け可能性）: 異なる2つ以上のデータ項目や操作ログを結びつけることで、データ主体のプロファイリングや特定が可能になるリスク16。
Identifiability（特定可能性）: データセット内から直接的または間接的に個人の身元が識別されてしまうリスク16。
Non-repudiation（否認可能性）: ユーザーが過去の行動やデータ送信の事実を否定できないことにより、プライバシーが侵害されるリスク（セキュリティとは逆の概念）16。
Detectability（検出可能性）: データの存在そのものや特定の通信の発生が第三者に察知されるリスク16。
Disclosure of information（情報開示）: センシティブな個人データ（PII）が権限のない第三者に参照・漏洩するリスク16。
Unawareness（不認知）: ユーザーが自身の個人データの収集・利用目的・処理状況について適切な通知を受けておらず、制御できないリスク16。
Non-compliance（不適合）: GDPR（EU一般データ保護規則）をはじめとする各種法規制やプライバシーポリシーに対する違反リスク16。

TRIKE

TRIKEは、セキュリティ監査の信頼性と再現性を高めることを目的に開発された、定量的かつリスクベースの脅威モデリングフレームワークである3。防衛側の視点からシステム要件を定義することに焦点を当てており、モデルは「要求モデル（Requirements Model）」と「実装モデル（Implementation Model）」の2つの領域で構成される21。
要求モデルの構築においては、システムのアクター（Actor）、資産（Asset）、意図された行動、およびルールを列挙し、アクターと資産の組み合わせに対するアクセス権限をCRUD（Create, Read, Update, Delete）の操作単位で定義した「アクター/資産/行動マトリクス」を生成する3。実装モデルで描かれたDFDとこのマトリクスを突き合わせることで、システム内のルールに違反する潜在的脅威（主に特権昇格やDoS）を自動的に生成し、5段階の確立・影響度スケールを用いて定量的リスク判定を行う構造を持つ3。

VAST（Visual, Agile, and Simple Threat）

VASTは、エンタープライズ規模の組織や、DevSecOpsおよびアジャイル開発環境への適用を目指して開発された脅威モデリング手法である3。従来の脅威モデリングが専門家の知識に依存しスケーラビリティに欠けるという課題を解決するため、統合された視覚的インターフェースと自動化機能を重視している3。VASTはシステムモデルを「アプリケーション脅威モデル（開発者・設計者向け）」と「インフラストラクチャ脅威モデル（運用・インフラ担当者向け）」の2つの視点に明示的に分離し、アジャイルの開発スプリントのスピードを阻害することなくスケールすることを可能にする3。

Attack Trees（攻撃ツリー）および DREAD

Attack Trees（攻撃ツリー）: Bruce Schneierによって提唱された階層型ダイアグラム手法であり、攻撃者の最終目標（ルートノード）を頂点に置き、それを達成するための具体的な攻撃手法や前提条件を「AND/OR」の論理ゲートを用いて分岐ノードへ展開する1。システム全体の横断的脅威抽出には適さないが、特定の高価値資産に対する攻撃経路の深堀り（深度の追及）において極めて高い効果を発揮する12。
DREAD: Microsoftの初期SDL等でSTRIDEと併用されたリスク定量化スコアリング手法である10。Damage potential（損害規模）、Reproducibility（再現性）、Exploitability（攻撃容易性）、Affected users（影響ユーザー数）、Discoverability（発見容易性）の5つの軸で各脅威を1〜10点で採点し、その平均値によって脅威の優先順位を決定する13。数値化による単純化が可能である一方、評価者の主観に依存しやすい傾向がある13。

OCTAVE（Operationally Critical Threat, Asset, and Vulnerability Evaluation）

カーネギーメロン大学ソフトウェア工学研究所（SEI）によって開発されたOCTAVEは、組織全体のアセット、ビジネスプロセス、および人的要素を含めた戦略的リスク評価フレームワークである1。技術的インフラのコードレベル分析に留まらず、組織内部のワークショップを通じて経営リスクを整理するため、全社的なセキュリティガバナンスやリスクアセスメントの文脈で利用される1。

脅威分析手法の包括的比較と構造的相互作用

個々の脅威分析手法は、ターゲットとする分析対象、抽象度、ならびに評価視点において明確な違いを有している3。組織の要求水準、開発体制、および規制要件に応じて最適手法を選択するためには、これらを多角的に比較することが不可欠となる3。
以下の比較表は、主要な脅威分析手法の構造的特性、モデル化の基盤、推奨される適用領域、強み、および限界を統合したものである1。

手法名	分析の視点・アプローチ	モデル化の基礎構造	推奨される適用フェーズ・領域	主要な強み	限界・構造的課題
STRIDE	セキュリティ属性中心（技術的・設計指向）1	データフロー図（DFD）と信頼境界4	ソフトウェア設計・アーキテクチャ検討フェーズ1	構造的ルールに基づく高い網羅性。エンジニアになじみやすい概念10。	ビジネス被害の評価軸がなく、大量の定型脅威（ノイズ）が発生しやすい1。
PASTA	リスク・ビジネス中心（攻撃者シミュレーション）1	7段階の多角的ステージモデル5	全社的リスク管理、高要件・コンプライアンス領域3	ビジネス目標と技術的脅威の直接的統合。投資対効果の明確化1。	プロセスが極めて重厚であり、導入・運用に多大な時間と専門性が必要1。
LINDDUN	プライバシー保護中心16	DFDおよびプライバシー脅威ツリー19	個人情報（PII）取扱システム、GDPR等適合要件3	プライバシーバイデザインの確実な実現。法規制リスクの特定3。	システム全体の技術的脆弱性（DoSや権限昇格等）の網羅的評価には不向き16。
TRIKE	防衛者・ルール中心（定量的リスク監査）3	アクター/資産 CRUDマトリクス3	権限構造が複雑なシステム、自動化監査環境21	要求定義に基づく形式的・自動的な脅威生成。監査の再現性21。	ツールの更新頻度が低く、初期モデル作成の学習曲線が非常に急峻21。
VAST	アジャイル・エンタープライズ中心3	アプリ/インフラ視点分離型ビジュアル図3	大規模組織、DevSecOps、アジャイル開発チーム3	視覚的で直感的。開発スピードを阻害せず大規模拡張が可能3。	特定ベンダーの商用ツール基盤に依存する傾向が強い3。
Attack Trees	攻撃目標中心（目標達成パス分析）12	階層型AND/OR論理ツリー構造12	高価値資産の特定攻撃経路分析、詳細評価12	クリティカルな攻撃シナリオにおける論理的深掘りとパスの可視化12。	システム全体の横断的評価には不向き（ツリー構築に多大なコスト）15。
DREAD	脅威優先度付け（定量的スコアリング）13	5軸の数理評価（1〜10点マトリクス）13	脅威抽出後のリスク判定・優先度設定12	定量的な数値による対策優先順位付けの容易性12。	採点基準における主観性が高く、評価者間のばらつきが大きい15。
OCTAVE	組織・ガバナンス中心1	ワークショップベースの資産リスク評価1	経営層主導のITガバナンス、全社リスク評価1	人的・プロセス要素を含む組織全体のアセットリスク把握1。	コードレベルやアーキテクチャの具体的技術対策への落とし込みが難しい1。

手法間の比較分析から、技術的網羅性とビジネスコンテキストの統合という構造的課題が浮かび上がる1。STRIDEはエレメントに基づく分類ルールにより極めて高い技術的網羅性を提供するが、抽出された大量の脅威が「実際の事業にどれほどの被害を与えるか」というビジネス文脈を評価する仕組みを内包していない1。この結果、現場の開発チームが軽微な脅威への対処に追われ、開発コストが増大する現象が生じやすい1。これに対しPASTAは、初期フェーズにおいてビジネス目標と事業影響度を明示的に定義することにより、抽出された脅威をビジネスリスクの観点から自動的に絞り込む1。実務においては、STRIDEの網羅的抽出能力とPASTAやDREADのリスク優先度評価を組み合わせるハイブリッドアプローチが有効に機能する12。
さらに、セキュリティとプライバシーの統合という視点も不可欠となっている3。GDPRに代表される法規制環境のもとでは、データ漏洩の防止（セキュリティ）だけでなく、データが適法かつ透明性を維持して処理されているか（プライバシー）の双方が問われる3。STRIDEによる機密性（Confidentiality）の防護と、LINDDUNによる不認知（Unawareness）や紐付け可能性（Linkability）の排除は相互補完の関係にあり、同一のデータフロー図（DFD）を活用して両モデルを適用する多角的アセスメントの実践が増加している3。
アジャイル開発やDevSecOpsへの適応性も大きな課題である1。ウォーターフォール型の開発に適した重厚なモデルは、迅速なデプロイを反復する現代のソフトウェアエンジニアリングにおいてボトルネックとなり得る1。これに対し、ユーザーストーリー単位で軽量に脅威を抽出するプラクティスや、VASTのように開発者とインフラ運用者の視点を分離して自動化を図る手法が、開発速度とセキュリティのバランスを維持するための手段として台頭している3。

結論と適用ロードマップ

脅威モデリングは、セキュアなシステムアーキテクチャを構築する上で不可欠な設計プラクティスであり、単一の手法ですべてのセキュリティ的・組織的要求を満たすことはできない2。STRIDEは現在も最も広範に採用されている技術的脅威の分類体系であり、ソフトウェア開発における基礎的枠組みとして中心的な役割を果たし続けている8。
組織が自社の開発環境、リスク耐性、および法規制要件に応じて手法を選択し適用するためのロードマップは、以下のように体系化される。
標準的なソフトウェアアーキテクチャの構築や、開発チーム主導で迅速にセキュリティ設計を開始する環境においては、STRIDEを中心的アプローチとして採択することが望ましい3。データフロー図（DFD）を作成し、信頼境界を交差するエレメントに対してSTRIDE-per-Elementを適用することで、基礎的なセキュリティ要件を漏れなく抽出することが可能となる7。
個人識別情報（PII）やセンシティブな顧客データを大量に取り扱うアプリケーションにおいては、STRIDEの適用と並行してLINDDUNを導入するアプローチが推奨される3。これにより、セキュリティ上の堅牢性を維持しながら、データ主体の権利侵害や法令違反リスクを段階的に低減させることができる3。
金融、医療、重要インフラなど、障害や侵入が破滅的な事業被害をもたらすシステム、あるいは厳格なコンプライアンスが要求される環境においては、PASTAを採用することが適切である3。ビジネス目標の定義から攻撃シミュレーションまでを行うことで、経営層が納得する投資対効果に基づいたセキュリティ管理を実現できる1。さらに、特定のアセットに対する極めて高度な標的型攻撃パスに対しては、Attack Treesを用いた局所的な深掘り分析を組み合わせることが効果的である12。
継続的デプロイメントを前提とするアジャイル・DevSecOps環境においては、VASTの考え方やOWASP Threat Dragon等のオープンソースツールの活用を通じて、脅威モデリングを開発スプリントおよびCI/CDパイプラインへと統合するアプローチが重要となる3。脅威モデリングを固定化されたドキュメント作成作業としてではなく、システムの変更に応じて継続的に更新される動的な設計プロセスとして定着させることが、現代のサイバー脅威に対する組織的な防御力を維持するための鍵となる2。

引用文献

A Short History of Threat Modeling - Necessary Security LLC., https://www.necessarysecurityllc.com/post/a-short-history-of-threat-modeling

Threat Modeling | OWASP Foundation, https://owasp.org/www-community/Threat_Modeling

10 Types of Threat Modeling Methodology To Use in 2026 - Practical DevSecOps, https://www.practical-devsecops.com/types-of-threat-modeling-methodology/

Threat Modeling Process (Historical) - OWASP Foundation, https://owasp.org/www-community/Threat_Modeling_Process

PASTA（Process for Attack Simulation and Threat Analysis）とは｜シス担のミカタ, https://kobesoft.co.jp/mikata/words/security/pasta-threat-modeling/

What Is Threat Modeling? Key Steps and Techniques | Exabeam, https://www.exabeam.com/blog/infosec-trends/top-8-threat-modeling-methodologies-and-techniques/

STRIDE-per-Interaction, https://www.ffri.jp/assets/files/monthly_research/MR201610_STRIDE_Variants_and_Security_Requirements-based_Threat_Analysis_ENG.pdf

Using the STRIDE Threat Model: Tutorial & Best Practices - Drata, https://drata.com/learn/risk/stride-threat-model

Threat Model (STRIDE DFD) - Schematex, https://schematex.js.org/docs/threatmodel

STRIDE Threat Model Components: Complete Guide To 6 Categories - PassITExams, https://passitexams.com/articles/stride-threat-model-components/

STRIDE Threat Model: The Complete Guide to Microsoft's Security Framework | Trent AI, https://trent.ai/blog/stride-threat-model/

Threat Modeling Explained: STRIDE in Practice - Strobes Security, https://strobes.co/blog/threat-modeling-explained-stride/

A Comparative Analysis of Threat Modelling Methods: STRIDE, DREAD, VAST, PASTA, OCTAVE, and LINDDUN - TechRxiv, https://www.techrxiv.org/doi/pdf/10.36227/techrxiv.173014171.11449253/v1

OWASP Threat Dragon, https://owasp.org/www-project-threat-dragon/

Threat Modeling: Which Method Should You Choose for Your Company? (Stride, Dread, QTMM, LINDDUN, PASTA) - CBTW, https://cbtw.tech/insights/threat-modeling-which-method-should-you-choose-for-your-company-stride-dread-qtmm-linddun-pasta

Threat Modelling / Cyber Threat Intelligence SIG Curriculum, https://www.first.org/global/sigs/cti/curriculum/threat-modelling

Mastering Threat Modeling: An In-Depth Guide to Frameworks, Methodologies, and Best Practices | by Okan Yıldız | Medium, https://medium.com/@okanyildiz1994/mastering-threat-modeling-an-in-depth-guide-to-frameworks-methodologies-and-best-practices-b5b9d043032f

PASTA Threat Modeling: The 7 Stages Explained - VerSprite, https://versprite.com/cybersecurity-listings/devsecops/pasta-threat-modeling/

Introducing the Cyber-Physical Data Flow Diagram to Improve Threat Modelling of Internet of Things Devices - arXiv, https://arxiv.org/html/2604.22307v1

linddun.org | Privacy Engineering, https://linddun.org/

Trike v.1 Methodology Document $D r a f t$ - Help Net Security, https://img2.helpnetsecurity.com/dl/articles/Trike_v1_Methodology_Document-draft.pdf

Trike Threat Modeling: Definition, Stages, And Benefits | EC-Council, https://www.eccouncil.org/cybersecurity-exchange/threat-intelligence/trike-threat-modeling-methodology/

Trike Threat Modeling, https://threat-modeling.com/trike-threat-modeling/

What Is Threat Modeling? Key Steps and Techniques | Exabeam, https://www.exabeam.com/ja/blog/infosec-trends/top-8-threat-modeling-methodologies-and-techniques/

Top Threat Modeling Methodologies - ZenGRC, https://www.zengrc.com/blog/top-threat-modeling-methodologies/

What Is Threat Modeling? - Cisco, https://www.cisco.com/site/us/en/learn/topics/security/what-is-threat-modeling.html

A Comparative Analysis of Threat Modelling Methods: STRIDE, DREAD, VAST, PASTA, OCTAVE, and LINDDUN - Cardiff Metropolitan University Research Explorer, https://pure.cardiffmet.ac.uk/en/publications/a-comparative-analysis-ofthreat-modelling-methods-stride-dread-va/