社内には構築・デプロイされているアプリケーションが1つや2つ、あるいは10、さらには100はあるかもしれません。そして、これからそれらのアプリケーションを対象とした脅威モデルを構築しようとしています。それはなぜでしょう? 以下で検討していきましょう。
それはアプリケーションの開発時点から存在していた潜在的な欠陥を発見するためです。さらに、まさに今開発チームが開発中の新しいアプリケーションもあります。この新しいアプリケーションについても脅威モデルを構築する必要があるでしょう。
脅威モデリングは、古いアプリケーションか新しいアプリケーションかを問わず、アプリケーションに影響するリスクと欠陥を特定します。ソフトウェアアーキテクチャ、事業状況、成果物(機能仕様書やユーザードキュメントなど)の徹底した分析を行うことにより、企業のセキュリティおよび品質関連の重要な問題を見つけることが可能になります。
脅威モデリングのプロセスは、システムの特性を考える手段となる戦略的方法を提供します。また、アプリケーションに対してだけでなく、場合によっては組織全体に影響する可能性がある脆弱性を可視化します。
脅威モデルの構築には数週間かかることがあります。脅威モデリングを行うチームが欠陥を探すためにとる方法は、社内で採用するSDLC手法に応じて調整が必要になる場合があります。どのような手法を利用する場合でも、設計の欠陥の特定・解決は無視できません。
こうした欠陥を特定して解決するには、脅威モデルを構成する主なアクティビティに次の5つがあることを理解しておく必要があります。
アーキテクチャが決まったら、なるべく早い段階で脅威モデリングを実施するのが理想的ですが、現実は理想どおりにいくとは限りません。いつの時点で脅威モデリングを行うにしても、SDLCの後工程へ進むほど問題解決のコストは一般に増大することを認識しておいてください。
攻撃の可能性を発見して脆弱性を阻止する時期が早いほど、解決にかかる時間/コスト面の効率が高くなります。セキュリティは後から追加するよりも組み込む方が望ましいことを覚えておいてください。とはいえ、繰り返しになりますが、常に理想どおりに事が運ぶとは限らず、すべてのアプリケーションの脅威モデリング評価が開発時に行われるとは限りません。それでも心配要りません。まだ希望はあります。
脅威モデリングは、なるべく早期に行うことが推奨されますが、アプリケーションのデプロイ間近でも、あるいは本番稼働が始まってからでも、きわめて有益なアクティビティであることに変わりはありません。アプリケーションが開発サイクルの終盤に入ってからでも、サポート工程で脅威モデリングを採用できます。
脅威モデリングはシステムの欠陥の可能性に関する視点を提供してくれます。また、徹底した評価により、組織はアプリケーションの設計レベルのセキュリティの現状を知ることができます。そのため、徹底した脅威モデリングによってシステムへのさらなる投資について的確な情報に基づく意思決定を行うことができます。