汽车软件漏洞频发ISO21434风险分析让功能安全与信息安全不再扯皮

你是不是也发现，最近买车和以前不太一样了？以前咱们关心的是这车避震舒不舒服、油耗高不高，现在打开新闻，看到的都是“某品牌车辆被黑客远程解锁”、“车联网系统存在严重漏洞导致隐私泄露”。

说实话，看着挺吓人的。但更让人头疼的，其实是车企内部那帮搞技术的兄弟们。

以前，负责功能安全（Functional Safety）的李工和负责信息安全（Cybersecurity）的王工，那是“老死不相往来”。李工只管车开起来别出事故，王工只管系统别被黑客黑掉。结果呢？出了事互相甩锅：“这车刹不住是因为被黑了！”“别扯淡，是你传感器标定有问题！”

直到 ISO/SAE 21434 这个标准出来，才真正把这个烂摊子理清楚了。今天，咱们就换个方式，不整那些枯燥的条文，像聊家常一样，把这事儿掰扯明白。

一、 为什么现在的车，成了黑客的“游乐场”？

先别急着骂黑客技术高，咱们得看看车为啥变得这么“脆弱”。

现在的车，早就不是那四个轮子加个发动机那么简单了。你可以把它想象成“装了四个轮子的智能手机”，甚至复杂度远超手机。

1. 电子电气架构的颠覆性变化

老款车，一个车灯一个开关，一个发动机控制单元（ECU）管发动机。大家井水不犯河水，通讯简单，用CAN总线传点简单的信号，密码？不需要。

新款车呢？ centralized architecture（集中式架构）来了。

• 域控制器：底盘域、动力域、座舱域，一个大脑管一片。
• 中央计算平台：未来的车，可能就像一辆装了轮子的超级计算机。
• 云连接：你的车实时连着车企的服务器，远程OTA升级，远程诊断，远程控车。

问题来了：攻击面（Attack Surface）指数级爆炸。 以前你只能撬车门，现在你可以：

• 通过蓝牙连接你的车；
• 通过车载Wi-Fi侵入系统；
• 通过手机APP控制你的车；
• 甚至通过360度摄像头识别你的车牌，反向入侵你的云端账户。

2. 软件代码量的剧增

一辆传统燃油车，代码量大概几十万行。 一辆智能电动车，代码量轻松突破1亿行，甚至更多。

代码越多，Bug（漏洞）越多。这就像你写文章，写100字不容易出错，写100万字，里面不掺点错别字和逻辑漏洞，那是不可能的。

3. 供应链的复杂化

你买的车，里头的软件可能来自几十家供应商：博世、大陆、高通、英伟达…… 每家都有自己的开发流程，各自为政。当这些软件集成到一起时，哪里来的漏洞？哪里来的后门？根本数不清。

举个真实的例子： 几年前，两名安全研究员 Chen 和 Ristani 做了一项研究。他们发现，通过分析一辆特斯拉的CAN总线数据，仅仅用了几个月的时间，就能重建出车辆的控制逻辑，甚至能预测驾驶员的下一步操作。这不是科幻，这是现实。

所以，漏洞频发不是偶然，是行业发展的必然阵痛。

二、 过去的糊涂账：功能安全与信息安全的“分家”之痛

在ISO 21434出来之前，汽车行业主要有两个标准在“单打独斗”：

1. ISO 26262：功能安全标准。

   • 核心关注：系统故障导致的危险。比如：刹车失灵、气囊不爆、方向盘卡死。
   • 思维方式：假设系统是“坏了”，怎么让它安全失效？
   • 盲区：它假设“故障”是随机的或系统性的，但不包含人为恶意攻击。

2. ISO 21434 的前身/散乱实践：信息安全。

   • 核心关注：系统被“黑”。比如：数据泄露、隐私暴露、车辆被远程控制。
   • 思维方式：假设系统是“被攻击”，怎么防御？
   • 盲区：它往往只关注IT层面（网络、软件），而忽略了安全目标对车辆物理安全的影响。

典型的“扯皮”场景

想象一下这个场景：

场景：一辆智能汽车的刹车系统被黑客通过远程入侵篡改了信号。车辆高速行驶中突然自动急刹，导致后车追尾，驾驶员重伤。

• 功能安全工程师（按ISO 26262）会说：“我们的刹车系统设计符合ASIL-D等级，故障率低于10^-8每小时。追尾是后车保持车距不当，或者传感器被恶意干扰导致的，这不是我们的‘故障’，是‘攻击’。”
• 信息安全工程师（按旧有标准）会说：“我们扫描了所有网络端口，没有发现已知漏洞。黑客用的是0day漏洞，这是不可抗力。而且，刹车控制单元有看门狗，正常情况下不会误动作。”

结果：没人负责。受害者得不到赔偿，车企互相推诿，政府监管无门。

这种“各扫门前雪”的模式，在智能网联汽车时代，是行不通的。因为信息安全问题，最终都会转化为功能安全问题。

三、 ISO 21434：一场“联姻”革命

2021年，ISO/SAE 21434:2021 Road vehicles — Cybersecurity engineering 正式发布。

这个标准最大的贡献，不是写了几百页技术细节，而是它把信息安全工程正式纳入了汽车产品开发的全生命周期，并且明确要求：信息安全必须考虑功能安全的影响。

1. 核心理念：V模型的双向融合

ISO 21434 沿用了汽车行业熟悉的 V模型开发流程，但在这个V模型里，左侧和右侧都增加了信息安全的维度。

• 左上方（概念阶段）：不仅要定义功能需求（如：车速不能超过120km/h），还要定义安全目标（如：防止黑客篡改车速数据）。
• 中间（设计与开发）：软硬件设计时，既要考虑抗故障设计，也要考虑抗攻击设计。
• 右下方（验证与确认）：测试时，既要做HIL（硬件在环）测试，也要做渗透测试。

2. 关键概念：Cybersecurity Engineering Process（信息安全工程流程）

ISO 21434 定义了一套严密的工程流程，大致可以分为五个阶段：

第一阶段：策略（Strategy）

在造车之前，车企要成立一个信息安全团队，制定全公司的信息安全策略。

• 谁是负责人？（CISO）
• 预算有多少？
• 遵循哪些法律法规？（比如中国的《汽车数据安全管理若干规定》，欧盟的GDPR）

第二阶段：整车型式认证与车辆分析（Vehicle Concept & Analysis）

这是最关键的一步，也是解决“扯皮”的核心。

步骤1：车辆分析（Vehicle Analysis） 把车拆解成一个个“组件”（Component）。

• 例如：摄像头、ECU、网关、手机APP、云端服务器。

步骤2：威胁分析与风险评估（TARA, Threat Analysis and Risk Assessment） 这是ISO 21434的灵魂工具。

TARA要做四件事：

1. 资产识别：什么值得保护？（比如：刹车指令、用户GPS位置、车门锁状态）

2. 威胁场景识别：谁会攻击？怎么攻击？为什么攻击？

   • 攻击者：黑产团伙、国家黑客、恶意车主。
   • 攻击路径：通过蓝牙、通过OTA、通过物理接口。
   • 威胁源：篡改数据、拒绝服务、隐私窃取。

3. 脆弱性评估：系统有哪些弱点？（比如：代码未加密、通信无认证）

4. 风险确定：

   • 这个攻击会导致什么后果？（严重度）
   • 这个攻击发生的可能性有多大？（可能性）
   • 关键点：如果攻击导致车辆失控，那么严重度就要参照ISO 26262的ASIL等级来评估！

   举例说明： 假设黑客可以远程关闭车辆的转向助力。

   • 后果：驾驶员在高速行驶时突然失去转向助力，极易发生致命事故。 -> 严重度：S3（致命）
   • 可能性：需要黑客先攻破防火墙，再注入恶意代码，难度较高，但若漏洞普遍存在，可能性中等。 -> 可能性：P2
   • 可归责性：驾驶员是否有时间反应？ -> C2

   根据ISO 26262，S3/P2/C2 对应的 ASIL等级是 D。

   这意味着：这个信息安全漏洞，必须达到ASIL-D级别的安全性！ 这不是普通的软件Bug，这是要人命的安全件！

第三阶段：产品开发与整合（Product Development）

根据TARA的结果，制定具体的信息安全控制措施。

• 技术措施：
  • 通信加密（TLS/DTLS）
  • 安全启动（Secure Boot）
  • 入侵检测系统（IDS）
  • 访问控制（ACL）
• 管理措施：
  • 代码审计
  • 第三方组件漏洞扫描
  • 员工安全意识培训

这里有个重要变化：以前功能安全工程师不管这些，现在他必须参与进来，确认这些安全措施是否会影响功能安全的实现。

第四阶段：生产、运营与服务（Production, Operation, Service, and Maintenance）

车卖出去了，工作没结束。

• 漏洞响应：如果发现新漏洞，如何快速发布OTA补丁？
• 事件响应：如果车辆被黑，如何追溯、取证、修复？
• 长期支持：一辆车的生命周期是10-15年，如何保证这15年内系统持续安全？

第五阶段：变更管理（Change Management）

车软件升级了，新功能加进去了，会不会引入新漏洞？ 必须重新进行TARA，哪怕只改了一行代码。

四、 深度解析：TARA 到底怎么让“两安全”不再扯皮？

咱们用大白话，结合一个具体案例，看看TARA是怎么解决“扯皮”问题的。

案例：智能座椅加热系统被“冻住”

背景： 一辆电动车，冬季场景。座椅加热由车身域控制器（BDC）控制，通过CAN总线发送指令。

传统视角的扯皮：

• 功能安全团队：“座椅加热是个舒适性配置，不属于安全关键功能（Safety-related）。ISO 26262不适用于它。即使它坏了，也不会导致车辆失控，不需要ASIL评级。”
• 信息安全团队：“我们给CAN总线加了加密，理论上很安全。但黑客如果通过诊断接口（OBDII）物理接入，还是有可能篡改加热指令。”

问题出现： 黑客通过OBD接口注入恶意代码，将座椅加热指令永久锁定在“关闭”状态。北方冬季，车外-20℃，驾驶员上车后座椅无法加热，导致失温、冻伤，甚至影响驾驶专注度，引发事故。

ISO 21434 TARA分析过程：

1. 资产识别：座椅加热控制指令、驾驶员舒适度数据。
2. 威胁场景识别：
   • 攻击者：本地物理接入者（如维修店恶意员工、路边黑客）。
   • 手段：通过OBDII接口发送伪造的CAN报文，禁用加热功能。
   • 目的：恶意破坏、勒索、或单纯恶作剧。
3. 风险评估：
   • 严重度（Severity）：
     • 直接后果：驾驶员冻伤。
     • 间接后果：驾驶员注意力分散、肢体僵硬，增加事故风险。
     • 参照ISO 26262，如果事故风险显著增加，严重度评估为 S2（轻伤）或 S3（致命，若导致严重车祸）。这里暂定为 S2。
   • 可能性（Possibility）：
     • OBDII接口在维修时常用，物理接入难度低。
     • 但加密通信增加了难度。
     • 评估为 P1（可能性高）。
   • 可归责性（Responsibility）：
     • 驾驶员无法预知座椅被远程（物理接入）禁用。
     • 评估为 C1。
4. 风险等级确定：
   • S2 + P1 + C1 = R1（高风险，不可接受）。
5. 安全措施制定：
   • 信息安全措施：OBDII接口增加身份认证，只有授权设备才能发送控制指令；CAN报文增加消息认证码（MAC）。
   • 功能安全措施：虽然座椅加热本身不是安全关键，但其失效模式可能影响驾驶员状态。因此，需要设计降级策略——当检测到异常攻击时，座椅加热进入默认安全状态（如关闭，但保留报警），并点亮仪表盘警示灯，提醒驾驶员注意体温。

结果：

• 功能安全团队必须参与：因为他们要定义“驾驶员冻伤导致事故”的风险等级。
• 信息安全团队必须参与：因为他们要实施“OBD认证”和“MAC”措施。
• 不再扯皮：双方共同确认，这是一个R1级风险，需要同时满足信息安全和功能安全的要求才能量产。

五、 实际落地：车企在做什么？

标准出来了，车企们也没闲着。咱们来看看实际发生了什么。

1. 组织架构调整

很多车企成立了CSOC（Cyber Security Operations Center，网络安全运营中心）。

• 以前，安全团队挂在IT部门下面，地位低，预算少。
• 现在，CSOC直接向CTO或CEO汇报，与功能安全部门平级，甚至更高。

2. 工具链的打通

以前，功能安全用ETAS、Vector工具，信息安全用Burp Suite、Wireshark。 现在，车企开始整合工具链。

• 例如：在AUTOSAR（汽车开放系统架构）中，集成了SecOC（Secure Onboard Communication）模块，专门用于车载网络的消息认证。
• 开发人员在写代码时，IDE（集成开发环境）会自动扫描潜在的安全漏洞，就像检查语法错误一样。

3. 供应链安全审核

车企对供应商的要求越来越严。

• 博世、大陆等一级供应商，必须提供符合ISO 21434标准的TSG（Technical Security Document，技术安全文档）。
• 如果供应商的代码有已知漏洞且未修复，车企可以直接踢出供应链。

4. 渗透测试成为标配

新车上市前，必须经过第三方安全公司的“红队”渗透测试。

• 这就像高考前的模拟考试，专门找茬。
• 如果发现高危漏洞，必须修复后才能上市，否则面临巨额罚款和召回。

案例：特斯拉的“Bug Bounty”计划 特斯拉很早就推出了漏洞奖励计划，邀请全球白帽黑客发现特斯拉系统的漏洞。发现一个高危漏洞，奖励可达数十万美元。这不仅降低了风险，还树立了品牌形象。

六、 挑战与未来：路还很长

虽然ISO 21434解决了“扯皮”问题，但落地过程中，依然面临巨大挑战。

1. 技术复杂度高

• 5G与V2X：车与万物互联，攻击面从车内扩展到车外，甚至整个城市交通网络。
• AI的引入：自动驾驶算法本身就是个“黑盒”，如何保证AI不被对抗性样本（Adversarial Examples）欺骗？这是新的难题。

2. 成本上升

• 安全开发需要更多的人才、工具和时间。
• 一辆车的BOM（物料清单）成本中，安全相关的占比从过去的不足1%，上升到现在的5%-10%甚至更高。
• 最终，这些成本会转嫁给消费者。买车时，你会为“安全性”支付溢价吗？

3. 法律法规的差异

• 欧盟有UN R155法规，要求车企必须通过网络安全认证才能上市销售。
• 中国有GB/T 40855-2021等标准，正在逐步完善。
• 美国则更多依赖市场机制和NHTSA（国家公路交通安全管理局）的监管。
• 跨国车企需要在不同市场满足不同的合规要求，压力巨大。

4. 人才短缺

• 既懂汽车电子，又懂网络安全，还懂ISO 26262和ISO 21434的复合型人才，极度稀缺。
• 目前，这类人才年薪百万都难挖。

七、 给普通车主的建议：如何保护你的“数字财产”？

作为消费者，我们虽然不是工程师，但也可以做一些事情，保护自己的车辆和隐私。

1. 定期更新软件： 如果车机提示有OTA升级，尽量及时更新。很多漏洞修复都在升级包里。

2. 谨慎连接蓝牙和Wi-Fi：

   • 不要随意连接陌生的车载蓝牙。
   • 在公共场所，避免使用车载Wi-Fi热点访问敏感信息（如网银）。

3. 物理接口保护：

   • 如果没有必要的诊断需求，可以考虑物理封堵OBDII接口（有些高端车型或改装店提供此服务）。
   • 停车时，确保车门锁好，车窗关严。

4. 检查隐私设置：

   • 查看车机系统中的隐私选项，关闭不必要的地理位置共享、语音助手云端录音等功能。
   • 卖二手车前，务必恢复出厂设置，清除所有个人数据。

5. 关注品牌声誉： 选择那些在网络安全方面投入较大、有明确安全响应机制的车企。

结语：安全是出行的底线，也是品牌的底线

ISO 21434的诞生