インサイトとカスタム検出結果アクション

正規化された検出結果が長いリストになっているだけでは、対応するのは困難です。Security Hubには、そのリストを重点的なアクションにつなげる2つのツールがあります。関連する検出結果をまとめるインサイトと、選択した検出結果を起点にワークフローを実行できるカスタムアクションです。

Security Hubのインサイトとは、フィルターと「group by」属性によって収集した検出結果を保存済みのグループとしてまとめたものです。たとえば、アクティブな検出結果をリソース別にまとめることで、どのリソースに最も多くの問題があるかを明らかにできます。インサイトを使うと、個々の検出結果だけでは見えにくいパターンが浮かび上がります。

Security Hubには、すぐに使えるマネージドインサイトがあらかじめ用意されています。たとえば、「検出結果が最も多いAWSリソース」や「パブリックアクセスが設定されたS3バケット」などです。これらの事前構築済みのグループを使えば、自分で定義しなくても問題の集中箇所を把握でき、すぐに効果を得られます。

懸念事項に合わせたカスタムインサイトを作成することもできます。任意のASFFフィールドでフィルタリングし、別のフィールドでグループ化できます。たとえば、あるチームが、重要度がHighの検出結果をアカウント別にまとめるインサイトを作成すれば、リスクが存在する場所に正確に注意を向けられます。

グループ化によって、ノイズを優先順位に変えられます。何千件もの検出結果をスクロールする代わりに、インサイトを使えば「この5つのリソースがリスクの大部分を占めている」と把握できます。これにより、影響が最も大きい修正に対処でき、試験で重視される優先順位付けにも役立ちます。

Security Hubのカスタムアクションとは、検出結果に関連付ける名前付きのトリガーです。アナリストが検出結果を選択してそのアクションを選ぶと、Security HubはEventBridgeにイベントを送信します。これは、人によるトリアージと自動対応をつなぐ橋渡しとなります。

各カスタムアクションには固有のARNがあり、選択した検出結果を含むEventBridgeイベントを生成します。その後、EventBridgeルールがそのイベントをLambda関数、Step Functionsワークフロー、チケット管理システムとの統合などのターゲットにルーティングし、修復またはエスカレーションを実行します。

カスタムアクションを使うと、アナリストが開始する対応が可能になります。つまり、人が確認してからクリックして修復します。完全に自動化する場合は、EventBridgeルールで検出結果を直接照合し、人の操作なしでアクションを実行します。両方のパターンを理解しておくと、適切な方法を選べます。

Security Hubには、検出結果を自動的に更新する自動化ルールもあります。たとえば、条件に一致したときに重要度を引き上げたり、ワークフローステータスを変更したりできます。これらのルールにより、検出結果のストリームを、アナリストや下流の自動化処理に届く前に調整できます。

自動化ルールは、検出結果がASFFフィールドに定義された条件に一致すると動作し、重要度の設定、ワークフローステータスの更新、メモの追加などの変更を適用します。たとえば、既知のテストアカウントからの重要度が低い検出結果を自動的に抑制するルールを作成できます。これにより、アナリストや下流の自動化処理が確認する前に、ストリームを一貫した方法で調整できます。

どちらのパターンを選ぶかは、最初に人が確認すべきかどうかで判断します。カスタムアクションは、アナリストが開始する、判断の比重が大きい対応に適しています。一方、直接的なEventBridgeルールは、明確で大量に発生し、待機せず即座に修復すべき検出結果に適しています。多くのチームでは両方を組み合わせ、明らかなものは自動修復し、判断が難しいものはカスタムアクションを通じてアナリストに送ります。

検出結果と対応を結び付けてください。

Security Hubのインサイトは、フィルターと属性（マネージドまたはカスタム）によって検出結果をグループ化し、リスクが集中している場所を明らかにします。カスタムアクションを使うと、アナリストは選択した検出結果をEventBridgeに送って対応できます。一方、直接的なEventBridgeルールでは完全に自動化された修復が可能で、自動化ルールは検出結果を自動更新します。これらを組み合わせることで、集約された検出結果をワークフローに変換できます。