发现提示注入漏洞： 判断LLM是否能通过特别制作的输入被操纵，以绕过安全指令或执行非预期动作。例如，它能否被诱导泄露其系统提示？
评估有害内容生成抗性： 测试LLM生成偏颇、歧视、仇恨或促进非法活动回应的倾向，即使在良性或对抗性提示下亦如此。
评估安全防护措施的有效性： 如果LLM系统包含输入过滤器、输出清理器或其他防御机制，评估其可靠性并找出绕过方法。
测试敏感信息泄露： 判断LLM是否能被诱导泄露其训练数据或可访问的机密信息（例如，个人身份信息 (PII)、专有算法或公司内部数据）。
审查越狱可能性： 研究LLM内置限制和道德准则被规避的难易程度，以使其遵循不当请求。
评估生成错误信息的可能性： 评估模型是否能被提示生成看似合理但虚假的信息，以及其生成此类信息的容易程度。
验证针对特定威胁行为者角色的控制措施： 模拟来自特定类型对手（例如，心怀不满的员工、外部活动家）的攻击，看其可能采取的TTPs（战术、技术和程序）能否成功。

制定目标时，可考虑使其符合SMART原则：

具体 (Specific)： 清楚说明将测试什么以及出于什么目的。不要用：“测试不良输出。” 要用：“判断LLM是否能被诱导生成创建钓鱼邮件的指令，从而绕过其内容安全过滤器，造成经济损失。”
可衡量 (Measurable)： 定义如何判断成功或失败。示例：“在每个类别20次尝试内，成功引出三种不同类型的有害内容（例如，仇恨言论、自残建议、宣传非法行为）。”
可实现 (Achievable)： 确保目标在可用时间、资源和LLM访问权限的条件下是实际可行的。
相关 (Relevant)： 目标必须与组织的风险状况和LLM的预期应用相符。测试与LLM用例不相关的漏洞可能会造成资源错配。
有时间限制 (Time-bound)： 明确达成目标的时间框架。这通常是整体测试时间表的一部分。

这些目标通常源于与各种利益相关者的讨论，包括LLM开发人员、产品经理、法律团队和现有安全团队。他们的意见对于确保红队专注于真正受关注的方面具有重要意义。

定义测试范围

目标设定后，下一步是定义范围。范围界定了红队测试的边界：包括哪些系统、模型、接口、数据和技术，以及同样重要的，排除哪些内容。

定义LLM红队测试范围时需考虑的重要要素：

目标LLM和版本：
- 正在测试哪些特定的LLM或模型？（例如，gpt-4-turbo、claude-3-opus、定制微调的llama-3-70b-instruct）。
- 特定的版本或部署实例是否在范围内？（例如，暂存环境中的模型与生产环境中的模型）。
- 它是基础模型、微调变体，还是集成到更大应用堆栈中的LLM？
接口和访问方法：
- 红队将如何与LLM交互？
- 示例：直接API访问（例如，REST端点）、Web应用程序UI、聊天机器人界面、SDK。
- 将提供什么级别的访问权限？（例如，用户级、管理员级——如果测试管理员界面，黑盒、灰盒或白盒）。
将考察的攻击向量：
- 哪些类别的攻击（如第2章所述）在范围内？
- 示例：提示注入、越狱、试图引出偏颇输出、探测训练数据泄露。
- 针对支持基础设施（例如，API网关、如果LLM使用RAG的向量数据库）的攻击是否在范围内，还是仅仅专注于LLM的直接输入/输出行为？
数据考量：
- 红队可以尝试输入或渗透出哪些类型的数据？
- 是否允许与真实的敏感数据交互，还是只能使用模拟/测试数据？这是一个需要明确批准的重要事项。
- 对存储或处理从LLM获取的任何数据是否有限制？
允许使用的技术和工具：
- 对可以使用的工具或技术类型是否有任何限制（例如，自动化模糊测试工具、特定开源工具）？
- 本次测试主要涉及手动提示构造，还是会采用自动化方法？
范围外元素：
- 明确列出不属于本次测试的内容。这可以避免误解。
- 常见的范围外项目可能包括：
  - 针对生产系统的拒绝服务（DoS）攻击。
  - 对后端云基础设施的攻击，除非另有说明。
  - 对人员的社会工程攻击。
  - 直接攻击训练数据管道（除非数据投毒测试明确为目标）。

以下图表说明了LLM系统的不同组件如何被归类为典型红队测试（侧重于基于提示的攻击）的范围内或范围外。

此图显示了一个典型的LLM系统配置。绿色组件通常在基于提示的攻击范围内，黄色组件可能根据目标而有条件地包含在内，而灰色组件在此类场景中通常不在直接攻击范围内，但它们与LLM的交互可能仍有关联。

目标与范围的关系

目标和范围并非孤立地定义；它们之间有着密切的联系。

目标驱动范围： 如果一个目标是测试从连接的知识库中进行数据渗透，那么LLM与该知识库的接口必须在范围内。
范围限制目标： 如果红队只能黑盒访问LLM（意味着无法了解其内部工作原理或训练数据），那么需要白盒分析（如基于梯度的攻击）的目标是无法达成的，应将其排除在范围之外。

这通常是一个迭代过程。您可能会从一个广泛的目标开始，然后根据在时间和资源限制下哪些系统部分可以实际包含在范围内来细化它。

记录目标和范围：行动规则

所有这些细节、目标、范围（包含和排除）、时间表、允许的技术以及任何其他限制，都必须正式记录。这份文件通常被称为“行动规则”（RoE）或包含在“工作说明书”（SoW）中。

这份文件有以下几个目的：

为红队提供明确的授权。
确保所有相关方（红队、系统所有者、管理层）达成共识。
在测试期间出现问题或争议时，作为参考依据。
有助于定义行动的成功标准。

在开始任何红队测试活动之前，获得所有相关利益相关者对此文件的正式签署是标准做法。

设定目标和范围的常见难点

定义目标和范围并非总是一帆风顺。请留意这些常见挑战：

范围蔓延： 随着测试的进行，可能会发现新的、有趣的攻击向量或漏洞，这些在技术上超出了初始范围。重要的是要么坚持商定的范围，要么正式讨论并批准任何修改。
模糊性： 目标或范围中的模糊语言可能导致误解。力求精准。例如，不要说“测试API安全性”，而要具体说明“测试/v1/chat API端点的提示注入漏洞”。
范围过宽： 试图在一次测试中测试“所有内容”可能会分散注意力，并导致表面化测试。通常，进行多次有针对性的测试效果更好。
范围过窄： 如果范围过于受限，可能会遗漏重要的漏洞。这时，了解LLM的完整背景和可能的集成点就变得很重要。
资源不匹配： 定义的范围和目标可能对于分配的时间或团队规模来说过于宏大。需要定期进行实际情况核查。

迈向实际应用

掌握如何设定明确目标和定义精准范围，是任何LLM红队人员的基本能力。这些原则为构建有组织且高效的测试过程奠定了基础。随着您学习本课程，特别是在本章末的实践练习中，您将有机会将这些理念应用于模拟的LLM红队测试场景。通过精心规划您的测试，您可以最大化红队工作的价值，并为LLM系统的安全保障做出有益贡献。

这部分内容有帮助吗？