セキュリティ検出結果の所有権を定義する

セキュリティ検出結果をトリアージするための所有権モデルを定義することは難しい場合がありますが、必ずしもそうである必要はありません。セキュリティ環境は常に変化し、実務者はこれらの変化に柔軟に対応できる必要があります。セキュリティ検出結果の所有権モデルを開発するための柔軟なアプローチを採用します。初期モデルでは、チームがすぐに行動できるようにする必要があります。基本的な所有権ロジックから始めて、そのロジックを時間の経過とともに改良することをお勧めします。完全な所有権基準の定義を遅らせると、セキュリティ検出結果の数は増え続けます。

結果を適切なチームやリソースに簡単に割り当てられるように、チームが日常業務の管理に使用する AWS Security Hub 既存のシステムと統合することをお勧めします。例えば、Security Hub をセキュリティ情報およびイベント管理 (SIEM) システムや製品のバックログおよびチケット発行システムと統合できます。詳細については、このガイドの「セキュリティ検出結果を割り当てるための準備」を参照してください。

以下は、開始点として使用できる所有権モデルの例です。

• セキュリティチームは、潜在的にアクティブな脅威を確認し、セキュリティ検出結果の評価と優先順位付けを支援します。セキュリティチームには、コンテキストを適切に評価するための専門知識とツールがあります。脆弱性の評価と優先順位付け、脅威検出イベントの調査に役立つ追加のセキュリティ関連データを理解しています。重要度の検出結果や追加の調整が必要な場合は、このガイドのセキュリティ検出結果の評価と優先順位付け「」セクションを参照してください。例については、このガイドセキュリティチームの例の「」を参照してください。

  

• クラウドチームとアプリケーションチーム間でセキュリティ結果を分散する – セキュリティ所有権の配布セクションで説明したように、リソースを設定するアクセス権を持つチームが、安全な設定を担当します。アプリケーションチームは、構築および設定するリソースに関連するセキュリティ検出結果に責任を負い、クラウドチームは、広範囲にわたる設定に関連するセキュリティ検出結果に責任を負います。ほとんどの場合、アプリケーションチームは、、 のサービスコントロールポリシー (SCPs) AWS のサービス、ネットワーク関連の VPC 設定 AWS Control Tower、AWS IAM Identity Center など AWS Organizations、広範囲にわたる設定や を変更することはできません。

  アプリケーションを専用アカウントに分割するマルチアカウント環境では、通常、アカウントのセキュリティ関連の検出結果をアプリケーションのバックログまたはチケット発行システムに統合できます。そのシステムから、クラウドチームまたはアプリケーションチームが検出結果に対処できます。例については、このガイドアプリケーションチームの例のクラウドチームの例「」または「」を参照してください。

  

• 残りの未解決の検出結果をクラウドチームに割り当てる – 残った検出結果は、クラウドチームが対処できるデフォルト設定または広範囲にわたる設定に関連している可能性があります。このチームは、調査結果を解決するための最も歴史的な知識とアクセス権を持っている可能性があります。全体として、これは通常、検出結果全体の非常に小さなサブセットです。