アプリケーションの脅威分析
総合的な分析を行って、脅威、攻撃、脆弱性、対策を明らかにします。 この情報を得ることにより、アプリケーションを保護し、それによってシステムにもたらされる可能性がある脅威を防ぐことができます。 簡単な質問から始めて、潜在的なリスクについての分析情報を得ます。 その後、脅威モデリングを使用した高度な手法に進みます。
1 - 基本的なセキュリティ制御に関する情報を収集する
脅威モデリング ツールにより、特定されたすべての脅威のレポートが生成されます。 通常、このレポートは、開発者が検証して対処できる追跡ツールにアップロードされるか、作業項目に変換されます。 ソリューションに新機能が追加された場合、脅威モデルを更新し、コード管理プロセスに統合する必要があります。 セキュリティの問題が見つかった場合は、問題の重要度をトリアージし、修復するタイミングと方法 (次のリリース サイクルで修復する、または迅速にリリースするなど) を決定するためのプロセスが必要になります。
最初に、アプリケーションの各コンポーネントに関する情報を収集します。 これらの質問に対する回答により、基本的な保護に存在するギャップが特定され、攻撃ベクトルが明らかになります。
| 行う質問 | 特定する制御 |
|---|---|
Azure AD、TLS (相互認証を使用)、またはセキュリティ チームによって承認されたそれ以外の最新のセキュリティ プロトコルを使用して、接続が認証されていますか?
|
アプリケーションのコンポーネントとデータへの不正アクセスを防止します。 |
| アプリケーションでデータの書き込みまたは変更を行う必要があるアカウントについてのみ、アクセスを制限していますか | 不正なデータの改ざんまたは改変を防止します。 |
| Azure Monitor または同様のソリューションにより、アプリケーションのアクティビティをログに記録し、セキュリティ情報イベント管理 (SIEM) にフィードしていますか? | 攻撃を迅速に検出して調査します。 |
| クリティカルなデータは、セキュリティ チームが承認した暗号化によって保護されていますか? | 保存データが不正にコピーされないようにします。 |
| 受信および送信ネットワーク トラフィックは TLS を使用して暗号化されますか。 | 転送中のデータが不正にコピーされないようにします。 |
| アプリケーションは、Azure の DDoS 保護のようなサービスを使用して、分散型サービス拒否 (DDoS) 攻撃から保護されていますか? | アプリケーションをオーバーロードさせて使用不可能にするように設計された攻撃を検出します。 |
| アプリケーションには、他のアプリケーション、データベース、またはサービスにアクセスするためのログオン資格情報またはキーが格納されていますか? | 攻撃がそのアプリケーションを使用して他のシステムを攻撃できるかどうかを識別します。 |
| アプリケーションの制御を使用して、規制要件を満たすことができますか? | ユーザーのプライベート データを保護し、コンプライアンスの罰金を回避します。 |
推奨されるアクション
脅威モデリング中に特定されたリスクを担当する個々のユーザーにタスクを割り当てます。
詳細情報
2 - アプリケーションの設計を段階的に評価する
アプリケーションのコンポーネントと接続およびそれらの関係を分析します。 脅威モデリングは重要なエンジニアリング演習であり、セキュリティ要件の定義、脅威の識別と軽減、それらの軽減策の検証が含まれます。 この手法は、アプリケーションの開発や運用のどの段階でも使用できますが、新しい機能の設計段階で使用するのが最も効果的です。
よく使用される手法は次のとおりです。
- STRIDE:
- スプーフィング
- 改ざん
- 否認
- 情報漏えい
- サービス拒否
- 特権の昇格
Microsoft セキュリティ開発ライフサイクルにおいては、STRIDE が使用され、このプロセスを支援するツールが提供されています。 このツールは、追加料金なしで利用できます。 詳細については、「Microsoft Threat Modeling Tool」を参照してください。
- Open Web Application Security Project (OWASP) によって、アプリケーション向けの脅威モデリング アプローチが文書化されています。
セキュリティで保護された操作を使用して、オートメーションにより脅威モデリングを統合します。 次にリソースをいくつか示します。
- Azure でのセキュリティで保護された DevOps 向けのツールキット。
- OWASP による DevOps パイプライン セキュリティに関するガイダンス。
3 - 特定された脅威を軽減する
脅威モデリング ツールにより、特定されたすべての脅威のレポートが生成されます。 潜在的な脅威を特定したら、その攻撃を検出して対応する方法を決定します。 ワークロード内の特定の脆弱性に対する露出を最小化するプロセスとタイムラインを定義し、これらの脆弱性が確実に解消されるようにします。
"多層防御" アプローチを使用します。 これは、主要なセキュリティ制御が失敗した場合にリスクを軽減するために、設計に必要な制御を特定するのに役立ちます。 主要な制御が失敗する可能性を評価します。 そうである場合、組織に対して可能性のあるリスクの範囲はどの程度ですか。 また、制御を追加した場合の有効性はどれくらいですか (特に、主要な制御が失敗する場合)。 評価に基づいて、セキュリティ制御が失敗する可能性に対処するため、多層防御手段を適用します。
"最小限の特権" の原則は、多層防御を実装する方法の 1 つです。 これにより、1 つのアカウントで実現できる損害が制限されます。 最小限の数の特権をアカウントに付与し、一定の期間内に必要なアクセス許可を使用して実現できるようにします。 これにより、セキュリティ保証を侵害するためにアカウントへのアクセス権を獲得した攻撃者による損害を軽減できます。
重要なワークロードのビジネス要件に関しては、組織のリーダーと技術チームの間でしばしば齟齬が発生します。 このことは、意図しない結果を引き起こす可能性があり、特に情報セキュリティに関することの場合は慎重になる必要があります。 エグゼクティブ スポンサーと共にビジネス クリティカルなワークロードの要件を定期的に確認し、要件を定義することで、予測内容を揃え、イニシアチブに対する運用リソースの割り当てを確保することができます。
発見された脅威をどのように解決するか?
いくつかのベスト プラクティスを次に示します。
- 関係のあるチームに結果が確実に伝達されるようにします。
- 脆弱性に優先順位を付け、最も重要なものを適切なタイミングで修正します。
- 脅威モデリング レポートを追跡ツールにアップロードします。 開発者が検証して対処できる作業項目を作成します。 サイバー セキュリティ チームも、侵入テストの間にレポートを使用して攻撃ベクトルを特定できます。
- アプリケーションに新しい機能が追加されたら、脅威モデル レポートを更新して、コード管理プロセスに統合します。 重要度に応じて、次のリリース サイクルまたはより高速なリリースにセキュリティの問題をトリアージします。
軽減戦略については、RapidAttack に関するページを参照してください。
セキュリティ修正プログラムを運用環境にデプロイするには、通常、どのくらいの時間がかかるか?
セキュリティの脆弱性が検出された場合、できるだけ早く修正プログラムを使用してソフトウェアを更新します。 修正プログラムを速やかにロールアウトするためのプロセス、ツール、承認を用意しておきます。