信息安全与很多其他科技厂商不同，其他科技领域，通常是业内领袖型公司拥有领先技术，并进一步带领整个行业发展，而信息安全领域，最顶尖的技术，通常掌握在一大部分骇客手里。于是乎，就出现了安全厂商需要不断追赶顶尖攻击技术的现象。本文探讨了英伟达在人工智能和信息安全规范的业务探索，给出了不错的思考框架，特别是攻防安全专家和数据科学家的跨领域团队配合模式，也是阿法兔选择翻译这篇文章的原因。
欢迎大家转发到朋友圈~~这样兔儿就更有动力发更多好内容了~
评估基础
研究和生活经验不断表明，人工智能和机器学习技术始终存在风险。过去仅限于科幻小说和学术界使用的能力正越来越多地为公众所用。想要负责任地使用和发展人工智能，就必须对所列举的风险进行分类、评估并在可行的情况下加以缓解。从纯人工智能的角度来看是如此，从信息安全规范的角度来看也是如此。
在标准制定和成熟测试形成之前，也有企业通过使用红队来探索和列举人工智能带来的直接风险，本文探讨的就是英伟达人工智能红队的理念和机器学习系统的总体框架。
英伟达人工智能红队，是由攻防安全专家和数据科学家组成的跨领域团队。通过综合技能的结合，进行机器学习的系统评估，以便从信息安全的角度，识别与降低风险。
通过制定信息安全框架，实现英伟达想要负责任应用AI的目标。下列框架（图1）是用于引导评估工作向组织内标准迈进的基础，主要用于指导和评估工作，从而实现下列目标：
解决整个组织关注且希望消除的风险。
明确界定所需的评估活动以及各种攻击者使用的特定策略、技术和程序 (TTP)，在不改变现有结构的情况下强化 TTP
明确界定评估范围内的系统和技术，从而专注于整个机器学习系统。
所有工作都规范在在单一框架内，任何利益相关者可以参考该框架，且能够对 ML 安全性有一个大致的了解。
这有助于我们设定评估预期，了解对潜在系统的影响，以及我们要应对的风险。注意，该框架并非专门针对红队，但其中一些特性是功能性机器学习安全计划的基础，而红队测试只是其中的一小部分。
图 1. 人工智能红队评估框架
重要的是，无论是红队评估、漏洞扫描，还是对机器学习系统进行任何形式的评估，图中都有相关体系。
这个框架使我们能够解决机器学习管道、基础设施或技术特定部分的具体问题，从而成为向受影响系统传达有关问题的风险的场所：在堆栈上下传递信息，并为政策和技术提供决策依据。
任何给定子集，都可以在整个系统的背景下进行分离、扩展和描述。
下列是部分场景：
规避可扩展至包括与特定模型类型评估特定算法或攻击者使用的特定策略、技术和程序，通过红队测试，可以准确指出受影响的基础设施组件。
而可以影响任何级别的基础设施的技术漏洞，也可以只影响一部分特定的应用程序，根据其功能进行处理，并进行相应风险评级。
对许多信息安全从业人员来说，陌生威胁和技术滥用情景，会被整合在一起。通过这种方式，鼓励技术工程团队在评估机器学习系统时，对各种危害和滥用场景进行考量。反之，也可以为机器学习伦理研究团队提供工具和专业知识。
更高效地将新旧需求整合。类似框架有很多好处，可以考虑披露流程如何从这一组成视图中获益。这里的核心构件是治理、风险与合规（GRC）和 机器学习开发。
治理、风险与合规（GRC）
治理、风险与合规，是信息安全工作的最高层级，它确保业务安全需求能够得以列举、传达并实施。作为信息安全领域下属的人工智能红队，以下是我们对信息安全工作最高层级风险的定义：
技术风险：人工智能系统或流程，因技术漏洞受到损害。
声誉风险：模型性能或行为对组织造成不良影响，这里包括发布具有广泛社会影响力模型所带来的潜在相关风险。
合规风险：机器学习系统不合规，比如说没有遵守GDPR（欧洲）或者PDI的条例，导致罚款或市场竞争力下降。
很多高级风险问题，在包括机器学习信息系统在内的许多系统都存在，如果我们把这些问题想象成灯上的各个彩色透镜。使用每种彩色透镜都能从不同角度了解底层系统的风险，这些风险有时候可能是叠加的。例如，导致漏洞的技术漏洞会造成声誉损失，根据漏洞发生的地点，合规性还可能要求进行漏洞通知、罚款等。
即使机器学习系统本身不存在漏洞，它仍然是在受 GRC 规定标准约束的基础设施上开发、存储和部署的。组织内的所有资产都必须符合 GRC 标准。
注释：GRC（Governance, Risk and Compliance，治理、风险和合规）
机器学习开发
最底层是机器学习开发生命周期，因为这是 GRC 希望深入了解的活动。这里通常将机器学习系统，视为任何涉及机器学习系统，包括构建模型的流程和系统。
一个机器学习系统的组成部分，包括托管推理模型的网络服务器、保存训练数据的数据湖、使用模型输出做出决策的系统。
而整个开发管道，是跨系统的，有时甚至是不协调的系统。开发管道的生命周期的每个阶段，既有独特的功能，又依赖于前一阶段。正因为如此，ML 系统往往是紧密集成的，管道中任何一个部分的问题都可能影响到其他上游或下游开发阶段。
表 1. 带有红队支持工具和服务的 MLOps Pipeline
这种高级结构，可将风险置于整个机器学习系统的背景中，提供一些自然的安全边界。例如，在各阶段之间实施权限分层，就有可能防止事件跨越整个管道或多个管道。无论是否受到破坏，管道的目的都是部署模型以供使用。
方法和应用案例
本方法试图涵盖与 ML 系统相关的所有主要问题。在我们的框架中，任何给定的阶段都可以交给有适当技能的团队：
现有攻防安全团队，可能具备执行侦查和探索技术漏洞的能力。
研究负责任人工智能的技术团队，具备处理危害和滥用场景的能力
机器学习研究员具备处理模型漏洞的能力。
我们的人工智能红队，倾向于将此类技能，集合在同个或联系紧密的团队中。
学习能力和效率的提高是毋庸置疑的：传统的红队成员能够参与学术论文的一部分，而数据科学家则获得了实战中的 CVE。
无论哪个团队执行哪项评估活动，都将在同一框架内进行，纳入更大的评估工作中。以下是一些具体应用案例：
处理新的提示词注入攻击（Prompt-injection）技术
检查和定义安全边界
使用权限分层
桌面演练
处理新的提示词注入攻击
大语言模型 (LLM) 的输出，被简单地放入 Python exec 或 eval 语句中，而输入验证是防止提示词注入攻击的防御层。 
图 2. 新的提示词注入漏洞可能同时涉及模型和technical Columns
检查并定义安全边界
通过安全控制，对各阶段进行划分，从而减少攻击面，提高机器学习系统的可见性。控制措施的一个例子可能是，在开发环境之外禁止使用 pickles（是的，torch 中有 pickle文件），而生产模型必须转换为不易执行代码的东西，如 ONNX。这样，研发人员就能在开发过程中继续使用 pickles，但在敏感环境中却无法使用。
虽然完全不使用pickles是最理想的，但安全往往是妥协的结果。
权限分层应用
通过安全控制，对各阶段进行划分，从而减少攻击面，提高机器学习系统的可见性。了解生命周期各阶段的工具及其属性非常重要。例如，MLFlow 默认情况下没有身份验证，容易产生风险。
另一个例子是，Jupyter 服务器通常使用移除身份验证的参数启动，而 TensorBoard 没有身份验证。这并不是说 TensorBoard 应该有身份验证。而是安全团队只是应该意识到这一问题，并确保制定了相应的网络安全规范。
考虑开发管道中所有技术范围。这包括在 HuggingFace 等机器学习服务上进行双因素身份验证等简单操作。
进行桌面测试
考虑排除机器学习开发过程中的其他因素，只考虑技术本身、它们所在的环境以及可能适用的方法、技术和流程。从上到下、从下到上地进行思考。以下是一些可供深入思考和分析的情景，供您深入思考：
一个Flask服务器被部署并启用了调试特权，然后暴露在互联网上，主要用来托管一个为HIPAA保护数据提供推理的模型。
个人可识别信息（PII）在数据集中被下载，并且已经有几个模型被用这些数据进行了训练。现在，一个客户正在询问相关情况。
一个公开的存储桶中包含了多个机器学习工件，包括生产模型，在未经授权的情况下对外开放。这个存储桶被不当访问，文件已被篡改。
尽管这些模型准确且更新，但某人可以持续地绕过内容过滤器。
某个模型在特定地理区域的表现不如预期。
有人从用于托管LLM的推理服务器上扫描内部网络。
系统监控服务检测到有人向推理服务发送了一个众所周知的数据集。
可以花些时间将上述例子中，不同的技术放入正确的类别中，然后按照方法逐步进行分析：
听起来像是技术漏洞导致的问题吗？
这是否影响了机器学习开发的流程？
谁负责模型？他们是否知道有更改发生？
这些都是必须回答的问题，并且，其中大部分问题都属于跨领域的。
结论
上述框架，可以为组织提供常见且熟悉的范例，可以开始围绕上述范例制定战略。通过原则性的方法论，构建从产品设计到生产部署的持续安全改进的基础，逐步构建标准与成熟度，上述方法论更建议您和实际工程与企业实践相结合。
上述方法论，并不对行为或流程进行硬性规定，而是要这些流程组织在一起。希望上述框架和方法论，同样能够帮助您识别与降低您在组织中部署的机器学习组件遇到风险的概率。
参考资料：NVIDIA AI Red Team: An Introduction | NVIDIA Technical Blog
声明：本文来自阿法兔研究笔记，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
