はじめに

なにげなく使っていらっしゃる方も多いであろうSecurity Hubでは、セキュリティチェック結果において地味に複数種類の「ステータス」が存在し、ちょっとややこしいです。（公式解説を読んでも初見だとピンときづらい気がします。）
この「ステータス」の意味を理解していないと、チェック結果の表示をフィルタリングしたり、アラート検出通知をおこなったりするための条件を正しく設定できません。結果として、無闇に大量の通知を受け、重要なアラートをとりこぼす可能性があります。
現場での経験をもとに、ゆるい表現で解説できればと思います。なお、これらの「ステータス」は日本語訳に表記揺れがあるため、英語表記にいたします。

ステータスの種類

コントロール(セキュリティチェック項目)のチェック結果のステータス
- Control Status
コントロールに対する各AWSリソースのチェック結果のステータス
- Compliance Status
- Workflow Status
- Record State

Security Hubの「検出結果」画面(※a)に表示されたりアラート検出通知(※b)の条件設定に使ったりするのは上記のうち2のため、2について記述いたします。（1にも若干触れます。）

※a.参考: AWS Security Hub で結果リストと詳細を表示する>検出結果
※b.アラート検出通知は、EventBridge、SNSを組み合わせて実装することを想定しています。
参考: 自動的に送信される結果の EventBridge ルールの設定

Compliance Statusとは

参考: 結果のコンプライアンスステータスの値

値：FAILED/PASSED/WARNING/NOT_AVAILABLE
意味：AWSリソースごとのチェック結果を表す。
補足：Control Statusとは似て非なるもの。
- Control Statusは、Compliance Statusを集約し算出されたコントロール(セキュリティチェック項目)ごとのチェック結果を表す。
  参考: コントロールステータスの値
- にもかかわらず、Control Statusのマネジメントコンソール上の日本語表記が「コンプライアンスのステータス」となっている画面があり紛らわしいので要注意。

Workflow Statusとは

参考: 結果のワークフローステータスを設定する

値：NEW/NOTIFIED/SUPPRESSED/RESOLVED
意味：チェック結果への対応状況を表す。
補足：Security Hubによって自動設定されるケース(1)と利用者によって手動設定するケース(2)がある。
1. 自動設定ケース： Compliance Status FAILEDとなった新着チェック結果はWorkflow Status NEWへ、Compliance Status PASSEDとなったチェック結果はWorkflow Status RESOLVEDへ、自動設定される。
2. 手動設定ケース： Workflow Status NOTIFIEDまたはSUPPRESSEDへ利用者にて手動設定する。
  - NOTIFIEDのユースケース：実装したアラート検出通知の仕組みにより通知を受けたらNOTIFIEDの目印をつける。
    参考: AWS Security Hub の検出結果を自動で「通知済み」にする
  - SUPPRESSEDのユースケース：利用者にてアクション不要と判断したチェック結果をSUPPRESSED(AWSリソース単位のアラート検出除外)にしControl Statusの算出に含めないようにする。
    参考: [Security Hub] ワークフローステータス「抑制済み」を使ってセキュリティチェックのリソース例外を登録する

Record Stateとは

参考: 用語と概念>アーカイブ済みの結果, RecordState

値：ACTIVE/ARCHIVED
意味：チェック結果自体の状態を表す。
補足：利用者がコントロール無効化(チェック項目単位のアラート検出除外)をおこなった、リソースが削除された、3~5日以上更新されていない、といったチェック結果はSecurity HubによってRecord State ARCHIVEDへと自動設定される。
参考: 特定の標準のコントロールを無効にする

Severityとは

参考: 用語と概念>重要度, 緊急度, コントロール結果への重要度の割り当て

「ステータス」ではないですが、「ステータス」と連動して値が変動することがあるため取り上げます。

値：CRITICAL/HIGH/MEDIUM/LOW/INFORMATIONAL
意味：チェック結果の重要度。
補足：コントロール(チェック項目)ごとにあらかじめ定義されておりチェック結果にもそのまま用いられるが、Compliance Status PASSED/WARNING/NOT_AVAILABLEの場合、Security HubによってSeverity INFORMATIONALへと自動設定される。

セキュリティチェック結果をどう判別すればよいか

このようにステータスが複数ある状況でどう判別するか、代表的なケースでのステータスの組み合わせを整理しました。

ケース	Record State	Workflow Status	Compliance Status	Severity	対応
アラート検出あり	ACTIVE	NEW/NOTIFIED/RESOLVED	FAILED	CRITICAL/HIGH/MEDIUM/LOW	要対応
アラート検出なし	ACTIVE	RESOLVED	PASSED	INFORMATIONAL	対応しない
チェックの失敗	ACTIVE	NEW/NOTIFIED/RESOLVED	WARNING/NOT_AVAILABLE	INFORMATIONAL	対応しない (AWS Config有効化漏れなど利用者起因のチェック失敗はない前提で記載)
アラート検出除外済み	ACTIVE	SUPPRESSED	FAILED WARNING/NOT_AVAILABLE	CRITICAL/HIGH/MEDIUM/LOW INFORMATIONAL	対応しない (除外プロセス策定済みという前提で記載)
アーカイブ	ARCHIVED	NEW/NOTIFIED/SUPPRESSED/RESOLVED	FAILED/PASSED/WARNING/NOT_AVAILABLE	CRITICAL/HIGH/MEDIUM/LOW/INFORMATIONAL	対応しない

この整理の結果では、以下のAND条件に合致したものが要対応のチェック結果(アラート検出)とみなすことができます。

Record State ARCHIVED以外(=ACTIVE)
Workflow Status SUPPRESSED以外
Compliance Status FAILED

ただし、この整理の結果を、アラート検出通知条件にそのまま当てはめるかというと、もう少し検討が必要です。

Workflow Statusは利用者が設定できるステータスのため、ステータスの意味づけによっては判別ロジックが変わります。たとえば「NOTIFIEDは、初回通知があった後に別途台帳で管理するという意味づけでセットする運用としているので、アラート検出通知対象は不要」などのケースがありえます。
Severityは利用者側の重視度合で対応レベルの細分化の検討が必要です。利用者によってはたとえばLOWのチェック項目を重視するケースも、逆に「検出通知までは不要」とするケースもありえます。

このように、最低限「要対応」となるチェック結果は前述のとおり整理したものの、個々のセキュリティ運用に合わせて追加の整理は必要となってくるものと考えます。

おわりに

Security Hubは有効化すれば利用開始できセキュリティチェックをクイックにおこなえてしまうので、それだけで万能感がありますが、利用者として正しく使うために、仕様をきちんと理解しておく必要があると考えます。
AWS利用システムのセキュリティ運用設計にて高頻度で登場するサービスなので、いざ使うとなったときに困らないようにしておきたいと思います。
ご覧くださった方にとって少しでもご参考になれば幸いです。