在上一篇关于UN R155和ISO/SAE 21434的博文中，我说明了汽车业及汽车行业供应商如何被赋予了为每辆车配备网络安全性的责任。汽车网络安全是一项重大的挑战，UN R155和ISO/SAE 21434等新规已经生效，从2024年款起，所有车辆都将强制执行。我们来深入探讨一些汽车厂商及其供应商现在和将来面临的问题。
规模惊人
ISO/SAE 21434要求汽车厂商提供清晰、可理解且有辩护依据的理由，并有证据和文件支持，以证明某物项或组件在应用时有足够的网络安全性。为实现这一目标，汽车厂商必须确定网络安全与各物项或组件的相关性；对于相关的物项或组件，汽车厂商可以进行分析和风险评估 (TARA)。评估后，他们可以得出一套网络安全目标和要求，实现可验证的安全水平。
由于每辆车都有数百个可能带来网络安全问题的组件，再加上最后期限紧迫，这一流程不仅对汽车厂商构成了严峻的挑战，对其供应商也是如此。现代汽车越来越依赖无线通讯来与周围环境交互并利用基于云的服务。这种连接在汽车内部得以延续，因此车内几乎每个电子组件都可能成为黑客的潜在目标。
2021年9月，恩智浦宣布符合ISO/SAE 21434汽车网络安全新标准，刚刚通过了第一次年度重新审计。
安全设计和遗留组件
理想情况下，这一挑战应在设计的最初阶段解决。“安全设计”也逐渐成为许多汽车供应商的标准做法。然而，当今许多汽车系统 (ECU) 的半导体和软件组件在标准获得批准甚至制定之前就已经完成设计。这并不意味着它们不安全，而是需要对这些系统进行威胁分析和风险评估 (TARA)；根据评估得出最新的安全要求；收集和分析现有文档以确定是否能够满足这些安全要求。如果现有文档已经足够，则必须执行其他安全活动，如回顾性设计审核或渗透测试，以弥合差距。这样做可能代价高昂，因此必须仔细确定是否应该进行评估，尤其是对于可能即将报废的“遗留”组件。在某些情况下，升级到较新的组件可能是更经济高效的方法
模糊性
汽车厂商和供应商的密切合作和共识至关重要。幸运的是，ISO/SAE 21434通过词汇表及其定义的安全工程框架提供了基础。不过，“产品是否合规？”这个简单的问题很难回答。很难回答是因为该标准留有充分的解释空间。例如，流程步骤只是广义的定义，而要求是相当通用的。因此，“合规性问题”是由客户 (汽车厂商和Tier 1供应商) 根据他们对标准的解释来判断的。因此，问题在于产品以及在开发和后续生命周期阶段应用的流程是否符合其解释。如果该标准的第二版能减少模糊性，将会很有帮助。
组件“脱离使用场景”
我们还观察到，汽车厂商和Tier 1供应商的采购程序通常采用“使用场景”组件，使用场景组件是为满足特定使用情形 (即使用场景) 的特定要求而开发的。然而，大多数半导体被设计成通用的“脱离使用场景”的组件，因为它们可用于各种用例。组件的使用场景通常不明确，仅仅基于假定用途，以及与客户的接触或与客户签订的协议。使用场景的不匹配会导致效率低下，带来各种挑战。
《网络安全/开发接口协议》(CIA/DIA协议) 适用于供应商与客户合作，在已知使用场景的情况下进行共同开发，如果没有合作开发，客户仍坚持必须符合CIA/DIA协议，则可能会造成效率低下。然而，这类协议并没有为脱离应用背景的开发增添多少价值。此外，客户通常拥有独立的CIA/DIA协议模板，这会进一步增加工作量，因为创建每个组件时需为每个客户创建单独却内容相同的文档。能精简这种冗余问题的流程将提高这一方法的效率。
了解恩智浦如何帮助加速向安全设计转变，点击下载白皮书>>
对半导体和软件的要求
当客户根据其对标准的理解向采购流程添加新的具体要求时可能会带来挑战。安全编码规则就是个很好的例子。该标准有一项一般性要求，即编程语言未涉及的网络安全标准应包含在编码指南或开发环境中。该标准提供了一些提示，但没有提供编码指南。因此，客户会定义自己的编码规则并通常要求严格遵守。有些甚至指定了必须用来检查合规性的具体工具版本。
这带来了一些挑战，特别是对半导体和通用软件而言。首先，不同的客户可能有不同的要求，这与开发通用组件以服务于多个客户和用例 (以实现规模经济) 的目标相悖。其次，脱离背景组件的采购流程通常在其开发项目结束后进行，并且考虑自定义要求，流程的后期可能不可行或成本过高。
因此，非常需要一套明确的半导体和软件编码指南和其他通用要求；理想情况下，指南应尽可能地重复使用。MISRA C是个很好的起点，已使用多年，是用C语言开发汽车软件的实际标准，其中功能安全和网络安全至关重要。
常见威胁情景、攻击可能性评级和保障级别
另一个挑战是缺乏衡量威胁情景和攻击可能性评级的通用基准。尽管R155提供了车规级的一般威胁列表，但并未针对半导体做出规定。因此，很难与客户就特定产品的攻击类型达成一致。
要就风险评级和更具体的攻击可能性达成一致也很困难。ISO/SAE 21434附件G为基于攻击可能性、基于CVSS和基于攻击向量这三种不同的评级方法提供了指南。虽然这些指南非常有用，但是并不十分一致——采用不同的方法可能会导致对同一攻击的评级完全不同。业界如果就半导体和软件选择哪种方法达成共识将有所帮助。或许更重要的是，利益相关方明白，尽管这些评级有助于确定问题的优先级，但肯定不是完美的，因为总有“误差幅度”。因此，这种评级不应作为业务流程或法律协议中的硬指标而忽视了专家判断的必要性。
同样，业界在保障水平方面尚未达成共识。该标准的附件E介绍了网络安全保障等级(CAL)，可用于具体说明并传达一套严格的保障要求，确保组件保护得到充分发展和验证。这些指南也并不是很具体，因此，如今很少有机构提及这些指南也就不足为奇了。但是，定义明确的保障级别将提供有用的指标，使客户能够确信产品满足其安全要求，其安全能力值得信任。
业界已经采取了一些举措来弥合这些差距。例如，ISO/SAE PWI 8475正在解决目标攻击可能性 (TAF) 和网络安全保障级别 (CAL) 问题。此外，在MITER ATT&CK的启发下，汽车信息共享与分析中心 (Auto-ISAC) 正在研究汽车威胁矩阵，有望作为通用汽车威胁模型的基础用于汽车及其组件。最后，在涉及经济高效的方法时，有几项举措可以保证产品符合其安全目标。其中一项是SESIP，这是一个新的认证方案，旨在满足对通用、优化方法的需求，以便评估不断发展的物联网生态合作体系中连接设备的安全性。
知识共享让知识翻倍
这不仅关乎要求和指标。如今，许多公司都有核心能力团队，他们对UN R155和ISO/SAE 21434有着广泛的了解。然而，这些专业知识也必须转移到其他团队，从设计和开发到产品管理、客户经理、现场支持工程师、质量保障、采购等。安全是一项团队运动，所有相关人员都必须至少具备基本的安全知识才能在职责范围内做正确的事情。没有基本的安全知识，就可能出现明确而现实的危险，即最终在合规方面采取“复选框”的做法。众所周知，这种方式不能带来有效的安全性和抗风险能力。
长期安全支持
UN R155要求在整个产品生命周期中对安全性进行管理。一般而言，这意味着必须监控威胁状况以发现新的威胁，并在出现漏洞和事件时对其进行管理。最大的挑战在于车辆及其组件的寿命很容易达到20年以上。ISO/SAE 21434更宽容一些，允许产品在生命周期结束前终止网络安全支持。争取网络安全长期支持是必要的一步。然而，这种支持不是免费的；由于需要经常性投资，付费服务模式可能不可避免。例如，保留知识、工具、IT设备和实验室环境所需的经常性投资。
协作是关键所在
到那时，我希望大家已经清楚地认识到：合作是汽车业及其供应商在有限时间内满足UN R155和ISO/SAE 21434广泛要求的唯一途径。这意味着，在实践中，客户与供应商的直接接触至关重要。
正如我之前在博客中所述，Auto-ISAC (汽车信息共享和分析中心) 是连接汽车业网络安全专家的关键平台。这提供了一个极好的机会，专家可以通过交流经验和最佳做法来应对一些共同挑战。在整个行业开展公开对话可以大大减少提供安全解决方案所需的时间。时不我待。
