AIセキュリティは壊れているのではなく、間違ったものを守っている

サイバーセキュリティ業界には、新しいテクノロジーが登場するとすぐにそれを囲む壁を築くというパターンがあります。クラウド、コンテナ、アンド今回はAIに対して同じことをしています。しかし、今回は壁を間違った場所に築いているのです。

今日の企業のセキュリティレビューに参加すると、同じ優先事項が聞かれます。AIモデルをセキュアにすること、トレーニングデータを保護すること、出力を検証すること、アンドAIパワードのコパイロットを展開すること。ベンダーは、モデルレベルのコントロールにのみ焦点を当てた「AIセキュリティ」ツールを売り出しています。ガードレール、プロンプトインジェクション防御、アンドモデルモニタリングプラットフォームなどです。

しかし、攻撃者はあなたのAI統合を他のすべてへのハイウェイとして利用しています。

見逃されている実際の攻撃対象領域

企業環境で観察される一貫したパターンは、セキュリティチームがAI開発環境のセキュア化に多大な投資をしていることを示しています。モデルアクセス制御、データガバナンスフレームワーク、MLOpsセキュリティツールなどです。これにより、AIが「ロックダウン」されているという誤った自信が生まれます。

しかし、実際の攻撃対象領域をマッピングすると、AIチャットボットがOAuthトークンを数十のSaaSプラットフォームに保持していることがわかります。APIキーには過剰なクラウドパーミッションがあり、アンドアイデンティティトラスト関係は、シンプルなプロンプトインジェクションからプロダクションインフラストラクチャへの直接パスを作成できます。モデル自体はセキュアかもしれませんが、モデルが存在するエコシステムは、多くの場合、開放されています。これはエッジケースではありません。

企業は現在、平均130以上のSaaSアプリケーションを使用しています。AI統合は、アイデンティティプロバイダー、クラウドインフラストラクチャ、データベース、アンドビジネスクリティカルシステムに及んでいます。各統合は潜在的な攻撃パスであり、アンドAPI接続は、攻撃者が積極的に探査しているトラスト境界です。

問題は、AIセキュリティツールが壊れていることではありません。問題は、個々のコンポーネントをセキュアにすることではなく、攻撃者がコンポーネント間の接続を利用していることです。

モデル中心のセキュリティが間違っている理由

現在のAIセキュリティアプローチは、現代の攻撃のしくみを根本的に誤解していることにもとづいています。AIを、データベースまたはWebアプリケーションのように保護する必要があるスタンドアローンアセットとして扱います。しかし、プロダクション環境のAIは孤立して存在しません。アイデンティティ、パーミッション、API、アンドデータフローが複雑に絡み合ったグラフの一部です。

典型的な企業AIデプロイメントを考えてみましょう。Google WorkspaceにアクセスできるAIエージェントがあります。SalesforceとAPIで接続されています。Slackと統合されています。AWS S3バケットからデータを取得しています。OktaまたはAzure ADで認証されています。ServiceNowでワークフローをトリガーしています。

従来のAIセキュリティは、モデル自体に焦点を当てています。セキュリティポスト、プロンプト検証、アウトプットセーフティです。しかし、攻撃者は統合に焦点を当てています。サービスアカウントの妥協、API操作、統合の悪用を通じて何が到達可能かを探査しています。

攻撃は、AIモデルで始まり、アンド終わりません。モデルはただのエントリーポイントです。

攻撃パスは製品境界を尊重しない

ここで、多くの組織が躓きます。各セキュリティツールは、個々のドメインの可視性を提供します。クラウドパーミッションを監視するツール、SaaS構成を追跡するツール、アイデンティティガバナンスを管理するツール、脆弱性管理を扱うツールなどです。

各ツールは、パズルの一部を示します。しかし、パズルのピースがどのように接続されているかは示しません。

ガートナーによると、組織は平均45以上のセキュリティツールを使用しています。にもかかわらず、攻撃者はこれらのドメイン全体でミスコンフィギュレーションをチェインして攻撃しています。なぜなら、単一のツールが完全な攻撃パスを可視化できないからです。

攻撃者は、AIモデルに重大な脆弱性を見つける必要はありません。ただチェインを見つける必要があります。たとえば、AIサービスにアタッチされたIAMロールが、S3バケットにパーミッションを持っており、そのバケットには、プロダクション環境に管理アクセス権を持つSaaSアプリケーションの資格情報が含まれている場合です。

各個々のミスコンフィギュレーションは、セキュリティツールで「中」または「低」に評価されるかもしれません。しかし、チェインしてみると、それは重大な脆弱性です。アンド、これは、各セキュリティドメインを個別に見ている場合、完全に不可視です。

エクスポージャ管理の必要性

これは、会話を「AIセキュリティ」から、AI統合環境の継続的な脅威エクスポージャ管理にシフトする必要がある理由です。

AIモデルがセキュアかどうかだけを問うことは不十分です。セキュリティチームは、AIサービスアカウントの妥協によって攻撃者が到達できるものを理解する必要があります。クラウド、SaaS、アンドアイデンティティシステム全体でミスコンフィギュレーションがチェインされる方法を可視化する必要があります。AI統合がリアルタイムで攻撃対象領域をどのように変更するかを理解する必要があります。アンド、実際の攻撃可能性に基づいてリスクを優先する必要があります。

多くのセキュリティプログラムは、依然としてCVSSスコアとコンプライアンスチェックリストを使用してリスクを優先しています。しかし、これらのリストは、脆弱性が実際にあなたの環境で利用可能かどうかを完全に無視しています。

AIシステムの場合、このギャップはさらに大きいです。新しい統合が毎週追加され、パーミッションは進化し、API接続は変化します。先月の攻撃対象領域は、今日の攻撃対象領域ではありません。しかし、あなたのセキュリティ評価は、まだ先月のものである可能性があります。

攻撃パスを意識したセキュリティの実像

プロダクション環境のAIをセキュアにするには、根本的に異なるアプローチが必要です。それには、4つの重要な考え方のシフトが必要です。

第一に、セキュリティドメイン全体で統一された可視性が必要です。各セキュリティツールが独自のシロで動作するのをやめましょう。クラウドセキュリティ、アイデンティティガバナンス、SaaS管理、脆弱性スキャニングツールなどは、すべて攻撃パスのパズルのピースを保持しています。これらはリアルタイムでデータを共有して、ミスコンフィギュレーションがどのようにチェインされるかを可視化する必要があります。

第二に、継続的な攻撃パスシミュレーションを採用しましょう。ペネトレーションテストまたはレッドチーム演習で攻撃可能なパスを見つけるのを待つのではなく、攻撃者が環境を通じてどのように移動できるかを継続的にテストしましょう。理論的な重大性スコアではなく、実際の利用可能性に焦点を当てましょう。

第三に、コンテキストに基づいて優先順位を付ける必要があります。S3バケットがパブリックであることだけが重大ではありません。パブリックであり、アンド資格情報を含んでおり、アンドそれらの資格情報が特権アクセスを持っており、アンドインターネットエクスポーズされたアセットから到達可能である場合に重大です。コンテキストは、個々のスコアよりも重要です。

第四に、予防的な修復に移行しましょう。SOCチームがアラートを調査している間に、貴重な対応時間を失っています。現代の防御には、インシデントが発生する前に攻撃可能なパスを閉じる能力が必要です。

無視できない警告

AIがエンタープライズスタックのすべての層に埋め込まれるにつれて、攻撃対象領域はセキュリティチームが手動で推論できるよりも速く拡大しています。AI統合は、セキュア化するよりも10倍のペースで追加されています。

AIを孤立してセキュアにすることを続ける場合、すでに後れを取っています。攻撃者はツールではなく、パスで考えています。個々の脆弱性を利用するのではなく、環境全体でミスコンフィギュレーションをチェインしています。

AIを成功裏にセキュアにする企業は、AIセキュリティツールを最も多く持っている企業ではありません。AIセキュリティは、全体の攻撃対象領域全体のエクスポージャ管理と切り離せないことを理解している企業です。

モデルセキュリティは、最低限の要件です。重要なのは、AI統合を妥協した場合に攻撃者が到達できるものを理解することです。セキュリティチームがこれを継続的に、リアルタイムで、全環境で回答できるまで、AIをセキュアにしていません。ただ、壁を建てた場所が正しいかどうかを願っているだけです。