Shutterstock.com

アプリケーションの脅威モデリング（ソフトウェア・アプリケーションのセキュリティリスクを特定、分析、軽減する活動）は長年にわたって誤解されてきた。製品チームと協力してアプリケーションの脅威モデリングを導入しようとするセキュリティ部門のリーダーたちは、これを単なるコンプライアンスのチェックリストとして捉える関係者や、過度に形式化され複雑化した過去の手法に直面することになる。だがセキュリティの専門家たちは、効果的で効率的、かつ再現可能な脅威モデリングのアプローチを見つけるために、相反するフレームワークや手法を検討しつつ、自分自身の「良い脅威モデル」とは何かという先入観を取り除く必要がある。 私は、実務者たちと対話を重ね、アプリケーションの脅威モデリングに関する最も一般的な誤解を明らかにし、それを解消するのに役立つ知見を得た。以下にそのうちの3つを紹介する。 ■誤解1：脅威モデリングフレームワークは必ず使用しなければならない STRIDEやDREADは最もよく知られている脅威モデリングのフレームワークであり、PASTA、VAST、LINDDUNなども知られている。しかし、知られているからといって採用されているわけではない。私たちがインタビューした多くの人々は、これらの標準的なフレームワークを一切使用せず、ホワイトボードを用いた議論、ディスカッション、決定木、または特定のアプリケーションがどのように機能するかを理解するための簡単な対話の方を好んでいた。また、『Threat Modeling Manifesto（脅威モデリング宣言）』の著者たちでさえ、特定のフレームワークの推奨を避け、「方法論に依存しない」と述べている。 しかし、フレームワークが役立つ場面もある。例えば、脅威モデリングの取り組みが経験の浅いセキュリティ担当者や、セキュリティに不慣れな開発者によって主導される場合、正式なフレームワークは指針と構造を提供してくれる。ただし、フレームワークを無理に適用する必要はない。フレームワークなしでも脅威モデリングの目標を達成することは十分に可能だ。