LLMのセキュリティ：LLMアプリケーションのOWASPトップ10とSplunk製品

AIがもたらす素晴らしい世界

筆者は幼い頃、映画「オズの魔法使い」を観て、悪い魔女の上に家が落ちたり、しゃべるライオンや空飛ぶサルが登場したりするお話にとてもワクワクしたことを覚えています。しかし、物語が進むにつれ、実は偉大な魔法使いがただの人間でしかなかったことがわかると、少しがっかりしました。そして、このところ爆発的な普及を見せるAI、とりわけ大規模言語モデル(LLM)に関しても、同じような感覚を覚えています。

一見すると魔法のように見えるLLMも、実際は人間が生み出した複雑なシステムに過ぎません。LLMは驚くようなことを可能にしますが、現実世界の域を出ないものであり、他のテクノロジーで何十年も行われてきたように、人が管理し、保護する必要があります。

ソフトウェア製品や食器洗い機、それに歯科治療の分野でさえ、「AIの搭載」がうたわれるようになっていますが、LLMやそのユーザーを保護するための取り組みはほとんど行われていません。その結果、LLMベースのアプリケーションが悪用され、ガードレールなしで運用される事例が、この1年で見られるようになっています。たとえば、次のような問題が実際に起こっています。

• ユーザーが自動車販売店のチャットアシスタントを誘導して、SUVをわずか1ドルで販売することに同意させた。
• 航空会社のAIチャットボットが、身内に不幸があった場合の払い戻しを実際には提供していないのにもかかわらず顧客に約束したため、訴訟に発展した。
• 大手のLLMを提供する企業のユーザーが他のユーザーのデータを見られることが判明し、大きく報道された。

LLMのような高度なツールを保護するのは不可能だとする見方もあります。しかし、こうした誤解は、一般的に認知されているLLMの複雑さとAIの急速な進歩から生じています。LLMベースのアプリケーションの多くが、セキュリティをほとんど考慮されずに導入されているため、この誤解を払拭することが極めて重要です。

LLMは高度な機能を備えていますが、サイバーセキュリティの標準的な原則と手法を使用すれば、LLMを保護できます。また、LLMならではの脆弱性と脅威の侵入経路を理解することで、固い防御を確立できます。

このブログでは、LLMに対する脅威を検証するとともに、「OWASPトップ10」のフレームワークとSplunk製品を使用して、LLMベースのアプリケーションとそのユーザーの保護を強化するための例をいくつかご紹介します。

LLMを脅かす現時点での主な脅威

LLMに対する脅威の特徴を定義したフレームワークを探し求める中で見つけた最適なフレームワークが、「OWASP Top 10 for Large Language Model Applications (LLMアプリケーションのOWASPトップ10)」でした。

ご存じない方のために説明すると、OWASPはOpen Worldwide Application Security Projectの略で、「安全ではないソフトウェアをこれ以上作らない」という、シンプルながらも壮大なビジョンを掲げて活動しているコミュニティです。OWASPで最も有名なプロジェクトは、Webアプリケーションのセキュリティに焦点を当てた「OWASPトップ10」で、20年以上前から公開されています。

「LLMアプリケーションのOWASPトップ10」フレームワークは、最初に発表されたOWASPトップ10を基に構築されたもので、以下に関する明確なガイダンスを提供します。

• LLM内の脆弱性
• アプリケーションフロー内でその脆弱性が存在する場所
• 脆弱性を緩和する方法に関する推奨事項

OWASPが定義した、LLMアプリケーションに対する脅威のトップ10は以下のとおりです。

データの収集方法

脅威検出の検証を進めるにあたり、次々に登場する各LLMを直接操作するのではなく、最も効果を得られそうな領域に調査対象を絞ってプロンプトとその回答を収集しました。プロンプトとはLLMに指示するための入力であり、回答とはLLMがその入力に対して返す出力です。

LLMに張り付いて作業しなくても、プロンプトとその回答を簡単に取得して、分析に利用できました。

実際にどのような手法をとったかというと、それはログの収集です。LLMベースのアプリケーション(シンプルなチャットインターフェイス)をインストルメントし、すべてのプロンプト、その回答、他の関心のある項目(トークンの使用状況や遅延など)をログに記録してから、Splunk OpenTelemetry Collector (OTel)を使ってSplunkに取り込みました。一般的に使用されているユニバーサルフォワーダーではなくOpenTelemetry Collectorを使用したのは、LLMベースのアプリケーションスタックの一部としてメトリクスとトレースを収集したいと考えたからです。

フロントエンドシステムは自社で構築し、そのときに関連するログやメトリクスをOpenTelemetry Collectorのjournaldレシーバーを使用して収集できるように構築しました。そして、組み込みのHEC (HTTP Event Collector)エクスポーターを介して、Splunkインスタンスにデータを送信します。バックエンドのLLMサービス(llama-cpp-python)については、OpenTelemetry自動インストルメンテーションパッケージを使用して実行し、その際にテレメトリを収集しました。

LLMに対する脅威の検出

OWASPトップ10のうち、以下の5項目については、プロンプトとLLMの回答を使用するだけで対処できることがわかりました。

• LLM01：プロンプトインジェクション
• LLM02：安全でない出力処理
• LLM04：モデルへのサービス拒否(DoS)攻撃
• LLM06：機密情報の開示
• LLM10：モデルの窃盗

ここでの検証はまだ理論的な段階にあります。嘘をつく必要はありませんので正直に申し上げると、私たちがこれらの脅威を検出するために開発した手法は、私たちのラボでは機能しますが、皆さんの環境で使用するには一定の調整が必要になると思います。

加えて、どのベンダーの製品であっても、市販の検出ツールのほとんどで、環境に合わせた調整が必要になるはずです(言い訳めいた話をするのは、このあたりでやめておきましょう)。

LLM01：プロンプトインジェクション

プロンプトインジェクションを検出するには、相互に関連する多くの要素を考慮する必要があります。プロンプトインジェクション攻撃では、不正なプロンプトを入力してLLMを不正に操作し、LLMの意図しない出力を引き起こします。こういった悪質なプロンプトを作成する方法は多岐にわたるため、シンプルな検出ルールを作成して対応することは困難です。

そのため、従来のサーチ方法では十分な成果が得られない可能性があります。しかし、Splunkの機械学習と異常検出技術を活用することで、プロンプトインジェクション攻撃を示す異常なパターンを特定するモデルを構築できます。

幸いにも、Protect AI社がプロンプトインジェクション検出用モデルをすでに作成していたため、これを活用しました。ただし、公開されているどのモデルにもいえることですが、モデル自体にリスクが存在する可能性があるため、必ずデューデリジェンスを実施する必要があります。私たちの検証では、Splunkから取得したデータをこの検出モデルに渡し、その結果をSplunkに出力するJupyter Notebookを構築しました。

ほとんどのJupyter Notebookでは、最初のフェーズでさまざまなPythonライブラリをインストールしてインポートすることで、以降のコードを実行するための環境を準備できます。

フェーズ1では、Jupyter Notebookで使用するために必要なデータをSplunkから収集します。以下の画像に詳細が書かれていますが、主なポイントは、fitコマンドを使用してサーチ結果をコンテナに転送することです。

フェーズ2では、トークナイザー、モデル、分類関数を定義します。ここで、Jupyter Notebookを使って主な処理をコーディングします。

Jupyter Notebookの下部で、プロンプトインジェクションを検出するために、しきい値を高めに設定しました(1.0に近いほど一致度が高くなります)。ただ、このしきい値は誤検知の許容度に応じて簡単に調整できます。

Jupyter Notebookで最後に作成するのは、フェーズ1でSplunkから収集したデータをモデルに渡し、その結果をprompt:injectionという名前の新しいソースタイプとしてSplunkに取り込む処理です。

以下のスクリーンショットでおわかりのように、データセットの上位3つの結果はすべてプロンプトインジェクションの試行であり、モデルはこの試行を高い精度で検出しています。

LLM02：安全でない出力処理

安全でない出力処理は、LLMのユーザーとLLMベースのアプリケーションそのものに影響を及ぼす可能性があります。

• クロスサイトスクリプティング(XSS)：サニタイジングされていないLLMの回答を表示できる場合、ユーザーのブラウザーで不正な処理が実行される恐れがあります。
• SQLインジェクション(SQLi)：ユーザーが入力したプロンプトがサニタイジングされないまま処理されると、バックエンドシステムで問題が生じる可能性があります。

ここではっきりお伝えしたいことは、LLMベースのアプリケーションにも、Webアプリケーションの基本的なセキュリティ対策を実装する必要があることです。また、見逃していた脆弱性や攻撃があればすぐに対処できるように、必ず検出ルールも作成しておきましょう。

XSSとSQLiの検出では、どちらも正規表現を利用できますが、その作業はすぐに負担が高くなります。プロンプトインジェクションの例では、Jupyter Notebookを使用して、データに潜むXSSとSQLiを検出しました。これらの脅威の検出に使える公開モデルが見当たらなかったため、私たちは独自のモデルをトレーニングしました。モデルのトレーニングについて説明すると、それだけで1本のブログ記事になってしまうため、ここでは私たちが実行した手順とその結果を簡単に説明します。

XSS

XSSを検出するために、以下の複数のアルゴリズムを使用してモデルをトレーニングしました。

• ロジスティック回帰
• ランダムフォレスト
• 勾配ブースティング
• サポートベクターマシン

公開されている複数のデータセット(悪質なデータを含むデータセットなのでリンクは張っていません)を組み合わせて使ってトレーニングすることで、XSSの検出に最適なアルゴリズムを決定しました。

以下に示す画像は混同行列と呼ばれるもので、真陽性や偽陽性などをまとめた表です。数字の1は実際のXSSデータのラベル、0は良性データのラベルです。色が濃いマスの数値が大きく、色が薄いマスの数値が小さいと、良好な状態と判断できます。次に、最終スコアであるF1スコアを計算し、モデルの精度を評価するのに役立つ平均スコアを算出します。

ロジスティック回帰のF1スコアは 0.9898 で非常に良好な結果となりました。

ランダムフォレストは F1スコアが0.9934 になり、ロジスティック回帰よりもやや優れた結果となりました。

勾配ブースティングは F1スコアが0.9855 となり、他と比べてわずかに低い結果となりました。

サポートベクターマシンも、F1スコアが0.9939と非常に良好な結果となりました。

すべてのアルゴリズムで、XSSの検出に使用できると考えられるほど良好なF1スコアが得られました。したがって、今回のユースケースに最適なアルゴリズムを決定するには、新たな要素を検討する必要があります。そこで私たちは、33,426件のイベントをSplunkで処理して、XSSの検出を試みました。各アルゴリズムでその処理にかかった時間は以下のとおりです。

ロジスティック回帰と勾配ブースティングの処理時間はほぼ同じで、ランダムフォレストも大きな差はありませんでした。一方、サポートベクターマシンは、イベントの処理に2倍近い時間がかかっていました。したがって、サポートベクターマシンのアルゴリズムは、精度がかなり高くない限り、現時点ではおそらく最適なアルゴリズムとは言えないでしょう。

では、残りの3つのアルゴリズムを他の要因に基づいて調べて、最適なアルゴリズムを絞り込みます。

以下は、特定の回答がXSSによるものであったかどうかを各アルゴリズムで判定した結果の抜粋です。以下の3つのXSSによる回答すべてを悪質なものと正しく検出したアルゴリズムは、ロジスティック回帰のみでした。

ここでは、XSSの検出に最適なアルゴリズムを決定する方法をご紹介しました。今回はロジスティック回帰が最も良好な成果を上げましたが、時間の経過とともに出力の精度が低下することがあるため、定期的にテストを行って検証することが重要です。

SQLインジェクション

SQLインジェクションでは、他の多くのセキュリティ関連の機械学習モデルで成果を上げた実績を持つ既存モデルDistilBERTをファインチューニングすることにしました。XSSの例と同じく、トレーニング手順をすべて説明するのではなく、いくつかの重要なポイントをご紹介します。

DistilBERTは、BERT (Bidirectional Encoder Representations from Transformers)モデルの小型バージョンで、スピードと効率性に優れています。また、ここで言う「Transformer」は、変形ロボットの「トランスフォーマー」ではなく、ニューラルネットワークを指します。詳しくは、こちらのNVIDIAの解説ページをご覧ください。

Transformerを使用すると、トレーニングと検出をGPUで高速化できます。AIワークロードにGPUを使用するメリットについては、こちらのNVIDIAのブログ記事で説明されています。

モデルのトレーニングでは一般的に、エポックを何回か繰り返し実行します。各エポックでは、データセットをいくつかのグループに分割して学習することで、以下のメリットを得られます。

• 精度の向上：エポックを何回か実行することで、モデルがデータの基本パターンをより効果的に学習できます。
• 過学習と学習不足の検出：各エポックの後に検証用のデータセットでモデルを評価すると、過学習(モデルのパフォーマンスがトレーニングデータでは高いのに検証用データでは低い状態)と学習不足(モデルのパフォーマンスがトレーニングデータと検証用データの両方で低い状態)を検出できます。
• モデルのチューニング：エポック単位でトレーニングすると、学習率、バッチサイズ、エポック数などのハイパーパラメーターを監視して調整し、モデルのパフォーマンスを改善できます。

私たちのコードには、早期終了と呼ばれる機能が実装されています。早期終了は、検証用データセットでモデルのパフォーマンスが向上しなくなったときにトレーニングを停止するために用いられる手法で、過学習を防ぐのに役立ちます。

DistilBERTをファインチューニングすると、SQLi検出用モデルの F1スコアは0.9946 となりました。これは極めて精度が高いことを示しています。そのため、十分に自信をもって、このモデルを使って検出テストを行えます。

このモデルを、SQLインジェクションを含む公開データセット(悪質なデータがこちらのデータセットにも含まれているため、リンクは張っていません)で使用したところ、出力に組み込まれたSQLインジェクションを正確に検出できることがわかりました。

LLM04：モデルへのサービス拒否(DoS)攻撃

DoS攻撃は、Splunkの標準的な技術で検出できる脅威です。プロンプトと回答のセッションごとのトークン使用状況、これらのトークンを使用したユーザー、トランザクションに関連した遅延をログに記録します。これにより、システムを悪用して大量のリソースを消費させようとしている可能性を示す外れ値を検出できます。

検証の結果、以下のようなさまざまな方法でリソースを大量に消費し、サービスの品質を低下させることができるとわかりました。

• トークンの制限値に達するまでリクエストを継続する(プロンプトごとのトークンの使用率が高くなる)。
• 入力を複雑にし、1秒あたりのトークン数を減らすことで、推論速度が遅くなるようなクエリを作成する。
• 各バックエンドがサポートできるノードごとのリクエスト数に限界があることを利用して、多数のプロンプトでタスクキューシステムに過剰な負荷をかける。

上の例のクエリは実装に合わせて使い分けて実行されますが、Splunk Observabilityでこういったテレメトリを収集すれば、APMのディテクターを使用して各メトリクスの適切なベースラインを設定して異常を検出できます。

LLM06：機密情報の開示

機密情報の開示を検出する検証では、Microsoft社が以前に開発したPresidioというSDKを活用しました。Presidioは、個人情報(PII)を識別して匿名化できる強力なツールです。ここでもJupyter Notebookを使用し、入力したプロンプトとその回答をPresidioで処理して、あらゆるタイプのPIIデータを特定しました。

しかし、上の画像で示されているように、Presidioは同じ番号を複数の異なるタイプのPIIとして識別しています。その解決策として、まず、PresidioがPIIとしてマークしたデータをすべて取得し、コンテキストを(前後に50文字ずつ)追加して別のLLMに送信して、PIIデータのタイプをより正確にラベル付けしました。

LLM10：モデルの窃盗

モデルの窃盗については、まだ調査中です。過去の研究から、この脅威はプロンプトと回答の分析だけで検出できると私たちは考えています。当面の課題は、研究するのに十分な規模のデータセットを見つけ出すことです。

とはいえ、XSS、SQLi、PIIデータの検出と同じ方法を使っても、モデルの窃盗を極めて高い精度で検出できると考えます。

まとめ

「LLMアプリケーションのOWASPトップ10」に準じた私たちの脅威分析の取り組みは、お客様自身のLLMベースのアプリケーション保護を強化するための指針となるでしょう。LLMを取り巻く状況は過去にないほど急速に変化しているため、いずれ新たな脅威に直面することは間違いありません。しかし、そのような脅威に対抗するための新しい防御策も登場するはずです。

私たちは、Splunk脅威調査チーム(STRT)のメンバーと共同で、このような脅威を本番環境で検出できる機能の開発に取り組んでいるところです。それまでの間は、独自のLLMベースアプリケーションの保護を強化するための土台として、私たちの研究やモデル開発の例をご活用ください。