机器学习有希望改善我们的世界，而且在很多方面它已经做到了。然而，研究和生活经验继续表明，这项技术存在风险。过去仅限于科幻小说和学术界的能力越来越多地向公众开放。负责任地使用和开发人工智能需要在可行的情况下对列举的风险进行分类、评估和减轻。从纯人工智能的角度来看，这是真的，但从标准信息安全的角度来看也是如此。
在标准到位和成熟的测试站稳脚跟之前，各组织都在使用红队来探索和列举人工智能带来的直接风险。这篇文章介绍了 NVIDIA 人工智能红队的理念和 ML 系统的一般框架。
评估基础
我们的人工智能红队是一支由进攻性安全专业人员和数据科学家组成的跨职能团队。我们使用我们的综合技能来评估我们的 ML 系统，以从信息安全的角度识别并帮助减轻任何风险。
信息安全有很多有用的范例、工具和网络访问，使我们能够在所有领域加快负责任的使用。该框架是我们的基础，并将评估工作引向组织内的标准。我们使用它来指导评估（图 1 ）实现以下目标：
- 我们的组织关心并希望消除的风险得到了解决。
- 明确规定了所需的评估活动以及各种战术、技术和程序（ TTP ）。 TTP 可以在不改变现有结构的情况下添加。
- 我们评估范围内的系统和技术有明确的定义。这有助于我们保持对 ML 系统的关注，而不会偏离其他领域。
- 所有的工作都存在于一个单一的框架中，利益相关者可以参考该框架，并立即对 ML 安全性有一个大致的了解。
这有助于我们设定评估的预期，我们可能影响的系统，以及我们应对的风险。该框架并不特定于红团队，但其中一些属性是功能性 ML 安全程序的基础，红团队只是其中的一小部分。
具体的技术和哪些功能并不一定重要。重要的是，无论你是红队、漏洞扫描还是对 ML 系统进行任何类型的评估，一切都有一个地方可以去。
该框架使我们能够解决 ML 管道、基础设施或技术的特定部分中的特定问题。它成为一个向受影响的系统传达问题风险的地方：向上和向下，并为政策和技术提供信息。
任何给定的小节都可以在整个系统的上下文中进行隔离、扩展和描述。以下是一些示例：
- 规避被扩展为包括与特定模型类型的评估相关的特定算法或 TTP 。红色团队可以准确地指出受影响的基础设施组件。
- 技术漏洞可以影响任何级别的基础设施或仅影响特定的应用程序。它们可以根据其职能和相应的风险评级进行处理。
- 对许多信息安全从业者来说陌生的伤害和滥用场景不仅被包括在内，而且被整合在一起。通过这种方式，我们激励技术团队在评估 ML 系统时考虑伤害和滥用场景。或者，他们可以为道德团队提供工具和专业知识。
- 传递下来的需求可以更快地集成，包括旧的和新的。
这样的框架有很多好处。考虑一下披露流程可以从这种冷静的观点中获益。核心构建块是治理、风险和合规（ GRC ）以及机器学习（ ML ）开发。
治理、风险和合规
与许多组织一样， GRC 是信息安全工作的最高级别，可确保列举、传达和实施业务安全需求。作为一支打着信息安全旗号的人工智能红队，以下是我们感兴趣的高级别风险：
- 技术风险：ML 系统或过程由于技术漏洞或缺点而受到损害。
- 声誉风险：模型性能或行为对组织的反映很差。在这个新的范式中，这可能包括发布一个具有广泛社会影响的模型。
- 合规风险：ML 系统不合规，导致罚款或降低市场竞争力，就像 PCI 或 GDPR 一样。
这些高级别风险类别存在于所有信息系统中，包括 ML 系统。把这些类别想象成灯上的单独彩色透镜。使用每一种彩色镜片都可以从不同的角度看待底层系统的风险，有时风险可能是叠加的。例如，导致违约的技术漏洞可能会造成声誉损害。根据违约发生的地点，合规还可能需要违约通知、罚款等。
即使 ML 没有自己的漏洞，它仍然是在受 GRC 工作制定的标准约束的基础设施上开发、存储和部署的。组织内的所有资产都必须符合 GRC 标准。如果他们没有，理想情况下只是因为管理层提出并批准了一个例外。
ML 开发
堆栈的底部是 ML 开发生命周期，因为它是 GRC 想要深入了解的活动。我们通常将 ML 系统视为任何涉及 ML 的系统，包括构建模型的过程和系统。 ML 系统的组件可能包括托管用于推理的模型的 web 服务器、保存训练数据的数据湖，或者使用模型输出来做出决策的系统。
开发管道跨越多个系统，有时甚至是不协调的系统。生命周期的每个阶段在功能上都是唯一的，并且依赖于前一个阶段。正因为如此， ML 系统往往是紧密集成的，管道的任何一个部分的折衷都可能影响其他上游或下游开发阶段。
有更详细的 MLOps 管道，但规范的示例足以成功地将支持工具和服务与其生命周期阶段分组（表 1 ）。
| 阶段 | 描述 | 模型状态 |
| 理想 | 讨论、会议和对需求的意图。 | 前期开发 |
| 数据收集 | 模型需要数据进行训练。数据通常是从公共和私人来源收集的，并考虑到特定的模型。这是一个持续的过程，数据将继续从这些来源收集。 | 训练 |
| 数据处理 | 所收集的数据在被引入用于训练和推理的算法之前以任何数量的方式进行处理。 | 训练 |
| 模特培训 | 然后通过算法获取处理后的数据，并训练模型。 | 训练 |
| 模型评估 | 训练模型后，对其进行验证，以确保准确性、稳健性、可解释性或任何数量的其他度量。 | 训练 |
| 模型部署 | 经过训练的模型被嵌入到一个系统中，以便在生产中使用。机器学习以多种方式部署：在自主车辆内部、在 web API 上或在客户端应用程序中。 | 推论 |
| 系统监控 | 模型部署完成后，将对系统进行监控。这包括系统的可能与 ML 模型不直接相关的方面。 | 推论 |
| 生命的终结 | 数据转移、业务需求变化和创新都需要适当地中断系统。 | 后期开发 |
这种高级结构使风险能够被放入整个 ML 系统的上下文中，并提供了一些自然的安全边界。例如，在阶段之间实现权限分层可能会防止事件跨越整个管道或多个管道。无论是否妥协，管道的目的都是部署模型以供使用。
方法和用例
该方法试图涵盖与 ML 系统相关的所有主要问题。在我们的框架中，任何给定的阶段都可以交给一个技术熟练的团队：
- 现有的攻击性安全团队可能具备执行侦察和探索技术漏洞的能力。
- 负责任的人工智能团队具备应对伤害和虐待场景的能力。
- ML 研究人员具备处理模型漏洞的能力。
我们的 AI 红队更喜欢将这些技能汇总在同一支或相邻的队伍中。学习和效率的提高是不可否认的：传统的红队成员可以通过 学术论文 为数据科学家提供 漏洞披露（CVEs）。
| 评估阶段 | 描述 |
| 侦察 | 本阶段介绍了在 MITRE ATT&CK 或 MITRE ATLAS |
| 技术漏洞 | 所有你所知道和喜爱的传统弱点。 |
| 模型漏洞 | 这些漏洞通常来自研究空间，涵盖以下内容：提取、规避、反转、成员推断和中毒。 |
| 伤害和虐待 | 模型通常是经过训练和分发的，因此它们可能被滥用用于恶意或其他有害任务。模型也可能有意或无意地带有偏见。或者，它们不能准确地反映部署它们的环境。 |
无论哪个团队执行哪项评估活动，都将在同一框架内进行，并为更大范围的评估工作提供信息。以下是一些具体的应用案例：
- 解决新的即时注射技术
- 检查并定义安全边界
- 使用权限分层
- 进行桌面练习
解决新的即时注射技术
在这种情况下，大型语言模型（ LLM ）的输出被笨拙地放入 Python exec 或 eval 语句中。您已经可以看到组合视图如何帮助解决多个方面的问题，因为输入验证是防止即时注入的一层防御措施。
检查并定义安全边界
将每个阶段与安全控制分隔开来，可以减少攻击面，并提高对 ML 系统的可见性。一个示例控制可能是 pickle （是的，那个 torch 文件有 pickle ）在开发环境之外被阻止，生产模型必须转换为不太容易执行代码的东西，比如 ONNX 。这使得研发人员能够在开发过程中继续使用泡菜，但不能在敏感环境中使用泡菜。
虽然完全不使用泡菜是理想的，但安全性通常是妥协。在完全避免问题不可行的情况下，各组织应寻求增加缓解控制措施。
使用权限分层
在开发流程中，了解生命周期每个阶段的工具及其属性非常重要。例如，默认情况下， MLFlow 没有身份验证。在知情或不知情的情况下启动 MLFlow 服务器会打开该主机以通过反序列化进行利用。
在另一个例子中，Jupyter 服务器通常以禁用身份验证的参数启动，而 TensorBoard 没有身份验证。这并不意味着 TensorBoard 应该有身份验证。团队应该意识到这一事实，并确保制定适当的网络安全规则。
考虑开发管道内所有技术的范围。这包括一些简单的事情，比如 HuggingFace 等 ML 服务上的双因素身份验证。
进行桌面练习
考虑一下如何清空 ML 开发过程，只考虑您的技术、它们所在的位置以及将应用的 TTP 。沿着烟囱上下移动。以下是一些需要快速思考的场景：
- 部署的 Flask 服务器启用了调试权限，并暴露在 Internet 上。它托管了一个为 HIPAA 保护的数据提供推断的模型。
- PII 是作为数据集的一部分下载的，并且已经对几个模型进行了培训。现在，一位客户正在询问它。
- 一个包含几个 ML 工件（包括生产模型）的公共 bucket 对公众开放。它被不正确地访问，文件也被更改。
- 尽管模型是准确和最新的，但有些人可以始终绕过内容过滤器。
- 某个模型在某些地理区域的表现不如预期。
- 有人正在从用于托管 LLM 的推理服务器扫描内部网络。
- 系统监控服务检测到有人针对推理服务发送了众所周知的数据集。
这些可能有点做作，但要花一些时间把各种技术放在正确的桶里，然后通过方法论逐步提升。
- 这听起来像是技术漏洞导致的问题吗？
- 这是否会影响任何 ML 流程？
- 谁负责这些模型？他们会知道是否已经做出了改变吗？
这些都是必须回答的问题。其中一些场景似乎立即融入了方法的一个部分。然而，仔细观察，你会发现它们大多跨越多个领域。
结论
这个框架已经为您提供了几个熟悉的范式，您的组织可以开始围绕这些范式制定战略。通过有原则的方法，您可以为构建持续的安全改进奠定基础，从产品设计到生产部署，达到标准和成熟度。我们邀请您采用我们的方法，并根据您自己的目的进行调整。
我们的方法没有规定行为或过程。相反，它旨在组织他们。您的组织可能已经有了成熟的流程来发现、管理和减轻与传统应用程序相关的风险。我们希望此框架和方法能够为您识别和减轻组织中部署的 ML 组件带来的新风险做好类似的准备。
如果您有任何问题，请在下面发表评论或联系 threatops@nvidia.com。
