有用な脅威モデルは、何を保護し、誰または何がそれに影響を与え得るか、信頼がどこで変化するか、最も重要なリスクをどのように低減しテストするかを説明します。一般的なツールのリストではなく、実際のプロジェクトから始めてください。
推論できるほど小さなスコープを定義する
1つの稼働中のサービスから始めます。顧客ポータル、公開サイト、または内部アプリケーションです。あなたが運用するコンポーネントと、依存する外部システムを書き出します。脅威モデルは仮定を可視化するものであり、考えられるすべての攻撃が解決されたと示唆するものではありません。最初のバージョンは、アプリケーションをデプロイする人々が、図を解釈する別のコンサルタントなしに説明できるほど小さく保ってください。
価値のある成果と資産を列挙します。これには顧客データ、管理アクセス、支払い状態、公開コンテンツ、サービスを復旧する能力が含まれる場合があります。情報が公開されていても、可用性は資産になり得ます。どの障害が不便で、どの障害が人々や組織に損害を与えるかを判断してください。その区別により、すべての警告を同等に扱うのではなく、管理策に優先順位を付けることができます。
信頼が変化する場所を描く
OWASPの脅威モデリングガイダンスは、データフローと信頼境界を使用して設計を理解しやすくします。小規模なホスト型アプリケーションの場合、ブラウザ、Webプロセス、データベース、管理者、バックアップ宛先、外部統合を描きます。それらの間を移動する情報をマークします。信頼されていないクライアントから特権サーバー操作へと越えるリクエストには、明示的な検証と認可が必要です。
同じマシン内にあるからといって、すべてのコンポーネントが等しく信頼されていると仮定しないでください。公開アップロードプロセスは、データベース管理と同じ権限を持つべきではありません。バックアップジョブは、稼働中のアプリケーションレコードを変更する能力なしに読み取りアクセスを必要とする場合があります。それらの役割を分離することで、侵害されたコンポーネントの影響を封じ込めやすくなり、必要な権限を確認しやすくなります。
具体的な障害シナリオを選ぶ
いくつかのもっともらしい出来事を使って設計に挑戦してください。攻撃者が管理者パスワードを盗む。ユーザーが別のユーザーのレコードを要求する。アップロードがディスクを満杯にする。デプロイが構成ファイルを露出する。リカバリコピーが復元できない。開始条件、影響を受けるコンポーネント、結果を説明してください。具体的なシナリオは、セキュリティを改善するという広範な指示よりもテストしやすいです。
外部からの侵入だけでなく、ミスや正当なワークフローの悪用も含めてください。再試行が2つの価値ある操作を生み出すことや、2つのリクエストが同じオブジェクトを変更しようと競合することがあります。OWASPのビジネスロジックガイダンスは、これらのプロセスの仮定を強調しています。誰がワークフローを次の状態に移行できるか、リクエストの繰り返しや順序変更が結果を予期せず変えるかどうかを確認してください。
| シナリオ | 調査する管理策 | 収集する証拠 |
|---|---|---|
| 管理者資格情報の盗難 | サポートされている場合はアクセス制限と第二要素 | 不正なログインが完了できない |
| 別のユーザーのオブジェクトが要求される | サーバー側のオブジェクト認可 | 分離されたテストが拒否結果を返す |
| アップロードによるディスク枯渇 | サイズ、クォータ、保持の管理 | サービス障害の前に制限が適用される |
| 重複したワークフローリクエスト | 冪等性とトランザクション境界 | 繰り返されたリクエストが1つの結果を生む |
影響と信頼できる経路で優先順位を付ける
各シナリオについて、潜在的な影響とそれが発生するために必要な条件を記録します。推測された数値スコアが正確な確率であるかのように装うことは避けてください。それでも、インターネットに露出した弱いパスワードと、条件が厳しいローカルイベントを区別することはできます。重要なリスクに担当者と実践的な次のステップを割り当て、モデルが誰かが実際に完了できる作業を生み出すようにしてください。
アプリケーションの侵害だけでなく、情報のライフサイクルも考慮してください。診断エクスポートは、通常の運用中に不必要なデータを開示する可能性があります。保持されたアカウントフィールドは、その目的が終わったずっと後まで露出を生み出す可能性があります。したがって、プライバシーレビューは情報を削除したり保持期間を短縮したりでき、セキュリティレビューは残ったものへのアクセスを制限します。両方の変更は、プロジェクトを保護する場合にモデルに含めるべきです。
承認された環境で管理策をテストする
代表的な権限と架空のレコードを備えたステージング環境を作成します。拒否されたアクセス、リクエスト制限、ワークフローの再試行、リカバリをテストします。合成データで動作を実証できる場合は、実際の顧客データを使用しないでください。目的は管理策を検証することであり、印象的な攻撃トラフィックを生成することではありません。所有している、または明示的に評価を許可されているシステム内に留まってください。
何が合格し、何が失敗し、何が不明のままかを記録します。スキャナの結果は証拠に寄与できますが、アプリケーションのビジネスルールのテストを置き換えるものではありません。同様に、ネットワーク保護オプションはオブジェクト認可や秘密ファイルの取り扱いを検証しません。有用な結果をシナリオに添付し、将来の保守担当者が特定の管理策が存在する理由を理解できるようにしてください。
モデルを変更に結び付けておく
統合を追加する、新しいエンドポイントを公開する、権限を変更する、データを別の宛先に移動する場合は、関連する部分をレビューします。軽微なテキスト編集のためにアーキテクチャ全体を描き直す必要はありません。トリガーは、アクセス、情報、またはシステム動作に関する仮定の変更です。モデルは、一度きりのワークショップの成果物として残すのではなく、デプロイとリカバリのドキュメントのそばに置いてください。
SwissOctetはインフラストラクチャの選択肢のカタログを提供するものであり、完成したアプリケーションの脅威モデルではありません。あなたの管理策を支える構成とオプションを選択し、構築したデプロイを検証してください。テストされたアクションを伴う小さく維持されたモデルは、対処するリスクを明確に説明しないセキュリティ製品の大規模なコレクションよりも有用です。
実践チェックリスト。
- 資産と障害の結果を列挙します。
- データフローと信頼境界を描きます。
- 具体的な侵入、ミス、ワークフローのシナリオを選びます。
- 重要なリスクに管理策と担当者を割り当てます。
- 承認された環境で合成データを使用してテストします。
- 関連する仮定が変更されたときにモデルをレビューします。
重要な詳細。
始めるために正式なフレームワークが必要ですか？+
いいえ。小さな図と文書化されたシナリオのセットが役立ちます。フレームワークは、リスクを一貫してレビューするのに役立ちます。
脆弱性スキャナは脅威モデリングを置き換えますか？+
いいえ。スキャナは技術的な弱点を見つけることがありますが、脅威モデルは設計の仮定、権限、ビジネスワークフローも検討します。
モデルはどのくらいの頻度で更新すべきですか？+
データフロー、統合、権限、または公開機能が変更されたときは影響を受ける部分を更新し、未解決のリスクを定期的にレビューしてください。
出典へ。
これらの参考文献は、このガイドの技術的概念をサポートしています。本番システムを変更する前に最新のドキュメントを確認してください。
- OWASP：脅威モデリングチートシート cheatsheetseries.owasp.org
- OWASP：実践における脅威モデリング devguide.owasp.org
- OWASP：ビジネスロジックセキュリティ cheatsheetseries.owasp.org
SwissOctetによる編集ガイダンス。例は例示目的です。サービス仕様、利用可能なオプション、契約条件は別途確認する必要があります。