re:Invent 2024: AWSのセキュリティサービス最新機能と改善点
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Innovations in AWS detection and response (SEC321)
この動画では、AWSの検知および対応サービスのポートフォリオについて、最新の機能と改善点が詳しく解説されています。Amazon GuardDutyによる脅威検知、Amazon Inspectorによる脆弱性管理、AWS Security Hubによる集中監視など、主要なセキュリティサービスの特徴と連携について説明されています。特に注目すべき点として、生成AIと機械学習を活用した新機能Extended Threat Detectionの導入や、Amazon Security Lakeによるログの一元管理、AWS Security Incident Responseによる24時間365日の専門家サポートなど、最新のセキュリティ対策の詳細が紹介されています。また、Open Cybersecurity Schema Framework（OCSF）の採用により、異なるソースからのセキュリティデータを標準化して管理できる利点についても言及されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWS re:Inventにおける検知および対応サービスの紹介
皆様、おはようございます。re:Invent 2024へようこそ。皆様、楽しんでいらっしゃることと思います。re:Inventの学習体験にふさわしく、このセッションでは、私たちの検知および対応サービスにおいて導入してきた革新的な機能についてご紹介させていただきます。
AWSは、様々なユースケースやドメインにわたって、多岐にわたるネイティブのAWSセキュリティサービスを提供しています。このセッションSEC321では、検知および対応サービスのポートフォリオに関する主要な機能と改善点に焦点を当てています。私はAWSのIdentityおよびセキュリティスペシャリストチームを率いるHimanshu Vermaです。そして、Amazon GuardDutyチームを率いるRyan Hollandも同席しています。本日の議題はシンプルです：検知および対応サービスの概要をご説明し、前回のイベントでこれらのサービスについて議論して以来、新たに導入した機能についてご紹介します。また、できるだけ体験的に理解していただけるよう、いくつかのデモもご用意しています。
AWSの検知および対応サービスの概要と脅威検知の取り組み
私たちの検知および対応サービスは、お客様のビジネス成果に関する重要な課題の解決を支援します。まず第一に、AWSワークロードの保護です。これらのサービスの主な目的は、AWSアカウント、ワークロード、セキュリティリスクを効果的に保護・測定し、適切なアクションを取ることです。また、お客様からは、これらの検知サービスを使用してAWS環境全体の可視性を確保するため、脆弱性とリスクの監視を一元化する機能が求められています。さらに、セキュリティ運用チームやセキュリティ担当者が、ワークフローを調整し、生成AIや機械学習を活用してセキュリティイノベーションを実現するために必要なデータを簡単に集約できることも重要です。
私たちの検知および対応サービスのポートフォリオは、3つの主要なサブカテゴリーに分類されています。1つ目は脅威検知とワークロード保護で、Amazon GuardDutyが主要サービスとして、お客様が脅威、異常、不審な活動を特定するのを支援します。2つ目のカテゴリーは脆弱性管理で、オープンソースの脆弱性やソフトウェア・OSの脆弱性だけでなく、潜在的なリスクや設定ミスも分類します。Security HubやInspectorといったサービスは、コードの作成時やコンテナ・インスタンスの起動時における、セキュリティチームと開発者の両方のエクスペリエンス向上に向けて革新を続けています。3つ目のカテゴリーは調査と対応で、お客様がセキュリティ問題をより深く掘り下げ、豊富な洞察を得るためのクエリを効果的に実行できるよう、必要なすべてのデータを調整することに重点を置いています。
サービスの詳細に入る前に、AWSがグローバルインターネットをより安全な場所にするためにどのように取り組んでいるかについてお話ししたいと思います。私たちの広範なインフラストラクチャーとスケールにより、グローバルな脅威の状況を検知し、洞察を得ることが可能になっています。本日ご紹介するサービスの一部は、このインフラストラクチャーによって支えられており、比類のない洞察とテレメトリーを収集し、それらの豊富な洞察を活用して、機械学習、ニューラルネットワーク、ヒューリスティックをサービス内で適用しています。
AWSのグローバルインフラストラクチャーを活用した脅威インテリジェンス
「全てのクラウドが同じように作られているわけではない」というフレーズを私たちはよく耳にしますが、クラウドのセキュリティに関しても、私たちはこれらの投資に情熱を注いでいます。グローバルインフラストラクチャに対する最初の重要な投資の一つは、Threat Intelligenceに関するものでした。私たちは、インターネットからAmazon全体に向けられる大量の悪意のあるトラフィックを観察しながら、ドメインのNeural Graph Networkの構築に努めており、そこにMachine LearningとArtificial Intelligenceを適用しています。
私たちは、観察対象のドメインが実際に悪意のあるものか有害なものかを確認しています。その情報を私たちのサービスにフィードバックすることができます。これには1日に数兆件のDNSリクエストの検査が必要で、多数の悪意のあるドメインを発見し、それらの情報をAmazon GuardDutyなどの脅威検出サービスにフィードバックしています。
インターネット全体に広がるセンサーインフラストラクチャを展開しており、これらのセンサーは大量のデータを収集し、悪意のある攻撃者の情報送信のデコイとして機能します。AWSでリソースを起動してから約90秒以内に、そのリソースへのプローブやヒットが確認され始めるケースを観察しています。これらのセンサーは悪意のある攻撃者を引き付け、収集した情報をAmazon GuardDuty、Amazon Inspector、AWS WAFなどのサービスにフィードバックすることを可能にしています。
また、私たちは自動化された脅威の阻止にも注力しています。Threat Intelligenceを収集し、悪意のあるドメインやIPアドレスの誤検知を排除するためのNeural Network Graph Modelを作成する中で、お客様のワークロードをBotnet、暗号通貨マイニング、Crypto Jackingから自動的に保護しています。Amazon S3、Amazon VPC、そして私たちのネイティブなセキュリティサービスは、AWS全体のインフラストラクチャに投資された同じ技術を活用しています。これは全て、グローバルなインターネット全体を、全てのお客様にとってより安全な場所にするための取り組みです。
Amazon GuardDutyとAmazon Inspectorの機能と最新の改善点
検知と対応のポートフォリオにおける具体的なサービスを見ると、6つの主要なサービスがあります。まず何よりも、これらのサービスは全てAWSアカウントにネイティブに統合されており、アカウントやワークロードの保護に関して運用化やオーケストレーションを必要としません。これらは検知ツールであるため、テレメトリーが必要で、お客様がログを有効にする必要があるという誤解がよくありますが、これらのツールはログの有効化やAPIの運用化を一切必要としません。お客様はアカウントレベルでこれらを有効にするだけで、自動的に保護を開始し、検出結果を提供し、インサイトを提供し始めます。
Amazon GuardDutyは、VPC Flow Logs、AWS CloudTrailからのAPI活動、そして現在ではランタイム保護を使用したホスト活動の監視に焦点を当てた、私たちの主要サービスの1つです。脅威インテリジェンスを通じて検知された悪意のあるIPアドレスやURL、あるいは異常や不審な活動を検出した際に、調査結果を提供します。Amazon Macieは、機密データに関連する機密性とリスクについて、豊富な洞察を顧客に提供することに重点を置いた主要サービスです。Amazon S3とそのオブジェクトにネイティブに統合されており、顧客が機密データの所在と、アカウントおよび組織レベルでの現在のリスクを理解するのに役立ちます。
Amazon Inspectorは、脆弱性管理に焦点を当てたサービスです。スキャン可能なAWSワークロードの種類を拡大し、大規模な脆弱性データベースの情報を取り込んで、顧客に調査結果の洞察を提供します。これらのサービスはすべて、Amazon EventBridgeで利用可能なJSON形式の調査結果を提供します。そこから、顧客はこれらの調査結果をSIEMツールやSOARツールなどの集中型セキュリティオペレーションツールにストリーミングすることができます。私たちは、これらの調査結果をすべて、集中監視ツールであるAWS Security Hubに集約しています。これにより、顧客はAWSネイティブのセキュリティサービスだけでなく、パートナーツールからの調査結果も1か所で集約することができます。
より重要なのは、Security Hubがクラウドセキュリティポスチャ管理を実行することです。これは、AWSアカウントとワークロードのコントロールを、AWS内部で構築したAWS Foundational Security Best Practicesや、NISTやCISベンチマークなどの外部基準に照らして継続的に評価することを意味します。これらの設定ミスやセキュリティベストプラクティスからの逸脱は、Security Hubで調査結果として報告され、自動化された対応アクションと修正を実行するための一元的な場所を提供します。
Amazon Detectiveは、Security Hubのすべての調査結果の相関関係を理解するためのグラフデータベースを構築することに焦点を当てたサービスです。インスタンスとその異なる攻撃ベクトルなど、エンティティやノードについて知りたい場合、Detectiveを使用すれば、ログを有効化したり解析したりする必要なく、視覚的にもAPIコールを通じても、そのグラフデータベースを探索することができます。この数年で、私たちはAmazon Security Lakeをリリースし、これは顧客が様々なログを管理するのに役立ちます。セキュリティチームが詳細な分析のためにログを整理し、セキュリティエンジニアリングや分析目的のためにクエリを実行する必要があることを認識しています。Security Lakeは、ログの複数のコピーを作成したり、パートナーツールでログへのアクセスを失うことなく、すべてのデータを簡単に整理して一元化することを支援します。また、それらのログの上に独自のGenerative AI機能を構築するなど、将来の技術へのアクセスとイノベーションを可能にします。
これらのサービスについて説明する中で、それぞれの詳細と、私たちが提供している新機能について詳しく見ていきます。ネイティブに統合されていることに加えて、これらのサービスが提供する重要な価値提案の1つは、AWS Organizationsとの統合です。この統合により、サービスを大規模に展開してプロセスを自動化することができます。各サービスはAWS Organizationsと統合されており、セキュリティチームが集中管理アカウントを指定できるようになっています。これにより、セキュリティアカウントでそれらのサービスからの調査結果を簡単に集約し、自動的に有効化されたサービスで組織に参加する新しいメンバーアカウントを管理することができます。また、集中委任管理アカウントから、メンバーアカウントの簡単なオンボーディングとオフボーディングが可能です。
この機能がどのように動作するのか、実際にお見せしましょう。こちらがGuardDutyのコンソールです。Detection and Responseドメインの各サービスには、中央管理アカウントが管理者アカウントを委任できるこのアカウントタブがあります。これを設定すると、各メンバーアカウントにはこのようなオプションが表示されます。GuardDutyの保護プランをスケールできる、非常に簡単なワンクリックオプションを用意しました。現在のアカウントに対して簡単に有効化でき、新しいアカウントをオンボードする際にも、セキュリティチームが容易に有効化できることが保証されています。新規アカウントに対して自動的に有効化するか、特定のアカウントを選択して有効化するかを選べます。
これらのワンクリックオプションは、個別の機能やGuardDutyのような各サービスの全体的な機能に対して利用可能です。すべてのサービスには無料トライアル期間が付いているので、お客様に試していただけます。また、お客様に好評なもう一つの機能として、ユーザータブがあり、そのサービスを使用した場合の潜在的なコストへの影響を確認できます。この洞察は無料トライアル期間中でも得ることができます。それでは、このセッションの脅威検出とワークロード保護の部分について、Ryanに引き継ぎたいと思います。
Amazon GuardDutyの進化：データソースの拡大と新機能の紹介
Zachoが言及した脅威検出とワークロード保護のコンポーネントは、脅威保護を提供する当社のサービスであるAmazon GuardDutyです。非常に大まかに言うと、GuardDutyは複数の検出技術を使用して、アカウント内の認証情報やワークロードの潜在的な侵害を特定する脅威検出サービスです。アカウント自体だけでなく、実行中のワークロードも監視して、Bitcoinマイニングやコマンド＆コントロールサーバーへの接続、その他のワークロード侵害の兆候など、不審なアクティビティを特定します。また、CloudTrailなどのコントロールプレーンで発生する不審なアクティビティも監視します。
この仕組みをもう少し詳しく説明し、このサービスが長年にわたってどのようにスケールしてきたかをお話ししましょう。2017年のre:Inventでこのサービスを立ち上げた時、上部に示されている基本的なデータソースがありました。GuardDutyは主にログデータに基づいて動作しますが、Assaniが言及したように、私たちの重要な利点の1つは、これらのログソースを設定したり有効にしたりする必要がないことです。GuardDutyを有効にすると、すぐに内部バックエンドソースからこのログデータを取得します。これは管理オーバーヘッドの観点から優れているだけでなく、セキュリティ上の意味も持ちます。誰かがアカウントに足がかりを得ても、このデータへのアクセスを妨害できないからです。また、何かを有効にし忘れることもありません。
基本的なデータソースは、すべてのお客様に対してデフォルトで有効になっています。これらはVPC Flow Logs、DNSクエリログ、AWS CloudTrailです。これにより、アカウント内のインスタンスのネットワークアクティビティとAPIコントロールプレーン上のアクティビティの両方を広く可視化できます。長年にわたり、これを拡張し、AWSサービスの他の部分に対する保護を提供する追加のオプション保護プランを追加してきました。どの保護プランがソースを提供しているかに関係なく、これらのログを受け取った最初のステップは、複数の異なる分析エンジンを通して処理することです。これらを単純なルールベースで処理するだけでなく、高度な機械学習モデルを使用して、これらの異なるデータソース間の異常を検出します。
CloudTrailでは、ユーザーが通常とは異なる場所からログインしたり、そのユーザーや他のアカウントユーザーにとって異常なアクティビティを実行したりするような、普段とは違う活動を監視しています。これらのモデルで私たちが特に重視しているのは、不審で悪意のある可能性が高い活動を特定することです。すべての異常が悪意のあるものとは限りませんが、より脅威となる可能性が高いものを特定できるようにモデルの調整を行っています。新しいモデルでは、通常期待される動作と、検出された動作が異なると判断した理由についての情報も含まれるため、初動対応者やヘルプデスクの担当者が何が異常で、なぜフラグが立てられたのかを理解しやすくなっています。
また、脅威インテリジェンスも活用しています。Amanshiが言及していた私たちの自社の脅威インテリジェンス、つまり悪意のある新しいドメインについて実用的な情報を提供するDNSグラフデータベースを持っています。日々特定している10万以上のドメインの多くは比較的新しく、一般的なサードパーティの脅威リストには含まれていないものです。さらに、CrowdStrikeやProofpointと提携して、サードパーティの脅威インテリジェンスも取り入れています。必要に応じて、お客様独自の脅威インテリジェンスを持ち込むこともできます。
これらの検出エンジンの出力はセキュリティ調査結果として提供され、より実用的なものとなるよう、できるだけ多くのメタデータやコンテキストを付加するようにしています。これらの結果は私たちのコンソールで確認できますが、多くの場合、お客様はAmazon EventBridgeを使用して、下流の自動化、チケット発行、対応アクションをトリガーします。AWS Security HubやAmazon Detectiveで更なる調査を行うことができ、また多くのAmazon Partner Networkツールが、GuardDutyの調査結果を収集し、お客様の対応をサポートしています。
この数年で追加したもう一つの対応オプションが、Malware Protectionです。Malware Protectionでは、マルウェアが存在する可能性が高いと特定された一連の調査結果があります。Amazon EC2インスタンスでそのような調査結果が発生し、Malware Protectionを有効にしている場合、ボリュームのスナップショットを作成し、オフラインでマルウェアスキャンを実行して、検出されたマルウェアを報告します。
これにより、コマンド＆コントロールサーバーやBitcoinサーバーとの通信など、インスタンス上のネットワークアクティビティの関連性を把握することができます。インスタンスでネットワークアクティビティを確認し、コマンド＆コントロールサーバーやBitcoinサーバーとの通信の可能性が見つかった場合、マルウェアスキャンを実行すると、マルウェアのファイルパス、ハッシュ、名前、および存在場所が分かり、対応時間を短縮することができます。
これまでに追加してきた追加のワークロード保護機能について、簡単にご紹介したいと思います。最初に追加したのは、GuardDutyにデータプレーンイベントの可視性を提供するAmazon S3保護機能です。AWS CloudTrailの管理イベントでは、S3の管理イベントを確認できましたが、こちらはget、list、putオブジェクトなどのデータプレーンイベントを対象としています。S3バケットで個別に有効化する必要はありません。この機能を有効にすると、アカウント内のすべてのS3データイベントの可視性が得られ、異常なアクティビティの監視が開始されます。通常は書き込みのみを行うプリンシパルが突然大量のデータを読み取り始めたり、アクセス元の場所や、普段アクセスしない多数のバケットへの突然のアクセスなど、異常な活動を検出します。
また、Amazon EKS保護機能も追加しました。EKS保護機能は、CloudTrailと非常によく似ています。Kubernetesには Kubernetesコントローラーがあり、EKSではEKSコントロールプレーンへのアクセスに関する監査ログを生成します。機械学習モデルを使用して、特権コンテナの作成や、認証情報が侵害されてKubernetesワークフローに影響を与える可能性のある異常なロールバインディングなどの異常なアクティビティを検出します。
すでにAmazon EC2向けのマルウェア保護についてお話ししましたが、今年のAWS re:Inforceで、これをAmazon S3にも拡張しました。S3向けのマルウェア保護では、特定のバケットに対してこの機能を有効にできます。有効にすると、そのバケットにオブジェクトが書き込まれるたびに自動的に通知を受け取り、マルウェアスキャンを実行し、検出された場合にはFindingを送信します。また、Amazon CloudWatchにも送信されます。よく使用される機能の1つとして、オブジェクトにタグを付けることもできます。これにより、Webポータルを通じて顧客からデータを収集したり、サードパーティがデータをアップロードしたりする際のデータ取り込みパイプラインを構築できます。データがバケットに到着すると、GuardDutyによってスキャンされ、そのスキャン結果がタグとして適用されます。データ取り込みワークフローは、このタグが存在するのを待ち、脅威が検出されなかったオブジェクトのみを受け入れることができます。
Amazon RDS保護機能は、RDSデータベースへの異常なログインを検出し、通常とは異なる場所からのログインや、普段アクセスしないデータベースへのログインなど、RDSデータベースへの実際の接続を監視します。また、RDSログインを強制しようとするブルートフォース攻撃の検出も行っています。AWS Lambda保護機能は、フローログの検出をLambda関数にも拡張し、VPCネットワークおよび標準ネットワークで実行されるLambda関数に対応しています。もしLambda関数が侵害されたライブラリによって突然EC2やクリプトサーバーにアクセスを始めた場合でも、それを検出することができます。
最近の拡張機能の1つが、ランタイムモニタリングです。ゲストオペレーティングシステム内で発生するアクティビティをより深く可視化し、従来のログソースよりも多くのテレメトリを提供するため、ランタイムモニタリングを導入しました。これは、GuardDutyの1クリック有効化を維持しながら実現したいと考えていました。eBPFベースの非常に軽量なエージェントを開発し、このエージェント自体はテレメトリコレクターとして機能します。ランタイム保護を有効にすると、EKS Managed Add-onsを使用してアカウント内のEKSノードに自動的にエージェントがデプロイされます。AWS Fargateの場合は、Fargate側から直接注入されるため、タスク定義を変更する必要はありません。必要なVPCエンドポイントを作成し、これらのエージェントはテレメトリをバックエンドにストリーミングし、そこで検出のためのすべてのコンテンツとロジックが適用されます。
これにより、イベントのストリームに対して検知を行い、個々のコマンドだけでなく、それ自体は無害でも、オペレーターからの将来のコマンドとの文脈で見たときに不審となる可能性のあるコマンドを特定することができます。また、Runtime保護のための新しい検知機能も継続的に追加しています。
12月1日に発表された最新機能は、Extended Threat Detectionと呼ばれるものです。この機能は、短時間での単一またはバッチ処理されたイベントの検査から、データソース全体にわたる検出結果のグループと、それ自体では検出結果を生成しないものの、重要なコンテキストを提供する追加シグナルの検査へと検知範囲を拡張します。目的は単一の検出結果を特定することではなく、データソース全体にわたる検出結果のグループと、それ自体では検出結果を生成しないものの、重要なコンテキストを提供する追加シグナルを検査することです。認証情報が侵害された場合、1つや2つの個別のイベントだけでなく、MITRE ATT&CKパターンに従う一連のイベントが発生するのが一般的です。そのため、私たちはこれらの多くをMITRE ATT&CKにマッピングしています。これらのイベントを時系列で検査することで、個々の不審なイベントというだけでなく、新しいタイプの検出結果として警告すべき、認証情報侵害の可能性が高いことを示すのに十分な確信を得ることができます。
Amazon InspectorとAWS Security Hubの機能強化と新たな取り組み
この機能の最初の利点は、デフォルトで有効になっていることです。すでにAmazon GuardDutyをご利用の場合、追加費用なしでこの機能が自動的に有効になっています。有効化や設定は必要ありません。 ここで提供するセキュリティ価値は、既存の検出結果を確認するだけにとどまりません。私たちが開発した機械学習モデルに、追加のマーカーやコンテキストを組み込むことで、利用可能なすべてのコンテキストに基づいて認証情報が侵害された可能性を予測できます。その認証情報に関する特定の検出結果を確認するだけでなく、ネットワークマーカーも検査します。例えば、脅威アクターの活動に関連するVPNプロバイダーからトラフィックが発生しているかどうかを、私たちの脅威インテリジェンスに基づいて確認します。一部のVPNプロバイダーはログを保存せず、暗号通貨での支払いを受け入れ、脅威アクターに好まれています。
これらの検出結果は、オペレーターが理解し対応しやすいように改良したコンソールを通じて提供されます。他の方法で検出結果を取得している場合は、新しいタイプの検出結果として表示されます。GuardDutyの立ち上げ時に、私たちは低から高までの重要度レベルを設定し、1から8までの数値でマッピングしました。9と10は、Criticalと呼ぶに値する検出のために確保していました。これらの新しい検出結果は重要度9で、Criticalタグが付けられています。
これらの検出には、主要なアクティビティのタイプによって区別される2つの検出タイプがあります。前述のように、侵害された認証情報は、新しいユーザーやアクセスキーを作成して永続性を確立するなど、脅威アクターが通常悪用する高リスクなAPI呼び出しにつながることがよくあります。S3データ保護が有効になっている場合、S3データプレーンのイベントも相関分析して、ランサムウェアやデータ流出を検知します。どちらのアクティビティがより顕著かに応じて、認証情報侵害またはデータ侵害として分類されます。
これからコンソールでご紹介する検出結果には、豊富なコンテキスト情報が含まれており、MITRE ATT&CKのTacticsとTechniquesにマッピングされています。上部には人間が読みやすい自然言語による要約があり、インシデントレスポンダーは何が起きたのか、いつ発生したのか、何が関係しているのか、なぜ注意が必要なのか、そして攻撃に関与したすべてのリソースについて明確に理解することができます。
これがGuardDutyの新しく改善された概要ページです。この検出結果ボックスには「Top Threats」という新機能が追加され、組織全体での優先度の高い脅威が表示されます。 Attack Sequencesオプションをクリックすると、適切なフィルターが適用された標準の検出結果ページが表示され、これらの攻撃シーケンスのみを表示することができます。ご覧のように、8つの異なるリソースに関連する認証情報の侵害検出があります。 こちらの別の検出結果には、2つの異なるリソースと複数のシグナルが関連付けられています。詳細を表示をクリックすると、情報が展開されます。
左上には、人間が読みやすい自然言語による説明が表示されます。確認された指標の数、関連するリソースの数、さらにMITRE ATT&CKのTacticsと様々なTechniquesが表示され、視覚的なマッピングも提供されます。このマッピングをクリックすると、そのMITRE TechniqueとTacticに関連する様々な検出結果を確認することができます。
確認された様々な指標を見ることができます。この例では、高リスクのAPI、様々なTactics、不審なUser Agent、関与したアクターとエンドポイントなど、4つの異なる指標があります。また、攻撃が開始されたと思われる時期を視覚的に表現したタイムラインも表示されています。この攻撃シーケンスが継続し、例えば権限昇格などのさらなる活動が確認された場合、既存の検出結果が更新され、タイムライン上に後続のアクションが表示されます。
また、関連するリソースも確認することができます。 この例では、Instance Roleを使用して攻撃シーケンスを生成したため、2つのリソースが関連しています。InstanceとそのRoleに関連するAccess Keyが含まれています。 S3に関する検出結果を見てみると、ある程度似ていますが、 この場合、モデルが特に注目したのは、他の異常な活動に関連する多数のS3の機密APIが含まれていたという点です。ここでも人間が読みやすい説明と、事象の開始から終了までを示す分かりやすいタイムラインが提供され、さらにリソースとして、悪意のある活動が確認されたS3 Bucket、検出結果を生成したInstanceとRole、Access Key、そして他のBucketなどが含まれています。
Ryanが説明したように、デモンストレーションでご覧いただいた情報の多くは、すべてJSONイベントで利用可能です。多くのお客様は、AWSの検出ツールだけでなく、他のクラウドプロバイダーからの調査結果も取り込むツールを活用しています。これらの調査結果は、集約している全てのシグナルを強化するために実際に使用することができます。先ほど触れた2番目の柱は、脆弱性管理です。この分野における主要サービスは、GuardDutyと共にAmazon Inspectorです。GuardDutyは機械学習を活用し、脅威や不審・異常なアクティビティに関する豊富な洞察をお客様に提供していることをご覧いただきました。
Amazon Inspectorは、まず第一に、お客様のSoftware Bill of Material（ソフトウェア部品表）の可視化に重点を置いています。つまり、アカウント内のすべてのインスタンス、コンテナイメージ、Lambda関数などの場所を把握し、その部品表のスナップショットを保持した上で、これらのワークロードの脆弱性スキャンを可能にします。また、私たちはAmazon Inspectorを、開発者が最初から安全なコードを書けるようにサポートするシフトレフトの考え方に合わせることも重視しています。コード作成を支援する生成AIツールであるAmazon Q Developerも、コード作成時に脆弱性管理を行うためのAPIを使用します。また、開発者が脆弱性の可能性があるオープンソースライブラリを呼び出している場合、それを置き換えて脆弱性を修正するための推奨コードを提案することもできます。
Inspectorも同様にワンクリック有効化に焦点を当てていますが、この数ヶ月間で、Inspectorの機能を継続的に拡張してきました。まず第一に、先ほど申し上げた通り、部品表が利用可能です。Inspectorを組織レベルで有効にすると、サポートされているすべてのリソースのスナップショットを素早く取り込みます。また時間の経過とともに、以前のバージョンからInspectorを強化してきました。実際、InspectorはGuardDutyよりも前に立ち上げた、最も初期のネイティブセキュリティサービスの1つでした。しかし、サービス立ち上げ時には、EC2をスキャンするために独自のエージェントが必要でした。
しかし、私たちはその摩擦を取り除き、機能を拡張しました。新しいバージョンのAmazon Inspectorでは、EC2のエージェントレススキャンをサポートしています。お客様はコンテナワークロード、特にECRコンテナレジストリのスキャンが可能で、これらのコンテナイメージの継続的なスキャンまたはプッシュ時のみのスキャンを選択できます。オペレーティングシステムレベルのスキャンだけでなく、スクリプト言語の脆弱性を特定するための言語ベースのスキャンも実行できます。また、CISベンチマークを活用して調査結果で報告された脆弱性を比較するオンデマンドCISスキャンも導入しました。時間の経過とともに、お客様からコードをリポジトリにプッシュする際の事前スキャンの要望があり、開発者が簡単にコードリポジトリへのプッシュ時に脆弱性をスキャンできるCI/CDイメージスキャンプラグインを提供しました。
私たちが行った主要な機能強化の1つは、生成AIを活用してセキュリティサービスの自動化と運用を行うことです。Amazon InspectorのLambdaコードスキャンを強化し、調査結果が報告される際に脆弱性を含むコード行を特定するだけでなく、簡単な修復に使用できる生成AI駆動のコード行を提供することで、潜在的な修復方法を推奨できるようになりました。セキュリティチームがその調査結果をチケットワークフローやアプリケーションチームに送信する際、開発チーム向けに推奨コード行を含めることができます。
先ほど述べたように、Amazon Inspectorには、組織レベルで有効化できるアカウントや使用状況の管理といった標準機能が含まれています。Inspectorを有効にすると、数分以内にすべてのインベントリが取り込まれます。お客様に特に評価いただいている主要な機能の1つが、組織内でこのサービスを有効にしているアカウントの数と、Inspectorの脆弱性管理の対象となっているインスタンス、コンテナイメージ、Lambda関数のカバレッジを示す環境カバレッジグラフです。また、最も脆弱性の多いパッケージを表示する、リスクベースの修復ビューも提供しており、特定のイメージやコンテナリポジトリに対するアクションの優先順位付けをサポートします。このビューでは、重大な発見事項が最も多いアカウントも強調表示され、迅速なアクション実施を可能にします。
Inspectorは、約40の異なるリソースからシグナルを収集して維持管理しているCVEやNVDデータベースによってマッチングされた脆弱性だけでなく、さらに多くの情報を提供します。お客様にとって特に有用な発見事項の種類の1つが、ネットワーク到達可能性です。パッケージやコードの脆弱性ではなく、ネットワーク到達可能性の発見事項を確認する際には、ネットワークから到達可能な影響を受けるリソースが表示されます。また、修復可能なネットワークパス情報も提供されます。これは脆弱性の重大度と組み合わせて活用され、Inspector発見事項のスコアを引き上げ、優先度の高い項目へのアクション実施に向けたより豊富な洞察を提供します。
Software Bill of MaterialsをCycloneDXやSPDXなどの一般的な形式でエクスポートし、これらのエクスポートをS3バケットに自動化して時系列のスナップショットを作成することができます。これにより、どのアプリケーションやビジネスチームが、いつ、どのリソースを起動したかを比較でき、リソースタグを使用することで、そのソフトウェア部品表の中でどこに最も多くの脆弱性が見つかっているかを特定できます。
Amazon DetectiveとAmazon Security Lakeによる調査と対応の強化
もう1つ強調したいのが、集中監視とクラウドポスチャー評価サービスであるAWS Security Hubです。Amazon GuardDutyとAmazon Inspectorからのすべての発見事項は、自動的にSecurity Hubに送られます。しかし、Security HubはAWSアカウントとワークロードのコントロールの評価にも重点を置いています。AWSアカウントが増え、アプリケーションチームやビジネスチームが新しいワークロードを立ち上げるにつれて、Security Hubは自動的にこれらのコントロールを評価し、セキュリティのベストプラクティスと照合します。
先ほど述べたように、これらのコントロールのカテゴリーである組み込みの標準があり、セキュリティチームにそれぞれの標準に対するリスクスコアを簡単に要約したビューを提供します。AWS Foundational Security Best Practicesは内部標準で、200以上（そして増加中）のこれらのコントロールをグループ化したもので、潜在的な設定ミスが見られる箇所に沿って、設定ミスや発見事項をお客様に提供します。また、NIST、PCI DSS、CISベンチマークなどの外部標準も追加しており、これらの重要なコントロールも含まれています。これらの発見事項の統合により、お客様は対応と修復のアクションを自動化することができます。
当社のソリューションライブラリで最も人気のあるAWSソリューションの1つは、Security Hub自動応答Runbookです。これを使用することで、お客様は独自のカスタムCloudWatchアクションを簡単にアップロードして作成し、複数の異なる対応アクションを実行することができます。Security Hubは、検出結果の取り込みだけでなく、下流のアクションとも連携します。多くのセキュリティチームが、JiraやServiceNowなどのチケットツールやSlackチケットとの自動化ワークフローを簡素化したいと考えていることを認識しており、これらの統合機能はすべてSecurity Hubにネイティブで搭載されており、ワークフローの自動化とダウンストリームアクションの効率化を実現しています。
お客様からSecurity Hubの一元的な設定などの機能についてリクエストをいただき、この最近発表された機能は現在、組織レベルですぐに利用できるようになっています。Security HubはAWS Organizationsとの統合により、マルチアカウント管理が可能なサービスです。お客様が必要としていたのは、すべてのアカウントまたはアカウントグループに設定を適用し、リスクポスチャーやポリシーを維持できる一元的な設定場所でした。アカウントタブでは、開発者アカウントやビジネスチームなど、リスクやポスチャー評価に異なる要件を持つアカウントグループに対して、セキュリティポリシーを作成・適用することで、Security Hubの設定と管理を簡単に効率化できます。
Security Hubで発表された重要な新機能の1つは、コントロールパラメータを設定する機能です。これは、Security Hubのコントロールに対するお客様定義の入力値です。先ほど申し上げたように、Security Hubには組み込みのコントロールがあり、Amazon Bedrockなどの新しいワークロードの立ち上げに伴って、さらに多くのコントロールを追加し続けています。アプリケーションチームがBedrockから生成AIや基盤モデルを活用したいが、そのセキュリティポスチャーコントロールの可視性も確保したい場合、これらは私たちが自動的に追加・強化し続ける新しいコントロールの一例です。
お客様は多くの場合、環境やAWSワークロードの構成方法に基づいて、これらのコントロールをカスタマイズする必要があります。時にはコントロールで使用されているポートもカスタマイズが必要かもしれません。たとえばポート22ではなく、ポート47や67を使用している場合があります。現在はSecurity Hubでコントロールごとにこれらの条件を編集し、すべてのアカウントに展開することができます。これも、Security Hubで新たに利用可能になった機能です。3番目のカテゴリーである調査と対応に移りますが、私たちがセキュリティサービスにおいて機械学習をどのように活用しているか、そしてネイティブのセキュリティサービスで生成AIをどのように使い始めているかについてお話ししました。
しかし、私たちは一部のサービスで、お客様が生成AIを活用できるようにすることも重視しています。調査と対応における最初のサービスの1つがAmazon Detectiveです。Amazon Detectiveは有効化されると、AWS Security Hubからの生ログやテレメトリーデータの収集を自動的に開始し、約1年間保持して、自動的にグラフデータベースを作成します。グラフデータベースは、基本的にインスタンスやワークロードなどのリソース間の異なる共通エンティティやタッチポイントの相関関係を示すものです。
Amazon GuardDutyがインスタンスで潜在的な脅威を検知した場合、あるいは不正なIPアドレスやCrypto and Command型の活動が攻撃経路で確認された場合、その脅威がどこから発生したのか、またAWS環境でどれくらいの期間存在していたのかを知りたいと思うでしょう。Amazon Detectiveは機械学習を活用して、アカウントのネットワークアクティビティとAPIアクティビティのベースラインを作成します。そして、それらのAPIやネットワークアクティビティの使用における異常に関する情報を提供します。このベースラインを基準として比較することで、そのベースラインからの異常につながったすべてのアクション、さらにはAPI操作のレベルまで簡単にたどることができます。
豊富な情報を取り込んでいることから、お客様が攻撃経路や視覚的なグラフデータベースを簡単に確認できるようにビジュアルビューを提供することにしました。このビューでは、セキュリティエンジニアやセキュリティオペレーションの担当者がクエリを手動で実行する場合には非常に困難なIAMロールやAssumed Roleを簡単に追跡することができます。また、Amazon S3のデータプレーンイベントに関するすべてのPutやGetも確認できます。ここでグラフの可視化が役立ちます。Detectiveで実装した生成AIを使用した主要な機能強化の1つは、このビジュアルグラフを提供するだけでなく、リソースやエンティティに関連する複数の検出結果をグループ化する際に、注目すべき重要なポイントの要約を提供することです。この検出グループの要約は、現在Detectiveにネイティブに実装された生成AIによって提供されており、セキュリティチームが対処や優先順位付けを行う必要があるリソースと脅威のベクトルを、人間が読みやすい言語で簡単に確認できます。
長年にわたってお客様から寄せられた主要な要件の1つは、ログ情報を簡単に集約する方法が欲しいということでした。このプロジェクトは、お客様の要件から逆算して始まりました。お客様は情報の簡単な集約だけでなく、セキュリティチームのログ収集コストを最適化することも望んでいました。現在の運用方法を伺うと、これらのログを直接パートナーツールにストリーミングするか、セキュリティチームやログを必要とするビジネスチームによって複数のコピーを作成しているケースが多いことがわかりました。
2年前に立ち上げたAmazon Security Lakeは、大きな採用実績を上げ、お客様から非常に好評を得ています。Security Lakeを有効にする際には、どのアカウントとリージョンでサービスを有効にしたいか、データをリージョンやアカウントごとにどのように集約したいか、どのAWSソースからデータを取り込みたいかなど、いくつかの質問に答えるだけです。Security Lakeは有効化後数分で、バックエンドでAWS Lake Formationを使用して、すべてのデータを自動的にお客様独自のAmazon S3バケットに集約・一元化します。また、すべてのデータをApache Parquet形式で整理し、Open Cybersecurity Schema Framework（OCSF）として知られる形式で正規化します。OCSFは業界の他のパートナーと共に立ち上げたオープンソースイニシアチブで、過去2年間で大きな採用実績を上げています。約2.5年前にBlack Hatで発表し、現在では更新されたバージョンにリビジョンされています。アプリケーションとコンシューマーのためのオープンソーススキーマフレームワークであることから、セキュリティ分野とセキュリティ分析分野の両方から、より多くのIndependent Software Vendorが積極的に参加しているのを目にします。
オープンソーススキーマフレームワークであるため、アプリケーションやコンシューマーログを同じスキーマ形式に変換することができます。これにより、セキュリティチームはこれらのログを簡単にクエリでき、SIEMツールなどのパートナーツールに送信した際に高いパフォーマンスを実現できます。Amazon Security LakeではAWSログソースに対してETLや変換が不要です。AWSログソースからのログ取り込みに料金を支払うことなくログを取り込めるだけでなく、エンタープライズアプリケーション、オンプレミスソース、他のクラウドプロバイダーからのすべてのログも取り込むことができます。これらすべてを標準フォーマットに正規化・変換することができます。
Amazon Security Lakeの活用とAWS Security Incident Responseの導入
Amazon Security Lakeには2つの構成要素があります。1つは「データソース」と呼ばれるもので、Security Lakeに情報が取り込まれる方法を指します。上部に表示されているのは、増え続けているAWSのログソースのリストで、お客様が1か所で簡単にすべてのログを活用できるよう、すべてのAWSログソースをこのLakeでサポートする予定です。また、パートナーソースのリストも増加していますが、これは完全なリストではありません。完全なリストはドキュメントで確認できますが、企業で使用している可能性のあるすべてのアプリケーションが含まれており、Criblなどのパートナーを利用して、他のクラウドプロバイダーやアプリケーションログからのログソースパイプラインをSecurity Lakeに取り込むこともできます。
データが取り込まれて整理されると、完全なコントロールと柔軟性が得られます。この情報がどのように見えるかをお見せするために、これは私がSecurity Lakeを有効にしたAmazon S3バケットのビューです。ここで注目すべきは、この整理や調整を私が行う必要がなかったということです。フォルダはソースログに基づいて自動的に作成されます。これらはすべてAWSのソースです。ここをクリックすると、Security Lakeに取り込むように選択したすべてのログが整理されて表示されます。すべてのAPIアクティビティ、AWS CloudTrail、VPC Flow Logs、監査ログ、Amazon Route 53 DNS、AWS Lambda、AWS WAFなどがご覧いただけます。これらはすべてSecurity Lakeでサポートされています。AWS Security Hubからのすべての検出結果も取り込むことができるため、セキュリティチームは標準のOCSFフォーマットでログだけでなく、関連する検出結果も簡単に照会できます。
同じバケットに戻ると、統合した外部ソースも確認できます。パートナーツールからのカスタムソースや他のクラウドプロバイダーからのソースを追加すると、1か所で簡単に統合して相関付けることができます。これらはすべてお客様に代わって自動的に実行されます。Amazon Security Lakeが提供する主要な価値の1つは、これらのログの整理と調整に伴う差別化されていない重労働を取り除くことです。Amazon Security Lakeにこの情報を取り込むために、AWS Lambda関数やAWS Step Functions、ETLは一切必要ありません。
情報が取り込まれると、お客様はこれらのログを活用する上で大きな柔軟性を得られます。Amazon AthenaなどのAWSの分析ツールを使用してすぐにログの照会を開始したり、Amazon OpenSearch Service、Amazon SageMakerを使用して、セキュリティ業界で進行中の多くのAIや生成AIのイノベーションを活用したりできます。これらのログの上にAmazon Bedrockを配置して、セキュリティチームのワークフローを自動化するための独自の生成AIアプリケーションを作成することもできます。さらに重要なのは、すでに使用している可能性のあるパートナーツールを利用できることです。大きな違いは、これらのサードパーティツールに直接データをストリーミングしてエグレスコストやデータ転送料金を発生させる代わりに、脅威分析やランタイム分析のために30日分や60日分のデータだけをパートナーツールに送信し、データの全体的なライフサイクルはすでに存在するAmazon S3で管理できることです。また、すべてが一元化されているため、ログのセキュリティポリシーとアクセス制御が簡素化され、どのログソースをどのサブスクライバーに送信するかを選択できます。
さらに、分析側のパートナーリストも拡大し続けています。これらのパートナーは現在Security Lakeをサポートしており、その多くがFederated queryアクセスをサポートしているため、パートナーツールにデータを移動する必要がありません。Amazon Athenaと同様に、これらのログをリアルタイムで照会できます。パートナーツールや主要なSecurity Information and Event Management（SIEM）ベンダーの一部は、現在Security LakeからのFederated queryアクセスをサポートしています。
数日前、私たちはAmazon Security LakeとAmazon OpenSearch Serviceの統合を発表しました。これにより、お客様はAmazon Security Lake内のデータソースをOpenSearchに簡単に接続し、カスタムダッシュボードを作成したり、VPC Flow LogsやAWS CloudTrail用にOpenSearchで提供されている既製のダッシュボードを利用したりすることができるようになりました。主要な価値提案の一つは、OpenSearchが現在、追加のコンピュートやそれに関連するコストを必要としないゼロETLのServerlessをサポートしているという点です。
最新のサービスの一つとして、先日発表したAWS Security Incident Responseがあります。セキュリティインシデントへの対応において、お客様に完全な柔軟性とセキュリティを確保していただきたいと考えています。このサービスはこれまでEnterprise Supportプランをご利用のお客様にのみ提供されていましたが、今週から固定のSLAと、Amazon GuardDutyやAWS Security Hubからの検出結果を自動的にトリアージする機能を提供開始しました。お客様がこれらの検出結果のトリアージに支援を必要とする場合、AWS Security Incident Responseを活用することができます。これはAmazonのCustomer Incident Response Teamが運営する人的支援サービスです。重要度2のチケットを登録すると、サービスは自動的にチケットのステータスの可視性を提供します。Incident Response Teamの編成、役割、権限、Critical Incident Response Teamとのコミュニケーション方法を定義することができます。
このサービスにより、お客様は環境内のアクティビティを完全に把握することができます。すべてのお客様にこのサービスの活用をお勧めしています。すべてのお客様が利用できる無料プランがあり、さらに今回、組み込みの自動化機能と24時間365日の専門家サポートを備えた固定SLAバージョンを立ち上げました。 まとめますと、私たちの検知と対応のサービスは進化とイノベーションを続けています。目標は、お客様がAWSワークロードを継続的に検知・保護し、合理化された自動化によってセキュリティを強化できるよう支援することです。これらのサービスは生成AIと機械学習を活用して改善を続けており、お客様が独自のイノベーションに必要な情報を容易に集約できるようにしています。ご清聴ありがとうございました。アンケートへのご協力をいただければ幸いです。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion