1. セキュリティの目標を設定する

　目標設定に当たっては、「対象範囲をどうするか」「決定的に重要なものは何か」「経営陣やセキュリティポリシー、さらには顧客やビジネスパートナーが何を要求しているか」を明確にする。また、関係者全員に共通認識を浸透させ、期待を適切に管理する。

2. アプリケーションの全体的なアーキテクチャを文書化する

　ユーザーからWebサーバへ、Webサーバからアプリケーションサーバへ、アプリケーションサーバからデータベースサーバへといった情報の流れも記述する。

3. 本当に保護しなければならないものは何かを見極める

　例えば、ユーザーのログイン資格情報、セッション情報、ソースコード、アプリケーションロジック、そして（保護しなければならない最たるものである）顧客情報などが挙げられる。

4. 保護する必要があるさまざまなエントリポイントと「信頼」ゾーンを特定する

　例えば、ユーザー認証、ユーザー管理、システムロギング、サーバやアプリケーション保守、重要なアプリケーションおよびデータベースのインタフェースなどがある。

5. 悪用が可能な問題を発見する

　信頼されていない外部者と、信頼されているユーザーの両方の立場から、攻撃者の視点で探す。

　あなたのチームがいかに綿密な分析を行っても、いかに優れたツールを使っても、すべての問題を見つけたり考慮に入れることは決してできないだろう。だが、それで問題ない。まずは基本を押さえよう。Webアプリケーションの脆弱性の大部分は、入力検証やシステム構成の問題、あるいは本来許可されていないようなアクセス権限を悪用する内部者に関連しており、このことを理解するのにそれほど時間はかからない。こうした脆弱性の例として次のようなものがある。

• 検索フォームや掲示板を使ってクロスサイトスクリプティングが行われる恐れがある
• SSLがアプリケーション全体で使われていない、あるいは強制されていない
• パスワード要件が緩い
• ログインに何度失敗しても、そのアカウントがロックアウトされない
• 余分な情報を含む認証エラーメッセージがユーザーに返され、ユーザー名とパスワードが知られてしまう
• 米国連邦金融機関検査協議会（FFIEC：Federal Financial Institutions Examination Council）の定める要件に従って実装された多要素認証プロセスが弱い
• セッションキーやクッキーが期限切れにならない、あるいは簡単に操作されてしまう
• URLやフォームフィールドの不正操作により、認証の回避や権限の昇格が発生してしまう
• 攻撃者にシステム侵入の足掛かりを与える機密情報がサーバエラーで返されてしまう

　米マイクロソフトのSTRIDEという脅威モデルを参考にするのもよいだろう。このモデルは、ほとんどのアプリケーションにかかわる重要な脅威を以下の6つのカテゴリーに分類したものだ。

• なりすまし（Spoofing identity）
• データの改ざん（Tampering with data）
• 否認（Repudiation）
• 情報漏えい（Information disclosure）
• サービス拒否（Denial of service）
• 権限の不正取得（Elevation of privilege）

6. 何が緊急で重要かを判断する

　各脆弱性について、攻撃が発生する可能性とその影響を見極め、それに基づいて判断を行う。常に念頭に置かなければならないのは、セキュリティ上の欠陥は、すべて同じように重大なわけではないということだ。最初はアプリケーションの最も機密性の高い部分や、最も機密性の高いシステムに含まれる悪用可能な脆弱性に重点的に対処すべきだ。攻撃が発生する可能性が高いが影響は小さい脆弱性もあるだろう。逆に、攻撃が発生する可能性は低いが、その影響が大きい脆弱性もあるだろう。攻撃が発生する可能性が高く、かつその影響が大きい脆弱性を特定し、そこから対策に取り組んでいくとよい。

　このように脆弱性の重大度を判断するために、DREADモデル──損害の可能性（Damage potential）、再現性（Reproducibility）、悪用の可能性（Exploitability）、影響を受けるユーザー（Affected users）、発見の可能性（Discoverability）──を利用できる。また、独自のリスク評価モデルを作成することも可能だ。いずれにしても長期的に、そしてアプリケーション間で一貫した分析を行わなければならない。

7. 各脆弱性について何ができるか、いつ解決できるかを判断する

　このステップでは、ステップ1のように目標を設定し、以降の作業につなげていく。一般に、選択肢は単純明快だ。脆弱性を修正する（コード変更かそのほかのセキュリティ対策によって）か、見つからないように隠すかだ（後者の対処がよく見られるが、ずっとそのままにしておいてはいけない）。

　問題を次のリリースで修正するか。6カ月以内に修正するか。あるいは放置するか。問題の重大度と修正の作業量に基づいて現実的に判断しなければならない。また、使い勝手に影響する形でセキュリティホールを「修正」する場合は、注意する必要がある。ハッキングされてしまうことを除けば、起こり得る最悪の事態は、使い勝手が変わって不満を募らせたユーザーがアプリケーションを使わなくなったり、厳しい管理を回避するようになり、そのためにセキュリティホールが発生してしまうことだ。

　脅威モデリングとは基本的に、Webアプリケーションを分析して、どのような情報がどのように流れるかを調べ、誰がいつ、何を行う可能性があるかを明確にし、起こり得る最悪の事態を想定することだ。これらはすべて手作業で行うこともできるし、AmenazaのSecurITreeのようなソフトウェアベースのモデリングツールを利用して行うこともできる。大規模な開発チームや複雑なアプリケーションを抱えている場合には、できればツールを使うことをお勧めする。そうすれば、一連のプロセスをスピードアップさせることができる上、モデリング結果を分かりやすい体裁で上司に提示することもできる。

　脅威モデリングは開発ライフサイクル全体に影響するため、なるべく設計フェーズで行わなければならない。設計の概要がまとまり、脅威モデリングが可能な段階になったら、すぐに着手するとよい。とはいえ、脅威モデリングによってプロジェクトの枠組みが変動したり、開発作業に支障が生じたりすることは避けなければならない。実際、開発者とマネジャーが脅威モデリングにこだわりすぎ、メリットよりもデメリットの方が大きくなる場合がよくある。特に、この試みを始める段階でそうなりがちだ。最初から完ぺきを目指し、あらゆる手を尽くして鉄壁のアプリケーションセキュリティを実現しようとしてはいけない。それでは結局空回りしてしまう。

　そうではなく、数年間のスパンの中でさまざまなプロジェクトを通じて、一連の手法を無理なく着実に実践しながら、脅威モデリングのノウハウを積み上げていけばよい。すべての問題を一挙に解決できるわけではないが、この堅実なアプローチにより、あなたのチームは多くの人の協力を得ながら、効果的な脅威モデリングに必要な手法と攻撃者の視点にスムーズに慣れていける。さらに、開発プロセスを改善し、あらかじめセキュリティ対策作業を組み入れることができ、後々セキュリティにあまり悩まずに済む。

本稿筆者のケビン・ビーバー氏は、米アトランタにあるPrinciple Logicを経営する独立系情報セキュリティコンサルタントで、執筆、講演も手掛ける。情報セキュリティに関する6冊の著書および共著書がある。