re:Invent 2024: AWSのGuardDutyによる高度な脅威検出と機械学習
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Uncovering sophisticated cloud threats with Amazon GuardDuty (SEC219)
この動画では、Amazon GuardDutyによる高度なクラウドの脅威検出について解説しています。上位2000社の95%が利用し、数百万のアカウントをカバーするGuardDutyの規模感や、新機能のExtended Threat Detectionによる攻撃シーケンスの検出機能が紹介されています。また、Mithraによる日々18万以上の悪意あるドメインの発見や、MadPotというHoney Potネットワークを活用した脅威インテリジェンスの収集、表現学習やMarkerを用いた機械学習モデルによる異常検知の仕組みなど、AWSならではの高度なセキュリティ機能の詳細が説明されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Amazon GuardDutyによる高度なクラウド脅威検出の概要
皆様、本日はご参加いただき、ありがとうございます。時間は私たちにとって最も貴重な資産であり、皆様がre:Inventで私たちと時間を共有してくださることに感謝申し上げます。本日のセッションは、Amazon GuardDutyによる高度なクラウドの脅威の検出についてです。私はMattで、Detection and Responseサービスのワールドワイドのセキュリティリーダーを務めています。皆様、おはようございます。私はShachar Hirshbergで、Amazon GuardDutyのProduct Managerを務めています。皆様、こんにちは。私はBarisで、AWS Security ServicesのSenior Principal Scientistを務めています。
本日は、アジェンダスライドを少し趣向を変えてみました。このようなアジェンダスライドを見たことがある方はいないのではないでしょうか。私も初めてですので、皆様のために特別に作成しました。今日は、データから検出結果に至るストーリーをお話しします。まず左側から始めて、私が左の2つのブロック、Amazon GuardDutyの基本的な保護プランとその運用規模についてお話しします。次にShacharが、検出結果と、私の意見では数年来最大規模となる、GuardDutyの新機能についてお話しします。そして、Principal ScientistのBarisが、AWSワークロードのセキュリティ向上に活用されるシグナルとインサイトにつながる、データの分析と処理についてお話しします。
GuardDutyの運用規模と内部セキュリティツールの活用
GuardDutyの素晴らしい点の一つは、その運用規模と広範さです。現在、上位2000社のお客様の95%（1～2%の誤差はありますが）にご利用いただいており、数百万のアカウント、数億のEC2インスタンス、そして数百万のバケットをカバーしています。これらすべてを、お客様が計算リソースの管理や、リソースタイプやサイズの変更、新しいものをアカウントにデプロイするといった、差別化につながらない作業を行う必要なく実現しています。数年前にGuardDutyを最初にリリースした時、CloudTrail、VPC、DNS Resolverログの基本モデルについては、ボタンをクリックするだけでワークロードに関する検出結果を得ることができました。
よく質問されるのが、AWSのセキュリティチーム（CSOやManaged Security Services）がどのように協力しているかということです。今日は、それがAmazon GuardDutyにどのように組み込まれているかについてお話しします。このスライドにはSonariは記載されていませんが、Sonariは検出結果の分析が必要になる前に、AWSワークロードに対する列挙活動やその他の活動をブロックするためにAWSで使用されています。Sonariは、私たちがデフォルトで提供するAWSクラウドの保護において重要な役割を果たしています。AWSは最大のクラウドフットプリントを持っており、それにより悪意のある行為者によるネットワークや活動全般について深い文脈理解が可能となっています。
私たちは、社内セキュリティチームが使用する、あるいはセキュリティチームが構築してManaged Servicesと共有する脅威インテリジェンスフィードを開発するための内部ツールを実際に構築しています。Mithraはその最初の例で、悪意のあるドメインを発見するために使用され、毎日180,000以上の新しい悪意のあるドメインを発見しています。これにより、GuardDutyは、それらの悪意のあるドメインが公開されている脅威インテリジェンスリストや有料リストで認識される何日も、何週間も、あるいは何ヶ月も前に、お客様のアカウントで検出結果をアラートとして通知することができます。昨日、あるお客様と、同様の脅威インテリジェンスモデルの構築について投資すべきかどうかという会話をしました。数十億のノードと数兆のエッジまたはリクエストを扱うMithraの規模では、これは本当にAWSだけが提供できる独自のポジションにあるものなのです。
多くの方はHoney Potについてご存知だと思います。MadPotは、世界中に分散配置されたHoney Potのネットワークです。Honey Pot（ハニーポット）という名前の由来は、蜂が蜜に群がることからきています。よく「なぜ銀行強盗は銀行を狙うのか」と聞かれますが、それはそこにお金があるからです。同じように、悪意のある攻撃者がクラウドを標的にしてデータを収集しようとするのは、それが彼らにとって価値があるからです。そこで、蜂が群がるように、Honey Potが設置されるわけです。これにより、悪意のある攻撃者がクラウド環境で実際に何をしようとしているのか、その行動パターンを理解することができます。そして、これらの行動モデルは脅威インテリジェンスとして、Amazon GuardDutyサービスとリアルタイムで共有されます。
AIモデルを構築する際、私たちは活動や行動の状態を理解するために、特定の方法でデータを分割します。これがMadPotの役割です。新しい脅威の戦術が出現しているのか、それとも一般的な脅威の戦術なのか、といった分析が可能になります。実際に、Fault、Typhoon、Sandwormなどの攻撃をブロックするのに役立っており、CISOたちはこれらの問題から自身を守るため、あるいは問題を解決するためにログを共有して協力しています。私はPrime Dayやホリデーシーズンが大好きです。これは単にAmazonで働いているからというわけではありません。私たちの社内セキュリティチームはGuardDutyを使用してCloudTrailイベントを監視していますが、Prime Dayは明らかに利用が急増します。今、私の家族は自宅にいて、母が私の犬の様子を見に家に寄ったのですが、Prime Dayで注文した商品がたくさん玄関の外に置かれていたそうです。きっと皆さんも同じような経験があるのではないでしょうか。母は「まあ、また5つも届いているわ」と言っていました。私もPrime Dayの CloudTrailイベントの一ユーザーというわけです。GuardDutyは1時間あたり6兆件のログイベントを監視し、これは前年比で32%近い増加でしたが、基盤となるインフラの管理は一切必要ありませんでした。
Extended Threat Detectionの導入とAttack Sequencesの仕組み
セキュリティチームから得られたすべての基礎的な脅威インテリジェンスは、保護プランという形でGuardDuty に送られます。これらの保護プランは、様々なリソースからデータを集約することで機能します。最初はCloudTrailとVPC DNSでスタートしましたが、時間とともにGuardDutyサービスは大きく進化し、リソースのカバー範囲を拡大し、検出結果に対してより深いコンテキストを提供できるようになりました。入力されるすべてのデータは、セキュリティ関連のイベントのみに絞って処理されます。CloudTrailのすべての列や行を取り込むのではなく、私たちの科学者が構築するセキュリティモデルに関連する部分のみを見ています。
このデータはすべて、社内で開発されたAIとMLアルゴリズムに投入されます。これらは公開されているモデルではなく、データはすべてAWS環境内に留まります。そして、これらのシグナルとデータから検出結果が生成され、それらの結果は、SIEMなどのサードパーティツールや、私たちの内部のCSPM Security Hub Detective、そしてセキュリティ運用組織のダウンストリームで連携することができます。すべての検出結果は、適切に対応できるよう、必要なコンテキストとメタデータを含めてEventBridgeストリームに書き出されます。特に素晴らしいのは、GuardDutyがバックプレーンで自動的にリソースからログを収集することです。現在有効になっているログ設定に関係なく動作します。例えば、VPC Flow Logsを有効にしていなくても、GuardDutyはVPC Flow Logsを監視できます。GuardDutyが自動的にログを取得し、そのログストリームは中断されることがありません。
他の方法でアラートや検出を行っている場合、ユーザーがCloudTrailをオフにすると、検出の詳細や相関関係にギャップが生じる可能性がありますが、GuardDutyではそのようなことはありません。ログストリームは中断不可能です。機能全体を無効にしない限り、GuardDutyがリソースから取得するフィードを変更したり操作したりすることはできません。さらに、GuardDutyはリソースに関する情報を非常に深いレベルで収集することができます。GuardDutyは、他では簡単に入手できない情報やインサイトを提供できる独自の立場にあります。その一例がRDSログインイベントです。RDSにおける予期せぬ、あるいは予期された成功・失敗のログインを実際に確認することは、他のサービスではかなり困難です。そして、これらをカバーするために、 GuardDutyには基本的な脅威検出サービス、つまり基本モードがあり、さらにオプションの保護プランがあります。これらは、セキュリティワークロードにとって最も重要なリソースを選択して有効にできるように設計されています。
これらのオプションの保護プランは、それぞれ個別に有効化することができます。すべてのプランには30日間の無料トライアルがあり、重要なポイントは、この無料トライアルが新しい保護プランごとに適用されるということです。つまり、現在Amazon GuardDutyを使用している場合でも、新しい保護プランを有効にすれば、そのプランに対して30日間の無料利用期間が得られます。これはアカウントごとにも適用されるので、テスト環境で試してから本番環境に移行する場合や、アカウントをまたいで使用する場合でも、保護プランとアカウントのレベルで無料トライアルがリセットされます。
チームが今年多くの時間を費やしたのはRuntime monitoringで、GuardDutyはサービスによって完全に管理される独自のエージェントを開発しました。これは軽量なeBPFエージェントで、GuardDutyに管理を任せることで、リソースに自動的にデプロイすることができます。高性能で軽量なため、本番アプリケーションのパフォーマンスに影響を与えることはありません。このエージェントは、Amazon EC2ではSystems Managerエージェントとして、Amazon EKSではアドオンとして、そしてAWS Fargateではサイドカーとして動作し、自動的にログを収集してモデルに送信し、検出結果を得ます。
このエージェントベースのテレメトリーの特筆すべき点は、VPCフローログを読み取る必要性が減ることです。GuardDutyは、このエージェントベースのランタイム保護が有効になっているリソースについては、VPCフローログのモニタリングコストを相殺します。フローログは引き続き取得して確認しますが、その分の支払いは不要です。これによってお客様が得られる価値は、コンテナワークロードに関する検出結果のコンテキストがより詳細になることです。以前は、監査ログの検出結果はインスタンスに関するコンテキストのみを提供していましたが、どのPod、どのホスト、どのタスクやプロセスIDを修復のために調査する必要があるのかが分かりにくいことがよくありました。
エンドポイントを使用することで、コンテナ内の個々のPodやホストのタスクプロセスIDについて、より詳細なコンテキストが得られます。ランタイムの検出結果で得られるすべての追加コンテキストは、検出結果のメタデータで確認することができます。 GuardDutyのお客様との会話で最も多く求められる3つの要素は、MITRE ATT&CK Frameworkへのマッピング、GuardDutyがなぜこの検出結果を生成したのかの説明、そして最も重要な事項を判断するための高レベルでのトリアージ機能です。本日、この新機能のローンチを発表できることを嬉しく思います。この詳細についてはShaharが説明します。
Attack Sequencesの詳細と実際の検出結果の例
ご存知の通り、GuardDutyは過去数年間にわたってさまざまなデータソースへのカバレッジを拡大してきました。データの流出、認証情報の侵害、そしてクラウド環境を使用する際に直面する可能性のある様々なリスクに関連する185種類以上の検出結果があります。セキュリティチームから聞こえてくる声は、これらの異なるアクティビティに対する深い保護を手に入れた一方で、それらを統合することに苦労しているということです。多くのアラートを受け取っており、実際、アラートが足りないと言うセキュリティチームには一度も出会ったことがありません。 彼らはこれらすべてのアラートを受け取り、それらを組み合わせて、異なるツールからの異なるアラートがどのように関連しているかを理解する必要があります。今日まで、これを行う方法は比較的手作業で時間がかかり、クラウドセキュリティ全般に関する専門知識と、得られる可能性のある様々な種類の検出について理解する必要がありました。今週初め、私たちはGuardDuty Extended Threat Detectionを発表し、この機能について本当にワクワクしています。これまでに得られたフィードバックは素晴らしいものでした。では、これが何なのかについて説明しましょう。先ほど述べたように、これまでGuardDutyはデータソースに関連するこれらの異なる検出結果の発見を支援してきました。今回、この新しいExtended Threat Detectionは、これらの異なるデータソースを横断的に見て、異なるシグナルを組み合わせることで、私たちが現在呼んでいるものを特定します。
Attack Sequencesは新しいタイプのFindingで、複数のセキュリティシグナルを組み合わせて提示します。様々なリソースに関連し、より長い時間枠もカバーしています。実際に24時間の時間枠にわたって、これらの異なるアクティビティを相関分析しています。
この新しいAttack Sequencesにより、独立したアラートを個別に確認してそれらの関連性を理解しようとする必要がなく、すでに関連付けられたAttack Sequenceを確認するだけで済みます。これにより、Findingの一次分析やトリアージにかける時間を大幅に削減でき、GuardDutyが最も信頼度が高いと判断した優先度の高い脅威に集中できます。これらは実際の脅威である可能性が格段に高く、ぜひ確認することを強くお勧めします。
仕組みについて説明しましょう。これは、マルチステージのクラウド攻撃を検出するためのマネージドアプローチと考えています。ご存知の通り、クラウド環境で実際の侵害や攻撃が発生した場合、それは複数のステップに関連します。単一のアクティビティだけではなく、時間の経過とともに様々な痕跡が見られます。照明が眩しくて皆さんの顔がよく見えませんが、現在GuardDutyをご利用の方は何人いらっしゃいますか？素晴らしい、たくさんの手が挙がっていますね。おめでとうございます。皆さんすでにこの新機能が有効になっています。追加コストはかからず、設定も必要ありません。既存のGuardDutyユーザーの方には自動的に有効になっています。まだGuardDutyを使用されていない方も、GuardDutyを有効にすれば、追加の設定なしで自動的に有効になります。
この機能は、私たちの製品の大きな方向性の一部です。より統合されたセキュリティ価値の提供を目指しています。その方法として、Findingと、GuardDutyで観察される他の弱いシグナルを相関分析します。これらの弱いシグナルは、お客様がトリアージや理解に必要なFindingの数で圧倒されないよう、通常は顧客には送信していません。今後は、これらの弱いシグナルがFindingに関連している場合や、suspicious activityの十分な証拠を集合的に提供している場合、Attack Sequencesの中に含めて集約されます。Attack Sequencesは複数のProtection Planもカバーしています。
これらのAttack Sequencesを特定する方法として、一般的な攻撃パターンと新しい攻撃パターンの両方に対する幅広く深い可視性を活用しています。先ほどMattが説明したように、私たちは毎日何千、実際には何百万ものクラウドアカウントとそこで観察される様々なアクティビティを監視しています。お客様のために多くのセキュリティケースに対応し、その知見を活かして攻撃者が使用する新しい攻撃パターンについての知識を蓄積しています。攻撃者は新しいテクニックや新しいクラウドAPIを使って、本当に毎週のように手法を変えてきているからです。
私たちはこの知見を活用して、真の多段階攻撃とは何かという、セキュリティに関する直感的な理解を構築しています。また、先ほど説明した社内の脅威インテリジェンスシステムやベンダーとのコラボレーションなど、脅威インテリジェンスも活用しています。これらの新しい攻撃シーケンスについて、統合は非常にスムーズです。新しいタイプのFindingとしてリリースされるため、すでにGuardDutyをチケットシステムに連携している場合、これらの新しいタイプのFindingは、既存のGuardDuty Findingを使用している場所にシームレスに流れる可能性が高いです。GuardDuty FindingをConsoleやAPIで使用している場合も、同様にそこで利用可能になります。私たちは単にFindingのスキーマを拡張して、これらの新しいFindingに含まれる追加のコンテキストをサポートするようにしています。ただし、EventBridgeを使用してGuardDuty Findingを送信するためのルールやフィルターを設定している場合は、新しいタイプのFindingにフィルターが対応しているかどうかを確認することを強くお勧めします。
これらの新しいFindingは重要度がCriticalであり、レベルが9になっているという非常に重要な点があります。以前のフィルターの多くは重要度レベルでフィルタリングしていたため、これらの新しいタイプのFindingを確実に受け取れるよう、確認をお願いします。
これらのFindingが何を検出できるのか、お話ししましょう。Amazonでは、私たちが目にする主要な脅威から逆算して作業を進めています。クラウド環境への最も一般的な初期攻撃ベクトルは認証情報の侵害であり、そのため、最初の攻撃シーケンスタイプはこの特定のケースに焦点を当てています。認証情報の侵害に関連する攻撃シーケンスには、これらの認証情報がどのような権限を持っているかを理解するための偵察活動、新しいユーザーの作成などの永続化活動、さらにはEC2インスタンスを作成してCryptoマイニングを実行するといった影響度の高い活動など、複数のアクティビティが含まれる可能性があります。これらの異なる信号は以前からGuardDuty Findingとして利用可能でしたが、今日では、何が起こったかを理解するために必要なすべての情報を含む、Critical重要度の単一の攻撃シーケンスとして含まれることになります。
認証情報の侵害という最も顕著な、あるいは一般的な初期攻撃要因に対応できるようになりました。この新リリースで2番目に焦点を当てているのは、S3に保存されているデータの侵害です。データは、ほぼすべてのお客様や組織にとって最も重要な資産であり続けています。データ侵害に関連する攻撃シーケンスでは、例えば、より大規模なランサムウェア攻撃の一部として、シーケンスの一部として複数のアクティビティを使用するデータ流出の試みなどを検出できるようになります。例として、認証情報の不正使用に加えて、権限昇格や永続化、さらにS3に保存されているデータの流出や破壊を試みる可能性があります。注意点として、データ侵害攻撃シーケンスには、データの流出や破壊の試みを検出するのに役立つGuardDuty S3保護が必要です。バックグラウンドでは、CloudTrailアクティビティの可視性やS3保護など、基本的なGuardDutyからのアクティビティを相関させて、S3データプレーンで可視化されるテレメトリからの試みを検出します。
来年にかけて、これらの攻撃シーケンスをさらに多くのシナリオに拡張していく予定です。今後の展開について簡単にご紹介すると、次は侵害されたホストについてです。この場合、Mattが先ほど言及したGuardDutyのRuntime Monitoringや、他の保護プランを使用して、EC2ホストが侵害されたかどうかを検出します。コンセプトは同様で、マシン上での不審なコマンドの実行などの一連のアクティビティを検出します。例えば、誰かがwgetコマンドを実行してファイルをホストにダウンロードし、そのファイルが不審であると識別され、その後、既知のCryptoマイニングプールとの通信が確認された場合などです。以前はこれらすべてが個別のGuardDuty Findingでしたが、新しい攻撃シーケンスでは、必要な関連情報をすべて含む単一のFindingとなります。
これらのFindingがどのように見えるのか、詳しく見ていきましょう。 この機能の開発を始めた時の目標は、すぐに対応可能で状況に応じた適切なFindingを作ることでした。何が起こったのか、誰が関与したのか、どのようなアクションが行われたのか、そしてどう対処すべきかを理解するために必要な情報をすべて含めることを目指しました。そのために、シーケンスの一部として発生したアクティビティの説明と証拠の両方を含め、さらにGuardDutyのお客様から長年要望のあったMITRE ATT&CK TacticsとTechniquesへのマッピングも行っています。
Extended Threat Detectionのベータテストと実際の効果
これは、何が起こったのかを共通言語ですばやく理解するのに非常に役立ちます。多くのお客様が様々なセキュリティツールを使用しており、特定のFindingタイプが何を意味するのか分からない場合があることを私たちは理解しています。しかし、ここに持続的な活動があると説明すれば、より簡単に理解できます。対応をサポートするために、各タイプの攻撃シーケンスに対する推奨事項とベストプラクティスも提供しています。
では、楽しい部分であるデモに移りましょう。 ここがGuardDutyのコンソールです。新しい概要ページを追加したことがお分かりいただけると思います。セキュリティチームとして一日を始める際、GuardDutyや他のツールで検出された様々なFindingに取り組むことになります。ここでお見せする内容はすべて、新しいFindingのJSONでも利用可能です。先ほど申し上げたように、重要度が「Critical」のFindingは攻撃シーケンスを示しており、これらに対する通知の設定を強くお勧めします。GuardDutyからの通知で誰かを夜中に起こすとすれば、それはこれらの攻撃シーケンスFindingであるべきです。その重要度と信頼性に私たちは自信を持っています。
これは素晴らしい例です。このアカウントには約400の異なるFindingがありますが、攻撃シーケンスはわずか3つです。これが私たちが目指している比率です - 実際の攻撃は稀であるため、これらは少数しか見られないはずです。コンソール体験の改善の一環として、 より素早く状況を把握できるよう、重要度別にFindingを分類した新しいウィジェットも追加しました。ここでは、複数のタイプのFindingが表示されています。データ侵害に関連する攻撃シーケンスと認証情報侵害に関連する攻撃シーケンス、そして他のタイプのGuardDuty Findingです。攻撃シーケンスだけをフィルタリングして表示することもできます。
また、この新機能についてより詳しく学べる新しいページも追加しました。 Extended Threat Detectionのページでは、この機能がデフォルトで自動的に有効になっていることが確認できます。先ほど申し上げたように、GuardDutyとその個別の保護プランの基本的なコスト以外に、この機能を使用するための追加コストはありません。基本的なGuardDutyだけでも認証情報侵害のFindingを受け取ることができますが、S3保護などの追加の保護プランを有効にすると、データ侵害の攻撃シーケンスも受け取れるようになります。これらのFindingが発生しないことを願っていますが、もし発生した場合は、これらの保護プランを有効にする必要があることを覚えておいてください。来年を通じてこれらのFindingをさらに追加し、カバレッジを拡大した際にはページを更新していく予定です。
それでは、これらの検出結果の1つを見ていきましょう。この例では、侵害された認証情報による攻撃シーケンスを見ていきます。お気づきかもしれませんが、GuardDutyの検出結果に全画面表示を追加したので、小さなサイドパネルだけでなく、より詳細に確認できるようになりました。この活動に関連する4つの異なるシグナルが相関付けられ、認証情報が侵害されたことが特定されています。誰が活動を行ったのか - この場合はAdminユーザー - そしてPrincipal IDを確認することができます。この情報は重要です。例えば、そのPrincipalによって実行された追加の活動をSIMで検索したい場合などに役立ちます。また、どのアカウントで、いつ活動が発生したのかも確認できます。これは興味深いケースで、11月27日から28日にかけて2日間にわたって活動が発生していることがわかります。24時間のローリングタイムウィンドウを採用しているので、活動が進展している場合は継続的に監視し、追加情報で検出結果を更新します。つまり、誰が何をしたのか、いつどこで発生したのかはわかりましたが、次は実際に何が起きたのか、そしてこれが本当に問題なのかという確信を得たいと思います。MITRE ATT&CK TacticsとTechniquesを使用することで、状況を素早く把握することができます。
例えば、このケースでは、証拠は初期アクセスとディスカバリーから始まり、すぐにDefense Evasion（防御回避）やPersistence（永続化）へとエスカレートし、最終的にImpact（影響）まで至っています。活動が攻撃チェーン全体にわたっているため、明らかに不審です。Techniquesをより詳しく見ていくと、クラウドログの無効化やデータの流出、破壊などが確認できます。また、VPNやTorなどを経由した不審なネットワークからの接続や、この活動で使用されたユーザーエージェントに関する追加情報も提供しています。この場合、通常の本番環境では想定されないKali Linuxがユーザーエージェントとして使用されていました。
どの重要なAPIが呼び出されたか、そしてそのユーザーが初めてそれらを呼び出したかどうかを正確に示しています。CloudTrailの削除が確認されていますが、これは非常に不審です。なぜなら、これらのAPIが頻繁に呼び出されることは想定されていないからです。さらに、S3からのオブジェクトやバケットの削除も確認されています。これらすべてを総合すると、15〜30秒程度で重大な不審な活動が発生していることを理解できます。画面の左側には攻撃シーケンスに関するより詳しいコンテキストを表示し、右側には具体的な活動内容を表示しています。
コンテキストをより深く掘り下げると、各活動をクリックすることで、それぞれの活動に関連するMITRE Tacticsや何が起こったのか、そしてその検出結果にナビゲートすることができます。GuardDutyがなぜこれを不審な活動としてフラグを立てたのかというセキュリティ的な直感を示すインジケーターも確認できます。ほとんどの場合、不審なAPI呼び出し、複数の攻撃TacticsとTechniques、脅威インテリジェンス、ユーザーエージェントなど、複数の要因の組み合わせとなります。これらの情報を素早く確認できるようにし、誰が活動を実行したのか、どのネットワークから接続したのかについての詳細も提供しています。例えば、主にアメリカを拠点とする企業で米国内での運用が中心の場合に、この活動がDublinから実行されていた場合、その人がその週にDublinでリモートワークをしていた可能性もありますが、そうでない可能性もあります。これにより、本当に問題があるのか、そして具体的に何が起きたのかをより良く理解することができます。
右側の活動を見る際には、最新のものから表示するか、最も古いものから表示するかを選択できます。私は「出血を止める」という観点から、活動の最後に何が起きたのかを確認するために、最新のものから表示することを好みます。ただし、ストーリーがどのように展開されたのかを見たい人は、古いものから表示することを好む場合もあります。また、この活動が11月27日に始まり28日まで続いていることから、攻撃者が不審な活動を時間的に分散させることで、追跡を逃れようとした可能性があることがわかります。特定のシグナルをクリックすると、その詳細や、さまざまなインジケーター、アクター、エンドポイントなど、何が起きたのか、なぜ不審だと判断されたのかを理解するために必要なすべてのコンテキストを確認することができます。
必要に応じて、不審なアクティビティに関連するS3バケットなどの影響を受けたリソースを確認することもできます。リソースについてより詳しく調べるために、S3コンソールやEC2コンソールに直接アクセスすることも可能です。このアクセスキーは様々な不審なアクティビティに関与していました。全体として、特にGuardDutyをしばらく使用されている方々にはお分かりいただけると思いますが、これは本当にGuardDutyの検出機能の大きな改善です。真のポジティブを素早く特定し、何が起きたのかを正確に理解し、どう対処すべきかを判断する助けとなるよう、大量のコンテキストと精度を追加しました。これにより、個々のGuardDuty検出結果がどのように関連しているのかを理解したり、個々の検出結果に対してアクションを取るべきかを判断したりするために必要な時間が短縮されます。現時点では、Attack Sequencesと通常の個々のGuardDuty検出結果の両方を確認することをお勧めするハイブリッドな状態です。これらのAttack Sequencesのカバレッジを拡大するにつれて、この数ヶ月でそのバランスは変化していくでしょう。
この数ヶ月間、この機能のプライベートベータを実施してきました。この場をお借りして、プライベートプレビューに参加してくださったお客様に感謝申し上げます。フィードバックをいただき、この機能をより良いものにするためにご協力いただき、ありがとうございました。プライベートプレビューは数十社のお客様と数万のAWSアカウントにわたって実施されました。
参加企業の一つがグローバルな企業向けソフトウェア会社のInforでした。Cloud SecurityのVPであるDerek Bush氏は、ベータ後に、この新機能により個々のGuardDuty検出結果の分析に費やす時間が減り、より確実性が高く優先度の高い脅威に集中できるようになったと述べています。また、組織内の不適切なセキュリティ習慣を特定し、それに対して行動を起こすことができたとのことです。また、この機能のテストの一環として、私たちは多数の真のポジティブを検証してきました。非常に効果的に機能しているため、これらのAttack Sequencesに対する通知を設定することを自信を持ってお勧めできます。場合によっては、お客様が不審なアクティビティを発見してAWSに認証情報が侵害された可能性について問い合わせてから数時間後に、侵害された認証情報に関する検出結果を作成したケースもありました。
GuardDutyで行っているもう一つの取り組みは、すべてのAWSアカウントとAmazonのAWSアカウントを保護することです。その一環として、深い脅威検出を提供するだけでなく、さまざまなチームと協力してサービスを改善しています。Prime Video、Twitch、その他のAmazonの子会社を含むAmazon Games, Media and EntertainmentのDirectorであるBrian Lozada氏は、この新機能が多段階の攻撃を可視化し、それらを関連付け、実行可能な形で提供することで、より早期に脅威を軽減できるようになったと述べています。
総じて、私からのお願いは、Attack Sequencesの通知を必ず設定していただきたいということです。GuardDutyを有効にしている場合は、すべてのSequencesを確認してください。それは簡単にできます。フィードバックがありましたら、ぜひお聞かせください。さて、ここはLas Vegasですので、この新機能の背後にある魔法について説明し、どのように実現しているのかを説明するために、同僚のBarisを再び舞台にお招きしたいと思います。ありがとうございました、Shachar。これは、魔法を見て数学の深い部分まで掘り下げたい方にとっては最も楽しい部分になるかもしれませんし、そうでない方にとっては最も退屈な部分になるかもしれません。
GuardDutyの機械学習モデルと検出アルゴリズムの解説
本日は、GuardDutyで使用している機械学習モデルと、これらのモデルの精度を向上させるために採用している手法についてお話しさせていただきます。GuardDutyが持つモデルの一つは、CloudTrail、EKS監査ログ、S3データプレーンログなどのテレメトリーデータを分析し、これらの大量のログデータからセキュリティシグナルを抽出します。 これらのモデルがセキュリティシグナルを抽出するためには、ログソースに現れるエンティティの行動特性を理解する必要があります。これらのエンティティには、ユーザー名、アカウントID、ロール、EC2インスタンス、API名、自律システムなどが含まれます。セキュリティシグナルとは、本質的にセキュリティインシデントを示す可能性のある異常や予期せぬ活動のことで、これらの行動特性の把握と抽出は、GuardDutyでは表現学習と呼ばれる手法によって行われています。表現学習とは、各エンティティの行動特性を捉えた代表ベクトルを見つけ出すことです。これらのベクトルは高次元空間における点として考えることができ、似たような行動をするエンティティは、その空間内で互いに近い位置に配置されます。この表現学習は素晴らしい可視化を提供してくれますが、実際にGuardDutyでどのように役立っているのでしょうか。
Shacharが述べたように、新しい何かを見つけた時にアラートを作成するのは簡単なので、アラートが不足することは問題ではありません。私たちは不審な活動を検出しますが、同時に実際には関心のない活動も多く検出することになります。このような表現学習により、本当に予期せぬ活動と、初めて見る活動ではあるものの、ある程度予測可能な活動とを区別することができます。
例を挙げてみましょう。CloudTrailにおいて、Nikkiがアルゼンチンのある通信会社のISPからStartInstance APIを呼び出しているとします。Nikkiが繰り返しこれを行い、モデルがこの行動を学習したとします。 そしてある日、Nikkiがアルゼンチンの別の通信会社からStopInstance APIを呼び出したとします。これは初めて見る行動で技術的には異常ですが、セキュリティの観点から本当に興味深いものでしょうか？おそらくそうではありません。
モデルは、これらのエンティティの表現を使用してデータのこうした微妙な違いを捉えます。多くのユーザーが同じリソースに対してStartInstanceとStopInstanceを同時に呼び出すことが多いため、StartInstanceは一つの点にマッピングされ、StopInstanceは近い位置にマッピングされることをモデルは理解します。同様に、アルゼンチンのTelecom AとTelecom Bは、地理的に近く、複数のユーザーがこれらのISP間をローミングしているため、似たような表現を持ちます。 したがって、検出モデルがこの活動を初めて見たとき、他のユーザーの類似した活動パターンを考慮すると、新しいものではあるが、それほど驚くべきことではないと認識します。
次のアルゴリズムクラスは、これらの抽出されたセキュリティシグナルを取り、より信頼性の高い検出結果にグループ化します。これらのモデルは、先ほどデモンストレーションされたExtended Threat Detection機能を支えています。 このモデルで起こることは次の通りです：左側に、先ほど説明したモデルによって抽出されたセキュリティシグナルがあり、そしてクラスタリングアルゴリズムがこれらのシグナルをシグナルグループにまとめます。これらのシグナルグループは、時間の経過とともに同じアクターからの活動や、一定期間にわたる同じリソースに対するアクション、あるいはこれらの属性の組み合わせなど、関連するシグナルです。
しかし、すべてのグループが注目に値するわけではありません。中には誤検知もあれば、本当に重要なものもあります。そのため、セキュリティ専門家の注意を要する重要なシグナルグループを優先順位付けするために、ランキング用の機械学習モデルを適用しています。このモデルは、セキュリティ専門家のドメイン知識を取り込み、彼らの期待に沿うように調整しています。 このランキングアルゴリズムは、本質的に、セキュリティ専門家がシグナルグループを分析する際の判断プロセスを模倣することを目指しています。 実際、セキュリティ専門家は、あるシグナルグループが懸念すべきものかどうかを判断する際、特定の質問をしながら証拠を集め、確信度を高めていくというメンタルモデルを持っています。
例えば、 リスクの高いAPI呼び出しの有無や、 この活動に通常とは異なるインスタンスタイプが関与しているかどうかを確認します。また、これらの活動の発信元IPアドレスが、私たちが保有するデータベースによると評判が悪いか、あるいはVPNや その他の匿名ネットワークに関連付けられているかどうかをチェックします。さらに、使用されているユーザーエージェントが、 既知の不審なユーザーエージェントの一つかどうかも確認します。このような小さな質問を通じて、セキュリティ専門家は、これが本当に注目すべき事象であるという確信を徐々に築いていきます。
私たちの目標は、このプロセスをスケールアップすることです。なぜなら、膨大な数のシーケンスすべてに対して手作業で行うことは不可能だからです。では、この手作業のプロセスをどのようにスケールアップすればよいのでしょうか？セキュリティ専門家に一つ一つ確認してもらう代わりに、これらの質問を書き出してもらい、小さな関数やルールとしてエンコードしてもらいます。私たちはこれらを Markerと呼んでおり、数十個のMarkerを収集してライブラリにしています。 セキュリティシグナルグループが発生するたびに、これらのMarkerを適用して回答を得ます。一部のMarkerは反応し、一部は反応しないことで、一連のYes/No回答が得られます。そして、機械学習モデルがこれらの結果を集約し、ランキングスコアを提供します。
このランキングスコアモデルは、いくつかの 重要な機能を持っています。まず、データからMarkerの集約方法を学習します。 お互いに矛盾する傾向にあるMarkerの寄与度を低く評価します。これらのMarkerは異なるセキュリティ専門家によって異なるコンテキストのために設計されているため、常に一致するわけではありません。そのため、モデルは、もし特定のMarkerが互いに矛盾する傾向にある場合、そのコンテキストではそれらのMarkerをあまり信頼すべきではないと学習します。 また、互いに一致する傾向にあるMarkerを高く評価します。あるMarkerが反応し、別のMarkerも繰り返し反応する場合、そこには私たちがより強く活用すべき有用な情報があります。
モデルはまた、 常に反応しているMarkerの寄与度を低く評価します。常に反応しているMarkerは実質的にシグナルを提供していないため、その寄与度を徐々に下げていきます。最後に、既知の事例と一致する傾向にあるMarkerの寄与度を高く評価します。これらのMarkerが、以前に検出した既知の悪意のある事例や、私たちのテストサンプルを通じて確認された事例と一致する場合、それらのMarkerは高く評価され、この集約関数における寄与度が上がります。これらの集約関数によって提供されるランキングスコアに基づいて、すべてのシグナルグループが順位付けされ、その順位に従ってお客様に提示されます。
これらが Amazon GuardDuty で採用している手法とモデルの一部です。冒頭で Matt が私がすべての分析について説明すると言いましたが、この限られた時間ですべてをカバーすることはできません。より詳しく知りたい方は、本日午後に予定されているワークショップセッションにぜひご参加ください。 また、来年の re:Inforce でもより多くのセッションとコンテンツを用意する予定ですので、そちらでもお会いできることを楽しみにしています。まだ GuardDuty を使い始めていない方のために、こちらに始めるためのリソースをご用意しました。 以上で私からの説明を終わらせていただきます。お時間をいただき、ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion