提到 ISO 21434，很多车企工程师的第一反应可能是“头疼”。毕竟，这标准不像 ISO 26262（功能安全）那样有现成的方法论可以直接套用，它更像是一个没有标准答案的开放性问题集：脆弱性怎么找？威胁建模怎么做才不被审核员挑刺？最后那个“剩余风险”到底是多少才算合格？
其实，ISO 21434 的核心逻辑并不复杂，它本质上是在问三个问题：什么东西可能被攻击？攻击者能造成什么后果？我们怎么确保这个风险在可接受范围内？
今天，我们就把这套流程拆碎了，结合车企落地的真实痛点，讲讲怎么从脆弱性识别一路走到量产合规，同时避免那些让人寝食难安的召回风险。
一、 基础概念：别被术语吓住
在深入细节之前，我们先统一一下语言。ISO 21434 里有两个核心概念，必须搞清楚：
- Vulnerability（脆弱性）：系统、设计或实现中的弱点，可能被威胁源利用。比如，一个未加密的 CAN 总线信号，或者一个默认密码的 ECU 固件升级接口。
- Threat（威胁）：对信息安全资产的潜在故意攻击，可能导致负面影响。比如，黑客通过远程 OTA 接口注入恶意固件。
ISO 21434 强调的 TARA（Threat Analysis and Risk Assessment，威胁分析与风险评估），正是将脆弱性与威胁结合，评估风险等级的过程。
二、 第一步：脆弱性识别——如何找到“软肋”
脆弱性识别是 TARA 的起点。很多车企在这里吃亏，因为测试不够全面，或者依赖单一方法。根据 ISO 21434 的要求，脆弱性识别应至少采用以下一种或多种组合方法：
- 设计审查（Design Review）：由熟悉系统的工程师仔细审查设计文档，寻找潜在弱点。
- 威胁情景分析（Threat Scenario Analysis）：基于系统架构，设想可能的攻击路径。
- 攻击树分析（Attack Tree Analysis）：从目标（如“非法控制车辆”）出发，逆向推导出达成该目标所需的所有可能路径。
- 漏洞数据库检索（Vulnerability Database Retrieval）：查询公开的 CVE（Common Vulnerabilities and Exposures）数据库，了解已知漏洞。
- 渗透测试（Penetration Testing）：通过实际攻击测试系统，发现隐藏的脆弱性。
实战建议：不要只依赖设计审查。对于关键系统，建议结合攻击树和渗透测试。例如，针对域控制器的 OTA 升级接口，可以先用攻击树分析所有可能的攻击路径（如中间人攻击、固件篡改），再通过渗透测试验证这些路径是否真实存在。
三、 第二步：威胁建模——构建“攻击视角”
威胁建模是将脆弱性转化为具体威胁的过程。ISO 21434 推荐使用 TARA 流程，其中包括：
- 定义安全边界（Definition of Security Boundary）：明确系统的物理、逻辑和时序边界。例如，将车辆网络划分为动力域、车身域、娱乐域等。
- 识别安全资产（Identification of Security Assets）：确定需要保护的信息和数据。例如，用户隐私数据、车辆控制指令、固件版本等。
- 识别威胁情景（Identification of Threat Scenarios）：对于每个安全资产，设想可能的攻击者、攻击路径和攻击目标。
- 评估风险等级（Evaluation of Risk Level）：根据影响力（Impact）和可实现性（Feasibility）两个维度，评估每个威胁情景的风险等级。
风险评估矩阵示例：
| 影响力 \ 可实现性 | 高（High） | 中（Medium） | 低（Low） |
|---|---|---|---|
| 高（High） | R1（最高风险） | R2（高风险） | R3（中高风险） |
| 中（Medium） | R2（高风险） | R3（中高风险） | R4（中风险） |
| 低（Low） | R3（中高风险） | R4（中风险） | R5（低风险） |
实战建议：影响力评估要具体。例如，对于“非法解锁车门”这一威胁，影响力可以是“用户不便”或“人身安全风险”。可实现性评估要考虑攻击者的能力、设备和知识水平。例如，远程非接触式攻击（如通过蜂窝网络）的实现难度通常低于物理接触式攻击（如通过 OBD 接口）。
四、 第三步：剩余风险管控——确保“风险可接受”
即使采取了安全措施，风险也不可能完全消除。剩余风险（Residual Risk）是指采取措施后仍存在的风险。ISO 21434 要求，所有风险必须降至“可接受水平”（Acceptable Level）。
1. 安全措施分类
- 预防措施（Preventive Controls）：防止攻击发生。例如，使用加密通信、身份认证。
- 检测措施（Detective Controls）：检测攻击行为。例如，入侵检测系统（IDS）、异常行为监测。
- 响应措施（Responsive Controls）：在攻击发生后减轻影响。例如，紧急制动、系统重启。
2. 风险接受准则
车企需要定义明确的风险接受准则。例如：
- R1 级风险必须降至 R2 或以下。
- R2 级风险必须降至 R3 或以下。
- R3 级及以下风险可接受，但需监控。
实战建议：风险接受准则应与组织的安全政策一致，并获得管理层批准。例如，某车企规定，所有 R1 级风险必须通过“纵深防御”（Defense in Depth）策略降至 R2 或以下，即至少需要三层独立的安全措施。
3. 剩余风险评估
在采取安全措施后，重新评估风险等级，确定剩余风险。如果剩余风险仍高于可接受水平，则需要采取额外的安全措施。
示例：
- 初始风险：R1（高风险）——黑客可通过蜂窝网络远程解锁车门。
- 采取的安全措施：
- 使用强加密（AES-256）保护通信。
- 实施双向身份认证（Mutual Authentication）。
- 部署 IDS 监测异常请求。
- 剩余风险：R2（中风险）——虽然攻击难度增加，但仍可能存在零日漏洞（Zero-day Vulnerability）。
- 额外措施：建立漏洞响应流程，定期更新固件。
- 最终剩余风险：R3（可接受风险）。
五、 车企落地合规的关键策略
1. 建立信息安全管理体系（ISMS）
ISO 21434 要求车企建立 ISMS，涵盖从概念阶段到报废阶段的全生命周期。ISMS 应包括：
- 安全政策：明确信息安全目标、职责和流程。
- 风险管理流程：定义 TARA 方法、风险接受准则和文档要求。
- 配置管理：确保系统配置的一致性和可追溯性。
- 变更管理：评估变更对信息安全的影响。
实战建议：ISMS 不应只是文档堆砌，而应融入日常研发流程。例如，在系统设计评审中，必须包含安全评审环节。
2. 供应链管理
ISO 21434 强调，车企需对供应商进行安全管理。供应链中的脆弱性可能导致整车风险升级。
- 供应商评估：评估供应商的信息安全能力和流程。
- 合同要求：在合同中明确供应商的安全责任。
- 信息共享：建立漏洞信息共享机制。
示例：某车企要求 Tier 1 供应商提供符合 ISO 21434 的 TARA 报告，并定期进行安全审计。如果供应商发现新的漏洞，必须在 24 小时内通知车企。
3. 持续监控与漏洞响应
信息安全是一个持续过程，而非一次性任务。车企需要建立：
- 监控机制：实时监控系统状态，检测异常行为。
- 漏洞响应流程：定义漏洞发现、评估、修复和通知的流程。
- OTA 更新能力：能够快速部署安全补丁。
实战建议：建立“安全运营中心”（SOC），7x24 小时监控车辆网络安全状态。例如，某车企通过云端监控所有车辆的 IDS 日志，一旦发现异常，立即触发告警并推送补丁。
4. 避免量产召回风险
召回风险主要源于未识别的脆弱性或未控制的剩余风险。为避免召回，车企应：
- 早期介入：在概念阶段就进行 TARA，避免后期设计变更带来的成本。
- 充分测试：在原型阶段进行充分的渗透测试和漏洞扫描。
- 模拟攻击：使用红队（Red Teaming）进行模拟攻击，发现潜在弱点。
- 售后监控：量产后进行持续的网络安全监控，及时发现新威胁。
案例：某车企曾因未对车联网模块进行充分的渗透测试，导致一个默认密码被公开利用，最终引发大规模召回。事后，该车企加强了 OTA 模块的安全设计，并引入了第三方安全审计。
六、 总结：从合规到竞争优势
ISO 21434 合规并非只是为了满足法规要求，更是提升产品竞争力的关键。随着消费者对车辆安全性关注度的提高，具备完善信息安全管理体系的车企将获得更多信任。
核心要点回顾：
- 脆弱性识别：多角度、多方法，结合设计审查、攻击树和渗透测试。
- 威胁建模：基于 TARA 流程，评估风险等级，制定针对性安全措施。
- 剩余风险管控：定义明确的风险接受准则，确保风险降至可接受水平。
- 全生命周期管理：从概念到报废，贯穿 ISMS、供应链管理和持续监控。
- 避免召回：早期介入、充分测试、模拟攻击、售后监控。
记住，ISO 21434 不是一成不变的规则，而是一个动态的风险管理框架。车企需要结合自身情况，灵活运用这些原则，才能真正实现信息安全与业务发展的平衡。
希望这篇指南能帮助你理清思路，顺利推进 ISO 21434 合规工作。如有具体疑问，欢迎随时交流。