Security Hub CSPM の抑制（SUPPRESSED）時に ASR がどのように動作するのか確認する

はじめに

Security Hub CSPMの自動修復ソリューションであるASR（Automated Security Response on AWS）を運用しています。Workflow Status を「抑制（SUPPRESSED）」にした場合の動作が気になったので調査しました。

ソースコードと公式ドキュメントを確認してみたのでまとめます。

前提条件

今回のバージョンは ASR v3.1.1 で確認しています。

利用しているバージョンのコードを確認するようにしてください。
https://github.com/aws-solutions/automated-security-response-on-aws/tree/main

ASR の自動修復は以下の流れで実行されます。

1. Security Hub CSPM が finding を検出
2. EventBridge ルールがイベントをキャッチ
3. SQS キューに送信
4. Pre-Processor Lambda がフィルタリング・判定
5. 条件を満たした場合のみ Step Functions → SSM Automation で修復

修復の可否を判断するのは Pre-Processor Lambda です。
EventBridge ルール側では Workflow Status のフィルタリングは行っていません。

確認してみる

Pre-Processor の判定ロジックを確認する

ASR v3.x の Pre-Processor Lambda（shouldTriggerRemediation 関数）のソースコードを確認してみました。修復するかどうかの判定ロジックは以下のようになっています。

// ASR v3.x Pre-Processor の修復判定ロジック
const baseRequirements =
  autoRemediationEnabled &&
  finding.Compliance.Status === 'FAILED' &&
  finding.RecordState !== 'ARCHIVED' &&
  finding.Workflow?.Status !== 'SUPPRESSED';  // ← SUPPRESSEDチェック

以下 4 つの条件をすべて満たす必要があります。

4 番目の条件で SUPPRESSED な finding は明示的に除外 されています。つまり、抑制した finding は自動修復されません。

ここまではなんとなく予想通りですね。でも本当に気になるのは「SUPPRESSED にした後、Compliance.Status が変わったらどうなるのか」という点です。

SUPPRESSED はリセットされないことを確認する

Security Hub CSPM の Workflow Status は NEW、NOTIFIED、RESOLVED、SUPPRESSED の 4 種類です。状態変化時のリセット挙動が異なります。

NOTIFIED や RESOLVED は、finding の状態が変化すると自動的に NEW に戻ります。しかし SUPPRESSED は状態変化があってもリセットされません。

SUPPRESSED
Indicates that you reviewed the finding and do not believe that any action is needed.

The workflow status of a SUPPRESSED finding does not change if RecordState changes from ARCHIVED to ACTIVE.
https://docs.aws.amazon.com/securityhub/latest/userguide/findings-workflow-status.html

一度 SUPPRESSED にした finding はずっと SUPPRESSED のままです。Compliance.Status が PASSED → FAILED と変化しても維持されます。ASR の Pre-Processor で再び除外されます。

既存 SUPPRESSED 環境への ASR 展開シナリオ

既に SUPPRESSED で運用している環境に後から ASR を展開するケースも確認してみました。

ASR はイベント駆動型のアーキテクチャです。Security Hub CSPM が finding を作成・更新したタイミングで EventBridge イベントが発生し、そこから処理が始まります。

ASR 展開直後:

• 既存の finding に対して EventBridge イベントは発生しない → そもそも処理されない

Security Hub CSPM 定期チェック後（12〜24時間後）:

• finding が再評価・更新される → EventBridge イベント発生 → Pre-Processor に到達
• しかし SUPPRESSED はリセットされない → Pre-Processor で除外 → 修復されない

どちらのタイミングでも SUPPRESSED の finding は修復されません。

注意点

抑制と修復無効化の使い分け

SUPPRESSED にすれば自動修復は止まりますが、すべてのケースで SUPPRESSED が最適とは限りません。

RemediationConfig は ASR にある自動修復対象を制御する DynamoDB テーブルです。

SUPPRESSED にすると finding 自体が Security Hub CSPM のデフォルトビューから見えなくなります。「修復はしてほしくないけど、違反状態は引き続き監視したい」という場合は、ASR 側の RemediationConfig で個別に無効化する方が適切です。

RemediationConfig ではすべてのコントロールがデフォルト無効になっているので、対応しないものについてはそのままで良いです。一部のリソースの finding だけ例外としたい場合は抑制するという使い分けにしましょう。

まとめ

Security Hub CSPM の SUPPRESSED は ASR で自動修復されないことが確認できました。他の Workflow Status と違い、SUPPRESSED は状態変化があってもリセットされません。

今回は ASR v3.1.1 のバージョンでの確認でしたが、今後 Pre-Processor のロジックが変わる可能性もありますので、最新のソースコードを確認することをおすすめします。

以上、鈴木純がお送りしました。

参考

• ASR Architecture Overview
• Security Hub CSPM Workflow Status
• Security Hub CSPM Automation Rules