セキュリティ・リスクを評価するための生成AIワークロードによる脅威モデリング

Pulisher : Cloud Technology Center イ・イェウン
Description : AWS環境での作業を保護するための脅威モデリングアプローチについて学ぶセッション

はじめに

最新の自動生成AI技術の進歩により、機械学習の可能性は拡大し続けていますが、それに伴うセキュリティ上の脅威を理解することは重要であり、特にAWS環境での作業を保護するために、これらのセキュリティリスクを特定し、対応するための実用的な脅威モデリングアプローチについて学ぶためにセッションに参加しました。

セッションの概要紹介

このセッションでは、仮想シナリオを設定し、生成型AIでのセキュリティ脅威モデリングを構築する方法についてお話しました。

医療企業で働いている場合、優れた革新的なAIのユースケースとして、健康データと対話する顧客向けのチャットボットを導入したとします。このチャットボットは、顧客が現在服用している薬や特定の健康情報に関する質問に回答し、例えば、心臓発作を予防するために1年前からプロフェノールを服用し始めたという情報を提供することができます。これにより、顧客はパーソナライズされたヘルスケアを受けるだけでなく、医療企業は価値の高いサービスを提供することができます。

このセッションでは、Generative AIに固有のリスクだけでなく、現在の優先順位を特定し、軽減すべきリスクへのアプローチについて説明します。

また、一般的にGenerative AIのセキュリティを開始するためにどのようなステップを踏むべきかについても説明します。具体的な質問への回答と脅威モデルに焦点を当てた説明により、セッションでは、スライドの情報を安心して理解できるよう、段階的に説明します。

このようなプロセスに従うことで、構築しているアプリケーションの実用的な脅威モデルを構築するのに役立ちます。

まず、現在何を構築しているのか、なぜそれを構築しているのかを簡単に説明します。 次に、そのプロジェクトをどのように構築しているのか、どのような問題が発生する可能性があるのか、導入された脅威がプロジェクトに基づいているかどうかを検討します。

発生する可能性のある脅威を理解したら、それに対する対応策と緩和策を構築します。最後に、脅威がどのように緩和されたかを確認し、全体的な脅威モデリングが行われたかどうかを評価します。このように構成された脅威モデルは、アプリケーションセキュリティ決定の技術的根拠として機能します。

理想的には、会話の一部をシナリオと一緒に具体的に扱うべきですが、このセッションでは、簡単なユーザーに対するデータフローを把握するスピーカー間の会話から始めました。

どのような内容のリクエストと回答ができるのか(チャットボットの応答内容、データフロー、S3バケットの内容-HTML/ファイル/ロゴ)とデータフローに関するダイアグラムの内容(API、データベース、言語モデルなどの様々なコンポーネントを使用してデータフローが行われ、ユーザーの入力を受けてデータベースにクエリを送信し、データベースへの安全なアプローチ(セキュリティ属性を遵守し、Cognitoを使用して認証および許可を受けたユーザーだけがデータベースにアクセスする)などについての質疑を行いました。

スピーカー間の会話の目標として、製品の技術的な側面を理解するためにアーキテクチャ図を活用し、これにより、どのように動作するのかなど、上記の6つについて確認しました。

上記の内容は一部分であり、セキュリティ担当者の意見と重要性は別の側面であり、より多くの技術的な文書及び観点が必要であると言及しました(ユーザーとシステム間の相互作用に対する予想、セキュリティのベストプラクティスと教育など)。

データフローチャートを作成して提示したことがこれに該当し、さらに設計文書も重要であることを強調しました。

次に、何がうまくいかない可能性があるかを確認する必要があります。

そのためには、前述のデータフロー図を通じて様々な状況や脅威がどのように発生する可能性があるかを確認し、現在進行中の作業が何であるかを理解し、確認する必要があります。 また、データ分類などの優先順位を理解し、金融、規制、レピュテーションリスクなどの特定のタイプのリスクを追跡できるビジネスコンテキストを理解する必要があります。

次に、脅威フレームワークの導入について説明し、STRIDEや他のフレームワーク（Dread、Dave Micro Attackなど）の例を示し、MITRE ATLASフレームワークのようなAIワークロードに重点を置いたアプリケーションに役立つフレームワークも紹介しました。

フレームワークは、脅威についてどのように考えるべきか、そして脅威について具体化したり、どのように見せるかについて正規化することで、他の道に進むことを防ぐことができることを話しました。

最後に、既存の脅威情報を活用することができ、これを総合したものが脅威インテリジェンスとなり、内部脅威インテリジェンス機能を備えた組織であれば、特定の業界内の組織にアプローチしようとする際に、どのようなタイプの脅威行為者がより顕著になるのかということと、特定の脅威インテリジェンスを追跡することができると話しました。

・Threat framework example: STRIDE
・Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege

最近OWASPでLLM Applications Top 10を発表し、実際の脅威に対する具体的な内容も存在することを言及し、その情報が認識を向上させ、実際の脅威に備えるための有用なガイドとして活用できることを話しました。

以下は、実際の脅威の表現を例として構成しました。まず、脅威のソースについて検討し、ソースは一般的に外部または内部と定義しました。 これらのソースは一般的に意図的なリソースを持ち、実際の作業に必要なリソースと権限を持ち、実際の作業に必要なもので構成されています。

次に、脅威行動について話しましたが、前のデータ図のように、ユーザープロンプトの始まりとしてLLMによって生成されたものがデータベースに伝達され、データを抽出することになります。

これを悪意のあるプロンプトと考えるなら、脅威行動は既存のシステムプロンプトを上書きするなどに分類することができます。これは悪意のある結果として抽出されることになり、その過程の進行後、データの機密性または整合性を目標に設定し、これらの目標を通じて脅威を分類する方法を説明しました。

結果として、脅威は情報公開とスプーフィングに分類され、これにより、優先順位を設定し、実質的な脅威に備えることができることを言及しました。 このような脅威表現でビジネスコンテキストについての議論が続き、脅威がどのように現れ、影響を与えるかを定義することができ、その後、エンジニアに脅威がどのように現れるかについての説明が進むことができると話しました。

[構成した脅威の例］
an [external threat actor] with [access to the public facing application],
can [injection malicious prompts which overwrite existing system prompts],
which leads to [resulting in healthcare data from other patients being returned],
negatively impacting [confidentiality] of [the data in the database]

その後、LLMシステムへの直接的なアクセスはありませんが、攻撃者がシステムの反応を模倣することで攻撃者がどのように目標を達成できるかについての概念実証デモ（ユーザーデータと医療記録への問い合わせによるデータ抽出とカラム抽出）を示し、システムの偵察と脅威の特定に関するプロセスを強調しました。

アプリケーションの内部動作に対する洞察を得るために、攻撃グループを分析し、システムの動作に関する情報を探求し、次のような特徴を話しました。

まず、アプリケーションは、プロンプトに関係なく、ユーザーからのすべてのプロンプトを受け入れるという点があり、特に、ユーザーのコマンドと意図をそのまま受け入れて、バックエンドで次のプロンプトに直接転送する方法が確認されました。

また、LLMがプロンプトを使用して最初からクエリが生成されることを発見し、ユーザーが入力した内容に応じてクエリが動的に生成され、データベースにクエリされる方法を大幅に制御できるようになりました。

最後に、生成されたクエリの結果が、最初のユーザーの質問に対する応答の一部として再使用され、ユーザーの入力と生成されたクエリがアプリケーション内でどのように相互作用するかを示し、LLMがデータベースに関連するさまざまなタスクを実行できることを発見しました。

このようなことを確認することで、以前エンジニアが考慮しなかった側面が発見され、これにより、アプリケーションの動作方法に対する理解を高め、脅威の原因などを把握することができると話しました。

これらの脅威を特定し、理解した後、セキュリティアプリケーションを構築するための次のステップを議論することができます。ステップバイステップでアプローチし、各ステップで目標と具体的なタスクを定義することができると話されました。

まず、アプリケーションがすべてのユーザープロンプトを受け入れる方法を制限することが提案されました。システムプロンプトを使用して、チャットやLLMの許容可能なものを定義し、アプリケーションのルールを定義することを話しました。

次に、プロンプトのパラメータを削除して、特定のパラメータや列名などの特定の項目を認識できないようにすることが提案されました。 これにより、アプリケーションがユーザーから特定の情報を受け取らないようにし、不要な権限やクエリが生成されるのを防ぐことができます。

また、特定のクエリ構造を許容するようにTREE構造を定義し、これに合わないクエリは捨てて再起動する方法を検討しました。 これは、アプリケーションで無効なクエリを防止し、ユーザーに付与された権限を遵守するための重要なステップであると説明しました。

最後に、クエリの結果がレスポンスとして伝達される際、そのレスポンス内のデータを確認し、最終レスポンスがユーザーに伝達される前にデータの検証を行う複数のレイヤーを追加することが提案されました。 これにより、レスポンスの信頼性を高め、データベースと一致するかどうかを確認し、緩和方法を確認する段階に進みました。

これらのステップにより、アプリケーションのセキュリティを強化し、脅威からの防御メカニズムを構築することが目標であると話されました。

最後に、脅威緩和作業の評価と今後の計画について話し、緩和作業がどれだけ効果的に行われたかを確認するためにPentestを推奨し、リリースごとにPentestを実施することが良いと言及し、特に生成型AIの急速な発展を考慮し、反復的なテストが必要であることを強調しました。

また、自動化されたテストを通じて脅威モデルを検証し、向上させることが重要であると言及し、LLM応答と関連して自動化されたテストを行うことができる権限付与と認証メカニズムが有用に活用できることが強調されました。

最後に、このような脅威モデルは時間が経つにつれて発展し、改善され、継続的な評価と更新が必要であることを強調し、追加的に活用できるものを共有しました。

追加資料

セッションを終えて

このセッションを聞いて、生成型AI脅威モデリングは様々な側面からの考慮と戦略が必要であり、特にリスクの識別、優先順位の選定、影響の評価は重要な段階であると思いました。

そのためには、アプリケーションに対する深い理解が不可欠であり、企業内部のフレームワークの導入は、複雑な作業を簡素化して効率的に脅威モデリングを行うことができ、継続的な評価と更新を通じて脅威モデルを維持しながら、組織はより堅固で安全な生産型AIを維持することができると思います。