一汽-大众：智能网联汽车信息安全分布式开发实践
2024年6月27日，在第三届中国车联网安全大会上，一汽-大众汽车有限公司产品信息安全开发负责人王嘉明认为，当前主机厂在信息安全开发过程中面临诸多问题，主要是从风险评估到导出安全概念以及安全规范的过程，其中最重要的是提好需求，让Tier1更好开发。
王嘉明强调，信息安全需求需要从风险评估而来，如何通过风险评估得到准确明了的安全需求，风险评估至关重要。无论是欧洲的UNECER155法规还是国内的汽车整车信息安全技术要求，都强调对车辆进行完整的风险评估。
王嘉明｜一汽-大众汽车有限公司产品信息安全开发负责人
以下为演讲内容整理：
OEM网络安全开发概述
当前，众多主机厂都已基于ISO21434标准建立起了一套完善的信息安全开发流程。目前，我们要求大多数的Tier1供应商也遵循这一流程进行信息安全开发，并且已有许多Tier1供应商成功获得了ISO21434的认证。与Tier1供应商的主要区别在于，作为主机厂，我们还需要对整车的整体框架性要求进行把控。
图源：一汽-大众
其次是风险评估，我们会从整车角度出发进行风险评估，进而明确后续的安全概念及安全规范。作为合资厂商，我们会将这些安全需求统一传达给Tier1供应商，由他们负责具体的开发实施。在开发模型中设有相应的测试验证阶段，这一阶段会识别出潜在的漏洞和难以处理的风险。对于可接受的风险，我们将通过安全手段进行减弱；对于残余的风险，我们将进行风险处置，这包括继续修复或选择接受，并在后续进行监控和日后处理。最终，当所有风险均达到我们可接受的范围内，即达到预设的阈值，我们将进行安全释放和安全认可。
作为主机厂，我们与Tier1供应商的主要区别在于我们具备一个从整车角度出发的安全策。它规定了整车信息安全开发过程中的基础框架。通常它包含如下部分内容：第一部分详细阐述了开发的前提条件，为整个开发过程设定了基调。第二部分则是对我们在整车开发过程中所使用的开发文档的概述。包括企业标准、安全基线、所遵循的法律法规，以及开发过程中采用的具体工具和模板等。第三部分详细描述了整车开发过程中应遵循的总体流程，这一流程确保了开发活动按照既定的步骤和顺序进行，从而保障产品的质量和安全性。安全政策定义好后，就可以深入到主机厂的信息安全开发过程。
在分布式开发模式中，传统主机厂向Tier1供应商提供安全需求以便开展后续的开发工作。因此，我们面临的核心挑战之一是确保安全需求的准确性和明确性。从风险评估到导出安全概念及制定安全规范，每一步都依赖于对需求的精准把握。我们进行了经验总结。
最佳实践：传统OEM安全开发
在主机厂的信息安全开发中，安全需求并非凭空产生，而是基于深入的TARA分析和风险评估。这些需求均源自对潜在风险的全面识别与评估。法规的遵从性也是信息安全风险评估的重要依据，例如欧洲UNECER155法规和国内汽车整车信息安全强制标准，都明确规定了主机厂需对其车辆进行完整的信息安全风险评估，以确保能够准确识别并应对各类风险。因此，进行信息安全风险评估是导出风险、明确信息安全需求的必要环节。
风险评估作为信息安全工作的重要环节，目的在于识别和分析车内系统存在的风险，并根据这些风险制定相应的安全措施，以降低风险至可接受的水平。在进行风险评估时，我们通常从两个角度衡量风险的大小。横轴代表攻击可能带来的潜在影响，这一影响通常通过人身安全、经济影响、功能影响、个人敏感信息泄露四个维度评估。纵轴是被攻击的可能性，被攻击可能性越高代表该车越容易被攻击、风险越大，因此最终风险的高低是由被攻击的可能性和被攻击后所能造成的影响两个维度决定的。
基于上述风险评估流程，市场上的众多OEM和Tier1供应商在进行风险评估时，仍然倾向于使用Excel等工具。尽管有些主机厂已经采用了更为电子化和采购的专用工具，但从总体思路来看，它们仍然遵循着前述的流程，这也导致了某些共性问题的出现。在实际操作中，我们观察到评估结果往往篇幅巨大，大量重复，甚至包括了一些针对安全目标强行分析的现象。因此往往导致评估结果大量冗余，可视效果差，质量下降，难以导出准确而有效的风险控制措施，而更多地停留在分析的层面，有较大的提升空间。
在完成了安全属性的优化后，要对这些属性被破坏后可能造成的影响进行深入分析。在进行影响分析时，我们也可以采用一定的方法和思路简化评估过程。首先，我们可以对资产可能造成的损害进行分类。以车内信号为例，不同的信号具有不同的功能和重要性。一些信号直接用于控制车辆，而另一些则仅用于在屏幕上显示信息，能够控制车辆的信号如果被破坏，所造成的损害将更为严重。因此在风险评估过程中，我们可以将那些仅用于显示的信号视为低风险资产，无论其被攻击的可能性有多高，所造成的风险通常都较低，基于这一认识，我们在进行风险评估时，可以省略对这类信号后续步骤的深入分析，因为它们的风险水平不会超过风险接受的阈值。
在进一步延伸关于风险评估的讨论时，无论采用何种风险评估矩阵，评估流程通常都遵循先分析影响再评估被攻击的可能性的顺序。如果某个潜在风险的影响被评估为非常低，存在无论该风险被攻击的可能性有多高，其整体风险水平都不会超出阈值的情况。因此，在进行风险评估时，一旦在影响分析阶段确定某个风险的影响非常低，那么接下来的步骤中，无需再详细考虑该风险的攻击路径和攻击可行性，这种简化的评估方法不会影响最终的风险评估结果。
完成损害程度评估后，分析攻击可行性同样可以做取舍。假设攻击者采用最简单的攻击路径对目标进行攻击，如果这种最简单的攻击路径是无法防范的，如直接进入车内对CAN总线信号进行DOS攻击等物理攻击，那么针对更困难的攻击路径所造成相同或更小的损害而提出安全措施并不会降低相应风险，因此针对更复杂的攻击路径提出安全措施是没有意义的。
在安全控制的实施过程中，一个经常被厂商忽视的步骤是对安全控制措施中的新增资产进行全面的风险评估。例如采用加密的安全措施会引入密钥，密钥作为一项重要的安全资产，其完整性、机密性和真实性一旦被破坏，将可能导致严重的安全风险。因此，密钥的引入必须重新纳入TARA分析流程中，以全面评估其可能带来的风险。
因此，从TARA分析、安全规范以及安全概念的角度出发，风险评估结果所导出的应当是安全概念，而非安全规范。安全概念是一个宏观的类别，可能是传输层安全，外部接口安全，也可能是操作系统安全等等，针对每一个类别都应该有更为详细的需求。这是在分布式开发过程中真正能够提供给Tier1供应商做开发的安全需求，即安全规范。这也是作为传统主机厂历经多年最重要的积累，未来也一定是国内主机厂和Tier1的发展方向。