简介
上周，安全研究员 Mika Ayenson 发表了一篇文章，重点介绍了在 Elastic OnWeek 活动系列期间通过代理实施的潜在检测策略和 LLM 内容审计原型解决方案。这篇文章强调了对在不同环境中实施的 LLM 技术的安全性进行研究的重要性，以及我们在 Elastic 安全实验室的研究重点。
鉴于 Elastic 在我们的平台中利用 LLM 技术来支持诸如安全 AI 助手等功能方面具有独特的优势，我们对更正式的检测规则、集成和研究内容的需求日益增长。本出版物重点介绍了我们在 LLM 集成方面取得的一些最新进展、我们围绕符合行业标准的检测的想法以及 ECS 字段映射。
我们致力于全面的安全策略，不仅保护基于用户的直接 LLM 交互，还保护其周围更广泛的生态系统。这种方法涉及多层安全检测工程机会，不仅要解决 LLM 请求/响应，还要解决模型使用的底层系统和集成。
这些检测机会共同帮助保护 LLM 生态系统，并且可以大致分为五个类别
- 提示和响应：旨在根据不断增长的 LLM 交互来识别和缓解威胁的检测机制，以确保所有通信都经过安全审计。
- 基础设施和平台：实施检测以保护托管 LLM 的基础设施（包括可穿戴 AI Pin 设备），包括检测针对存储的数据、处理活动和服务器通信的威胁。
- API 和集成：检测与 LLM API 交互时的威胁，并保护与其他应用程序的集成，这些应用程序会摄取模型输出。
- 运营流程和数据：监控运营流程（包括 AI 代理中的运营流程）和数据流，同时在其整个生命周期中保护数据。
- 合规性和道德：使检测策略与广泛采用的行业法规和道德标准保持一致。
保护 LLM 生态系统：五个类别
这些类别的另一个重要考虑因素扩展到谁最能解决风险，或者谁负责与 LLM 系统相关的每个风险类别。
与现有的 共享安全责任模型类似，Elastic 评估了四个广泛的类别，当我们继续研究检测工程策略和集成时，最终会进一步扩展这些类别。总的来说，本出版物考虑了涉及以下责任所有者的安全保护
- LLM 创建者：构建、设计、托管和训练 LLM 的组织，例如 OpenAI、Amazon Web Services 或 Google
- LLM 集成者：将 LLM 创建者生成的现有 LLM 技术集成到其他应用程序中的组织和个人
- LLM 维护者：监控运营 LLM 的性能、可靠性、安全性和完整性用例，并直接参与代码库、基础设施和软件架构维护的个人
- 安全用户：通过传统的测试机制和手段积极寻找系统中漏洞的人员。这可能会超出 OWASP 的 LLM Top 10 中讨论的传统风险，扩展到与这些系统周围的软件和基础设施相关的风险
这种更广泛的视角展示了一种统一的 LLM 检测工程方法，该方法从使用原生 Elastic 集成摄取数据开始；在此示例中，我们重点介绍了 AWS Bedrock 模型调用用例。
将 LLM 日志集成到 Elastic 中
Elastic 集成简化了从各种来源将数据摄取到 Elastic 中的过程，最终增强了我们的安全解决方案。这些集成通过 Kibana 中的 Fleet 进行管理，允许用户轻松部署和管理 Elastic Agent 中的数据。用户可以通过 Fleet 选择和配置集成，从而快速使 Elastic 适应新的数据源。有关更多详细信息，请参阅 Elastic 关于使系统更容易与 Elastic 集成的博客。
该团队最初在 ONWeek 上进行的工作涉及一个简单的代理解决方案，该解决方案从与 Elastic Security AI 助手的交互中提取字段。此原型与 Elastic Stack 一起部署，并使用了来自缺乏安全审计功能的供应商解决方案的数据。虽然最初的实施在概念上很有趣，但它促使团队投入时间评估我们云提供商合作伙伴 Amazon Web Services 的现有 Elastic 集成。此方法确保我们的用户可以流畅地访问，从而为数据摄取提供无缝的一键式集成。所有摄取管道都符合 ECS/OTel 标准化标准，其中包含全面的内容，包括统一包内的仪表板。此外，此策略使我们能够利用其他现有集成（例如 Azure 和 GCP）进行未来的以 LLM 为中心的集成。
供应商选择和 API 功能
在选择要为其创建集成的 LLM 提供商时，我们研究了安全用例需要摄取的字段类型。对于此处详述的初始规则集，我们需要诸如时间戳和令牌计数之类的信息；我们发现诸如 Azure OpenAI 之类的供应商对提示和生成的内容提供了内容审核过滤。LangSmith（LangChain 工具的一部分）也是主要竞争者，因为数据包含所使用的供应商类型（例如，OpenAI、Bedrock 等）和所有相应的元数据。但是，这需要用户也设置 LangSmith。对于此实现，我们决定使用来自提供 LLM 的供应商的第一方支持日志。
当我们深入研究潜在的集成时，我们决定采用 AWS Bedrock，原因有几个具体原因。首先，Bedrock 日志记录对 Amazon CloudWatch Logs 和 Amazon S3 提供第一方支持。其次，日志记录是专门为模型调用而构建的，包括特定于 LLM 的数据（与其他操作和机器学习模型相反），包括提示和响应，以及防护栏/内容过滤。第三，Elastic 已经与 AWS 建立了 强大的集成目录，因此我们能够专门为 AWS Bedrock 模型调用日志快速创建新的集成。下一节将深入探讨此新集成，您可以使用该集成在 Elastic Stack 中捕获您的 Bedrock 模型调用日志。
Elastic AWS Bedrock 模型集成
概述
新的 Elastic AWS Bedrock 模型调用日志集成提供了一种快速收集和分析来自 AWS 服务的数据的方法，特别是专注于模型。此集成提供了两种主要的日志收集方法：Amazon S3 存储桶和 Amazon CloudWatch。每种方法都经过优化，可在考虑成本效益和性能效率的同时提供强大的数据检索功能。我们使用收集到的这些 LLM 特定字段进行检测工程。
注意：虽然此集成并未涵盖每个建议的字段，但它确实将现有的 AWS Bedrock 字段标准化为 gen_ai 类别。这种方法可以更轻松地维护各种数据源的检测规则，从而最大限度地减少为每个 LLM 供应商设置单独规则的需要。
配置集成数据收集方法
从 S3 存储桶收集日志
此集成允许使用两种不同的方法从 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 交互内容触发这些过滤器时，响应对象会填充 amazon-bedrock-trace 和 amazon-bedrock-guardrailAction 字段，提供有关 Guardrails 结果的详细信息，以及指示输入是否与内容过滤器匹配的嵌套字段。这种通过详细过滤器结果来丰富响应对象的方式提高了整体数据质量，当这些嵌套字段与 ECS 映射对齐时，这种方式会特别有效。
ECS 映射的重要性
字段映射是集成开发过程中至关重要的一部分，主要是为了提高我们编写广泛适用且兼容性强的检测规则的能力。通过标准化数据的摄取和分析方式，组织可以更有效地检测、调查和响应摄取到 Elastic 中的日志（在本例中为 LLM 日志）中潜在的威胁或异常情况。
我们的初始映射从调查供应商提供的字段和现有差距开始，从而建立一个针对 LLM 操作细微差别的全面模式。然后，我们协调这些字段，使其与我们的 OpenTelemetry 语义约定保持一致。表中显示的这些映射涵盖了各个方面
- 通用 LLM 交互字段：这些字段包括基本但关键的信息，例如请求和响应的内容、令牌计数、时间戳和用户标识符，这些是理解交互上下文和范围的基础。
- 文本质量和相关性度量字段：用于测量文本可读性、复杂性和相似性分数的字段有助于评估模型输出的质量和相关性，确保响应不仅准确，而且适合用户。
- 安全度量字段：这类指标对于识别和量化潜在的安全风险非常重要，包括正则表达式模式匹配以及与越狱尝试、提示注入以及其他安全问题（如幻觉一致性和拒绝响应）相关的分数。
- 策略强制执行字段：这些字段捕获在交互期间采取的特定策略强制执行操作的详细信息，例如阻止或修改内容，并提供对这些操作的置信水平的见解，从而增强安全性和合规性措施。
- 威胁分析字段：这些字段专注于识别和量化潜在威胁，提供有关风险评分、检测到的威胁类型以及为减轻这些威胁而采取的措施的详细分析。
- 合规性字段：这些字段有助于确保交互符合各种监管标准，详细说明检测到的任何合规性违规情况以及在交互期间触发的特定规则。
- OWASP 前十名特定字段：这些字段直接映射到 LLM 应用的 OWASP 前 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 hunting 目录和 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检测说明：此查询用于检测模型多次明确拒绝提供有关潜在敏感或受限主题的信息的实例。结合预定义的格式化输出，输出内容中使用诸如“我无法提供任何有关以下内容的信息”之类的特定短语表明模型已被用户提示触发，以讨论它被编程为视为机密或不适当的内容。
安全相关性：监控 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 Security 集成解决的潜在用例。它假设这些字段已完全填充，并且必要的安全审计增强功能（例如，Guardrails）已在 AWS Bedrock 内或通过 LLM 供应商提供的类似方法实现。结合可用的数据源和 Elastic 集成，可以基于这些 Guardrail 请求和响应构建检测规则，以检测部署中 LLM 的滥用情况。
恶意模型上传和跨租户升级
最近对 Hugging Face Interface API 的一项调查显示，存在一个重大风险，即攻击者可以上传恶意制作的模型来执行任意代码执行。这是通过使用 Python Pickle 文件实现的，该文件在反序列化时执行嵌入的恶意代码。这些漏洞突显了需要采取严格的安全措施来检查和清理 AI 即服务 (AIAAS) 平台中从 LLM 到托管模型的基础设施以及应用程序 API 集成中的所有输入。有关更多详细信息，请参阅本文。
潜在的检测机会：使用诸如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 的一些规则类型（阈值、指标匹配和新术语）的其他检测工程技术，以提供更细致和强大的安全态势。
- 阈值规则：识别短时间内按
gen_ai.user.id分组的高频率被拒绝的请求，这可能表明存在滥用尝试。（例如，OWASP 的 LLM04） - 指标匹配规则：匹配已知的恶意威胁情报提供的指标，例如包含这些用户属性的 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 自行决定。任何当前不可用的特性或功能可能无法按时交付或根本无法交付。