汽车网络安全 CyberSecurity ISO/SAE 21434 测试之三

一、ISO/SAE 21434 第7章

接下来是ISO/SAE 21434的第七章——分布式开发中的网络安全管理 。

这一章的核心是：如何管好供应链上的网络安全 ，从OEM到Tier 1、Tier 2，甚至内部供应商，一个都不能少。

1. 为啥需要管供应商？

举个栗子 ：
如果车企用了一个供应商的车载娱乐系统，结果这个系统有漏洞被黑客利用，那整车的安全性就崩了！所以供应链上的每个环节都得“上锁”。

2. 三项核心活动：供应商管理的“三板斧”

从上图我们知道，供应商管理主要从供应商能力评估、报价以及网络安全职责界定等三个方面展开。

（1）供应商能力评估

干啥的？ 先看看供应商有没有能力保障网络安全。比如：

• 是否有漏洞管理流程？
• 能不能做渗透测试？
• 发生安全事故时能不能快速响应？

因此，我们得到如下结论：

• 应评估候选供应商按照本标准进行开发和后开发活动的能力；
• 供应商应提供网络安全能力的记录，如组织能力证据、持续性网络安全活动和网络安全事件响应的证据、过往网络安全评估报告摘要。

这里提到一个概念叫做后开发能力，这是因为安全是“终身大事”！开发完成≠安全结束 ！供应商还得持续做：

• 打补丁 ：发现漏洞立刻修复；
• 渗透测试 ：定期“找茬”，确保系统没被攻破；
• 监控响应 ：一旦被攻击，马上启动应急预案。

（2）报价（CIA协议）

客户向供应商发出的报价请求应包括：

• 正式要求符合本标准；
• 要求供应商按照CIA承担网络安全职责；（Confidentiality、Integrity and Availability）
• 相关的网络安全目标或网络安全要求。

那么，CIA是啥？ 这是网络安全的“铁三角”：

• 机密性 （Confidentiality）：数据不能被黑，比如用户隐私；
• 完整性 （Integrity）：数据不能被篡改，比如刹车指令；
• 可用性 （Availability）：系统不能瘫痪，比如自动驾驶必须随时在线。

因此，报价阶段要明确 ：

• 双方的安全联络人是谁；
• 各自负责哪些安全活动（比如车企做测试，供应商打补丁）；
• 需要共享哪些信息（比如漏洞报告）。

（3）网络安全职责界定

• 客户和供应商应在CIA中规定分布式网络安全活动，包括：联络人；分别开展的网络安全活动；裁剪；信息共享；分布式开发活动的里程碑；网络安全活动结束支持的定义等。
• CIA应该在网络安全活动开始前商定。
• 如果存在需要进行管理的漏洞，就行动责任达成一致。
• 如果要求不明确或不可行，或与其他需求冲突，应互相通知。
• 应在责任分配矩阵中明确责任。

看着内容很多，实际上关键点就是 ：不能“甩锅”！必须白纸黑字写清楚：

• 供应商负责哪些安全任务（比如维护车载系统）；
• 车企负责哪些监管（比如定期审计）。

因此，总的来说，第7章就是教车企和供应商“绑在一根安全绳上”——从选伙伴到签协议，从开发到维护，全程都得盯紧网络安全！

二、ISO/SAE 21434 第8章

第8章主要是持续的网络安全活动，在生命周期的所有阶段进行，主要目的是监控网络安全信息以确定网络安全事件，评估网络安全事件以确定弱点，从弱点中识别漏洞，管理已识别的漏洞。

1. 网络安全信息监控

• 首先我们需要监控网络安全信息，那就需要选择选择适当的来源以收集网络安全信息（尚未确定相关性的网络安全信息），包括内部来源和外部来源：

  • 内部来源：相关项定义、网络安全声明、网络安全规范、威胁场景、过往漏洞分析、现场信息（漏洞扫描报告、维修信息、消费者使用信息），比如车厂自己定义的功能项、安全规范、威胁场景，还有以前的漏洞分析报告、用户反馈（比如维修记录、消费者投诉）；

  • 外部来源：网络安全研究者、商业或非商业来源、供应链、客户、政府，比如网络安全专家的研究成果、供应商提供的信息、政府发布的安全公告，甚至黑客论坛里的讨论，举个栗子 ，如果发现有人在论坛上分享了某款车载系统的破解方法，这就是一个潜在的安全信息，得赶紧跟进！

• 其次，我们得确定什么是“真问题”？不是所有信息都算“网络安全事件”，得筛选出和你的系统相关的。

  • 比如某个漏洞可能影响刹车系统，这就是一个“网络安全事件”。因此，我们需要定义触发条件以筛选出网络安全事件（与相关项或组件相关的网络安全信息），网络安全信息可成为一个或多个事件。
  • 举个栗子 ：如果你收到一条消息说“某车载娱乐系统有漏洞”，但你的车压根不用这个系统，那就不算事件；但如果这个系统会影响刹车，那就必须重视！

2. 网络安全事件评估

干啥的？ 其实就是找弱点。分析事件，看看系统里有没有缺陷 （weakness）。

监控到网络安全事件后，我们应进一步分析网络安全事件（event），确定相关项或组件的缺陷，即弱点（weakness）。

• 如果存在弱点，并且存在补救措施（如供应商提供补丁），可以将该补救措施作为一个假定的漏洞来处理，事儿就到此为止，不再需要其他活动；
• 如果发现TARA分析遗漏的威胁场景，可更新TARA。（Threat Analysis and Risk Assessment）
• 举个栗子 ：假设你发现黑客可以通过蓝牙入侵车载系统，但之前的TARA没考虑到蓝牙安全问题，那就得重新评估风险。

3. 漏洞分析

找到弱点后，我们就需要进行分析，弱点是不是“漏洞”？

也就是说，弱点应进行分析以确定为漏洞。

• 基于架构进行攻击路径分析、攻击可行性等级分析；
• 可以配合根本原因分析，确定弱点成为漏洞的任何潜在可能性；
• 如果不存在攻击路径、或攻击可行性等级很低，弱点不被视为漏洞；
• 对于未被确定为漏洞的弱点应提供理由。

也就是说，黑客能不能利用这个弱点攻进来？攻击难度高不高？如果难度很高，可能不算漏洞，那就不用管它，但得写明理由。

举个栗子 ：
如果某个弱点只能通过物理接触车辆才能利用（比如拆开车门），那可能不算漏洞，因为攻击成本太高。

4. 漏洞管理

即怎么“堵住漏洞”？

对已识别的漏洞进行管理，保证风险被处置，直到网络安全支持终止。

• 通过TARA方法对漏洞评估和处理，或独立于TARA的补救措施来消除漏洞，比如开源软件的补丁；
• 如果漏洞管理导致项目或组件的变更，进行变更管理。
• 对已识别的漏洞信息需要共享，即把漏洞信息告诉相关方（比如供应链、客户），大家一起防着点。
• 如果漏洞发展成为网络安全事件（incident），网络安全事件响应过程可以独立于TARA进行应用。比如黑客真的入侵了，就得启动应急响应流程，独立于TARA快速处理。

举个栗子 ：
如果发现一个开源软件有漏洞，赶紧打补丁；如果补丁改了系统功能，还得通知相关部门测试，确保不会引发新问题。

总结一下 ：
第8章的网络安全信息监控，实际上就是一套“发现问题、分析问题、解决问题”的闭环流程。