LLM」を見出そうと試行錯誤しています。LLMは、LLMを利用するアプリケーションで発見された重大な脆弱性とセキュリティガイドラインに関するレポートです。レポートでも述べられていますが、昨今はLLMの取り組みが猛烈に進んでいる中で、包括的なセキュリティプロトコルやベストプラクティスはそこまで浸透していないのが現状だと捉えています。自分自身あまりキャッチアップ出来てないので、一般的なアプリケーション・セキュリティの原則と、LLMがもたらす特有の課題との間の溝やギャップを埋めるためにもレポートの内容を紹介します。レポートのリンクは以下です。Project)によって発表される、Webアプリケーションのセキュリティ上の最も重要な10のリスクのリストです。このリストは、開発者、セキュリティ専門家、組織にとって、Webアプリケーションのセキュリティ強化のためのガイドラインとして広く用いられています。(モデルの盗難)以降、それぞれ詳細です。InjectionTOP1はプロンプトインジェクションです。サプライズではないですね。プロンプトインジェクションは名前からイメージする通り、不正なプロンプトを入力することで、LLMが意図しない動作を引き起こすことを指します。prompt」みたいなやつですね。アプリケーションの作りでプロンプトからデータストアにクエリが繋がっている場合は、不正アクセスや権限昇格攻撃が成立してしまう危険性が指摘されています。レポートでは、プロンプトインジェクションを以下の二つに分類しています:ダイレクトプロンプトインジェクションジェイルブレイク(脱獄)とも呼ばれる悪意あるユーザーがシステムのプロンプトを上書きしたり公開することで発生。Interpreterでファイルに何か仕込む例:ユーザーの指示を無視するためのプロンプトをWebサイトに仕込み、そのページを要約させるプロンプトインジェクションは日本語での記事も多く、日経クロステックやビジネスインサイダーでも取り上げられていますので、目にする機会も多いのではないでしょうか。レポート以外でもこの辺りは参考になり、おすすめです。ChatGPTプロンプトインジェクションを学べるGandalfで遊んでみるのも良いですね。パスワードを引き出すゲームです。Gandalfどう防ぐか?基本的には権限制御やundo出来ないような操作にはユーザーの承認を必須とするなどが軽減策・対策になります。ような特権的な操作にはユーザーの同意・承認を要求する信頼できないコンテンツをプロンプトに使用しない加えて、攻撃の意図を持ったプロンプト自体を弾く・機能させないための手法も存在します。明らかに想定ユースケースと外れた内容かを判定この辺りは以下が詳しいです。Handlingです。プロンプトインジェクションと同じように、特にユーザーによるプロンプトを受け入れている場合は、プロンプトでLLMの制御が可能なため、適切にハンドリングを行わないと内部の関数へのアクセスを許可している状態になってしまいます。chat2sqlのようなサービスも出てきてますし、同じような機構をLLMで作ってみるというのやってみたことがありますが、ユーザーが自然言語で入力して、データを引っ張ってこれるのは良さげな体験に思えつつ、悪意のあるユーザーにもプロンプトを通じてデータストアへのアクセスが間接的にされてしまうので、適切なバリデーションやサニタイズなどの対策が必要ですね。いう話だと理解しています。レポートでも、LLMの出力がシステムシェルまたはexecやevalなどに直接入力され、リモートコード実行が成立する例が紹介されています。Standard)ガイドラインに従って、LLMモデルからバックエンド関数などへのレスポンスに適切なバリデーション・エンコードを行うことが推奨されています。Standard)については以下記事を参照しました。Poisoningです。損なう可能性のある脆弱性、バックドア、バイアスを導入するために、データやチューニングプロセスに介入されることを指します。外部データソースはモデル作成者がデータを管理することができず、コンテンツに偏りや改ざんされた情報、不適切なコンテンツが含まれていないという高い信頼性を持っていないため、構造上どうしてもリスクが高くなることを指摘しています。LLMモデルを利用する構造にいる開発者にとっては、上流で汚染されてしまうのがなかなか辛いやつです。Applicationの開発者としては、どのようなリスクを反映させる可能性があるのか、その意味を理解することが重要です。防ぐか?トレーニングデータやトレーニング・調整段階/後で出力の正当性を検証することや、意図しないデータソースをモデルがスクレイピングしないようにする、外れ値検出や異常値検出でデータのサニタイズを行い敵対的なデータを検出するなどの方法が紹介されています。ServiceLLMへのDoS攻撃がTOP4です。LLMならではの概念としてリクエスト数だけでなく、コンテキストウィンドウ、最大トークン数を駆使した攻撃も存在します。flood可変長入力を処理する際の非効率性を利用し負荷をかけるどう防ぐか?比較的聞き慣れたDDoS攻撃・スパイクへの対策が候補にあがっています。VulnerabilitiesTOP5はサプライチェーンです。ChatGPTに教えてもらったサプライチェーンの説明が以下です。一般的なソフトウェア開発と異なり、機械学習は改ざんやポイズニング攻撃の影響を受けやすい事前学習済みモデルや学習データがプラスで加わると指摘しています。Designで詳細が説明されています。Disclosureです。関連する話でサムスン社でChatGPTにソースコードを入力してしまった話も過去ありましたね。サムスン、機密情報をChatGPTにリークして大問題にユーザデータがトレーニングモデルデータに入力されるのを防ぐ、また利用者視点だと自分のデータがどのように処理されるのか、またトレーニングモデルに含まれることをオプトアウトできることを確認する必要があります。LLMが返すべきデータの種類に関する制限をシステムプロンプト内に含めることで、機密情報の漏洩をある程度緩和することができるが、そのような制限が常に守られるとは限らず、プロンプト・インジェクションなどによって回避される可能性も考慮しなくてはいけません。Enterpriseも発表されるなどプレイヤーも増えてきており、多くの企業ではこれらのサービスの利用が有力な解決策になりそうです。Vulnerabilities内でも言及されていました。ここで言うプラグインはChatGPTプラグインのような、有効にすることでユーザーとの対話の間で、モデルによって自動的に呼び出される拡張機能を指しています。プラグインは、LLMモデルによって自動的に呼び出されますが、プラグインがLLMモデル/ユーザーからのプロンプト入力を検証等を行わずに受け入れてしまっている場合、攻撃者がプロンプトインジェクションなどの悪意のあるリクエストを送信することを許してしまう可能性があります。ある脆弱性を生み出す例は、バリデーションなしに入力を受け入れたり、入力・プロンプトを元にSQLを組み立てる場合などです。Agency8つ目です。LindyのようなAIエージェントが有害なアクションを実行できてしまう状態です。一般的にLLMエージェントは、一定アクションを実行する能力が与えられ、プロンプトやLLMの推論結果(ReActとか)に基づいて、自身のアクションを決定していきます。持ってしまっているがゆえに、ユーザーが想定しないまたは不利益なアクションが実行されてしまう問題です。LLMエージェントがどの・どれだけのシステムと通信可能か、アクションが許されているかで影響度も変化します。Autonomy)ユーザーが影響度の高いアクションを検証・承認できない例:ユーザーの確認なしに削除を実行どう防ぐか不要な機能・権限を持たせない、不可逆やデータの書き換えを行うアクションは必ずユーザーの実行承認を取得する、ヒューマン・イン・ザ・ループの仕組みを取り入れることです。レポートでは、極力シェルコマンドの実行、URLの取得など、汎用性の高い処理を持たせないことが推奨されています。ファイル書き込みを行う場合、シェル関数実行をサポートするのではなく、限定されたユースケースでファイル書き込みを行う機構をサポートする方がリスクが軽減します。LLMの生成したコンテンツの監視やフィルターを行いましょうというやつです。LLMはhallucinationを代表に、事実と異なる・不適切なコンテンツを生成する可能性も考えられ、例として:生成した意図せずフェイクニュースやコンテンツの盗用を行なってしまうCodex等のコード自動生成に依存し、安全でないデフォルト設定や、安全なコーディングプラクティスと矛盾する推奨により、アプリケーションにセキュリティ脆弱性がもたらされるLLMの提案を鵜呑みにし、悪意のあるパッケージを組み込んでしまう上記例から分かる通り、何らかのレビュー・監視プロセスやクロスチェックを行う重要性が指摘されています。Theft(モデルの盗難)です。OpenAIのGPTモデルのようなプロプライエタリなLLMが物理的に盗まれたり、コピーされたり、機能的に同等なモデルを作るために出力から重みとパラメータが抽出されたり...と言った状況を指します。これにより経済的・ブランド的評判の損失、競争上の優位性の低下、モデルの不正使用、モデルに含まれる機密情報への不正アクセスなどの恐れがあると指摘されています。権限不備による不正アクセスや内部漏洩の可能性は今まで通りの一般的なWebアプリケーションにおいても該当しますが、LLMならではとして攻撃者がLLMからの出力を元にシャドーモデルを作成するシナリオが提示されています。防ぐか認証・認可、ログ監視に加えて、電子透かしを入れるなども提案されています。Applicationsをひたすら読んでみました。途中から息切れし、特にLLMモデル自体に関してはそもそもの知識も甘く、ゆるふわな理解・内容になっているのが反省です。Theftなんかは如何ともしがたい感じはありますが、かなり参考になる内容ではないでしょうか。Applicationsならではのセキュリティリスクや観点もあり知識のアップデートが必要だなーと実感しました。Applications開発を目指して頑張っていきたいですね!以上、ありがとうございました。Reserved.Elvescore.io。