Security Hub Automation Rules でコントロールを指定する際は「統合されたコントロールの検出結果」を意識しておくと良さそうな話

Security Hub Automation Rules のユースケースとして、Security Hub のコントロールと他の条件(リソース名など)を組み合わせて自動抑制を行うことが考えられます。
上記を実現するために以前ブログを書いた際、特定コントロールを指定するために GeneratorID を指定していました。

しかし、Security Hub は最近「統合コントロールビュー」と「統合されたコントロールの検出結果」に対応しています。

GeneratorID でも問題無く動作するのですが、上記変更を考慮した際に別項目である Compliance.SecurityControlId を利用した方が望ましいように感じたので本ブログで取り上げてみました。

「統合コントロールビュー」と「統合されたコントロールの検出結果」で何が変わるのか

「統合コントロールビュー」によって異なる標準に含まれるコントロールも一括で確認できるようになっています。
マネジメントコンソールからの確認方法が増えたという形で、全てのユーザーで有効化されています。
「統合されたコントロールの検出結果」は複数のコントロールにより検知された Findings( 検出結果 ) を 1 つに統合する機能です。
こちらを有効化することで、コントロールが複数の標準に含まれていて違反している場合も 1 つの Findings のみ生成される形になります。
こちらは機能のオン/オフを選択することができます。

既に Security Hub を有効化している場合はデフォルトオフですが、今後新しく Security Hub を有効化する場合はデフォルトでオンになります。
これらの機能追加によって、ASFF(AWS Security Finding Format) の一部項目が変更になっています。

この変更には、全てのアカウントで適用されるもの(「統合コントロールビュー」を利用するために必要な変更)と「統合されたコントロールの検出結果」を有効にした時のみ変わるものがあります。
Security Hub のコントロール ID に関わる変更は下記になります。

全てのアカウントで適用されるもの(「統合コントロールビュー」を利用するために必要な変更)

  • Compliance.SecurityControlId が追加されています。
    • こちらには EC2.2 などの標準に関係無いコントロール ID が入ります。
    • この項目は既に追加済みであり、「統合されたコントロールの検出結果」の有効化/無効化には関係なく利用可能です。

「統合されたコントロールの検出結果」を有効にした時のみ変わるもの

  • GeneratorId の値が変わります。
    • 無効化時は標準ごとの ID になっていましたが、有効化すると標準に関係無いコントロール ID が入ります
    • aws-foundational-security-best-practices/v/1.0.0/Config.1 が security-control/Config.1 に変わるような形です。
    • 「統合されたコントロールの検出結果」を有効にした際は Compliance.SecurityControlId と同じ情報を取得できる形になります。(security-control/ が付与されますが)
  • ProductFields.ControlId は無くなります。
    • こちらは元々 Automation Rules の条件には指定できませんでした。

「統合されたコントロールの検出結果」が有効になっていても無効になっていても関係無い形にするには?

今後「統合されたコントロールの検出結果」を有効化するかはわからないが、どちらの場合でも Automation Rules の動作に影響が無い形にしたい場合を考えます。
この場合、2 通りの方法が考えられます。

  • Compliance.SecurityControlId を指定する
  • GeneratorId を使いつつ、新旧の ID を指定する(もしくは 統合されたコントロールの検出結果有効化時に指定 ID を変更する)
    • Automation Rules は各値について OR 条件を指定可能

どちらを使うかですが、現時点では Compliance.SecurityControlId を指定しない理由が特に無い気がしています。
特定標準の検出結果のみを抑制したい場合も考えられなくは無いですが、全く同じチェック内容について対応方法を変えるケースはあまり無いのではないかと思っています。
下記条件で、masukawa から始まるバケットの [S3.9]S3 バケットサーバーアクセスのログ記録は有効になっている必要があります の検出結果を指定することができました。( 今回は自動抑制して確認してみました。 )

まとめ

Security Hub で「統合されたコントロールの検出結果」をオン/オフする可能性を考えると、Compliance.SecurityControlId を利用してコントロールを指定した方が良さそうに思います。
「統合されたコントロールの検出結果」が現在オフの状態であり、Automation Rules の設定を行っている方は参考にしていただけると幸いです。