在 ISO/SAE 21434 标准中，网络安全需求的分解与分配是连接概念阶段（Clause 9-10）与产品开发阶段（Clause 11+）的核心桥梁，其根本驱动力来源于 TARA（威胁分析与风险评估） 的结果。

整个机制遵循“自上而下、逐层细化、双向追溯”的原则。

一、 驱动源头：从 TARA 到网络安全目标 (Cybersecurity Goals)

1. 资产识别与风险评级：识别车辆相关项（Item）的关键资产，分析威胁场景与攻击路径，评估影响等级与攻击可行性，得出风险值。

2. 风险处置决策：若决策为 Reduce（降低风险），则必须定义网络安全目标（Clause 9）。

• 特征：高层次、与解决方案无关（Solution-independent）、关联 CAL（网络安全保证等级）。

• 示例：“防止对整车控制器固件的未授权修改”（目标不涉及具体用 HSM 还是加密算法）。

二、 需求分解机制：三层转化逻辑

1. 网络安全目标 → 网络安全需求 (Cybersecurity Requirements)

• 机制：将高层的“目标”转化为系统层面的“需求”，此时开始引入解决方案特异性。

• 方法：

• 针对每个目标设计网络安全机制（如认证、加密、隔离、审计）。

• 结合系统初步架构，识别哪些组件参与该机制。

• 输出：形成系统级的网络安全需求规格，每条需求必须可追溯至对应的网络安全目标及 TARA 威胁场景。

2. 网络安全需求 → 技术/软硬件需求 (Technical Requirements)

• 机制：在产品开发阶段（Clause 11），进一步分解为硬件、软件、通信协议的具体技术指标。

• 示例：

• 系统需求：“诊断会话需身份认证” → 软件需求：“实现 UDS 0x27 服务安全访问” → 硬件需求：“MCU 集成 HSM 用于存储密钥”。

3. 分解中的关键约束：CAL 等级的继承与映射

• 分解过程中，CAL 等级随需求一同分配至下级组件。若架构中引入了额外的缓解层（如网关隔离），可能通过论证调整子组件的 CAL，但需保留证据链。

三、 需求分配机制：从整车到供应链

1. 架构驱动的分配

• 基于系统架构设计（含信任边界、接口定义），将网络安全需求分配给 ECU、通信总线、网关、云端组件等。

• 原则：无遗漏、无重叠（确保每个架构元素知道自己的安全职责，且接口两侧的需求匹配，如发送端要求 MAC 认证，接收端要求验证 MAC）。

2. 分布式活动中的供应链分配（Clause 7 & 15）

• OEM 职责：在整车层面定义需求，通过网络安全接口协议 (Cybersecurity Interface Agreement) 将需求释放给 Tier 1/Tier 2。

• RASIC 模型：使用责任分配矩阵（如 RASIC）明确客户与供应商谁负责（Responsible）、谁批准（Accountable）、谁支持（Support）。

• 供应商承接：供应商收到需求后，需在零部件层面开展局部 TARA（Component-level TARA），验证 OEM 分配的需求是否充分，或进一步细化本地的网络安全需求。

四、 核心保障：追溯性与一致性

• 需求追溯矩阵 (RTM)：

• 向上追溯：网络安全需求 → 网络安全目标 → TARA 威胁场景 → 资产。

• 向下追溯：网络安全目标 → 系统需求 → 软硬件需求 → 测试用例。

• 一致性检查：确保架构变更时，分配的需求同步更新；确保 CAL 等级在分配过程中未被不当降级。

总结：典型流程链

TARA 风险 > 网络安全目标 (CAL X) > 网络安全机制设计 > 系统网络安全需求 > 分配至架构元素 (ECU/Network) > 软硬件技术需求 > 供应商需求释放与确认

推荐阅读：

亚远景-ISO 26262与ASPICE：汽车软件开发中的协同与互补

亚远景-拒绝“为了评估而评估”：如何让 ASPICE 真正融入日常开发？

亚远景-ASPICE在供应链管理中的角色：如何利用标准评估和选择供应商

亚远景-ASPICE过程参考模型（PRM）解析与应用

亚远景-从仿真测试到实车验证：ISO/PAS 8800 的测试策略

亚远景-配置管理与ASPICE评估的契合点分析

推荐服务：

点击查看亚远景ASPICE咨询、评估、“认证”、培训服务

点击查看亚远景ISO26262咨询、认证、培训服务

点击查看亚远景ASPICE、ISO26262培训课程

点击查看亚远景ASPICE、ISO26262实施工具-APMS研发过程管理平台