第3章安全需求定义

3、安全需求定义：从功能安全（ISO 26262）过渡到信息安全（ISO 21434）、安全需求分解与追溯

好，咱们进入第三讲。这一讲，我打算聊聊安全需求定义。

说实话，很多团队在ADAS开发中，容易把功能安全和信息安全割裂开。功能安全团队做一套需求，信息安全团队再做一套。结果呢？两边打架，开发人员也懵了。

我个人习惯是，从一开始就把这两条线拧在一起。为什么？因为ADAS系统太特殊了。一个刹车指令，既关系到功能安全（刹不住车会死人），也关系到信息安全（黑客伪造刹车指令也会死人）。你分得开吗？分不开。

3.1 从功能安全到信息安全的思维转变

先说说功能安全。ISO 26262的核心思路是：系统在发生随机硬件故障或系统故障时，仍能保持安全。说白了，就是“万一坏了怎么办”。

但信息安全（ISO 21434）问的是另一个问题：如果有人故意搞破坏，系统扛得住吗？

我在项目中遇到过这样一个场景：功能安全要求“制动系统在CAN总线故障时，进入降级模式”。这个需求很清晰。但信息安全团队追问了一句：“如果攻击者故意往CAN总线上灌垃圾数据，算不算故障？”

嗯，这一问，就把两个领域串起来了。

核心观点：功能安全处理“意外故障”，信息安全处理“蓄意攻击”。但在ADAS中，两者的边界是模糊的。一个蓄意攻击，可能表现为一个“意外故障”。

3.2 安全需求分解：从TARA到具体需求

信息安全需求怎么来？不是拍脑袋。标准流程是：先做TARA（威胁分析与风险评估）。

我建议的分解路径是这样的：

资产识别：找出系统中需要保护的东西。比如：感知数据、控制指令、OTA升级包。
威胁场景分析：攻击者可能怎么搞破坏？比如：篡改摄像头数据、重放CAN报文。
风险等级评定：根据攻击可行性、影响程度，定出高、中、低风险。
安全目标定义：针对高风险项，定义安全目标。比如：“防止未授权的CAN报文注入”。
安全需求分解：把安全目标拆成具体的、可验证的需求。

举个例子：

安全目标	分解后的安全需求	对应功能安全项
防止未授权的CAN报文注入	1. 所有CAN报文必须包含MAC（消息认证码） 2. 接收方必须验证MAC，验证失败则丢弃报文并记录日志	与功能安全的“通信故障检测”重叠
防止OTA固件被篡改	1. OTA包必须使用私钥签名 2. 设备端必须验证签名，验证失败则拒绝安装	与功能安全的“软件更新完整性”重叠

你看，很多信息安全需求，其实和功能安全需求是“同源”的。只是出发点和验证方法不同。

3.3 需求追溯：别让需求变成“孤儿”

需求定义完了，最怕什么？最怕需求写进文档就没人管了。

我曾经在一个项目里，发现有一条安全需求写着“系统应具备防重放攻击能力”。但到了测试阶段，没人知道这条需求对应哪个测试用例。结果呢？这条需求成了“孤儿需求”。

怎么避免？我建议用双向追溯矩阵。

我的做法：在需求管理工具（比如DOORS、Jama）里，把每条安全需求都关联到：

上游：对应的TARA威胁场景、安全目标
下游：对应的设计文档、测试用例、验证结果

这样，任何时候都能回答一个问题：“这条需求，到底有没有被实现和验证？”

举个例子，一条需求“CAN报文MAC验证失败时，系统应在100ms内进入安全状态”。它的追溯链应该是：

威胁场景（攻击者注入伪造CAN报文）
  → 安全目标（防止未授权CAN报文注入）
    → 安全需求（MAC验证失败后100ms内进入安全状态）
      → 设计文档（描述MAC验证模块的实现）
        → 测试用例（注入伪造报文，验证系统响应时间）
          → 测试报告（记录测试通过/失败）

嗯，这个链条不能断。断了，你就没法证明你的系统是安全的。

3.4 功能安全与信息安全的“握手”

最后，我想聊聊两个标准怎么“握手”。

ISO 26262和ISO 21434不是互斥的。相反，它们有很多可以互相借力的地方。

危害分析与风险评估：功能安全用HARA，信息安全用TARA。但两者的输出可以合并。我习惯把“信息安全攻击导致的功能安全危害”单独列出来，作为高优先级项。
安全机制复用：功能安全里的“看门狗”、“ECC校验”，其实也能防一些攻击。别重复造轮子。
验证与确认：功能安全的测试用例，可以加上信息安全攻击场景。比如：功能安全测试“CAN总线断线”，信息安全测试可以加一个“CAN总线被恶意灌包”。

避坑指南：我曾经见过一个团队，功能安全和信息安全各做各的TARA/HARA，结果发现同一个风险被评估了两次，但处理措施互相矛盾。所以，我建议两个团队至少做一次联合评审，把重叠项找出来，统一处理。