Security analysis信息安全无法事后补装 - ECSS-E-ST-80C 与 IEEE P3536 将航天信息安全前移至设计阶段
VisualPro Tech Brief
信息安全无法事后补装
ECSS-E-ST-80C 与 IEEE P3536 将航天信息安全前移至设计阶段
航天系统信息安全 | 生命周期与设计阶段标准 | 行业动态简报
ECSS-E-ST-80CIEEE P3536IEEE P3349CCSDS SDLSNIST IR 8270
01概述（TL;DR）— 使航天信息安全成为“设计要求”的两件大事
长期以来，航天系统的信息安全一直被视为运行阶段的问题。地面站访问控制、链路加密、异常监测——这些都是发射之后才做的事。过去两年间，这一前提发生了变化。信息安全已前移为设计和开发阶段的要求，而且现在有两项标准对此作出了规定。
ECSS-E-ST-80C《Space engineering — Security in space systems lifecycles》于2024年7月1日生效。该标准由欧洲空间标准化合作组织（ECSS）的工程分支发布，覆盖空间段、地面段、发射段和支持段，并对从初始定义到退役处置的整个生命周期提出信息安全要求。
IEEE P3536《Standard for Space System Cybersecurity Design》于2026年3月26日获得IEEE SA标准委员会批准。它是首个要求卫星制造商和运营商在设计阶段内建网络安全的国际技术标准，定义了覆盖地面系统、航天器、链路和集成层的组件级设计流程。
通过系统的工程设计方式排除整类攻击——而不是在一个从未考虑信息安全的设计之上叠加监测和补丁。
— Gregory Falco，IEEE 航天系统网络安全工作组主席（康奈尔大学）
这两项标准的性质并不相同。ECSS是欧洲航天项目在合同中引用的标准体系；而IEEE P3536是自愿性标准，本身没有强制执行机制，其推广取决于合同、保险公司、监管机构和出口管制制度。混淆二者会导致应对优先级判断失误。
02为什么是现在——将航天信息安全推向设计阶段的三大变化
1整个生命周期纳入规定范围生命周期范围
ECSS-E-ST-80C关注的不是运行安全，而是生命周期信息安全管理：实现信息安全功能（例如信息安全管理体系）、保护设计信息，以及——尤为关键的——通过信息安全风险评估识别敏感信息，并施加相应的保护标识和保护措施。它不仅适用于涉密的政府项目，也适用于非涉密任务。
其排除范围同样明确。正式的系统信息安全认可（System Security Accreditation）流程不在本标准范围内，标准也不会施加与组织自身政策相冲突的企业信息安全约束。允许根据项目特点进行剪裁。
其排除范围同样明确。正式的系统信息安全认可（System Security Accreditation）流程不在本标准范围内，标准也不会施加与组织自身政策相冲突的企业信息安全约束。允许根据项目特点进行剪裁。
2信息安全前移至设计阶段（Secure by Design）设计阶段
IEEE P3536在五个领域中定义网络安全控制措施——地面系统、航天器、连接二者的链路段，以及涵盖将任务联结在一起的API、数据链路和测试环境的集成层——另有第五个分委员会负责用户段：手持终端、平板电脑、基站以及导航和遥感应用。
值得注意的是其覆盖面。它并非只针对大型国家项目而编写，而是为模块化商用现货（COTS）系统、立方星和小卫星平台提供技术性网络安全规范。随着商业航天门槛的降低，设计层面的信息安全要求也随之下沉到这一层级。
值得注意的是其覆盖面。它并非只针对大型国家项目而编写，而是为模块化商用现货（COTS）系统、立方星和小卫星平台提供技术性网络安全规范。随着商业航天门槛的降低，设计层面的信息安全要求也随之下沉到这一层级。
3标准体系一下子变得厚重标准格局
IEEE P3349《Standard for Space System Cybersecurity》正由同一工作组（S2CY）从控制措施的角度并行制定。在美国，NIST IR 8270提供了将网络安全框架应用于商业卫星运营的方法。在链路层，CCSDS SDLS提供空间数据链路安全协议；在威胁知识方面，The Aerospace Corporation维护着SPARTA。
这些标准的要求最终汇聚为一点：识别资产、推导威胁、评估风险、将对策转化为要求，并留下其已被实现和验证的证据。这正是汽车和国防领域所称的TARA流程。
这些标准的要求最终汇聚为一点：识别资产、推导威胁、评估风险、将对策转化为要求，并留下其已被实现和验证的证据。这正是汽车和国防领域所称的TARA流程。
03两项标准的实际要求
ECSS-E-ST-80C 概览
| 项目 | 内容 |
|---|---|
| 正式名称 | Space engineering — Security in space systems lifecycles |
| 生效日期 | 2024年7月1日 |
| 适用段 | 空间段、地面段、发射段、支持段（航天器、运载火箭、有效载荷及相关地面基础设施） |
| 生命周期范围 | 从初始定义到退役处置 |
| 核心要求 | 信息安全功能（ISMS等）、生命周期信息安全管理、设计信息保护、基于风险评估的敏感信息识别及保护标识与保护措施 |
| 适用对象 | 涉密政府项目和非涉密任务均适用 |
| 不在范围内 | 正式的系统信息安全认可（System Security Accreditation）流程；与组织政策相冲突的企业信息安全约束 |
| 剪裁 | 可根据项目特点进行（依据ECSS-S-ST-00指南） |
IEEE P3536划分的五个领域
| 领域 | 覆盖范围 | 分析中必须涉及的内容 |
|---|---|---|
| 地面系统 | 控制中心、地面站、运行网络 | 访问控制被攻破、指令伪造、内部人员威胁 |
| 航天器 | 卫星平台、星载软件、内部总线 | 指令接收逻辑、软件上注路径、安全模式 |
| 链路段 | 上行链路、下行链路、中继 | 干扰、欺骗、重放、密码运行 |
| 集成层 | API、数据链路、测试环境 | 接口信任边界、测试环境中的资产暴露 |
| 用户段 | 手持终端、平板电脑、基站、导航与遥感应用 | 经由终端用户设备的入侵、应用数据完整性 |
两组容易混淆的标准 第一，IEEE P3349与P3536是不同的标准。二者出自同一工作组（S2CY），但P3349规定必须具备哪些防护（控制措施），而P3536规定如何进行设计（流程）。一个是规定性的，另一个是程序性的。
第二，ECSS-E-ST-80C与ECSS-Q-ST-80C编号看似相同，却是完全不同的标准。E属于工程分支（信息安全），Q属于产品保证分支（软件产品保证）。在引用文件或审查合同要求时，务必核对分支字母。
第二，ECSS-E-ST-80C与ECSS-Q-ST-80C编号看似相同，却是完全不同的标准。E属于工程分支（信息安全），Q属于产品保证分支（软件产品保证）。在引用文件或审查合同要求时，务必核对分支字母。
04航天项目早已拥有分析体系——如今信息安全与之并肩而立
航天领域开展可靠性与安全分析的历史之长、要求之严，几乎超过任何其他领域。ECSS-Q-ST-30-02C规定了FMEA/FMECA的原则和要求，按危害性（criticality，即严重度与发生概率的综合度量）对失效模式进行分类。ECSS-Q-ST-40系列则定义了危害分析的原则、流程和要求。
E-ST-80C和P3536所增加的不是一种新的分析技术，而是一条新的原因轴。此前的原因是随机故障以及设计或制造缺陷；如今，怀有意图的行为者也加入其中。
| 既有分析（ECSS Q分支） | 新要求的信息安全活动 | 二者共享的内容 |
|---|---|---|
| FMEA / FMECA（Q-ST-30-02C） | 威胁场景的影响评估 | 相同的功能与结构分解 |
| 危害分析（Q-ST-40系列） | 信息安全风险评估 | 风险识别与分级程序 |
| FTA与可靠性分析 | 攻击路径分析 | 事件逻辑与最小割集 |
| 要求的分解与追溯 | 信息安全要求的分解与追溯 | 要求层级与设计分配 |
| 验证证据包 | 对策有效性的证据 | 评审与审核应对的依据 |
当两条轴分处不同工具时，问题便随之出现 如果安全分析放在可靠性团队的FMECA中，而信息安全分析放在单独的威胁分析表中，同一颗卫星就要建模两次——而且信息安全遭到破坏所导致的任务损失永远不会进入FMECA。反过来，为安全而引入的冗余对攻击者意味着什么，也从未得到审视。
在航天领域，这种遗漏的代价比其他领域更高。测控接触机会有限，无法进行物理访问，任务周期长达十年以上。设计阶段遗漏的问题，事后几乎没有余地补救。这正是两项标准都瞄准设计阶段的原因。
在航天领域，这种遗漏的代价比其他领域更高。测控接触机会有限，无法进行物理访问，任务周期长达十年以上。设计阶段遗漏的问题，事后几乎没有余地补救。这正是两项标准都瞄准设计阶段的原因。
05VisualPro 如何提供支持
一棵结构树，五种分析结构共享
FMEA、FTA、HARA、TARA和STPA共享同一个系统结构数据库。将卫星平台、有效载荷、地面站和链路放在一棵树上，IEEE P3536定义的五个领域便成为同一棵树上的节点。可靠性分析与信息安全分析引用同一个模型。
TARA——从资产到信息安全要求标准契合
资产识别、威胁场景推导、风险评估、对策以及信息安全要求，都在工具内完成并加以追溯。ECSS-E-ST-80C要求的信息安全风险评估和敏感资产识别，以及P3536设计流程所期望的工作成果，都建立在这一流程之上。
跨分析的可追溯性（数字主线）核心价值
威胁→对策→信息安全要求→验证项，以及失效模式→影响→严重度→设计措施，都在同一个数据库中关联。当设计变更或出现新威胁时，相关分析会随之更新，因此在评审时即可提供实时的可追溯性。
基于MCP的AI智能体集成AI集成
VisualPro面向FMEA、FTA、HARA、TARA和STPA的MCP（Model Context Protocol）功能，使Claude等AI智能体能够与工具直接通信。从候选威胁与危害的识别到评分草案，都可以通过对话完成，分析人员则专注于验证和判断。
06常见问题（FAQ）
Q1IEEE P3536 是强制性的吗？
不是。P3536是自愿性标准，本身没有强制执行机制。其约束力来自采购合同、保险公司的承保条件、监管机构的引用以及出口管制制度。ECSS-E-ST-80C则性质不同——它是欧洲航天项目在合同中引用的标准体系。如果您正在评估进入欧洲项目，应优先考虑ECSS；P3536可作为设计流程的国际基准。
Q2ECSS-E-ST-80C 与 ECSS-Q-ST-80C 是同一项标准吗？
不是。编号看似相同，但分支不同。E-ST-80C涉及信息安全（工程分支），Q-ST-80C涉及软件产品保证（产品保证分支）。这一点在实务中经常被混淆，因此在引用文件或审查合同要求时，务必核对分支字母。
Q3汽车网络安全（ISO/SAE 21434）的经验能否迁移到航天领域？
方法论流程可以直接迁移。资产识别、威胁场景、风险评估、对策推导和可追溯性，在TARA与航天信息安全标准中构成相同的骨架。不同之处在于段的构成（地面、链路、轨道、用户）、接触机会的限制（可见弧段与带宽）、任务寿命（十年及以上）以及所依据的标准。需要学习的是领域约束和标准格局，而不是分析方法。
Q4VisualPro 能否直接生成 ECSS 格式的交付物？
准确地说，VisualPro以标准格式输出的是AIAG-VDA FMEA、ISO 26262 HARA（ASIL）、ISO/SAE 21434 TARA和FTA。ECSS-Q-ST-30-02C中的FMECA在字段结构和危害性（criticality）的推导方式上有所不同，因此需要进行字段映射。不过，分析的实质内容——结构分解、失效模式、影响、严重度、对策、可追溯性——都在同一个数据库中管理，因此可在导入阶段协商并配置符合项目格式的输出定义。
07立即开始（Next Step）
在航天系统中，安全与信息安全已不再是不同阶段的工作。ECSS-E-ST-80C将信息安全锚定在整个生命周期，IEEE P3536将其锚定在设计阶段。而两项标准所要求的工作成果，只有建立在与您现有可靠性和安全分析相同的结构之上，成本才能得到控制。从已在汽车、国防、航空、机器人和半导体领域得到验证的VisualPro开始，将威胁分析与失效分析置于同一结构之上。
威胁分析与失效分析置于同一结构之上——借助VisualPro满足航天信息安全标准。
参考资料：ECSS, “ECSS-E-ST-80C — Security in space systems lifecycles” (2024-07-01) · CYSAT News, “IEEE Approves First Space Cybersecurity Design Standard” (2026-07-10) · IEEE SA, “P3349 — Standard for Space System Cybersecurity” · NIST IR 8270 · ECSS-Q-ST-30-02C FMEA/FMECA