功能安全 × 信息安全协同工程 — ISO 26262 与 ISO/SAE 21434 的 co-engineering
本质与导读
本质 zonal / 以太网 / OTA 把 safety 与 security 焊死:安全机制会被攻击绕过,安全冗余反而扩大攻击面,二者不可分离分析。协同的硬核是让同一套分析同时承载"故障 → 后果"与"攻击 → 故障"两条因果链;ASIL 与 CAL 没有直接映射,只在某条攻击路径能命中高 ASIL 失效模式时才耦合——此时必须 safety 与 security 双方签字。
主线坐标:横轨 · 功能安全(跨站) · ↑ 全景主线
1. 抓硬约束:为什么 SDV 架构让 safety 与 security 不可分
传统分布式 E/E 架构里,安全功能(如制动 ECU 内部冗余)躲在物理隔离的私有总线后面,攻击者够不着,于是功能安全团队可以假装"输入都是善意的"、把恶意输入当成超出范围的故障一笔带过。zonal / 中央计算 + 车载以太网 + OTA 这三件事同时发生后,这个假设彻底崩塌:安全攸关报文跑在与信息娱乐共享的交换网络上,刷写口直通互联网,于是任何安全机制的有效性都取决于它的输入没被篡改——而这正是 security 的领域。
1.1 三个架构变化与它们消除的隔离假设
把三个变化拆开看,会发现它们各自打掉了功能安全长期依赖的一条隐含前提。下表列出变化、被打掉的假设、以及由此产生的协同需求。
| 架构变化 | 被打掉的功能安全隐含假设 | 由此产生的协同需求 |
|---|---|---|
| zonal + 中央计算 | "安全功能跑在专用隔离 ECU" | 多功能共硬件,一处被攻破波及多个安全目标,需联合资产分析 |
| 车载以太网(SOME/IP) | "安全报文在私有 CAN 上,外人看不见也插不进" | 安全攸关帧需鉴权(SecOC),鉴权又引入时延,可能撞 FTTI |
| OTA + 远程诊断 | "刷写要进车间、物理接触" | 刷写通道成为远程攻击面,签名/RXSWIN 与安全发布管理必须对齐 |
术语:FTTI(Fault Tole…
术语:FTTI(Fault Tolerant Time Interval,故障容错时间区间)指从故障发生到必须进入安全状态的最长允许时间;RXSWIN 是 UN R156 定义的、标识一台车上与法规相关软件版本的标识符。
1.2 两套标准的结构同构(为什么协同有抓手)
协同之所以可行,是因为两套标准的生命周期骨架几乎同构:都走"管理 → 概念 → 产品开发 → 生产后"的 V 流程,概念阶段都先做风险分析(26262 是 HARA,21434 是 TARA),再导出目标(安全目标 / 信息安全目标),再分解到需求,最后用一份 case 论证。正因为结构对齐,二者的工作产物可以共享或互相引用,而不是各写一套互不相认的文档。
2. 因果分析:safety 与 security 的四象限相互作用
把"哪一方影响哪一方"做成二维分类,就得到协同分析的核心心智模型:横轴是"谁是因",纵轴是"谁是果"。理解这四个象限,才能判断一个具体设计决策到底是协同还是相互拆台,而不是凭直觉拍脑袋。
2.1 象限 I:security 威胁触发 safety 危害(攻击 → 危害)
这是最容易被忽视、也最危险的方向:一个纯粹的信息安全漏洞,经由攻击被利用后,最终表现为一次会害人的功能失效。例如攻击者向车载网络注入伪造的 CAN / SOME-IP 报文,谎报"前方无障碍"或直接命令意外制动,后果是车辆失稳——这在 26262 眼里是一个 ASIL 危害事件,但它的根因在 21434 的威胁清单里。含义:HARA 必须把"恶意触发"列为 HARA 危害的一种触发源,否则会漏掉一整类高严重度场景。
2.2 象限 II:safety 机制被攻击削弱(攻击 → 安全机制失效)
功能安全为了高可靠性引入的机制,本身可能成为攻击靶子。经典例子是 CAN 总线:它为了实时性和容错被高度优化,却几乎没有鉴权,攻击者因此能轻易伪造/抑制安全报文;再如安全监控用的看门狗、lockstep 比较器,若其触发信号或复位线可被远程置位,攻击者就能反复强制系统进安全状态(拒绝服务)。含义:每一个安全机制(safety mechanism)都要在 TARA 里被当作一项资产,评估它被绕过/触发/瘫痪的可行性。
2.3 象限 III:safety 措施扩大攻击面(安全设计 → 新攻击面)
为达成 fail-operational 引入的冗余、降级通道、诊断接口,几乎都会增加可被攻击的入口。冗余通信意味着多一条可被注入的链路;丰富的 UDS 诊断服务为标定/排故而开放,却也给了攻击者读写内存、刷写固件的入口;安全降级模式如果缺乏鉴权,反而成了攻击者主动触发的目标。含义:任何为 safety 新增的接口/路径,都要回灌进 TARA 的攻击面分析,不能"加了冗余就以为更安全"。
3. 解决方案:协同流程、工作产物对齐与冲突裁决
光知道四象限不够,工程上要的是一套可重复的并轨流程。其骨架是:一份联合 item definition 喂给两条分析线,HARA 与 TARA 在共享工作坊里互相投喂中间结果,产出可共享或交叉引用的工作产物,冲突进入一个明确的仲裁通道——而不是各做各的、到集成测试才发现打架。
3.1 HARA 与 TARA 的互喂回路
互喂不是"先做完一个再做另一个",而是两条线在概念阶段并行、在固定检查点交换结果形成闭环。HARA 先给出安全攸关功能及其 ASIL 与失效后果,这份清单告诉 TARA"哪些资产一旦被攻破会害人、影响有多严重"(填 TARA 的 S 影响维度);TARA 反过来给出"哪些攻击路径会触发上述安全失效",这些路径作为新的触发源回灌 HARA。下表给出互喂的具体交换物。
| 方向 | 交换的工作产物 | 接收方如何使用 |
|---|---|---|
| HARA → TARA | 安全攸关功能清单 + ASIL + 危害后果严重度 | 作为 TARA 资产的 Safety 影响维度(S),定位高价值攻击目标 |
| TARA → HARA | 可触发安全失效的攻击路径 + 可行性 | 作为 HARA 的新触发源,补全"恶意诱发"类危害场景 |
| 共享 | 联合 item definition + 系统边界 + 接口清单 | 两条线用同一份系统描述,避免边界/假设不一致 |
3.2 工作产物对齐表(共享 / 交叉引用 / 各自专属)
并非所有工作产物都该合并:有些天然共享(同一份系统描述),有些只需交叉引用(各保留专属文档但互相指认),有些是某一方独有(21434 的持续监控、26262 的硬件度量)。强行合并独有产物只会制造噪声。下表给出对齐策略。
| ISO 26262(safety) | ISO/SAE 21434(security) | 对齐策略 |
|---|---|---|
| Item Definition | Item Definition / 资产边界 | 共享同一份(单一系统真源) |
| HARA(Severity·Exposure·Controllability) | TARA(Impact·Attack Feasibility) | 各自方法,检查点互喂 |
| Safety Goals | Cybersecurity Goals | 共享需求库,交叉引用 |
| Safety Case | Cybersecurity Case | 各自论证,顶层组装成 assurance case |
| 安全机制(看门狗/lockstep/E2E) | 安全控制(SecOC/Secure Boot) | 互列为对方分析对象(象限 II/III) |
| ASIL 分解 + 硬件度量(SPFM/LFM) | CAL + 攻击可行性评级 | 无直接映射,仅在攻击危及安全功能时耦合 |
| —(无对应) | 持续监控 / 漏洞处理 / 事件响应 | security 专属,生产后长期运行 |
3.3 联合分析方法:combined FMEA 与 attack tree
单独的 FMEA 看不见恶意因果,单独的 attack tree 看不见随机失效后果,协同分析要把二者缝合:在 FMEA 的失效模式行旁挂一列"是否可被恶意诱发 / 攻击路径",对每条会导致安全后果的攻击路径用 attack tree 展开其可行性。学界把这套融合记为 HATARA(HARA + TARA 融合)等方法,本质都是让一张表/一棵树同时承载"故障 → 后果"和"攻击 → 故障"两条因果链,避免两套分析的接缝处漏判。判据:任何一条 attack tree 的叶子若能命中 FMEA 中某个高 ASIL 失效模式,就必须同时拿到 safety 与 security 双方签字。
3.4 冲突裁决矩阵:fail-operational vs fail-secure 等
第 2.4 节的需求冲突不能靠"折中"蒙混,需要一套显式的裁决原则:先看该功能的 ASIL 与 CAL 谁更高、再看失效/被攻破的后果哪个更不可接受,据此决定缺省偏向,并为另一方设计补偿措施(而非牺牲)。下图把几类典型冲突的裁决落到一张矩阵上。
裁决的总原则可以浓缩成三条因果链:其一,生命优先于资产——当继续运行(fail-operational)是避免人身伤害的唯一手段时,默认偏 safety,但对降级通道单独加鉴权/限权以补偿 security;其二,被攻破的安全状态不是安全状态——若攻击者能主动触发"安全降级"并借此扩大危害,则该降级路径必须先满足完整性,fail-secure 在此优先;其三,时延冲突靠架构而非取舍——鉴权撞 FTTI 时,不是删鉴权或放宽 FTTI,而是用硬件加速 MAC / 预计算 freshness / 分级保护(只对安全攸关帧做轻量鉴权)把两者同时压进预算。
4. 把协同钉进过程:ASPICE 4.0 作为共同底座
前三章是"做什么",但若没有共同的过程底座,协同会退化成两个团队偶尔开个会。Automotive SPICE 4.0 在这里充当公共脚手架:它的过程参考模型同时容纳 safety 与 security 的工程活动(需求、架构、设计、验证都有统一的能力维度),于是 HARA/TARA 互喂、case 交叉引用、冲突仲裁都能挂到具体的 ASPICE 基础实践与工作产物上,被同一套评估审计。换句话说,26262 与 21434 回答"要满足什么",ASPICE 4.0 回答"用什么过程纪律保证两者被一致地执行并留痕"。
4.1 三层职责切分(避免"全合并"陷阱)
协同不等于把两个团队捏成一个、也不等于让一个人精通双方。可行的切分是:方法层各自保留专长(失效建模 vs 攻击建模),接口层共享产物并设固定检查点,治理层设一条统一的冲突升级路径。下表给出三层的归属。
| 层 | safety 侧 | security 侧 | 协同形态 |
|---|---|---|---|
| 方法层 | HARA / FMEA / FTA / 硬件度量 | TARA / attack tree / STRIDE | 各自专长,不强行合并 |
| 接口层 | 安全攸关功能 + ASIL | 攻击路径 + 可行性 | 共享 item definition,检查点互喂 |
| 治理层 | 安全经理裁决 | 信息安全经理裁决 | 统一冲突升级路径 + assurance case 总装 |
缩写表
| 缩写 | 全称 | 通俗解释 |
|---|---|---|
| HARA | Hazard Analysis and Risk Assessment | 危害分析与风险评估(26262),识别会害人的功能失效并定 ASIL |
| TARA | Threat Analysis and Risk Assessment | 威胁分析与风险评估(21434),识别攻击并定 CAL |
| ASIL | Automotive Safety Integrity Level | 汽车安全完整性等级 A-D,衡量功能安全严苛度 |
| CAL | Cybersecurity Assurance Level | 信息安全保障等级 1-4,衡量信息安全严苛度 |
| FTTI | Fault Tolerant Time Interval | 故障容错时间区间,从故障到必须进安全状态的最长允许时间 |
| SecOC | Secure Onboard Communication | 车载安全通信,给总线报文加 MAC + 新鲜值防重放 |
| RXSWIN | Regulation X Software Identification Number | UN R156 定义的法规相关软件版本标识 |
| FMEA | Failure Mode and Effects Analysis | 失效模式与影响分析 |
| FTA | Fault Tree Analysis | 故障树分析(自顶向下找失效原因) |
| STRIDE | Spoofing/Tampering/Repudiation/InfoDisclosure/DoS/Elevation | 微软威胁分类法,常用于汽车 attack 建模 |
| SPFM/LFM | Single/Latent Point Fault Metric | 单点/潜伏故障度量(26262 硬件指标) |
| ASPICE | Automotive SPICE | 汽车软件过程能力评估模型 |
| SDV | Software-Defined Vehicle | 软件定义汽车 |
| UDS | Unified Diagnostic Services | 统一诊断服务(ISO 14229) |
核心要点
- zonal + 车载以太网 + OTA 同时打掉了功能安全"输入皆善意、机制躲在隔离总线后"的隐含假设,safety 与 security 因此不可分离。
- 两套标准生命周期同构(管理→概念→开发→生产后),这是工作产物可共享/交叉引用的结构基础。
- 四象限是核心心智模型:攻击触发危害(I)、安全机制被攻击(II)、安全措施扩攻击面(III)、需求直接冲突(IV)。
- HARA 与 TARA 必须互喂:HARA 给 TARA 的 S 影响维,TARA 给 HARA 的恶意触发源,在检查点形成闭环。
- ASIL 与 CAL 无直接映射,只在攻击可危及安全功能时才耦合;别用 ASIL D 强推 CAL 4。
- 冲突裁决三原则:生命优先于资产(默认 fail-op + 补鉴权)、被攻破的安全状态不算安全(降级路径先保完整性)、时延冲突靠架构(硬件 MAC / 分级保护)而非取舍。
- ASPICE 4.0 是共同过程底座;协同分三层:方法层各自专长、接口层共享产物、治理层统一仲裁。
Engineering Objects
joint_item_definition(safety 与 security 共享的单一系统描述 + 边界 + 接口清单)hara_tara_exchange(HARA↔TARA 检查点互喂的中间产物:安全攸关功能清单 / 攻击路径清单)combined_fmea_attacktree(融合分析:FMEA 失效模式行挂攻击路径列 + attack tree 命中高 ASIL 模式即双签)conflict_resolution_matrix(fail-op vs fail-secure 等冲突的裁决矩阵 + 三原则)assurance_case(safety case + cybersecurity case 顶层组装的统一可信论证)
Cross-references
- ← 索引
- ISO/SAE 21434 网络安全深度 — 本页的 security 侧前置;那页讲 TARA/SecOC/HSM 标准本身,本页讲它如何与 safety 并轨
- 功能安全总览 — safety 侧总入口,ASIL / V 流程的根基
- HARA 危害分析 — 本页 HARA↔TARA 互喂中 HARA 那一端的方法细节
- STPA 危害分析深度 — STPA 的控制结构视角天然适合 safety-security 联合分析,可作 combined 分析的方法补充
来源:ISO/SAE 21434:2021 Clause 15 + ISO 26262-3;MDPI Sensors 24(6):1848 safety-security co-analysis;Embitel / piembsystech 集成实践;Springer "Integrated Analysis of Safety and Security Hazards";IJISRT HATARA;Jama Software team alignment。综合公开二手资料整理,非标准原文引用。