通过

机器学习工程师的 AI 风险评估

  • 项目

尽管保护机器学习系统有令人信服的理由，但跨越 28 家企业的 Microsoft 调查发现，大多数行业从业者尚未接受对抗机器学习 (ML)。 28 家企业中有 25 家表示，他们没有适当的工具来保护机器学习系统。 而且，他们正在显式寻找指导。 我们发现，不只是较小组织缺乏准备，从财富 500 强公司、政府到非营利组织都是如此。 客户承认需要保护 AI 系统，但根本不知道该如何保护。

本文档是组织评估其 AI 系统安全状况的第一步。 但是，我们尝试以可以贴靠现有安全风险评估框架的方式提供内容，而不是为组织添加另一个框架。

本文档有三个目标：

  • 提供 AI 系统安全的全面视角。 我们在生产环境中查看了 AI 系统生命周期的每个元素：从数据收集、数据处理到模型部署。 我们还考虑了 AI 供应链以及与 AI 系统相关的备份、恢复和应变计划方面的控制措施和策略。
  • 概述对关键 AI 资产的威胁，并指导保护它们。 为了直接帮助工程师和安全专业人员，我们枚举了在 AI 系统构建过程的每个步骤中的威胁声明。 接下来，我们提供了一套指南，这些准则覆盖并强化了 AI 系统上下文中的现有做法。
  • 使组织能够进行 AI 安全风险评估。 该框架有助于收集有关组织中 AI 系统当前安全状态的信息，执行差距分析，并跟踪安全状况的进度。

我们将其与 Microsoft 的利益干系人结合在一起，与来自 Azure 安全、工程负责任的 AI 战略、Microsoft 安全响应中心、Azure 安全与 AI、工程与研究中的道德和影响 (Aether)。

介绍

我们建议使用本文档开始讨论如何保护符合正在进行的信息安全工作和业务目标的 AI 系统。 本文档重点介绍 AI 系统，并包含传统控制措施，因为 AI 系统是基于传统 IT 基础结构构建的。

我们介绍以下与 AI 系统相关的领域。

管理控制措施 说明
机器学习安全策略 与管理机器学习、人工智能和信息安全的已记录策略相关的控件和策略。
技术控制措施 说明
数据收集 与用于机器学习和人工智能的数据的集合、存储和分类相关的控件和策略。
数据处理 与用于机器学习和人工智能的数据的处理和工程相关的控件和策略。
模型训练 与模型的设计、训练和验证相关的控件和策略。
模型部署 与部署模型和支持基础结构相关的控件和策略。
系统监视 与机器学习系统持续监视相关的控件和策略。
事件管理 与如何处理与 AI 系统相关的事件的控件和策略。
业务连续性和灾难恢复 通过模型窃取、服务降级或其他 AI 特定漏洞来控制与知识产权丢失相关的控件和策略。

我们根据流行的 ISO27001:2013 标准调整了现有的控制措施和策略框架，并将其映射到从数据收集阶段到应对 AI 系统的威胁的 AI 系统构建过程。 组织可能从 ISO27001:2013 实施一些或所有现有控制措施，或者已符合多个风险框架（NIST 800-53、PCI-DSS、FedRamp 等），作为现有信息安全工作的一部分。

未能充分保护 AI 系统不仅会增加此评估中应对的 AI 系统的风险，而且更普遍地提高到整个信息技术和合规性环境的风险。

本文档的目标不是替换上述任何现有工作，而是从现有工具和框架的有利位置描述保护 AI 系统，并将其扩展到 AI 构建过程的所有部分。

此处列出的指南并不具有规范性，因为这将需要更多的上下文，例如基础平台、基础数据类型和算法的选择。 如果你是 Azure 机器学习客户，请参阅企业安全和治理一文。

建议的严重性、可能性、影响

并非所有控制措施都对 AI 系统的安全性至关重要。 因此，若要正确确定工作优先级，应按组织对每个控件进行分级，其严重性分级与不实现给定控件的业务影响有关。 组织可能会选择接受关键控件的风险，改为实施补偿控制来降低风险。 归根结底，这些评级有助于指导基于风险的决策，而不是规定活动。

Severity

泄露的严重性将取决于 AI 模型用例。 幸运的是，如果在集成机器学习之前使用的数据或系统极为重要，则它应该保持不变。 同样，如果使用的模型是没有其他输入的“现成”模型，则根据模型所使用的上下文，泄露的严重性可能较低。 差异隐私等技术可以减少泄露的潜在影响。 但是，此上下文不会降低系统、数据或模型的关键性。 建议使用深层防御策略保护模型，而不是依赖任何防御实现。

建议的严重级别

建议为关键

  • 如果对 AI 模型进行了训练，或者引入敏感个人数据、分类数据或合规性要求（如 PCI、HIPAA、GLBA 等）管理的数据。
  • 如果 AI 模型在业务关键型应用程序或系统中使用，那么这种泄露会对业务运营产生很大的负面影响
  • 如果在可能造成物理或伤害或死亡的应用程序中使用 AI 模型
  • 如果 AI 模型用于支持关键基础结构的系统（例如水、电力、运行状况）

建议为高

  • 如果 AI 模型经过训练或引入敏感数据、机密信息或组织认为至关重要的数据
  • 如果此 AI 模型的泄露会对业务运营产生较大但在范围之内的影响
  • 如果 AI 模型用于业务关键型应用程序或系统

建议为中

  • 如果对包含敏感数据类型的训练数据的子集训练 AI 模型
  • 如果此 AI 模型的泄露会对生产中部署的模型产生影响
  • 如果 AI 模型用于非关键但面向业务的应用程序
  • 如果 AI 模型未用于生产，但包含有关生产模型的信息

建议为低

  • 如果 AI 模型在生产环境中未使用的数据进行训练
  • 如果 AI 模型未用于生产，且不包含有关生产模型的信息

建议为信息性

  • 如果数据未从经过审查的源进行分类
  • 如果生产环境中未使用 AI 模型

可能性

可能性有两个主要组件：模型的可用性，以及技术的可用性。 为了减少攻击的可能性，组织应实施以下控制措施：

  1. 删除攻击面或使攻击面更难枚举。
  2. 确保日志记录和警报按设计工作，以确保快速解决问题。
  3. 确保所有支持系统都符合最新安全要求。

控件可能包括对终结点、网络分段或速率的限制。 应特别注意流量和网络或管道关系图，例如攻击者泄露和面向外部的终结点，并通过管道向后工作。

影响

影响与对组织的影响有关。 我们建议你开始熟悉机器学习系统受到攻击的不同方式，并考虑生产模型影响组织的方式。 有关详细信息，请参阅机器学习中的故障模式的文章。 熟悉后，可将其映射到严重性矩阵。

严重性矩阵

下表是启动组织的基本风险和漏洞严重性矩阵。 我们建议通过召集安全架构师、机器学习工程师和 AI 红色团队成员来填写类似的分类。

攻击类型 可能性 影响 可利用性
提取 高 低 高
规避 高 中 高
推理 中 中 中
反转 中 高 中
中毒 低 高 低

“设计和开发安全 AI 是 BCG AI 产品开发的基石。 随着保护 AI 系统的社会需求变得越来越明显，Microsoft AI 安全风险管理框架等资产可能做出基础性贡献。 我们已经在为客户开发的 AI 系统中实施在此框架中找到的最佳做法，并且很高兴 Microsoft 为整个行业的利益开发和开放了此框架。” —波士顿咨询集团高级安全工程师 Jack Molloy

基本用例

文档的其余部分遵循以下结构：

  • 风险控制包含控件涵盖哪些区域的说明。
  • 控件的目标及其应该实现的内容。
  • 威胁声明说明正在缓解的风险。
  • 用于实现控件的指导。 我们知道，并非所有指南都可以出于合法的业务原因来实现。 建议记录无法实现的指导。

下表是从 AI 系统风险评估中提取的控件，添加了说明来描述风险类别结构的每个部分。

示例控件

如何读取

1.数据收集

主类别

与用于机器学习和人工智能的数据收集和存储相关的控件和策略。

介绍此类别中的哪些控制措施涵盖较高级别。

2.数据源

控制类别

目标：确保用于定型模型的收集的数据的完整性。

应描述使用控制措施缓解的风险。

威胁声明：从可能包含敏感数据、可能影响模型安全性的其他不良数据或向组织呈现合规性风险的不受信任的源收集数据。

描述不实现控件的结果的语句。

控件：应从受信任的源收集数据。 应保留和更新的受信任的源的列表。 应逐个考虑收集不受信任的数据的审批。

描述控件最佳做法的特定谓词。

指导：

  1. 应尽一切合理的努力来确保在训练模型之前可以信任数据。 不受信任的或未知数据可能稍后会在管道中引入安全漏洞。
  2. 包含敏感数据的数据，无论是用于数据科学目的，还是应适当地清理或存储和访问。
  3. 在不考虑其上下文的情况下收集数据可能会导致包含非法数据的数据集。 数据收集工作应注意版权材料、数据泄露、意外泄露数据的不安全终结点。

指导是满足上述条件的建议。 我们以产品和供应商不可知的方式为他们提供，为组织提供空间，以对他们有意义的方式解决问题。

机器学习安全评估

开始之前

此评估的目的是帮助组织阐明、跟踪和修正 AI 系统引入的业务运营的风险。 此评估应该用于：

  1. 收集有关组织中 AI 安全当前状态的信息。
  2. 执行差距分析，并构建实施建议的路线图。
  3. 通过每年一次或两次执行此评估来跟踪安全进度。

如果组织没有安全计划，则不从此评估开始。 在实施此评估中的建议之前，组织应具有正常运行的信息安全计划。 有关详细信息，请参阅云采用框架中的 Azure 安全指南一文。

数据收集

与用于机器学习和人工智能的数据收集和存储相关的控件和策略。

目标：确保用于 AI 模型的收集的数据的完整性。

数据源

控件：应从受信任的源收集数据。 应保留和更新的受信任的源的列表。 应逐个考虑收集不受信任的数据的管理审批。 如果批准不受信任的源，则应记录该源。

威胁声明：从可能包含敏感数据、可能影响模型性能的其他不良数据或向组织呈现合规性风险的不受信任的源收集数据。

指导：

  1. 在 AI 系统中使用之前，应通过管理审批验证和信任输入数据。
  2. 在使用或存储之前，应先查看为 AI 系统收集的数据。
  3. 如果适用，应清理收集的数据，以便清除不需要的条目。
  4. 应记录数据源，并将其与数据一起保存。
  5. 用于训练模型的推理数据不应隐式信任，应被视为新数据。
  6. 应记录和审核数据收集工作。 收集的数据应具有一个所有者，负责其遵守记录的策略。

敏感数据类型

控件：确保 AI 系统存储的数据根据其敏感度和用例进行正确保护、跟踪和分类。 此控件包括适当的数据分类标签、访问策略、许可证信息、描述性统计信息、发起源和收集日期。

威胁声明：由于缺少必需的属性、元数据或文档，AI 系统中的数据被不当使用、存储或访问。

指导：

  1. 制定包含敏感数据类型的隐私和保护的数据策略，并将策略传达给参与 AI 系统使用或创建的所有人员。
  2. 实现训练和部署管道，以保护 AI 系统中使用的数据的机密性和完整性。

数据存储

控件：应根据记录的分类过程适当存储数据。 数据集应编制索引，并被视为受资产管理和访问控制策略约束的资产。

威胁声明：数据存储不安全，可以由未经授权方或系统篡改或更改。 数据未正确分类，导致机密信息或敏感个人数据泄露。

指南

  1. 确保开发或 AI 研究系统或帐户无法访问生产数据库，反之亦然。
  2. AI 系统中使用的数据应根据记录的分类策略进行分类和保护。
  3. AI 系统中使用的数据在记录的资产管理策略下进行跟踪。
  4. 用于敏感 AI 用例的数据存储在已批准和托管的系统上。
  5. 应审核对数据的访问权限，请求访问权限的用户应通过包括管理审批在内的正式访问控制过程。
  6. 机器学习过程中使用的数据不应向 Internet 公开。
  7. 从 Internet（或其他不受信任的源）提取的数据应通过包括管理审批的筛选过程。
  8. 数据集应随正式更改控制过程一起进行版本控制。

数据访问

控件：在使用之前，应通过加密哈希恰当跟踪和验证数据集。

威胁声明：数据集未经授权得到更改。

指导：

  1. 应强制实施数据集基于角色的访问控制。
  2. 执行常规访问审核，以确保有权访问数据集的帐户有权访问数据集。 确保每个帐户在正常边界内运行。
  3. 如果未使用中央跟踪平台，则应有目的地查看通过原始访问日志访问数据。 确保每个帐户在正常边界内运行。
  4. 第三方资源提供程序、承包商或其他外部方不应在没有合同的情况下对公司的训练/测试数据资产进行过度或不当的访问。

数据完整性

控件：数据集应受信任，且在整个 AI 系统生命周期内保持受信任状态。

威胁声明：数据集在 AI 生命周期内更改，且无法审核或跟踪更改。

指导：

  1. 数据集应具有唯一标识，以便对已批准的数据集进行未经授权的更改会导致对数据集进行评审。
  2. 数据集及其加密说明应在中心位置跟踪。 应审核对数据集的访问权限。
  3. 对数据集的更改应包括更新的加密说明和管理审批，然后再提交到中央跟踪服务。

数据处理

与用于机器学习和人工智能的数据的处理相关的控件和策略。

目标：确保将数据从原始形式安全处理成为准备训练的中间形式。

处理管道

控件：应充分保护处理管道。

威胁声明：威胁参与者可以通过更改数据处理管道对系统进行未经授权的更改。

指导：

  1. 并非所有通过生产系统移动的数据都与数据科学工作相关。 必须仅分析所需的数据，并确保正确跟踪从安全生产设置移动到开发设置中的所有数据。 请考虑某些类型的数据可能无法移动到开发环境中。 数据科学可能需要在安全的中间环境中发生。
  2. 在整个数据处理生命周期内正确审核数据访问非常重要。 如果没有单独的帐户，则无法对访问进行足够的审核。 此外，在不影响业务流程的情况下，无法应对事件。 单个帐户的泄露将导致所有数据泄露，导致安全生产环境丢失。
  3. 数据科学过程可能需要超出严格合规性边界的资源。
  4. 数据科学过程应始终符合现有要求。 此过程可能包括将数据科学资源和流程移动到合规的环境中。
  5. 应在整个生命周期内跟踪数据，此跟踪包括较大数据集的子集。 应要求将模型追溯到已训练的数据。 此外，该数据的副本应全部存在。

数据集光圈

控件：为了确保模型构建中包含的数据的子集（例如时态、分类切片）以及如何（通过隐私泄漏、过度强调反馈中毒/完整性等方式）来传达安全隐患。

威胁声明：威胁参与者可以通过重新构造/恢复数据子集来恢复部分数据。

指导：

  1. 数据的子集本身是数据集。 这些子集必须与父数据集附加相同的元数据，并且应该对敏感数据类型进行类似的评审。
  2. 根据有关机器学习实践（SLA、偏差指标等）的策略，任何给定数据集（包括子集）在模型构建中使用时，都应满足围绕这些指标的最低记录标准。 元数据应始终附加到数据集。
  3. 违反现有策略的所有数据集都应具有经管理批准的记录异常。 除了所需的元数据外，异常中还应包括异常的记录原因。
  4. 用于模型构建的所有数据都应在中心位置进行跟踪。 数据应随时可审核。 此外，发现针对未跟踪数据进行训练的模型应从生产中提取，直到它们与具有所需元数据的已知数据集匹配为止。
  5. 应适当地对数据集进行版本控制，以便更新所有元数据，并且数据的用户了解内容和统计属性。 如有必要，应要求对敏感用例进行管理审批。

模型定型

与模型和算法训练相关的控件和策略。

模型设计

控件：模型训练代码由责任方评审。

威胁声明：模型代码中的不当代码或漏洞会产生可用性、完整性或机密性风险。

指导：

  1. 模型设计和研究应在适当的环境中进行。 模型设计和体系结构可能会对模型的有效性产生很大影响。 生产环境不是研究或测试有关设计有效性的非可证明声明的地方。
  2. 生产系统的模型选择应由管理评审和批准。 此过程应在开发阶段的早期进行，应通过任何可用机制（Excel、DevOps、Git 等）进行跟踪。 应记录异常。
  3. 模型通常是特定于域的，并且在整个组织的全部应用中应有足够的文档随附模型。
  4. 确保用户可访问模型元数据，并记录和强制实施未经批准的模型使用。 只要正确附加和跟踪新的元数据，用户就能微调现有模型。

模型定型

控件：模型选择条件（指标和维持集）模拟自然偏移以及部署时可能预期的任何对抗条件。

威胁声明：在对抗设置中部署时，在理想条件下训练的模型可能很脆弱。

指南

  1. 训练和验证集应遵循自然时态依赖关系。 例如，对于恶意软件分类器，验证集应仅包含比训练集中包含的软件版本更新的版本。
  2. 通过将数据集与在野外合理发现的常见损坏扩充数据集，显式添加模型可靠性。
  3. 使用对抗性重新训练显式训练最坏的情况。
  4. 跟踪试验和关联的元。

模型选择

模型选择包括从一组候选项中选择一个模型，其中每个候选项都有一组独特的模型参数、训练算法和训练超参数。 获胜模型的选择条件通常基于单个可量化指标（例如，最小损失、最大检测率）作为测量的常见维持数据集或 K 折验证集的平均值。

控件：模型设计和训练算法包括显式或隐式模型正则化。

威胁声明：模型与训练和/或单一验证数据集过度拟合，更容易出现故障模式。

指导：

  1. 在计算可行的情况下，应使用 k-折交叉验证来防止过度拟合到单个保留集。
  2. 验证所选模型是否在不同的维持集上表现良好，以验证它们是否未过度拟合。
  3. 确保进程存在。

模型版本控制

控件：随着新的训练数据流入训练管道，模型会持续重新训练。

威胁声明：发生事件，但无法找到所涉及的模型进行调查。

指导：

  1. 进行模型版本控制，以便每次训练模型时，都会为其分配新版本。 应使用 my_model_dev_1.1 或 my_model_prod_1.1 等限定符来描述预生产模型的生产。 此版本控制有助于将问题隔离到生产或预生产问题。 引用现有的安全 SDL 进程或策略。

模型部署

与模型、算法和支持基础结构的部署相关的控件和策略。

安全测试

控件：投入生产的模型得到充分保护。

威胁声明：在部署之前，AI 系统未对漏洞进行充分测试。

指导：

  1. 尚未为新的 AI 系统、升级和新版本定义和记录正式验收测试标准。
  2. 应通过正式测试实现新的 AI 系统、升级或新版本。
  3. 自动化工具应用于测试信息系统、升级或新版本。
  4. 测试环境应尽可能类似于最终生产环境。
  5. 应记录独立安全评审的频率、范围和方法。

安全性和合规性评审

控件：基础网络的可靠管理是保护机器学习系统和基础结构的关键。

威胁声明：通过访问不安全的网络来泄露机器学习系统。

指导：

  1. 应将机器学习的网关设备配置为筛选域之间的流量，并阻止未经授权的访问。
  2. 应明确界定和记录相关的法定、法规和合同要求，并伴随具体控制措施和个人责任进行处理。
  3. 还应记录、实施或审查安全配置准则。
  4. 将机器学习网络隔离到域的标准应与组织的访问控制策略或访问要求保持一致。
  5. 应充分实施安全网关、VPN、机器学习系统的路由等机制，以实现分等级的控制措施集。
  6. 用户和机器学习工程师应采用或遵循实施控制措施的要求，以正确隔离和限制使用可公开访问的系统、内部网络和关键资产。

系统监视

与机器学习系统和支持基础结构的持续监视相关的控件和策略。

日志和日志评审

控件：出于安全原因，日志记录和监视对于机器学习系统至关重要。

威胁声明：在调查期间，找不到机器学习系统的日志。

指导：

  1. 日志记录和监视应在所有 AI 系统及其组件（包括存储、管道、生产服务器等）中持续发生。
  2. 应定期查看事件和安全日志，了解异常行为。
  3. 管理或安全代表应生成和审查有关系统活动的合并报表和警报。

事件管理

角色和职责

控件：应在中心位置收集安全日志。

威胁声明：在调查期间，安全分析师没有正式的 playbook。

指导：

  1. 组织必须遵循正式流程，在服务丢失、设备丢失、设施丢失、系统故障、系统过载、人为错误、不符合策略或准则、违反物理安全、不受控制的系统更改、软件故障、硬件故障和访问违规的情况下报告 AI 系统事件。
  2. 应制定正式的事件响应和升级过程，记录在收到信息安全事件报告时采取的操作。
  3. 事件响应过程应定期测试，跟踪响应指标。

业务连续性规划

规划、评审和结果

控件：确保可以在事件发生后修正和恢复机器学习系统。

威胁声明：事件会导致关键机器学习系统出现持久的机密性、完整性或可用性问题。

指导：

  1. 应识别并盘点关键 AI 资产。
  2. 组织应制定 AI 系统受到攻击时的业务连续性计划 (BCP) 或灾难恢复 (DR) 流程。
  3. 组织必须确定与攻击导致失去关键 AI 系统的影响相关的风险的优先级。
  4. 组织必须对关键 AI 系统的重复计划运行业务连续性测试。

参考

如有疑问、评论或反馈，请联系 atml@microsoft.com。

从 GitHub 存储库下载本文档的 PDF。