はじめに
なにげなく使っていらっしゃる方も多いであろうSecurity Hubでは、セキュリティチェック結果において地味に複数種類の「ステータス」が存在し、ちょっとややこしいです。（公式解説を読んでも初見だとピンときづらい気がします。）
この「ステータス」の意味を理解していないと、チェック結果の表示をフィルタリングしたり、アラート検出通知をおこなったりするための条件を正しく設定できません。結果として、無闇に大量の通知を受け、重要なアラートをとりこぼす可能性があります。
現場での経験をもとに、ゆるい表現で解説できればと思います。なお、これらの「ステータス」は日本語訳に表記揺れがあるため、英語表記にいたします。
ステータスの種類
- コントロール(セキュリティチェック項目)のチェック結果のステータス
Control Status
- コントロールに対する各AWSリソースのチェック結果のステータス
Compliance StatusWorkflow StatusRecord 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)がある。
- 自動設定ケース：
Compliance StatusFAILEDとなった新着チェック結果はWorkflow StatusNEWへ、Compliance StatusPASSEDとなったチェック結果はWorkflow StatusRESOLVEDへ、自動設定される。 - 手動設定ケース：
Workflow StatusNOTIFIEDまたはSUPPRESSEDへ利用者にて手動設定する。- NOTIFIEDのユースケース：実装したアラート検出通知の仕組みにより通知を受けたらNOTIFIEDの目印をつける。
参考: AWS Security Hub の検出結果を自動で「通知済み」にする
- SUPPRESSEDのユースケース：利用者にてアクション不要と判断したチェック結果をSUPPRESSED(AWSリソース単位のアラート検出除外)にし
Control Statusの算出に含めないようにする。
参考: [Security Hub] ワークフローステータス「抑制済み」を使ってセキュリティチェックのリソース例外を登録する
- NOTIFIEDのユースケース：実装したアラート検出通知の仕組みにより通知を受けたらNOTIFIEDの目印をつける。
- 自動設定ケース：
Record Stateとは
参考: 用語と概念>アーカイブ済みの結果, RecordState
- 値：ACTIVE/ARCHIVED
- 意味：チェック結果自体の状態を表す。
- 補足：利用者がコントロール無効化(チェック項目単位のアラート検出除外)をおこなった、リソースが削除された、3~5日以上更新されていない、といったチェック結果はSecurity Hubによって
Record StateARCHIVEDへと自動設定される。
参考: 特定の標準のコントロールを無効にする
Severityとは
参考: 用語と概念>重要度, 緊急度, コントロール結果への重要度の割り当て
「ステータス」ではないですが、「ステータス」と連動して値が変動することがあるため取り上げます。
- 値：CRITICAL/HIGH/MEDIUM/LOW/INFORMATIONAL
- 意味：チェック結果の重要度。
- 補足：コントロール(チェック項目)ごとにあらかじめ定義されておりチェック結果にもそのまま用いられるが、
Compliance StatusPASSED/WARNING/NOT_AVAILABLEの場合、Security HubによってSeverityINFORMATIONALへと自動設定される。
セキュリティチェック結果をどう判別すればよいか
このようにステータスが複数ある状況でどう判別するか、代表的なケースでのステータスの組み合わせを整理しました。
| ケース | 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 StateARCHIVED以外(=ACTIVE) -
Workflow StatusSUPPRESSED以外 -
Compliance StatusFAILED
ただし、この整理の結果を、アラート検出通知条件にそのまま当てはめるかというと、もう少し検討が必要です。
-
Workflow Statusは利用者が設定できるステータスのため、ステータスの意味づけによっては判別ロジックが変わります。たとえば「NOTIFIEDは、初回通知があった後に別途台帳で管理するという意味づけでセットする運用としているので、アラート検出通知対象は不要」などのケースがありえます。 -
Severityは利用者側の重視度合で対応レベルの細分化の検討が必要です。利用者によってはたとえばLOWのチェック項目を重視するケースも、逆に「検出通知までは不要」とするケースもありえます。
このように、最低限「要対応」となるチェック結果は前述のとおり整理したものの、個々のセキュリティ運用に合わせて追加の整理は必要となってくるものと考えます。
おわりに
Security Hubは有効化すれば利用開始できセキュリティチェックをクイックにおこなえてしまうので、それだけで万能感がありますが、利用者として正しく使うために、仕様をきちんと理解しておく必要があると考えます。
AWS利用システムのセキュリティ運用設計にて高頻度で登場するサービスなので、いざ使うとなったときに困らないようにしておきたいと思います。
ご覧くださった方にとって少しでもご参考になれば幸いです。