汽车网络安全开发全流程

OPTEE

已于 2024-05-10 15:41:20 修改

阅读量964

点赞数 11

分类专栏：汽车网络安全Cybersecurity 文章标签： web安全安全

于 2024-05-09 20:00:00 首次发布

本文链接：https://blog.csdn.net/Chyneya/article/details/138599274

版权

汽车网络安全Cybersecurity 专栏收录该内容

3 篇文章

订阅专栏

本文详细介绍了汽车网络安全开发的全流程，从概念阶段到报废阶段，涵盖了TARA威胁分析、需求开发、零部件测试、集成验证等多个关键环节，并阐述了V模型下的网络安全验证与确认过程，确保汽车网络安全。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

网络安全开发整体流程

需求开发、分解阶段: 实施整车级、功能级、零部件级三级TARA分析, 分别定义Item、Concept, 导出各层级软硬件网络安全需求,并形成安全规范;
零部件开发和制造阶段: 网络安全软/硬件需求开发, 包括自研和供应商开发活动, 自研部分通过内部需求跟踪流程来保障需求开发进度, 供应商部分通过供应商管理来跟踪需求开发状态;
测试验证阶段: 分别为零部件测试、集成测试、整车测试, 每个环节分别验证对应的软/硬件需求开发结果, 形成测试验证报告;
工厂生产、认证、售后运营、报废阶段：由整车主导，智驾域配合相关活动；

概念阶段(Concept Phase)

开发阶段(Development Phase)

供应商管理阶段(Supplier Management Phase)

测试阶段(Test Phase)

生产阶段(Production Phase)

关键活动包括: 产线系统安全、生产过程安全、密钥更新。

本阶段由整车主导, 智驾域配合整车提供需要做灌装的密钥清单、证书等。

运营阶段(Operation Phase)

关键活动包括: 应急响应、安全更新。

本阶段由整车主导, 智驾域配合整车要求进行漏洞跟踪、处置。

报废阶段

关键活动包括: 敏感信息处理、证书撤销。

本阶段由整车主导, 智驾域配合说明智驾域控哪些数据需要进行销毁处理。

网络安全开发流程V模型

针对智驾域进行网络安全开发流程细化.

Item Definition 对象定义

在进行TARA分析前需要完成对象定义（Item Defintion）来得到明确的分析范围。所谓对象，就是在车辆级别实现功能部件或组件。对象定义包括目标对象的边界、功能、初步系统架构等。

TARA 威胁分析与风险评估

Asset Definition 资产定义

本身有价值的物体，或者能产生价值的物体，即可定义为资产。资产可分为实体资产、数据资产（包括ECU固件、通讯数据、用户隐私数据、安全算法等）。识别资产所带有的网络安全属性（Cybersecurity Properties）得到带有网络安全属性的资产，进一步可分析其潜在的损害场景（Damage Scenarios，DS），这是资产定义所需要输出的两大产物。可根据对象定义，借助数据流图（Data Flow Diagram，DFD），从进程、数据流、数据存储、交互方角度考虑得到资产，也可基于预定义分类进行枚举、基于损害场景-威胁场景得到资产。

对于损害场景的描述可包括对象功能与不良后果之间的关系、外部环境、对道路使用或者相关资产造成的危害。

损害场景示例，假设资产为车辆行驶显示数据，网络安全属性为机密性，那么可以得到损害场景为车辆行驶显示数据被盗，造成乘客隐私信息泄露。

Impact Rating 影响等级评估

对于影响等级的评定可从以下四个评判因子：Safety 安全、Financial 财产、Operational 操作、Privacy 隐私（S、F、O、P）来评定DS的危害影响。每个评判因子评级分为四档：Severe 严重的、Major 重大的、Moderate 中等的、Negligible 微不足道的。对于影响等级评估除了标准附录F以外还可参考J3601。

Threat Scenario Definition 威胁场景定义

威胁场景是资产被破坏的原因，同时也是损害场景的原因。对于威胁场景的描述可从以下几个角度来考虑：目标资产、资产的安全属性损失、安全属性损失的原因。

威胁场景示例，假设资产为车辆行驶显示数据，网络安全属性为机密性，那么得到威胁场景为行车显示数据在车内传输过程中，数据被篡改，导致行车显示数据的保密性和私密性被破坏。

Attack Path Analysis 攻击路径分析

对于攻击路径的识别分为两种方法，一种为自顶向下的方法，通过分析实现对应威胁场景的不同方法来推断攻击路径，可借鉴攻击树、攻击图，通过R155进行自检。 另外一种为自底向上的方法，从漏洞（Vulnerability）出发, 如果该攻击路径没有导致威胁场景，则可停止该条路径的分析。

Attack Feasibility Rating 攻击可行性评估

评估攻击可行性在标准附录G中列举了三种方法，基于攻击潜力（重点介绍）、基于CVSS、基于攻击向量。

攻击潜力方法对攻击路径实现的难易程度评估分为四个等级：High、Medium、Low、Very Low，主要从以下五个角度考虑：

经历时长（Elapsed Time)，指基于专家知识来识别漏洞到最后利用漏洞所花费的时间；
专业知识（Specialist Expertise），指攻击者的能力包括技能、经验等；
对象或组件的知识（Knowledge of the Item or Component），指攻击者对于对象和组件所需要的信息；
窗口期（Window of Opportunity），指能够成功攻击的条件因素；
设备（Equipment），指攻击者发现漏洞或执行攻击所需要的工具。

根据以上五个维度的打分，相加得到总分，然后根据攻击可行性等级评定表映射到相应的攻击可行性等级。

Attack Feasibility Rating
Rating	Value
High	0-9
High	10-13
Medium	14-19
Low	20-24
Very low	>=25

Risk Value Determination 风险等级判断

危害场景的影响程度和相关攻击路径的可行性通过风险矩阵运行确定一个风险值。如果一个威胁场景对应多损害场景，可为每个影响等级确定一个风险等级。如果一个威胁场景对应多条攻击路径，则取攻击可行性最大的。

Risk Matrix (from ISO21434, Annex H, Table H.8)
Risk Level	Attack Feasiblity
Impact Level		Very low	Low	Medium	High
	Severe	2	3	4	5
	Major	1	2	3	4
	Moderate	1	2	2	3
	Negligible	1	1	1	1

Risk Treatment 风险处理决策

对于每一个威胁场景及其风险值，在ISO21434标准中建议了以下四种决策：

· 消除风险，通过消除风险源来避免风险，或者决定不开始或继续进行引起风险的活动；

· 缓解风险，通过提供网络安全目标和概念来降低风险；

· 分担风险，购买保险或者与供应商签订风险转移合同；

· 保留风险，通过提供关于风险的网络安全声明来保留风险。

同时在R155中也有对于风险处置的决策可参考。

Cybersecurity Concept 网络安全概念

网络安全概念（Cybersecurity Concept）指的是针对目标系统及运行环境相关的网络安全需求，以及与安全控制措施相关的信息。网络安全概念中的需求是比网络安全目标中的需求更具体、更靠近技术层面的描述。网络安全概念可基于网络安全目标，结合更多更全面的目标对象的信息来获得。网络安全概念步骤的主要活动包括：定义用于满足网络安全目标的技术层面与/或操作层面的网络安全控制措施、描述进一步的网络安全需求以及对分析输出的结果进行完整性、正确性及一致性的验证。

Cybersecurity System Requirement 网络安全系统需求

定义网络安全系统需求。

Cybersecurity SW/HW Requirement 网络安全软硬件需求

基于网络安全系统需求，分析网络安全软件硬件需求，并将需求分解到各个软硬件部件。

Cybersecurity SW/HW Requirement 网络安全软硬件开发

网络安全软硬件需求开发。

Cybersecurity SW/HW Integration and Test 网络安全软硬件集成和测试

网络安全软硬件需求开发交付版本集成和测试。

Cybersecurity System Test 网络安全系统测试

网络安全系统测试，包含功能测试、渗透测试等。

Cybersecurity Verification and Validation 网络安全验证与确认

产品集成及验证（Integration and Verification）的主要目标是提供证据来证明对目标对象的应用及集成操作是符合所定义的网络安全规范的。相关人员可通过各类适合目标对象及环境的验证方法，包括接口测试、需求驱动测试、动态或静态分析，来验证系统的设计开发符合所规定的网络安全要求。另一方面，需要对目标对象执行各类测试，包括功能测试、漏洞扫描、模糊测试及渗透测试，以确保遗留在系统中未被识别出来的缺陷或漏洞处于最低水平。

完成上述阶段后，将进入网络安全确认（Cybersecurity Validation）阶段，该阶段的主要目标是确认网络安全目标被达成，且系统中没有不合理的风险存在。确认活动主要可通过审查的方法完成，包括审查工作输出以确保目标系统达成了网络安全目标、审查所有的已受到管理的风险等。

验证（Verification）与确认（Validation）是产品开发阶段中两个较为重要的活动，在实践工作中，这两个词的含义经常被混淆。ISO/SAE 21434中也对这两个词做了明确的定义。“确认”指通过提供客观的证据，以确认目标对象的网络安全目标是足够的且已经被实现了的。“验证”指通过提供客观的证据，以确认所规定各类要求已被满足。两个词都是指通过提供客观证据以确认某些事项，“确认”活动所需对标的是较为上层的需求，而“验证”活动所对标的是具体的系统设计要求。