セキュリティ態勢を維持し進化させる
 継続的な改善を組み込み、攻撃戦略を継続的に進化させ続ける攻撃者の先を行くために警戒を続ける |
|---|
セキュリティ態勢は、時間の経過とともに低下してはなりません。 新しい混乱をより効率的に処理できるように、セキュリティ オペレーションを継続的に改善する必要があります。 業界標準で定義されているフェーズに合わせて改善に努めましょう。 そうすることで、準備状況が向上し、インシデント検出までの時間が短縮され、効果的な封じ込めと軽減が実現します。 継続的な改善は、過去のインシデントから得られた経験に基づく必要があります。
脅威が進化する中でセキュリティ態勢を継続的に改善するには、セキュリティ態勢を測定し、その態勢を維持するためのポリシーを適用し、セキュリティ軽減策と補正コントロールを定期的に検証することが重要です。
サンプル シナリオ
Contoso Race Day Performance は、プロのラリー カー レース チーム向けのデータ キャプチャ システムを作成します。 ほとんどのシステムは自動車に埋め込まれており、ドライビング クルーにローカル フィードバックを提供しますが、レースの最後にすべてのテレメトリがクラウドにアップロードされ、分析処理が行われます。 この処理では、トラックと環境条件と車両テレメトリ データがレポートに結合されます。これは、レース チームが実行を評価し、戦略を微調整するために使用できます。 クラウド システムにより、Azure Synapse Analytics で Azure Spark が使用されます。 ワークロード内の補助システムでは、すべて PaaS オファリングが使用されています。 このシステムは、世界の上位 5 つのレース チームのうち 3 チームによって既に使用されています。
各レース チームはデータを厳重に保護しており、データを侵害するおそれがある進化するセキュリティ上の脅威に対して最新の状態を保つために Contoso Race Day Performance が何を行っているかを知りたいと考えています。
脅威モデリングを実行して潜在的な脅威を特定して軽減する
ワークフローの各コンポーネントを分析し、各コンポーネントが受ける可能性がある潜在的な脅威を評価します。 業界標準の手法を使用して、特定された脅威を分類します。
このアプローチを採用すると、重大度レベルによって優先度付けされた攻撃ベクトルのレポートを生成できます。 さらに、脅威と脆弱性をすばやく特定し、対策を設定できます。
"Contoso の課題"
- まだ、彼らにセキュリティ インシデントは発生していませんが、ワークロード チームには、既存のセキュリティ コントロールで適切に対処されていない脅威ベクトルがあるかどうかを評価する標準化された方法がありません。
- チームは、ワークロードのセキュリティに関して盲点があり、セキュリティ インシデントが発生した場合にガードから外れるリスクがあることを認識しています。
"アプローチの適用と結果"
- チームは、脅威モデリングを実行する方法を学習するため、セキュリティ コンサルティング スペシャリストと連携しています。
- 最初の脅威モデリングの演習を実行した後、ほとんどの脅威ベクトルに対して適切に設計された制御があることがわかりましたが、Azure Spark ジョブが完了した後に発生するデータ クリーンアップ タスクの 1 つにギャップが見つかり、データ流出の 2 つの内部関係者による脅威のベクトルを見つけました。
- これらのギャップは、次の開発サイクルで修復がスケジュールされます。
- また、チームは、レース テレメトリに大きなアクセス権を持っている、レース チームが使用しなくなったサービスで使用されているレガシ システムを見つけます。 修復の一部として、このシステムの使用を停止します。
コントロールを個別に検証する
ワークロード チームの外部の専門家が実行する、システムの倫理的なハッキングの試行による定期的なセキュリティ テストを実行します。 定期的な統合された脆弱性スキャンを実行して、インフラストラクチャ、依存関係、アプリケーション コードの悪用を検出します。
これらのテストを使用すると、侵入テストなどの手法を使用して実際の攻撃をシミュレートして、セキュリティ防御を検証できます。
脅威は、変更管理の一部として導入できます。 スキャナーをデプロイ パイプラインに統合すると、脆弱性を自動的に検出し、脆弱性が削除されるまで使用状況を検疫することもできます。
"Contoso の課題"
- 脅威モデリングの演習は、チームがセキュリティギャップを明らかにするのに役立ち、特に修復を実装した後に、チームがコントロールの検証に関心を持つようになりました。
- チームは過去にオープン ソース ツールを試してセキュリティをテストし、演習が楽しく勉強になると感じました。 しかし、彼らと利害関係者は、セキュリティの専門家に参加してもらい、徹底的で厳密なテストを定期的に実行したいと考えています。
"アプローチの適用と結果"
- チームは、クラウド セキュリティを専門とする有名な Microsoft パートナーと連携し、侵入テストについて話し合います。
- ワークロード チームは、四半期ごとの侵入テスト サービスの作業記述書に署名し、年に 1 回のホワイトボックス テストを組み合わせて、より高い信頼性を確保します。
- また、コンサルティング チームは、開発チームが開発ボックスとセルフホステッド ビルド エージェントにマルウェア対策をインストールするのを支援しています。
- これらの対策により、ワークロード チームと利害関係者は、進化する脅威に備えるという高い信頼度が得られます。
最新の状態を取得し、最新の状態を維持する
更新プログラム、パッチ、セキュリティ修正プログラムを最新の状態に保ちます。 システムを継続的に評価し、監査レポート、ベンチマーク、テスト アクティビティからの教訓に基づいて改善します。 必要に応じて、自動化を検討します。 脅威の動的検出には、セキュリティ分析を利用した脅威インテリジェンスを使用します。 定期的に、ワークロードのセキュリティ開発ライフサイクル (SDL) のベスト プラクティスへの準拠を確認します。
このアプローチを採用すると、セキュリティ態勢が時間の経過とともに低下しないようにすることができます。 実際の攻撃とテストアクティビティからの結果を統合して、新しいカテゴリの脆弱性を継続的に改善して悪用する攻撃者に対抗することができるようになります。 反復的なタスクを自動化すると、リスクを生み出すおそれがある人為的ミスの可能性が減少します。
SDL レビューにより、セキュリティ機能が明確に表示されます。 SDL は、発生元、使用状況、運用上の弱点、その他の要因をカバーするワークロード資産とそのセキュリティ レポートのインベントリを維持するのに役立ちます。
"Contoso の課題"
- Apache Spark ジョブの記述を担当する開発者は、変更を導入することをためらっており、通常はジョブに対して "破損していない場合は修正しない" というアプローチを採用しています。 つまり、ソリューションに取り込む Python パッケージと R パッケージは、時間の経過とともに古くなる可能性があります。
"アプローチの適用と結果"
- ワークロード チームが内部プロセスをレビューした後、Spark ジョブを維持するためのプロセスに対応しない場合、パッチが適用されていないコンポーネントがワークロード内に存在するリスクがあることがわかります。
- チームは Apache ジョブの新しい標準を採用しており、定期的な更新およびパッチ スケジュールと共に使用中のすべてのテクノロジを更新する必要があります。
- セキュリティ コントロールのこのギャップに対処すると、ワークロード全体がパッチを適用されていないコンポーネントがリスクにさらされる可能性が低くなります。 PaaS と SaaS サービスの使用は、基になるインフラストラクチャにパッチを適用する必要がないため、このリスクへの露出を制限するのにも役立ちます。