皆さんMerry Christmas！コーポレート本部 サイバーセキュリティ推進部 セキュアシステムデザイングループの福山です。
本記事は、電通総研 Advent Calendar 2024の24日目の記事となります。
今回は、私の好きなAWSサービスの一つであるAmazon Detectiveについてお届けしたいと思います。
- はじめに
- Amazon Detectiveとは
- Detectiveを有効化してみよう！
- GuardDutyアラートの生成
- Detective管理アカウントによる調査方法
- まとめ
- 最後にちょっとだけ補足
はじめに
AWS上で発生したセキュリティインシデントを調査する際、GuardDuty の検出結果、CloudTrailやVPCフローログ等を読み解く作業が発生します。
しかし、これらのログ調査には知見と労力が必要です。
そんな課題を解決し得るサービスがAWSには存在します。
Amazon Detectiveとは
Amazon Detectiveは、AWS上で発生したセキュリティインシデントの調査を容易にするサービスです。
CloudTrail／VPCフローログ／GuardDutyの検出結果などのログデータを自動で収集し、"動作グラフ"と呼ばれる各アカウントに紐づくデータセットを生成し、機械学習・統計分析を用いて可視化します。
下図はセキュリティインシデントの調査のプロセスを示しています。
Detectiveを使わない従来の調査方法では、それぞれのプロセスで利用するサービスが異なるため、時間と手間が発生していました。
Detectiveを使うことで、各サービスのログがDetectiveに集約・分析され、セキュリティインシデントの調査を一気通貫で進めることができます。
引用：https://www.youtube.com/watch?v=Vf-s3ZQmJhc
Detectiveを有効化してみよう！
と言いたいところですが、その前に重要なポイントがあります。
それは、Detectiveではマルチアカウント連携が可能であるということです。
例えば、複数のAWSアカウントを抱える組織のSOCやCSIRTが、Detective管理アカウント（ログの集約アカウント）を使って、メンバーアカウント（ログを吐くアカウント）で起きたセキュリティインシデントを調査する、といった構成を組むことができます。
詳細は下記のユーザーガイドを確認してください。
https://docs.aws.amazon.com/ja_jp/detective/latest/userguide/accounts.html
以降の説明では、マルチアカウント連携を行う前提で進めます。
管理アカウントでの作業
まずはDetective管理アカウントとなるアカウントでDetectiveを有効化しましょう。
必要に応じてオプションデータソースを有効化します。
"AWSセキュリティ検出結果"を有効にすると、メンバーアカウントのSecurity Hubの検出結果を収集することが可能です。
メンバーアカウントでEKSを利用している場合はEKS監査ログも収集できますが、ログのデータ量によってはメンバーアカウント側に想定外の課金が生じるため注意してください。
30日間の無料期間がありますので、その間に費用感をチェックすることをお勧めします。
各アカウントを招待しましょう。DetectiveはOrganizations連携にも対応しています。
メンバーアカウントでの作業
メンバーアカウント側で設定すべき内容は以下です。
- GuardDutyの有効化（必須）
- Detectiveに取り込まれるためには、GuardDuty有効化後、48時間が経過している必要があります。
- GuardDutyの検出結果のエクスポートオプションで更新結果の取り込み頻度を15分に変更する（推奨）
- デフォルトは6時間になっており、GuardDutyの更新結果がDetectiveに反映されるまでに時間がかかります。
15分に設定することをお勧めします。
- デフォルトは6時間になっており、GuardDutyの更新結果がDetectiveに反映されるまでに時間がかかります。
- 招待を承諾（マルチアカウント連携の場合は必須）
- 招待を承諾してから、管理アカウントが情報を取り込むまでに最大24時間を要します。
- メンバーアカウント側で事前にDetectiveを有効化してしまうと、メンバーアカウントの動作グラフが管理アカウント内およびメンバーアカウント自身に存在するため、それぞれに課金が発生します。
メンバーアカウント側でDetectiveを使って調査する必要がなければ、メンバーアカウントでDetectiveを明示的に有効化する必要はありません。 - アカウント連携前のログはDetectiveに取り込まれません。
- Security Hubの有効化（必要に応じて）
- Inspectorの有効化（必要に応じて）
GuardDutyアラートの生成
続いてAWS上にリソースを立てて、擬似攻撃を起こしてGuardDutyアラートを生成しましょう。
今回は、コマンド1つでサンプルではない実際のGuardDutyアラートを生成できるツール"GuardDuty Findings Tester"を用います。
https://github.com/awslabs/amazon-guardduty-tester
GuardDuty Findings Testerでは、攻撃元となるリソース（Kali Linux）と、攻撃対象となるリソースをCDKでデプロイします。
アラート生成方法としては、FindingType指定をはじめ、リソース種類別、ログソース別、MITRE ATT&CKのTactics（攻撃戦術）別などがあります。
今回は下記のFindingTypeを指定して検出させてみました。
- UnauthorizedAccess:EC2/RDPBruteForce
- UnauthorizedAccess:EC2/SSHBruteForce
なお、以下の点は予め留意した上で、デプロイ先のアカウント、GuardDutyの通知先を事前に考慮することをお勧めします。
- 本環境はTorノードにアクセスする仕様になっているため、CDKをデプロイした後にUnauthorizedAccess:EC2/TorClientが勝手に検出される
- FindingTypeを指定して検出させても、複数のアラートが発生する場合がある
Detective管理アカウントによる調査方法
お待たせしました。Detectiveを使って調査を始めましょう！
Detectiveで利用できる機能は大きく分けて3つあります。
検出結果グループ（finding groups）
関連性のありそうな検出結果を検出結果グループとしてまとめてくれる機能です。
検出結果グループの概要を要約してくれたり、各エンティティ間の関連性を可視化してくれます。
注意点として、GuardDutyアラートが生成されて検出結果グループが作成されるのに最大48時間を要するということ、利用できるリージョンに限りがあります。
- 検出結果グループの一覧
- 検出結果グループの概要を要約
- 生成AIによって個々の検出結果グループを要約する機能で、以下のような内容を確認できる
- 関連する以下の検出結果を一覧で確認できる
- GuardDuty
- Security Hub
- Inspector（ネットワーク到達可能性とソフトウェアの脆弱性）
- 各エンティティ間の関連性を可視化（Finding group visualization）
- 攻撃の起点や関連しているリソースを図から読み取れる
- ブルートフォース系のアラートはインバウンド/アウトバウンドで色分けされる
- Finding group visualizationから特定のエンティティを選択してドリルダウン的に検索することが可能（→インスタンスIDで検索に遷移）
調査機能（Detective Investigation）
IAMユーザーまたはロールに関連するIoC（Indicator of Compromise; 侵害の証跡）を調査し、レポートを作成します。
対象のIAMユーザーまたはロールがセキュリティインシデントに関与しているかの判断に役立つ機能です。
- リソース（IAMユーザーまたはロール）を選択し、調査を実行するとレポートが生成され、影響度に基づいて調査結果の重要度が割り当てられる
IAMユーザーを調査
- MITRE ATT&CKのTTP（攻撃手順）によってマッピングされ、重要度が判定された例
ロールを調査
検索機能（search）
アカウントレベル、またはアカウント内の各エンティティレベルで分析できる機能です。
いくつか例をあげてみました。
アカウントIDで検索
- GuardDuty、Security Hub、Inspectorの検出結果を一覧で確認できる（各エンティティレベルでも確認可能）
- 新しい動作では、新たに観測された位置情報を確認できる（各エンティティレベルでも確認可能）
- 時間範囲内に観測された位置情報はオレンジの丸で表示される
- 位置情報を一覧でも表示でき、全体のAPI呼び出しに占める割合なども確認できる
- 時間範囲内に観測された位置情報はオレンジの丸で表示される
インスタンスIDで検索
- 対象インスタンスの詳細（作成者や作成時刻など）を確認できる
ロールをドリルダウンしたい場合はロール名のリンクをクリック（→インスタンスに紐づくロールで検索に遷移）
- インスタンスに紐づくIPアドレスを確認できる
- VPCフローログに基づいて観測されたリモートのIPアドレスを一覧で確認できる
- リモートのIPアドレスの通信の方向、allow/denyについてフィルターできる
インスタンスに紐づくロールで検索
- 検出結果グループや調査レポートとの紐付けがあれば確認できる
調査（Detective Investigation）が未実施であればその場で実施できる（→ロールを調査に遷移）
- IPアドレス別 -> サービス別のAPIの呼び出し結果を一覧で確認できる
IPアドレスで検索
IAMユーザー名で検索
- 検出結果グループや調査レポートとの紐付けがあれば確認できる
調査（Detective Investigation）が未実施であればその場で実施できる（→ IAMユーザーを調査に遷移）
- 対象のIAMユーザーによって呼び出されたサービス別のAPIの結果を一覧で確認できる（キャプチャは割愛）
まとめ
Detectiveを活用することで、セキュリティインシデントに関連したリソースが可視化され、調査が容易になります。
以下のポイントを押さえ、効果的な活用を目指しましょう。
- Detective管理アカウント／メンバーアカウントにて事前に必要な設定を実施する。
- Detectiveの各種機能を活用
- 検出結果グループ： 複数のセキュリティイベントの関連性を俯瞰的に把握する。
- 調査機能： IAMユーザーやリソース単位での分析を行い、侵害の痕跡（IoC）を特定し、セキュリティインシデントへの関与を判断する。
- 検索機能： エンティティレベルで詳細に分析できるようになっており、問題の根本原因を特定する。
- コストへの配慮
- Detectiveの利用においては、30日間の無料期間中にデータ量や費用感を確認する。
- メンバーアカウント側で予め明示的にDetectiveを有効化しないこと。
- オプションデータソースであるEKS監査ログは必要なければ有効化しないこと。
最後にちょっとだけ補足
Detectiveの使い方としては、検出結果グループで概要を掴み、その後は調査機能でインシデントの有無を判断したり、検索機能で詳細調査する流れが理想的かと考えています。
ただし、検出結果グループが反映されるまでにGuardDutyアラート生成後、最大48時間を要するという制約があり、検出結果グループを見たい時にまだ見られないということが起こり得ます。
上記について改善要望を挙げていますが、より早く検出結果グループが生成されるように改修されることを期待したいと思います。
また、Detectiveがその効果を最も発揮するのは、Amazon Detectiveとはで図示されている通り、Inspector、Security Hub、GuardDutyの検出結果から、それぞれの関連性を読み解く必要性が生じた時だと思います。
例えば、利用しているOSSにSSRFの脆弱性があり、インスタンスIMDS v2が適用されておらず、GuardDutyから"UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS"が検出された。みたいなケースです。
参考：https://aws.amazon.com/jp/blogs/news/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/
今回利用したGuardDuty Findings Testerではそのようなシナリオを作ることが難しいため、あくまで機能紹介という形でお伝えしました。
執筆：@fukuyama.kenta、レビュー：@nagamatsu.yuji
（Shodoで執筆されました）
