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構成を追跡するツール、アイデンティティガバナンスを管理するツール、脆弱性管理を担当するツール。

各ツールは、それぞれのピースを示している。ただし、ピースがどのように接続されているかは示していない。
Gartnerによると、組織は現在、平均して45以上のセキュリティツールを使用している。にもかかわらず、この大量の投資にもかかわらず、攻撃者はこれらのドメインを横断するミスコンフィギュレーションをチェーンして攻撃に成功している。これは、単一のツールが完全な攻撃パスを視覚化できないためである。

攻撃者はあなたのAIモデルに重大な脆弱性を見つける必要はない。ただチェーンを見つけるだけでよい。もしかしたら、AIサービスにアタッチされたミスコンフィギュレーションされたIAMロールがS3バケットへのパーミッションを持っており、S3バケットにはSaaSアプリケーションの資格情報が含まれており、SaaSアプリケーションにはあなたの生産環境への管理アクセス権があるかもしれない。

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

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

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

AIモデルがセキュアかどうかだけを問うのではなく、セキュリティチームは、攻撃者がAIサービスアカウントを妥協した場合に何に到達できるかを理解する必要がある。クラウド、SaaS、アイデンティティシステムのミスコンフィギュレーションがチェーンを形成する方法を視覚化する必要がある。AI統合が実時間に攻撃面をどのように変更するかを理解する必要がある。実際の攻撃可能性に基づいてリスクを優先する必要がある。

ほとんどのセキュリティプログラムはまだ、CVSSスコアとコンプライアンスチェックリストを使用してリスクを優先順位付けしており、これらのリストは、脆弱性が実際にあなたの特定の環境で悪用できるかどうかを完全に無視している。

このギャップは、AIシステムではさらに顕著である。新しい統合は毎週追加される。パーミッションは進化する。API接続は変化する。先月の攻撃面は今日の攻撃面ではないが、あなたのセキュリティ評価はおそらく同じである。

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

実稼働環境のAIをセキュアにするには、根本的に異なるアプローチが必要であり、4つの重要な思考の転換に帰着する。

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

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

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

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

無視できない警告

AIが企業スタックのすべての層に埋め込まれるにつれて、攻撃面はセキュリティチームが手動で推論できるよりも速く拡大している。AI統合をセキュア化するペースは、追加するペースの10分の1である。

AIを孤立してセキュア化している場合、モデルを保護しているのにエコシステムを無視している場合は、すでに遅れをとっている。攻撃者はツールではなくパスを考える。個々の脆弱性を悪用するのではなく、環境全体を横断するミスコンフィギュレーションをチェーンする。

AIを成功的にセキュア化する企業は、最も多くのAIセキュリティツールを持っている企業ではなくなり、AIセキュリティは攻撃面全体のエクスポージャ管理と切り離せないことを理解している企業になるだろう。

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