2021年6月25日

引言

2021年5月12日颁布的14028号行政命令《改善国家网络安全》要求国家标准技术研究院（NIST）发布“关键软件”一词的定义。

• 在本命令颁布45天内，商务部长（通过NIST院长）须在与国防部长（通过NSA局长）、国土安全部部长（通过CISA局长）、OMB局长以及国家情报总监讨论后发布“关键软件”一词的定义，并将其纳入根据本条（e）款制定的指南中。该定义应说明运行所需的权限或访问级别、与其他软件的集成和依赖性、是否需要直接访问网络和计算资源、影响信任的关键功能的性能以及受到入侵时可能导致的潜在损害。

该行政命令要求网络安全与基础设施安全局（CISA）依据所发布的“关键软件”定义，制定一份符合命令要求的相关软件类别和产品清单。

• 在根据本条（g）款发布定义后30天内，国土安全部部长（通过CISA局长）须与商务部长（通过NIST院长）讨论，确定符合依据本条（g）款发布的“关键软件”定义的当前正在使用或采购流程涉及的软件类别和产品清单，并提供给各机构。

为了让定义符合实际使用情况，NIST向相关人群征集意见，举办虚拟研讨会收集信息，与CISA、行政管理和预算局（OMB）、国家情报总监办公室（ODNI）和国家安全局（NSA）协商确定定义，提出分阶段实施的构想，并初步拟定了适用于初始阶段的通用软件类别清单。CISA和OMB将就如何根据行政命令应用该定义提供指导。NIST与CISA和OMB密切合作，确保定义和建议与相应计划一致。

本文从背景信息和“关键”一词的上下文入手，提出了分阶段实施的构想；根据行政命令的要求定义了“关键软件”一词，初步拟定了符合该定义的软件清单，并建议将清单纳入初始实施阶段。文章最后部分是常见问题（FAQ）解答。CISA将为初始和后续实施阶段确定最终的软件类别。

背景

最近发生的事件表明，联邦政府必须加大力度，查明、阻止、防护、检测和响应恶意网络行动和攻击者。尤其需要注意的是，威胁行为者会利用普遍使用的软件、复杂的底层代码以及软件开发和分发活动发动攻击。本文所述行政命令有多个目标，包括协助制定安全基线，确保联邦政府使用的关键软件产品的安全。软件被标为“EO-关键”后，后续会有一系列其他活动，包括联邦政府如何购买该关键软件以及部署后如何进行管理。重点是，该行政命令着力对软件购买进行限制，只允许购买满足安全措施的软件，例如采用了命令第4（e）款中定义的安全开发流程和完整性检查。

由于命令覆盖范围广泛以及对政府运行和软件市场有潜在影响，NIST对于定义“关键软件”设定了以下目标：

• 清晰–该计划的实施将推动整个联邦政府的活动，并对软件行业产生影响。提供清晰的定义供软件行业和政府使用，这对命令的成功实施至关重要。
• 可行–实施命令时必须考虑到软件行业的运行机制，包括产品开发、采购和部署。软件市场是动态变化、不断发展的，软件的开发、引入和使用方式也在快速变化。软件可作为产品、产品的一部分或服务购买。软件通常是模块化的，包含许多组件。

“关键”一词有许多现成的定义和用法。大多数是围绕技术如何支持各种任务或流程，如“关键安全”或“关键基础设施”。本文所述命令中该术语的用法略有不同，它不是基于软件的使用方法，而是基于特定软件的属性，这些属性使得软件在大多数用例中都是关键存在。也就是说，它主要针对的是与网络运营和安全基础设施相关的关键功能。这与“高价值资产”计划下的“联邦民用企业基本IT”的概念类似。

为了将行政命令下的“关键”定义与该词的通用用法区分开来，在容易混淆时，我们将会使用“EO-关键”一词进行明示。

方法

考虑到软件市场的规模、范围和复杂性以及政府实施行政命令所需的基础设施，NIST已与关键机构就分阶段实施EO-关键软件供应链安全保护的设想进行了沟通。通过这种分阶段方法，联邦政府和软件行业能够循序渐进地实施行政命令，及时提供反馈，逐步改进流程。

定义和说明材料

本节对EO-关键软件进行了定义，并通过表格初步列出了软件类别以及说明信息，供初期实施时参考。之后，CISA将根据定义提供软件类别的权威列表，用于初始实施阶段。该权威列表拟定后，将在此处提供链接。

最后，本文列出了有关定义解释、分阶段方法等方面的常见问题并进行了解答。

EO-关键软件是指包含一个或多个组件或与一个或多个组件具有直接软件依赖关系、且具有下述任一属性的软件：

• 需要以提升的权限或管理权限运行；
• 对网络或计算资源具有直接或特权访问权限；
• 可控制对数据或运营技术的访问；
• 所执行的某项功能对信任至关重要；或
• 使用特权访问权限在正常信任边界之外运行。

该定义适用于为生产系统购买或部署各种形式的软件（如单机软件、特定设备或硬件组件的集成软件、基于云的软件等）用于运营目的。其他用例（例如软件仅用于研究或测试，没有部署在生产系统中）不在本定义范围之内。（参见FAQ #10和?FAQ#11.）

NIST建议，初始实施阶段将重点放在本地部署的单机软件上，这些软件具有关键安全功能或在遭到破坏后会造成类似的重大潜在危害。后续阶段可扩展到其他类别的软件，例如：

• 控制数据访问的软件；
• 基于云的软件和混合软件；
• 软件开发工具，如代码库系统、开发工具、测试软件、集成软件、打包软件和部署软件；
• 引导级固件中的软件组件；或
• 运营技术（OT）中的软件组件。

下表初步列出了EO-关键软件类别，用以说明如何按上文建议初步实施EO-关键软件定义。如前所述，CISA将在稍后提供软件类别的权威列表。

常见问题

以下问题在与OMB和CISA讨论后确定，作补充说明之用。

1. 下一阶段何时开始？

CISA和OMB将会监控计划的初期实施情况，决定何时加入其他软件类别。

2. 定义中的“直接软件依赖”是什么意思？

对于特定组件或产品，“直接软件依赖”指的是直接集成到该软件实例中、且该软件实例运行所必需的其他软件组件（如库、包、模块等）。这并不是对依赖关系的系统定义，也未涵盖独立产品的接口和服务。

3.?定义中的“对信任至关重要”是什么意思？

“对信任至关重要”包括用于安全功能的软件类别，如网络控制、端点安全和网络保护。

4.?软件产品在云中、本地或混合环境中部署有什么不同吗？

没有。如果产品或服务提供的功能符合EO-关键定义，那么无论其部署模式如何，产品或服务本身都视为EO-关键。

尽管如此，NIST建议，命令的初始实施阶段应将重点放在本地部署的软件上。许多本地产品依赖于云组件和服务来执行EO-关键功能（例如基于云的访问控制）。在这种情况下，如果本地组件直接执行EO-关键功能，则为关键组件。建议在后续实施阶段考虑云组件和系统，留出时间与此类系统的其他联邦要求（如FedRAMP）进行协调。

5.?开源软件有可能是EO-关键软件吗？

有可能。如果开源软件执行的功能属于EO-关键功能，那么该软件就是EO-关键软件。实际应用中，开源软件常集成在其他产品中。这种情况下，产品开发人员将开源组件视为开发过程的一部分。有时候，开源软件为独立产品。这种情况下，行政命令的要求仍然适用。如果支持该产品的开源社区没有或无法满足第4（e）款中的某些要求，政府可能需要介入。

6.?政府开发软件有可能是EO-关键软件吗？

有可能。联邦政府通过内部和合同开发软件，这些产品通常被称为GOTS（政府现成）软件。如果GOTS软件执行的功能属于EO-关键功能，那么该软件就是EO-关键软件。虽然行政命令第4条未对商用和GOTS软件进行区分，但GOTS软件的开发和采购方式可能要求针对EO-关键软件制定的标准、程序和标准在这方面有所区分。

7.?如果一个产品只包含部分EO-关键功能，产品怎么定性？

产品若包含EO-关键定义中的功能，就属于EO-关键产品。不过，某些EO-关键软件产品可能包含特殊组件，这些组件不具有EO-关键属性或不直接支持产品提供的EO-关键功能。开发人员证明其产品具有第4（e）款要求的安全措施时，可以明确说明产品的哪些组件为EO-关键组件，具有这类安全措施，而哪些组件不是。当然，这可能会导致各厂商对如何划定证明范围理解不一致，但只要厂商明确了哪些组件要进行证明、哪些不需要即可。

8.?软件若作为另一产品的组件购买应如何处理？

产品若执行EO-关键定义中的功能，就属于EO-关键产品。在证明实施了第4（e）款中规定的安全措施时，厂商可以具体说明其产品的哪些组件实施了这些措施。这其中可能包括由其他方开发的组件。例如，如果政府欲购买包含操作系统的产品，那么该产品为EO-关键产品，需要证明实施了安全措施，但此等证明可仅限于操作系统。参见FAQ #7。

9.?该计划如何与FedRAMP协调？

行政命令第3条涉及FedRAMP的现代化。建议的分阶段方法从本地软件开始，可能会包括一些依赖云托管组件的本地软件。CISA将与FedRAMP协调，确定行政命令在后续实施阶段对基于云的软件的适用范围。

10.?该定义排除了未在生产系统中部署用于运营目的的软件。能进一步解释一下吗？

有几种用例，共同点是拥有软件，但部署方式决定了软件即使被入侵也不足以构成重大的危害风险，例如，作为研究对象的软件和为存档目的收集的软件。也就是说，政府可以购买EO-关键软件用于这些非运营目的，这种情况下，即使厂商没有实施或证明采用4（e）款中的安全措施也无妨。

11.?国家安全系统（NSS）中使用的软件呢？是否包含在内？

行政命令第9条描述了行政命令要求对国家安全系统的适用性。

12.?嵌入式软件或固件有可能属于EO-关键定义范围吗？

有可能。若嵌入式软件或固件执行EO-关键定义中的功能，就属于EO-关键软件或固件。考虑到此类产品的复杂性，我们建议在初始实施阶段排除此类软件。

13.?各部门和机构难道不应该根据支持机构任务的软件使用方法来判断软件是否属于EO-关键定义范围吗？

不。对EO-关键的定义是基于软件的功能，而不是其使用方式。这样，软件厂商无需了解具体的采购和部署方式便能确定其产品是否为EO-关键软件，进而按照第4（e）款要求行事。这会避免市场产生误解。否则，政府在采购时可能无货可买或可选范围很小，因为厂商没法预知产品是否为EO-关键软件。表中定义的EO-关键软件类型适用于大多数情况。

14.?关键安全系统等高保证系统是EO-关键系统吗？

关键安全系统等高保证系统包含很多类型，许多都有法规或行业安全要求。如果这些系统使用包含EO-关键功能的软件，则该软件是EO-关键软件。关键安全与高保证软件和系统会有额外的安全要求。例如，如果高保证系统包含操作系统，而因为操作系统属于EO-关键软件，则该系统除了要满足关键安全或其他系统要求外，还必须满足EO-关键要求。

15.?如果我使用的软件产品未包含在EO-关键清单中，但对我来说是关键的，我可以要求厂商提供证明吗？

可以，各部门和机构可在采购中加入第4（e）款中定义的EO-关键安全措施。