简介
上周，安全研究员 Mika Ayenson撰写了一篇出版物，重点介绍了潜在的检测策略和通过在 Elastic 的 OnWeek 活动系列期间实施的代理实现的 LLM 内容审计原型解决方案。 这篇文章强调了在不同环境中实施的 LLM 技术的安全性研究的重要性，以及我们在 Elastic Security Labs 所采取的研究重点。
鉴于 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 Assistant 的交互中提取字段。 该原型与 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 堆栈中的 Bedrock 模型调用日志。
Elastic AWS Bedrock 模型集成
Overview
新的 Elastic AWS Bedrock模型调用日志集成提供了一种快速收集和分析来自 AWS 服务的数据的方法，特别专注于模型。 此集成提供了两种主要的日志收集方法：Amazon S3 存储桶和 Amazon CloudWatch。 每种方法都经过优化，提供强大的数据检索功能，同时考虑成本效益和性能效率。 我们将这些收集的 LLM 特定字段用于检测工程目的。
注意：虽然此集成并未涵盖每个提议的字段，但它确实将现有的 AWS Bedrock 字段标准化到 gen_ai 类别中。 这种方法使得跨各种数据源维护检测规则变得更加容易，从而最大限度地减少了为每个 LLM 供应商制定单独规则的需要。
配置集成数据收集方法
从 S3 存储桶收集日志
通过这种集成，可以使用两种不同的方法从 S3 存储桶高效收集日志：
- SQS 通知：这是首选的收集方法。 它涉及从 AWS 简单队列服务 (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 ) 字段。 然后在aws.bedrock组下引入核心 Bedrock 字段，其中包括有关模型调用的详细信息，如请求、响应和令牌计数。 该集成填充了为 LLM 定制的附加字段，以便对模型的交互提供更深入的见解，这些见解稍后将用于我们的检测。
LLM检测工程实例
通过标准化字段和 Elastic AWS Bedrock 集成，我们可以开始制定检测工程规则，以不同的复杂性展示所提出的功能。 下面的示例是使用ES|QL编写的。
注意：请查看检测规则搜索目录和aws_bedrock规则以获取有关这些查询的更多详细信息。
敏感内容拒绝的基本检测
根据组织内有关敏感话题的现行政策和标准，建立机制确保法学硕士也遵守合规和道德标准非常重要。 组织有机会监控和捕捉法学硕士直接拒绝回应敏感话题的情况。
样品检测：
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 集成解决的潜在用例。 它假定这些字段已完全填充，并且已在 AWS Bedrock 中或通过 LLM 供应商提供的类似方法实现了必要的安全审计丰富功能（例如，Guardrails）。 结合可用的数据源和 Elastic 集成，可以在这些 Guardrail 请求和响应之上构建检测规则，以检测部署中 LLM 的滥用。
恶意模型上传和跨租户升级
最近对 Hugging Face 接口 API 的调查发现了一个重大风险，攻击者可以上传恶意制作的模型来执行任意代码执行。 这是通过使用 Python Pickle 文件实现的，该文件在反序列化时会执行嵌入的恶意代码。 这些漏洞凸显了需要采取严格的安全措施来检查和清理 AI-as-a-Service (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 自行决定。当前尚未发布的任何特性或功能可能无法按时提供或根本无法提供。