はじめに
先週、セキュリティ研究者のMika Ayensonは、ElasticのOnWeekイベントシリーズで実装されたプロキシ経由のLLMコンテンツ監査プロトタイプソリューションと、潜在的な検出戦略に焦点を当てた 出版物を執筆しました 。 この記事では、さまざまな環境で実装されるLLMテクノロジーの安全性に関する研究の重要性と、Elastic Security Labsが注目している研究に焦点を当てました。
Elasticが独自の視点を持ち、LLMテクノロジーをプラットフォームに活用してSecurity AI Assistantなどの機能を強化していることから、より正式な検知ルール、統合、研究コンテンツに対するElasticの要望は高まっています。 この資料では、LLM 統合における最近の進歩、業界標準に沿った検出に関する考え方、ECS フィールドマッピングに焦点を当てています。
私たちは、ユーザーベースのLLMとの直接的なインタラクションだけでなく、それらを取り巻くより広範なエコシステムも保護する包括的なセキュリティ戦略に取り組んでいます。 このアプローチには、LLM の要求/応答だけでなく、モデルで使用される基盤となるシステムや統合にも対処するためのセキュリティ検出エンジニアリングの機会のレイヤーが含まれます。
これらの検出機会は、LLMエコシステムの保護に総合的に役立ち、大きく5つのカテゴリに分類できます。
- プロンプトとレスポンス:LLMの相互作用の多様化に基づいて脅威を特定して軽減するように設計された検出メカニズムにより、すべての通信が安全に監査されるようにします。
- インフラストラクチャとプラットフォーム: LLM をホストするインフラストラクチャ (ウェアラブル AI Pin デバイスを含む) を保護するための検出を実装します。これには、保存されたデータに対する脅威の検出、処理アクティビティ、サーバー通信が含まれます。
- APIと統合:LLM APIと対話する際の脅威を検出し、モデル出力を取り込む他のアプリケーションとの統合を保護します。
- 運用プロセスとデータ: 運用プロセス (AI エージェントを含む) とデータ フローを監視しながら、ライフサイクル全体を通じてデータを保護します。
- コンプライアンスと倫理的:検出戦略を、広く採用されている業界規制と倫理基準に合わせます。
LLMエコシステムの保護:5つのカテゴリー
これらのカテゴリに関する別の重要な考慮事項は、誰がリスクに最も適切に対処できるか、またはLLMシステムに関連するリスクの各カテゴリに誰が責任を負うかにまで及びます。
既存の 共有セキュリティ責任 モデルと同様に、Elasticは4つの広範なカテゴリを評価しており、検出エンジニアリング戦略と統合の研究を続ける中で、最終的にはさらに拡大していく予定です。 大まかに言えば、この資料では、次の責任所有者が関与するセキュリティ保護について考察しています。
- LLM Creators: OpenAI、Amazon Web Services、Google など、LLM の構築、設計、ホスティング、トレーニングを行う組織
- LLM インテグレーター: LLM Creators によって作成された既存の LLM テクノロジを他のアプリケーションに統合する組織および個人
- LLM メンテナー: 運用 LLM のパフォーマンス、信頼性、セキュリティ、および整合性のユースケースを監視し、コードベース、インフラストラクチャ、およびソフトウェア アーキテクチャのメンテナンスに直接関与し続ける個人
- セキュリティユーザー:従来のテストメカニズムと手段を通じてシステムの脆弱性を積極的に探している人々。 これは、 OWASPのLLM Top 10 で説明した従来のリスクを超えて、これらのシステムを取り巻くソフトウェアとインフラストラクチャに関連するリスクに拡大する可能性があります
この広範な視点は、ネイティブ のElastic統合を使用してデータを取り込むことから始まるLLM検出エンジニアリングへの統一されたアプローチを示しています。この例では、AWS Bedrock Model Invocation のユースケースを強調しています。
LLMログをElasticに統合する
Elasticの統合により、さまざまなソースからElasticへのデータインジェストが簡素化され、最終的にElasticのセキュリティソリューションが強化されます。 これらの統合はKibanaのFleetを通じて管理されるため、ユーザーはElastic Agent内でデータを簡単にデプロイして管理できます。 ユーザーは、Fleetを通じて統合を選択して設定することで、Elasticを新しいデータソースにすばやく適応させることができます。 詳細については、ElasticとElasticの統合を容易にする方法に関するElasticの ブログ をご覧ください。
チームが最初に行ったONWeekの作業には、ElasticセキュリティAIアシスタントとのインタラクションからフィールドを抽出するシンプルなプロキシソリューションが含まれていました。 このプロトタイプはElastic Stackと一緒にデプロイされ、セキュリティ監査機能がないベンダーソリューションからデータを消費しました。 この初期実装は概念的に興味深いものでしたが、チームはクラウドプロバイダーパートナーの1つである Amazon Web Servicesの既存のElastic統合の評価に時間を費やすことになりました。 この方法論により、ユーザーのアクセシビリティが合理化され、データ取り込みのためのシームレスなワンクリック統合が提供されます。 すべての取り込みパイプラインは ECS/OTel 正規化標準に準拠しており、ダッシュボードを含む包括的なコンテンツを統合パッケージに収めています。 さらに、この戦略により、AzureやGCPなどの既存の統合をさらに活用して、将来のLLMに焦点を当てた統合に活用することができます。
ベンダーの選択とAPI機能
統合を作成するLLMプロバイダーを選択する際には、セキュリティのユースケースで取り込む必要のあるフィールドのタイプを検討しました。 ここで詳しく説明するルールの開始セットには、タイムスタンプやトークン数などの情報が必要でした。Azure OpenAI などのベンダーが、プロンプトと生成されたコンテンツに対するコンテンツ モデレーション フィルタリングを提供していることがわかりました。 LangSmith(LangChainツールの一部)も、データに使用されたベンダーの種類(OpenAI、Bedrockなど)とそれぞれのメタデータがすべて含まれているため、最有力候補でした。 ただし、これにはユーザーがLangSmithも設定している必要がありました。 この実装では、LLM を提供するベンダーのファーストパーティサポートログを使用することにしました。
統合の可能性を深く掘り下げるにつれ、いくつかの特定の理由から、AWS Bedrock を採用することにしました。 まず、Bedrock Logging は Amazon CloudWatch Logs と Amazon S3 を ファーストパーティでサポート しています。 次に、ロギングは、プロンプトや応答、ガードレール/コンテンツフィルタリングなどの(他の操作や機械学習モデルとは対照的に)LLMに固有のデータを含む、モデル呼び出し専用に構築されています。 3つ目は、ElasticはすでにAWSとの統合の 堅牢なカタログ を持っているため、AWS Bedrockモデルの呼び出しログに特化した新しい統合を迅速に作成することができました。 次のセクションでは、この新しい統合について詳しく説明します。これを使用して、Elastic スタックの Bedrock モデルの呼び出しログをキャプチャできます。
Elastic AWS Bedrockモデルの統合
Overview
モデル呼び出しログ用の新しいElastic AWS Bedrock 統合により、AWSサービスからデータを迅速に収集して分析する方法が提供され、特にモデルに焦点を当てています。 この統合により、ログ収集には主に Amazon S3 バケットと Amazon CloudWatch の 2 つの方法が提供されます。 各方法は、費用対効果とパフォーマンス効率を考慮しながら、堅牢なデータ検索機能を提供するように最適化されています。 収集されたこれらのLLM固有のフィールドは、検出エンジニアリングの目的で使用します。
注: この統合は、提案されたすべてのフィールドをカバーするわけではありませんが、既存の AWS Bedrock フィールドを gen_ai カテゴリに標準化します。 このアプローチにより、さまざまなデータソース間で検出ルールを維持することが容易になり、LLM ベンダーごとに個別のルールが必要になることが最小限に抑えられます。
統合データ収集方式の構成
S3 バケットからのログの収集
この統合により、次の 2 つの異なる方法を使用して S3 バケットから効率的にログを収集できます。
- SQS通知:これは収集に推奨される方法です。 これには、AWS Simple Queue Service (SQS) キューからの S3 通知イベントの読み取りが含まれます。 この方法は、直接ポーリングと比較してコストが低く、パフォーマンスが優れています。
- 直接 S3 バケット ポーリング: この方法は、S3 バケット内の S3 オブジェクトのリストを直接ポーリングするため、SQS 通知を設定できない場合にのみ推奨されます。 このアプローチはリソースを大量に消費しますが、SQS が実現不可能な場合の代替手段を提供します。
CloudWatch からのログの収集
ログは CloudWatch から直接収集することもでき、統合は filterLogEvents AWS API を使用して指定されたロググループ内のすべてのログストリームを利用します。 この方法は、S3 バケット全体を使用する代わりに使用できます。
統合インストール
統合は、通常のElastic インストール手順に従ってElastic Agent内で設定できます。
- AWS Bedrockインテグレーションに移動します
- SQS の
queue_urlを設定するか、直接 S3 ポーリングのbucket_arnを設定します。
Bedrock Guardrailsの設定
AWS Bedrock Guardrails を使用すると、組織は LLM インタラクションの有害または望ましくないコンテンツを制限するポリシーを設定することで、セキュリティを適用できます。 これらのガードレールは、特定の件名をブロックするための拒否されたトピックや、プロンプトと応答のコンテンツの重大度を緩和するためのコンテンツ フィルターを含むようにカスタマイズできます。 さらに、単語と機密情報のフィルターは、冒とく的な表現をブロックし、個人を特定できる情報(PII)をマスクして、インタラクションがプライバシーと倫理基準に準拠していることを確認します。 この機能は、LLM によって生成および消費されるコンテンツを制御するのに役立ち、理想的には、悪意のあるプロンプトに関連するリスクを軽減します。
注: その他のガードレールの例としては、Azure OpenAI の コンテンツ フィルターとレスポンス フィルターがあり、ベンダーに依存しないロギングのために提案されている LLM 標準化フィールドでキャプチャすることを目指しています。
LLM インタラクション コンテンツがこれらのフィルターをトリガーすると、応答オブジェクトには、Guardrails の結果に関する詳細を提供する amazon-bedrock-trace フィールドと amazon-bedrock-guardrailAction フィールド、および入力がコンテンツ フィルターに一致したかどうかを示すネストされたフィールドが入力されます。 このレスポンスオブジェクトのエンリッチメントと詳細なフィルター結果により、全体的なデータ品質が向上し、これらのネストされたフィールドがECSマッピングと整列している場合に特に効果的になります。
ECSマッピングの重要性
フィールドマッピングは、統合開発のプロセスの重要な部分であり、主に、広範囲で広く互換性のある検出ルールを作成する能力を向上させることを目的としています。 データのインジェストと分析の方法を標準化することで、組織はElasticにインジェストされたログ(この場合はLLMログ)の潜在的な脅威や異常をより効果的に検出、調査、対応できます。
最初のマッピングは、ベンダーが提供するフィールドと既存のギャップを調査することから始まり、LLM運用のニュアンスに合わせた包括的なスキーマの確立につながります。 次に、OpenTelemetry のセマンティック規則に合わせてフィールドを調整しました。 表に示されているこれらのマッピングは、さまざまな側面をカバーしています。
- 一般的なLLMインタラクションフィールド:これには、リクエストとレスポンスの内容、トークン数、タイムスタンプ、インタラクションのコンテキストと範囲を理解するための基礎となるユーザー識別子など、基本的でありながら重要な情報が含まれます。
- テキスト品質と関連性メトリックフィールド:テキストの可読性、複雑さ、および類似性スコアを測定するフィールドは、モデル出力の品質と関連性を評価するのに役立ち、応答が正確であるだけでなく、ユーザーにとっても適切であることを確認します。
- セキュリティ メトリック フィールド: このクラスのメトリックは、正規表現パターンの一致や、脱獄の試み、プロンプト インジェクション、幻覚の一貫性や拒否応答などのその他のセキュリティ上の懸念事項に関連するスコアなど、潜在的なセキュリティ リスクを特定して定量化するために重要です。
- ポリシー適用フィールド: これらのフィールドは、コンテンツのブロックや変更など、インタラクション中に実行された特定のポリシー適用アクションに関する詳細をキャプチャし、これらのアクションの信頼レベルに関する分析情報を提供し、セキュリティとコンプライアンス対策を強化します。
- 脅威分析フィールド: 潜在的な脅威の特定と定量化に重点を置いたこれらのフィールドは、リスク スコア、検出された脅威の種類、およびこれらの脅威を軽減するために講じられた対策の詳細な分析を提供します。
- コンプライアンスフィールド: これらのフィールドは、インタラクションがさまざまな規制基準に準拠していることを確認するのに役立ち、検出されたコンプライアンス違反とインタラクション中にトリガーされた特定のルールを詳しく説明します。
- OWASP Top Ten Specific Fields: これらのフィールドは、LLM アプリケーションの OWASP Top 10 リスクに直接マッピングされ、セキュリティ対策を認められた業界標準に合わせるのに役立ちます。
- 感情および有害性分析フィールド:これらの分析は、トーンを測定し、応答内の有害なコンテンツを検出し、出力が倫理ガイドラインと基準に合致していることを確認するために不可欠です。 これには、センチメント スコア、有害性レベル、不適切または機密性の高いコンテンツの特定が含まれます。
- パフォーマンスメトリックフィールド:これらのフィールドは、システムパフォーマンスを最適化し、効率的な運用を確保するために重要な、応答時間やリクエストとレスポンスのサイズなど、LLMインタラクションのパフォーマンスの側面を測定します。
注: 提案されたフィールドの拡張表については、 要点 を参照してください。
これらのフィールドは LLM 統合によってマッピングされ、最終的には検出内で使用されます。 脅威の状況を引き続き理解しながら、これらのフィールドを引き続き改良し、他のLLMベンダーが入力する追加のフィールドが標準化され、概念的にマッピングに反映されるようにします。
標準化の広範な影響と利点
LLMエコシステム内のセキュリティフィールド(ユーザーインタラクションやアプリケーション統合など)を標準化すると、セキュリティドメインへの統一されたアプローチが容易になります。 Elasticは、一連の標準フィールドを定義し、推進することで、先頭に立とうとしています。 この取り組みは、個々の組織のセキュリティ体制を強化するだけでなく、より安全な業界を育成します。
セキュリティツールとの統合:LLM関連のセキュリティツールからの応答を標準化することで、元のLLMベンダーのコンテンツとともにセキュリティソリューションに出荷できるセキュリティ分析フィールドを充実させます。 LLMアプリケーションのエコシステムで運用上チェーンされている場合、セキュリティツールは各呼び出し要求と応答を監査できます。 その後、セキュリティチームはこれらのフィールドを活用して、LLMインタラクション内の誤用や脆弱性の微妙な兆候を特定できる複雑な検出メカニズムを構築できます。
ベンダー間の一貫性: すべての LLM ベンダーがこれらの標準フィールドを採用することを主張することで、アプリケーションを効果的に保護するという単一の目標が推進されますが、すべての業界ユーザーが遵守できるベースラインを確立する方法になります。 ユーザーは、プラットフォームやツールに関係なく、共通のスキーマに合わせることをお勧めします。
強化された検出エンジニアリング:これらの標準フィールドにより、検出エンジニアリングはより堅牢になり、誤検出の変化が減少します。 セキュリティエンジニアは、さまざまなモデル、インタラクション、エコシステム全体で潜在的な脅威を特定する効果的なルールを作成できます。 この一貫性は、複数のLLMまたはセキュリティツールに依存し、統一されたプラットフォームを維持する必要がある組織にとって特に重要です。
LLM 固有のフィールドの例: AWS Bedrock のユースケース
統合のインジェストパイプライン、フィールドマッピング、プロセッサに基づいて、AWS Bedrockデータはクリーンアップ、標準化され、Elastic Common Schema(ECS)フィールドにマッピングされます。 その後、コア Bedrock フィールドは、要求、応答、トークン数などのモデル呼び出しに関する詳細を含む aws.bedrock グループの下に導入されます。 この統合により、LLM に合わせて調整された追加のフィールドが入力され、モデルの相互作用に関するより深い洞察が得られ、後で検出に使用されます。
LLM検出エンジニアリングの例
標準化されたフィールドとElastic AWS Bedrockの統合により、提案された機能をさまざまな複雑さで示す検出エンジニアリングルールの作成を開始できます。 以下の例は、 ES|QLです。
注: これらのクエリの詳細については、detection-rules ハンティング ディレクトリと aws_bedrock ルールを確認してください。
センシティブなコンテンツの拒否の基本的な検出
組織内のデリケートなトピックに関する現在のポリシーと基準では、LLMがコンプライアンスと倫理基準も遵守することを保証するメカニズムを用意することが重要です。 組織には、LLMが機密性の高いトピックへの対応を直接拒否するインスタンスを監視およびキャプチャする機会があります。
サンプル検出:
from logs-aws_bedrock.invocation-*
| WHERE @timestamp > NOW() - 1 DAY
AND (
gen_ai.completion LIKE "*I cannot provide any information about*"
AND gen_ai.response.finish_reasons LIKE "*end_turn*"
)
| STATS user_request_count = count() BY gen_ai.user.id
| WHERE user_request_count >= 3検出の説明: このクエリは、モデルが機密性の高いトピックや制限されたトピックに関する情報の提供を複数回明示的に拒否するインスタンスを検出するために使用されます。 定義済みの書式設定された出力と組み合わせると、出力コンテンツ内で "I cannot provide any information about" などの特定のフレーズを使用すると、モデルが、機密または不適切として扱うようにプログラムされた内容について話し合うユーザー プロンプトによってトリガーされたことを示します。
セキュリティの関連性: LLM 拒否を監視すると、モデルの機密データを調査したり、専有情報や制限された情報の漏洩につながる可能性のある方法でモデルを悪用したりする試みを特定するのに役立ちます。 これらの拒否のパターンと頻度を分析することで、セキュリティチームは、情報セキュリティポリシーを侵害しようとする標的型攻撃があるかどうかを調査できます。
潜在的なサービス拒否攻撃またはリソース枯渇攻撃
LLM のエンジニアリング設計は計算量が多く、データ集約型であるため、リソースの枯渇やサービス拒否 (DoS) 攻撃の影響を受けやすくなります。 高い使用パターンは、LLM の可用性を低下させるように設計された不正使用または悪意のあるアクティビティを示している可能性があります。 プロンプト要求のサイズとトークン数を直接関連付けることはあいまいなため、プロンプトのトークン数が多い場合の影響を考慮することが不可欠です。これは、要求本文が大きいことが必ずしも原因であるとは限らない。 トークン数と文字数は特定のモデルによって異なり、それぞれが異なる場合があり、埋め込みの生成方法に関連しています。
サンプル検出:
from logs-aws_bedrock.invocation-*
| WHERE @timestamp > NOW() - 1 DAY
AND (
gen_ai.usage.prompt_tokens > 8000 OR
gen_ai.usage.completion_tokens > 8000 OR
gen_ai.performance.request_size > 8000
)
| STATS max_prompt_tokens = max(gen_ai.usage.prompt_tokens),
max_request_tokens = max(gen_ai.performance.request_size),
max_completion_tokens = max(gen_ai.usage.completion_tokens),
request_count = count() BY cloud.account.id
| WHERE request_count > 1
| SORT max_prompt_tokens, max_request_tokens, max_completion_tokens DESC検出の説明: このクエリは、悪用またはサービス拒否 (DoS) 攻撃の試みを示している可能性のある大量のトークン使用量を特定します。 異常に多いトークン数 (入力または出力) を監視すると、システムの速度を低下させたり、サービスを圧倒したりして、サービスの中断につながる可能性のあるパターンを検出するのに役立ちます。 各アプリケーションが異なるトークン量を活用する可能性があることを考慮して、既存の経験に基づいて、基本的なユースケースをカバーするはずの単純なしきい値を選択しました。
セキュリティとの関連性: この形式の監視は、システムの可用性とパフォーマンスに関する潜在的な問題を検出するのに役立ちます。 これは、正当なユーザーのサービス品質を低下させる可能性のあるDoS攻撃や不正行為を早期に検出するのに役立ちます。 トークンの使用状況をアカウントごとに集約して分析することで、セキュリティチームは潜在的に悪意のあるトラフィックのソースを特定し、適切な対策を講じることができます。
レイテンシ異常の監視
レイテンシーベースのメトリクスは、システムの過負荷を引き起こす根本的なパフォーマンスの問題やセキュリティの脅威を示す重要な指標となる可能性があります。 処理の遅延を監視することで、組織はサーバーが期待どおりに効率的に動作していることを確認できます。
サンプル検出:
from logs-aws_bedrock.invocation-*
| WHERE @timestamp > NOW() - 1 DAY
| EVAL response_delay_seconds = gen_ai.performance.start_response_time / 1000
| WHERE response_delay_seconds > 5
| STATS max_response_delay = max(response_delay_seconds),
request_count = count() BY gen_ai.user.id
| WHERE request_count > 3
| SORT max_response_delay DESC検出の説明: この更新されたクエリは、LLM が要求を受信してから応答の送信を開始するのにかかる時間を監視し、初期応答の待機時間に焦点を当てます。 応答の実際の開始を通常の応答時間と比較することで、大幅な遅延を特定し、これらの遅延が異常に長くなる可能性があるインスタンスを強調します。
セキュリティとの関連性:異常なレイテンシは、ネットワーク攻撃(DDoSなど)やシステムの非効率性など、対処が必要な問題の兆候である可能性があります。 レイテンシーメトリクスを追跡して分析することで、組織はシステムが効率的かつ安全に稼働していることを確認でき、異常な遅延として現れる可能性のある潜在的な脅威に迅速に対応することができます。
高度な LLM 検出エンジニアリングの使用例
このセクションでは、Elasticセキュリティの統合で対処できる可能性のあるユースケースについて説明します。 これらのフィールドが完全に入力されており、必要なセキュリティ監査エンリッチメント機能 (Guardrails など) が AWS Bedrock 内または LLM ベンダーが提供する同様のアプローチによって実装されていることを前提としています。 利用可能なデータソースとElastic統合を組み合わせることで、これらのGuardrailリクエストとレスポンスの上に検出ルールを構築し、デプロイ中のLLMの誤用を検出できます。
悪意のあるモデルのアップロードとテナント間のエスカレーション
Hugging Face Interface APIに関する最近の調査では、攻撃者が悪意を持って細工されたモデルをアップロードして任意のコードを実行するという重大なリスクが明らかになりました。 これは、Python Pickle ファイルを使用して実現され、逆シリアル化されると、埋め込まれた悪意のあるコードが実行されました。 これらの脆弱性は、LLMからモデルをホストするインフラストラクチャ、およびアプリケーションAPI統合まで、AI-as-a-Service(AIAAS)プラットフォーム内のすべての入力を検査およびサニタイズするための厳格なセキュリティ対策の必要性を浮き彫りにしています。 詳細については、 こちらの記事 を参照してください。
潜在的な検出機会: gen_ai.request.model.id、 gen_ai.request.model.version、プロンプト gen_ai.completion などのフィールドを使用して、異常なモデルとの相互作用を検出します。 モデルの識別子とバージョン番号の異常な値やパターンを監視し、要求されたコンテンツを検査する (たとえば、一般的な Python Pickle シリアル化手法を探す) と、疑わしい動作が示される可能性があります。 同様に、同様のフィールドを使用してモデルをアップロードする前にチェックすると、アップロードがブロックされる場合があります。 gen_ai.user.id などの追加のフィールドを相互参照すると、これらの種類のアクティビティを実行する悪意のあるテナント間操作を特定するのに役立ちます。
不正なURLと外部通信
LLMが運用エコシステムに統合されるにつれて、電子メールやWebhookなどの外部機能と対話する能力が攻撃者によって悪用される可能性があります。 これらの相互作用から保護するには、モデルの出力とその後の統合に基づいて、疑わしいアクティビティや不正なアクティビティを特定できる検出ルールを実装することが重要です。
潜在的な検出機会: gen_ai.completionや gen_ai.security.regex_pattern_count などのフィールドを使用して、悪意のある外部 URL と Webhook をトリアージします。 これらの正規表現パターンは、既知の疑わしいパターンに基づいて事前に定義する必要があります。
階層的な命令の優先順位付け
LLMは、さまざまなソースから指示を受け取る環境( ChatGPTカスタム命令など)でますます使用されていますが、必ずしも善意であるとは限りません。 この独自のモデル作成ワークフローでは、モデルがすべての命令を同等に重要度で扱い、チェックされないままになると、さまざまな潜在的なセキュリティの脆弱性が発生する可能性があります。 ここで参照してください。
潜在的な検出機会: gen_ai.model.instructions や gen_ai.completion などのフィールドを監視して、特定の命令とモデルの応答との間の不一致を特定します。これは、モデルがすべての命令を同等に重要度で扱うケースを示している可能性があります。 さらに、 gen_ai.similarity_scoreを分析して、元の要求からの応答がどの程度類似しているかを識別します。
追加の Elastic ルールタイプを特徴とする拡張検出
このセクションでは、ElasticのルールタイプであるThreshold、Indicator Match、New Termsの一部を使用して、より微妙で堅牢なセキュリティ体制を提供する追加の検出エンジニアリング手法を紹介します。
- しきい値ルール: 不正使用の試みを示す可能性のある
gen_ai.user.id別にグループ化された、短期間に拒否された要求の高頻度を特定します。 (例: OWASPのLLM04) - インジケーター一致ルール: これらのユーザー属性を含む LLM ユーザー ID などの LLM ユーザー ID など、インテリジェンスが提供する既知の悪意のある脅威のインジケーター
gen_ai.user.id一致させます。 (例:arn:aws:iam::12345678912:user/thethreatactor) - 新しい用語ルール: ユーザー プロンプトで、ユーザーのロールの通常の使用以外の通常のアクティビティを示す可能性のある新しい用語または異常な用語を検出し、新しい悪意のある動作を示している可能性があります。
まとめ
Elasticは、ジェネレーティブAIランドスケープ全体でLLMベースのフィールドを標準化する先駆者であり、エコシステム全体でのセキュリティ検出を可能にしています。 この取り組みは、LLMの統合およびセキュリティ戦略における継続的な強化と整合するだけでなく、直接的なユーザーインタラクションと基盤となるシステムアーキテクチャの両方を保護する広範なセキュリティフレームワークをサポートします。 検出と対応の能力を強化するためにLLMベンダー間で統一された言語を推進することで、エコシステム全体を保護し、より安全で信頼性の高いものにすることを目指しています。 Elasticは、業界内のすべてのステークホルダー、クリエイター、メンテナー、インテグレーター、ユーザーに、これらの標準化されたプラクティスを採用するよう呼びかけ、それによって集団的なセキュリティ対策を強化し、業界全体の保護を推進します。
AWS Bedrockを皮切りに、統合の追加と強化を続ける中で、他のLLMベースの統合を設定した新しい基準に合わせるための戦略を立て、Elasticエコシステム全体で統一されたエクスペリエンスへの道を開いています。 既存のElasticsearch機能とシームレスにオーバーラップすることで、ユーザーはLLMデータに対して直接高度な検索と分析を活用でき、既存のワークフローをユーザーが最も使い慣れたツールに戻すことができます。
これらのトピックを深く掘り下げた LLM安全性評価をご覧ください。
本記事に記述されているあらゆる機能ないし性能のリリースおよびタイミングは、Elasticの単独裁量に委ねられます。現時点で提供されていないあらゆる機能ないし性能は、すみやかに提供されない可能性、または一切の提供が行われない可能性があります。