Cybersecurity ASPICE实施策略-基于ISO/SAE 21434-亚远景科技

近几年，随着软件定义汽车和汽车的智能化和网联化，使得汽车融合了现代通信与网络通信技术，实现了车与人、车与车、车与道路、车与云端等智能信息交互和共享，也让车具备了环境感知、协同控制、智能决策等功能；与此同时，这些功能的实现，也增加了网络安全漏洞的发生概率，因此也加大了汽车被攻击的风险。

如何在车变得越来越智能化的同时，还能够有效降低网络安全事件发生的概率和影响程度，这成为了从OEM到Tier1、Tier2等整个汽车产业链需要重点考虑的事情。

因此， 近几年也出台了很多关于网络安全方面相关的法规和标准，例如：R155/156、ISO21434等，但是这些法规和标准如何在汽车电子产品研发过程中有效落地实现，VDA组织制定了对应的Cybersecurity ASPICE标准，以指导目开发过程中对网络安全要求的实现。

随着车越来越智能化，车与外部信息交互和共享也越来越多，这也就增加了网络安全漏洞被外部恶意利用进行攻击的可能性。10个主要被攻击的模块：

1. IVI 信息娱乐系统

2. T-Box 车载网络通信终端

3. OTA 汽车远程升级

4. ADAS/ADS 高级辅助驾驶系统

5. 手机端车联网应用

6. 充电网络系统

7. OBD 车载诊断

8. TSP 车载

9. Gateway车载网关

10. UDS 统一诊断服务

2023年汽车安全事件分布情况：

2023年汽车漏洞分布情况：

正在做或者做过汽车电子电气产品开发的朋友，大概率听过2个英文单词Safety和Security，翻译成中文好像都可以叫“安全”。但实际上，这两个词的意思是有区别的，网络安全的英文是Cybersecurity，另一个英文说法Functional Safety，中文是功能安全。

功能安全，注重的是我们自己做的产品内部出现了Bug或者故障，导致了人员伤亡，讲究2个点，一个是产品内部出问题，导致人员伤亡。

网络安全，注重的是我们自己做的产品功能是Ok的，但存在一些漏洞或者弱点，被外部恶意利用或者不小心进行了攻击，导致产品里面的资产受到了损失，例如用户信息被盗取。

因此从这个视角看，Safety和Security的区别就比较容易理解了，

Safety关注自己产品内部，Security关注外部攻击；

Safety关心人员伤亡，Security关心资产损失。

网络安全相关标准背景情况：

UNECE：联合国欧洲经济委员会的缩写。

R155：英文是：Cybersecurity Management System，简称CSMS；是对车辆网络安全管理方面的法规要求。

R156：英文是：Software Update Management System，简称SUMS；是对车辆进行软件升级管理方面的法规要求。

这两个法规主要是对整车的要求，整车车型在市场上销售之前，必须进行型式认证，也就是我们经常会听到的VTA认证，目的是：整车厂要保证实际的工作和过程体系是一致的，对过程体系进行认证，过程是OK的才准许车型进行销售。

它们都适用于乘用车、货车、卡车和公共汽车，尤其是这些汽车如果有软件更新需求，则更加适用于两个法规的要求。

R155法规，在过程需求和型式认证需求2个维度，对网络安全提出了相关要求：

过程需求层面：

车辆在设计过程中，要能够识别和管理网络安全风险，并且能够监控和有效对应网络安全攻击等。

型式认证层面：

在认证前，网络安全管理系统已经部署到车辆中，能够通过一些测试方法证明这些措施能够达到预期效果，将监测活动报告递交给相关的认证机构。

2022.7月所有新车型必须进行R155/R156的VTA认证；2024年7月所有车型必须满足R155/R156要求。ISO（国际标准化组织）同步给出了一个标准21434，可以作为主机厂参考的标准以满足R155的法规要求，用21434进行CSMS的构建。

我们的国家网络安全相关的国标目前正在制定中，预计在2025年1月出台，应该是在2026年1月对所有新车型要求进行网络安全认证。

实际工作中，欧盟的R155是对主机厂的要求，要提供整个车辆中所有零部件在研发端和管理端都具备网络安全特性。这就使得主机厂不得不对供应商提出网络安全要求，对供应商进行管理，这就意味着欧盟管主机厂、主机厂管供应商。那么具体的研发端，不管是主机厂自己的研发还是供应商的研发，需要知道要做些什么，要用什么样的形式满足网络安全的要求。当前主机厂依赖21434构建CSMS，可是主机厂如何对供应商的网络安全进行管理呢？

VDA提供了2个解决办法，一个是VDA ACSMS，这个标准主要是一套Checklist，第2个是ASPICE For cybersecurity。这两个标准主要是指导供应商怎么证明自己完成了对应的网络安全工作，或者是主机厂如何管理供应商来识别它是否完成了网络安全的工作。

5112比较针对组织，是一套公司体系的checklist，可以类比16949，公司内部做体系审核的时候，把5112加进去进行审，标明公司具备网络安全体系。

ASPICE for Cybersecurity，是针对具体的某个特定项目，例如内部有大众项目、福特项目；每个项目单独存在，每个项目可以使用黄色的这个标准进行项目级的评估，评估项目的实施是否实现了网络安全的要求；类比当前的ASPICE评估。

VDA交出了2个工具给到企业进行使用，基于VDA与德系车厂的关系来看，德系车厂会使用这两个标准对供应商进行管理。

对于我们具体的一个研发项目，有各种要求。

基本要求：客户一套SOR，里面包含了产品的功能、交付要求、时间要求、质量要求。但是同步呢，当前做汽车行业的项目，有很多额外的要求。

比较通用的要求：任何产品都会面临的要求，是研发的过程一定要合规，ASPICE是里面的核心标准。ASPICE间接有一些进阶的标准，如果做德系的项目，要满足ASPICE Guideline、KGAS（大众），相对ASPICE会更难一些。

往下会有非常通用的标准，组织级别的体系标准16949，在汽车产业链也用了很多年了，主要是整体的产品生命周期标准，更偏生产端的内容。

因为网络安全的介入，现在在组织体系又提出了一些信息安全相关的要求，对于主机厂要建CSMS，对供应商来说更关心信息安全。只要是带有一些软件的产品都要考虑的通用标准；对于安全产品，属于特殊产品，只要涉及到人生安全、资产安全，就要考虑功能安全标准和网络安全标准；同时，在网络安全标准中有一个ASPICE For Cybersecurity。

现在做一个行业的项目，不仅要考虑正常这个功能怎么做，有没有人做；还要考虑在实现这些功能的过程中满足下面这四个方面的要求。

亚远景科技作为咨询方，重点解决的就是这四个标准的问题，帮助研发单位们能够更高效的实现这里面的要求。

21434是基于R155提出的CSMS而产生的标准，对整车的全生命周期从设计开发、到量产、到维护，到对应的报废提了核心的网络安全要求，这也体现了网络安全的一个特性，网络安全是应对外界的攻击，攻击是无时无刻可能会发生，并且可能会升级的，因为技术手段在不断的升级；所以整车的全生命周期都要关注这个事情。

当前21434在行业里定的范围是相对比较广的，我们认为非常广，21434的应用范围是大于功能安全，小于ASPICE的。假如你的产品被要求要满足功能安全，那么必须要做网络安全。假如你的产品不在功能安全范围内，但是可能用到了一些关键信息，不管是乘客的私人信息、道路信息、车辆信息等敏感性带有保护性质的隐私信息。如果你用到了网络，用到了整车通信网络，包括CAN、LIN等，那基本上也跑不掉。

所以，基于这三个点大的要求，整个车辆上大部分带软件的产品基本都在21434的范围内，从这些层面看21434引发的工作范围是比较广的。

21434当前的标准框架，类似于26262的框架，熟悉26262标准的人可能会看着眼熟。当前这个标准只有80多页，只相当于一本书，26262是每个PART分了一本书。

这些PART里，5、7、8是对组织级的要求，里面的内容不针对某个特定项目，而是组织应该构建一种能力，这个能力应该能支撑所有项目网络安全相关的事情；其他的 6、9~15，这些PART都是项目级的要求，就是说要做一款产品，必须把6、9~15里面要求的事情都得做一遍。

所以21434就变成了2个层面的事情，一个是公司需要具备什么样的能力才能满足网络安全的要求；另一个是项目上要做什么能够满足网络安全的实现组织层面的事情。

第5章：

整个公司需要有对应的网络安全文化、网络安全管理系统、网络安全管理工具、信息安全管理、组织级网络安全审计等。

第7章：

供应商分布式开发的管理，考虑分布式的开发、供应商的网路安全能力、供应商的网络安全职责等。

第8章：

当你的车型在路上外面跑的时候，需要有一个高效的反馈机制和一个应对机制，当市面上出现了信息泄露或者威胁，甚至还没出现的时候，你就要监控你的产品是否有这方面的风险，如果发现了，当做一个网络安全事件进行管理，类似于售后管理、重点投诉管理或者召回之类的事件管理。

因此，不管是主机厂还是供应商，主机厂压力大一些，供应商压力小一些。

ASPICE是一个行业通用的开发过程标准，另外，主机厂在管供应商的时候，也希望能够通过一种手段能看到供应商做的产品到底做的怎么样，仅仅通过黑盒测试是不够的，供应商的开发过程是否正规，是否在交付前做了应该做的开发活动。

因此，ASPICE提供了一种assessment的手段，给到主机厂或者供应商进行审核或者自评，来了解供应商的开发过程到底做的怎么样。当前德系车厂用的比较广泛，国内主机厂现在也基本对供应商提出了这个要求。

ASPICE 3.1：

整个ASPICE分了32个小方框，每个方框被叫做一个过程，指的是项目中一类聚合的活动，这些过程中，包含了有工程类的过程活动、管理类的过程活动、以及支持类和供应商相关的过程活动。

红色框部分，是官方推荐的16个过程，比较被主机厂主推。假设之前我们基于ASPICE构建了内部的研发能力，现在的现状就是有一套基本的开发办法，我的团队能够以一种完整且有序的方法把这套东西给弄出来。

接下来就看网络安全要什么，我们怎么利用这套能力去支撑网络安全在研发过程的快速实现，基于这种情况，又产生了一个新的标准ASPICE for Cybersecurity。

​

VDA提出ASPICE for Cybersecurity 这个标准的核心目的是，企业之前已经有了ASPICE，21434出来了后，如何在研发过程中快速实现网络安全的要求。这个标准形成了一个桥梁，帮助企业快速把21434的要求导入到现在已经有的ASPICE要求上来。它是基于ASPICE 3.1的版本制定的，在2021年正式发布，后续可能会并入到ASPICE 4.0里；它作为ASPICE3.1的增量标准，衔接网络安全的要求，快速把网络安全要求导入到项目中。

简单点讲，如果你们现在已经形成了ASPICE能力，想在研发端快速形成网络安全能力，那么就可以把这个标准搞一遍。

上图的红框是VDA Scope推荐的过程域，现在增加了绿色的框，主要是中间的SEC，就是Security的方面，这4个过程是帮助串联之前的需求、设计、测试等需要额外做什么事情。

右边的MAN.7是新增的，主要是网络安全风险管理，是帮助把21434标准中的TARA与实际项目衔接起来的过程；左上角的ACQ.2，对标21434标准中的第7个PART，主要是如果有一些网络安全风险要转移给供应商，需要考虑供应商承接网络安全的能力，以保证实现网络安全要求，所以有这个供应商要求和选择的过程。

稍微总结一下，如果我们之前具备了ASPICE能力，想快速导入网络安全能力，那就拿着这个标准去套，理论上就可以找到Mapping的点了。

这几个过程域的主要目的：

MAN.7 网络安全风险管理

1、识别、优先排序和分析损害风险

2、持续监控各自的风险处理方案

从以上几个BP的要求来看，MAN.7的实施可以对应到ASPICE中的MAN.5，以及ISO21434的TARA。

ACQ.2  供应商请求和选择

1、基于网络安全需求选择供应商

2、聚焦供应商的网络安全能力

3、给供应商发出RFQ/合同

RFQ中可包含：

1、符合所有与客户相关的法律标准的正式请求；

2、供应商的网络安全职责；

3、网络安全方面的工作范围，包括网络安全目标或一套相关的网络安全要求及其属性；

4、已识别偏差和风险的行动计划；

SEC.1   网络安全需求挖掘

从风险管理的输入提取出网络安全目标和网络安全需求。

从这4个简单的BP内容看出，首选需要先提取出网络安全目标，在ISO1434中的9.4和9.5章节分别是网络安全目标和网络安全概念。

网络安全目标可以从三个方面考虑：

1、需要被保护的资产

2、网络安全等级

3、网络安全申明

基于网络安全概念，需要考虑：

1、技术或操作的网络安全控制要求

2、为达成网络安全目标的相关项网络安全需求

3、分配网络安全需求

基于这些可以很容易对应到ASPICE的SYS.1 需求挖掘、SYS.2 系统需求分析和SWE.1软件需求分析这三个过程域，如果不了解这几个过程域内容的，可以去读一下ASPICE标准，就不在这里展开讲。

SEC.2   网络安全实施

分配网络安全需求给到系统和软件的组件，以确保需求被实现。

从这10个BP可以看出，这些要求能够对应到ASPICE中的SYS.3 系统架构设计、SWE.2 软件架构设计、SWE.3 软件详细设计和单元构建。

SEC.3   风险处理验证

确保网络安全的实现与网络安全需求、更新架构设计和详细设计的一致。

这个过程域其实就是对SEC.2 网络安全实施的结果进行验证，网络安全实施包含了：架构设计、详细设计和单元构建，那么这里的验证就包含了：架构设计和详细设计的验证、软件单元的验证，则可以对应到的是ASPICE的：

1、SUP.1 质量保证中BP2的要求，对工作产品的质量保证，大概率是采用对设计结果进行评审，并使用评审检查单

2、SWE.4 软件单元验证：静态扫描、单元测试和代码评审

3、SYS.4/SWE.5 系统/软件集成和集成测试

SEC.4   风险处理确认

确认集成后的系统达到了相关网络安全目标要求

渗透测试

是指通过模拟黑客攻击的方式，检测和评估计算机系统、网络和应用程序的安全性。渗透测试的目的是发现潜在的安全漏洞和弱点，以便及时修复和加强系统的安全防护能力。

渗透测试可以包括以下步骤：

1. 信息收集：收集目标系统的相关信息，包括IP地址、域名、网络拓扑等。

2. 漏洞扫描：使用专业的扫描工具对目标系统进行扫描，发现系统中存在的漏洞和弱点。

3. 漏洞利用：利用发现的漏洞和弱点，尝试获取系统的敏感信息或者控制系统。

4. 权限提升：在获取系统访问权限后，尝试提升权限，以获取更高级别的权限。

5. 数据获取：获取系统中的敏感数据，包括用户账号、密码等。

6. 持久化访问：在系统中留下后门或者其他方式，以便后续持续访问系统。

7. 清理痕迹：在完成渗透测试后，清理所有留下的痕迹，以保证测试的安全性。

8. 编写报告：整理渗透测试的结果，编写详细的报告，包括发现的漏洞和建议的修复措施。

渗透测试是一种有效的安全评估方法，可以帮助组织发现和修复系统中的安全问题，提升系统的安全性和防护能力。同时，渗透测试也需要遵循法律和道德规范，确保测试的合法性和合规性。

渗透测试技术是指用于进行渗透测试的各种方法和工具。以下是一些常用的渗透测试技术：

1. 网络扫描：使用端口扫描工具（如Nmap）对目标系统进行扫描，发现开放的网络服务和漏洞。

2. 漏洞利用：使用漏洞利用工具（如Metasploit）对发现的漏洞进行攻击，获取系统访问权限。

3. 社会工程学：通过欺骗、诱导和操纵人员，获取敏感信息或者系统访问权限。

4. 密码破解：使用密码破解工具（如John the Ripper）对系统中的密码进行破解，获取用户账号和密码。

5. Web应用程序渗透测试：对Web应用程序进行安全评估，包括注入攻击、跨站脚本（XSS）攻击、跨站请求伪造（CSRF）攻击等。

6. 无线网络渗透测试：对无线网络进行渗透测试，包括破解WEP/WPA密码、钓鱼攻击等。

7. 物理渗透测试：对物理设备和设施进行渗透测试，包括入侵物理空间、获取物理设备访问权限等。

8. 漏洞扫描和评估：使用漏洞扫描工具（如OpenVAS）对系统进行扫描，发现系统中存在的漏洞和弱点。

9. 代码审计：对应用程序的源代码进行审计，发现潜在的安全漏洞和弱点。

10. 社交工程学：通过与目标用户进行交互，获取敏感信息或者系统访问权限。

渗透测试技术的选择取决于目标系统的类型和特征，以及测试人员的技术水平和经验。同时，渗透测试需要遵循法律和道德规范，确保测试的合法性和合规性

模糊测试（Fuzzing）

是一种自动化的软件测试技术，它通过向目标系统输入大量的随机、异常或非预期的数据（即“模糊”数据），以触发系统中的潜在漏洞和错误。

在模糊测试中，测试人员会使用专门的模糊测试工具，如AFL（American Fuzzy Lop）、Peach Fuzzer等，来生成和发送模糊数据。这些数据可能包括随机的输入、边界值、非法字符、格式化字符串等。目标系统会接收并处理这些数据，测试人员会观察系统的反应，如崩溃、异常退出、错误信息等。

模糊测试的目标是发现系统中的潜在漏洞和错误，如缓冲区溢出、格式化字符串漏洞、输入验证错误等。通过模糊测试，可以揭示系统对异常输入的处理能力，并帮助开发人员修复潜在的安全漏洞和软件缺陷。

模糊测试的优点包括：

1. 自动化：模糊测试可以自动化生成和发送大量的模糊数据，减少了测试人员的工作量。

2. 发现隐藏漏洞：模糊测试可以发现系统中隐藏的漏洞和错误，这些漏洞可能在正常输入下很难被发现。

3. 覆盖广泛：模糊测试可以覆盖系统的各种输入路径和边界条件，包括正常和异常情况。

4. 高效性：模糊测试可以在相对短的时间内发现大量的潜在漏洞和错误。

然而，模糊测试也有一些限制和挑战，如需要大量的计算资源和时间、可能产生大量的无效数据、可能导致系统崩溃等。因此，在进行模糊测试时，需要选择合适的测试工具和策略，并进行适当的测试范围和深度控制，以确保测试的有效性和可行性。

模糊测试（Fuzzing）是一种软件测试技术，它通过向目标系统输入大量的随机、异常或非预期的数据，以探测系统中的潜在漏洞和错误。下面是一些常见的模糊测试技术：

1. 随机模糊测试（Random Fuzzing）：随机模糊测试是最简单的模糊测试技术，它使用随机生成的数据作为输入，向目标系统发送大量的随机数据，以期望触发系统中的潜在漏洞和错误。

2. 字典模糊测试（Dictionary Fuzzing）：字典模糊测试使用事先准备好的字典文件作为输入，字典文件包含了各种可能的输入值和边界条件。测试工具会逐个尝试字典中的每个输入值，以探测系统对不同输入的处理情况。

3. 变异模糊测试（Mutation Fuzzing）：变异模糊测试是一种基于已知有效输入的变异技术。测试工具会对已知有效的输入进行变异操作，如改变数据的一部分、插入随机字符、删除字符等，以生成新的模糊数据。

4. 符号执行模糊测试（Symbolic Execution Fuzzing）：符号执行模糊测试结合了符号执行和模糊测试技术。它会对目标系统进行符号执行，生成系统的约束条件，并根据约束条件生成模糊数据，以探测系统中的漏洞和错误。

5. 状态机模糊测试（Stateful Fuzzing）：状态机模糊测试是一种基于系统状态的模糊测试技术。它会对系统的状态进行建模，并根据系统状态生成模糊数据，以模拟真实的系统行为。

6. 协议模糊测试（Protocol Fuzzing）：协议模糊测试是一种针对网络协议的模糊测试技术。它会生成针对特定协议的模糊数据，并发送给目标系统，以探测协议实现中的漏洞和错误。

以上是一些常见的模糊测试技术，每种技术都有其适用的场景和特点。在进行模糊测试时，需要根据目标系统的类型和特征选择合适的技术，并结合测试工具和策略进行测试。同时，模糊测试需要进行适当的测试范围和深度控制，以确保测试的有效性和可行性。

总结：

Cybersecurity ASPICE vs. ISO21434

Cybersecurity ASPICE vs. ASPICE V3.1：

关于亚远景科技

上海亚远景信息科技有限公司是家位于上海，服务全国的高技术企业，向研发领域提供以下产品与服务：

• 国际认证：ASPICE/ISO26262/ISO21434

• 研发咨询：诊断，培训，流程定义

• 软件工具：研发过程管理平台

• 人才培养：专业训练，资格认证

• 资源整合：供应链业务外包介绍

原文链接：Cybersecurity ASPICE实施策略 -基于ISO/SAE 21434-亚远景科技