[アップデート] Amazon DetectiveがSecurity Lakeとの統合をサポートしたので試してみた #AWSreInvent

あしざわです。

AWS re:Invent 2023中に発表されたアップデートにて、Amazon Detective とAmazon Security Lake の統合がサポートされました。

以下AWS What’s newの記事です。

本記事では、アップデートの概要 および サービス統合をやってみた様子をお届けします。

概要

本アップデートについてのDetectiveの公式ドキュメントからの引用です。

Amazon Detective integrates with Amazon Security Lake, which means that you can query and retrieve the raw log data stored by Security Lake. Using this integration, you can collect logs and events from the following sources which Security Lake natively supports.

• AWS CloudTrail management events
• Amazon Virtual Private Cloud (Amazon VPC) Flow Logs

これまでAmazon Detectiveはログイン試行、API コール、ネットワークトラフィックに関するイベントをCloudTrail管理イベント、VPCフローログから自動検出した結果をソースに調査を行っていましたが、ソースとしてSecurity Lake上に保存される生ログを取得することでより多くのデータを得られるようになったようです。

ただ、実際にどのようなメリットがあるのかアップデートの文面や公式ドキュメント上からは読み取れなかったので、手を動かして検証してみます。

やってみた

Organizations組織にあるアカウント上でGuardDuty、Detective、Security Lakeを既に有効化してあるアカウントで検証をはじめます。

また、今回の検証環境ではGuardDuty、DetectiveはSecurity-Toolingアカウントを、Security LakeはLogArchiveアカウントを委任管理者に指定し有効化しています。

統合の有効化

Security Lakeの委任管理者アカウントで、Security LakeのソースCloudTrail管理アカウント、VPCフローログが取得されているかを確認します。

現状、マネジメントコンソールからはそれぞれのソースが各アカウント・各リージョンで取得されているかを一目で確認する方法がないため、以下のようにSecurity Lake > アカウントの画面で有効になっているソースの数をホバーしてCloudTrail管理イベント・VPCフローログが有効になっていることを確認しました。

このアカウントでSecurity Lakeを有効化した時にはありませんでしたが、現在はIngest default AWS sourcesという取り込みデータの推奨設定が指定できるようになっていました。

大量のデータが発生しうるCloudTrail - S3 データイベントを除いたものでソースが設定されるため、基本的にはこれを選べば問題なさそうです。

続いて、Detective委任管理者アカウントのDetectiveコンソール、Integrations > Security Lake integrationでリソース共有のために必要な以下情報をメモします。

• Detectiveの委任管理者アカウントのAWSアカウントID
• 外部ID

再度、Security Lake委任管理者アカウントにログインし、Security Lakeコンソールのサブスクライバー > サブスクライバーを作成から以下パラメータを入力して進めます。

• サブスクライバー名： detective
• ログとイベントソース： CloudTrail - 管理イベント、VPC フローログ
• データアクセス方法：Lake Formation
• サブスクライバーの認証情報：メモしたDetective管理アカウント ID、外部IDを入力

サブスクライバーが作成できたらリソース共有ARNをメモします。

Detective委任管理者アカウントに戻ります。

Security Lake subscriberのResource Share ARNに、先ほどメモしたリソース共有ARNを入力します。

利用中のIAM権限が不足している場合は、コンソールのStep 1: Copy IAM permissionsで確認できるようなIAM権限を付与してください。

ここから統合を行う前に、以下を実施する必要があります。

• リソース共有 ARN 招待の受け入れ
• AWS Glue クローラーの作成
• AWS Lake Formation 管理者権限の付与

これらをまとめて実行できるCloudFormationスタックが利用できるので、Use CloudFormation templateからテンプレートを実行します。

CFnスタックのパラメータは以下を入力します。

• AthenaResultsBucket（任意）：Athenaのクエリ結果を保存するS3バケットのARN。未指定だと新規作成される。
• DTRegion（固定）：デフォルトでOK
• LakeFormationPrincipals：ログイン中のIAMリソースのARN を入力
• ResourceShareArn（固定）：デフォルトでOK

チェックを入れてスタックを作成します。

スタック作成が完了した後、Detectiveコンソールを確認するとIntegrationの欄がEnabledとなっていました。

これでDetectiveとSecurity Lakeの統合が完了した模様です。

GuardDutyの検知テスト

GuardDutyの検知させるテストを実施してみましょう。

以下の方法を取って、簡易的にテストしてみたいと思います。

組織の中でGuardDuty、Detective、Security Lakeが有効なアカウント、東京リージョンでテストを行いました。

やったことは、パブリックサブネットに起動したEC2で以下コマンドを実施したのみです。

nslookup pool.supportxmr.com

しばらく待つとCryptoCurrency:EC2/BitcoinTool.B!DNSの項目で検知していました。

執筆時は検知できるとこまでの検証としていました。

追加の検証(2023/12/5追記)

後日にre:Invent2023のセッション動画 [LAUNCH] Elevate your security investigations using generative AI (SEC244) を視聴しました。

動画の中で、Detectiveの調査結果のコンソール上からCloudTrailなどの生ログに対しAthenaによるクエリができる機能が紹介されていました。

こちらを試してみたいと思います。

再度、CryptoCurrency:EC2/BitcoinTool.B!DNSで検知したいたGuardDutyの検出結果からDetectiveのコンソールへ遷移しようとすると、検出結果グループにいったほうがいいとガイダンスが表示されました。

Findings単位のDetectiveの検索画面は個人的に少しみづらいと感じるため、これは便利ですね。

検出結果グループに遷移し、検出結果グループ > 関連するエンティティのEC2インスタンスを選択します。

EC2インスタンスの詳細画面の下の方に、VPCフローデータに関するグラフが表示されています。トラフィックのグラフ上、黒枠で囲われている箇所がGuardDutyで検知した時間の前後1時間のログ量を表しているように見えます。グラフの種類は、線型・ログのどちらでも問題なさそうです。

時間間隔を未設定もしくは時間範囲の詳細を表示してくださいのどちらかを選択してください。

すると、グラフの下、タイムウインドウのアクティビティの枠にVPCフローログをサマリしたもの（ところどころ情報が抜けているため）が表示されました。続けてQuery raw logsをクリックします。

「Raw log preview: VPC Flow」のウインドウが表示されました。内容からVPCフローログの生ログを分析した結果だとわかります。青枠のDownloads resultsからはこの結果をそのままcsvファイルでダウンロードできました。

See Results in Athenaクリックすると、この出力結果が得られるクエリが入力された状態のAthenaのコンソール画面が開きます。この結果に続けてAthenaを使ったフィルタを行う場合に、役に立ちそうです。

検証は以上とします。

さいごに

Amazon DetectiveのSecurity Lake統合について紹介しました。

統合の有効化は公式ドキュメント通りの手順で問題なく進められました。ただし、アカウントが異なる場合複数のアカウントを行き来して設定を行うことになるため、もう少しシンプルに設定できるようになると嬉しいなと思いました。

検知テストについては、追加で検証を行ったDetectiveでQuery raw logsの箇所以降がアップデートによってできるようになった新機能だとわかりました。

サマリした結果の取得だけであればDetectiveだけでもできますが、Security Lakeと統合することによって完全なログの分析が可能になります。

Detectiveによる分析の後に生ログの分析を行う手間を感じていた方は、Security Lake統合をお試しください。

今回はVPCフローログをチェックしましたが、Youtube動画の画像からはCloudTrailの生ログも検索できるようです。また試してみたいです。

以上です。