トップ > Amazon GuardDuty > Amazon GuardDutyでエンティティリストを使用した脅威検出のカスタマイズ

Amazon GuardDutyでエンティティリストを使用した脅威検出のカスタマイズ

Amazon GuardDuty セキュリティ
記事タイトルとURLをコピーする

はじめに

こんにちは！
「はじめに」に書く面白いことが浮かばず、自分の限界を感じているCC2課の滝澤です！

唐突ですが、みなさんAmazon GuardDutyはお好きですか？私は嫌いです
（だって、脅威が検出されるんだもの）
今回はGuardDutyのアップデートについてご紹介させてください！

概要

2025年9月5日付で、GuardDutyでエンティティリストを利用した脅威検出の強化というアップデートがありました。
GuardDutyは以前からIPアドレスのみTrusted ListやThreat Listを利用して、脅威検出の範囲をカスタマイズ可能でした。
今回のアップデートでドメインレベルでの制御も可能となり、ドメインとIPアドレスを含めてTrusted ListやThreat Listで制御できるようになり、エンティティリストという機能で提供が開始されました。

aws.amazon.com

また、上記のアップデートと合わせてカスタムエンティティリストのドメインによって脅威が検出された場合に発生する新しい検出タイプである、「Impact:EC2/MaliciousDomainRequest.Custom」も追加になっています。

今回はこのエンティティリストを使ってみようと思います！！

なお、CLIベースの利用方法などは以下ブログにて記載がありますので、ぜひご参照ください。

blog.serverworks.co.jp

やってみた

検証環境

検証環境としては以下の図の通りとなります。
エンティティリストはS3バケットに保存します。
脅威検出のテストのために、インターネット上のドメインに対してEC2からPingを行います。

環境構成

エンティティリストの前提条件

エンティティリストを利用するにあたって、以下前提条件が必要となります。

  • エンティティリストを保存するS3バケットに対して「s3:GetObject」のアクセス許可が必要です。
  • エンティティリストのファイルとして使用できる形式は以下の通りです。実際の形式は、下記リンクを参照してください。
    • プレーンテキスト(TXT)
    • 脅威情報構造化記述形式(STIX)
    • Open Threat Exchange(OTX)TM CSV
    • FireEyeTM iSIGHT 脅威インテリジェンス CSV
    • ProofpointTM ET Intelligence Feed CSV
    • AlienVaultTM Reputation Feed

docs.aws.amazon.com

注意点

エンティティリストを使用するにあたり、以下の重要な考慮事項があります。
※IP リストとは若干異なりますので、ご注意ください。

  • エンティティリストは、パブリックにルーティング可能な宛先のトラフィックのみに適用される。
    • VPC内などの内部通信に対しては有効ではありません。
  • エンティティリストは、GuardDutyの元ネタとなるCloudTrail、VPCフローログ、Route53 Resolver DNSクエリログの結果に適用される。
  • Trusted Entity ListとThreat Entity Listの両方の同じ内容を含めた場合、Trusted Entity Listが優先されます。
  • マルチアカウント構成では、GuardDuty管理者アカウントのみリストの管理が可能です。また、リストの設定はメンバーアカウントに自動的に適用されます。
  • IPv4アドレスのみサポートされます。
  • エンティティリストの有効化、無効化、更新、削除は15分以内で完了されますが、特定の場合最大40分程度時間がかかります。
  • エンティティリストは更新してS3にアップロードしただけではGuardDuty側では更新されません。
  • エンティティリストのクォータはIP リストとは異なります。
    • Trusted Entity Listあたりのエンティティ数：1000 (上限緩和不可)
    • Threat Entity Listあたりのエンティティ数：1000 (上限緩和不可)
    • エンティティリストの最大ファイルサイズ：35MB (上限緩和不可)

Trusted Entity List

まずはTrusted Entity Listを用意します。今回はプレーンテキストでリストを作成します。
検証ではGuardDutyで「Backdoor:EC2/C&CActivity.B!DNS」の検出結果のテストを行うためのテストドメインである、「guarddutyc2activityb.com」でリストを作成しています。
※あくまで検証なので、GuardDutyのテストドメインを登録しておりますが、結果として「guarddutyc2activityb.com」はTrusted Entity Listに追加しても脅威検出されてしまいます。

Trusted Entity Listの中身

エンティティリストが作成できたら、S3バケットにアップロードします。
アップロードが完了したら、GuardDutyのコンソールから[設定] - [リスト] - [Entity lists]タブを選択し、[Add a trusted entity list]を選択します。

Trusted Entity Listの作成1

[Trusted Entity listを作成]画面で、以下項目を入力して[リストの追加]を選択します。 ※Expected bucket ownerはオプションのため、今回は入力を割愛しています。

入力項目 値 備考
リスト名 任意のリスト名を入力 -
場所 S3に保存したエンティティリストのURIを入力 -
形式 S3に保存したエンティティリストの形式を選択 選択可能な形式は前提条件を参照
Expected bucket owner(オプション) 「場所」に入力したS3バケットの所有者アカウントIDを入力 入力しない場合GuardDutyが自動でS3バケット所有者を検証します(※)
同意します チェックをつける チェックしないとリストの追加ができません

※GuardDutyがこのS3バケットが指定されたアカウントID に属していないと判断した場合、リストの有効化時にエラーが発生します。

Trusted Entity Listの作成2

リストの作成が完了すると、リストは「Inactive」状態で追加されます。

Trusted Entity Listの作成3

ここ！非常に重要な手順です！！リストは自動的に有効化されないため、手動での有効化が必要です！
[アクション] - [有効化]を選択します。

Trusted Entity Listの作成4

有効化は15分以内で完了します。（場合によっては最大40分）
ステータスが「Active」となったら、リストの設定がGuardDutyの検出結果に反映されています！

Trusted Entity Listの作成5

Threat Entity List

続いて、Threat Entity Listを試してみます。
Threat Entity Listにみんな大好きGoogle先生のドメイン「google.com」を追加してみようと思います。
リストの作成と追加方法はTrusted Entity Listと同様なため割愛します。

Threat Entity Listの作成1

EC2からgoogle.comに対してPingを実行して少し待ってみると...
「Impact:EC2/MaliciousDomainRequest.Custom」が検出されていますね！

Threat Entity Listの作成2

Impact:EC2/MaliciousDomainRequest.Customについて

せっかくなので、Impact:EC2/MaliciousDomainRequest.Customではどういった内容が確認できるか見てみましょう！
まず、タイプは新しい検出結果のタイプである「Impact:EC2/MaliciousDomainRequest.Custom」が確認できますね。
このタイプの重要度は「ミディアム（中）」のようです。

Impact:EC2/MaliciousDomainRequest.Customについて1

Action typeではどのような通信だったのか、Actorではどこに接続したのかが確認できます。
また、脅威リストではどのThreat Entity Listの設定で検出されたのかが確認できます。

Impact:EC2/MaliciousDomainRequest.Customについて2

リストの更新

最後にリストの更新方法を確認します。
まず、エンティティリストの内容を更新し、S3バケットにアップロードします。
ここ！非常に重要な手順です！！S3のファイルを更新しただけでは、GuardDuty側は更新されません。必ずGuardDuty側での更新作業が必要です！
更新するリストを選択し、「編集」を選択します。

エンティティリストの更新1

「同意します」にチェックをつけ、「リストの更新」を選択します。 ※リストの作成時に割愛した、「Expected bucket owner」は自動的にS3バケットの所有者が入力されていました。

エンティティリストの更新2

Trusted Entity ListとThreat Entity Listに同じ設定を追加したらどうなるか

重要な考慮事項にも記載がありましたが、Trusted Entity ListとThreat Entity Listに同じ内容を設定した場合は、Trusted Entity Listが優先されるようですがいくつかのパターンについて検証した結果を以下の表にまとめました。

  • TrustedもThreatも同じ

    両方同じパターン

  • Trustedがワイルドカードドメイン、Threatが特定ドメイン

    Trustedがワイルドカード、Threatが特定ドメイン

  • Trustedが特定ドメイン、Threatがワイルドカードドメイン

    Trustedが特定ドメイン、Threatがワイルドカード

パターン 結果 備考
TrustedもThreatも同じ 脅威検出されない -
Trustedがワイルドカードドメイン、Threatが特定ドメイン 脅威検出されない -
Trustedが特定ドメイン、Threatがワイルドカードドメイン 一部脅威検出されない Trustedに設定した特定ドメインのみ脅威検出されません

想定通りの結果となりましたね！
また、「Trustedが特定ドメイン、Threatがワイルドカードドメイン」のようにあるドメイン全体は信頼しないが、その特定のドメインのみ信頼するといった制御が可能です。
考えられるケースとしては、ワイルドカードで指定されたドメインの署名が信頼できない認証局によるもので、特定のドメインの認証局が信頼できる場合です。

再度リストの注意点を記載すると、誤って同じ内容を登録してしまっていた場合、もともとTrusted Entity Listに入っていたものをThreat Entity Listに追加したのであればそこまで問題はありませんが、逆だった場合は本来脅威を検知したいドメイン、IPからの検知ができなくなってしまうため注意が必要です。

嬉しい点/気になった点

嬉しい点

今までIPアドレスでしか対応できなかったため、IPアドレスが変更となった場合に都度変更が必要でしたが、今回のアップデートでドメインでの制御が可能となったため、管理の手間の減少と柔軟性が向上しました。

気になった点

利用していて感じた気になる点としては以下の4つがありました。

  • リストを作成/更新した後の有効化を忘れそう
    • リストを追加しただけでは使用されません！必ず有効化を行いましょう
  • S3のリストファイルを更新しただけでGuardDuty側の更新を忘れそう
    • 動的にリストの更新を認識してくれるわけではありません！必ず更新を行いましょう
  • リストの有効化にそこそこの時間がかかる
    • 有効化や更新を行うと体感で10分程度かかります。公式でも述べられている通り15分以内で完了するようですが、ケースによっては40分かかることもあるようです
  • TrustedとThreatの登録内容の誤りに注意
    • 両方に同じ内容を追加した場合は、Trusted Entity Listが優先されるので必ず追加して良い内容か確認する必要があります

さいごに

さてGuardDutyのエンティティリストについて見てみましたがいかがだったでしょうか？
嬉しいアップデートなので、上手に使って行きたいですね！
余談ですが「Threat」ってなんて読むか知ってます？？「スレット」ですよ。（意外と読めない方がいましたのでね）

この記事が誰かの役に立つと幸いです。

kento.takizawa(記事一覧)

妻と娘をこよなく愛すエンジニア