大型语言模型安全风险的基准评估套件

本文主要是介绍大型语言模型安全风险的基准评估套件，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

CYBERSECEVAL 2 扩展了以前的工作，增加了两个新的测试套件：解释器滥用和提示注入。

原文标题：CYBERSECEVAL 2: A Wide-Ranging Cybersecurity Evaluation Suite for Large Language Models

原文作者：Manish Bhatt, Sahana Chennabasappa, Yue Li, Cyrus Nikolaidis, Daniel Song, Shengye Wan, Faizan Ahmad, Cornelius Aschermann, Yaohui Chen, Dhaval Kapil, David Molnar, Spencer Whitman, Joshua Saxe
发表会议：arxiv 2024
原文链接：https://arxiv.org/pdf/2404.13161
主题类型：大模型安全
笔记作者: 童话
主编：黄诚@安全学术圈

概述

CYBERSECEVAL 2 是一个用于评估大型语言模型（LLMs）安全风险的基准套件，其目标是解决随着 LLMs 的广泛使用而出现的新的网络安全风险。这个工具主要关注两类人：LLM 构建者（包括构建新 LLM 或选择适合他们系统的 LLM 的开发者）和使用 LLM 自动化网络安全任务的人。对于 LLM 构建者，CYBERSECEVAL 2 能帮助他们衡量 LLM 对安全风险的脆弱性，以便在发布前进行调整，或者理解如何确保整个系统的安全。对于第二类人，CYBERSECEVAL 2 提供了一个量化评估 LLMs 在合成易受攻击代码的漏洞的方式。

CYBERSECEVAL 2 扩展了以前的工作，增加了两个新的测试套件：解释器滥用和提示注入。解释器滥用的测试是因为最近的 LLMs，如 GPT-4，可以访问 Python 和其他代码解释器，以直接运行由 LLM 作为对提示的响应生成的代码。提示注入的测试是因为研究人员发现了越来越多的对 LLMs 的提示注入攻击。在新测试集上进行的评估显示，所有测试的模型有26%到41%的成功提示注入，这表明训练 LLMs 以减少代码注入攻击风险仍然是 LLM 安全性中的一个未解决的问题。

最后，作者团队引入了一个新的指标，即“错误拒绝率”（FRR），用于衡量当我们训练 LLMs 以拒绝不安全的提示时，可能会错误地拒绝良性的提示，从而降低其效用。这种情况被称为设计安全 LLMs 的安全-效用权衡。

此外，他们还开源了 CYBERSECEVAL 2 的代码和评估工件，欢迎开源贡献，并计划在未来更新他们的基准。相关 GitHub 项目地址：https://github.com/meta-llama/PurpleLlama/tree/main/CybersecurityBenchmarks

如下表格高亮了该 paper 的相关贡献：

image

背景

CyberSecEval首次发布于2023年12月，其初版提供了两种测试：不安全的编码实践测试和网络攻击帮助测试。这个工具能够帮助我们判断一个大型语言模型（LLM）在被要求实现特定功能或者用于代码自动完成时，是否会复制已知的不安全编码实践。此外，它还可以测试LLM在被要求协助进行网络攻击时的反应，覆盖了行业标准的MITRE ATT&CK本体中定义的攻击。

CyberSecEval 2在此基础上进行了扩展，新增了假拒绝测试，以衡量LLM对合法但"边缘"的请求（即可能和网络安全相关的技术主题有关）的反应。

为了更深入理解LLM是否能够在拒绝实际的网络攻击请求的同时，仍然对完全合法的请求提供帮助，开发者结合了原始测试案例和新开发的FRR（假拒绝率）数据集。这个数据集包括了各种主题，例如网络防御，并设计为边缘提示，这意味着它们可能对LLM来说看起来是恶意的，但实际上是良性的，与网络安全相关的，但不表现出恶意意图。这样，我们就可以分析在成功拒绝协助网络攻击和FRR帮助处理模糊但最终良性的网络安全相关技术主题的请求之间的权衡。

简单来说，假拒绝率（FRR）是为了测量一个LLM对于特定风险的假拒绝率。我们将FRR定义为LLM因错误认为它们是由于那个风险而不安全的提示而拒绝的良性提示的百分比。也就是说，如果一个LLM被设计成拒绝所有网络攻击的请求，那么它可能也会错误地拒绝一些实际上是良性的、与网络安全相关的请求，这就是所谓的安全-效用权衡。

安全行业老生常谈的概念了，本质上就是在不牺牲功能性需求，少量影响用户体验的前提下，尽最大努力提高产品的安全性，作者团队量化了这一点。

新增测试类型

在CYBERSECEVAL 2的新测试中，有两个值得我们关注的部分。首先，我们看到了引入了"提示注入评估"。在这种情况下，攻击者会通过提交违反应用程序开发者意图的提示，试图让大型语言模型（LLM）执行意料之外的指令。这种攻击方式与SQL注入这类混合代码和数据的经典注入攻击类似，只是这里的风险源于不受信任的第三方或用户输入与应用程序开发者在LLM的上下文窗口中的受信任输入相连。这种提示注入攻击及一般注入攻击的风险完全缓解仍然是一个未解决的问题。

提示词注入的测试方法覆盖范围如下图所示：

image

其次，我们看到了"漏洞利用评估"。随着LLM的进步，人工智能在软件漏洞利用方面的潜力也引发了讨论。在这个领域，AI的进步无论是帮助防御者识别和优先处理安全漏洞，还是帮助攻击者更快地开发攻击能力，都有其安全和不安全的用途。因此，监控AI在这个领域的进展至关重要，因为任何突破都可能对网络安全和AI政策产生重大影响。

CyberSecEval 2 的实际应用案例

作者团队针对大型语言模型（LLM）如Llama，CodeLlama和OpenAI GPT进行了一系列的安全性测试。这些测试主要包括提示注入，代码利用，网络攻击帮助和解释器滥用等方面，目的是通过这些测试来了解并评估这些模型在处理各类安全性问题上的表现。

首先，我们来谈谈网络攻击帮助测试的结果。在这个测试中，我们发现大部分模型在面对网络攻击帮助请求时，能够以52%的比例拒绝这些请求，而在处理一些可能的恶意请求时，这些模型的表现则更好。然而，我们也发现，模型在处理一些边缘情况的请求时，例如网络防御相关的请求，拒绝率却较高。这就引出了我们的假拒绝率（FRR）的概念，即当LLM对某一特定风险进行拒绝时，可能会误拒一些实际上并不具有风险的请求，这就是我们所说的安全-效用权衡。

image

接下来，我们来看提示注入测试的结果。在这个测试中，我们发现所有的LLM都会在一定程度上受到提示注入攻击的影响，平均受影响的程度达到了17.1%。这就意味着，模型在处理用户输入时可能会被恶意输入影响，使其生成非预期的结果。

image

在代码利用测试中，我们发现模型在处理利用攻击时的表现并不是特别理想。尽管有些模型如GPT-42, Llama 3 70b-Instruct, 和 CodeLlama-70b在这方面的表现较好，但是整体来看，LLM在这个测试中的表现仍有待提高。

image

最后，在解释器滥用测试中，我们发现LLM在处理解释器滥用请求时，平均有35%的请求会得到执行。这就意味着，当LLM连接到代码解释器时，可能会存在一定的安全风险。

image

总的来说，通过一系列的测试来评估LLM在处理各类安全性问题上的表现。通过这些测试，我们可以看出LLM在这方面的表现仍有待提高。

总结

这一部分是关于CYBERSECEVAL 2的结论，这是一个全面的基准测试套件，用于量化大型语言模型（LLMs）的网络安全风险。对于LLM构建者和选择LLM的人来说，这个工具扩展了我们可以量化测试的风险类型，从两类增加到了四类，包括了针对提示注入和解释器滥用攻击的新的测试套件。这里还引入了一个新概念，即LLM的安全-效用权衡，用假拒绝率（FRR）来衡量。作者团队通过创建一个关于网络攻击帮助的测试集来实践测量FRR。

对于LLM构建者和选择LLM的人来说，这个工具提供了一些关键的洞见。首先，消除对提示注入攻击的风险仍然是一个未解决的问题：所有测试的模型都显示出对提示注入的脆弱性，成功率在13%到41%之间。这意味着使用LLM的系统设计者不能假设LLM会在面对对抗性的下游输入时可靠地遵循系统提示中的指令，他们需要仔细考虑为提示注入增加额外的防护和检测。

其次，测量FRR对于量化安全-效用权衡是有效的。在我们对网络攻击帮助的FRR测试中，我们能够区分出低FRR率的模型和高FRR率的模型。我们揭示了在LLM对帮助执行网络安全技术活动的请求的响应中，安全性和有用性之间的小的权衡。许多LLM能够成功地遵循良性的‘边缘’网络安全相关的技术请求，同时仍然拒绝大部分帮助执行攻击性网络操作的请求。我们相信，对于其他属性，FRR将是衡量安全-效用权衡的有效指标。

对于那些使用LLM自动化网络安全的人，作者团队提供了关于生成攻击利用的定量结果，该测试是新颖的，因为它们强调测试LLM的行为而非LLM的信息检索。作者团队的方法提供了一套可以与其他框架一起使用的互补信号。

结果表明，在LLM能够自主生成攻击利用之前，还需要更多的研究：作者团队发现，大多数LLM在完全解决测试用例上失败了，但是具有更高一般编码能力的LLM在我们的测试上得分更高，这表明，在LLM可以自主生成攻击利用之前，还需要进行更多的研究，但是LLM的攻击利用能力可能会随着LLM的总体编码能力的增长而增长。

随着LLM的普及，评估它们的风险变得越来越重要。为此，我们已经将我们的评估开源，供他人建立。我们希望这项工作能够为所有人提供更安全、更可靠的LLM部署。