re:Invent 2024: AWS PublicセクターチームがGenerative AIのセキュリティ活用法を解説
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Generative AI for security in the real world (SEC403)
この動画では、AWS Public SectorチームのBrad DispensaとAWS IndustriesのMatt Sanerが、セキュリティ分野におけるGenerative AIの実践的な活用方法を解説します。単調な作業の自動化やリソースの最大活用、プロアクティブな防御など、AIをセキュリティツールとして活用する具体的な方法を12個のデモを通じて紹介します。Amazon SageMaker、Amazon Q、Amazon Bedrockなどを使用したインシデントレスポンス、コンプライアンス対応、Deceptionプラットフォームの構築など、実務で使える実践的なユースケースを詳しく解説。特に、Lambda関数とDocker containerを組み合わせた脅威アクターへの動的な対応手法は、セキュリティ実務者にとって示唆に富む内容となっています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
セキュリティとコンプライアンスの専門家による400レベルセッションの紹介
みなさん、こんにちは。Amazon Web Services Public SectorチームのPrincipal Security and Compliance Specialistを務めるBrad Dispensaです。簡単に言うと、私のチームは世界中のPublic Sectorのお客様とセキュリティとコンプライアンスに関する課題について取り組んでいます。私はMatt Sanerです。AWS Industriesと呼ばれる部門のセキュリティスペシャリストのリーダーを務めています。私たちは、世界中の最大規模で最も複雑なお客様がセキュリティソリューションを活用してビジネス目標を達成できるよう支援する特権を得ています。今日は非常に盛りだくさんのアジェンダを用意しています。挙手していただきたいのですが、理論だけの学術的な内容を深く掘り下げたい方はどのくらいいらっしゃいますか？そうですね。では、実際に自分で構築できる実践的な内容を見たい方は？ライトが眩しいですが、手が挙がっているのが見えているとします。何人か見えましたね。それでは始めましょう。今日は12個のデモを用意しています。この時間内では盛りだくさんですね。
念のため確認させていただきますが、これは400レベルのセッションです。400レベルのセッションは最も技術的な内容となります。私たちの期待としては、皆さんがAmazonのテクノロジーを使用されており、私たちのサービスや略語に精通し、プログラミングやコードについてもある程度の知識をお持ちということです。基本的な仕組みの説明はスキップして、実際のプロセスがどのように組み合わさるかを素早く見ていきます。 触れておきたい点の1つは、AIに関する話題が多いということです。今週は町中どこを見ても、AI搭載のスロットマシンだのAI搭載の何とかだのという文字が目につきます。そして、Public Sectorの分野でAIが台頭し始めたとき、私が感じた問題は、これは大きなハイプトレインだということでした。個人的に、これを実践的にどう活用すればいいのか本当に悩みました。そこで私たちは、セキュリティ実務者としての役割の中で実際に使える優れたツールと手法をまとめることにしました。はっきり申し上げますが、これはナードによるナードのためのセッションです。そうでない方は、他にも素晴らしいセッションがありますので、そちらをお勧めします。
Generative AIのセキュリティ活用：課題と可能性
まずは簡単な整理から始めましょう。このハイプトレインが走り始めた当初、多くのお客様からソリューションを構築したいという話がありました。 そして、それらのGenerative AIソリューションをどのように保護するのかという質問が続きました。私たちはこれを3本脚の椅子として考えています。1つ目は「AIをどう保護するか」、2つ目は「セキュリティのためのGenerative AI」、 そして3つ目は「新興のAIソリューションが私たち防御側にもたらすセキュリティ課題」です。今日は、私たちのニーズと目標を達成するためにAIをどのように活用するかに焦点を当てます。
では、セキュリティにおいてGenerative AIは何に適しているのでしょうか？本日のセッションを通じて、これらのテーマが繰り返し出てきます。 まず第一に、単調な作業を自動化することです。時間を取られる作業を効率化したいのです。セキュリティの専門家は限られた貴重な存在で、彼らの時間は非常に価値があります。そこで、単調な作業をどのように自動化できるでしょうか？また、限られたリソースを最大限活用したいと考えています。大学を卒業したばかりの人、キャリアの初期や中期の人、あるいは開発やその他の技術職からセキュリティの役割に移行した人など、様々です。私たちはその成長の過程を加速させたいと考えています。さらに、プロアクティブな対応も重要です。何ができるでしょうか？明らかに、プロアクティブな防御について考える必要がありますし、リアクティブな分析を行う際にも何をすべきかを考える必要があります。
皆さんに理解していただきたい重要な点は、Generative AIやAI全般はツールだということです。これは私たちのデモや説明、例を通じて繰り返し見ていただけると思います。AIは常にソリューションの一部であり、決してソリューション全体ではありません。特にセキュリティの実務者として、このような考え方でアプローチすれば、組織の力を増幅させるために活用できる非常に強力なものがたくさんあります。 これは、私たちが長年望んできた目標達成を支援する仮想アシスタントとして、これらのツールを考えることができる転換点の1つかもしれません。
いくつかの課題があります。これらはセキュリティのユースケースに特有のものではありませんが、セキュリティの実務者は真剣に考える必要があります。私たちは皆、ハルシネーション（幻覚）について知っています - 単なる遊びならば面白いかもしれませんが、これらのツールを実務で頼りにしている時は面白くありません。データプライバシーについて - セキュリティの実務者として、私たちは公開したくありません。どのようなデータを使用し、さらすのかについては非常に慎重である必要があります。品質管理 - どのようにツールやレポート、テクニック、そしてAgent基盤のワークロードを構築して品質管理を行うのか。そしておそらく最も重要なのが、過剰な権限付与です。例えば、Agent基盤のワークフローを通じて誰かがより多くの特権を得てしまう「混乱した代理人」問題を実装したくはありませんし、これらのツールが提供する権限についても考える必要があります。
Amazon SageMakerを用いたインシデントレスポンスの自動化デモ
インシデントレスポンスにおけるGenerative AIのユースケースについて説明したいと思います。先ほどのMattのスライドから指摘したい点の1つは、ハルシネーションやデータ品質の問題についてです。Mattと私は、この点について皆さんに美化して伝えたくありませんでした。そのため、問題が発生した場合、どのように物事が破綻し、実際に望む結果を得るために何をしなければならなかったかをお見せします。すべてが素晴らしいとは言いません。実際に計画通りにいかない場面もお見せしようと思います。
このケースにおけるインシデントレスポンスのペルソナは、組織が困難な状況に直面した際の対処方法に焦点を当てています。あなたの役割は、そのインシデントに対応することです。Runbookやプロセスを使用し、多くの場合、標準に準拠することになります。AWSのGenerative AIスタックにおいて、これらのサービスがどの基盤に位置するかを理解することが重要だと思います。最下層はインフラストラクチャで、これは生のインフラストラクチャ、GPU、AWS Trainiumなどです。これは、実際に生のハードウェアを扱うような、モデルのアカデミックな側面に近い部分です。次は抽象化された層で、Amazon Bedrockがあります - Mattと私は環境でBedrockを広く使用しているのをご覧いただけると思います。これは基盤モデルトレーニングの拡張です。私たちは基本的に下層の上に構築しており、最上層にはAmazon Qのようなものがあります。
Amazon Qはよりリレーショナルな性質を持っており、特別な設定は必要ありません。私たちのデモの両方で見ていただけることの1つは、私たちが異なるツールを好んで使用していることです。私の場合はAmazon SageMakerを好んで使用し、Mattの場合はVisual Studio IDEを好んで使用しているのがわかります。結局のところ、あなたが使いやすいものを使えばよく、私たちは2つの異なるタイプの環境での使用方法をお見せしたいだけです。これは私のチームが作成した成果物から取られています。これはAWS Samplesにアップロードしたオープンソースプロジェクトです。もし次の数分間注目したくない場合は、これがTLDRです - QRコードをスキャンしてノートブックを入手できます。
インシデントレスポンスノートブックは、基本的にAmazon SageMakerを使用してAWSリソースと対話します。この場合、SageMakerノートブックとSecurity Hubの間の接続はBoto3を介して行われます。Boto3はSecurity Hubと対話して検出結果に関する情報を取得し、その後Bedrockを使用して情報を統合し、意味のあるものにします。しかし、皆さんに理解していただきたい重要な点の1つは、これらのAIモデルを使用する際には、特にインシデントレスポンスにおいて、一貫性があるかどうかという問題が常に存在するということです。
このパターンの優れている点の1つは、どこでも動作し、更新やメンテナンスがほとんど、あるいはまったく必要ないRunbookを作成できることです。ただし、「毎回同じ答えが得られるのか？」という疑問があります。私のデモが何度も繰り返し動作する理由は、モデルパラメータを定義する際に、常に低いTemperatureを使用しているからです。私の場合、Temperature 0を使用しています。基本的にこれにより、よりランダムな応答を防ぐことができます。ここで重要なポイントは、すべての言語モデルが非決定論的であることを覚えておく必要があるということです。つまり、これはスクリプトや関数をハードコーディングするのとは異なるということを常に念頭に置く必要があります。非決定論的モデルであるため、常に異なる答えが出てくる可能性があるのです。
私のPromptでは、セキュリティポスチャを改善しようとしているセキュリティエンジニアとして、調査結果を要約して情報を得ようとしています。論理的に考えると、なぜこれを行うのでしょうか？これは先ほど見たQuadrantに関連しています。1つは単調な作業の自動化です。脅威インテリジェンスの要約やアラートの相関関係の分析などを行いたいと考えています。しかし、政府機関であれAmazonであれ、私たちは非常に限られた高度な資格を持つ人材を奪い合っています。そのため、私が持っている人材を組織にとって最も有益な方法で活用したいと考えています。チケット対応を好む人はいませんからね。
自動化の側面では、プロアクティブな観点から下のQuadrantには、パッチ適用や異常な設定の検出、Playbookの作成と実行などがあります。これは今すぐに実現したいことを見ていくことになります。そして、Threat HuntingやGuided Remediationなどがあり、これは他の例で見ていきます。最初の例として、Amazon SageMaker Incident ResponseとSecurity Hubを使用した例を見てみましょう。基本的に、これが実際の調査結果であることを証明しています。
Security HubとAIを活用したセキュリティ脆弱性の特定と修正
これを説明するために、Security Hubを使用したAmazon SageMaker Incident Responseを見てみましょう。これが実際の調査結果であることを証明しています。この場合、意図しないSecurity Groupが接続されているEC2インスタンスを特定しました。最初に行うことは、そのSecurity Hub Findingを取得することです。そこでSageMaker Notebookを実行して、その調査結果の情報を取得すると、何が返ってくるでしょうか？大量のテキストのJSON、そうですよね？これは役に立ちませんし、新入社員にとってはなおさら役に立ちません。
次のパートでは、先ほどお見せしたPromptを使用してそのライブラリを活用し、すべての情報を整理して、これが何を意味しているのかを理解するのを手助けします。なぜそのSecurity Groupがオープンだと言っているのか？それはどういう意味なのか？そしてここで、人間が読みやすい形式で情報が得られることがわかります。Security Groupに関する情報が含まれており、なぜそれがベストプラクティスではないのかを説明しています。これは、ジュニアプログラマーのスキルをより早く向上させるのに役立つ方法です。
次のステップとして、問題を特定したので、できれば修正したいと考えています。ここでご覧のように、Security Group IDをそれに置き換えています。そして基本的に、この問題を修正するためのコードを求めています。これでPythonコードができましたが、この環境では少し追加情報も提供しています。この対応者は新人だという前提なので、ただ単にクリックするだけではなく、その関数が何をするものなのかを読んで理解してほしいと考えています。
最後の部分では、これをいじり始める前に、何かに接続されているかどうかを確認する簡単なテストを行いたいと思います。そこで、これが実際に稼働中かどうか、ENIに接続されているかどうかを確認する簡単なサニティチェックを行います。この場合、1つ目は現在ENIによって使用されていないことがわかります。2つ目については、基本的に調査結果で2つのSecurity Groupが返されました。もう一方はENIに接続されています。これは接続されていないという結果が返ってきたので、その点については問題ありません。
そこで次に、その情報を活用して、修復スクリプトまたは関数を提供できるようにしたいと思います。ここでご覧のように、Security Group IDを返す関数を実行して、すべてが期待通りに動作していることを確認します。そして最後の部分では、そのEC2インスタンスに関する調査結果の情報があり、すべての情報が返ってきています。
AIを活用したコンプライアンス業務の効率化：SBOMの自動生成
次に紹介したい例は、誰もやりたがらない作業を行うことです。私はPublic Sectorに所属しており、多くのコンプライアンス業務を行っています。私自身はコンプライアンスが好きですが、誰もが好きというわけではありません。多くの人にとって、コンプライアンスは難しいものです。そこで私たちが実現したかったのは、監査に関するヘルプを求めている人々、コンプライアンスリスクの観点からヘルプを求めている人々、そういったペルソナに向けて話をすることでした。
これが私たちが想定しているあなたの姿であり、US Federal Spaceにおけるこのようなソリューションに期待される成果だと考えています。Software Bill of Materials（SBOM）のような要件が次々と出てきています。そこで私が実現したいのは、SBOMを生成するという要件を満たすための運用上の摩擦を減らすことです。この環境でも、前回と同様にSageMakerを使用します。前回と同じようにBoto3とインターフェースを取ります。そして基本的に、Systems Managerから環境の現状に関する情報を取得するためのフックを使用することになります。
私たちのプロセス概要としては、「あなたはCloud Complianceのスペシャリストで、これはFedRAMPベースのワークロードです」というようなプロンプトを使用しています。そして、SSP SBOMの付録レコードを生成したいと考えています。生データを使用する場合、これはそれほど複雑な作業ではありません。デフォルトの生情報をそのまま使用すると、このような形になります。JSONのブロブが返され、基本的な表形式への変換も可能ですが、見た目が良くありません。また、プログラムによる分析の観点からも非常に扱いづらいものとなっています。
そこで、現在注目を集めている新しい標準規格の一つであるCycloneDXを採用しました。私の環境にCycloneDXのスキーマを取り込み、このパターンを自分のデータに適用して結果を得られるようにしました。この場合、SageMakerのノートブックがあり、下部にこのようなテキストブロックがあります。私はコンプライアンスの担当者であり、プログラマーではないので、これらが何を意味するのかわからないかもしれません。これが私の悲しい表情の理由です。Software Bill of Materialsを生成しなければならないと言われていますが、このような形では扱いたくありません。
では、これをもっと簡単にできないでしょうか？はい、できます。この場合、最初の発見データを呼び出します。ここでご覧のように、SageMakerノートブックを実行しています。データをロードしますが、緑色のフラッシュが表示されるたびに、時間短縮のために処理を加速させています。先ほど見た同じ発見データが得られました。次の部分では、先ほど取り込んだ標準規格に対して、CycloneDXの出力を生成するように指示します。
そして、できあがりです。CycloneDXについて、トレーニングやファインチューニングは必要でしたか？いいえ、基本的にこれは、「このデータに対してこのタイプのモデルで出力してください」と指示する非常に簡単な方法です。これにより、最小限のサポート情報で迅速に作業を進めることができます。
Amazon Bedrockを用いたコンプライアンス質問への自動応答システム
また、よく目にするのは、コンプライアンスに関する質問への対応です。標準規格を扱う際には、「AC-3コントロールをサブセクション2に適用し、171のコントロールにも適用されていることを確認する必要がある」といった専門的な言葉が使われます。コンプライアンスに携わっていない人にとっては、「やりたくない」とか「全く興味がない」という反応になりがちです。そこで私が実現したいのは、このような基本的な質問への対応というオペレーション上の負担をコンプライアンス担当者から取り除くことです。
では、中身を見ていきましょう。この例では、私の環境にFedRAMPのデータを事前にロードしています。NIST 800-53 R5のコピーがあることがお分かりいただけると思います。実際に、AmazonのサービスとScopeのページをHTML形式で取り込んでみました。なぜかって？実際にScopeに含まれているかどうかを確認したかったからです。さらに、組織の要件を理解するために、他のメタデータも2、3点追加しています。
前回と同じプロセスですが、今回はより RAG型のモデルを使用して、そのナレッジベースを活用し、特定のデータセットに関する質問に答えていきます。 この例では、質問に答えていく方法を見ていきます。正直に言うと、簡単な方法があります。SageMakerの起動と停止を行う代わりに、 Bedrockにはこれを行うためのUIが用意されています。これはBedrockのナレッジベースUIを使用した例です。基本的な質問をして答えを得ることができます。853のAC-3コントロールは何ページにありますか？と聞くと、特定のページ番号を返してきます。 ソースの詳細も確認でき、正しい情報を返しているかどうかを検証できます。
しかし、MattとI私は皆さんに正直に話したいと思います。 この場合、特定のページ番号を教えてくれましたが、これは人間の問題で、ページ番号と実際のページ番号には違いがあるのです。 つまり、表示されているページ番号と実際のスクロールページ番号の違いです。AIはこのコンテキストを理解していません。そこで、今回も同じように、データのサブセットを用意して、SageMakerで同じモデルを実行していきます。
同じ情報を使って出力を得たいと思います。同じような基本的な質問をしてみました：800-53の中で暗号化について言及しているコントロールは何ですか？ SC-28が返ってきて、同じように便利な要約が提供されます。ナレッジユーザーインターフェースを使用したくない場合は、SageMaker環境で非常に低い労力で実行できることがわかります。違いは、ナレッジワーカーはおそらくSageMakerノートブックよりもコンソールの方が快適に感じるということです。ただし、IRプロセスのワークブックや、特定のペルソナ向けに調整されたワークブックの一部として使用する場合は、この方法の方が適している可能性があります。
先ほど述べたように、私たちはこれらの問題に対するさまざまなアプローチ方法を、異なるツールを使用して紹介したいと考えています。モノリシックな方法を選択することもできました。 私たちの時間は貴重です。新しい難しい問題が発生したときに、それを解決することに注力したいのです。そこで今回は、これらのバーチャルアシスタントが どのように役立つかを見ていきます。ここでは、セキュリティインシデントレスポンダーやThreat Huntingを行う人のペルソナに注目し、 Visual Studio CodeのIDEを使用して、セキュリティイベントやインシデントをすばやく確認する方法の例を見ていきます。例えば、環境内の潜在的な設定ミスを探している場合、私が初心者で、Boto3 APIやSDKの使い方を知らないかもしれません。これが私の助けになります。プレーンな英語や擬似コードを使用して、クワッドゼロやオープンなセキュリティグループルールを見つけるスクリプトが必要だと伝えます。これらは必ずしも望ましくないもので、コンプライアンスに準拠していないことは分かっていますが、すべての状態、すべてのリージョン、すべてのアカウントにわたってそれらを見つける手助けが必要です。先ほどの指摘通り、最初から完璧に動作するとは限りません。これは会話のようなものです。チャットボットを人間化しすぎないように気をつけていますが、このようなやり取りを会話として考えることもできます。実際、これは私のデフォルトリージョンを設定しませんでした。これは意図的に環境変数に設定していなかったものです。エラーシナリオを実演するために、意図的に特定の変数のない環境を設定しました。
よく理解できないエラーに遭遇したとき、私はヘルプを求めました。システムは問題を認識し、スクリプトの修正を提案してくれました。次の実行では、出力形式を指定しませんでしたが、システムが適切なコンソール出力の方法を提案し、いくつかのSecurity Groupを正常に特定することができました。
AIを活用したDeception Platform：「Feed the bear」戦略の実装
解決策をより堅牢にするため、具体的な改善点を要求しました。問題が見つかった際の専用の警告メッセージ、より詳細な分析のためのTXTファイルとCSVファイルの両方への出力、そしてログ分析を容易にするための適切なUTC形式のタイムスタンプが必要でした。再度実行すると、ディスカバリープロセスが実行されているのが確認できます。生成されたTXTファイルとCSVファイルの両方をお見せしましょう。実装の詳細は明示的に指示せず、必要なカラムと戻り値の形式を指定するだけで、システムが残りの処理を行ってくれました。出力には、コンソールメッセージとロールテキストファイルの両方が含まれており、要求した通りの問題発見時の具体的な警告メッセージも含まれていました。
Bastionホスト用のSecurity Groupを含む、非準拠のSecurity Groupを発見した後、それらの問題に対処するため、適切に設定されていない地域を特定する必要がありました。Excessive Agencyについて議論する際は、環境に変更を加える自動化されたワークフローには十分な注意が必要です。これらのプロセスは必ずテストし、出力を盲目的に受け入れるべきではありません。読み取り専用の操作については適切にリスクを評価しますが、変更を加える場合は、Human-in-the-loopアプローチを好みます。
自然言語とシュードコードを使用して詳細なプロンプトを作成し、それを貼り付けて保存し、結果を確認するために実行しました。スクリプトは全リージョンのスキャンを開始し、最初のリージョンでは何も見つかりませんでしたが、us-east-1に到達すると、問題が見つかり始めました。また、CycloneDXで議論したように、セキュリティツールとの統合を可能にするためにOCSF形式での出力も要求しました。システムは次に、yes/noの確認を求めてきます。この確認ステップは、明示的な承認なしに変更が行われないようにするために重要です。
確認後、Security Groupが適切なBastionホストのSecurity Group設定に更新されたことを確認できます。これにより、そのリージョンのコンプライアンスが回復しました。ここで興味深い話があります。Mattは確かにこれらすべてを手動でコーディングできる能力がありますが、それにどれだけの時間がかかるか考えてみてください。このアプローチは力を増幅させ、適切な基準を維持しながら、より迅速に解決策にたどり着くことができます。最近、政府機関の顧客と仕事をしていた際、彼らのコンサルタントは特定のチェックの実装に3ヶ月かかると見積もっていました。しかし、通話中にAmazon Bedrockを使用することで、必要なコードをすぐに生成して実行し、即座に結果を提供することができました。これはコーディングスキルだけの問題ではありません。コーディングの専門家でなくても、適切な質問の仕方を知っていることが重要なのです。
これらのデモはリアルタイムで行われました。具体的な例では最小限の内容の加速や編集のみを行いましたが、後半のいくつかは編集しています。開発を加速できるという能力は重要です。約125行のスクリプトを手動で書くこともできましたが、このアプローチの方がはるかに効率的でした。
手作業で書いて1日数時間かけてテストを繰り返すか、3分で済ませるか - どちらが良いでしょうか？ これが私の完全なプロンプトです。望む出力が得られなかったため、何度も試行錯誤を重ねました。自分のプロンプトから適切な出力を得る方法を学び、自己トレーニングしていたのです。ここで強調している例の1つは、単に「Inspector をクエリできますか」と言った時に、システムが Inspector Classic API を想定してしまうことでした。私が必要なのは Inspector2 API なので、エラーを避けるためにより明示的に指定しました。
このケースでは、計算が間違って返ってきていました。日数や発見された日付が返されましたが、私は日数で計算したかったのです。そのため、この計算をどのように行うべきかについて、より具体的に指示していきました。これによってシステム内の脆弱性を見つけることができます。 ここで少し加速している部分がありますが、応答が返ってくるまでおそらく20秒ほどかかりました。
前回と同様に入力すると、約120行のコードが保存され実行されるのが分かります。これが事前に用意されたものではないことがお分かりいただけると思います。 エラーが発生した時、このエラーが実際に何に起因しているのか尋ねます。つまり、単純に英語でエラーをコピー＆ペーストするだけです。すると、これは別の方法で対処する必要があると説明してくれます。 そして、盲目的に受け入れるのではなく、トレーナーやコーダーを実際にトレーニングしようとするかのように、変更点を説明してくれます。
もう一度実行すると、今度は4000以上の脆弱性が見つかりました。私はセキュリティの専門家なので、パッチ適用の衛生管理が好きです。これはデモ環境で、この目的のために意図的に脆弱な状態にしています。 この出力はかなり近いものが得られましたが、多くの「N/A」が見られます。私が望んでいたのは、実際の CVE ID を抽出して NVD データベースのリンクを作成することでした。これも、指示を詳細に出さなくても、何かから新しいものを作り出すというコンテキストの一例です。
「CVE IDが返ってこないんですよね。N/Aとしか表示されないので、何か問題があるはずです」と私が言うと、AIは期待した出力が得られていないことを認識しました。では、こうしてみましょう。変更を加えて上書き保存し、もう一度実行してみます。すると結果には、CVE IDとNVDリンクが表示され、この脆弱性の意味や、関連するCVSSスコアについてさらに詳しく調べることができます。
Threat hunterやIncident responderの立場になって考えてみてください。何時間も何日もかけてツールを作る時間はありません。できるだけ早く答えが必要なのです。これこそが、このような素早いターンアラウンドで私たちが実現できることなのです。
次にお見せする一連の例は、最も基本的なものと呼べますが、時には基本的な答えが必要なのです。セキュリティチームが一元化されている場合、私たちの時間を守る必要があります。開発チームやアセットの所有者がコンプライアンスに関する質問がある場合、まず最初に身近なセキュリティの専門家に連絡しようとします。しかし、私たちにはこのような初歩的な質問に常に答える時間がありません。私たちには多くの依頼が寄せられるため、時間を賢く管理する必要があるのです。
これは銀行に行って窓口で待つようなものです。引き出しや基本的な取引のために、本当に列に並んで待つ必要があるでしょうか？その必要はありません。私たちはセルフサービス、つまりATMのような仕組みを目指したいのです。
このシナリオでは、対象となるのはセキュリティの実務者ではありません。開発者や、セキュリティの実務者ではない組織内の人々が対象です。先ほどのAmazon Q Developerを使用した例とは異なり、今回はAmazon Q Businessを使用します。Amazon Bedrockやナレッジベースを使用して実現することも可能で、アプローチは複数ありますが、これはコンポーネントの高レベルなアーキテクチャを示しています。重要なポイントは、内部のポリシードキュメントをネイティブなRetrieverに取り込み、Q Businessに付属するWebexの体験を活用できることです。また、Identity Centerとの統合により、あなたのIDを通過させ、データや情報のコンテキストに応じた取得を可能にします。これにより、強力でありながらシンプルな仕組みを実現できるのです。
優れたセキュリティ実践者として、このログイン機能を実装していきます。これは標準搭載の機能なので、アイデンティティの扱い方を考える必要はなく、単に公開するだけです。もちろんMFAも含まれています - これを含めないのは罪です。判断は控えめに...まあ、個人的な判断程度にしておきましょう。ログインすると、アイデンティティコンテキストで認証されます。ただし、このデモでは、私はセキュリティ実践者ではなく、ただの開発者です。基本的なパスワードに関する質問から始めましょう：パスワードの長さはどれくらい必要でしょうか？これは単純なはずです。回答には、「業務関連のパスワードはすべて最低12文字必要」という直接的な引用が示されています。幻覚（Hallucination）について - 先ほど議論したことの一つですが - ポリシーに関する幻覚は特に注意が必要です。正確な文言の引用を提供するだけでなく、直接の出典を脚注として含めることで、人々が確認でき、この情報がどこにあるかを知ることができます。同じ質問が再び出てきた場合、この情報がどこにあるのかを正確に知ることができます。
これらのツールはこのような質問の処理が向上しているので、いくつかのロジックをテストしてみましょう。5文字のパスワードは使えますか？いいえ、最低12文字のパスワードが必要だからです。次に、データベースにアクセスする必要があり、認証情報の保存と管理方法について質問するとします。これはパスワードに関係するからといって、パスワードポリシーの質問でしょうか？システムは、実際には特定のデータベース認証情報ポリシーが存在することを認識できるほど賢いのです。そのポリシーには、認証情報の保存方法が詳細に記載されています。質問のコンテキストに基づいて、どのソースがより適切かを判断できるコンテキスト認識を示しています。次の例では、質問が複数のソースにまたがる場合はどうでしょうか？使用可能な暗号化プロトコルにはどのようなものがありますか？自前の暗号化は避けるべきなので、適切なガイダンスを提供し、正しい方向に導きましょう。適切な暗号化ポリシーとプロトコルに対応する複数のポリシーがあり、参照している2つの異なるポリシーに2つの脚注があることがわかります。
ここで質問したいのですが、DESが素晴らしく安全だということは皆さんご存知ですよね？DESは使えますか？私は開発者なので、わかりません。DESは使えますか？1980年代直伝でクールに聞こえますね。答えはノーです、DESは使用できません。なぜでしょうか？ポリシーで明示的に許可されていないからです。ポリシーにないものは、この場合許可しません。ここでも、その情報の正確な出典を追跡できます。これは、最も貴重なセキュリティリソースの時間を消費することなく、それらの質問に答えることができる非常に強力な機能です。Kirby、そしてこれは私が本当に興奮していることの一つです - Brad、お願いします。次のデモはやや物議を醸すかもしれません。これをDeceptionプラットフォームとして使用します。これまで防御的な対策について議論してきましたが、今度は攻撃的な側面に踏み込みます。これは新興の分野なので、まだ多くの研究が進行中であることを理解することが重要です。これが危険な領域になる可能性があることを明確にしておきたいと思います。
高度なDeception技術：動的リソース生成とカスタマイズされた応答
アクターが私に伝えていること、アクターの特徴、そしてアクターが探しているものについてのメタデータに基づいて、これらのモデルを使用してアクターに応答していきます。しかし、ここでも非常に明確にしておきましょう - これは危険な領域です。明確な注意と焦点が必要な分野です。これを本番環境の重要なデータの隣にデプロイしないでください。これは別の環境に置く必要があります。
Deceptionに関して、これはThreat HunterとBlue Teamタイプの環境に移行します。この点で重要なのは右下の象限のハイライト部分です - これを行うには強力なリスク許容度が必要です。なぜなら、これは私たちがリスクにさらされる可能性のある領域だからです。
過去を振り返って、以前はどのように対処していたのか考えてみましょう。歴史的に見ると、攻撃者の能力をより深く理解したい場合、Honeypotを配置していました。昔は物理サーバーや仮想サーバーをネットワーク上に配置し、通常は何らかの脆弱性を仕込んでおきました。その目的は、攻撃者にそのサーバーにログインさせて、何をするのかを観察することでした。また、攻撃者がネットワーク内で何を特定できるのかを確認したい場合は、Firewallの内側にHoneypotを配置して早期警戒システムとして活用していました。
しかしAWSでは、お客様が早い段階で、認証情報を取得するためのSTSサービスを使用して偽の認証情報を作成できないかと考え始めました。そこで登場したのがHoney Tokenという概念です。Honey Tokenについては、これはオープンソースプロジェクトの一例に過ぎませんが、基本的にこのツールは環境内のどこかに配置できる合成トークンを生成します。コードの中やS3 Bucketのどこかに配置することができます。
このアイデアは、攻撃者がトークンを使用しようとした時に検知する - 基本的にトリップワイヤーとして機能するというものです。トークン自体には権限やポリシーがありませんが、攻撃者はそれを使用するまでそのことを知りません。悪意のある人物として、トークンをロードしてSTS get caller informationを実行し、すべてのEC2インスタンスを見ることができるか、EC2 lsを実行できるか試みます。実行は失敗しますが、APIを呼び出したという事実だけで、このトークンがこのリソースによって使用されたことが即座に通知されます。
ここでの課題は、このモデルが受動的な性質に基づいているということです。基本的に、攻撃者がトークンを使用するのを待つしかありません。そして頭の片隅にあるはずの疑問 - 攻撃者が環境内にいないからトークンを使用していないのか、それともこのようなトークンを使用することのリスクが高いと気付いたからなのか？
そこで、もう少し能動的な何かが必要です。これから私がお見せする例は、実際の顧客との実務で行っているワークフローの概要を見ていくことになります。明らかな理由から、バックグラウンドプロセスについては概要レベルに留めておきます。例の中には出力の返し方が少し単純なものもありますが、それは皆さんを軽視しているわけではなく、単に私の仕事を守りたいからです。いくつかの例を見ながらこれらの実装方法をお見せしますが、完全なコードをお見せすることはできません。
この分野で重要なのは、従来のDeception Platformsとは対照的に、攻撃者が誰なのかを推測する必要があったということです。特定の名前を持つエンティティや、狙うべきInsiderが誰なのかを把握し、どのように誘い込むかを考える必要がありました。一方、このような新しいモデルを使用する場合、発信者の属性を取得して、その人に合わせたカスタマイズが可能になります。例えば、外国語のキーボードを使用していることを検知し、その確率から特定の特徴を推測して、応答の中にその人を引き付けそうな要素を組み込むことができます。多国籍の防衛請負業者が、特定のプログラムを探している特定のエンティティを見つけ出したい場合を想像してみてください。
このテクニックを、非常にカスタマイズされた方法で使用することができます。最初の例は「Feed the bear」です。ここでは、Amazon CloudFrontディストリビューションに向かう実際のトラフィックのシフトを合成します。最初の手順として、バックグラウンドで悪意のある、または不正な攻撃者を特定するプロセスを実行したと仮定します。この場合、これが悪意のある攻撃者だと判断したので、Lambda関数を使用してその接続のヘッダーを書き換えました。そして、その個人とやり取りするために使用する別のAmazon API Gatewayにトラフィックをシフトさせます。
API GatewayによってAmazon Bedrockと連携し、データを供給することができます。このデータは、私の場合DynamoDBテーブルから取得します。最初の関数プロンプトでは、学生情報システムのプロバイダーとして、この特定の攻撃者向けに偽の学生記録を生成したいと想定しています。これが使用したいスキーマで、文字による成績評価とその区分けを指定しています。
Example 5: Revenge of the AIを詳しく見ていきましょう。この場合、攻撃者からのシグナルから始まり、Amazon SageMakerを使用します。これは、実際のレコードが存在することを証明するための処理です。hacker123のレコードがあります。これがLambda関数にフックするAPIです。最初に行うのは、システムに脅威情報、つまり脅威プローブを送信し、それを使用してリソースをその場で生成することです。先ほど見たプロンプトが、それを構築する最初の部分で、これを送信して、彼らが何を狙ってきたのかを示します。
今、hacker123レコードを持つAPIができました。つまり、hacker123は実際に存在します。これがハニーポットではないと確信できました - これが欲しかったものです。しかし、もっとたくさんのレコードを作る必要があります。そこでLittle Bobby Tablesの出番です - Bobby Tablesは最初のスキャナーになります。Bobbyは記録の作成を開始します。これが実際のシステムだと理解し、Bobbyは実在の人物で、信憑性のある情報をもっと見つけたいと考えています。バックエンドでは、Bobbyに関する合成情報をその場で作成し始めています。これにより、その個人が探し始める情報に基づいてカスタマイズを開始でき、Bobby Tablesがどのようなペルソナを持っていたかについての情報を推測できます。さらに、攻撃者が興味を持ちそうな他の潜在的なターゲットの生成も開始できます。
ここで重要なのはDynamoDBテーブルです。冒頭でお話ししたように、これは非決定的なものです。「Bobbyをもう一度表示して」と言われたときに、まったく異なるレコードが表示されるのは明らかにおかしいですよね。そのため、レコードを生成するときは、その特定のアクターのために後で呼び出せるようにどこかに保存する必要があります。DynamoDBテーブルがある理由は、このレコードをそこに保存しておくことで、アクターが再びBobby Tablesを呼び出したときに、正しいプロンプトを返すことができるからです。これは、バックグラウンドで基本的なLambdaを使用して、素早くレスポンスを生成し、情報を提供しています。 これはシンプルなコードの問題の場合、非常にうまく機能します。
この例では、Dockerized環境を使用してジャストインタイムビルドを実行できるようにしたいと思います。この場合、前と同じようなパターンに従いますが、少し変更を加えます。Application Load BalancerをLambda関数に使用し、さらにPCAPを使ってEC2インスタンスに情報をダンプすることもできます。そのプローブがどのように立ち上がってくるかを見ていきます。私の場合、プローブはユーザー名とパスワードを渡すアクターを探すことになります。これはAmazon Threat Intelligenceチームについて説明しているブログの例です。ここでのアイデアは、脅威情報をどのように入手するにせよ、これが私のシステムに供給される情報のタイプの例だということです。どのようなパスを狙っていたのか、どのようなペイロードを渡していたのかという情報を提供してくれるので、それを使ってレスポンスを生成できます。
これはサーバーオンデマンドになります。サーバーを再度生成できるようにしたいと思います。SageMaker環境を使用することになります。このコードブロックが大きいのは、基本的なDocker情報をそこに含める必要があるからです。プローブデータを渡しているのが分かりますが、これは通常は変数になります。
試行錯誤を通じて、プロンプトをもう少し詳細にする必要があることが分かりました。というのも、時々関係のないコードを生成することがあったからです。ここではAPI Gatewayでその場で実行して生成します。API Gatewayのリストに入って更新すると、別のAPI Gatewayができていて、バックグラウンドにLambda関数があることが分かります。Lambda関数はDockerizedコンテナ内でコードを実行します。これによって、そのリソースをその場で再作成するのを助けています。
API Gatewayの出力を置き換えて、これを合成的にテストできるようにします。最初に試すのはBobユーザーです。Bobユーザーは存在しないので、ログイン失敗のプロンプトが表示されます。アクターがadminを探していることは分かっているので、adminを取得しようとしたときに探しているものを表すレスポンスを返せるようにしたいと思います。これは手を振る（ごまかす）例です。Hello Worldを返していますが、実際の環境では、おそらく他のものを返すことになるでしょう。しかし、この場合、ユーザーに関するメタデータと、彼らが送信したペイロードにその名前が含まれていたという事実に基づいて、私たちの環境内でその名前を返したいと考えています。
なぜLambdaを2回使用したのか疑問に思われるかもしれません。 Lambdaは、リソースをその場で生成できるため、断然最速の方法なのです。Lambdaはほぼ瞬時に起動できるため、EC2インスタンスを構築し、起動し、立ち上がりを待ち、インスタンスをアタッチするのを待つ必要がありません。Lambda関数は数秒で起動します。脅威アクターの立場で考えてみてください - 彼らがスキャンして探索しようとする速度に対して、リアルタイムまたはそれに近い速度でデータを取得し、彼らが目的のものに到達する前に何かを作り出すことができるのです。まさに「クマに餌を与える」ような出力を提供したいわけです。
タイミングとアーキテクチャの構築は非常に重要です。これは非常に危険な作業であることを強調しておきたいと思います - 実際にアクターがシステムと対話することを許可しているのですから。Lambdaを好む別の理由は、攻撃対象の永続性の観点から、関数が終了すると、例えばEC2インスタンスのような長期的な永続性について心配する必要がないことです。基本的にLambda関数が自身を終了すると、それで終わりです。コストへの影響についても考慮することが重要でしょう。
これは拡張機能です。 同様のプロセスに従いますが、今度はそれを拡張してコンテナをECRリポジトリに公開できるようにしたいと思います。ここでも、脅威アクターのプローブに基づいて情報を渡し、コンテナを作成していきます。同じプロセスですが、少し時間がかかります。 アクターが探しているプローブデータを使って、再び処理を進めています。今回は、同じタイプのPythonコードを生成しています。 しばらくすると、Dockerマニフェストが完全に構築されます。これをECRリポジトリに公開します。API Gatewayが稼働しているのが確認できます。 ECRに脆弱性のあるアプリケーションが登録されているのが確認でき、これを関数にフックすることで、そのリソース上のDockerコンテナ内でコードを実行できるようになりました。
これが意図した通りに動作しているか確認するため、APIの出力を取得してみましょう。その出力をライブで確認しながら、 お気に入りのアクターであるBobに切り替えてみましょう。Bobは探しているペイロードがadminなので、何も返さないはずです - 予想通り失敗しました。 では、探している対象 - admin - を検索してみましょう。すると、adminが再び返ってきます。この場合、なぜこのような方法を取るのでしょうか？ Dockerコンテナにコードを読み込む理由は、単一の巨大なLambda関数では実行が難しい処理を行いたい場合があるからです。関数の呼び出しに時間がかかりすぎたり、組み込むにはスペースを取りすぎる場合があります。Dockerコンテナに入れることで、このプロセスを加速するためにコンテナを事前にステージングするようなことが可能になります。
すべては時間との勝負です。これにはトレードオフがあります - 「しばらく後」というのは約15秒でした。コンテナを完全にコンパイルし、ECRに公開し、リソースに取り込むまでに約15秒かかりました。アクターの洗練度と使用しているプローブの種類によっては、15秒という応答時間では十分に速くない可能性があります。これは、他のシグナル情報に基づいて、次に何をしようとしているかを予測するワークフローにチェーンする必要があるかもしれません。
きっと今この瞬間も、「それは現実的じゃない、もっとちゃんとやれ」と言っている人がいるはずです。 これまで私が示してきた例は、管理者の認証情報のようなペイロードを渡すことに焦点を当てていました。それはかなり分かりやすく、特に印象的ではありません - 誰でも理解できることです。
ここに、あるプローブデータがあります。 セキュリティの専門家として、私はこのペイロードを脅威アクターのプローブから入手しましたが、彼らが何をしているのかはあまり明確ではありません。そこで、このロジックを調べて、彼らが正確に何をしているのかを特定したいと思います。この場合、同様のワークフローを使用します。同じパスとペイロードが確認できますが、 まず最初にこの脆弱性を特定するように依頼します。プロンプトの開発に役立つので、そのリソースのCVEを取得する必要があります。次に、脆弱性の種類についてより詳しい情報を得る必要があります。脅威アクターのプローブを入力すると、特定のCVEと脆弱性の詳細が返ってきました。課題は、これは役立つしプロンプトでも動作しますが、もう少し調整が必要かもしれないということです。なぜなら、Amazon Bedrockの処理を遅くするだけの他の情報を含めずに、エクスプロイトの正確な名前と正確なCVEだけを教えてもらいたいからです。
この場合、先ほどのDockerコンテナワークロードと同じ作業を行いますが、今度はプロセスの一部を分岐させます。アプリケーション開発では、ウォーターフォール型である必要はないことを覚えておいてください。一つのことを行って待ち、次のことを行って待つ必要はありません。私たちは皆Agileに移行しました。そこで、API Gatewayが構築され、コンテナのステージングが開始される間に、これが何なのかを突き止めるプロセスを最初から分岐させています。これにより、ステッププロセスの下部で、API Gatewayの初期化に約5秒かかることを考慮して、ジャストインタイムでそれを注入することができます。
これら全ての重要な点は、これらのテクニックを使用することで、敵対者のように行動できるようになることです。彼らにとって価値のあるものを推測するのではなく、実際に価値のあるものを提供できるようになります。そのペイロードの脅威情報に基づいて、彼らが探しているものに直接対応したジャストインタイムのリソースを作成できます。先ほど触れたように、これにより彼らに関するメタデータ分析なども始められます。例えば、あなたが猫だとすると、猫らしい特徴から「purr（ゴロゴロ）」を含むものを好むだろうと推測します。そこで、私の応答には「purr」をたくさん入れるようにします。つまり、アクターに合わせて出力をカスタマイズしようとしているのです。これはクールですよね？
AIセキュリティツールの活用：重要ポイントと今後の展望
今日特に強調したい重要なポイントを3つ挙げてみましょう。 まず、これは人間の専門知識の代替ではありません。これらの成果を達成するには、依然として賢い人々が困難な課題に取り組み、対処する必要があります。これらは、先ほど示したように、ツールボックスの中のドライバーのようなツールであり、私たちの仕事の最適化に使用できる方法なのです。
2番目に、これらのサービスは基本的にすぐに使い始めることができます。必ずしもMachine LearningやAIのスペシャリストである必要はありません。この民主化こそが、私たちが現在いる新しい時代を定義するものであり、それを自社の独自データと組み合わせて活用することこそが、本当の価値となります。3番目に、今すぐ実験を始めることです。私たちは様々なアプローチ方法をお見せしました - Amazon SageMaker、Amazon Q、Amazon Bedrockなど、多くのツールがあり、それぞれが異なる機会と異なるアプローチ方法を提供しています。もしあなたが生まれながらのビルダーでないなら、すでにある加速支援ツールを探してみてください。
最初のポイントについて、もう少し詳しく説明させてください。私たちの両方の例で、論理的な懸念は、それらが私たちの本質を掘り下げているということです。しかし、両方のケースで、MattもPrivateも、どのように質問すべきかを知っていなければなりませんでした。単に「ファイアウォールセキュア」と言うだけでは意味がわかりません。しかし、「このセキュリティグループにquad zero CIDRを含めないようにする必要がある」という言い方なら理解できます。適切にプロンプトを作成し、表現する能力が、これからの人々にとって重要な基本スキルとなります - つまり、最高の出力を得られるようにこれらのモデルとやり取りする能力です。
本当にありがとうございました。re:Invent週間の終わりに来ましたが、皆さん素晴らしい一週間を過ごせましたか？素晴らしい発表、素晴らしいスピーカー、素晴らしいお客様とパートナーの皆様 - 皆様に心から感謝申し上げます。このセッションに参加していただき、今週私たちと共に過ごしていただいたことに感謝いたします。そして、この週の後に来るものを本当に楽しみにしています。私たちに何かできることはありますか？セッション後にステージ付近におりますので、お話したい方はぜひお越しください。そして、アンケートの記入をお忘れなく。私たちは本当にそれらを読んでおり、皆様のフィードバックを大切にし、継続的に改善を重ねていきたいと考えています。皆様、ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion