【国际视野】美国宇航局发布新版《太空安全：最佳实践指南》

《空间安全： 最佳做法指南》（BPG）以原则和适用控制措施的形式为飞行任务安全实施提供指导，这些原则和控制措施涵盖航天器和地面段。该指南利用了国家标准与技术研究所（NIST）特别出版物（SP）800-53中定义的安全控制措施，并作为NIST 措辞与NASA 飞行项目术语之间的翻译指南。

本指南适用于所有任务、计划和项目，无论其级别如何。鼓励任务、计划和项目将本文件作为太空安全原则的基线。虽然本文件仍然是指导性的，但将对这些原则和控制措施进行评估，以便将其纳入NASA 机构标准和要求的主体中。 图 1显示了影响任务管理人员风险和计划决策的文件映射。

由于空间飞行任务和地面段在结构、开发（生命周期）和操作方面存在重大差异，本文件同时阐述了空间飞行任务和地面段的原则。

目前，《最佳做法指南》将在企业保护计划的主持下，与信息和外联办公室协调发布，并将收集有关原则的反馈意见，目的是将这些原则纳入NASA 官方标准。该标准将按照NASA-STD-1006的制定方式制定。预计这一进程将加快，以满足正在积极设计和制定其技术原则的飞行任务的需要，以及行动者迅速发展的能力。

企业保护计划和首席信息官办公室对动词原则的实施定义如下：

“应该”用于表示良好做法或目标，是可取的，但不是强制性的，不需要正式验证。应用于有效载荷时，用"应该"来说明为促进有效载荷任务的整体成功而指定适当硬件和软件接口的要求。不遵守"应该"声明可能会导致运行限制或无法实现有效载荷目标。

本《最佳实践指南》中列出的控制措施采用由三部分组成的命名模式。第一部分确定原则的适用范围，包括任务、地面或管理。第二部分确定该原则适用于系统的哪个部分。最后一部分是原则的顺序号。

除原则语言和基本原理外，还有四项附加信息（控制措施）：

有七种威胁行为者能力与最初的《航空航天技术操作报告》（Aerospace TOR-2021-01333）相关联，网络攻击者可调用多种能力：

此外，还探讨了MITRE ATT&K 威胁行动者战术(https://attack.mitre.org/)，为读者提供潜在的缓解途径。从工业控制系统（ICS）或操作技术（OT）中引入了十二种战术。为什么要在太空任务系统中使用ICS 或OT 战术，而不是传统的网络安全战术？ICS和OT系统对时间的要求与太空任务系统非常相似，而且通常是联网在一起的。太空任务系统通常在各种处理器上安装多个操作系统，而这些操作系统通常不受保护（指令链路除外）。此外，由于政府和商业开发的航天器目前在设计中都采用了TCP/IP 和UDP等通用标准和架构，以实现系统互联和通信。此外，人工智能（AI）和机器语言（ML）应用等较新技术的融入将有可能扩大保护需求。随着未来系统集成和互联的不断发展，从信息系统和操作技术的角度来考虑航天器是非常重要的。要保护日益复杂的空间系统，就必须调整和实施与设计、预期操作、互连和零信任观点有关的最佳实践。使用的MITRE ATT&CK 威胁行为者战术包括：

最后，空间飞行任务安全和保护关键性能参数用于完善基于风险的方法。这些关键性能参数分为三个领域或支柱，以确保太空任务系统的生存能力/复原能力：

由于目前还没有针对端到端综合太空任务系统的风险管理框架，这四种做法的结合为太空任务提供了知情风险管理框架的雏形。这种组合最终将使工程师、项目经理和领导者能够在一个类似于其他风险决策系统的基础上，对太空任务的网络安全和保护做出明智的风险管理决策。该系统将在第二版指南中开发。

2021 年10 月至12 月期间，来自企业保护计划(EPP) 和首席信息官办公室(OCIO)的团队成员努力使人们认识到需要为空间任务和地面段网络安全控制提供明确定义的指导。这一过程以制定共识方法为明确目标，与整个机构的利益相关者会面，征求意见并要求参与未来的工作组。工作组利用现有研究、参考资料和已完成的工作，具体如下：

通过与主要利益相关方举行多次反馈会议和修订草案，最终为《空间安全》确定了27 项控制措施： 最佳实践指南》（BPG）。最终文件已于2023 年10 月格式化并送出审批。

如果本文件的原则和控制措施与用于创建本文件的参考资料之间发生冲突，则本文件的原则为最佳做法，不得取代参考文件。解决任何优先顺序冲突的办法是使用豁免和偏离，或由任务经理酌情决定。然而，本文件中的任何内容都不能取代适用的法律和法规，除非有特定的豁免规定。

治理原则和控制措施涉及任务、计划、项目中应处理的总体任务、计划、项目主题。

本节介绍与治理相关的各项原则和相关控制措施。

原则： 作为一种最佳做法，应在整个任务期间建立一个持续的定性和定量的任务安全风险分析和风险应对流程。

原理：静态的网络安全防御不足以迅速适应不断变化的风险条件，如发现新的网络行为体模块化攻击工具包，并有能力在很短的时间内为全新的平台整合目标攻击包。这一要求要求设计和运行一种网络安全防御的组织模式，该模式可快速整合整个生命周期和工具包中的新信息，以重新配置架构、设计、测试、部署、补丁、监控、分析、警报和响应活动的触发、重点和自动化方式。

空间飞行任务原则将是适用于空间飞行器、天基托管有效载荷或天基基础设施或架构的原则。

本节介绍与太空任务有关的各项原则和相关控制措施。

原则：应建立并维护一个最新的、准确的数据流图，涵盖任务基本数据流，包括那些通过任务外部服务供应商的数据流。

原理：好的数据流图能让人了解系统需要哪些数据，以及这些数据如何在网络和通信链路中流动。

原则：任务应在机载结构、通信和控制方面采用域分离和最小权限原则。

原理：最低权限设计将通过限制共享总线和车载网络上可执行的操作，保护车辆的主处理器和核心控制功能免受攻击。车辆上的分段和边界控制将减轻对采购或提供的组件和不同来源的车载软件的供应链攻击，以及在有多个命令路径时的操作漏洞。

原则：飞行任务应建立中介访问机制，防止未经授权访问空间段的关键子系统。

有效的边界保护除了某种形式的身份验证外，还应/将会包括使用加密（如NASA STD 1006所定义）的保密保护。这种边界保护还需要包括空间飞行器方面的保护，以防止地面被用作攻击载体。需要解决地面和空间飞行器之间固有的信任问题，即在地面受到攻击时，空间飞行器能够保护自身不受地面攻击。每个任务都应确定/定义其最关键的子系统。关键子系统或控制界面应具有任务关键控制界面之间的中介访问权限，可通过物理或软件手段造成任务终结故障/后果。

原则：飞行任务应确保只有经过认证和授权的人员、设备和软件才能访问空间飞行任务系统。

虽然这一控制的理由似乎更多的是以地面为中心，但在空间 在太空任务系统的开发过程中，任务人员将需要该控制中列出的访问权限。

原则：任务应将机载网络行为体行动探测功能纳入其要求和最终系统。

原理：任务应为安全事件可能造成的机载干扰制定计划，并纳入这些考虑因素。事件检测、缓解和向地面段安全运营团队发出警报是至关重要的控制措施，可使运营团队在其他控制措施失效时了解情况，并（在可能的情况下）迅速做出反应。由此获得的经验教训应反馈到设计过程中。需要监控关键软件观测指标（如登录尝试失败的次数、飞行接收器的计划外锁定、非电信设备上的射频干扰迹象、性能变化、内部通信变化），以发现阻碍任务成功的网络攻击者行动。

影响机上系统组件的网络安全攻击是意料之中的。网络安全事件响应计划是及时有效应对网络安全攻击的关键。应报告所有疑似网络攻击者的行动。应进一步分析原始事件数据，以确定异常事件是否代表攻击，如果是，则应确定攻击的性质以及适当的应对措施，以减轻对任务的影响。确保任务遵循NPR 7150.2 关于软件检测网络攻击者行动的指导，如3.11.8 中的指导。

原则：飞行任务应将故障管理旁路保护纳入其要求和最终系统。

原理：应考虑故障管理转换绕过系统保护措施的可能性，并纳入这些考虑因素。故障管理系统可能会被故意触发，以绕过系统的保护措施。

原则：任务应能从通信干扰和欺骗企图中恢复。

原理：使用共享介质的通信系统很容易受到干扰和欺骗，导致无法访问（拒绝服务），并有 可能丧失数据的完整性和可用性。射频和光学频段的通信链路普遍受到影响，通信链路可能受到有针对性的欺骗。

原则：任务应能从定位、导航和定时干扰及欺骗企图中恢复。

原理：作为MI-INTG-01的一个具体例子，依靠全球导航卫星系统信号的天基定位、导航和定时 （PNT）可能会出现信号丢失（拒绝服务）和信号数据完整性可能丢失的情况。操纵（欺骗）GNSS信号数据可能会对航天器PNT 造成影响。

原则：飞行任务应在飞行段及地面段的异常检测、响应及恢复计划与设计中，包含与任务脆弱性分析一致的故意中断。

原理：完整的纵深防御架构包括航天器在发生影响飞行或地面系统的安全事件时保持安全运行的能力，以及在事件解决后恢复到额定状态的能力。在机载故障处理、异常响应和持续运行规划中，应将安全事件与设备故障、环境事件、自然灾害和其他干扰源一并考虑，以确保任务的恢复能力。

原则：任务应设计安全的车辆故障管理功能和安全模式操作。

原理：故障管理系统是网络攻击的目标之一： 故障管理系统是网络攻击者试图入侵的目标之一。尽早为这些系统设计安全功能至关重要。

安全问题也应被视为故障管理系统捕捉到的系统故障的潜在根本原因，故障响应的设计应将安全事件与系统故障的其他原因一并考虑。

原则：任务系统软件更新应在部署、发射前及任务运行期间的规定时间间隔内进行验证，以确保不含恶意软件。

原理：在轨软件更新/升级/补丁以及所有软件更新在加载前均应进行恶意软件检查。此外，通过供应链攻击注入空间飞行器软件模块的恶意软件可能要到飞行后很长时间才会被发现，并可能作为入侵飞行器的一个步骤被激活。因此，在飞行过程中没有更新的模块仍可能构成风险。使用更新的签名对存储的飞行模块副本进行定期扫描，可能会发现隐藏的恶意软件，对恶意软件和漏洞报告的定期监测也会促使做出反应。

软件的完整性应通过采用加密安全的散列算法来验证，以确定被评估系统（或软件更新包）的散列值（摘要值）。此外，与系统哈希值进行比较的"控制"或"参考"哈希值的真实性也应使用加密数字签名的私钥进行签名，以确保控制值是由合法、可信的实体提供的。

原则：任务应建立并验证其软件图像的完整性。

原理：在轨软件更新/升级/补丁。如果TT&C 或 MOC或甚至开发人员的环境遭到破坏，就有可能进行变种的供应链攻击，在进入轨道后注入恶意代码或直接写入内存。如果不更新制造商定义，就无法识别新的或修改过的病毒或恶意软件。拦截、删除或推荐用于破坏计算机运行、收集敏感信息或访问私人计算机系统的常见病毒或恶意软件的补丁。

原则：任务应通过既定程序与技术方法执行软件保障。

原理：该控制的目的是确保提供商在创建安全关键软件（包括所有MOTS、GOTS、COTS、开 软件开发流程，包括所有MOTS、GOTS、COTS、开源、从库中获取和重复使用的软件。软件保证方法也必须延伸到开发环境中。要确保开发环境的安全，首先要了解与之交互的所有设备和人员。对接触开发环境的所有人员和资产进行准确的清点。确保在整个开发环境中使用强大的多因素身份验证，尽可能对代码库使用零信任访问控制。

安全的开发环境要求对整个环境进行变更管理、权限管理、审计和深入监控。

软件开发过程应包括软件需求定义、设计、实施、验证、维护和报废阶段，并纳入软件质量保证、配置管理、问题报告和纠正措施、可靠性、可维护性、安全性、验证和确认、认证以及软件的操作使用。

此外，软件的重复使用、对现成商业软件的依赖以及机载系统采用积木式方法并增加开源技术的标准化，都会导致潜在的供应链漏洞，必须加以适当缓解。参见NPR 7150.2D，NASA软件工程要求和NASA-STD-8739.8B，软件保证和软件安全标准。最后，任务应通过既定程序和技术方法执行软件保证，包括对照NASA 的"评估和批准清单"进行检查。