ゴール

既存環境について、

• 検出結果を「未調査・調査中・対応不要・解決済み」などの状態で管理する
• 検知機能そのものと、検出結果の管理を分けて考える
• AWS Security Hubで複数情報源の検出結果を横断的に扱う
• 同じリソースや主体に関係する検出結果をまとめて調査する
• 抑制を修復と混同しない
• 既に付けられた優先順位を調査キューへ反映する
• AWS Configの設定履歴を調査時の文脈として利用する
• Amazon Detectiveで関連する活動を深掘りする
• Finding Groupの重要度を正しく解釈する

ことを目指します。

1. 検出後の運用を監査する

既存環境では、

GuardDuty 有効
Amazon Inspector 有効
AWS Config 有効
AWS Security Hub 有効

だけを確認して終わりません。

次に確認するのは、

検出結果が届いた後
誰が確認する？

調査中かどうか分かる？

対応不要の理由は残っている？

同じ事象を重複調査していない？

関連する検出結果をまとめられる？

詳細調査へ引き継げる？

です。

セキュリティ監視は、

検出できること

だけでなく、

検出した後に処理できること

まで含めて評価します。

2. 検出と検出結果管理を分ける

検知サービスが問題を検出しても、その後の運用は別の責任です。

検知
↓
検出結果
↓
整理
↓
調査
↓
判断

例えば、既知の正常処理によって同じGuardDuty検出結果が繰り返し生成されている場合でも、

うるさい
↓
GuardDutyを停止

とは考えません。

まず、

検知は維持
↓
検出結果をレビュー
↓
対応不要と確認
↓
適切な状態で管理

とします。

ノイズ削減と検知停止は別の操作です。

3. AWS Security Hubを調査キューの中心として利用する

AWS Security Hubでは、複数のAWSセキュリティサービスなどから取り込んだ検出結果を共通形式で扱えます。

ここで重要なのはサービスごとの役割を覚え直すことではなく、

複数の情報源
↓
Security Hub
↓
共通の調査キュー

として運用できることです。

例えば、

GuardDuty由来
Amazon Inspector由来
Security Hub CSPM由来

の情報をサービスごとに別々の担当表へ転記するより、

対象リソース
主体
重要度
状態
関連情報

を横断的に確認できる方が調査を管理しやすくなります。

現在のAWS Security Hubでは、セキュリティ検出結果をOCSF形式で扱います。

4. 状態を管理して重複調査を防ぐ

大量の検出結果がある環境では、

担当者A
調査開始

担当者B
同じ検出結果を再調査

担当者C
すでに対応不要と判断済みと知らず
再び調査

という無駄が発生します。

そのため、Security Hubで利用できる状態情報などを使い、

新規

調査中

抑制対象

解決済み

といった調査状態を明確にします。

重要なのは、

検出結果が存在するか

だけでなく、

現在どの段階なのか

をチーム内で共有できることです。

5. 抑制は「修復済み」ではない

レビューの結果、

既知の正常動作

誤検知と判断

明示的に受容したリスク

などで追加対応を行わない場合があります。

そのような検出結果を抑制して、通常の調査対象と区別することはできます。

しかし、

抑制
=
原因がなくなった

ではありません。

例えば、

危険な設定が残っている

しかし
例外として受容している

場合でも、抑制された状態になることがあります。

したがって、

検出結果の管理状態と実際のリスク状態を分離して考えます。

6. 抑制理由は後から再評価できる状態にする

一度抑制したからといって、永久に対応不要とは限りません。

例えば、

当初
内部ネットワークだけで利用

↓ 後日

インターネット公開へ変更

した場合、以前は受容できたリスクでも再評価が必要になる可能性があります。

そのため、

なぜ抑制したか

どの条件なら
再評価するか

を運用上明確にします。

7. 優先順位付け済みの検出結果を調査順へ反映する

重要度だけでは最終的な対応優先度が決まらないことは既習です。

ここでは、

すでに優先順位付けした結果を、実際の調査キューへ反映できているか

を確認します。

例えば、

高優先度
↓
担当者を割り当て
↓
調査中へ変更
↓
関連情報を確認

低優先度
↓
後続キューへ

という形です。

問題なのは、

優先順位は計算した

のに、

全件を到着順に処理

している状態です。

8. 同じリソースに関係する検出結果をまとめる

1つのリソースに複数の検出結果が存在する場合があります。

例えば、

EC2
├─ GuardDuty由来の検出結果
├─ Amazon Inspector由来の検出結果
└─ 設定上の問題

です。

それぞれを完全に独立した問題として扱うと、

同じリソースで
複数のセキュリティ問題が
同時に発生している

という文脈を見失う可能性があります。

そのため、

リソース
主体
時間
ネットワーク情報
関連する検出結果

などを使って、同じ事象に関係する可能性を確認します。

9. Exposure Findingは既存の優先順位付けを補助する情報として使う

AWS Security Hubでは、複数のセキュリティシグナルを相関したExposure Findingを利用できます。

Exposure Findingの仕組みそのものは既習です。

ここでは、

個別検出結果
+
Exposure Finding
+
現在の調査状態

を組み合わせて、

どの調査を先に進めるか

を判断する補助情報として使います。

Exposure Findingがあるからといって、

関連する個別検出結果を
確認しなくてよい

わけではありません。

10. AWS Configを調査時の設定文脈として使う

高優先度の検出結果を調査するとき、

検出時点で
そのリソースは
どのような設定だった？

を確認したい場合があります。

AWS Configでは、

設定状態

設定変更履歴

コンプライアンス状態

などを確認できます。

例えば、

GuardDuty検出結果
↓
対象EC2を確認
↓
直前にセキュリティグループが変更

という情報が得られれば、調査対象を絞り込めます。

ここでAWS Configは、

脅威を検出するためではなく、調査へ設定変更の文脈を追加するため

に利用します。

11. Amazon Detectiveへ詳細調査を引き継ぐ

調査対象を絞った後、

どの主体が関係する？

どのIPアドレスが関係する？

他の検出結果も関連する？

近い時間帯に
何が起きていた？

といった深掘りが必要になる場合があります。

Amazon Detectiveでは、検出結果やエンティティ、行動データなどを関連付けて調査できます。

したがって、

Security Hub
↓
調査対象を整理

Amazon Detective
↓
関連活動を深掘り

という役割分担で考えます。

12. Finding Groupで関連する活動をまとめて調査する

Amazon Detectiveの Finding Group では、関連する、

検出結果
エンティティ
証拠

をグループ化して調査できます。

例えば、

同じIAM主体

同じIPアドレス

近い時間帯

関連するリソース

などを手掛かりに、

複数の検出結果が
同じセキュリティ事象に
関係していないか

を分析できます。

これは、

検出結果A
調査完了

検出結果B
別担当が最初から調査

という分断を減らすためにも有効です。

13. Finding Groupの重要度を正しく読む

Amazon DetectiveのFinding Groupには重要度があります。

Finding Groupの重要度は、グループ内に含まれる検出結果のうち、最も高い重要度と同じです。

例えば、

Medium
High
Critical

の検出結果を含むFinding Groupなら、

Finding Group
Critical

となります。

ただし、

グループがCritical
=
原因や影響範囲まで確定

ではありません。

重要度は、

どのグループから調査するかを判断する材料

として使います。

14. Detectiveを検知サービスの代わりにしない

Amazon Detectiveは詳細調査を支援します。

検知サービス
↓
検出結果
↓
調査対象を整理
↓
Detectiveで深掘り

という流れです。

したがって、

Detectiveを導入
↓
GuardDutyなどを停止

とは考えません。

検知と調査は別の責任です。

15. 調査終了後に状態を更新する

詳細調査が終わっても、Security Hub側の状態が、

未調査

のままなら、次の担当者が再び同じ調査を始める可能性があります。

したがって、

調査
↓
判断
↓
状態更新
↓
必要なら根拠を記録

までを一連の作業として扱います。

16. ノイズ削減では「件数を消す」ことを目的にしない

例えば、

Low
Medium

という理由だけで一括抑制すると、

現在は重要度が低くても、

重要リソース

他の検出結果と関連

継続して発生

している情報を見失う可能性があります。

したがって、

ノイズ削減
=
検出結果を大量に消す

ではありません。

調査対象

対応不要

抑制

解決済み

関連する検出結果

を正しく区別することで、重要な情報へ集中します。

17. Security Hubの状態変更と実際の修復を分ける

Security Hub上で、

状態を変更

抑制

解決済みとして管理

しても、それ自体がAWSリソースを修正するわけではありません。

例えば、

危険なセキュリティグループ

に関する検出結果を抑制しても、セキュリティグループ設定は変わりません。

したがって、

検出結果管理

と、

リスクの実際の修復

を分けます。

自動修復や自動応答そのものは後続で扱います。

18. 検出結果管理の基本フロー

1. 検出結果を受け取る
        ↓
2. 既存の優先順位を
   調査キューへ反映
        ↓
3. 調査状態を設定
        ↓
4. 同じリソース・主体に
   関係する情報を確認
        ↓
5. 必要ならAWS Configで
   設定履歴を確認
        ↓
6. 高優先度の対象を
   Detectiveへ引き継ぐ
        ↓
7. Finding Groupなどで
   関連活動を調査
        ↓
8. 対応判断
        ↓
9. 状態と根拠を更新

19. 混同しやすいポイント

20. SAP-C02での判断手順

問題文で、

Security Hubへ
大量の検出結果

調査の重複

対応状態が不明

関連する検出結果を
まとめられない

調査に時間がかかる

とあれば、

優先順位は
調査キューへ反映されている？
↓
現在の状態は分かる？
↓
対応不要の理由は明確？
↓
同じリソース / 主体の
検出結果は関連している？
↓
設定変更の文脈が必要？
↓
Detectiveへ
深掘りすべき対象？
↓
調査後に
状態を更新した？

と判断します。

決定打は、

検出結果を増減させることではなく、重要な検出結果を重複なく調査し、関連情報をまとめ、判断結果を管理できる状態にすること

です。

まとめ

セキュリティ監視と検出結果管理では、

検出
↓
検出結果
↓
優先順位
↓
調査状態
↓
関連付け
↓
詳細調査
↓
判断
↓
状態更新

という運用を考えます。

重要なのは、

抑制
≠
修復

状態変更
≠
リスク解消

Detective
≠
検知サービス

Finding Group
≠
インシデント確定

です。

AWS Security Hubで検出結果を整理し、AWS Configで設定の文脈を確認し、必要な対象をAmazon Detectiveで深掘りし、調査結果を状態管理へ戻せる運用へ改善します。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional (SAP-C02) — Domain 3 / Task 3.2
• AWS Security Hub — セキュリティ検出結果
• AWS Security Hub — OCSF
• AWS Security Hub — Exposure Finding
• AWS Security Hub — 検出結果の状態管理
• AWS Config — リソース設定履歴
• Amazon Detective — Finding Group