/w=1920,quality=90,fit=scale-down)
※本記事は、AWS re:Invent 2024で行われたセッション「Precision AI and security action plans: A path to optimal remediation (SEC331)」の内容を基に作成されています。 このセッションでは、Palo Alto NetworksのBar Schwartz氏（プロダクトマネジメントディレクター）とEchoStarのGeoff Filippi氏（プリンシパルセキュリティアーキテクト）が登壇し、Precision AIを活用したクラウドセキュリティの革新について解説しています。 本記事では、セッションの内容を要約しておりますが、正確な情報については、オリジナルの動画をご覧いただくことをお勧めいたします。このプレゼンテーションはAWSパートナーであるPalo Alto Networksによって提供されています。AWS re:Inventに関する詳細情報は https://go.aws/reinvent でご覧いただけます。
1. イントロダクションと背景
1.1. Palo Alto Networksとセキュリティソリューションの概要
Bar Schwartz：このセッションにご参加いただきありがとうございます。今日は、AIを活用してクラウドでのリスク優先順位付けとより良い修復をどのように実現するかについてお話します。私はBar Schwartzで、Palo Alto NetworksのPrisma Cloudでプロダクトマネジメントディレクターを務めています。私たちのクラウドセキュリティチームは、お客様がパブリッククラウドでアプリケーションを実行する際により安全になるよう支援しています。AWSはもちろん、その中でも非常に重要な部分です。
Palo Alto Networksは世界最大のサイバーセキュリティ企業であり、さまざまな分野でセキュリティサービスを提供しています。まず、伝統的なネットワークセキュリティ部門では、お客様向けに運用しているファイアウォールやSASEなどのソフトウェアとハードウェアがあります。これが私たちの成長の基盤となった最初のビジネスです。
二つ目は、クラウドセキュリティのPrisma Cloudです。これは、お客様がクラウド上でアプリケーションを構築する際の保護を提供します。三つ目は、Cortexソリューションによるセキュリティオペレーション（SOC）です。ここでは、完全に統合されたデータと自動化でプレイブックを実行するなど、SOCに対する新しいアプローチでお客様を支援しています。そして、私たちのUnit 42は、脅威インテリジェンスとアドバイザリーサービスを提供し、攻撃を受けている時のお客様支援や、興味深い情報の公開を行っています。
1.2. Prisma Cloudの位置づけ
Bar Schwartz：本日は、Prisma Cloudで行っていることに焦点を当てていきます。CNAPPというのがこの分野の名称で、Cloud-Native Application Protection Platformの略です。これらのプラットフォームは、お客様がクラウドでより安全なアプリケーションを構築したり、クラウドで実行されるアプリケーションを安全にしたりするのを支援するものです。Prisma Cloudは、この分野で最初のソリューションとしてスタートし、お客様をこれらの課題で支援してきました。
1.3. CNAPPの進化（Cloud-Native Application Protection Platform）
Bar Schwartz：CNAPPが誕生した当初は、設定ミスや様々な検証を行う多数の異なる設定やポリシーがありました。例えば、設定ミスをチェックしたり、S3バケットやIAM権限、アイデンティティ関連、クラウドに保存されているデータのタイプ、ワークロードの脆弱性などを確認していました。
これらはすべて個別にチェックされていました。何か重要なことを発見した場合は、アラートを生成して「アイデンティティに問題がある」または「設定に問題がある」などと通知していました。つまり、多くのサイロ化されたポリシーがあり、それらが多くのサイロ化された発見とアラートを生成していたのです。もちろん、相関関係を理解し全体像を把握することは初期の段階では容易ではなく、優先順位付けや修復についても言うまでもありませんでした。
2. CNAPPの進化
2.1. CNAPP 1.0：サイロ化された検出と警告
Bar Schwartz：CNAPPが最初に登場した時、多くの異なる設定やポリシーがあり、様々なことをチェックしていました。これには設定ミスのチェック（データベースやS3バケット、IAM権限などの誤設定）、アイデンティティに関する事項、クラウドに保存しているデータの種類、ワークロードの脆弱性などが含まれていました。
これらのチェックは非常にサイロ化されており、それぞれが個別に行われていました。何か重要なことが見つかると、アラートを生成し「ここにアイデンティティの問題がある」または「設定に問題がある」などと通知していました。つまり、多くのサイロ化されたポリシーがあり、それらが多くのサイロ化された発見とアラートを生成していたのです。相関関係の理解や全体像の把握、優先順位付けや修復は当時簡単ではありませんでした。
2.2. CNAPP 2.0：相関関係と攻撃パスの可視化
Bar Schwartz：数年前、私たちはCNAPP 2.0と呼ぶものにシフトしました。これは市場が相関関係や統合ポリシーを実施し始めた時期です。これはどういう意味かというと、例えば、インターネットに公開されている可能性のあるEC2インスタンスの設定ミスと、機密データを含むS3バケット、そして過度に許可されたアクセス権を持つIAMロールをそれぞれ個別に見るのではなく、それらを一緒に見始めて「ここに実際のパスがある」と言うようになったということです。攻撃者が実際にインターネットからEC2インスタンスに、そしてIAMロールを通じて機密データを含むS3バケットにアクセスできるようなパスです。
私たちはこれらを一緒に結びつけ始めました。そして当然のことながら、アラートや発見の数が減少しました。なぜなら、各項目について個別にアラートを発する必要がなくなったからです。代わりに、攻撃パス全体を見て「ここに問題がある」と言うことができるようになりました。つまり、この場合のアラートはずっと少なくなり、非常に大きな削減が見られました。
相関関係自体、相関部分は現在はるかに自動化されていますが、それでも優先順位付け、つまり実際に取り組む必要があるものは何かを考えると、修復についても言うまでもなく、これらはまだ多くの手作業が必要な部分です。そこで私たちは「次は何だろう？どうすればお客様をよりよく支援できるだろうか？」と考え、CNAPP 2.0から3.0への移行を検討し始めました。CNAPP 3.0では、ご想像のとおり、この優先順位付けと修復の部分をさらに自動化しようとしています。
2.3. CNAPP 3.0：AIを活用した優先順位付けと修復の自動化
Bar Schwartz：私たちが次に何ができるか、どうすればお客様をさらに支援できるか、そしてCNAPP 2.0から3.0へどう移行するかを考えていたとき、明らかに最良のアプローチは、すべての技術的進歩に基づいて、AIがこの領域でどう役立つかを検討することでした。Palo Alto Networksでは、AIを多くの異なる領域、多くの異なるソリューションに統合していますが、ここでの焦点は、AIをどう活用して、より良い検出を行い、優先順位付けを自動化し、実際の修復を支援できるかということです。
実際に必要なものは何かを考えると、主に3つのことがあります。まず、クラウド自体での異常や侵害を継続的に監視して検出できているかどうか。ここで「継続的」が重要なキーワードです。次に、インシデントが実際に発生した瞬間にそれらを分析し理解する方法。そして3つ目は、できれば人間の介入なしに、またはせめて多くの場合において、どのようにそれらを軽減または修復できるかということです。
このように、CNAPP 2.0から、優先順位付けと修復がまだ手動である状態から、それらをより自動的に行うCNAPP 3.0への移行を目指しています。そのために、私たちは多くの検討を重ね、今日お話しする4つの主要なプロジェクトを考案しました。
最初のプロジェクトは、以前お話した攻撃パス、つまり相関関係の構築や、攻撃者がインターネットからマシン、ワークロードを通じて機密データにアクセスできるという物語を伝えるためのものを、自動的に作成する能力に関するものです。私たちはこれらを自動的に行い、多くのAIを利用するよう取り組んでいます。つまり、この膨大なデータを取り込み、それらを組み合わせて、クラウド環境を攻撃する攻撃者のストーリーを実際に伝える方法を理解することです。
2つ目は「ブラストラディウス」です。ブラストラディウスとは、攻撃者が環境のどこかに侵入したとき、どのような影響が広がるかを計算することです。例えば、攻撃者があなたのワークロード、コンテナの1つに侵入できたとします。その後、どうなるでしょうか？攻撃者は何ができるでしょうか？ネットワーク接続性、APIコール、権限などをすべて組み合わせて、環境内での横方向の移動を把握します。ブラストラディウスは、クラウドのどこかに侵入してから、攻撃者が取りうるすべての異なるパスを見つけようとするプロジェクトなのです。
そして今日特に焦点を当てる残りの2つのプロジェクトがあります。1つはリスク優先順位付けの改善で、詳しくお話しします。リスク優先順位付けとは、基本的にあるものが他のものより重要だと言える能力です。これは非常に重要です。なぜなら、多くのことを発見し、それらをお客様に知らせたいからです。データのスキャン、脆弱性のスキャン、設定ミスのスキャン、様々な異なることのスキャンができることをお知らせしたいのです。しかし、取り組むべきことを伝えられなければ、自分で処理しなければならない問題の山が残るだけです。
最後は、修復と問題の修正を支援するアクションプランについてですが、それだけではありません。すぐに詳しくお話しします。これがCNAPP 2.0から3.0への移行アプローチでした。私たちはこれら4つのプロジェクトについて考え、取り組み始めました。これから進捗状況と成果を共有します。
ここでひとつ結論に飛びますが、AIを活用することで、アラートの数と分類・修復にかかる時間を20倍削減することができました。これは大きな数字です。もしあなたがセキュリティチームの一員、あるいはセキュリティに関わる人であれば、セキュリティ関連の業務にどれだけの時間や労力が必要かを理解しているでしょう。これらの問題を解決するのにかかる時間を20倍削減できるなら、それは大きな成果です。これらのプロジェクトでは、AIを活用してこれを実現しました。詳細はこれから共有します。
3. Precision AIによるリスク管理アプローチ
3.1. 攻撃パスの自動検出
Bar Schwartz：私たちがどのようにこれを実現したかについてお話しましょう。最終的な目標はリスクを削減し、排除することです。場合によってはリスクを軽減することもあります。その違いについてはすぐに説明します。まず、リスク管理アプローチには3つの主要な要素が必要と考えました。
第一に、優先順位付けです。取り組むべきことが分からなければ、自動化を実行したり修復を試みたりする意味がありません。優先順位付けは非常に重要な最初のステップだと思います。これについては皆さんも同意してくださるでしょう。
私たちが攻撃パスの自動検出に取り組んだ理由は、以前お話した攻撃パス、つまり相関関係を構築し、インターネットから機械、ワークロードを経由して機密データに至るまでの攻撃者のストーリーを伝えるためのプロセスを、自動的に行えるようにしたかったからです。このプロセスでは膨大なデータを取り込み、AIを活用して、それらのデータを組み合わせてクラウド環境を攻撃する攻撃者のシナリオを実際に構築します。
これにより、セキュリティの専門家がそれぞれの断片的な問題を調査して関連付ける手間を大幅に削減できます。システムが自動的に潜在的な攻撃パスを特定し、それらを視覚化することで、真のリスクがどこにあるのかをより明確に理解できるようになります。この自動化された攻撃パスの検出は、CNAPP 3.0への移行における重要な要素の一つです。
3.2. ブラストラディウス（攻撃影響範囲）分析
Bar Schwartz：2つ目のプロジェクトは、ブラストラディウスです。ブラストラディウスとは何かというと、攻撃者があなたの環境のどこかに侵入した場合、私たちはその後の可能性を計算します。例えば、攻撃者があなたのワークロード、コンテナの1つに侵入できたとします。その後どうなるでしょうか？攻撃者は次に何ができるでしょうか？ネットワーク接続性、APIコール、権限など、これらすべてを組み合わせて環境内での横方向移動を行う可能性を計算します。
ブラストラディウスは、クラウド内のある地点に侵入し、そこから攻撃者が取りうるすべての異なるパスを見つけようとするプロジェクトです。これは、単一の脆弱性や設定ミスがどれほど広範囲に影響を及ぼす可能性があるかを理解するための重要な分析ツールとなります。攻撃者が一度侵入すると、さまざまな権限やネットワーク接続を介して横方向に移動し、より多くのシステムやデータにアクセスできるようになります。
この分析により、一見小さな問題に見えるものが、実際にはより広範な影響を持つ可能性があることを示すことができます。例えば、一つのコンテナの脆弱性が、そのコンテナに関連するIAMロールを通じて、多くの機密データを含むS3バケットへのアクセスにつながるかもしれません。ブラストラディウス分析は、そのような影響の連鎖を明らかにし、真のリスクの大きさを把握する助けとなります。
3.3. リスクの優先順位付け
Bar Schwartz：3つ目の重要なプロジェクトは、リスクの優先順位付けの改善です。これについては詳しくお話ししたいと思います。リスク優先順位付けとは基本的に、あるものが他のものより重要だと言える能力のことです。これは非常に重要です。なぜなら、もし多くのことを発見し、それらをお客様に知らせたいのであれば、データのスキャン、脆弱性のスキャン、設定ミスのスキャン、さまざまな異なる項目のスキャンができることをお知らせしたいからです。しかし、取り組むべきことを伝えられなければ、自分で処理しなければならない問題の山が残るだけです。
例えば、今日のクラウド環境における単純なポリシーやチェックだけを見ても十分ではありません。例を挙げましょう。あなたのクラウド環境、AWSの環境でS3バケットがあり、このS3バケットが暗号化されていないとします。この設定では、S3バケットは暗号化されるように設定されていません。おそらくあなたはそれを知りたいでしょうし、S3バケットのデータを暗号化したいでしょう。しかし、この問題はどれほど重要なのでしょうか？
実際の重要度はコンテキストによって大きく異なります。例えば、本番環境にあるS3バケットの場合、暗号化されておらず、機密データを含み、インターネットに公開されていたらどうでしょうか？この未暗号化のバケットは、別の開発環境で開発者が残したもので、内部にデータがなく、誰もアクセスできないIAM権限を持たない場合よりもはるかに重要です。
つまり、2つのS3バケットがあり、両方とも暗号化されていなくても、「暗号化されていないS3バケットが2つある」と単に伝えるのではなく、「非常に重要で調査が必要なバケットが1つと、あまり重要ではないバケットが1つある」と伝えたいのです。すべてはコンテキストによるものであり、これがリスク優先順位付けで私たちが取り組んでいることです。
3.4. アクションプランの生成と実行
Bar Schwartz：アクションプランは戦略を構築する上で非常に重要です。例えば、あなたがPrisma Cloudで10,000件のアラートを持っているとします。私たちが設定ミス、脆弱性などを発見した10,000件のアラートです。優先順位付けができれば、優先順位付けされた状態になりますが、それでもまだ取り組むべき10,000件の問題があります。
優先順位付けだけを提供して終わりというのは、今日多くの製品で見られることですが、それだけでは不十分です。なぜなら、まだ取り組むべきことがたくさんあるからです。もちろん、重要なものから先に取り組むでしょうが、私たちの主な目標は実際にリスクを排除すること、つまりこれらの問題をゼロにすることです。
そこで次のステップが戦略の構築です。これらのアラートをより効率的に、より良い方法で処理する方法を本当に理解することが重要です。具体的には、クラウド環境を見ると、多くの共通パスや、複数の異なるセキュリティリスクを引き起こす可能性のある共通の問題があります。
例を挙げましょう。攻撃パスを発見したとします。攻撃者がインターネットからワークロードを経由して機密データにアクセスするというものです。これを可能にしているのは、EC2の設定とそのEC2が使用しているIAMロールなどの組み合わせかもしれません。また、別のサーバーレス関数、例えばLambda関数があり、これがIAMロールを使用して、そのIAMロールの権限の組み合わせにより、より多くのアクセスが可能になる場合があります。
これら2つは非常に異なるものです。一方はインターネットからの攻撃者に関するもので、もう一方は環境内での権限昇格に関するものです。しかし、この2つの攻撃パスが同じIAMロールを使用している可能性があります。同じIAMロールが異なるワークロードによって再利用されています。これは私たちがお客様の環境で明らかに見ているパターンです。
1つのIAMロールが多くのワークロードで共通して使用されているなら、そのロールを修正することで、環境内の多くの問題が解決されるのではないでしょうか？これがアクションプランで行っていることです。環境を見て、「発見したさまざまな問題に基づいて、1つずつ対処する代わりに、より効率的な方法があるのではないか」と考えています。
一つのアプローチとしては、問題を見つけて修正方法を理解しようとし、Prisma Cloudの推奨事項を見て、それを適用して問題を解決するというものがあります。そうすれば、心配する問題が一つ減ります。しかしアクションプランでは、「ここにIAMロールがあり、ここに画像があり、ここにEC2セキュリティグループがあります。これらは他の資産で共通して使用されている資産であり、これらを修正すれば複数の問題が解決されます」と伝えています。
アクションプランを使えば、一つずつ修正するよりもはるかに効率的に問題を修正できます。ここでもAI技術を活用しています。IAMロールの例は比較的わかりやすいですが、環境内に何千もの問題があり、それらをどのようにまとめ、グループ化して、ほとんどの問題を解決するための根本原因を見つけるかを理解するためには、AIを活用しています。デモで実際の例をお見せしますが、これにより、アラート数を大幅に削減できます。一つずつアラートに対応する必要がなくなるからです。私たちはそれらをグループ化し、「これを修正すれば、一度に複数の問題、複数のアラートが解決されます」と伝えています。
4. リスク優先順位付けの仕組み
4.1. セキュリティ属性の評価
Bar Schwartz：リスク優先順位付けがどのように機能するのか詳しく説明しましょう。まず、私たちはすべてのセキュリティ問題を調査します。もし環境内でアクティブな攻撃があれば、それを探します。私たちのディフェンダーはワークロード、コンテナ、仮想マシン、サーバーレス関数と連携しており、マシン自体やその公開APIに対する潜在的なアクティブな攻撃に関する情報を取得しています。
次に、異常なアクティビティを探します。例えば、過去に見たことのない場所から環境に接続しようとしている人を見つけたり、過去に見たことのないAWSの特定サービスへの大量のAPIコールなどを検出します。そのような異常行動は、私たちが注目するもう一つの点です。
そして、以前に言及したその他すべての発見事項があります。データ、脆弱性、設定ミス、シークレット、過度に許可されたロールなどを検査します。これらすべてを取り、前述のように、それだけでは十分ではありません。次のステップでは、最初のステップで見つけた問題にコンテキストを追加し、それらの洞察を豊かにします。
例えば、問題を見つけた場所は本番環境か開発環境か、インターネットに公開されているか、誰がアクセスできるか、使用量はどうか、脆弱性の場合はCVSSスコアはどうかなどを確認します。いくつかの要素を見ています。
一つはセキュリティ属性です。これは、CVSSスコアや特定のリスクなど、先ほど言及したものであり、多くの測定方法があります。CVSSスコアは脆弱性の重大度を測る国際的な標準スコアリングシステムで、例えば9.8は非常に危険な脆弱性を示します。こうした客観的な指標を活用して、セキュリティの観点からの重大度を評価します。
4.2. 資産属性の評価
Bar Schwartz：もう一つの評価対象は資産属性です。これは、資産が開発環境にあるのか本番環境にあるのか、インターネットに公開されているのか、といった資産自体の特性を評価するものです。例えば、同じ脆弱性や設定ミスがあっても、それが開発環境のサーバーにある場合と本番環境の重要なデータを扱うサーバーにある場合では、重要度がまったく異なります。
資産がインターネットに公開されているかどうかも非常に重要な要素です。インターネットからアクセス可能な資産は、内部ネットワークでのみアクセス可能な資産よりも攻撃される可能性が高くなります。また、その資産の使用量も考慮します。頻繁にアクセスされる資産は、ほとんど使用されない資産よりもリスクが高い場合があります。
これらの資産属性を評価することで、同じ技術的問題であっても、実際のビジネスリスクの観点から適切に優先順位付けできるようになります。技術的な脆弱性だけを見るのではなく、その脆弱性がどこにあり、どのような環境で動作しているのかを考慮することが重要です。
4.3. 顧客固有の属性を学習
Bar Schwartz：ここまでお話したことはすべて一般的なものです。これらは全顧客に対して実行できることです。しかし、私たちは各お客様がそれぞれ独自の環境を持ち、異なる方法で作業していることを知っています。一部のお客様は非常に優れたタグ付けを行っており、クラウド内のすべての「クラウンジュエル」（最重要資産）や重要なものにマークを付けるためにタグを使用しています。
あるお客様は名前に特定のプレフィックスを使用し、別のお客様はより重要な特定のリージョンを使用しています。それぞれの環境は異なります。そのため、お客様固有の属性も考慮しています。お客様固有の属性は、まさにこれを調査します。クラウド環境でのお客様の行動を時間をかけて学習し、何が重要かを理解します。
私たちはお客様のタグを調査して、「これらのタグから、このものが他のものより重要であることが分かります」と理解します。プレフィックスを見て、「ワークロードにこのプレフィックスがある場合、それはあなたにとってより重要であることを意味します」と判断します。これをどのように知るのでしょうか？お客様のクラウドログを調査し、クラウドでの行動を分析することで、何が重要で何がそうでないかを本当に理解します。もちろん、明示的に教えていただくこともできますが、時間をかけてこれを学習します。
4.4. AIモデルによる優先順位と説明の生成
Bar Schwartz：3つ目のステップでは、完全なコンテキストを獲得した後、実際にリスク優先順位付けを行います。ここでAIとMLを活用しています。私たちはモデル、つまりトレーニングされたモデルを構築しており、これが行動を学習します。グローバルレベルだけでなく、お客様固有の行動も学習します。そして、コンテキストと資産について知っていることに基づいて、このバケットは非常に重要であると言うことができます。
ただ重要であると伝えるだけでなく、なぜそれが重要だと考えるのか、説明を提供することもできます。多くのセキュリティツールに慣れていれば、一部のツールはただ「ここに問題があります、スコアは90です」と伝えるだけだということをご存知でしょう。90は70より重要だということは理解できますが、なぜこれに90を付けて70ではないのか？なぜこれが他のものより重要だと思うのか？これは私たちのアルゴリズムで行っていることであり、AIを使用して、なぜあるものが他のものより重要だと判断したのかを説明できるのです。
これがリスク優先順位付けです。私たちはこれを構築し、すぐに、環境で発見したすべてのアラートや問題を取り、コンテキストに基づいて何が重要で何がそうでないかを伝えることができるようになりました。
5. アクションプランの戦略と効果
5.1. 共通の根本原因の特定
Bar Schwartz：戦略は、前述のように非常に重要です。なぜなら、10,000件のアラートがあり、優先順位付け前はそのまま10,000件、優先順位付け後もまだ10,000件のアラートがあるからです。優先すべきものは分かるようになり、それは素晴らしいことですが、究極の目標はできるだけリスクを減らすことです。そのため戦略が必要です。
クラウド環境を見ると、複数の異なるセキュリティリスクを引き起こす可能性のある共通のパスや共通の問題があることがわかります。例を挙げましょう。攻撃パスを見つけたとします。インターネットからワークロード、機密データへの攻撃者がいるとします。これを可能にしているのは、EC2の設定やEC2が使用しているIAMロールなどの組み合わせかもしれません。
また、例えばLambda関数のようなサーバーレス関数があり、IAMロールを使用して、そのIAMロール内の権限の組み合わせにより、例えば権限昇格のような問題が発生する可能性があります。これら2つの問題は非常に異なります。1つはインターネットからの攻撃者に関するもの、もう1つは環境内での権限昇格に関するものです。しかし、両方の攻撃パスで同じIAMロールが使用されている可能性があります。同じIAMロールが異なるワークロードによって再利用されているのです。
これは明らかに顧客環境で見られるパターンです。1つのIAMロールが多くのワークロードで共通して使用されている場合、なぜそのロールを修正して環境内の多くの問題を解決しないのでしょうか？これがアクションプランで行っていることです。私たちは環境を見て、「様々な問題に基づいて、それらを一つずつ処理する代わりに、より効率的な方法はないだろうか？」と考えています。
人間では、10,000件の問題を分析して共通の原因を見つけるのは困難ですが、AIを活用することで、データのパターンを認識し、多くの問題の根本にある少数の共通原因を特定できます。例えば、脆弱なソフトウェアライブラリが複数のアプリケーションで使用されていたり、過度に寛容なセキュリティグループが多くのEC2インスタンスに適用されていたりする場合があります。これらの共通原因を特定することで、修復作業を大幅に効率化できます。
5.2. 複数の問題を一度に解決するアプローチ
Bar Schwartz：アクションプランでは、環境を見て、「発見したさまざまな問題に基づいて、より効率的に取り組む方法はないか」と考えています。一つのアプローチは、問題を見つけて修正方法を理解しようとし、Prisma Cloudの推奨事項を確認し、それを適用して問題を解決することです。これで心配すべき問題が一つ減ります。
しかしアクションプランでは、「ここにIAMロールがあり、ここに画像があり、ここにEC2セキュリティグループがあります。これらは複数の資産で共通して使用されている資産であり、これらを修正すれば複数の問題が一度に解決されます」と伝えています。アクションプランを使えば、問題を一つずつ修正するよりもはるかに効率的に修正できます。
ここでも私たちはAI技術を活用しています。IAMロールの例は比較的わかりやすいですが、環境内に何千もの問題があり、それらをどのようにまとめグループ化して、ほとんどの問題を解決するための根本原因を見つけるかを理解するためには、AIが必要です。デモでは実際の例をお見せしますが、これによりアラート数を大幅に削減できます。一つずつアラートに対応する必要がなくなるからです。それらをグループ化し、「これを修正すれば、一度に複数の問題、複数のアラートが解決されます」と伝えています。
具体的な例として、あるアプローチでは、単一の攻撃パスで権限A、Bを持つロールを見つけ、それらを削除する必要があるとします。別の攻撃パスでは、同じロールについて権限C、Dを削除する必要があります。アクションプランはこれらを一緒に取り、「これは同じIAMロールであり、権限は異なりますが、問題1を解決するには権限A、Bを削除し、問題2を解決するには権限C、Dを削除する必要があります。全体として、権限A、B、C、Dを削除する必要があります」と理解します。
これは非常に単純化した例ですが、私たちはAIと生成AIを活用して、同じ資産によって引き起こされる異なる問題があり、修正方法も異なる場合に、すべてを一緒に取りまとめて、リスクを排除するために取るべき完全なステップのリストを取得しています。
5.3. 20倍の効率化を実現
Bar Schwartz：AIを活用したこれらのプロジェクトを通じて、アラート数と分類・修復にかかる時間を20倍削減することができました。これは非常に大きな数字です。もしあなたがセキュリティチームの一員、あるいはセキュリティに関わる人であれば、セキュリティ関連の業務にどれだけの時間や労力が必要かを理解しているでしょう。これらの問題を解決するのにかかる時間を20倍削減できるなら、それは大きな成果です。
この効率化は、単に問題をグループ化するだけでなく、それらを効果的に優先順位付けし、最も影響の大きい修復アクションを特定することで実現されています。例えば、100個の個別アラートを処理する代わりに、5つか10つの重要なアクションプランに対応するだけで、同等以上のセキュリティ改善が得られます。これにより、セキュリティチームはより戦略的な活動に時間を費やせるようになり、組織全体のセキュリティ姿勢を大幅に向上させることができます。
最も重要なことは、この効率化により、実際にリスクを排除し、アラートの数をゼロに近づけることができるという点です。単に優先順位付けを行うだけでは、アラート数は減りません。しかし、根本原因に対処するアプローチを取ることで、同様の問題が将来的に発生することも防げます。これがCNAPP 3.0の真の価値であり、AIの力を活用してセキュリティの自動化と効率化を実現しています。
6. 実行フェーズの最適化
6.1. 所有者の特定
Bar Schwartz：最後に、優先順位付けとグループ化だけを行い、実際に問題を解決する実行がなければ、何も価値はありません。そこで実行部分にも取り組んでいます。実行部分では、いくつかの重要な要素があります。
一つ目は、所有者を見つけることです。セキュリティエンジニアやDevSecOpsとして働いている方なら、多くの場合、最初の即時ステップは所有者を見つけることだとご存知でしょう。問題がある、セキュリティの問題がある、セキュリティの設定ミスがある、でも所有者は誰？誰が実際にこの問題を修正できるのか？それはおそらくセキュリティエンジニアではなく、開発者や開発チーム、DevSecOpsなど、実際に問題を修正する人です。
所有者を見つけることは非常に重要な最初のステップです。私たちがアクションプランを生成するとき、さまざまなロジックに基づいて、すぐに正確な所有者を見つけることができます。このチームがこの資産を所有していると言えるのです。したがって、実行したい、あるいは行動を起こしたい場合、これが話すべきチームです。あるいはもっと良いのは、私が後で言及しますが、自分の介入なしに自動的に情報を送る方法です。
6.2. クイックアクション（緩和策）の提供
Bar Schwartz：二つ目は、取れる迅速なアクションです。私たちは明らかに修復について話していますが、修復とは問題を解決することです。例えば、脆弱性があり、その脆弱性をもう持っていない状態にすることです。インターネットに公開されているEC2があり、そのEC2がもはや公開されていないようにすることです。これが修復の部分です。
しかし、多くの場合、状況をより良くするための迅速な対策を取るオプションがあります。完全に修復されたわけではないものの、状況を改善する方法です。これを私たちは緩和策と呼んでいます。
緩和策の例としては何があるでしょうか？公開されているEC2があるとします。完全に削除する代わりに、あるいは脆弱性があり、脆弱なパッケージを再デプロイする代わりに、時間がかかる可能性があります。その間、ワークロードを保護するファイアウォールを設置したり、誰かがこの脆弱性を利用しようとしているのを見たら即座にブロックするようなAPIの保護をしたりできます。
これで問題が解決するわけではありません。脆弱性はまだあります。しかし、正しいことをして問題を修正している間も保護することができます。これが実行部分で可能な、迅速な対応です。
6.3. さまざまな修復形式のサポート
Bar Schwartz：次の要素は、すべてのお客様がこれらの問題を異なる方法で修正しているということです。一部のお客様はTerraformスクリプトでこれらの修復推奨事項を受け取ることを好みます。一部のお客様はコンソールで実行する必要のある実際のステップやCLIコマンドを取得したいと考えています。
また、一部のお客様は独自のスクリプトを作成し、クラウドの問題を修正するための既存のワークフローがあるため、そのスクリプトを実行したいと考えています。私たちはこれらのことを可能にし、さまざまな形式で推奨事項を入手したり、独自のものを持ち込んだりできるようにしています。
6.4. 予防策の実装
Bar Schwartz：次に予防について話しましょう。予防は非常に非常に重要です。問題を修正した後、将来的にこの問題が再発しないようにするにはどうすればよいでしょうか？考えてみてください。環境内のLog4jの脆弱性をすべて修正したとします。しかし、開発者がLog4jの脆弱なバージョンを使い続けるなら、また同じ脆弱性が発生し、再び開発者に修正を依頼することになるでしょう。
しかし、問題を修正した上で、将来的にその問題が発生することも防止できれば素晴らしいことです。それは単に一つの問題を修正するだけでなく、将来の問題も防止することになるからです。Prisma Cloudでは、クラウド環境だけでなく、CI/CDパイプラインやコードリポジトリとの統合も可能です。ここでコードというのは、実際に開発者のIDEを指します。
私たちはパイプライン内の様々な領域と統合しており、例えばCI/CDとの統合により、「この脆弱性を修正し、脆弱なバージョンがなくなるようにイメージを再デプロイしましょう。そして、CI/CDパイプラインでは、開発者がこのパッケージを再度プッシュしようとして脆弱性を引き起こす場合は、ビルドを失敗させましょう」ということができます。これらはすべて、Prisma Cloudから非常に簡単に行うことができます。
6.5. Cortexとの統合によるオートメーション
Bar Schwartz：最後に、Palo Alto Networksの他のソリューションとの緊密な統合について説明します。その一つがCortexで、これにより多くのプレイブックを作成して、問題が見つかったときに実行することができます。例えば、過度に許可されたロールを発見した場合、取るべきステップは何かを考えます。
Palo Alto Networksの別のソリューションであるCortex XSOARとの深い統合により、これらのプレイブックをトリガーして「過度に許可されたロールがあることを理解したとき、毎回どのようなステップを実行する必要があるか」を指定できます。これが自動化の世界であり、介入なしに問題を修正し、最も重要なことに集中できるようにする方法です。
7. デモンストレーション
7.1. EC2イメージの脆弱性対策
Bar Schwartz：それではPrisma Cloudコンソールで実際の機能をお見せしましょう。ここではアクションプランと呼ばれるタブにいます。これが先ほどお話したもので、問題を一緒にグループ化する能力です。いくつか例を見てみましょう。
まず最初に見えるのは、EC2イメージがあるということです。これは基本的にイメージです。スキャンで見つけた24のアラートまたは脆弱性があり、これはすべてこの一つのIAMイメージが原因で生成されたものです。
さらに詳しく分かるのは、このイメージが3つの異なるEC2インスタンスで使用されているということです。つまり、脆弱性のあるイメージを一度定義し、それを異なるEC2インスタンスで使用することで、これらの脆弱性が3つのEC2インスタンスに複製され、環境内でますますリスクが高まっています。
ここでグループ化された24のアラートを表示できますが、アクションプラン以前は、アラートページに行って一つずつ対応する必要がありました。脆弱性に関連するアラート1を見て修正し、次にアラート2に進むという具合です。もちろん、このようなアラートが何千もある場合、どこから始めればいいのでしょうか？そしてこれらのアラートが互いに関連していることをどうやって知るのでしょうか？これらのアラートがすべて同じイメージに起因していることをどうやって知るのでしょうか？
7.2. EC2セキュリティグループの修正
Bar Schwartz：もう一つの例を見てみましょう。2つ目の例では、EC2セキュリティグループがあり、このセキュリティグループがインターネット露出に関連する45の異なるアラートを引き起こしています。ここでも同様に、資産を確認すると、同じセキュリティグループを使用している複数の資産があり、システム内に45のアラートがあります。
これらのアラートの一つを見てみましょう。例えばこちらは攻撃パスです。より大きく表示してみましょう。ここにはEC2インスタンスがあり、脆弱性があります。また、このEC2インスタンスがENI、サブネット、VPCなどを通じてインターネットに公開されている様子も確認できます。
これは一つの問題ですが、この特定のアクションプランには、これに似た45の問題があります。それらは非常に異なりますが、すべてここに示しているこの一つのEC2セキュリティグループを修正するだけで解決できます。ここでは特定のセキュリティグループの完全な情報、その場所などすべての情報を確認できます。
興味深いことに、最初のアクションプランでは24のアラート、2つ目のアクションプランでは45のアラートがあります。重要度順に並べると、システムは基本的に、24のアラートを修正する修正（つまり24のアラートを修正する単一の修正）は、45のアラートを修正する別の単一の修正よりも重要だと教えてくれています。
なぜでしょうか？これはリスク優先順位付けについて話したことを思い出してください。この場合、24のアラートは第2のアクションプランの他の45のアラートよりも重要だと理解しています。両方のアクションプランで、24のアラートを解決するために1つのアクションを実行するか、45のアラートを解決するために1つのアクションを実行するかですが、それでも24のアラートを最初に修正するよう指示しています。なぜでしょうか？24のアラートがより重要だからです。コンテキストを理解し、以前に言及したさまざまな属性のために、より重要である可能性があることを理解しているため、これを最初に修正すべきなのです。
7.3. IAMロールの権限修正
Bar Schwartz：最後の例をお見せしましょう。この最後の例はIAMに関するものです。この場合、IAMロールがあり、再び特権昇格に関連する24のアラートがあります。このIAMロールも複数のEC2インスタンス間で再利用されています。つまり、同一のIAMロールが複数のEC2インスタンスで使用されています。そのため、多くの異なる問題が見つかりました。
ここにもう一つの攻撃パスがあります。この場合、インターネットに公開されているEC2インスタンスがあります。しかし、この場合の主な問題は、このEC2インスタンスに接続されているこの一つのIAMロールです。このIAMロールにより、リスクのある権限の組み合わせが可能になっています。この例では、IAM PassRoleとIAM SageMakerという組み合わせのIAM権限があり、これらが一緒になると、より多くの権限を取得したり、特権昇格のリスクを持つ可能性があります。
このロールはクラウド環境の他の多くのエリアでも再利用されています。一部は異なる攻撃パスにあり、一部はここに見られるように、完全に異なる攻撃パスにあります。あるいは、IAMロール自体の設定ミスである場合もあります。しかし、このIAMロールだけを修正すれば、24のアラートが一度に解決されます。
アクションプラン以前は、24の異なるアクションを実行する必要がありました。アクションプランがあれば、「このアクションを一つ実行すれば、24の問題が一度に解決される」と伝えることができます。ここでは、このようなことを行い、基本的に適切な修復ステップを提供するために、Precision AIのメカニズムを使用しています。
最後に例を挙げましょう。一つの攻撃パスで、このロールの権限AとBを削除する必要があるとします。そして別の攻撃パスがあり、同じロールに対して、この攻撃パスを解決するには権限CとDを削除する必要があります。アクションプランはこれら二つを合わせて「これは同じIAMロールであり、権限は異なりますが、一つを解決するには権限AとBを削除し、アラート二つを解決するには権限CとDを削除する必要があります。全体として、権限A、B、C、Dを削除する必要があります」と言います。
これは非常に単純化したアプローチと例ですが、同じ資産が原因で異なる問題が発生し、修正方法も異なる場合に、AIと生成AIを活用して、リスクを排除するために取るべき完全なステップリストを得るために、すべてを一緒に考慮しています。
8. EchoStar社の事例（Geoff Filippiとの対談）
8.1. EchoStar社のクラウド環境と規模
Bar Schwartz：それでは、Geoffをステージにお招きしましょう。GeoffはEchoStarのプリンシパルセキュリティアーキテクトで、Prisma Cloudと私が今お見せしたことについて少し話し合いたいと思います。Geoff、ようこそ。
Geoff Filippi：ありがとう、Bar。
Bar Schwartz：まずは自己紹介と会社での役割について教えていただけますか？
Geoff Filippi：もちろん。私はGeoff Filippiで、EchoStarのプリンシパルセキュリティアーキテクトを務めています。当社にはいくつかの事業があり、おそらく皆さんご存知のものもあるでしょう。Dish Networkは有料テレビ会社、Sling TVはストリーミング会社です。また、衛星事業のHughes、家庭での設置サービスを行うOnTech、そしてBoost傘下の5Gセルラーネットワークも運営しています。BoostはクラウドネイティブでAWS上に構築されています。AWS上に構築されたものです。これらが私たちが顧客に提供しているサービスです。
Bar Schwartz：素晴らしいですね。クラウドの利用について、セキュリティや他の側面に触れる前に、もう少し教えていただけますか？環境はどのようになっていて、顧客向けにどのようなワークロードや規模で運用されているのでしょうか？
Geoff Filippi：私たちの歴史は、Slingというクラウドネイティブなストリーミングプラットフォームから始まりました。AWSで構築され、現在も稼働しています。それから年々追加してきました。ここ数年では、クラウド内に5Gネットワークを構築しました。AWSのクラウドネイティブです。また、お話した他の事業ラインもクラウドにあります。私たちは大規模なAWSのフットプリントを持ち、1,000以上のAWSアカウント、複数のコントロールタワーを運用しています。
8.2. クラウドセキュリティの独自の課題
Bar Schwartz：ワークフローについてもう少し教えてください。エンジニアがテンプレートやICとコードに取り組む方法、DevOpsとの連携、セキュリティエンジニアとの連携などについてはどうですか？組織内ではどのように進められていますか？
Geoff Filippi：私たちには何千人もの開発者、何百ものチームがあります。彼らは異なる事業ラインのために開発を行っており、一部は多くの自動化、TerraformやCloudFormationを使用しています。一部はコンソールに行って手動で作業を行うこともあります。
通常のアジャイル開発があり、人々が製品アイデアや製品機能を思いつき、それをキューに入れています。ここ数年、DevOpsパイプラインにDevSecOpsを追加してきました。つまり、人々のコードをスキャンし、発見事項を取得して、先ほど話した優先順位付け戦略について話し合う能力です。
Bar Schwartz：完璧ですね。クラウドセキュリティとそこで行っていることについて触れる前に、一般的にセキュリティについてはかなり経験がおありだと思いますが、クラウドセキュリティが従来のセキュリティと異なる理由は何だと思いますか？何が特徴的なのでしょうか？
Geoff Filippi：似ている点と異なる点があります。似ている点は、コードをどこに展開するかに関わらず、管理すべきコードがあり、コードのセキュリティ問題を管理する必要があるということです。異なる点は、クラウドではより多くの可視性があることです。すべてにAPIがあり、それらのAPIを呼び出して何かが誤設定されているかどうかを教えてくれる製品を統合するのが簡単です。
オンプレミスではちょっと違います。私たちはハイブリッド環境なので、両方を持っています。オンプレミスではより多くのレガシーがあり、資産追跡を維持する能力に依存します。対してクラウドでは、すべての資産が追跡されています。すべてが追跡され、課金されています。アマゾンでは必要な資産を取得するためのコールをするだけです。
ある意味では簡単ですが、より分散しています。オンプレミスでは、データセンターチームがあり、機器のラッキングを担当しています。クラウドでは、非常に分散したアクセスを提供しています。多くのチームがクラウド資産を作成できます。そのため、プロセスをコントロール下に置けるかどうかがポイントです。私たちの持つすべての異なる環境でです。
8.3. セキュリティエンジニアの日常と課題
Bar Schwartz：クラウドのセキュリティエンジニアの日常はどのようなものですか？重要なことは何ですか？大きなプロジェクトや大きな目標に取り組んでいるのか、それとも積極的にリスクを見つけようとしているのか、どのような感じですか？
Geoff Filippi：私たちにはセキュリティエンジニアリングにおいて異なるチームがあります。DevSecOpsとSDLCチームがあり、コードの問題に取り組んでいます。このチームは一般的な問題の修正プロセス開発において非常に役立っています。彼らは規模の大きい問題を修正するのが非常に上手です。あるチームはコードベースに20,000の脆弱性があるかもしれません。彼らはそれを処理できます。簡単ではありませんが、彼らはその処理方法を見つけました。後でそれについて話すことができます。
他のチームはクラウドの設定ミスを調査しています。彼らが多くの場合行っていることは、誰かが「アクセスが機能していない、IAM権限を修正してください」と言った時に対応することです。そのためこのチームが作業負荷に追いつき、さらに問題を積極的に探すのは非常に難しいのです。私たちにはセキュリティエンジニアリングを行うさまざまなチームがあり、彼らが過ごす日常はそのようなものです。
Bar Schwartz：完璧です。私はサプライヤー側で物事を見ていますが、皆さんの生活を少し楽にしようとしています。理解を深めるために教えていただきたいのですが、これらのソリューション、CNAPPの前、クラウドの前はどうでしたか？どのように対処していましたか？クラウド環境でリスクや問題を見つける方法はどうでしたか？それを助けるようなソリューションがなかった時は？
8.4. CNAPPソリューション導入前後の比較
Geoff Filippi：私たちがかなり前にAmazonのクラウドを始めた頃、これらのソリューションはありませんでした。最善を尽くすしかなく、本当にクラウドのセキュリティを知っているエンジニアが1人か2人しかいませんでした。彼らはいつも追いつくのに必死で、「このチームは何をしているんだろう？彼らが何をしているのかもっと知るにはどうすればいいだろう？」と考えていました。
現在可能な一部のネイティブソリューションさえもありませんでした。それはほとんど宝探しのようでした。「セキュリティの問題はどこにあるのか？どこで見つけられるのか？」といった具合です。その後、Evident.ioのようなソリューションを構築し始めました。これは現在Prismaの一部です。少なくともクラウドの問題が何であるか、つまり発見事項が何であるかを見ることができました。これはSecurity HubやGuardDutyなどのネイティブソリューションと似ています。
これらは役立ちます。少なくとも可視性を持つことができますが、可視性があっても実際には何も修正されません。それを超えていく必要があります。また、私たちのSDLCにおける旅、DevSecOpsについても同様です。当初は、プロジェクトがテスト段階にあるときにQAのチームがスキャンするだけでした。彼らは基本的に動的ペネトレーションテストを行い、何を壊せるかを見つけようとしましたが、それはかなり遅い段階でした。これは本番に行こうとしているものについての話です。
見つかったものを修正する時間はほとんどなく、そうしないと製品の本番への移行がブロックされてしまいます。少し早送りすると、左シフトの完全なSDLC、開発者のエディタ内でコードをスキャンする能力を追加しました。その場で修正できるのです。私はこれがあるべき方向だと思います。
しかし、すべてを開発者に任せることもできません。パイプラインにも何かを入れる必要があります。パイプラインが実行されコードが構築される時にスキャンし、問題があればデプロイメントをブロックすることもできます。クラウドも同様です。より多くの可視性を持つようになった今、その可視性で何をすべきでしょうか？実際に問題を修正するにはどうすればいいでしょうか？それが私たちが話している旅であり、Palo Altoが向かっている方向と似ています。
私はただチームにスプレッドシートを与えて、そこに20,000の発見事項があると言うことはできません。彼らは対応の仕方を知りません。優先順位の付け方を知りません。そこで、アクションプランで見られるものと非常に似たことをやっています。優先順位付けを行い、実際の脆弱性を分析し、修正チームを見つけ、彼らの視点から分析します。
修正チームに今アプローチするとき、具体的な計画を持って行きたいのです。「リスクを最も減らすために修正すべき3つのことがこれです」と。そしてそれは脆弱性だけに基づくものではありません。私たちが見ているのは、脆弱性を修正するために何をする必要があるかということです。それは他の脆弱性と共通の修正でしょうか？多くの場合、OSのアップグレードなどであれば、それをするだけで脆弱性はすべて解決します。すべてではないにしても、大部分は解決します。それは一つのアクションで可能です。
また、この脆弱性があるかもしれないが、複数のプロジェクトにあるというケースも考えられます。同じ脆弱性をすべてのプロジェクトで修正しましょう。これは開発チームにとって非常に効率的です。彼らは同じテンプレートやスケルトンを使用してコードを生成しているかもしれないからです。「あなたにしてほしい修正はこれです。Log4jを更新してほしい」と言えば、それはスプリングブートの更新を意味するかもしれません。私たちがしているのは、チームと協力して彼らに適した解決策を見つけることです。スプリングブートの更新が、私たちが見ている脆弱性すべてを解決する可能性があります。
8.5. コードセキュリティとパイプライン統合の重要性
Bar Schwartz：コードが非常に重要だという点について、2つの非常に重要なことをコメントしたいと思います。パブリッククラウドについて考えるとき、最初に考えるのはおそらくAWS環境、インフラストラクチャ自体、そしてランタイムも含めて、ワークロード、仮想マシン、コンテナ、サーバーレスの保護でしょう。
しかし、多くの顧客と協力する中で見えてくるのは、コードが非常に重要だということです。なぜなら、結局のところ、本番環境で何かを見つけた場合、あなたが言及したように、それから戻って適切なチームを見つけ、優先順位付けを手伝い、実際に修正していることを確認し、そして再デプロイして問題が実際に解決されたことを検証するまでには、非常に時間がかかるからです。最初から本番環境に問題が入らないようにできれば、多くの時間を節約できます。そしてこれはコード自体を見て、パイプラインの早い段階で物事をブロックすることでのみ可能です。
Geoff Filippi：その通りです。コードセキュリティは根本的なものだと思います。なぜなら、クラウドで実行されているすべてはあなたが書いているソフトウェアに基づいているからです。そしてその多くはライブラリであり、チーム自身が開発するコードは氷山の一角に過ぎません。しかし氷山全体は、取り込んでいるすべてのライブラリと依存関係です。
コードの良い点は、誰が書いたのか、どのチームか分かることです。コミットの各行にはそれを担当した人がソース管理に記録されています。コードでは、修正すべき人を素早く突き止め、その人をすぐに関与させ、ワークフローを理解し、「何を伝える必要があるか、何を共有する必要があるか」を理解して、コードを修正できるようにすることができます。これは効率的な方法で行う必要があります。
開発者は貴重なリソースであり、たくさんいたとしても、彼らは忙しく、無駄にする時間はありません。セキュリティ作業をしているとき、それはビジネスのために彼らにしてほしい他のことをする時間がないということです。だから開発者の時間に対して非常に効率的かつ効果的でなければなりません。
それは私たちにとって、ワークフローに入ることを意味します。スプリントスケジュールはいつですか？私たちのために最も早く完了できるようにスプリントにいつこれを入れてほしいですか？そして努力を組み合わせること、つまりすべてを集約して一つのアクションにまとめることです。「一つのことだけを修正してください」というように。スプリングブートのアップグレードであれば、それが私たちが見ているすべてのもの、すべての重大な問題を修正するなら、それをしてください。それが人々にしてほしい主なことです。
8.6. 優先順位付けと修復の効率化
Bar Schwartz：あなたが言及した優先順位付けの製品も非常に興味深いです。多くの顧客から見られる点として、スプレッドシートでの作業、物事の相関付け、リスクの理解など、多くの手作業があります。AIについてこの会議でたくさん話していることを考えると、誰かが私たちのためにこの作業をするだけで、適切な優先順位付けを行ってくれるのが理にかなっているでしょう。
Geoff Filippi：私たちが見ていることの多くは自動化できると思いますが、その段階に到達するには多くの手作業が必要です。すべてのチームがどこにいるのか、あなたのビジネスを学び、これを修正するために誰と話す必要があるのかを知ることなど。例えば、ロードバランサーに問題があるかもしれません。過去には開発チームに行って「TLSバージョンを修正してくれませんか？」と言ったでしょう。彼らはTLSバージョンを修正しません。それは彼らのすることではありません。
タグ付けや他の技術を使って、すべての所有者を把握できるようにする能力、つまりシステムがそれを動的に理解できるようにすることで、最初から正しいチームに物事を割り当てることができるようになります。チーム間でバウンスさせるのではなく。ここには自動化の大きな約束があると思います。
私たちが手動で行っていることをもう行う必要がないような能力。優先順位付けのように。すべての修正を一つの修正に関連付けるようなこと。手作業を減らすための大きな可能性がそこにあります。そして戦略、それらの修正をチケット管理システムを通じてチームに合わせること、「これがセキュリティから最初に取り組んでほしいこと、これが2番目、これが3番目です。適切に優先順位を付けてください。あなたのスプリントに入れてください」と言えるようにすることです。これが問題を解決する方法であり、間違いなくAIと自動化がそれをより簡単にする大きな機会があります。それほど複雑ではありませんが、量が圧倒的なのです。いくつかのルールや基本的なガイドライン、あるいは自動化コードがあれば、これらの一部を構築することができると思います。それが私たちが探しているものです。
8.7. アクションプランの価値と開発者への影響
Bar Schwartz：これを共有してくださってありがとうございます。私たちの顧客全体で見られるものを確認するのは本当に素晴らしいことです。この手作業、優先順位付けの必要性、最も影響のあることに取り組むことの必要性などです。これはまさに私たちがアクションプランで考えていたことです。アクションプランでは、物事をグループ化して「この修正をすれば、小さな影響ではなく、これだけの大きな影響がある」と基本的に伝えることで、両方の目標を達成しようとしています。また、一部は自動化されているかもしれない、所有者を見つけるなどのアクションを取る能力もあります。
これは単純かもしれません。特定のリポジトリからのものであれば、おそらくこのチームになるでしょう。特定のタグがあれば、このチームになるでしょう。おそらくこれらのことは自動化できるでしょう。そして最後の部分は、どのように修正するかです。あなたが言ったように、異なる種類の修正を使用しており、一部はコードで修正することを好みます。これが正しい方法だと信じています。ソースに行って、正しいテンプレート、インフラストラクチャ・アズ・コードのテンプレートを修正するか、あなたの組織に意味のあると思われる他の種類の自動化を実行してください。
これを共有してくださってありがとうございます。アクションプランと私たちが構築しているものについて考えると、時間の節約が明らかに主な目的ですが、このことについてどのような利点が見られますか？
Geoff Filippi：アクションプランがどのように進化しているかは本当に気に入っています。なぜなら私たちの戦略と一致しているからです。修正を集中させ、針を最も動かす本質的な修正に絞るという考え方です。それが私たちのいる場所であり、ツールが私たちと一緒に来るのを見るのは素晴らしいことです。なぜなら、それが実際のゲームの名前だからです。
何十万もの問題を一つずつ修正することはできません。一括変更をする必要があります。スマートなことをする必要があります。効果的なことをする必要があります。それが私たちが初期に抱えていた問題の一つです。可視性を得た後、それで何をすべきか分かりませんでした。戦略、計画を考え出す必要がありました。修正をどのように優先順位付けするか？スコアだけでは行わないでください。
スコアだけで試みて、「9.8のものをすべて修正しましょう」というようにしました。次に9.7に移動します。問題は、それらが多すぎることです。一つずつ修正していては、決して進展しません。それを統合し、ストーリーを伝え、適切なチームに届けることができる能力。彼らはいつも「なぜこれをすべきなのか？他にもやるべきことがあるのに、何が大したことなのか？」と尋ねます。
攻撃パスやブラストラディウスのようなものを使って、全体像を伝え、「これが今すぐこれをする必要がある理由です。それはより重要です」と言うことができます。時には、これはビジネスのために取り組んでいるこれらのことの一つよりも重要だと言わなければなりません。それは大きな決断です。そのため、それを言うだけの理由が必要です。
しかし規模でそれを行う能力、それが約束です。現在、私たちは手動で、スプレッドシートを使って行っています。月に約20チームを処理できます。しかし、何百ものチームがあります。月に200チームを処理できるようになりたいのです。そのためには自動化が必要です。システムは機能していますが、自動化がなければ、スケールアウトすることはできません。
Bar Schwartz：まさにアクションプランで考えていたことと、できるようにするものです。前に言及したように、以前は多くの顧客がこのCVSSスコアを取り、「このスコア以上のものはすべて修正しよう」としていました。
アクションプランでは、そのようなプロセスがあったとしても、「はい、この一つのものを修正してください。しかし、これをして、複数のことを変えたり、バージョンを上げたりすれば、この一つの非常に重要度の高いまたは重大な問題や脆弱性を解決するだけでなく、他の多くのものも解決できますよ」と言うことができます。そしてそのために既に使おうとしていた同じ時間で、複数の脆弱性を解決できるのです。
Geoff Filippi：それは本当に強力です。なぜなら、それは私たちが最終的に学んだことだからです。ただ脆弱性を見るのではなく、修正を見ています。何が最も重要度の高い脆弱性を修正するのか、そして何が他にも修正されるのか？共通の修正を持つすべてのものを見ると、そのグループ内で優先順位を付けることができます。共通の修正を持つそのグループが、どの修正を追求したいかを理解するのに役立ちます。
私は、セキュリティチームはセキュリティチームの視点から見ていると思いますが、物事を修正するためには、テーブルを回転させて修正チームの視点から見る必要があります。彼らにとっての労力のレベルは何か？彼らが最も影響を与えるために何ができるか？あなたは彼らにLog4jを修正するように言うかもしれませんが、あなたが言ったように、間違ったバージョンを持つイメージがあるかもしれません。そしてイメージを修正すれば、Log4jプラス他の多くのものを修正することになります。だからチームにそうさせましょう。彼らと会話をすれば、彼らは「Log4jを修正するには実際に何をすればいいのか？」と言うかもしれません。POMファイルをどう変更するかなどを教えるかもしれません。しかし彼らが「実は、スプリングブートのアップグレードをする予定だった。それをするだけでこれらすべてが修正されるのではないか」と言うなら、その通りです。
9. クラウドセキュリティの将来展望
9.1. 自動化の可能性
Bar Schwartz：では、これらのアクションプランを活用する過程にありますが、この新しい自由時間をどのように使いますか？
Geoff Filippi：セキュリティで自由時間があるかどうかわかりませんね。主なことは、同じ量の時間（それは多いですが）を費やして、それからより多くの成果を得ることだと思います。もう一つは、開発者により多くの時間を返せるということです。これは私たちが非常に高く評価されていることの一つですが、すべての異なる種類の問題についてピンポイントで開発者に連絡するのではなく、「すべての脆弱性を修正するように言うのではなく、この一つの修正をするように言います」ということです。
これは基本的に、コードの一部の脆弱性を修正するのと同じくらいの作業量です。しかし、同じ労力レベルで何百回も実行できます。大きな絵を見ると、開発者はビジネスのための機能開発により多くの時間を持ち、より多くのものを出荷することができ、それでいて依然としてより安全なコードを実行しています。また、コードが実行されるインフラストラクチャを担当するチームも、より安全なインフラストラクチャを持ち、他のことをする時間をより多く持っています。セキュリティチームは常に完全に忙しいままでしょうが、成果としては会社のリソースをより少なく使いながら、より良いセキュリティを持つことになります。
9.2. リソース効率と開発者時間の最適化
Bar Schwartz：開発者にとって、コンテキストスイッチは非常に重要な何かであると思います。一つのIAMロールに行って1つから3つ、4つのことを修正するよう伝えることができれば、彼らはそのロールを理解し、誰がそれを使用しているか、どのような影響があるのかを理解する必要があります。彼らが実際の修正以外で行っていることがたくさんあり、もし一つの問題でロールに取り組み、そして1週間後に同じロールの別の問題に取り組む必要があるなら、このコンテキストスイッチ全体を節約しているのです。これはもう一つの非常に強力なことです。
Geoff Filippi：そうですね、相関関係と集約は本当に開発者がタスクを続けるのに役立ち、あちこち切り替える必要がありません。スプリングアップデートを100回行うのは大したことではないですが、100の異なる問題を解決するのは大きな違いです。
例えば、チームに「50のマイクロサービスがあり、各マイクロサービスでスプリングブートをアップグレードする必要がある」と伝える場合、いくつかやれば、残りはそれほど難しくありません。そして彼らは同じ精神状態にいます。しかし「多くの異なる問題があり、それらはあちこちにあり、その一部はあなたのチームのものでさえありません」と言うと、彼らは調査、調査、調査する必要があります。一度調査すれば、一度だけやりたいものです。
9.3. コンテキスト切り替えコストの削減
Bar Schwartz：完璧です。他に観客と共有したいことはありますか？
Geoff Filippi：脆弱性は非常に難しい作業であり、これらのものを修正するのは難しいですが、それをはるかに簡単にし、はるかに生産的にする方法があります。チームが苦労しているのを見るもう一つのことは、何をすべきか分からないということです。だから彼らは何もしません。彼らは多くの調査をしますが、何も修正していません。そして私たちの脆弱性プログラムで持っていた課題の一つは、「物事を修正し始めて、リスクを減らさなければならない。それから反復できる」ということです。リスクが減少するプロセスが必要で、それから反復できます。
Bar Schwartz：これで本セッションを終了したいと思います。今日参加してくださってありがとうございました。