re:Invent 2025: AI時代のセキュリティスケーリング - Gen AI活用による開発から本番環境の保護戦略
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Intelligent security: Protection at scale from development to production-INV214
この動画では、AWSのCISO AmyとNeha Rungta、Eli LillyのAndrea Abellが、AI時代におけるセキュリティチームのスケーリング戦略について解説しています。Gen AIによる脅威の進化と防御の機会を踏まえ、3つの重要な実践を提示します。第一に、セキュリティの専門知識を製品開発ワークフロー全体に組み込むこと。s2n-tlsのようなプリミティブの構築、Agent Coreを活用したAPI自動テスト、Blackfoot、MadPot、Mithra、Sonarisといったactive defenseシステムの運用例が紹介されます。第二に、変化するリスクへの適応。CVE分析の自動化により、P90時間を27時間から10分未満に短縮した事例や、denied party screeningでの96%の精度達成が示されます。第三に、ビジネスとの協働。AWS Security Agentを使用したセキュリティ要件の自動チェックや、Eli Lillyでの脅威モデリングを通じたサプライチェーンリスク管理の実践が共有されます。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
セキュリティチームのスケーリングとAIがもたらす変化
おはようございます。今朝はご参加いただきありがとうございます。皆さん、ここに来られてとても興奮しています。私はAmyです。AWSのCISOを務めています。そして、同僚のNeha Rungta、それからEli LillyのAndrea Abellも一緒に登壇します。今日はセキュリティチームのスケーリングについてお話しします。これについて話せることをとても楽しみにしています。なぜなら、大規模なシステムのセキュリティ確保と、私たちを取り巻く変化への適応は、特に今、非常に重要なトピックだからです。
皆さんお聞きになったかもしれませんが、この数年でAIに関するいくつかの技術的変化がありました。このイノベーショントークでは、少し趣向を変えてみたいと思います。AWS社内でどのようにこれを行っているかについて少しお話ししたいと思います。お客様である皆さんのために、どのようにこれを行っているかについてもお話ししたいと思います。そして、私を本当に鼓舞してくれた素晴らしいお客様の事例を共有したいと思います。
AIだけではありませんが、AIは確かに、セキュリティチームとして私たちがプレイするゲームがどのように変化しているかを示す素晴らしい例です。 お客様のために強力なセキュリティを実現してきた従来の方法は、多くの場合、決定論的なシステムに依存してきました。つまり、これを行えば、あれが起こる、または起こらないということを理解することに依存してきたのです。しかし、非決定論的なシステムではそれでは十分ではありません。防御の観点でこれを行えば、保護の観点でこれが正確に起こるということを確実に知ることはできないのです。Gen AIをミックスに加えることで、物事がどのように再構築されるのか、まだ完全には分かっていません。これはまだ非常に速く変化している分野です。しかし、AIが解決に役立ついくつかの問題について、私たちにとっても脅威アクターにとっても、学び始めています。
Gen AIが変える脅威の風景と防御側の優位性
そこで、今後の変化にスケールするためにセキュリティチームに実行してもらいたい3つのことに入る前に、それらについて少しお話ししたいと思います。まず、脅威アクター側について、最も重要だと思うことは、 Gen AIが脅威アクターにとって、意味のあるターゲット化されたバリエーションを生成することを本当に安価にしているということです。つまり、特定のフィッシングターゲットやブランドに対してターゲット化された攻撃を行う経済性が大幅に安くなり、その結果、より広範な展開とより説得力のある誘引が見られるようになっています。
また、Gen AIコーディングがより普及するにつれて、ビルダーが依存しているAIツールをターゲットにした攻撃も観察されています。プロンプトインジェクションは、この時点では本当に新しいものではありませんが、その使用の進化と反復は確実に見られています。例えば、攻撃者が開発者のツールチェーンが解釈することを知っているコンテンツの中に埋め込まれたプロンプトなどです。そして攻撃者は、AIエージェントがより自律的に行動していることを理解しており、その脅威においてそれを計画しています。そして、これが今日のセキュリティチームであることの意味を変えているのです。
従来のアプローチだけでは十分ではありませんが、決して悲観的な話ばかりではありません。実際、私はかなり楽観的です。なぜなら、これらの同じ機会や進歩は、私たちディフェンダーにとっても利用可能だからです。特に、セキュリティチームとして、ディフェンダーやレスポンダーとして必要な情報を収集し処理するスピードを向上させることができます。私たちはしばしば膨大な量の情報を見渡して、私の同僚のCJが「針の山の中の針」と呼ぶものを特定するゲームをしているわけですが、Gen AIはこの問題を非常に迅速に解決するのに非常に優れていることがわかりました。
そして、皆さんのチームもそうだと思いますが、私のレスポンスチームもこれを試すことに非常に熱心で、社内では、より深いログ調査のプロセスを約4時間から現在平均約11分まで短縮することができました。そして、この分野では引き続き改善が見られています。これは本当に私たちにとって大きなアドバンテージとなっています。例えば、社内で認証情報の侵害が検出されると、自動的にCloudTrailデータを取得できます。AIを使用して影響を受けたすべてのエンティティやラテラルムーブメントの可能性のある兆候を発見でき、人間のレスポンダーに対して、エンティティグラフや実行可能な初期推奨事項を含む完全なパッケージを準備することができます。これにより、レスポンダーは手動の方法と比べて、脅威を迅速に評価し封じ込めることができるようになります。
私たちはこのような投資を業務プログラム全体で行うことを検討しており、これは私たちにとって本当に重要なことです。私たちがここに積極的に取り組んでいるのは、より速く動く必要があることを知っているからです。開発のスピードが上がり、脅威アクターの進化のスピードも上がる中で、私たちはここで迅速に対応しなければなりません。これには、変わっていない基本的なことも含まれますが、マシンスケールで物事が起こり始めると、認証情報管理、可観測性、可視性、レスポンスワークフローなど、より重要になる可能性があります。そして、非決定論的システムは単に異なるため、変化しているもの、変化したものも含まれます。
セキュリティ専門知識を製品開発ワークフロー全体に組み込む3つのアプローチ
この1時間で、私たちがどのようにセキュリティをスピードでスケールさせているかを共有したいと思います。皆さんがスケールするのに役立ついくつかの方法についてより深く掘り下げ、そしてEli Lillyからの非常に説得力のあるストーリーで実例をお見せします。
さて、このトークでは、この部屋を出るときに覚えておいていただきたい3つの主要なことに焦点を当て、セキュリティチームに実行を促していただきたいと思います。セキュリティチームが業務を遂行する場所と方法を、従来の実践方法から変えて、スケールできるようにすることについて考えていただきたいと思います。特に、セキュリティチームの専門知識と活動を製品開発ワークフロー全体に組み込むことについてお話しします。私たちの周りの変化にどのように適応するかを変えて、防止または管理したいリスクに注意を払い続けられるように調整することについてお話しします。そして、セキュリティチームの業務を、ビジネスで行う必要がある一般的な万能アプローチとしてセキュリティに取り組むのではなく、サポートするビジネスが具体的に抱えている問題に根ざしたものにするために、ビジネスと並んで協力することについてお話しします。
では、始めましょう。もしまだやっていないのであれば、ビジネスの開発および運用ワークフロー全体にセキュリティの専門知識を組み込む必要があります。ちょっと熱く語らせてください。私は「シフトレフト」という言葉が好きではありません。おそらくこの部屋の半分の方がそう考えているでしょうけれども。なぜなら、シフトレフトは製品が直線的な方法で出荷されることを暗示しているからです。つまり、タイムライン上にいて、その上で後ろに戻っているということですよね。この直線的なフレームの中で早い段階にシフトしているわけです。しかし、それは今日の製品開発のやり方とは全く違いますし、生成AIが開発の姿を変えていく中で、今後の製品開発のやり方とも確実に異なります。これは混沌とした反復的な混乱状態なのです。ですから、セキュリティチームを左にシフトすることを考えるのではなく、私たちが保護する必要のある製品開発プロセスのあらゆる異なる部分全体にセキュリティの専門知識を組み込むことを考えていただきたいのです。
私たちが社内で行っていることと、皆さんのチームをどのように支援してきたか、そして今後も支援し続けるかについて少しお話ししたいと思います。AWSでは、私たちが運用しなければならない規模のため、創業当初からこのテーマについて反復を重ねてきました。私のチームのセキュリティビルダーたちは、彼ら自身がビルダーなのです。なぜなら、それが真実でなければAWSの規模を保護することはできないからです。そして私たちは3つの異なる種類のものを作成し、投資しています。まず、難しい作業が行われていて私たちが支援できることに気づいたときはいつでも、プリミティブに投資して、ビルダーチームからその作業を取り除きます。一度正しく行いましょう。ライブラリで簡単にしましょう。次に、私たちが社内で呼んでいる、セキュアからイシューマネジメント、アクティブディフェンス、レスポンス、コンプライアンス、アシュアランスまでのライフサイクル全体にセキュリティガイダンスとツールを組み込み、ビルダーが安全な方法で何かを行うために少しの情報が必要なときはいつでも、それが彼らのために用意されているようにします。
そして3つ目は、セキュリティチームとして私たち自身のビルダーエクスペリエンスを適応させて、私たちが必要なことを行うためにスケーラブルにし、私たち自身の社内ツールと開発した外部ツールを使用して、私たちの視点から得られる独自の観点が、ビルダーたちと顧客である皆さんの安全を守るのに役立つようにしています。そして、できる限り頻繁に、これらの進歩を外部に共有して、皆さんの仕事がより簡単になるようにしています。
プリミティブの進化：s2n-tlsとポスト量子暗号への対応
では、プリミティブについて考えてみると、私たちが行っている3つのことを見ていくと、これらは開発者向けの基礎レベルのビルディングブロックであり、難しい、またはすみません、1つ前のスライドに戻していただけますか？ありがとうございます。難しいセキュリティに敏感な作業を取り上げて、デフォルトでうまく実行するものです。プリミティブは開発者の使いやすさのために最適化されています。私たちは社内でこれらを多数作成しており、それらが皆さんの環境でも機能することがわかったときは、皆さんのためにも作成します。そして、時間とともに変化してきた、古いけれど優れた例についてお話ししたいと思います。
では、次のスライドに進みましょう。s2n-tlsは、私たちがリリースした、皆さんにとって有用であることがわかっていたこの種のプリミティブの例であり、長年にわたって進化し成長してきました。これはTLSプロトコルのオープンソース実装です。小さく、高速で、シンプルさを優先して設計されています。私たちは、確か当時OpenSSLだったと思いますが、それが50万行以上のコードであることに気づき、これをどうやって安全にするのかと考えました。そこで、本当に必要なものは何かを検討しました。人々が通常使用しない余分な機能を大量に削除し、それを6,000行のコードにまで削減しました。
私たちは2015年に、セキュアであることを確認し、そのセキュリティ実装を理解できる形でコミュニティにリリースしました。2022年には、s2n-quicという類似のバージョンを、同じ原則に従ったQUIC Transportプロトコルのオープンソース実装としてリリースしました。そしてその年の後半には、ポスト量子鍵交換のサポートも追加しました。この鍵交換は、NIST PQCプロジェクトの3つのポスト量子鍵カプセル化メカニズムのサポートを追加するものです。
私たちは、これらのプロトコルの適切な実装は、慎重に行われ、注意深く構築され、徹底的にテストされ、広範囲に検証される必要があることを知っていました。それは、誰もが長期的にこれらの基盤となる構成要素に依存できるようにするためです。皆さんも同じ問題を抱えていることを知っていたので、私たちはこれをリリースしました。これは、多くの方が実際にそうされているように、セキュリティプリミティブとして皆さんが試して使用できる素晴らしい例です。これが私たちが行う最初の種類の仕事です。つまり、私たち自身がビルダーとなり、製品開発ライフサイクル全体に私たちの知識を組み込むということです。
エージェント駆動のAPIテストとコンプライアンス評価の自動化
このようなプリミティブに加えて、私たちはワークフロー全体に組み込んでいます。この例については今年のre:Inforceで初めて言及しましたが、システムは改善を続けていますので、少しアップデートをお伝えしたいと思います。AWSはAPIで動いています。セキュリティチームとして、機能テストと同様に、それらが皆さんの安全を守ることを確実にするために徹底的にテストする必要があります。最近、私たちはエージェント駆動のソリューションを通じて、ビルダーチームからテストの手間を削減する支援をしています。
APIに変更が提案されると、エージェントがそのAPIを分析し、各エンドポイントを適切にテストするために必要なすべてのリソースを作成します。そしてそれは単純なテストだけではありません。通常のケースやエッジケースを含む幅広い範囲をカバーするために、そのAPIの全体像をカバーする多数のテストを作成します。このアプローチにより、ビルダーが毎回細かい作業を大量に行う必要なく、セキュリティテストと保証の一貫性を確保できます。
もう少し例を挙げていきます。コンプライアンスと保証の観点から、できるだけスムーズに、できるだけスケールして正しいことが行われるようにすること、これも過去において製品開発サイクル全体でビルダーが行わなければならなかったことです。これは以前はかなり手作業でした。Amazonの社内用語を使って自己批判的に言いますと、私たちはビルダーに対して、彼らのシステムのコントロールや実装について何度も繰り返し質問していたことがわかりました。そして、これを調べてみると、私たちは製品がどのように構築されているかについて非常に多くのことを知っていることもわかりました。
私たちは自問しました。この知識を活用して、セキュリティ、コンプライアンス、保証の目標を達成し、ビルダーに提供できるものを拡大し強化することはできないだろうかと。そこで私たちは長年にわたって、評価準備の多くを自動化することに多大な投資をしてきましたが、生成AIによって、独立した別個のコンプライアンス作業ストリームから、ビルダーの関与を必要としない初期評価へと移行することができ、関連性が高いと確信できる情報のほとんどをまとめることができるようになりました。
私たちは今でもコンプライアンス評価を実施しています。依然として人間が関与していますが、生成AIを含む自動化ツールを活用して、以前はすべてのステップで人間対人間で行われていた評価と検証を実行しています。これによってフローがよりスムーズになります。開発プロセスがスピードアップし加速され、お客様が私たちのものを信頼して使用できることを確認できるようになります。
アクティブディフェンスシステム：大規模な脅威インテリジェンスの収集と保護
製品リリース後、私たちのアクティブディフェンスシステムは、お客様を保護し、大規模に脅威インテリジェンスを収集するように設計されています。これも私たちが話してきたことの一つです。クールだからですが、私たちのソフトウェア開発ライフサイクルと運用フローの中でどのように機能するかについては、あまり議論してこなかったと思いますので、ここでその文脈で少し説明していきたいと思います。Blackfootは、ネットワークエッジに配置され、外部IPアドレスを内部IPアドレスに変換する内部システムです。
MadPotは、監視センサーと自動応答機能を含む、私たちが持っている大規模なハニーポットシステムです。Mithraは、レピュテーション分析の理解を支援することに焦点を当てた、ある種の大規模なニューラルネットワークグラフモデルである別の内部システムです。そしてSonarisは、ネットワークトラフィックを分析することで、お客様のために潜在的なセキュリティ脅威を自動的に積極的に防御し軽減します。
AWSで働くことの面白いところは、こういう仕事に就く前はスケールという言葉の意味を知っていると思っているのですが、実際に入って1ヶ月後には、ああ、本当にその言葉の意味を分かっていなかったんだなと気づくことです。Blackfootは1日あたり312兆を超えるフローを変換します。MadPotは1日あたり5億5000万を超える悪意のある活動に対応しています。
Mithra は1日あたり20万以上の悪意のあるドメインを処理しており、Sonarisは私たちのために毎日ほぼ50億のスキャンをブロックしています。これらすべてが連携することの素晴らしい点は、ローンチ後も運用している間、それが製品開発の一部になっているということです。私たちは社内の保護だけでなく、AWS Shield、Route 53 Resolver DNS Firewall、その他のサービスを通じて、皆さんに追加の保護を提供することができます。これによってWAFやNetwork Firewallのようなサービスのマネージドルールセットが強化され、GuardDutyやInspectorで顧客に検出結果を提供しています。
この流れ、つまり運用を通じてセキュリティを組み込むことは、セキュリティチームとしてスケールするのに役立つだけでなく、皆さんのアカウントのコンテキストにおける脅威に関する情報を提供し、運用全体を通じて強力なセキュリティ上の意思決定を促進します。これは長期的に製品を構築し運用する際のセキュリティの取り組みの素晴らしい例です。これらすべての取り組みの鍵は、AWSで製品がどのように構築されているかを深く理解し、適切なタイミングでそこにいなければ、うまくいかないということです。製品がどのように構築され運用されているかを理解していなければ、これらのことは何一つうまくいきません。これらは、皆さんを保護するだけでなく、私たちビルダーが構築、デプロイ、運用のライフサイクルを毎日実践し、ビルダーが同じことをすることの意味を理解するために、社内で構築したシステムとツールのほんの一部です。
AIを活用したdenied party screeningの自動化と精度向上
AIはこの分野で私たちを助けてくれています。それはポジティブな影響です。以前は人間が行う必要があった問題の組み立てと解決の一部をAIが得意としているため、タスクを達成する方法が広がっています。しかし大局的に見れば、これは新しいツールが手に入ったときに効果的にスケールする方法のもう一つの例に過ぎません。生成AIによって何か新しい魔法のようなことができるようになったわけではありません。すでに行っていたことをより良く行うのに役立っているのです。これから突入しようとしている新しい段階の要求に応えるためにスケールする方法を考える上で、これは本当に重要だと思います。AIが得意とすることを私たち自身のプロセスに組み込んでいる方法をいくつかお話しします。
社内でAIを使ってスケールを支援している分野の一つに、denied party screeningチームがあります。このチームはエージェントと従来の機械学習やその他の自動化を使用して、トランザクションが遅延なくグローバルな制裁要件に準拠していることを確認しています。繰り返しになりますが、かなり大きなスケールの話をしています。毎日この質問に20億回以上答えています。私たちは常にこのプロセスを自動化してきましたが、今年はBedrock Agent Coreを使用して、以前は人間が必要だったワークフローの側面を管理するAIエージェントをローンチしました。これについてのブログ投稿があります。読んでいただけます。かなりクールですが、特にマッチングの微調整、特定のマッチに対するアクション、または顧客が続行できるようにする能力について、Agent Coreでの作業のおかげで、より良く実行できるようになり、素晴らしい結果が出ています。
過去の決定と比較すると、全体的な精度96%、適合率96%、再現率100%を達成しています。これらは人間を上回るパフォーマンスを発揮し、その膨大なトランザクション量の60%以上で意思決定を自動化するのに役立っています。私たちは、これが何ができるかを理解しようとする段階を超えて、大規模にビジネス価値を生み出すためにそれを活用しています。私たちは皆さんが同じことをできるようお手伝いするためにここにいます。そしてそれについてもう少し掘り下げるために、Neha Rungtaをステージにお招きして、私たちが皆さんをお手伝いする方法の一つ、昨日Mattが共有した発表について話していただきたいと思います。私が特に興奮している発表です。Nehaをステージにお迎えください。
AWS Security Agent：セキュリティの意図をメカニズムに変換する
ありがとうございます、Amy。私はNehaです。本日は皆さんと一緒に、私たちがプロアクティブなセキュリティをスケールさせるために社内で構築し、使用してきたものについて共有できることを大変嬉しく思います。AWS Security Agentは、チームが適切なタイミングで適切なコンテキストにおいて適切なセキュリティプリミティブを使用できるようにすることで、セキュリティを変革します。しかし、それがどのように実現されるかを理解するために、Amazonで私たちが頻繁に使用している概念を掘り下げてみましょう。それはintentionsとmechanismsです。Intentionsとは、あなたが実現したいことです。
それらはベストエフォートであり、正しいことをしようとする試みです。しかし、intentionsには常に努力が必要です。実装が必要であり、継続的な監査が必要であり、そして失敗する可能性があります。一方、mechanismsは異なります。それらは体系化され、組み込まれたintentionsです。誰かが覚えておく必要もなく、誰かが強制して追跡する必要もなく機能します。例えば、高速道路の線はintentionsですが、コンクリートの障壁はmechanismsです。
AWSは、Amyが話してきたように、多くの優れたmechanismsを持っていますが、まだいくつかのintentionsも存在します。例えば、Block Public Accessを取り上げてみましょう。私たちのautomated reasoningチームは、このpolicy analysis engineを構築しました。これを使用して、リソースへのパブリックアクセスをブロックすることができます。S3バケットに対してBPAをオンにすると、そのバケットが今日も、そして将来も決してパブリックにならないことを確信できます。これを可能にするために、さまざまなサービスがBPAと統合しています：S3、DynamoDB、EFSなど。これらの多くのサービスがBPA機能と統合しています。
では、新しいサービスを構築している場合はどうでしょうか？何か新しいものを構築しているとき、BPAが必要だとどうやって知ることができるでしょうか？ここでのポイントは、すべてのサービスや機能にこれが必要なわけではないということです。クリティカルでクロスアカウント共有を持つものだけが必要とします。しかし、必要な場合には、それを持つことが重要です。セキュリティの知識は存在しています。しかし、それは多くのナレッジベースに散在しています。チームは、自分たちに適用される要件を見つけるために、無関係な要件の断片をふるいにかけなければなりません。それは面倒で、一貫性がなく、そしてintentionのように、失敗します。私たちに必要なのは、適切なタイミングで適切な人々に適切な知識を提供するmechanismです。
では、私たちはどのようにそれを実現しているのでしょうか？昨日、Mattの基調講演でFrontier Agentsが紹介されました。これは、自律的でスケーラブルな、人間の介入を必要とせずに長期間動作できる高度なクラスのAIエージェントです。これらのエージェントには3つあります：Kiro Autonomous Agent、DevOps Agent、そしてAWS Security Agentです。Security Agentはコンテキストを認識します。組織のセキュリティ要件を認識しています。作成するドキュメントをチェックしてセキュリティの問題を見つけます。作成するコード、実装するコード、コーディングアシスタントが実装するコードをチェックします。Security Agentは、オンデマンドでコンテキストを認識したpenetration testingを実行し、完全なプロアクティブセキュリティソリューションを提供します。
一歩引いて見ると、Security Agentが行っているのは、セキュリティの意図をメカニズムに変換することです。道路上の線から具体的な障壁へと変えるのです。私たちは過去数ヶ月間、これを非常にうまく活用してきました。そしてこれが、セキュリティの意図をメカニズムに変える私たちの方法となっています。例を見てみましょう。私たちは、Security Agentの関連チームに対するセキュリティ要件として、Block Public Accessを追加しました。デザインドキュメントを作成すると、それがメカニズムになります。
架空のサービスのデザインドキュメントを見てみましょう。Security Agentは、ドキュメント内のすべての要件に対して、1分以内に要件を分析します。関連するコンテキストを使用します。この要件は重要か？どのセキュリティ要件が適用可能で、どれが適用されないか？そしてここでは、11個が適用不可となっています。なぜなら一般的に、特定のサービスに対しては、そのサービスに適用されるすべてのものがあるわけではないからです。5つが準拠しています。素晴らしい、これについては何もする必要がありません。2つは追加情報が必要です。なぜなら、ドキュメントで何かを十分に指定していない可能性があり、エージェントは、準拠しているかどうかを判断するのに十分な情報がないと言っているからです。そして1つが準拠していません。
では、もっと詳しく見てみましょう。この架空のサービスは、Block Public Access要件に失敗しています。素晴らしい点は、チームがこれをデザインフェーズで、コードを1行も書く前に発見できることです。彼らは何をする必要があるかを正確に知っています。誰も、それを実現するために覚えておくための追加の努力をする必要はありませんでした。これは今や、すべてのデザインレビューで、毎回、適切なコンテキストで行われます。別の例を見てみましょう。
私たちにはDaffodilという内部セキュリティプリミティブがあります。これは私たちの内部のものです。なぜなら、これは形式的に検証されたIAMライブラリで、他のサービスチームがIAMと正しく統合するのを支援するものだからです。正しいことが証明されており、数学的に証明されています。しかし、チームがDaffodilについて知らなければ、その証明はチームにとって何の役にも立ちません。使うべき最高のものがあっても、それが存在することを知らなければ、どうやって使うのでしょうか？もう1つの課題は、IAM統合は非常に標準的なので、チームがデザインでそれを文書化することはほとんどなく、そのためデザインレビューだけではこのギャップを捉えられないということです。
そこで、Security Agentはコードレビューも分析します。私たちが定義した同じセキュリティ要件を使用します。そしてこれが例です。私たちの内部コードシステム内で、新しいサービスが立ち上がろうとしているコミットの提案がありますが、チームはDaffodilとの統合を忘れていました。そこでSecurity Agentがそれをフラグし、すぐに修復ガイダンスを提供します。さて、このエージェントはGitHubと統合されているので、皆さん全員が、GitHubのプルリクエストで同じ機能を持つことができます。繰り返しになりますが、覚えておくべき意図が、今や忘れないメカニズムを持つようになったのです。要件を一度定義するだけで、デザインレビューとコードレビューの両方に等しく適用できます。
さて、これは私たちと私たちの社内要件についてのお話でしたが、皆さんにも独自の社内セキュリティ要件があるはずです。それらは皆さんの会社、業界、コンプライアンス、そして事業を展開している市場に固有のものでしょう。MCPサーバーが皆さんの会社でどのように構築され統合されるかについて、新しいルールがあるかもしれません。これらのガイドラインは毎月変更されます。週単位で変更されることさえあるかもしれませんが、今ではこれらをセキュリティ要件としてエンコードし、すべての設計とコードレビューに適用されるメカニズムに変えることができます。ガイドラインが変更されたら、要件を更新できます。もう、皆さんが望むことと実際に起こることの間にタイムラグはありません。
私たちはこの数ヶ月間、AWSでのこの速度の変化を気に入っており、皆さんにもぜひこれを体験していただきたいと思っています。ですので、今日AWS Security Agentにアクセスしてセキュリティの意図をセキュリティのメカニズムに変えてください。どうもありがとうございました。それではAmyに戻します。Neha、本当にありがとうございます。私はこれにとても興奮しています。これがどこまで進化するのか、特に私たち全員がそれぞれ異なるビジネスニーズに合わせてカスタマイズできるようになることを見るのが本当に楽しみです。
変化する現実への適応：外部脅威と内部ワークフローの進化
では、私たちのコラボレーションと皆さん自身が行っている作業のおかげで、最後にセキュリティを付け足そうとするのではなく、ビジネスとエンジニアリングのオペレーション全体にセキュリティの専門知識を組み込む道を順調に進んでいると仮定しましょう。でも、まだ終わりではありません。申し訳ありません。セキュリティチームに行ってもらう必要がある2つ目のことは、組織の外部と内部の両方で変化する現実に適応することです。なぜなら、今まさに多くのことが変化しているからです。
組織の外部では、リスクは常に変化しており、皆さんはそれを深く認識しておく必要があります。私たちのサイバー脅威インテリジェンスチーム、ACTIは、最近、夏の終わりにAPT29、またはMidnight Blizzardによる水飲み場攻撃キャンペーンの妨害を支援した作業の詳細を公開しました。私たちは、攻撃者が正規のウェブサイトを侵害し、訪問者のわずか約10パーセントだけをfindcloudflare.comのような攻撃者が管理するドメインや、正規に見せかけるために正規の検証ページを模倣した他のドメインにリダイレクトするJavaScriptを注入していることを特定しました。最終的なターゲットはAWSではありませんでした。それはMicrosoftのデバイスコード認証フローでしたが、私たちは何が起こっているかを見ることができました。
コードの分析により、検出を困難にするいくつかの回避技術が明らかになりました。これには、ランダム化を使用して訪問者の少ない割合だけを誘導すること、Base64エンコーディングを使用して悪意のあるコードを隠すこと、同じ訪問者の繰り返しのリダイレクトを防ぐためにCookieを設定すること、そしてブロックされた際に新しいインフラストラクチャに移行することが含まれていました。AWSシステムの侵害や、私たちのサービスやインフラストラクチャへの影響は観察されませんでしたが、私たちはこれが進行中であることを確認しました。私たちはインターネットのセキュリティを保護することにコミットしており、このような高度な脅威アクターを積極的に探し出し、妨害しています。そこで私たちは、影響を受けたインスタンスを迅速に隔離し、移動している場合でも活動を追跡して妨害し、関連情報をパートナーと共有するよう取り組みました。これは極めて重要です。これは非常に興味深い作業です。素晴らしいストーリーであり、AWS Security Blogで読むことができます。
しかし、これを取り上げたかったのは、これが私たち全員が防御しなければならない、そして私たち全員が一緒に防御する方法を見つけ出さなければならない、増加し進化し規模を拡大する攻撃のタイプの一例に過ぎないからです。
もう一つの例は、Amazon Inspectorチームがこの秋、3つの異なるオープンソースパッケージのサプライチェーン攻撃に関する研究を提供したときのことです。これらの攻撃はすべて、オープンソースレジストリ内のパッケージを標的としていました。少し前に表示されたShihuludwormは、典型的な開発者のワークフローを使用して認証情報を収集し、特定の種類のNPM認証情報を見つけると、それを使って自己増殖しました。もちろん、攻撃者が正規の認証情報を使用して通常の作業を行っている場合、検出はより困難になります。私たちはセキュリティ研究者と協力し、AIと組み合わせた新しい検出ルールを展開して、NPMレジストリ内の疑わしいパッケージパターンを特定しました。その組み合わせにより、循環依存関係や特定の設定ファイルの有無などの指標を使用して、このパッケージが疑わしいと思われるタイミングをより正確に把握できるようになりました。
それに基づいて、特定のキャンペーンに関連する150,000以上のパッケージを特定し、OpenSSFと協力して対応と開示と検出を調整しました。これは、脅威アクターの側からのGen AIの進化においてもう少し先に進んだものです。これは今後も続くと考えており、チームは防止しようとしているリスクに適応し、適切に防御する必要があります。
変化しているのは外部だけではありません。おそらく皆さんの中には、開発ワークフローでも今、異なることが起きていることに気づいている方もいるでしょう。開発者がGen AIを使用してより多くのコード、より多くのテストを構築することで、そしてKiroや他の何かを使った仕様モードに移行することで、やり方を変えていく中で、セキュリティチームとしてリスクに対応するために行動を適応させる準備ができるよう、防止しようとしているリスクに目を向け続ける必要があります。実は私は、この開発者ワークフローの特定の変化について本当にワクワクしています。なぜなら、これがセキュリティチームにとって新しい機会を開くと思うからです。
Gen AIで強化されたコード開発は、開発者、つまり人間と、本番環境で実行されるコードの間に距離が挿入されるもう一つの例に過ぎません。少なくとも私のキャリアの中で、この二つの間にいくつかのステップが離れていくのを見てきました。私が始めた頃は、かなり低レベルな言語で作業していました、とだけ言っておきます。それから、CICDがより一般的になり、そしてテスト駆動開発がより一般的になったとき、人間とコードを実行するマシンの間の距離を広げていました。Gen AIはそれを、もう、すごい勢いでやろうとしています。
これはセキュリティチームにとって本当にチャンスなんです。なぜなら今日では、テストが少し不完全でも人間が高い判断力を持って関与していれば、おそらく問題ありません。何かがおかしな方向に進んでいるときに気づくことができます。しかし将来、テストが少し不完全で、人間がこのプロセスのどこにもいない場合、セキュリティの観点からだけでなく、運用の観点からも、物事が本当に速く、本当に悪い方向に進む可能性があります。可用性のリスクがあるかもしれません。
この新しい世界に移行するにつれて、私たちがサポートする開発者は、テストが優れたものである必要があります。この新しい現実において、堅牢なセーフティネットが必要になるのです。そしてそれが、セキュリティチームにとって以前は必ずしも真実ではなかった何かを開くことになります。それは、私たちが同じ堅牢なセーフティネットを使って、修正が必要だとわかっているものを、開発者からの入力、調整、または依存関係なしに修正できるということです。私たちは彼らのためにそれを解決できるのです。このテクノロジーは、その結果として、開発者との契約を変える機会を本当に私たちに与えてくれています。そしてこれにより、何か新しい変更が必要なものを発見したときの対応において、以前よりもはるかに迅速に適応できるようになります。
私はこのことに本当にワクワクしていますし、リスクに焦点を当ててこの問題にアプローチする方法であれば、今後数ヶ月、数年でもっと多くの例が見つかると思います。物事はまだ急速に変化していますが、そこに到達するプロセスではなく結果に焦点を当てるこのアプローチは、私たちがAWS内で時間をかけて構築してきた筋肉のもう一つの例です。適応する必要があることに気づいたとき、つまり物事が変化していることに気づき、どこに向かいたいかを知っているとき、私たちは人間対人間の双方向ドアの学習と実験から始めます。私たちは、サポートする開発者と共に最高のイノベーションを結集し、そして何かを自動化する方法や初期実験を作成する方法を見つけ出し、それから反復してスケールすることができます。
この種の適応の鍵、セキュリティチームでそれを行う際に成功するための鍵は、何を測定しているかを非常に慎重に考えることです。あなたはセキュリティの専門家なので得意でしょうし、その測定システムで何が間違う可能性があるかを非常に慎重に考えることです。逆インセンティブは何か？誰かが数字を操作しようとしたら何が起こるか？セキュリティチームとして何を見ているのかに本当に注意を払ってください。そうすれば、物事が変化したときに適応できるようになります。
次に進む前に、これについて簡単にお話しします。セキュリティ組織が行う必要がある最後のことに移る前にです。私たちはエージェントを使った実験を始め、より汎用的なヘルパーを作成しようとしました。最初の私たちのメンタルモデルは、これらは非決定論的で、生成的なことができるので、人間として考えましょうというものでした。それを達成するのにかかる速度とコストとともに、彼らがやろうとしていることのセキュリティ品質を測定していたので、これが実際には私たちにとって全体的に成功するアプローチではないことに気づくことができました。より特定的なエージェントの集合体が、より汎用的なものよりも優れたパフォーマンスを発揮することに気づきました。それが見つけられるものの観点からだけでなく、重要なことに、プロセスに沿ってどれだけの反復と人間の関与が必要かという観点からもです。
成功は、エージェントが一つのことをうまくやっているときに訪れます。そして、それらを組み合わせて、Nehaが話していたような、より大きくて魔法のようなものを作り上げることができるのです。私たちはこれをセキュリティアプローチに組み込んでいます。なぜなら、私たちは一つのことだけを見ているのではなく、測定する必要があるものの全体像を考えていたからです。エージェントが一つのことをうまくやる場合、エージェント自体を保護するという観点からも、実は推論しやすくなることがわかりました。もし私が、何でもかんでもアクセスが必要な、いわば野放しのエージェントを作っているなら、まあ、すべてへのアクセスが必要になります。もし私が、一つのことを本当に具体的に、本当にうまくやるエージェントを作っているなら、それにどんな権限が必要かがわかります。ですから、パフォーマンスだけでなく、セキュリティも相補的であることが、私たちのアプローチで発見されました。この種のエージェントは最小権限のパーミッションモデルに適しているからです。
もしチームのすべてを処理する仮想チームメイトがいるなら、それにはさまざまなアクセス権を与える必要があります。オンコール対応をするものがあれば、一種類の権限を与えることができます。信頼性を担当するものがあれば、読み取り専用のセンサー権限だけを与えることができるかもしれません。これにより、エージェントを使って自律的なアクションを取る際のリスクを低減できます。なぜなら、付与される認証情報が、それらが行う必要があることと、それ以上知る必要があることにスコープされているからです。このスコープと独立したアクションのバランスを取ることで、特定のリスク許容度とニーズに合わせてコントロールを配置することができるのです。
もしこのエージェントがすべてをやろうとしていたら、その能力を失ってしまいます。達成しようとしていることについて本当に注意深く考え、それを測定すれば、自分自身のためにスケールするシステムをセットアップできるようになります。私たちはチームをリスクに集中させるようにセットアップしてきたので、これを理解できていますが、この講演を組織に持ち帰る皆さんに、少しアドバイスと視点を提供したいと思います。目的に合ったエージェントは、適切なことに構造化され集中し続けるための、厳密で全体的な測定があれば、推論しやすくなります。
セキュリティチームが測定しやすいものを測定することは、非常によくあることだと思います。どれだけの発見事項を生成したか？どれだけの発見事項を修正したか？それは本当に重要なことではありません。重要なのは、得られた発見事項を修正するのにどれくらい時間がかかるか、単なる量ではなく、そのカーブがどのように見えるかです。3分以内にどれだけ対応できるか？どれだけ対応できるか？P50の時間は？最も長いテールがオープンになっているのはどれくらいか？それについて何をするか？これらを修正するのに、どれだけのビルダーのアクションが関与しているか？
それに焦点を当てることで、たとえ測定が難しくても、時間の経過とともにセキュリティからより良いスケールした結果が得られます。発見事項と解決について考え、キャンペーンを展開し、好きなだけチケットを発行すれば、素晴らしい発見事項の数字が得られ、素晴らしい解決の数字が得られます。しかし、そこに関わる人間のタイムラインや、ビルダーへの負担を完全に見逃すことになります。今お話ししたように、すべてを一緒に測定していれば、プラクティスを自動化しスケールするためのより良い方法を考え出すことができます。ですから、講演の後半部分の要点は、スケールにおいても、急速な変化を通じても、機敏に適応し続けるためには、適切なものを測定する必要があるということです。
ビジネスとの協力：実際の問題解決とエージェントシステムのセキュリティ
最後にお話ししたいことは、皆さんがサポートするワークフロー全体にセキュリティを組み込み、ビルダーとして行動し、正しいことに目を向けている、ということですね。
セキュリティチームを効果的にスケールさせるために持ち帰るべきことがもう一つあります。それは、ビジネスが行うすべてのことにおいて、パートナーとして協力することです。そして先ほどと同様に、Gen AIがこれをどのように変えているかを含めて、いくつかの例をお話しします。その後、Andreaからお話を聞けることを楽しみにしています。
ビジネスと緊密に連携することで得られるのは、単に一般的な意味でセキュリティを行うのではなく、彼らの実際の問題を解決できるということです。AWSでは、私たちの問題は大規模に運用しているということであり、焦点を優先順位付けし、作業を管理可能な単位に分割することが非常に重要です。これは私たちがやらなければならないことです。このリスクに対処しようとする際に、セキュリティチームが意識すべき中核的なことなのです。ビジネスの問題を理解しているからこそ、効果的にスケールできた2つの簡単な例をお話しします。
AWS全体では、作業はチケットを通じて追跡されており、サポートのコンテキストでは、Target for InvestigationまたはTFIと呼ばれるシステムを使用して、私のチームが関与する必要があるかもしれないチケットを特定、分類、エスカレーションしています。これらのタグはチケットに付けられてフォローアップキューに入れられ、必要とされる可能性がある時にビルダーを積極的に支援できるようにしています。これはすべてのAWSサービスのすべてのケースで実行されており、スケールが私たちの問題であるという点について言えば、これはAWS supportが、エンタープライズ、ビジネス、デベロッパーのお客様にわたって285以上のサービスで年間約150万件のケースを解決しているということであり、そのスケールとペースで私たちがそこにいる必要があるということを意味します。
TFIがケースの対応をリアルタイムで自動的にレビューする方法は、2022年にキーワードと正規表現から始まりました。それは機械学習を使用するように進化し、現在はGen AIを使用するように再び進化しています。そのビジネスとのパートナーシップと彼らの問題に対する深い理解を活用することで、その大規模なスケールと継続的な成長にもかかわらず、AWSとお客様のセキュリティバーを引き上げるためにTFIをスケールさせることができたのです。
セキュリティチームにおいて、私たちにとってより身近な課題として、私たちの規模とCVE公開数の急速な増加が、私たちにとっても、そしてビジネスチームにとっても本当に大きな課題となっています。今年は前年比で約22%増加すると予測されており、2024年の4万件強から2025年には5万件弱になる見込みです。これをAWSチームの視点から考えてみると、1つのCVEが数千万のアセットに影響を与える可能性があるため、これらを迅速に理解し対応できることが非常に重要なのです。
私たちはこれまでもこの作業を自動化してきており、新しく公開され更新された脆弱性について、公開から5分以内に最初のアセスメントパスを処理できるよう自動化しました。これはかなり良い結果ですが、セキュリティエンジニアがリスクを本当に理解する必要があるケースにおいて、より深い脆弱性アセスメントを実施できる速度も反復的に改善しています。そこではGen AIを使用しており、私たちの取り組みのおかげで、セキュリティエンジニアは現在、以前のP90時間が約27時間だったのに対し、10分未満で包括的なアセスメントを完了できるようになりました。これを活用して、深い分析を実施できる対象の数を増やしています。セキュリティエンジニアを活用して、より多くのものを深く理解できるようになり、実際、この深い分析のカバレッジを520%拡大することができました。これにより、変化に自信を持って対応する能力が拡張されています。
最後に、ビジネスと補償コントロールに関する知識を活用して、インフラストラクチャと顧客に対する適切なリスクに適切な方法で対処できるようにしています。私たちは、すべてのCVEを継続的に監視し、ネットワーク到達可能性やインスタンスの詳細、アイデンティティ、データ分類などの要素を考慮して、リスクをニュアンスのある方法で特性化し、ビジネスが必要とすることを実行する、コンテキストに応じたポスチャーを維持するAIベースのアセスメントエンジンをトレーニングしています。これにより、偽陽性をさらに削減し、数百万のアセットにわたってリスクを適切に特性化できるようになります。このビジネスに関する知識こそが、私たちの規模において、開発者を常に怒らせることなく、必要なスピードでセキュリティ問題に対応し修復するのに積極的に役立っているのです。
AWSビジネスが独自に必要とするもう1つのことは、APIのセキュリティを理解する能力です。私たちは基本的にAPIベンダーです。ビジネスチームとこれらの問題に取り組む方法は、まず取り組み方がわかっている最大の機会から始めることです。粗粒度で行い、そこから洗練させていきます。これはラチェット、つまり反復的なサイクルであり、私たちが提供するセキュリティの有効性を常に向上させるために使用しているもので、同時に、セキュリティチームが時々つまずいてしまうと思われる、開始時の麻痺状態を回避することができます。
APIのセキュリティ状況を理解するために、まずSDKを十分に理解することから始め、それに基づいて多数のテストを作成しました。これは素晴らしいことですが、静的です。そこで、APIがどのように使用されているかを見ます。インタラクションはどのように見えるか？何をしようとしているのか？それを使ってセキュリティを理解し、私たちが行っていることを洗練させます。そして今では、システム全体のコンテキストとそれらがどのように相互に接続しているかについて、はるかに豊かな全体像を提供できる自動化されたヘルパーを、ますます活用できるようになっています。
次回は別のことをやろうと思っています。なぜなら、私たちはビジネスと一緒にいて、彼らが何をしようとしているのかを理解しているからです。どこから始めればいいかわかっていますし、これまでお話ししてきたすべてのものをどう使えばより効果的になるかもわかっています。皆さんの環境でこれを実現するために、どんなアドバイスがあるでしょうか？まず、皆さんのビジネスが何を達成しようとしているのかを本当に理解することから始めてください。それは私たちが達成しようとしていることとは異なるでしょう。それは素晴らしいことです。本当に素晴らしい。
皆さん特有の問題と制約は何でしょうか？皆さんが置かれている全体的なシステムを見て、大きな機会をいくつか特定し、それらを核心的な粒度で解決してください。それは今日の状態よりも良いものです。そして、これら2つのポイントを深く理解すれば、イノベーションを起こすことができるようになります。エンドツーエンドで質問をし、周りで変化が起きていることに気づいてください。
この会場にいる皆さんの多くは、ソフトウェアを構築してデプロイする企業の責任者です。そのプロセスには3種類のコストが発生します。構築するコスト、セキュアにするコスト、そしてデプロイするコストです。Gen AIは、そのうちの最初と最後を変えつつあります。ビジネスと密接に連携して、真ん中のコストをどう削減できるかも理解できるようにしてください。
私たち自身のビジネスにおけるこれらの変化に気づいたことで、エージェント的な世界に移行するにあたって何が違っている必要があるのかを問うようになりました。そして、私たちのセキュリティビジネスをスケールさせるためにAIを使っている方法についてはすでに少しお話ししました。しかし、エージェント自体をセキュアにすることもあります。そこで、この問題にどうアプローチしたかについて少し時間を取ってお話ししたいと思います。これは皆さんの環境にも適用できると思うからです。
私たちはまず、セキュアに構築し、セキュアに設定し、セキュアに実行してエージェントをスケールさせ、それらの間の分離を確保する必要があることに気づきました。これらのシステムが長期的に価値を提供するためには、過去のやり取りを記憶し、そこから学習できるようにする必要があります。エージェントが何であるか、何にアクセスする必要があるか、きめ細かい方法でこのテーブルが必要なのかを知る必要があります。なぜなら、これらは人間とも完全には同じではなく、サービスとも完全には同じではないからです。
そして、エージェントが複雑なワークフローを実行し、カスタムツールや一般的なツールを発見して接続できるようにする必要があります。そして最後に、テレメトリが必要です。なぜなら、何が起こっているかわからなければ、それを保護することはできないからです。これらのニーズに対応するため、私たちはAgent Coreモジュラーサービスを構築しました。これは、エージェントを安全に本番環境に導入するために必要なすべてのものを組み合わせて使用できるものです。そして、この問題について考え、このように分解していくと、長期的にこれらのものの価値をビジネスでどのように引き出すかが見えてくるでしょう。
agentic systemsについて話しているのか、fast API分析、チケッティング、その他何かについて話しているのかに関わらず、サポートするビジネスと密接に連携することは、スケールする必要があるあらゆるセキュリティチームにとって極めて重要です。私は、Lillyのアンドレアがサプライチェーンリスクについてまさにそれを実践した話に大変インスピレーションを受けました。彼女をステージにお迎えして、詳しくお話しいただきたいと思います。大きな拍手でお迎えください。
Eli Lillyの事例：サプライチェーンリスクへの脅威モデリングアプローチ
ありがとうございます。こんにちは。Lillyでは、私たちは常に患者さんに人生を変える医薬品をより早く届けるために取り組んでいます。そして私と私のチームにとって、それは安全に行うこと、そしてその過程で複雑なサプライチェーンをナビゲートすることを意味します。ですから、もちろん、私たちはAIをナビゲートすることにも取り組んでいます。AIに伴う脅威と、それに伴う計り知れない機会についてです。
皆さんはどうかわかりませんが、私はAIのない世界には戻りたくありません。私はAIが大好きです。でも、企業を守るということになると、私は間違いなく古い学派です。私はサイバーキルチェーンの原則に従って生きています。それは最も基本的なレベルでは、エイミーが今言ったことです。見えないものは守れない、ということです。
ですから、私たちLillyでは、エコシステム全体にわたって可視性を確保することに多くの時間を費やしてきました。なぜなら、率直に言って、ビジネスに影響を与える前にサイバーイベントを阻止したり検知したりできなければならないからです。そして、もし私たちがワークフローにAIを組み込んでいるなら、それはさらに重要になります。しかし、私たちがまだそれを実現するのに苦労している場所がサプライチェーンなのです。実際、アンケートに答えることで何かのセキュリティやセキュリティ態勢を判断する場所は、他に思いつきません。
友人と私はちょうどこのことについて話していたんですが、私たちは実際には問題へのアプローチ自体が間違っているんじゃないかと言っていました。私たちはAIやボットを使ってアンケートにより速く答えようとしているだけで、セキュリティを向上させているわけではないんです。 そして攻撃者たちは何度も何度も私たちが間違っていることを証明しています。なぜならサプライチェーンの侵害が私たちを苦しめているからです。だから私たちは方程式を逆転させなければなりません。方程式を逆転させたかどうかはわかりませんが、Eli Lillyでは確実に古典的なアプローチに戻って、私たちが大切にしているものにサードパーティやベンダーのソフトウェアを接続する際には必ず脅威モデリングを行うことにしました。それが私たちが始めたことで、これから少しストーリーをお話ししたいと思います。少し誇張されたストーリーですが、共感していただけるんじゃないかと思います。 そして願わくば皆さんを楽しませることもできればと思います。
覚えていらっしゃるかもしれませんが、Eli Lillyで私たちが常に目指しているのは、人生を変える医薬品へのアクセスを増やすことで、これは崇高な目標です。考えてみてください、ビジネスサイドはリーチとスケールを加速させる革新的な技術を見つけ出すことに非常に意欲的です。つまり、誰かが人生を変える医薬品をより早く届けることができる新しい技術を見つけてくるわけです。そして私にとってそれは時々、子供が両親に「クリスマスにこのおもちゃを一つだけ買ってくれたら、もう二度と何も欲しいとは言わないから」と言っているように見えるんです。
そしてセキュリティは、脅威モデリングを始めるにあたって、よく大人や理性的な人が言うようなことを言います。「坊や、それで目を撃ち抜いちゃうよ」とね。 そして脅威モデルが出てきて、「平文のパスワードがあります、共有サービスがあります、ラテラルムーブメントの可能性があります、過剰な管理者権限があります」などと言うわけです。そして実際にビジネスサイドに説明を始めると、ビジネスサイドが意気消沈し始めるのが見えるんです。でも優れた脅威モデルはそれ以上のことをしますよね。優れた脅威モデルは緩和策のオプションとそれに伴う優先順位も示します。そして先ほどNehaから聞いたことを考えると、もしエージェントが脅威モデリングできたらどうなるか想像してみてください。うまくいけば近いうちに実現するかもしれませんね。
でも脅威モデリングがどのようにソリューションになり始めるかを考えると、私たちはビジネスサイドを巻き込んで、「わかりました、このソリューションをそのまま採用することはできません」と言います。そしてもしこれが内部の問題であれば、すでに前進しているでしょう。でもサプライチェーンが本当に厄介なのはそこなんです。私たち二者だけの問題ではなく、ビジネスとセキュリティだけではないんです。ベンダーがいるわけです。そしてそこで今年、私たちは複数のケースで幸運にも、サプライヤーのプラットフォームが実際にAWS上にあったんです。それで実際にアカウントマネージャーに電話することができました。Matt SaterとDave Reedに感謝します。私が電話するたびに出てくれて、私たちは三本脚の椅子のようになって脅威モデルを見てきました。
そして実際に計画を立てて、もちろん最も重要なものから始めて、緩和計画に向けて前進し始め、実際に前進し始めることができるんです。ビジネスが必要とすることを満たし、それらの技術を導入できるようにするためにね。そして私が思うに、業界の私たち全員が抱えている課題は、サプライチェーンリスクに関して正しいことをしていないということを私たちは知っているということです。誰もがそれを認めていると思います。素晴らしいニュースは、AIによって実際に私たちの目の前にチャンスがあるということです。そしてエージェントと新しいアプローチ、そして適切なパートナーがあれば、実際にそれを変え始めることができると思います。なぜならセキュリティの誰も喜びを妨げたいわけではないからです。それは実際には私たちの目標ではありません。でも私たちがやりたいのは、皆さんが技術や最新のおもちゃに恋をしたときに、意図しない結果を招くことなく、それから望むものを確実に得られるようにすることなんです。
AIの時代において、私たちは実際にそれを実現できると思います。脅威駆動型のアプローチを取ることができ、洗練された手法を使うことができ、テクノロジーを活用することができます。そして一緒に飛躍することができるのです。AWSには素晴らしいパートナーでいてくれることに感謝したいですし、AmyとNehaにはこのステージを共有してくれたことに本当に感謝しています。彼女たちと一緒に働けて最高でした。 Andreaさん、本当にありがとうございました。私たちはEli Lillyと一緒に働き、これらの課題に手を取り合って取り組めることを嬉しく思っていますが、Andreaがここで説明してくれた仕事について私が最も気に入っているのは、提供しようとしているビジネス成果から逆算して取り組み、その過程で開発者の摩擦を減らすことで生まれる、ポジティブなフライホイールが生み出されることです。
セキュリティは、あらゆるビジネスが顧客に提供するものの一部であり、セキュリティ目標をビジネスの観点から捉えることで、ビジネス全体でどのように協力して提供できるかが明確になります。私たちのactive defenseチームは、実は昔、この方法で始まり、インターネット上のあらゆる悪意ある人々による意図しないデータ発見の可能性を減らそうとしていたS3組織から、非常に積極的な投資パートナーを見つけました。これにより、データサイエンス、分散システムエンジニアリング、脅威インテリジェンス、そしてソフトウェア開発者が、分野横断的に協力し、AWSのユニークなスケールを活用して、顧客を保護するというビジネスのセキュリティニーズを解決することになりました。その取り組みは成長し、私が講演の前半でお話しした、とても楽しいものも含まれるようになりました。
私たちが今いるような変化の中でセキュリティチームをスケールさせることは簡単ではありませんし、不安に感じることもあるかもしれませんが、始めるにあたって思っているよりもずっとシンプルにする3つのことを示してきたつもりです。それには、ビジネスプロセスやワークフロー全体に専門知識を組み込むこと、リスクに目を向けて必要に応じて適応すること、そしてそのすべてをビジネスと協力する強い文化をセキュリティチームに持って行うことが必要です。皆さん自身の世界でこれを実現するための、いくつかの実践的な方法を残して終わりにしたいと思います。そして、残りのショーを楽しんでいただければと思います。
ビジネスプロセスやワークフロー全体に専門知識を組み込むことは、自分自身もビルダーであればずっと簡単になります。そしてこれは、一人でやる必要があるという意味ではありません。私たちがお手伝いします。もちろん、すべてを一度に変える必要があるという意味でもありませんが、問題を解決するために何を構築できるかを考える建設的なマインドセットを持ち、必要なツールや拡張機能を作ることを恐れないことが、これを機能させる鍵となります。
実際に正しいものを測定していれば、リスクに目を向けて状況の変化に適応することがずっと簡単になります。つまり、セキュリティの品質、何を発見しているかではなく、どれだけ早く修正しているか、その目標を達成するために実際に何が必要かとのバランス、そしてエラー率、特に誤検知です。誤検知は信頼を損ないます。
最後に、ビジネスの成果から逆算して理解し、そこから取り組むことで、ビジネスパートナーシップが向上します。特に、お客様が皆さんに期待していることという観点から、セキュリティのニーズをフレーミングすることが重要です。ビジネス側から、どこに摩擦を入れているのか、そこが摩擦を入れるべき適切な場所なのかを理解することです。摩擦をゼロにすることは決してできません。安全でないものをリリースしてほしくはありませんが、ビジネスの賛同を得ながら賢く行うことで、スケールできるようになります。
そして、はい、AIは役に立ちます。いくつかの点ではより困難になっていますが、私は非常に強気です。私たちディフェンダーがこれを使ってかなり素晴らしいことができることについて、とても楽観的です。これは、先ほどお話しした修正をデプロイする能力のような新しい機会を開いてくれます。全体として、私は楽観的でありたいと思いますし、この旅に取り組む上でAIは役に立つと考えていますが、それは私たちがずっと取り組んできた同じ旅における、もう一つのツールに過ぎないということです。
本日はご参加いただき、誠にありがとうございました。モバイルアプリにリンクされているアンケートにぜひご回答ください。AWSではデータと継続的改善を重視しており、どうすればより良くできるかをぜひお聞かせいただきたいと思っています。このセッションが皆さんのお役に立てたことを願っていますし、残りのイベントを楽しんでいただければと思います。それでは、お気をつけて。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion