SAEJ3061汽车信息安全指南文档

admin 管理员组

文章数量: 887007

基本原理

更多智能汽车信息安全信息，请关注博大汽车信息安全  公众号BodaSecurity。

网络物理车载系统在整个开发生命周期进程中，需要提供一个网络安全进程框架和指导，帮助企业识别和评估网络安全

威胁和设计网络安全。

定义一个完整的生命周期过程框架，能够被定制和应用到每个产品的开发进程中，从产品的概念阶段到生产，经营，服

务，以及售后维修等过程将网络安全纳入到网络物理车辆系统。

提供高水平的指导准则。

提供现有的工具和方法信息。

为进一步发展提供标准基础。

1.范围 ........................................................................................................................................................................ 8

1.1目的 .............................................................................................................................................................. 9

1.2何时申请网络安全过程 .............................................................................................................................. 9

2.参考文献 ................................................................................................................................................................ 9

3.定义和缩略语 ...................................................................................................................................................... 11

3.1 API............................................................................................................................................................. 11

3.2 ASF - 应用安全框架 ............................................................................................................................... 11

3.3 ASIL –汽车安全完整性等级A ................................................................................................................ 11

3.4潜在攻击 .................................................................................................................................................... 11

3.5攻击面 ........................................................................................................................................................ 11

3.6 攻击树树分析（ATA） .......................................................................................................................... 11

3.7黑盒测试 .................................................................................................................................................... 11

3.8 CAN - 控制器区域网络 .......................................................................................................................... 11

3.9 CERT C ..................................................................................................................................................... 11

3.10 CPU - 中央处理单元 ............................................................................................................................. 11

3.11常见漏洞枚举（CVETM） .................................................................................................................... 11

3.12通用安全漏洞评分系统（CVSS）计分制度的漏洞。 ........................................................................ 11

3.13共同弱点枚举（CWETM） ................................................................................................................... 11

3.14共同弱点评分系统（CWSSTM） ......................................................................................................... 11

3.15网络攻击 .................................................................................................................................................. 11

3.16 CYBER-物理系统（CPS） ................................................................................................................... 11

3.17 CYBER-物理车辆系统（CPAS） ........................................................................................................ 12

3.18网络安全 .................................................................................................................................................. 12

3.19网络安全评估 .......................................................................................................................................... 12

3.20网络安全案例 .......................................................................................................................................... 12

3.21网络安全概念 .......................................................................................................................................... 12

3.22网络安全控制 .......................................................................................................................................... 12

3.23网络安全危害 .......................................................................................................................................... 12

3.24网络安全目标 .......................................................................................................................................... 12

3.25网络安全机制 .......................................................................................................................................... 12

3.26潜在的网络安全 ...................................................................................................................................... 12

3.27网络安全项目计划 .................................................................................................................................. 12

 

3.28网络安全审查 .......................................................................................................................................... 12

3.29 DIS........................................................................................................................................................... 12

3.30DOD ......................................................................................................................................................... 12

3.31 DREAD-伤害再现性可利用受影响的用户和发现性 .......................................................................... 12

3.32DVD-数字视频光盘 ................................................................................................................................ 12

3.33 ECU – 电子控制单元 ............................................................................................................................ 12

3.34以太网 ...................................................................................................................................................... 12

3.35 ETSI......................................................................................................................................................... 12

3.36EVITA-电子安全车辆入侵受保护的应用............................................................................................. 13

3.37功能 .......................................................................................................................................................... 13

3.38 故障树分析（故障树） ........................................................................................................................ 13

3.39 FlexRay................................................................................................................................................... 13

3.40模糊测试 .................................................................................................................................................. 13

3.41灰盒测试 .................................................................................................................................................. 13

3.42GPS........................................................................................................................................................... 13

3.43黑客 .......................................................................................................................................................... 13

3.44 HACKER CHATTER ............................................................................................................................. 13

3.45黑客入侵 .................................................................................................................................................. 13

3.46HAZOP..................................................................................................................................................... 13

3.47 HEAVENS .............................................................................................................................................. 13

3.48HMI .......................................................................................................................................................... 13

3.49HSM - 硬件安全模块 ............................................................................................................................. 13

3.50HM............................................................................................................................................................ 13

3.51IEC - 国际电工委员会 ........................................................................................................................... 13

3.52 事件 ........................................................................................................................................................ 13

3.53 ISAC-信息共享和分析中心................................................................................................................... 13

3.54 IOS/TS ..................................................................................................................................................... 13

3.55I/O............................................................................................................................................................. 14

3.56 IT - 信息技术 ......................................................................................................................................... 14

3.57 ITS ........................................................................................................................................................... 14

3.58 JTAG ....................................................................................................................................................... 14

3.59 LIN - 本地互连网络 .............................................................................................................................. 14

3.60 恶意攻击者 ............................................................................................................................................ 14

3.61 MISRA C................................................................................................................................................. 14

3.62 MOST - 媒体导向系统运输.................................................................................................................. 14

3.63 NIST-国家标准与技术研究所 ............................................................................................................... 14

3.64 NVD-美国国家漏洞数据库 ................................................................................................................... 14

3.65 OBD-II -车载诊断连接器 ...................................................................................................................... 14

3.66 OCTAVE -操作性关键威胁，资产和漏洞评估................................................................................... 14

3.67 OEM - 原始设备制造商 ........................................................................................................................ 14

3.68 渗透测试 ................................................................................................................................................ 14

3.69 PII - 个人身份信息 ................................................................................................................................ 14

3.70 QS ............................................................................................................................................................ 14

3.71 RAM ........................................................................................................................................................ 14

3.72 ROM ........................................................................................................................................................ 14

3.73 风险分析方法 ........................................................................................................................................ 14

 

3.74 SAE......................................................................................................................................................... 15

3.75 安全关键系统 ........................................................................................................................................ 15

3.76 SCADA................................................................................................................................................... 15

3.77 SDL-安全开发生命周期 ........................................................................................................................ 15

3.78 SEI ........................................................................................................................................................... 15

3.79 利益相关者 ............................................................................................................................................ 15

3.80 SQL......................................................................................................................................................... 15

3.81 STRIDE ................................................................................................................................................... 15

3.82 SW ........................................................................................................................................................... 15

3.83 SYSTEM ................................................................................................................................................. 15

3.84 系统环境 ................................................................................................................................................ 15

3.85 相位技术综述 ........................................................................................................................................ 15

3.86 技术的网络安全概念 ............................................................................................................................ 15

3.87 技术审查 ................................................................................................................................................ 15

3.88 TARA - 威胁分析和风险评估 .............................................................................................................. 15

3.89 TATRC .................................................................................................................................................... 15

3.90 TIER 1 ..................................................................................................................................................... 15

3.91 威胁 ........................................................................................................................................................ 16

3.92 THROP -威胁和可操作性分析.............................................................................................................. 16

3.93 信任边界 ................................................................................................................................................ 16

3.94 TVRA ...................................................................................................................................................... 16

3.95 越权存取 ................................................................................................................................................ 16

3.96 USB - 通用串行总线 ............................................................................................................................. 16

3.97 VALIDATION ........................................................................................................................................ 16

3.98 VERIFICATION ..................................................................................................................................... 16

3.99易损性分析 .............................................................................................................................................. 16

3.100明确，结构合理（WDWS）工艺 ....................................................................................................... 16

3.101 白盒测试 .............................................................................................................................................. 16

4. 系统安全和网路系统安全之间的关系1 .......................................................................................................... 16

4.1系统安全与系统网络安全工程之间的类比 ............................................................................................ 17

4.2系统安全和系统网络安全的独特方面 .................................................................................................... 17

5.网络物理系统的网络安全指导原则（CPS） ................................................................................................... 19

5.1了解您系统的网络安全潜力 .................................................................................................................... 19

5.2了解关键的网络安全原则 ........................................................................................................................ 19

5.3考虑车主对系统的使用 ............................................................................................................................ 19

5.4 在概念和设计阶段实施网络安全 .......................................................................................................... 19

5.5 在开发和验证中实施网络安全 .............................................................................................................. 20

5.6 在事件响应中实施网络安全 .................................................................................................................. 20

5.7 当车辆所有者更改时网络安全的注意事项 .......................................................................................... 20

6.网络安全过程概述 .............................................................................................................................................. 20

6.1 一个定义良好，结构良好的过程的动机 .............................................................................................. 20

6.2 过程框架 .................................................................................................................................................. 20

6.3里程碑和门评论 ........................................................................................................................................ 27

7.循环的总体管理 .................................................................................................................................................. 29

7.1网络安全文化 ............................................................................................................................................ 29

7.2测量与网络安全过程的一致性 ................................................................................................................ 30

7.3识别和建立通信信道 ................................................................................................................................ 30

7.4制定和实施培训和指导 ............................................................................................................................ 30

7.5营销和维护活动 ........................................................................................................................................ 31

8.过程实施 .............................................................................................................................................................. 31

8.1将集成通信点单独应用于安全过程的网络安全过程 ............................................................................ 31

8.2 基于ISO 26262应用网络安全与安全流程定制的过程。..................................................................... 33

8.3概念阶段 .................................................................................................................................................... 34

8.4产品开发:系统层 ....................................................................................................................................... 36

8.5硬件层的产品开发 .................................................................................................................................... 39

8.6 软件层面的产品开发 .............................................................................................................................. 41

8.7生产，经营和服务 ................................................................................................................................45

8.8支持开发过程（16） ............................................................................................................................48

9. 注意 .................................................................................................................................................................... 50

9.1修订指示器 ............................................................................................................................................50

附录A - 网络安全分析技术的描述 ...................................................................................................................... 51

A.1威胁分析与风险评估和脆弱性分析方法概述 ....................................................................................... 51

A.2网络安全测试方法概述 ........................................................................................................................... 65

附录B - 工作产品的示例模板 .............................................................................................................................. 66

附录C - 使用识别的分析的实例 .......................................................................................................................... 68

C.1使用威胁和可控性分析（THORP）在特征级别的EVITA应用示例 ..............................................68

C.2 攻击树例子 ............................................................................................................................................. 70

C.3 HEAVENS安全模型的示例.................................................................................................................... 72

C.3.1 HEAVENS威胁分析示例..................................................................................................................... 72

C.3.2 HEAVENS方法的风险评估示例......................................................................................................... 73

C.3.3 HEAVENS方法的网络安全要求示例................................................................................................. 73

附录D - 安全和隐私控制描述和应用 .................................................................................................................. 74

附录E - 脆弱性数据库和脆弱性分类计划 .......................................................................................................... 78

附录F - 车辆水平考虑........................................................................................................................................... 81

附录G - 可用于车辆工业的当前网络安全标准和指南 .............................................................................. 83

附录H - 车辆项目意识 .......................................................................................................................................... 86

附录I - 对车辆行业潜在使用的安全测试工具 ................................................................................................... 89

 

 

目录

1.领域

1.1目的

1.2何时申请网络安全过程

2.参考文献

3定义和缩写

4系统安全和系统网络安全时间的关系

4.1系统安全和系统网络安全工程的类比

4.2系统安全和系统网络安全的独特之处

5. CYBER-物理车辆系统（CPS）网络安全指导准则

5.1了解自身系统网络安全的潜能

5.2了解关键网络的安全原则

 

 

5.3考虑车主的应用系统

5.4概念和设计阶段实现网络安全

5.5开发和验证实施网络安全

5.6应急网络安全实施

5.7当车辆用户改变时考虑网络安全

6. 网络安全过程概述

6.1一个完美定义和良好结构过程的动机

6.2过程框架

6.2.1全面的网络安全管理

6.2.2概念阶段

6.2.3产品开发

6.2.3.1产品开发： 系统层

6.2.3.2产品开发： 系统层

6.2.3.3产品开发： 系统层

6.2.4生产、运行和服务

6.2.5支持过程

6.3里程碑和门评论

7. 网络安全的全面管理

7.1网络安全文化

7.2网络安全过程的测量一致性

7.3确定和建立通信通道

7.4指定和实施培训指导

7.5操作和维护任务

7.5.1事件响应过程

7.5.2现场监控过程

8.流程实现

8.1将网络安全过程单独应用于安全过程的综合通信

8.2应用网络安全过程中结合ISO26262后量身打造一项安全流程

8.3概念阶段

8.3.1功能定义

8.3.2网络安全生命周期的开始

8.3.3威胁分析与风险评估

8.3.3.1识别网络安全目标

8.3.4安全概念

8.3.5确定网络安全需求的功能

8.3.6最初的网络安全评估

8.3.7概念阶段评审

8.4产品开发：系统层

8.4.1在系统级（计划）开始产品开发

8.4.2系统层漏洞分析

8.4.3网络安全概念的细化功能技术引用到技术网络安全概念

8.4.4明确提出网络技术安全要求

 

 

8.4.5系统设计

8.4.6功能集成和测试

8.4.7网络安全技术要求的验证

8.4.8最终网络安全评估/网络安全案例

8.4.9最终网络安全审查

8.4.10投入生产

8.5硬件层的产品开发

8.5.1背景

8.5.2硬件层开始开发产品

8.5.3硬件层级漏洞分析

8.5.4硬件层的网络安全需求规范

8.5.5硬件层网络安全设计

8.5.6硬件层集成和测试

8.5.7硬件层的漏洞测试和渗透测试

8.5.8验证/验证硬件网络安全需求

8.5.9完善网络安全评估

8.6软件层的产品开发

8.6.1软件层开始开发产品

8.6.2软件层的网络安全需求规范

8.6.3软件架构设计

8.6.4软件层漏洞分析

8.6.5软件单元设计和完善

8.6.6实现软件代码审查

8.6.7软件单元测试

8.6.8软件集成与测试

8.6.9验证/验证软件网络安全需求

8.6.10软件层的漏洞测试和渗透测试

8.6.11完善网络安全评估

8.7生产、运行和服务

8.7.1生产

8.7.1.1计划

8.7.2运行和服务（保养与维修）

8.7.2.1现场维修

8.7.2.2时间响应

8.7.2.3 一个事件响应过程（15）的执行和维护

8.8支持过程（16）

8.8.1配置管理

8.8.2需求管理

8.8.3变更管理

8.8.4文档管理

8.8.5质量管理

8.8.6分布式发展需求（与供应商）

 

 

9.注释

9.1修正指标

附录A 网络安全分析技术的描述

附录B 工作产品示例模板

附录C 鉴定分析的应用案例

附录D 安全和隐私控制描述与应用

附录E 漏洞数据库和漏洞分类法

附录F 车辆级别审议

附录G 目前的网络安全标准和准则可能对汽车业有用

附录H 汽车项目意识

附录I 汽车行业潜在用途的安全测试工具

图1 安全关键和网络安全关键系统的关系

图2 系统的安全性和系统的网络安全工程元素之间的关系

图3 总体网络安全过程框架

图4 概念阶段任务

图5 系统，硬件和软件级别的产品开发之间的关系

图6 系统级的产品开发V曲线图

图7 产品开发：系统层

图8 V曲线图产品开发在硬件级和系统级的产品开发的关系

图9 产品开发：硬件层

图10 V曲线图为产品开发在软件层面上到产品开发的系统级关系

图11 产品开发：软件层

图12 里程碑和门评论

图13 门评审活动

图14 潜在的通信网络安全和安全活动之间的通信路径的概念阶段活动

图15 系统层的产品开发活动，具有潜在的网络安全和安全活动之间的通信途径

图16 硬件层的产品开发活动，具有潜在的网络安全和安全活动之间的通信途径

图17 软件层的产品开发活动，具有潜在的网络安全和安全活动之间的通信途径

图18 确定网络安全功能要求

图19 示例事件响应组数据源（15）

图20 实例事件响应过程

图21 该OCTAVE方法的阶段（21）

图22 OCTAVE快板路线图

图23 安全模型的工作流程

图24 一般攻击树

图25 攻击树

图26 车载诊断的数据流图（OBD）用例

图27 故障，弱点，漏洞和漏洞之间的关系

表1 事故处理清单案例（15）

表2 EVITA严重程度等级

表3 攻击潜力等级和攻击概率

表4 隐私，财务和运营网络安全威胁的网络安全风险图

 

 

表5 安全相关威胁的可控性分类

表6 安全相关威胁的风险图的部分

表7 列标题为EVITA法在特征层使用THROP

表8 OCTAVE（21）阶段的相关性和工艺步骤NIST SP800-30（16）

表9 STRIDE威胁和安全属性之间的映射

表10 运用TL参数估计威胁级别

表11 估计威胁级别（TL）

表12 影响层面参数-安全

表13 影响层面参数-金融

表14 影响层面参数-运营

表15 影响层面参数-隐私和法律

表16 估计影响层面（IL）

表17 安全级别基于威胁级别和水平的影响

表18 推导网络安全要求的例子

表19 OCTAVE快板表10，信息资产风险工作

表20 OCTAVE快板表10，风险缓释部分

表21 特征级EVITA风险评估的示例电子表格

表22 Octave的快板表10的例子中，信息资产风险表ECU固件

表23 Octave的快板表10例，风险缓解部分–ECU固件

表24 “恶意故意车辆禁用”攻击树结构实例

表25 与OBD用例相关的威胁

表26 根据HEAVENS的OBD用例的风险评级

表27 资产、威胁、安全属性和安全对于OBD的使用情况的水平

表28 汽车行业潜在安全控制家庭和控制示例列表

表29 汽车行业潜在隐私控制家庭和控制示例列表

表30 关于软件安全问题的抽象层次的例子

表31 用于漏洞数据库的字典和术语源的例子

表32 漏洞数据库的例子

表33 漏洞分类法的例子

表34 可能对汽车业有用的网络安全标准和准则

表35 汽车网络安全相关的研究项目（2004年至今）

表36 样品类别的安全测试工具

1.范围

 

本推荐作法为车辆网络安全提供指导，是基于封闭式的创建，并且，目前在行业，政府和会议上发表论文报告现有做法

正在被扩展。最好的做法是为了灵活，务实，适应其进一步应用到汽车行业以及其他网络物理车辆系统（例如，商用和军用

车辆，卡车，巴士）。其他专有网络安全开发流程和标准可能已经建立了支持特定制造商的开发流程，并且在本文档中也许

不能全面代表，但是，本文档中包含的信息可以帮助改进现有的内部流程，方法等。

本推荐作法建立了一套网络安全高级别指导原则，因为它涉及到网际物理车辆系统。 包括：

定义一个完整的生命周期过程框架，它可以针对每个组织的发展进程，从概念阶段到生产，经营，服务，以及报废等流

程中将网络安全应用到网络物理车辆系统。

在设计，核实和确认网络物理车辆系统时给常用的一些现有工具和方法提供信息

 

 

关于车辆系统的网络安全提供基本指导原则。

为车辆网络安全进一步开发任务提供标准制定基础。

附录中提供额外的有用和熟知的信息可以帮助改善网络安全的功能设计。大部分在附录中确定的信息可用，但有些专家

可能不知道的所有可用信息。因此，附录中提供的一些信息概述为有关网络安全建设成网络物理车辆系统进一步提供指导。

总览的目的是鼓励研究，以帮助改善设计，并确定将其方法和工具应用到公司的内部网络安全过程。

附录A-C - 描述一些技术威胁分析和风险评估，模型威胁和漏洞性分析（例如，攻击树）以及何时使用它们。

附录D-I - 提供有用的信息知识给汽车业。

附录D - 提供一个网络安全样品概述和设计阶段所考虑的NIST SP 800-53网络安全衍生的隐私控制。

附录E - 提供一些可用的漏洞数据库和漏洞性分类方案引用的参考文献。

附录F - 描述整车级的构思，包括电力结构一些好的设计做法。

附录G - 列出当前的网络安全标准和汽车产业潜在利益的的指导方针。

附录H - 提供自2004年开始的车辆网络安全相关的研究项目

附录I - 介绍潜力感兴趣的汽车产业存在的一些安全测试工具。

通过指定的定义部分可以了解整个文件中的使用术语。

 

1.1目的

正如系统的安全，网络安全应内置于设计，而不是在开发的末尾添加上。从概念阶段到生产，经营，服务，和报废等适

当的生命周期过程中将构建网络安全融入到设计。这份文件提供了一个完整的生命周期过程框架，可针对特定公司的过程。

本文档中描述的过程框架类似于ISO 26262中描述的流程框架功能安全道路车辆（1）。这两个过程是不同的，但是相关的，

为了保持组织安全过程输出和它们的网络安全过程输出之间的一致和完整性需要集成通信。一个组织可以自由地保持与两个

过程之间的相互作用的适当水平的单独进程，或试图直接集成两个过程。本文档中描述的网络安全程序框架可以根据个人组

织适应任意应用程序（集成或独立）。

1.2何时申请网络安全过程

对于可能被认为是网络安全关键网络物理车辆系统，相关潜在威胁的初始化短评估系统中，例如，运行，隐私（例如，

PII，窃听），金融，声誉和风险的初始估计可以进行，以确定该系统被认为应遵循一个网络安全过程。威胁分析和风险评

估的快速评估版本，以确定一个网络安全过程的适用性可以由一个简短的头脑风暴和讨论会议，审议与功能相关联的潜在威

胁，并考虑威胁的潜在风险是否可以足够高以保证下一个网络安全过程。初步评估的风险评估部分可以根据经验或专家判断，

而不是严格的评估程序。潜在的头脑风暴可能来自黑客颤振和会议的知识、以往的经验和清单。获得的清单可能在确定的风

险加以考虑问题包括的影响程度的估计，金融，安全，隐私，或操作方面，以及是否攻击可能涉及的车队或一个单一的车辆。

对于潜在的安全相关的车辆的功能，则建议潜在的安全有关的威胁的初始短评估来执行，以确定是否有任何潜在的高风

险安全性有关的威胁。如果初步评估表明，高风险的安全相关威胁可能存在，那么网络安全过程应该被应用。如果初始评估

没有标识任何高风险潜在的安全有关的威胁，则网络安全过程可能不需要相对于低风险的安全相关的威胁被应用；它是由一

个机构来决定什么被认为是低风险和低风险安全有关的威胁是否需要解决。为了帮助确保所有潜在安全相关的威胁被考虑，

网络安全专家应与安全专家直接交流。标定决定的基础是以下确定安全相关威胁的潜在风险过程而不是在一个是否对应的潜

在危险ASIL（A，B，C或D）。这是因为安全相关威胁的威胁危险可能比较低，而相应的危险可被判定一个高ASIL；这儿在

ASIL等级与安全相关的威胁有关的潜在风险之间并没有直接的对应关系。

2.参考文献

 

1. ISO 26262第8部分第一版，“支持过程，道路车辆 - 功能安全”，2011年11月15日。

2. Barbara J. Czerny. “系统安全与系统安全工程：异同，并基于ISO 26262流程框架系统安全工程过程”，SAE技术

论文2013-01-1419，SAE世界大会暨展览会，2013。

3. B. Potter.”微软SDL威胁建模工具”。在：网络安全2009.1（2009），页15-18。 ISSN：1353-4858。

 

 

DOI：HTTP：//dx.doi/10.1016/S1353-4858（09）70008-X。

网址：http://www.sciencedirect/science/article/pii/S135348580970008X（CIT在第37页。）。

4. Iván Arce, Kathleen Clark-Fisher, Neil Daswani, Jim DelGrosso, Danny Dhillon, Christoph Kern, Tadayoshi Kohno,

Carl Landwehr, Gary McGraw, Brook Schoenfield, Margo Seltzer, Diomidis Spinellis, Izar Tarandach, and Jacob West.

“避免十大软件安全设计缺陷”，IEEE计算机学会，2014年。

5.全球联盟，全球汽车，“消费者隐私保护原则车辆技术和服务”，2014年11月12日。

6. NIST，SP 800-88，修订1，“指引介质清理”，2014年12月。

7. ISO / IEC 15408“信息技术 - 安全技术 - IT评估标准安全”，（3份）。

8. NIST，第1版，“提高关键基础设施网络安全框架”，2014年2月12日。

9. NIST SP 800-53，修订版4，“联邦信息系统和组织的安全和隐私控制”，2014年4月。

10. FIPS PUB  199.“联邦信息和信息系统安全分类标准”。

11. ISO（国际标准化组织）。 “ISO 12207 - 系统和软件工程 - 软件生命周期过程”，2008

12. ISO（国际标准化组织）。 “ISO / IEC 27001： - 信息技术 - 安全技术 - 信息安全管理体系 - 要求”。国际标

准化组织。 2015年1月27日。

13. ISO（国际标准化组织）。 “ISO / IEC 27002：信息技术 - 安全技术。对于信息安全控制“2008实务守则。

14. ISO（国际标准化组织）。 “ISO / IEC 29119：国际软件测试标准”，2014年9月10日。

15. NIST 800-61修订版2，“计算机安全事件处理指南”，2012年8月。

16. NIST特别出版物800-30修订1，“指南进行风险评估”，2012年9月。

17.克莱斯勒公司，福特汽车公司，通用汽车公司，QS 9000第三版，“质量管理体系要求”，1998年10月。

18. ISO / TS 16949：2009“质量管理体系”2008年12月。

19.Ruddle, Alastair,Ward,David等。EVITA项目可交付成果D2.3：2009年12月30日“基于暗侧的场景汽车板载网络安

全的要求。”版本1.1，2009年12月30日。

20. EVITA交付成果D2.1：“电子安全相关用例的评价与规范”，2009年。

21.Woody,Carol. “应用OCTAVE：学员报告”。软件工程学院，2006年5月。

22. Caralli, Richard, James Stevens, Lisa Young, and William Wilson. “介绍OCTAVE快板：提高信息安全风险评估过程。”

软件工程学院，2007年5月。

23. M. Islam等，交付D2安全模型。 HEAVENS项目，交付D2， 2014年12月第1版。

24. ISO（国际标准化组织）。道路车辆-功能安全ISO 26262：2011。(同页数17，30，40，42，44)。

25. BSI-100-4标准1.0版，2009年，联邦信息安全办公室（BSI），德国。

26.汽车工业行动集团（AIAG），“潜在失效模式及后果分析(FMEA)”，2008年。

27.“隐私影响评估指引”，2011年，联邦信息安全办公室（BSI），德国。

28. ISO（国际标准化组织）。道路车辆 - 功能安全 - 第3部分：概念阶段（ISO 26262-3：2011）。ISO 26262-3：

2011。2011（前引书第18页）。

29. Schneier, Bruce ，“秘密与谎言 - 数字安全网络世界”，Wiley出版社，ISBN 978-0-471-45380-2。

30. Amer Aijaz1, Bernd Bochow2, Florian D¨otzer3, Andreas Festag4, Matthias Gerlach2, Rainer Kroh5 and Tim

Leinm¨uller5 ，“关于车辆间通信系统的攻击 - 一种分析”。

31.HTTP//www7.informatik.uni-erlangen.de/~dulz/fkom/06/Material/11/Security/NOW_TechReport_Attacks_on_Inter

_Vehicle_Communications.p DF。

32. Avizienis A, Laprie J-C, Randell B, Lanwehr C， 基本概念和安全可靠的计算的分类学”，自主和Secure Computing

公司工程学报“。2004年1月至3月。

33. MITRE公司，“共同的弱点细目，社区开发的软件弱点类型词典”2006-2014年，http://cwe.mitre/。

34. MITRE公司，“通用漏洞和暴露弱点”，1999-2014年，https://cve.mitre/cve/index.html。

35.安全焦点“，Bugtraq”，2010年，http://www.securityfocus/archive。

36. NIST，“国家漏洞数据库”，http://nvd.nist.gov/。

37. MITRE公司，“共同的弱点评分系统”，2006-2014年，http://cwe.mitre/cwss/cwss_v1.0.1.html。

38. NIST，“通用安全漏洞评分系统”，http://nvd.nist.gov/cvss.cfm。

3.定义和缩略语

 

3.1 API

应用程序接口

3.2 ASF - 应用安全框架

威胁分类工具，该工具是基于系统分解方法来确定威胁。

3.3 ASIL –汽车安全完整性等级A

在ISO 26262的危险性分类方法。

3.4潜在攻击

一个潜在攻击的可能性可以被成功地去执行。

3.5攻击面

不同点（以下简称“攻击源”），其中未经授权的用户（以下简称“攻击者”），可以尝试从一个环境导入数据或从一

个环境导出数据。

3.6 攻击树树分析（ATA）

一种决定潜在路劲的分析方法是指攻击者便可通过该系统导致顶层的威胁。

3.7黑盒测试

关于系统测试这儿没有熟知的正式测试方法。在测试期间不会提供说明书，硬件信息，软件代码等。

3.8 CAN - 控制器区域网络

CAN是串行通讯网络。下列标准所提供CAN协议和它的一些汽车变种相关的细节：SAE J1939，SAE J2411，ISO 11898，

ISO 15765-2。

3.9 CERT C

对于C，C ++，Java和Peal安全编码标准。由CERT编码计划团队开发的。

3.10 CPU - 中央处理单元

执行计算机的主要功能和控制系统部件的计算机系统（微控制器）单元。

3.11常见漏洞枚举（CVETM）

CVE旨在允许漏洞数据库和其他功能连接在一起，方便安全工具和服务的比较。

3.12通用安全漏洞评分系统（CVSS）计分制度的漏洞。

漏洞评分系统

3.13共同弱点枚举（CWETM）

该CWE是一个由MITRE合作主办的“软件弱点类型的正式名单”。

3.14共同弱点评分系统（CWSSTM）

CWSSTM是一个评分系统，可以帮助关心软件的安全利益相关者 - 评估 – 哪里适用 - 优先报道软件的弱点。

3.15网络攻击

一种源于智能行为的网络安全系统攻击，即，智能行为是蓄意（尤其是在方法或技术的意义上），以逃避网络安全服务

和违反一个系统制度的网络安全政策。

3.16 CYBER-物理系统（CPS）

协作计算元件来控制物理实体的系统。

3.17 CYBER-物理车辆系统（CPAS）

车辆的嵌入式那里存在的计算元件与系统的物理元件和系统周围环境之间的紧密耦合的控制系统。

3.18网络安全

保护网络物理系统免受未经授权的访问或攻击的措施。

3.19网络安全评估

网络安全将在整个开发过程中加以完善，并提供适当的论点和证据，以支持在开发的每个阶段网络安全要求要素的水平

的评估。网络安全评估在每一个重大里程碑中被审查。

3.20网络安全案例

最终的网络安全评估是在所有的里程碑评审已经完成之后，并在生产功能发布之前。

3.21网络安全概念

在概念开发阶段来描述高层次的网络安全策略的功能。网络安全概念将在系统级的产品开发过程中被细化到一个技术网

络安全的概念。

3.22网络安全控制

管理，运行和技术控制规定的功能（例如，保障或对策），以消除潜在的漏洞或减少一个漏洞会被利用的可能性。

3.23网络安全危害

一个系统中的损失可能发生在网络物理系统，由于系统中的漏洞，可能被外部实体直接或间接的利用。

3.24网络安全目标

为实现网络安全从威胁分析和风险评估结果来确定该功能的目标。这是最高级别的网络安全需求，将推动功能和技术要

求，网络安全的发展和完善。

3.25网络安全机制

技术的网络安全控制添加一种功能，以消除潜在的漏洞或减少一个漏洞将被利用的可能性。

3.26潜在的网络安全

某些事情可能发生的风险或可能性的水平。

3.27网络安全项目计划

定义规划和监督网络安全活动的责任。

3.28网络安全审查

审查，可能由一个小团队的技术评审员进行评估，以评估在开发过程中的各个阶段的工作产品的技术方面。

3.29 DIS

国际标准草案

3.30DOD

国防部

3.31 DREAD-伤害再现性可利用受影响的用户和发现性

基于系统分解方法确定威胁的威胁分类工具。

3.32DVD-数字视频光盘

一种具有高存储容量的设备。

3.33 ECU – 电子控制单元

为车辆提供功能的模块。

3.34以太网

串行通信网络。

3.35 ETSI

欧洲电信标准协会

3.36EVITA-电子安全车辆入侵受保护的应用

欧洲共同体从2007年至2013年开始主要以设计，验证和原型网络安全构建模块的车辆车载网络项目。

3.37功能

系统或一组系统中的一个网络的物理车辆系统的网络安全过程被用来实现在车辆级的功能。

3.38 故障树分析（故障树）

一个演绎分析技术，从一个顶级的风险和降低工作来确定潜在的单个和多点可以导致危险发生的故障组合。

3.39 FlexRay

串行通讯网络。

3.40模糊测试

一种可以用来发现潜在的安全漏洞的软件测试技术。

3.41灰盒测试

测试部分信息是已知的正在测试的功能。例如，提供了一些功能规范，但没有提供产品源代码。因此，一些特别的方法

来尝试确定这些漏洞。

3.42GPS

用于导航的全球定位系统。

3.43黑客

非法企图获得访问权限或获得进入一个意图获得东西的系统权限或造成一些利益相关者损失的人。例如，名声，金融，

恐怖袭击。

3.44 HACKER CHATTER

在网上的博客或公约等，那里的黑客会举行他们试图做什么的谈话。

3.45黑客入侵

未经授权的访问

3.46HAZOP

危害和可操作性分析，在功能安全的背景下，是一种结构化和系统的技术，用于识别特征的潜在危害; 该方法使用指导

词和头脑风暴来尝试识别潜在的危险。

3.47 HEAVENS

修复漏洞，以提高软件的防护性和安全性

3.48HMI

人机界面

3.49HSM - 硬件安全模块

保护和管理用于加强认证的数字密钥，并提供密码处理的物理计算设备。

3.50HM

硬件模块

3.51IEC - 国际电工委员会

集团创作行业标准

3.52 事件

系统的攻击也许有或没有成功的。

3.53 ISAC-信息共享和分析中心

用于安全相关信息的中央存储库。 该小组的目的是在所有成员之间共享每个组织关于网络安全攻击和漏洞的信息。

3.54 IOS/TS

国际标准化组织/技术规格

 

3.55I/O

输入/输出

3.56 IT - 信息技术

资源管理活动

3.57 ITS

智能交通系统

3.58 JTAG

用于从ECU提取数据或代码的微处理器上的端口

3.59 LIN - 本地互连网络

串行通信网络

3.60 恶意攻击者

意图识别和利用特征内的漏洞以实现对特征的访问以获得个人或群体利益的一个或多个人; 收益可能是名誉，财务，恶

意的意图等。

3.61 MISRA C

由Motor Industry Software Reliability Association（MISRA）开发的C编程语言的软件开发标准。 它旨在促进嵌入式系

统上下文中的代码安全性，可移植性和可靠性。

3.62 MOST - 媒体导向系统运输

串行通信网络（光纤或电）

3.63 NIST-国家标准与技术研究所

美国商务部将一群人聚在一起，起草各种技术领域的标准

3.64 NVD-美国国家漏洞数据库

包含超过57000个漏洞由NIST进入

3.65 OBD-II -车载诊断连接器

车辆中的接入点能够与模块通信并且获取诊断信息

3.66 OCTAVE -操作性关键威胁，资产和漏洞评估

用于评估现有企业信息系统中的风险的威胁分析和风险评估方法

3.67 OEM - 原始设备制造商

一家大型车辆制造商公司

3.68 渗透测试

一种测试方法，旨在渗透特征，以识别未知的漏洞，并确定没有得到充分保护的漏洞。 渗透测试揭示关键问题，并演

示该功能如何保护。 结合全面的网络安全计划，渗透测试可以帮助降低违约风险。

3.69 PII - 个人身份信息

可以单独使用或与其他信息一起使用的信息，以识别，联系或定位单个人，或在上下文中标识个人。

3.70 QS

质量体系。（例如，QS 9000）

3.71 RAM

随机存取存储器

3.72 ROM

只读存储器

3.73 风险分析方法

根据攻击的可能结果的严重性和潜在攻击可以成功执行的可能性（攻击潜力）分析已识别威胁的潜在风险的过程。

 

 

3.74 SAE

汽车工程师协会

3.75 安全关键系统

如果一个系统没有表现出预期或期望的行为，可能会导致对生命、财产或环境的危害。

3.76 SCADA

监控和数据采集是一种通过通信信道上的编码信号的系统，以提供远程设备的控制。

3.77 SDL-安全开发生命周期

安全开发生命周期（SDL）是一个软件开发过程，帮助开发人员构建更安全的软件和解决安全合规要求的同时降低开发

成本。

3.78 SEI

卡内基梅隆软件工程学院

3.79 利益相关者

可能影响或可能受到组织行为影响的组织，组织或成员。

3.80 SQL

结构化查询语言是一种专用于编程语言，用于管理关系数据库管理系统（RDBMS）中保存的数据。

3.81 STRIDE

微软威胁建模技术。代表身份欺骗、数据篡改、否认、信息泄露、拒绝服务和特权提升。

3.82 SW

速记软件

3.83 SYSTEM

用于执行车辆中的一个或多个功能的硬件和软件的集合

3.84 系统环境

定义系统的硬件和软件之间的接口，系统内的关键数据流、存储和处理。

3.85 相位技术综述

一个技术阶段评审是处于发展阶段的技术活动进行审查，在开发阶段创造了技术文件的结束；比如，一个概念阶段技术

评审会在完成概念发展阶段来帮助确保技术活动和文件在概念阶段产生的正确的，一致的，完整的，等技术阶段复习最好是

由技术审查委员会组成的小团队的技术专家（3-4）。评审的工作产品应在评审委员会会议前至少2-3周向评审委员会成员提

供。

3.86 技术的网络安全概念

高级网络安全战略定义为工程术语

3.87 技术审查

作为网络安全过程一部分开发的工作产品的技术正确性，技术完整性和技术一致性的审查。 可以在每个单独的分析活

动或工作产品完成时或在整个开发生命周期中的设定门检查点执行技术审查。 该审查可以由少数（例如，3-4个）技术专家

的技术审查委员会完成，并且应当提前向审查委员会成员提供正在审查的工作产品或分析活动（例如，两到三个 周）的技

术审查，以允许审查委员会有足够的时间审查工作产品。

3.88 TARA - 威胁分析和风险评估

在概念阶段应用的分析技术，以帮助识别功能的潜在威胁，并评估与已识别威胁相关的风险。 识别潜在威胁并评估与

这些威胁相关的风险，允许组织优先考虑与威胁相关的后续网络安全活动，因此努力和资源可以集中在最高优先级的威胁。

3.89 TATRC

远程医疗和高级技术研究中心

3.90 TIER 1

由车辆制造商直接为给定产品指定供应商。 供应商与汽车制造商签订了直接业务协议。

3.91 威胁

有可能造成伤害的情况或事件，如果在财务，声誉，隐私，安全或操作方面可能受到损害。

3.92 THROP -威胁和可操作性分析

分析技术，适用于指导确定一个特征的初始功能，以识别该特征的潜在威胁。THROP与HAZOP类似，它考虑的是潜在

威胁而不是潜在危害。

3.93 信任边界

程序数据或执行更改其“信任”级别的边界。 执行信任边界的示例将是应用程序获得增加的特权级别（例如root）的

地方。 数据信任边界是数据来自不受信任来源的点。

3.94 TVRA

威胁，脆弱性和风险（TVR）。一个TARA方法。

3.95 越权存取

如果用户尝试访问系统的某个区域，则不应访问该区域。 当尝试访问该区域时，他们将被拒绝访问。

3.96 USB - 通用串行总线

一种存储和传达信息给他人的方法。

3.97 VALIDATION

确保产品，服务或系统满足客户和其他确定的利益相关者的需求。 它通常涉及对外部客户的接受和适用性以及验证对

比。

3.98 VERIFICATION

对产品，服务或系统是否符合法规，要求，规范或强加条件的评估。 它通常是一个内部过程。即验证对比。

3.99易损性分析

脆弱性分析技术试图在软件和可能被攻击者利用开发的硬件来识别和分类潜在网络安全漏洞或孔。

3.100明确，结构合理（WDWS）工艺

建立一个可重复的，结构化的方法来系统地识别和评估威胁，并可能被利用来实现威胁漏洞，以及相应的网络安全控制

在开发过程中，设计系统以防止确定的漏洞。

3.101 白盒测试

测试已知功能的全部信息测试。详细规格和源代码在测试期间是可用的。

4. 系统安全和网路系统安全之间的关系

 

系统安全（超出法规要求）是系统的状态，其不会对生命，财产或环境造成危害。系统网络安全是一种系统状态，不允

许利用漏洞导致的损失，如财务，操作，隐私或安全损失。安全关键系统是可能对生命，财产或系统环境造成损害的系统，

其不按预期或期望的方式运行。网络安全关键系统是一种这样的系统，如果该系统受到系统中可能存在的漏洞的影响，也许

会导致财务，操作，隐私或安全损失。所有安全关键系统都关键是网络安全的，因为直接或间接对安全关键系统的网络攻击

可能导致潜在的安全损失（图1）。不是所有的网络安全关键系统都是安全关键的，因为对网络安全关键系统的网络攻击可

能导致安全损失以外的损失; 即隐私，操作或财务。

这两个领域也有关系，在系统安全工程的元素和系统网络安全工程的元素之间有一些重叠，但是两个工程学科之间的元

素不相同（图2）。不是安全关键的网络安全关键系统的示例是从驾驶员获得个人信息的娱乐系统。如果这个系统被破坏，

它可能导致财务或隐私损失的驱动程序，但是，它很可能不会对驾驶员造成身体伤害；因此，该系统是网络安全关键的，但

不是安全关键的。同时具有网络安全关键和安全关键性的系统的示例是转向辅助系统。同时具有网络安全关键和安全关键性

的系统示例是转向辅助系统。 转向辅助系统是安全关键的，因为如果其表现出故障行为，则其可能导致对车辆乘客的潜在

危害。转向辅助系统也是网络安全关键的，因为如果系统被攻击者危害并且注入恶意的有意的转向操纵，则这也可能导致对

车辆乘客的潜在危害; 在网络安全中，这将被分析为潜在的安全损失。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

图1-安全关键系统和网络安全关键系统之间的关系

 

 

 

 

 

 

 

 

 

 

 

 

 

 

图2-系统安全和系统网络安全工程要素之间的关系

4.1系统安全与系统网络安全工程之间的类比

系统安全和系统网络安全工程的目标彼此类似。如果可能，两个工程活动的目标是在设计中建立安全性，或者在设计中

构建网络安全，而不是试图在现有设计上增加安全性和网络安全性。系统工程方面在系统网络安全和系统安全方面都很重要。

然而，在网络安全中，可能存在仅将问题视为仅仅遵守最佳实践（例如，认证和加密）以及忽略系统工程方面的倾向。 本

节在网络安全之前使用术语“系统”来强调本建议操作中描述的系统方法到网络安全。

系统安全和系统网络安全工程的过程元素也彼此类似。 在系统安全工程过程的概念阶段，执行危害分析和风险评估。

类似于此，在系统网络安全工程过程中，在概念阶段执行威胁分析和风险评估。在系统安全工程过程的需求阶段，从危险分

析和风险评估中确定安全目标导向和完善安全要求。同样，在系统网络安全工程过程的需求阶段，网络安全要求从威胁分析

和风险评估中确定网络安全目标导向和改进。在系统安全工程过程的设计阶段，对最高风险危险进行详细的危害分析，以帮

助识别控制或安全机制，以帮助消除潜在危险，或在潜在危险发生时帮助减轻后果。过程元素之间的类比继续通过产品开发

和验证。 尽管在系统安全性和系统网络安全工程之间的过程元素中有许多相似之处，但是过程元素的基本应用在两个工程

学科之间可能是唯一的。

维护安全与网络安全之间的一致性的建议包括：

在两个进程的产品生命周期中建立适当的检查点。

使用风险分析方法来帮助指导公司解决最高风险的威胁，在现有流程和论坛中建立网络安全意识和界面或通信点。

识别，建立和分发安全和网络安全之间的各种通信路径。

4.2系统安全和系统网络安全的独特方面

系统安全和系统网络安全是彼此独特的。虽然系统的安全重点在分析系统的潜在危害，使安全机制能够识别和集成到设

计中，以解决潜在的危害，并减少与这些潜在危害相关的风险，系统网络安全考虑了攻击者的潜在威胁，攻击者的目标是造

成伤害，肆虐，获得财务或其他利益，或者只是为了获得臭名昭着。

虽然在“危害分析和风险评估”与“威胁分析和风险评估”之间存在类比，对已识别危险的响应与对已识别威胁的响应

不同。由于潜在威胁涉及故意，恶意和计划的行动，它们比潜在危险更难以解决。充分应对潜在威胁，需要分析师像攻击者

一样思考，但是可能很难预测攻击者可能做出的确切移动。然而预测攻击者的移动，有助于分析人士知道什么是网络安全控

制和适当的保护对攻击者的可能行动。在系统的安全性，分析人员可以更容易地识别潜在的危害，确定潜在的原因，并采取

适当的行动，以减轻潜在的后果，或消除潜在的危害都在一起。原因是潜在危险的原因可以基于经验，系统的知识，组件和

相互作用等来确定，并且潜在原因对于特定系统可以是唯一的，但是不是未知的。此外，在安全方面，统计可用于声称可接

受的风险水平。 然而，对于网络安全可能不是这样。 对于网络安全，由于可能是网络安全分析的一部分的大量未知信息，

可能需要以某种方式采用统计或统计分析技术，然而，这些技术可能根本不同于可以使用的经验技术 在安全相关系统的经

验。

危害分析和风险评估以及威胁分析和风险评估之间的另一个区别是，在威胁和与威胁相关的风险方面考虑了其他因素，

不需要考虑危险和与危险相关的风险。在评估潜在威胁的风险时要考虑的这些额外因素包括攻击者所需的知识（专有的或公

开可用的），攻击者的经验水平，攻击者需要访问系统的去权限，攻击者对特殊设备的需求等。但是在评估潜在危害的风险

时，不需要考虑这些因素。

关于系统网络安全和系统安全的另一个独特方面是系统网络安全是一个主要关注重点。在系统安全中，重点是安全关键

系统，而在系统网络安全中，安全关键系统和非安全关键系统都有考虑。系统网络安全考虑了安全关键系统和非安全关键系

统，因为威胁可能是非安全相关的（例如，财务，隐私，操作），威胁也许可以从非安全关键系统访问安全关键车辆系统（例

如，车载娱乐系统）。此外，作为系统安全工程分析的一部分，任何安全状态都需要考虑网络安全，以评估该安全状态是否

可以被攻击者利用。即使利用安全状态似乎是可接受的，并且不会导致安全威胁，但也应该对其进行评估，以确定是否可能

导致拒绝服务的另一个功能。安全状态具有与其相关的一些潜在风险是可能的;这些安全状态可能被攻击者利用，并可能导

致从网络安全角度分析的安全威胁。因此，传统的危害控制是不够的，因为网络安全控制并且如所述的，可以通过导致拒绝

服务或潜在的安全相关威胁造成对系统的危害。

对于详细的危险性分析和脆弱性分析，分析技术可能是类似的，但方法和目标是独一无二的。例如，一个详细的危险分

析技术可以利用故障树分析（FTA）。同样，对于系统的网络安全威胁，详细分析技术可以利用攻击树分析（ATA）。虽然方

法是相似的，但是他们是唯一的。在故障树分析的分析师确定了潜在的原因，顶部的危险事件，并寻找单点和多点可能会导

致顶层的危险随机硬件故障。攻击树分析是不考虑单点和多点随机硬件故障，而是确定潜在的路径，该路径是指攻击者可以

通过系统导致的最高水平的威胁。基本目标是一样的–在故障树分析中目标是确定单点和多点可能导致前风险的随机硬件故

障，所以将安全机制的添加可以检测和减轻潜在的原因，并且攻击树分析的目标是识别潜在可能被用来产生最高水平的威胁

安全漏洞，网络安全控制可以确定消除漏洞或让他们利用更多的困难。

在实施和验证/验证阶段，系统安全中使用的静态代码分析是用来帮助识别直接影响主要功能性的错误。而在系统网络

安全，静态代码分析是用来确定潜在的网络安全漏洞的代码。从安全的角度来看有效或正确的代码可能仍然有网络安全漏洞。

最后，一些验证/验证方法的网络安全是不同的，并且比用于系统安全的验证方法更困难。例如，在系统安全性的故障

注入测试进行验证，确定故障检测和适当的响应发生，但是，在网络安全有没有特定的故障可以注入，或查看系统漏洞是否

被关闭。网络安全依赖于攻击（漏洞）测试、渗透测试与故障注入测试。在渗透测试中，一个伪攻击者（S）试图识别和利

用系统中的漏洞。这显然不是简单的故障注入测试。渗透测试也不打算以确认正确的响应（即，特定的网络安全控制添加到

设计）取得相对于一个潜在的漏洞。另外，传统的结构化测试的网络安全控制（这可以确认，设计满足其要求）的有效性是

不足以解决黑帽的方块类型的攻击。网络安全可能会使用传统的结构化测试和渗透测试，以解决攻击者的方法的不可预测性。

网络安全和安全之间的一个更普遍的区别是，网络安全风险随着时间的推移，攻击者的动机和能力进行变化。这使得网

络安全特别困难，因为它涉及到对技术的防御，系统被创建时可能无法理解。

安全和网络安全也可能在某些情况下相互冲突,例如, 网络安全对策可以与安全要求冲突,反之亦然. 系统工程原则考

虑系统需求的整体集成,包括集成网络安全和安全要求。为了帮助保持安全和网络安全的一致性和完整性，应识别和建立安

全和网络安全之间的各种通信点。在安全和网络安全之间的产品生命周期中，还应添加适当的检查点或门户审查。

 

 

5.网络物理系统的网络安全指导原则（CPS）

 

本节介绍的网络安全指导原则旨在为汽车行业的各种公司工作，由于每个公司可能有自己的内部流程来管理其产品开发，

此推荐实践提供了一套可以由公司内的任何组织应用的，关于网络安全的指导原则。以下指导原则适用于来自微软安全开发

生命周期（SDL）指导原则（3）的网络物理车载系统的网络安全以及IEEE用来避免前10大软件安全设计的缺陷（4）。除

了这些指导原则，可以确定可能适用于网络安全的立法或监管要求。

5.1了解您系统的网络安全潜力

了解潜在的网络安全漏洞对您的系统是非常重要的（例如，可以通过进行适当的脆弱性分析来识别的攻击面）。系统开

发的概念阶段应考虑对这些潜在漏洞使用什么防御。例如：

是否有任何存储在您的系统上或由您的系统传输的敏感数据和/或个人身份信息（PII），这些信息可能使您的系统成为

目标？

你的系统在车辆安全关键功能中有什么作用（如果有）？

你的系统与车辆电气架构外部的实体之间的通信或连接是什么？

你的系统可以用作对另一个系统的攻击的“垫脚石”吗？

你的系统的信息（例如，时序，功耗）可以用来启动边沿信道攻击？进行适当的威胁分析和风险评估。

5.2了解关键的网络安全原则

以下列出了有关网络安全的关于网络物理系统的一些关键原则。

保护个人身份信息（PII）和敏感数据：可以在汽车联盟和全球汽车制造商消费者隐私保护中找到一个可以提供指导的

潜在参考来源原则（5）。存储在车辆上的PII应该受到保护，并且应该控制和限制对存储的PII数据的访问：

为客户的数据使用保守的默认访问设置。

在收集和传输任何数据之前，获得负责机构的适当同意。

通过保护存储在访问控制列表中的客户数据，防止未经授权的访问。

使用“最少特权”的原则 - 所有组件以尽可能少的权限运行。

应用“深度防御”，特别是针对最高风险威胁。这意味着威胁缓解不应仅依赖于单一的网络安全控制，同时在系统中留

下可以被利用的、主要网络安全控制的其他漏洞。

禁止更改未经过彻底分析和测试的校准和/或软件。

防止车主有意或无意地对车辆系统进行未经授权的更改，从而引入潜在的漏洞。车主可能会引入漏洞的一些方法包括：

用来改变校准设置和/或软件以获得不同的动力系性能特征的“调谐器”。

来自诸如DVD，配对蓝牙手机等的设备的软件，这些软件可以通过车辆的娱乐系统自动安装，而不会通知用户或告知用

户可能的风险。安装的软件可能没有恶意，但是，它可能具有可能被利用的漏洞。

5.3考虑车主对系统的使用

考虑车主对你的系统的使用情况。

最小化数据收集。收集特定用途所需的最低数量的个人数据，并使用该数据中最不敏感的方面（例如，用户名不如社会

保险号码敏感）。

启用用户策略和控制。允许所有者管理其车辆系统的隐私设置，并在他们希望更新/撤销时提供授权（如适用）。并且

允许制造商对其隐私设置进行操作。

保护PII的存储，使用和传输.确保数据使用与传达给OEM和车辆所有者的用途一致。

对收集，存储和共享的数据提供适当的通知，以便业主可以对其个人信息做出明智的决定。

为经销商、客户帮助热线、网站和用户手册开发适当的材料。此材料的目标是确定客户对数据隐私的期望，并告知他们

系统的能力和限制，以及促进一般的网络安全实践。

5.4 在概念和设计阶段实施网络安全

从开发生命周期的概念阶段开始设计网络安全的功能。工程师在定义系统和特性所要满足的要求时应考虑网络安全。

 

 

分析威胁（即在系统外部或内部开始），以确定系统将面临的内容。对于确定的威胁，发现的任何漏洞，并确定适当的

网络安全控制方法。

实施网络安全分析（和管理工具），使工程师能够确定和配置系统的最佳网络安全级别。

5.5 在开发和验证中实施网络安全

用状态评估来评估设计工作是否按计划达到网络安全的要求。对于任何不确定会达到网络安全要求的设计工作，请与适

当的利益相关者合作制定计划以解决未解决的问题。

进行测试以确认在网络安全方面已经满足的要求。

确保与对未来/车辆软件进行重新闪烁的机制相关的任何风险都被最小化或消除了。

5.6 在事件响应中实施网络安全

修订（或创建）事件响应流程，包括对网络安全事件的跟踪和响应。这种事件响应流程应强调迅速响应对报告网络安全

漏洞/事件，以及将有关安全更新的信息传达给受影响的人、用户和利益相关者的重要性。这些事件响应需要记录和发布出

来。

确定在发生事件时如何进行软件和/或校准的更新。例如，如果空中（OTA）安全机制可用，则该方法可以用于对校准

和/或软件的修改。

5.7 当车辆所有者更改时网络安全的注意事项

当车主出售车辆时，当车辆在事故中报废、并被送去回收厂时，当经销商的演示车辆需要准备销售给顾客等时，车主会

发生改变。当车辆所有者发生更改时，应该：

为了保护客户和/或保护组织（例如，防盗器，手机配对），需要确定车辆上是否存在任何需要擦除的软件系统或客户

个人信息。

当所有权更改和/或车辆寿命终止时，提供一种方法，可以从车辆系统中删除个人信息。这应在车主/操作员手册或车辆

服务提供商的说明中进行注明。有关清除存储介质的方法的信息，请参阅NIST特别出版物800-88“介质清洁指南”（6）。

6.网络安全过程概述

 

6.1 一个定义良好，结构良好的过程的动机

与系统安全一样，网络安全应该内置到系统中，而不是在开发结束时添加到系统。尝试将网络安全添加到现有的系统，

或使用特定方法来识别和实施网络安全控制可能会导致：

需要有价值的有限资源（成本和工程师）来识别，开发和实施的不必要的网络安全控制。

不正确的网络安全控制。

不完全或不一致的网络安全控制。

无意中插入了其他东西和未知的漏洞。

没有系统可以保证100％安全。然而，遵循良好定义和结构良好的过程提供了一种可以帮助减少成功攻击可能性的方法。

一个定义良好且结构良好的（WDWS）流程建立了一个可重复的，结构化的方法，来系统地识别威胁，识别被用来实现威胁的

漏洞，同时提供适当的网络安全控制，以便在开发期间就设计到系统中去识别这些漏洞。WDWS过程在概念阶段以及后续的生

产，操作和服务的整个生命周期中都提供指导。

减少成功攻击的可能性可以被看作是降低潜在危险的可能性。为了减少潜在危险发生的可能性，车辆工业在安全关键系

统的设计和开发中应用系统安全工程的原则。以类似的方式，来减少对车辆遭遇网络攻击的可能性，车辆工业可以应用系统

网络安全工程的原理来设计和开发网络安全关键的网络 - 物理车辆系统。

6.2 过程框架

图3显示了从概念阶段到生产，运营和服务的整个生命周期的网络物理车辆系统的整体网络安全工程的过程框架。图中

所示的生命周期与ISO 26262功能安全道路车辆标准（1）的过程框架相类似。选择这种类似的生命周期是为了使基于ISO 26262

安全流程的组织在网络安全和安全之间使用一个共同框架，以便于：

通过利用网络安全和安全，共同的组织现有安全过程的方面，来开发定制的网络安全过程，例如，支持过程程序和模板。

 

 

考虑到两个领域之间的相互关系，保持网络安全和安全之间的一致性。

流程框架包括网络安全的管理，核心网络安全工程活动和支持流程。核心网络安全工程活动包括概念阶段活动，系统产

品开发活动，硬件和软件级别以及生产，操作和维护活动。支持过程活动包括适用于不同生命周期阶段的活动，如配置管理，

变更管理等。

6.2.1 网络安全的整体管理

网络安全管理包括两个方面：1.）网络安全的整体管理;2.）在开发生命周期的特定阶段管理网络安全活动。一部分网

络安全的整体管理包括：

创建，培养和维持一种网络安全文化用来在组织内支持和鼓励有效实现网络安全。

建立帮助确保遵守已通过的网络安全工程流程的方法。

在内部和外部确定和建立所需的网络安全通信渠道。

开发和实施培训和指导用来实现网络安全对网络实体车辆系统的影响。

结合扩展的现场监控过程，包括监控黑客聊天（包括在线和在可能发生潜在攻击/漏洞对话的会议上），报告失败的攻

击等。

结合事件响应过程很重要，应包括攻击事件报告程序，攻击事件调查，解决和操作程序。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

图3-整体网络安全过程框架

在概念阶段，网络安全活动的管理可能包括指派一名网络安全经理来监督网络安全活动，并负责规划和监督网络安全活

动，包括制定网络安全计划。

在产品开发期间，网络安全活动的管理可能包括：

开始初步的网络安全评估，在整个开发过程中进行改进，并在比较关键的方面进行审查，直到达到最终的网络安全评估

（网络安全案例）。

识别和监督审查，以保证活动可以正确执行。

任何与网络安全相关的未决问题都将被记录下来，并提出适当的后续行动。如果在以前的网络安全评估中包含开放的网

络安全问题，则应在更新的评估中解决这些问题。网络安全案例就是最终的网络安全问题评估。在网络安全案例中，任何开

放的网络安全问题都将得到解决，或者包括说明为什么公开的问题是可以接受的，并提供支持索赔的最终论点和证据。

6.2.2 概念阶段

图4显示了概念阶段的活动流程。定义功能活动是定义正在开发的功能，包括识别边界和网络安全周边，以及标识外部

依赖项和资产。定义特征阐明了未来分析活动的边界和范围。良好定义的范围有助于约束未来的分析活动，从而可以更有效

和高效地完成分析。

网络安全生命周期的启动包括制定网络安全计划，描述作为网络安全生命周期的一部分进行的活动。威胁分析和风险评

估（TARA）活动用于识别和评估系统的潜在威胁，并确定与每个已识别威胁相关的风险。TARA的结果将推动未来的分析活动，

聚焦未来分析最高风险的网络安全威胁。

网络安全目标是针对高风险潜在威胁确定的。在最高级别，网络安全目标可能与潜在威胁是相反的;例如，如果潜在威

胁是恶意制动，最高级别的网络安全目标可能是防止或减少发生恶意制动的可能性，或减轻恶意制动的潜在后果。一旦为最

高级别的威胁确定了网络安全目标，就可以开发一个网络安全概念来描述该功能的高级网络安全策略。

从网络安全概念和网络安全目标，可以确定和推导出高级别的网络安全要求。这些高级网络安全要求可以在产品开发阶

段进一步细化。在概念阶段结束时，可以执行初步的网络安全评估，以评估这种因特征所提出的网络安全状态。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

图4-概念阶段活动

6.2.3 产品开发

生命周期的产品开发阶段包括系统级产品开发，硬件产品开发和软件产品开发。

图5显示了产品开发阶段的概述，以及在系统级设计阶段的产品开发与在硬件和软件级别的产品开发之间的关系。

注意：迭代发生在生命周期的许多阶段;然而，这些迭代没有为了避免过度复杂的图而被出来。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

图5-系统，硬件和软件级别的产品开发之间的关系

6.2.3.1 产品开发：系统层

图6显示了系统级产品开发的V图。在系统级别的产品开发期间，网络安全概念被改进为技术网络安全概念（即，网络安

全概念中描述的高级网络安全策略被改进为工程术语）。为帮助将网络安全概念改进为技术网络安全的概念，在有大量新信

息可用的情况下，就可以执行系统级威胁分析或漏洞分析。技术网络安全要求是从高级网络安全要求和技术网络安全战略衍

生和完善出来的。

可以创建一个系统环境（硬件/软件接口文档）来定义系统的硬件和软件之间的接口，密钥数据流以及系统内的存储和

处理。使用系统环境，系统级技术网络安全将会对系统硬件和软件都会有一定的要求，或者两者都有。一旦技术性网络安全

要求已分配给硬件和/或软件，产品开发活动：硬件级别（6.2.3.2）和产品开发：软件级别（6.2.3.3）就可以开始（见图6）。

在硬件和软件完成产品开活动后，将对执行硬件和软件进行集成和测试（图6和图7）。脆弱性和渗透测试可以在集成系

统上执行，验证系统是否达到网络安全技术要求的要求。执行最终的网络安全评估，导致最终的网络安全案例。最终的网络

安全审查可以在之前完成并发布生产。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

图6-系统级产品开发的V图

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

图7-产品开发：系统层

6.2.3.2产品开发：硬件层

图8显示了与系统级产品开发相关的HW级别产品开发的V图。图9显示了硬件层面产品开发的活动流程。硬件在系统级开

发期间，将根据分配给硬件的网络安全要求来指定网络安全要求。如果适用，在此阶段就可以改进技术网络安全的概念。以

 

 

下硬件设计，可以通过漏洞分析来识别设计中的潜在漏洞，并帮助识别潜在的网络安全控制以解决潜在的漏洞。在接下来的

硬件集成和测试中，漏洞和渗透测试可以应用于硬件设计中。可以进行网络安全评估，并完善初步网络安全评估。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

图8-V图显示了HW级别的产品开发及其与系统级别产品开发的关系

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

图9 - 产品开发：硬件级

6.2.3.3 产品开发：软件层

图10显示了系统层产品开发与软件层产品开发相关联的V图。图11显示了软件层面产品开发的活动流程。在系统层开发

期间软件网路安全需求将从网络安全分配给软件指定网络安全要求。如果适用，技术网络安全概念可以在此阶段进行细化。

遵循软件架构设计，可执行漏洞分析以帮助识别软件架构设计中的潜在漏洞，并帮助识别潜在的网络安全控制以解决潜在的

漏洞。在软件单元设计和实施之后，可以执行软件层脆弱性分析，随后执行软件单元测试和软件集成和测试。在软件集成之

后验证软件网络安全要求，并且可以对软件执行脆弱性和渗透测试。然后执行网络安全评估，并改进先前的网络安全评估。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

图10 -系统层产品开发与软件层产品开发相关联的V图

图11 - 产品开发：软件层

6.2.4生产，经营与服务

生产阶段的活动包括针对可能影响生产过程的任何网络安全相关要求的生产计划，与制造过程的特定部分安全相关要求。

网络安全相关的生产要求可能包括在现有生产计划中。系统的网络安全要求可能影响软件在制造设备中刷写到ECU上的具体

过程，例如要求刷写工具是安全的。

经营阶段包括操作和服务。 服务包括正常的维护活动和维修。在操作期间对网络安全的特定要求都应该记录在相应的

文档中。（例如，车主操作手册）。关于服务，任何可能对网络安全产生不利影响的维护和修理活动应在早期生命周期阶段

确定，并应指定在维护和维修过程中如何维持网络安全的适当程序；例如，维护程序和修理程序。可能影响网络安全的服务

包括重新刷写ECU，连接到车载诊断端口，远程信息处理系统更新，车辆/云计算接口等。

操作阶段还包括执行和维护在网络安全活动中定义和建立的整体管理现场监控过程，以及履行在网络安全活动中定义和

建立的整体管理事件响应过程。

6.2.5支持过程

一些支持过程活动应与作为符合ISO 26262的系统安全工程过程的一部分应用活动相同。建议将这些流程集成到公司现

有的产品开发流程中。这些包括：配置管理，文档管理，变更管理等。ISO 26262中使用的其他支持流程活动可以针对网络

安全进行定制。 这些包括：网络安全要求的管理，处理分布式开发的要求等。分布式开发要求旨在确保以下内容：

供应商能够根据客户组织的内部网络安全过程开发和生产网络安全关键功能。

在供应商和客户之间建立和维护适当的通信渠道。

同意网络安全工作产品

在关键的里程碑确定适当的审查，能使客户获得工作产品

任何可能影响网络安全的变化都将被评估和同意。

最终的网络安全案件得到审查和同意

供应商可能意识到的任何网络安全问题都会及时报告给客户，等等。

6.3里程碑和门评论

图12显示了可能在每个主要里程碑执行的门评论。 这些包括在完成概念阶段活动时的概念阶段审查，可能分阶段进行

的需求审查（例如，功能需求审查和技术需求审查，包括审查在系统一级分配给硬件和软件的需求） 设计审查，实施审查，

以及验证和验证审。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

图12 -可能的里程碑和门评论

图13显示了可能在每个主要里程碑进行审查的任务。 概念阶段审查中，审查可能包括审查网络安全计划，系统定义，

威胁分析和风险评估结果（包括已识别的威胁，威胁分类和网络安全目标），功能网络安全概念， 网络安全目标纳入功能

网络安全的要求，以及初步网络安全评估。

需求审查可能跨越生命周期阶段，包括审查功能性网络安全要求，从功能性网络安全要求改进或衍生的技术网络安全要

求，以及分配给硬件和软件的技术网络安全要求。它还包括在确定要求时进行的分析活动的审查。设计审查包括影响设计和

系统设计的分析活动和结果。实施审查包括影响实施的分析活动和结果，以及硬件和软件级别的实施。验证和验证审查有助

于确保根据要求进行设计和开发的系统，并且网络安全控制措施是预期工作和合适的； 请注意，在某些情况下，可能无法

或不可能验证和验证所有的网络安全控制。 可以考虑使用共同的标准方法来确保进行全面的测试(7)。

门评论旨在帮助确保在下一个开发阶段开始之前已经正确和一致地执行和完成了适当的活动。这些审查可以由小的（例

如，3-4人）技术专家团队来进行，这些团队应该完美地独立特征开发。为了保持功能开发的一致性和完整性，建议同样的

3-4人团队参与整个系统开发过程中的所有评审。每次审查的结果可以是通过或有条件通过（需要返工）。 在退出门之前应

该成功完成门检查，并进入下一阶段。一个组织机构可以选择两种可能的方式完成技术审查。 一种是使用如上所述的技术

“门”审查概念，其中审查被认为是下一阶段的门户，并且在完成的开发阶段结束时执行，第二种方法是执行每个活动完成

的每个开发阶段期间的那些活动。第一种方法（门检查方法）的一个优点是，审阅者可以遵循对于一个评论的定义，描述，

分析等的进展，当同时完成审查的活动时，能够更容易地识别跨越的所有不完整，不一致或不正确的方面。第二个潜在优势

是，技术专家只需要一次会议，而不是多次审查会议。这种方法的潜在缺点是问题可能不会立即被捕获并且可能传播到下一

个活动，在给定时间内需要更大量的时间来审查多个文档，并且单个会议将需要更多的时间，因为正在审查更多的活动 一

次。可以通过向审查者提供审查结果的时间段，在审查之前（例如，至少两周前）提供活动的结果也许能帮助减轻第一潜在

不利。

第二种方法的潜在优点是，在每个活动完成时审查结果，包括可以在传播之前更快地捕获问题并进行修复，通过审查单

个记录的结果而不是审查所需的更少的时间来准备审查 多个结果，单个文件的审查会议也将缩短。这种方法的主要缺点是，

 

当结果被单独审查而不是集体审查时，结果之间的连续性可能会丢失。因此，为了彻底，审查者将需要重新审查以前的结果，

以检查整个结果的完整性，一致性和正确性。这消除了较少准备时间的优点。由一个组织来决定关于评论的最佳方法。它可

能是有益的，因为一个组织正在加速与网络安全和网络安全过程，开始使用第二种方法和过渡到第一种方法能够在网络安全

中获得的经验。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

图13 - 门审查活动

7.循环的总体管理

 

如第4章“网络安全过程概述”所述，网络安全整体管理的一部分包括：

创建，培养和维持一种支持和鼓励在组织内有效实现网络安全的网络安全文化。

建立方法以帮助确保遵守已通过的网络安全工程过程。

在内部和外部确定和建立与网络安全相关的所需通信渠道。

开发和实施培训和指导，以实现网络安全对网络物理车辆系统的能力。

结合现场监控过程，包括监控黑客聊天（包括在线和在可能发生潜在攻击/漏洞对话的会议上），媒体文章，报告失败

的攻击等。

结合事件响应过程，包括攻击事件报告程序，攻击事件调查，解决和操作程序。

本章将更详细地描述这些概念。

7.1网络安全文化

组织内的网络安全文化是一种组织文化：

 

 

 

高度重视网络安全。

提出了保持领先于潜在威胁的组织目标。

将处理最高风险威胁作为优先事项。

通过以下方式在组织内创造，促进和维持网络安全文化：

建立专门的组织结构：

开发和遵循全球网络安全流程，实践，工具和方法。

培训员工以正确的方式设计和思考网络安全。

如果攻击成功，通知管理层对组织的攻击动机和潜在的不利影响。

针对网络安全漏洞解决方法和产品介绍（例如，定义的威胁，理由，基准[如果适用]，公司影响，利弊，实施影响[组/

产品受影响]和时间）制定商业论证。

在产品开发组织中的网络安全主题冠军。

7.2测量与网络安全过程的一致性

在整个产品开发生命周期中应遵循网络安全过程。 通过这一过程，被确定为具有较高风险的威胁可能需要额外的或更

严格的分析。 该处理如下所述。

目标是一个整体过程，组织监测“日常事件”，并警告和通知那些需要知道，确定最大风险的威胁，分析数据，计划升

级，维护系统，确保符合标准和法规，响应 到网络安全问题，并且始终在监控新技术。

基于风险水平，流程实施将有更多或更少的严格性。 一些活动可能包括：

确保符合公司内部网络安全流程和要求。

在每个发展里程碑进行技术审查。

执行审核以确保过程遵循。

提交性能和验证/验证计划。

7.3识别和建立通信信道

应明确组织结构，使用适当的通信渠道。组织应该知道如何通信：

向相关团体和组织发布新的媒体文章和活动。

个人（内部和外部）报告事件的过程。

公司根据其供应商和/或车辆制造商报告事故的过程。

处理和响应政府，媒体，公众和内部查询的流程（和专门小组）。

公司内部的内部组织结构，让员工知道什么人去对任何类型的网络安全问题或问题。

7.4制定和实施培训和指导

授权组织中的员工识别共同的威胁可以有益于组织的网络安全健康。 网络安全意识和培训教导员工了解业务运营和产

品的脆弱性和威胁。

员工应该意识到所有产品和流程都有漏洞。

应该进行调整的威胁分析和风险评估，以指导资源用于何处。这种调整的威胁分析和风险评估应在新功能/产品的开发

早期发生，因为在产品生命周期的后期修复任何问题更昂贵。

指导应该由经验丰富的网络安全工程师进行。

分享网络安全最佳实践和组织洞察，了解真正有用的内容。

鼓励在无威胁的环境中公开交流思想和问题。

持续强调数据和产品网络安全的关键性质，员工有责任意识到并将其建设到他们的设计中。

将网络安全意识酌情纳入现有流程和论坛。

提供关于网络安全过程的持续培训以及如何实施。

提供持续的技术网络安全培训课程，以提高个人工程能力。

告知员工网络安全设计和评估工具，并使他们了解行业标准和最佳实践。

从以前的产品中重复学习漏洞，进入新的和未来的产品。

7.5营销和维护活动

7.5.1事件响应过程

被计划组织的方法处理影响车辆，车队或车辆制造商/供应商基础设施的任何网络安全事件。一个团队应该初步审查报

告的事件，以确定潜在的影响和准确性。 如果报告的事件被认为是准确的，并且具有高级别的重要性，则团队应调查此问

题以确定更多细节，将正确的团队集中在一起以确定总体影响，并最终确定必要的更改（如果有），以减轻/ 消除问题。 应

监测事件响应的及时性和适当关闭。 应该生成事件的详细记录，捕获/收集取证数据和采取的预防措施。

7.5.2现场监测过程

一个计划和方法应该用于报告网络安全事件的潜在通信路径。一旦向公众提供系统，车辆，车队和/或车辆制造商/供应

商基础设施，就需要现场监测。通知可能来自客户，执法机构，保险公司，媒体，供应商等。如果事件发生，应该有清楚和

容易的指示，如何去向汽车制造商报告事件。 而且应该有一个小组来检索这些通知。

目标是一个整体过程，组织监测“日常事件”，以及那些需要知道的警告和通知，确定最大风险的威胁，分析数据，计

划升级，维护系统，确保符合标准和法规，响应 网络安全问题，并且始终用新技术在监控。

注：2015年，启动了汽车信息共享和分析中心（ISAC）。 范围涉及轻型道路客车车辆电子和相关网络。 这可以是与汽

车行业相关的网络安全事件的快速信息的另一个有价值的来源。

8.过程实施

 

本文档中描述的网络安全过程可以与具有两个过程之间的集成通信点的系统安全工程过程分开应用，或者可以更紧密地

集成网络安全和系统安全过程。由组织决定如何最好地实施和应用这两个过程。这两种类型实现的一些优点和缺点在本节中

描述。甚至可以采取第三种混合方法，其中有一些共享的过程和安全的步骤以及一些网络安全特有的安全。不管组织选择哪

种实施方式，如果网络安全过程是从组织现有的安全过程定制的，并且过程彼此类似（共享一个共同框架），则可以通过已

经在网络安全过程 所实施的行动开发网络安全过程。例如，针对安全过程开发的支持过程可以容易地定制并适应于网络安

全过程。同样，针对安全过程开发的模板可以针对网络安全过程进行定制; 例如，来自安全过程的安全计划可以容易地针对

网络安全过程的网络安全计划定制。此外，为安全而开发的现场监测和事件响应过程将根据需要进行修订，以便为网络安全

工作。来自安全过程的许多其他可能的活动和模板可以被定制和适应到网络安全过程中，以便于在具有现有安全过程的组织

内创建，实现和应用网络安全过程。

8.1将集成通信点单独应用于安全过程的网络安全过程

网络安全过程可以与组织的安全过程分开开发，实施和维护。这种方法的一些优点是，尽管两个领域（网络安全和安全）

从流程的角度来看具有类似的活动，但活动是不同的，并且可能影响不同的领域（例如，网络安全通常影响信息娱乐，这通

常是不受安全影响的领域），并需要不同类型的专业知识。考虑到根据结构良好且定义明确的过程在每个域中开发系统可能

是资源密集的，可能有利的是，使两个活动与根据它们各自的过程工作的单独的技术专家分开。这种方法的一个缺点可能是

增加资源需求，因为每个域需要单独的资源。然而，由于所有安全关键系统都是网络安全关键的，并且网络安全漏洞可能导

致违反安全目标，因此有必要保持网络安全和安全之间的一致性和完整性。

图14至图17显示了产品开发生命周期的每个阶段的结构和良好的网络安全过程活动，以及网络安全活动与类似安全过程

中的安全活动之间可能的通信联系。另一个重要方面是，除了如图所示的团队之间的通信之外，重要的是，两个团队与设计

过程的同步发生。例如，在这两种情况下，所有要求应该在设计验证开始之前解决，以便可以进行基于需求的测试。

功能定义

 

 

信息安全生命周期开始

（规划）

 

 

危险分析和风险评估

 

 

信息安全的概念

 

 

识别带功能的信息安全需求

 

 

开始信息安全评估

 

 

概念阶段评审

信息安全与安全过程的路径

 

 

 

高风险潜在的威胁

 

 

确定信息安全目的

安全过程

 

 

 

 

危险分析及风险评估

 

 

功能安全的概念

 

 

功能安全需求

 

 

 

 

 

概念阶段评审

 

 

图14概念设计阶段信息安全与安全活动的潜在联系

开始产品系统级的开发

（规划）

信息安全与安全过程的路径

系统级的漏洞分析

 

针对技术信息安全概念重新

定义带功能的信息安全概念

 

指定信息安全需求

 

 

系统设计

 

 

产品硬件层开发产品软件层开发

 

 

特征集成&测试

 

漏洞&渗透测试

 

确认信息安全目标

 

最后信息安全评估/

信息安全案例

 

最后信息安全评审

 

发布产品

安全过程

 

 

 

技术安全概念

 

技术安全需求

 

 

 

 

 

 

 

概念阶段评审

 

 

 

 

 

最后安全评估/

安全案例

 

最后安全评审

 

发布产品

 

图15在系统级产品开发活动与潜在的之间的通信路径网络安全及安全活动

 

 

开始产品系统硬件层开发

（规划）

信息安全与安全过程的路径

安全过程

 

硬件漏洞分析

 

 

指定信息安全需求

 

 

硬件信息安全设计

 

指定硬件安全需求

 

 

硬件设计

 

硬件集成与测试硬件集成与测试

 

硬件漏洞&渗透性测试

 

 

确定硬件层信息安全需求

 

 

重新信息安全评估

重新安全评估

 

图16.在硬件级别产品开发活动与潜在的之间的通信路径网络安全及安全活动

开始产品系统软件层开发

（规划）

信息安全与安全过程的路径

安全过程

 

指定软件层信息安全需求

 

 

软件架构设计

 

 

软件漏洞分析

 

 

软件单元设计及实现

 

 

软件实现漏洞分析

 

 

软件单元测试

 

 

软件集成及测试

 

 

确定软件信息安全需求

 

 

软件漏洞&渗透性测试

 

 

重新信息安全评估

指定软件层安全需求

 

 

软件架构设计

 

 

 

 

 

软件单元设计及实现

 

 

 

 

 

软件单元测试

 

 

软件集成及测试

 

 

 

 

 

 

 

 

重新安全评估

 

图17.在软件级别产品开发活动潜在的之间的通信路径网络安全及安全活动

8.2 基于ISO 26262应用网络安全与安全流程定制的过程。

这种类型的应用程序是一个紧密集成的网络安全和安全的过程。因为网络安全的过程描述在此推荐的做法是基于ISO

26262的过程框架,紧密地集成这两个过程仅仅意味着包括网络安全活动为每个产品生命周期阶段,本文档中描述的对应每个

 

 

 

产品生命周期阶段的活动中所描述的安全过程。这些活动的集成可能是通过保持独立的网络安全和安全活动,但与执行这些

活动彼此相同的团队,或并行的活动可能是通过开发一个集成技术覆盖同时安全及网络安全。一个例子是开发一种技术来执

行风险分析和风险评估和威胁分析和风险评估同时使用一个集成的模板和方法。一个紧密集成的过程对网络安全和安全一套

公共资源的优势,因此, 需要额外的资源更少。然而,由于活动需要不同的技术专长和活动是资源密集型的,它可能不是可行

的,期待一个专家小组能同时执行网络安全和安全任务。

8.3概念阶段

图4显示了概念阶段的活动。每个活动所示框图将会在这部分描述。

8.3.1功能定义

功能定义定义了网络安全的系统开发过程将被应用。这个功能定义将会标识出物理边界、网络安全边界和信任边界的特

征,包括网络边界的功能。这个特性非常重要,因为它定义了定义的范围的功能。分析活动进行描述的功能仅限于定义中定义

的范围和周边功能。

8.3.2信息安全生命周期开始

这是信息安全周期功能的开始，包括开发网络安全计划（也就是说, 活动将进行网络安全生命周期的一部分功能,谁负

责的活动, 开始日期、结束日期、状态等。）信息安全计划可能是一个简单的电子表格,或者它可能是一个计划项目等。这

一阶段的重要组成部分是在信息安全的环境下来进行功能设计及开发。

如果有修改功能,以前发达根据组织的信息安全的过程, 一个可以执行影响分析,以确定哪些方面的功能受到影响,是否

修改会影响网络安全。在修改功能的情况下,只有修改可能产生不利影响信息安全会执行定制的过程。修改功能开发之前没

有一个信息安全的过程, 应该遵循组织的信息安全的过程。

8.3.3威胁分析和风险评估

威胁分析和风险评估(TARA)识别威胁和评估风险和识别的威胁的剩余风险。威胁分析和风险评估的结果将驱动整个信息

安全活动过程。识别和评估的潜在威胁所确定的威胁风险,允许将宝贵的资源应用于风险最高的潜在威胁。此外,自重点是最

高风险的潜在威胁,威胁分析和风险评估促进最具价值的网络安全的识别控制在应用程序的更详细的分析技术。

威胁分析和风险评估由三个组件或步骤:

1.威胁分析(威胁识别)的识别系统或组织的潜在威胁 (利益相关者)。

2、风险评估(威胁分类)进行评估,因此,风险的分类, 一个特定的威胁。

3、风险分析——威胁排名根据风险水平和决定是否或不相关的风险与一个特定的威胁是在一个可接受的水平,或者降低

风险措施必需的。

危险分析、风险评估的组件考虑一个潜在的攻击系统造成严重性的结果的可能性和一个潜在的攻击的可能性。一个潜在

的攻击的可能性被成功地执行通常被称为“攻击潜力”。攻击的潜在可以定义不同根据威胁分析和风险评估方法。通常,攻

击可能会考虑很多不同的因素,包括运行时间(时间确定一个漏洞,开发一个攻击,和山攻击成功), 专家的专业知识、知识的

系统调查,网络安全对策控制窗口的水平的机会(访问系统),和设备要求。

如果风险分析识别威胁有一个不可接受的风险水平,然后定义一个信息安全的过程推荐的做法可能是识别风险减少措施

可能应用于减少风险的威胁一个可接受的水平。这些网络安全控制风险降低措施。来确定风险降低完成一个可接受的水平,

重新评估风险的威胁可能是考虑到信息安全完成控制应用于风险降低到可以接受的水平。

可能有不同的标准来确定可接受的风险等级，如根据危险分析、风险评估方法或使用在一个特定的组织的鉴定。可接受

的风险等级分类可能基于特定威胁的风险分类。例如,如果风险评估和分类根据I-IV的规模，IV是最高风险和I是最低的风险,

一个组织可能决定确认威胁与风险分类 I和II是可以接受的,而威胁的风险分类III和IV是不能接受的,需要适当的网络安全

控制来确定风险降低到可接受水平的I和II。这是离开一个组织确定哪些危险分析、风险评估方法是适合他们的目的,并确定

一个基于危险分析及风险评估方法的可接受的风险水平。

威胁分析和风险评估的目的是确定潜在威胁的特性,评估相关的风险每个确定潜在的威胁,威胁进行分类和确定风险是

否在可接受的水平或风险削减措施是必需的。风险分类允许威胁被优先考虑，组织可以根据最高风险的威胁来分配自己的资

源。附录A提供了各种威胁分析和风险评估的概述方法来帮助一个组织决定哪种方法最适合应用在他们的组织。

 

 

8.3.3.1确定网络安全目标

网络安全的目标是最高水平的网络安全需求,包括实现网络安全的目标的特性。网络安全的目标是基于威胁分析和风险

评估的结果决定的。一旦风险最高的潜在威胁识别、网络安全的目标是确定每个风险最高的潜在威胁。网络安全的目标可能

是去阐述什么是要去避免的,或什么是无关至要的危险。例如,如果一个潜在的威胁是恶意的意想不到的转向,这种潜在的威

胁可能的网络安全目标表示为避免或防止恶意意想不到的转向。单个潜在的威胁可能有多个网络安全的目标,以及多个潜在

威胁可能有相同的网络安全的目标。网络安全目标及其相关的风险是用来确定实现网络安全系统的高层战略。

8.3.4网络安全概念

网络安全的概念是一个高层次的描述获得网络安全策略的特性。在这个阶段，网络安全的概念可能包含根据危险分析及

风险评估所确定的高级网络安全目标，每个网络安全的目标相关的风险,和一个潜在满足网络安全的目标的高层策略。这一

策略为解决网络安全的目标可能是依赖于与网络安全的目标相关潜在威胁的风险。一个组织可以创建一个模板的高层策略不

同的分类确定的潜在威胁。基于风险水平创建模板将简化和简化创造威胁网络安全的概念。下一阶段的开发,产品开发系统

级, 网络安全的概念将被更新和细化技术水平。也就是说,将高级网络安全策略精制的功能级别战略技术策略。

8.3.5识别功能的网络安全需求

一旦高层战略确定为满足识别威胁网络安全的目标,功能网络安全需求可以确定。从本质上讲, 在危险分析及风险评估

的网络安全目标识别是最高级别的网络安全需求。这些功能的网络安全需求源自于网络安全战略和网络安全中目标精炼出来

的。图18提供了一个网络安全的目标到功能的网络安全的需求流程图。

 

危险分析及风险评估

 

 

 

信息安全目标

 

 

 

信息安全概念

 

 

 

决定功能的信息安全需求

取决于危险分析及风险评

估对最高风险分析结果

 

 

满足信息安全目标的

高层战略

 

 

功能的网络安全需求源自于网络

安全战略和网络安全中目标精炼

 

图18 -确定功能网络安全需求

8.3.6开始网络安全评估

网络安全评估描述当前的在整个网络生命周期网络安全功能和开发水平阶段。最后网络安全评估将生产完成,操作, 和

服务阶段的生命周期, 并将成为网络安全的情况下,提供该功能的理由设计和开发是“安全”所需的水平；即在危险分析及

风险评估过程的网络安全目标识别的概念阶段感到满意。

在这个阶段,临时网络安全评估可能只包含危险分析及风险评估过程烦人高级网络安全目标识别, 与每一个网络安全目

标的相关风险, 和任何可能的开放的网络安全问题在这个早期阶段确定。开放的网络安全问题在这一点上可能只是一种威胁

已被确认和一个或多个高级网络安全目标已确定以解决的威胁,而一个策略来解决威胁,来满足网络安全威胁的目标可能还

不确定,需要进一步分析。任何开放的网络安全问题应该在随后的更新和改进的初始网络安全评估得到解决。

8.3.7概念阶段评审

概念阶段门审查可能在完成执行概念阶段的活动或审查每个活动完成后执行（6.3描述了这两种方法的优缺点）。特定

的方法取决于各自组织。在制定概念阶段审查的活动包括:

信息安全计划

功能定义

危险分析及风险评估

 

 

 

信息安全的概念

功能网络安全需求

最初的网络安全评估。

审查技术和应该包括:

验证功能的正确性的定义范围,边界,和周边,

验证的完整性、一致性和危险分析及风险评估的正确性, 和危险分析及风险评与功能定义,

验证的完整性、一致性和正确性的网络安全概念,都在网络安全的概念和功能定义和危险分析及风险评估

验证的完整性、一致性和正确性的功能网络安全需求, 在功能性网络安全需求和功能定义和网络安全的概念,

验证的完整性、一致性和正确性的网络安全评估,都在网络安全评估和危险分析及风险评估,网络安全概念和功能的网络

安全要求。,

之前在系统级别进行产品开发,成功完成概念阶段审查应该发生。如果在审查期间发现任何问题,他们应在下一个阶段发

展之前纠正。

8.4产品开发:系统层

在网络安全领域,系统级设计是最专注于软件和电子硬件系统的集成。这是因为网络安全涉及整个系统的运动信号, 存

储的数据,发送消息的软件等。因此,系统的包装部分,内部尺寸的模块,和其他物理特征均是最小对网络安全的系统（注意:

异常点可能是在一个物理漏洞上，可以被利用进入系统通信）。

图6显示了活动发生在系统级产品开发。每个活动所示框的图将在这一节中描述。

注意：每个人都应该认识到,并不是所有的系统都是从头开发,也并不是每个系统集成现有的组件都需要考虑其可能存在

的漏洞。如果你的系统开发存在硬件和软件，可能需要采取额外的步骤来帮助确保任何现有的漏洞是解决。在后面的版本上

将就这一主题提供更多的指导。

8.4.1起始的产品开发系统级(规划)

启动任务在系统级别的目的是开发一个计划,基于网络安全的概念了从概念阶段,如何解决网络安全活动在系统层面,以

及如何确保集成电子硬件和软件。最后,系统级的主要成员网络安全团队将确定为这个起始任务的结果。

8.4.2 系统级的漏洞分析

网络安全团队将首先进行系统级的漏洞分析，在进行潜在的危险分析。这个团队可以使用的网络安全概念阶段(见8.3.4)

和概念网络安全评估(见求值)作为漏洞评估的两个输入。漏洞评估是旨在找到地区可能出现的攻击,不必利用漏洞。该漏洞

评估首先编目系统所有的资源和资产,并为每个根据其分配一个优先级价值和重要性。接下来,评估识别漏洞和潜在的威胁,

和减轻的步骤最严重的威胁或消除最有价值的资产。附录A,描述了几种不同的方法可用于进行脆弱性分析和记录。您的组织

需要确定这种方法的使用。关键是要理解系统的漏洞在哪里,以及潜在的影响可能这些漏洞的系统的功能。

基础设施的漏洞可能会影响其他系统的车辆, 车辆家庭系统的共同之处或非车辆应用程序（如：智能交通系统,后端服

务和维护）。这些漏洞应该传达给其他系统,以便任何交互需要解决,以确保信息安全可以正确的识别和管理。

8.4.3细化功能网络安全概念到技术网络安全概念

在概念阶段,网络安全概念将会被定义。在这个任务中,分析了网络安全的概念, 系统级的漏洞分析，以及确定系统安全

功能，这些功能将会面临潜在的信息安全相关的高风险事件。这一分析,确定网络安全的功能/数据优先权, 将使用创建一个

技术网络安全的概念,定义了特定的技术决策,将在系统水平相对于网络安全设计来保护这些高优先级功能/数据。例子包括:

特定功能的隔离，例如，是否应该在一个单独的电路运用特定函数运算功能？

使用对策（如：加密、解密）。

不存储当前GPS定位系统的一个副本。

深度防护策略,等等。

8.4.4指定技术网络安全要求

一旦技术网络安全概念被定义,便可以制定特定系统的需求。为了要完成这个任务,应该有一个特定功能（如。,激活安

全气囊、制动、转向等）将会被系统执行。此外,创建一个系统上下文定义在接口和功能系统。这些包括:

 

 

硬件和软件接口,

数据流,

数据存储，

数据处理，

支持网络安全功能的函数

使用此系统的功能列表,和系统上下文,具体技术要求应满足实现这些功能,支持上下文定义。

8.4.5系统设计

进行系统级的设计工作将使用指定组织的流程,工具和程序。目的是设计一个系统,满足其需求,包括网络安全。功能设

计的工作在系统中需要被跟踪,以确保功能设计水平 (硬件和软件)将满足他们的需求，以及确保所有的功能将会被集成到系

统中。

8.4.6功能集成和测试

系统的能力来执行用于网络安全将评估结果的基础上的功能水平测试（包括硬件测试以及软件测试），测试这些功能有

没有集成到系统中。集成测试应确认功能,适当的功能识别, 以及功能对策。基于结果集成和测试的功能，根据需要更新网

络安全评估。

整车级：系统的集成以及对应的测试在整车集成上式一个关键的环节。这个层面上集成测试依赖于独立系统已经成功完

成验证和确认工作以确认他们满足系统级需求(包括网络安全需求)。集成测试的目的是为了验证独立系统之间是否可以集成

一起正常工作，同时满足车辆自身信息安全需求。

8.4.7验证/确认的网络安全技术要求

网络安全技术要求在整个开发使用传统方法的组合的方法来验证/确认,并通过使用专门为网络安全测试方法。漏洞测试,

渗透测试,模糊测试是评估系统的网络安全性能至关重要的工具。漏洞测试计划可以基于系统级8.4.2中描述的脆弱性分析来

进行开发。漏洞测试的目的是确认已经给出的需求是否实现，当集成回系统时，漏洞分析将为确认的系统漏洞提供有效的措

施之一。

漏洞分析应该包括：

1.漏洞扫描方法检测可以利用的漏洞。

2.探索性测试方法用于检测和调查漏洞,可以出现在一个实现中和。

3.积极测试试图打破,绕过或篡改网络安全控制,以证明滥用系统或功能的能力。

从一个潜在对手的角度来看，漏洞测试车辆,使用网络安全分析和攻击方法,利用访问和漏洞识别车辆。渗透测试(简称

笔测试)包括一个模拟攻击系统。这些积极的(外部)的攻击个人(或个人)提供一个现实的逼近实际的黑客如何试图渗透并利

用系统问题(有关更多信息,请参见8.2),并且可以测试的网络安全的好方法控制工作。然而,渗透测试的一个缺点是,它需要

发生在生命周期的相对较晚(当代表系统软件,硬件,可用)没有多少时间来纠正错误。

模糊测试也可以作为功能测试的一部分。模糊测试的目的是用数据和/或信号功能轰炸功能或系统，看系统功能或系统

是否会回应在一个不受欢迎的方式可能暴露弱点加以利用。工具仍在开发中，专门为嵌入式车辆系统,进行模糊测试但有些

模糊测试工具为其他行业开发(如使用。、智能手机、网站) 有一些特定的系统适用性(例如、蓝牙和无线网络连接)。

这些测试方法：漏洞测试、渗透测试以及模糊测试可以在内部进行或由第三党机构进行。建议漏洞测试和渗透测试由独

立进行公正的评估系统的渗透测试评估个人或团体来做。公正意味着评估是不受任何感知或实际利益冲突的发展,操作,或管

理系统的评估或网络安全控制有效性的决心。为了实现公正, 评估员不应该：（i）创建一个共同的或相互冲突的利益与组

织来进行评估；（ii）评估自己的工作；（iii）作为为组织服务管理层或员工; (iv)把他们自己放在倡导组织收购他们的

服务的位置。独立的评估可以从元素组织内,或者公共或者私人组织获得。（来源:国家标准800 - 53,CA-8渗透测试/独立渗

透剂或团队(9)）这些测试的结果应当存档，包括任何发现的任何新的漏洞。

产品发布之前,重要的是网络安全技术要求是否已经实现的验证。在之前漏洞测试工作的结果怎样？基于漏洞测试、渗

透测试、功能测试水平,等等, 定义的技术网络安全需求得到满足吗? 如果任何网络安全需求尚未完全满足, 他们应该记录

用于最终的网络安全评估。

8.4.8最终网络安全评估/网络安全案例

最终的网络安全评估分析了系统在开发的最后阶段网络安全要求的满足程度，并解决在硬件层级，软件层级以及硬件和

软件集成时在产品开发过程中进行的网络安全评估，更新存在的任何剩余开放式网络安全问题。最终的网络安全评估在发布

生产系统之前完成。一旦完成，最终的网络安全评估就成为网络安全案例。网络安全案例类似于系统安全过程中的安全案例。

虽然安全案例提供证据和论证，设计和开发的系统满足已确定的安全目标，但网络安全案例将提供证据和论证，系统设计和

开发的“安全”到所需的水平; 即在概念阶段中在TARA中标识的网络安全目标得到满足。

应根据网络安全评估/网络安全案件的调查结果和建议，制定行动计划和里程碑，以排除问题。可能的情况是，并非所

有开放的网络安全问题都需要消除。对于一些安全人员来说，一些开放的网络安全问题可能被确定为允许访问的。如果是这

种情况，对于相关的网络安全风险是可以接受的应提供合理化解释。注意，提供这种合理化解释以便成功地解决和“关闭”

未决问题是很重要的。 在所有开放的网络安全问题关闭，或者合理化解释可接受以及实际上是“关闭”之前，系统不应该

被释放生产。

8.4.9最终网络安全审查

最终的网络安全门审查可以在系统层级阶段活动的产品开发完成时执行，或者可以在每个活动完成之后执行审查（6.3

描述了两种方法的优点和缺点）。所选择的特定方法取决于每个组织。

在系统层级阶段审查的产品开发需要审查的活动包括：

系统级漏洞分析和结果。

技术网络安全概念。

技术网络安全要求。

系统设计。

功能集成，测试和结果。

脆弱性和渗透测试结果。

网络安全目标和网络安全案例的验证。

技术性的审查应包括：

验证系统层级漏洞分析的正确性和完整性以及结果。

验证技术网络安全概念的完整性，一致性和正确性，以及从功能性网络安全概念。

无论是在技术网络安全要求内，还是根据技术网络安全概念和功能网络安全要求，验证技术网络安全要求的完整性，一

致性和正确性。

验证系统设计相对于技术网络安全要求的完整性，一致性和正确性。

验证特征集成和测试的完整性，一致性和正确性，以及特征集成和测试的结果。

验证漏洞和渗透测试的完整性，一致性和正确性以及漏洞和渗透测试的结果。

验证网络安全目标的验证和验证的完整性，一致性和正确性。

验证网络安全案例以及最终网络安全案例中的网络安全案例的完整性，一致性和正确性。

在开始生产发布之前，应该在系统级阶段审核中成功完成产品开发。 如果在审核期间发现任何问题，应在更改生产版

本之前纠正和/或解决问题。

8.4.10发布生产

一旦最终的网络安全审查已经完成并被接受，系统就可以投入生产。一旦生产，组织的生产过程和程序将在生命周期的

有效期内生效。 有关在生产期间和系统/车辆在现场操作期间以及需要系统/车辆维修时的与网络安全相关的任务的信息，

请参见8.7。

此外，这也是当推出所有权变更或寿命终止的网络安全考虑时。 具体来说，如果系统存储所有者想要擦除的任何个人

可识别信息（PII）（例如，当车辆出售时），则应描述用于擦除/消毒PII的任何方法，并且应向所有者提供指令 ，经销商

和其他服务提供商。 有关此主题的更多信息，请参阅5.7。

 

 

8.5硬件层的产品开发

图9显示了硬件层级产品开发的活动。 将在本节中描述图中框中所示的每个活动。

8.5.1背景

在引入自动化和无线互连之前，车辆是更简单的机械控制，物理隔离的机器。 现在，自动化控制可以增强或替换人类

交互，并且数字信息可以在内部有线网络以及延伸超出物理车辆的无线网络上流动。 随着传感器和控制信息的传输，处理

和存储，现代车辆看起来更像一个信息系统，其中传统网络安全目标的完整性，可用性，甚至保密性都适用。 如果车辆数

据损坏或不可用，则会对车辆操作产生不利影响。 如果存储在车辆网络内的制造商专有信息或用户的私人信息被泄露，则

可能危及机密性。

本节重点介绍硬件过程开发，其作为构建安全车辆系统的一部分。 硬件对于确保网络安全功能特别重要，因为嵌入式

系统的资源有限，并且由于网络安全功能（例如加密计算）可以通过特殊设计的硬件执行速度，比在软件中执行的速度快许

多倍。 网络安全硬件可以作为使CPU或微控制器从计算密集加密操作释放的特殊外围芯片存在。 嵌入在微控制器中的专用

硬件安全芯片或硬件安全模块可以承载作为整体支持车辆系统的多个网络安全功能，例如加密算法加速，安全密钥存储，安

全数据存储和安全执行。 硬件安全芯片也可以在防篡改封装中实现，以帮助检测和阻止物理篡改。

8.5.2 硬件层开始开发产品

启动确定和计划与硬件开发的各个子阶段相关的网络安全活动。 在此阶段，网络安全和系统工程团队将识别任何与硬

件相关的网络安全要求，包括安全，隐私，财务，业务，法律或法规影响。

网络安全应最大可能减少对车辆的威胁和影响，以防止对系统，用户和业务案例的损害。 应该被定义和记录网络安全

管理角色和职责，包括识别硬件网络安全领导，定义网络安全，工程，硬件/软件，安全，以及建立网络安全评估和测试的

预算和范围之间的关系。 在启动期间，网络安全小组与工程，安全和感兴趣的商业团体一起，应识别以下部分中概述的潜

在威胁。

8.5.3 硬件层脆弱性分析

从安全角度来看，硬件级分析可识别，量化并优先考虑可能影响安全目标的危险。在现代车辆上，从网络安全角度进行

的硬件级分析应识别，量化并优先处理可能导致影响网络安全目标或网络安全要求的风险。潜在的硬件网络安全漏洞的一个

例子是对ECU上的联合测试操作组（JTAG）端口的无保护访问，该端口可用于从ECU的ROM或RAM提取数据或代码（例如固件）。

物理/硬件漏洞的另一个示例可能是通过OBD II端口轻松访问车辆总线，即使访问被要求进行排放测试。车载网络OBD II端

口一般允许直接物理访问除诊断和控制之外的信息。通过OBDII端口的总线访问也可以用于注入假诊断业务消息或控制消息。

潜在的物理/硬件网络安全漏洞的另一个示例可能是旨在用于娱乐，安全或诊断应用的无线连接，其也可允许未授权的远程

访问车辆信息和控制。在这种情况下，无线协议连接在网络栈中的软件的任何更高级处理之前存在于网络模型的物理层。为

了帮助识别由于硬件网络安全漏洞的潜在硬件攻击面，可以关注车辆内的物理组件和接口以及这些组件和接口的潜在威胁。

8.5.4硬件网络安全要求规范

硬件网络安全要求的第一步是检查（并根据需要更新）系统网络安全上下文，其中包括标识硬件接口，数据流，数据存

储，数据处理以及支持网络安全功能的系统。 下一步涉及了解硬件如何支持整个系统的目的或任务，包括应该执行的网络

安全功能，例如防止未经授权的访问或检测篡改。 所需的网络安全功能可以根据诸如性能，有效性或及时性的参数来定义。

例如，当硬件设备检测到已经发生篡改时，设备应该擦除所有存储的信息或记录其已被设计为保护的篡改事件。 应确定设

计的潜在约束，包括内部或外部威胁，法律/监管考虑和成本。

硬件网络安全要求指导了网络安全设计的创建，并代表在测试阶段测量系统的网络安全所依据的标准。

8.5.5硬件网络安全设计

网络安全设计的重点是满足上一阶段发展的网络安全要求。 网络安全设计可能需要使用和集成现有的网络安全解决方

案以满足网络安全要求，或者可能需要开发全新的网络安全解决方案。 网络安全设计应该降低威胁分析中发现的威胁的整

体风险。 重要的是衡量竞争网络安全设计选项的潜在有效性，并选择最有可能降低风险的选项。 应完成风险评估以确定网

络安全设计的有效性。 硬件可以设计网络安全体系结构度量，以帮助衡量或量化针对网络安全目标的进展。

硬件网络安全解决方案可以在防止篡改，未经授权的物理访问或逆向工程的控制方面实施。 例如，篡改保护应防止攻

击者访问设备的某些部分而不被检测。 物理访问控制应防止未经授权的读取或使用系统的某些部分（例如内部车辆总线）。

反逆向工程控制应防止攻击者解密和读取专有权限。

设计人员可以查阅推荐的网络安全控制列表，如附录D中的网络安全控制列表，以帮助确保硬件网络安全设计考虑标准

的网络安全保护方法。 附录D中列出的网络安全控制（仅作为样本列表）围绕不同的控制系列进行组织。 单个控制功能可

以实现为硬件和软件的组合，因此硬件网络安全设计应与软件网络安全设计协调。 在随后的阶段，测试应验证设计中提出

的控制是否已实施并按预期运行。

一个特别有用的网络安全设计选项是将信任锚如HSM（硬件安全模块）或安全硬件扩展结合到硬件设计中。可信硬件组

件可以提供可信和可靠的密码处理功能，例如密钥生成，密钥存储，加密/解密和随机数生成。 EVITA项目开发了三个级别

的HSM（全，中和轻）的规范，这些规范可嵌入ECU中，以实现安全存储和安全通信。完整版HSM是最昂贵，也是功能最全的。

它适用于ECU和外部系统之间的通信，包括硬件加速的非对称加密/解密功能。中版本HSM比完整版更简单和更便宜，它没有

硬件加速的非对称加密/解密功能，最适合与使用对称加密的车辆内的其他ECU进行通信。 Light版本是最便宜和最简单的版

本。它最适合ECU和车辆传感器或执行器之间的通信。

8.5.6硬件层集成和测试

在实施阶段，将获取和/或构建，集成，配置，测试和记录硬件网络安全组件。 硬件级集成和测试结合了硬件组件，并

在系统测试之前将组合作为一组进行测试。 在下面的漏洞和渗透测试之前，集成测试应该验证硬件组件的分组满足功能，

性能和可靠性需求。

8.5.7硬件层脆弱性测试和渗透测试

网络安全漏洞测试和/或渗透测试有助于确定硬件是否已经抵御创造性的智能威胁，例如熟练的人员攻击者。 测试有助

于确定在应用网络安全控制之后剩余风险的数量。 可能无法消除所有风险; 某些风险可能需要被接受。 记录测试结果和残

留风险，具有接受残留风险的权限的个人将确定风险是否可接受，或者是否需要额外的网络安全设计工作和控制以将风险降

低到可接受的水平。 本阶段的文件包还可包括解决剩余风险的行动计划。 例如，如果创建了使所有者/操作者或维护人员

意识到潜在风险并提供避免其的指示的策略和程序，则特定风险是可接受的。

硬件层漏洞测试应该尝试验证已知被减轻的漏洞和潜在漏洞。 测试方法将检查已知的硬件漏洞列表及其建议的缓解措

施，以确保相应的网络安全控制已实施并正常工作。 硬件层渗透测试应该模拟攻击者或攻击者试图绕过网络安全控制并获

得对系统的控制行为。 渗透测试（更多信息参见A.2）可以由一系列具有初级专家技能组的模拟攻击者来执行，并且攻击可

以模拟具有每次攻击或具有越来越高级攻击工具对目标系统的增加的知识攻击者，直到攻击是成功的，这有助于定义系统的

抵抗攻击的阈值。

硬件漏洞测试和渗透测试可能会开始尽快作为一个工作原型，并在开发生命周期的关键点，应重复测试。脆弱性和渗透

测试可以由人员在内部网络安全测试团队作为基线评估，但一个合格的、独立的实体（见8.4.7条款）最终应从事这种试验

确定内部团队可能错过的问题。

8.5.8 验证/验证硬件网络安全要求

涵盖所有硬件的网络安全测试进行网络安全要求以确定实际硬件设计是否与所需结果相匹配。 硬件网络安全设计可追

溯到并针对硬件网络安全要求进行验证，实施可追溯到硬件网络安全设计并经过验证。

8.5.9优化网络安全评估

在硬件层面的产品开发完成后，对功能的网络安全评估进行了细化。任何以前开放的网络安全问题都应进行审查，以确

定硬件级别的产品开发活动是否导致任何未决问题的结束。关于如何关闭问题的解释应包括在网络安全评估的更新中。无法

关闭的问题将转移到网络安全评估的下一个改进。在此阶段确定的任何新的开放性网络安全问题应包括在评估中。如果知道

在发展的后期阶段解决未决问题的潜在途径，这些建议可以包括在各自的未决问题中。如果任何开放的网络安全问题在这个

发展阶段被认为是可接受的，那么应该提供一个理由来解释为什么公开的问题是可以接受的，并且该问题应该基于所提供的

理由实际上被“封闭”。事实上“封闭”的问题，不需要重新审查，除非在后来的发展阶段引入信息，使用于几乎“关闭”

问题的理由无效。

 

 

8.6 软件层面的产品开发

图11显示了软件层面产品开发的活动。 将在本节中描述图中框中所示的每个活动。

8.6.1软件层面启动产品开发（计划）

本节使用ISO 26262 部分6中软件开发过程框架，以便有效地规划软件开发，并且仅作为参考。 还有其他框架可以根据

项目要求使用。 为了开发嵌入式软件，ISO 26262第6部分“软件层面的产品开发”被用作基础，允许在开发安全相关软件，

网络安全相关软件和没有安全或网络安全的软件之间的通用过程的效率意义。

要纳入软件开发规划的典型活动包括：

软件生命周期阶段的规划，调度和资源配置；

识别任何“现货”或重用软件组件，并确定任何所需的资格活动以建立这些元素的网络安全能力；

识别支持软件开发过程的任何工具，对这些工具所需的信心以及任何适用的指南；

选择支持软件开发的方法（见下文）；

选择编程和/或建模语言（见下文）；

软件集成和测试规划（见下文）。

方法选择：

ISO 26262第6部分（与该标准的其他部分相同）包含大量的方法表。 所述方法是将在软件开发中应用的技术示例，其

支持实现相关联的需求和所需的完整性（鲁棒性）。 ISO 26262中表的一个关键特征是可以使用那些列出的方法的替代方法，

并且不管方法（从表或其他地方）的选择，应当提供为什么所选择的方法满足 相关要求。 方法的选择和理由记录在软件开

发的文档规划中。

ISO 26262中给出的方法指南可用作选择其他方法以支持除了功能安全之外的网络安全完整性/鲁棒性的起点。

选择编程和/或建模语言：

选择编程语言用于实现与网络安全相关的软件。 关键要求适用于选择语言以最小化软件包含漏洞的可能性，这些包括：

语言应该在语法（允许的构造）和语义（由在程序代码中编写的语言构造产生的行为）方面具有明确的定义；

语言应支持模块化，抽象和结构化结构；

语言应促进创建确定性和可分析的代码；

语言应支持实时系统和运行时错误处理。

如果语言不固有地支持这些要求，则可以通过在开发环境中使用语言子集，编码指南和分析工具来将它们强加于基本语

言。 此类子集和准则可以是现有的公共领域指导，或者可以针对具体开发进行修改。

例如，对于“C”编程语言，公开可用的子集MISRA C和CERT C提供关于避免软件中的漏洞和不可预测的行为的指导。 子

集通常通过在开发环境中使用静态分析工具来强制执行。 有关静态分析的更多讨论，请参见下面的“软件单元设计和实现”

部分。

注意，虽然语言子集和静态分析传统上应用于诸如“C”的命令性编程语言，但是这些要求同样适用于基于模型的开发

范例和自动代码生成。

软件集成和测试规划

建议“提前”开发软件集成和测试策略，以确保效率，避免重复任务; 尽管这应该随着软件的设计和实现而更新。 例

如，渗透测试传统上被视为生命周期后期活动，以证明产品的鲁棒性，但是可以在生命周期中更早地指定和重用测试用例，

例如，在软件单元测试中，验证软件单元响应如何 污染的数据。 可以考虑使用共同的标准测试方法以确保获得全面的综合

测试（7）。

8.6.2软件网络安全要求规范

软件网络安全要求规范与定义硬件网络安全要求一样，指定软件网络安全要求的第一步是检查（并根据需要更新）系统

上下文，包括标识硬件和软件接口，数据流，数据存储，数据处理和支持网络安全功能。下一步涉及了解软件如何支持整体

系统目的或任务，包括应该执行的网络安全功能，例如防止未经授权的访问或检测篡改。所需的网络安全功能可以根据诸如

性能，有效性或及时性的参数来定义。例如，当一个软件检测到篡改已经发生时，软件应该记录（并且如果可能的话报告）

 

 

篡改，并且改变用于其被设计为保护的所有存储信息的相关联的网络安全密钥。如果软件擦除它正在保护的数据，这可能是

攻击者的预期后果;因此，所实施的所有网络安全措施应最大限度地减少和减轻意外后果。另一个示例是实现代码签名以检

测和防止修改的代码在模块或系统中被安装或执行。应确定设计潜在的约束，包括内部或外部威胁，法律/监管考虑和业务

案例。

8.6.3软件架构设计

软件架构设计具应该有以下分析：数据类型的使用; 数据如何流动; 软件如何检测错误; 以及软件如何从错误中恢复。

期望的结果是使数据保持机密性，完整性和可用性（CIA）。

FIPS 199（10）将CIA定义为：

保密：“保护对信息访问和披露的授权限制，包括保护个人隐私和专有信息的手段”,失去保密性是指未经授权的披露

信息。

完整性：“防止不当信息修改或破坏，包括确保信息不可否认性和真实性”，完整性的丧失是未经授权的修改或破坏信

息。

可用性：“确保及时可靠地访问和使用信息”可用性的丧失是对信息或信息系统的访问或使用的干扰。

NIST FIPS 199定义的CIA为理解设计软件架构时应解决的潜在威胁提供了一个框架。 例如，如果对将在系统上的敏感

数据（即，机密性）存在重大关注，则确定将提供处理加密和/或访问控制的能力的架构。 以类似的方式，软件设计者应该

查看CIA的其他方面，并确定是否存在与CIA类别相关的威胁，这些威胁可以在软件架构的设计中解决，例如保护网络安全关

键数据和/或功能。

对数据流的分析将有助于识别软件可以在哪里进行分区和隔离。 这将有助于保持效果或后果传播到另一部分。

为了帮助防止软件部分失败（例如：无响应的应用程序，堆栈/数据操作），软件应该实现错误检测和错误恢复，包括

格式错误或损坏的输入。 如果错误不可恢复，那么软件应该恢复到预定义的安全/安全状态，并通知所有相关软件模块发生

错误。 这些依赖软件模块应该具有这种类型的故障设计用例。

如果失败的软件模块能够在稍后的点恢复，则在已经通知依赖模块其失败之后，它应该通知从属软件模块它已经恢复并

且返回到操作状态。 软件模块还应该具有此类恢复案例的用例。

还应记录错误，故障和恢复。 记录帮助分析以识别异常，入侵尝试或系统鲁棒性的缺口。

8.6.4软件脆弱性分析

作为软件漏洞分析的一部分，分析软件的网络安全要求和来自软件架构设计的数据流，并定义信任边界的存在位置。 当

数据跨越这些信任边界时，定义所需的控制。 这是完成威胁模型，威胁分析和攻击树（参考A.1.7有关攻击树的更多信息）

的一个重要部分。

威胁建模首先是一个帮助突出设计过程中的风险过程。 它有助于设计团队在网络安全验证期间确定在哪里定位添加的

测试和审查。 威胁建模回答了在分析系统的网络安全时需要有条理的思考过程; 主要关注的是创建攻击目标方法，然后可

以用于保护系统。

威胁建模通过专注于组件之间的数据流和控制，以及通过系统的给定功能使用情况的整个系统入口点和出口点来实现其

目标。 数据和控制通过任何信任边界的任何地方都特别关注。 信任边界显示信任级别改变的位置（例如，不受信任的外部

数据进入系统或安全系统与非安全性交互）。

威胁建模中的基本步骤从分解应用程序或用例开始。 这涉及理解应用程序如何与外部实体交互以及数据在哪里存储和

处理。 这涉及创建用例，以了解如何使用应用程序来了解潜在的攻击者可以与系统进行交互。 此信息记录在威胁模型中，

并为应用程序生成专用数据流图，显示整个系统的不同路径，突出显示特权边界。

第二步涉及使用威胁分类（如STRIDE，ASF或DREAD）来根据系统故障识别威胁。 一般威胁情境可以在这里使用，并覆

盖在系统细节上，以帮助突出风险领域。在一些模型中，确定过程，控制和数据区域的严重性值，而其他，特别是微软的SDL

（3），任何入口点或信任边界被视为对最后一步是关键的。

最后阶段从以前的步骤获取目标区域，并对从最高风险到最低风险的确定区域应用控制。 网络安全控制可以包括减少

或减轻风险，接受风险，公开风险（例如警告标签）或终止风险（例如，改变功能行为或减少功能）。 实施的决定应包括

 

 

对业务成本和与实现风险相关的成本的理解。

8.6.5软件单元设计与实现

在软件设计和实施过程中，应遵循良好的编码实践。 良好的编码做法包括但不限于：

输入验证

输入清理（例如，SQL注入）

安全字符串使用，禁止API使用（已弃用的函数），不安全的函数

字符串或数组使用没有显式长度，可能导致缓冲区溢出

域特定：SQL，web，网络与CAN使用相比

实际使用标准（例如，MISRA C，CERT C）

静态和动态分析

注意，ISO 26262中推荐的许多方法（也称为“设计原则”）有助于确保所需的属性，包括软件单元设计和实现中的鲁

棒性，通常通过语言子集（如MISRA C或CERT C）来实现。每个语言子集通常集中在特定区域; MISRA C用于可靠的嵌入式编

程，而CERT C用于安全性。语言子集可能重叠。 建议一起使用涵盖安全性和网络安全性的语言子集（例如MISRA C和CERT C

语言子集）。

经验表明，静态分析是一种特别有用的技术，用于识别可能成功编译的代码中的软件漏洞，因为尽管代码可能满足语言

的句法要求，但仍然可能包含不可预测或未定义的行为。

可以参考以下来源以获取更多信息：

ISO 12207：系统和软件工程 - 软件生命周期过程（11）

ISO 27001：信息安全管理（12）

ISO 27002：信息技术 - 安全技术 - 信息安全管理实践守则（13）

ISO 29119：软件测试标准（14）

8.6.6软件实现代码审查

代码审查应在整个软件设计和实施阶段（8.6.5）对软件进行，在适当的门审查期间，特别是对于新的或修改的软件。

这些审查应分析和识别可能会在系统中造成或引入风险和脆弱性的编码方法和结构。使用语言子集可以帮助避免引入漏洞的

构造。此外，工具应进行评估（例如，优化的编译器，可能会产生不确定的行为），以确定是否使用该工具可以引入或无法

检测到一个漏洞。测试用例应该被创建以评估代码所施加的风险。 如果风险超过了被认为允许的程度，或者如果代码危及

系统的网络安全或稳定性，则代码应该被重写或减轻。

代码审查还应该验证在方法，函数，类，模块等之间传递的数据是如预期发送和接收的，并且不匹配（例如，不适当的

单位，大/小端，超出范围）。

第三方库也应该分析潜在的漏洞，可能会增加一个成功的攻击的风险。第三方组件可能包含同一个库的不同版本。跟踪

第三方组件可以是一个重要的任务。资源和工具确实存在，以协助这个过程。一些资源包括：

美国国家漏洞数据库（NVD）（35）

常见的漏洞（CVE™枚举）

工具和实用例子见附录一。

8.6.7软件单元测试

单元测试验证软件的元素，例如子例程，函数或类的执行如预期。 单元测试将被测元件与应用或系统的其余部分隔离。

在进行单元测试时，建议您从最低单元级开始，并进行后处理。 应对每个元素进行测试，以确保以下内容符合预期：

输入

输出

数据流/数据依赖链

边框

错误处理

异常处理

故障模式

恢复模式

如果元素失败单元测试，应采取纠正措施，并且需要重新测试元素。 还应进行回归测试，以确保元件不会对其他元件

产生不利影响。

当为单元测试设计合适的测试用例时，您应该对以下测试用例进行良好的抽样：

一般测试数据

边框

错误处理

故障/恢复处理

重要的是要注意，虽然边缘情况不是常规遇到的，但由于缺乏足够的测试，它们往往是一个漏洞源。

8.6.8 软件集成和测试

单体测试后，软件元素需要集成在一起。 测试应包括验证集成软件不会导致集成软件以非预期的方式运行，例如当不

应发送CAN消息时发送CAN消息。

测试旨在确定是否满足网络安全要求。测试应包括所有数据入口点的模糊测试，包括无线接口，USB和CAN。这将测试

软件的鲁棒性，并且软件模块正在按预期进行通信。测试还应包括渗透测试，以帮助确定软件和系统是否已经抵御创造性的

智能威胁，如熟练的人类攻击者。测试有助于确定在应用网络安全控制之后剩余风险的数量。可能无法消除所有风险;某些

风险可能需要被接受。记录测试结果和残留风险，具有接受残留风险的权限的个人将确定风险是否可接受，或是否需要额外

的网络安全设计工作和控制以将风险降至可接受的水平。本阶段的文件包还可包括解决剩余风险的行动计划。例如，如果创

建了使所有者/操作者或维护人员意识到潜在风险并提供避免其的指示的策略和程序，则特定风险是可接受的。

8.6.9软件网络安全要求的验证/验证

在实施阶段，获取和/或构建，集成，配置，测试和记录软件组件。 进行涵盖所有软件网络安全要求的网络安全测试，

以验证实际结果与所需结果相符。

软件网络安全设计可以针对软件网络安全要求进行追溯和验证，实施可追溯到软件网络安全设计并经过验证。

8.6.10 软件脆弱性测试和渗透测试

第8.4.7节概述了渗透测试和模糊测试的测试方法，两者都可以在软件级使用,如果某种程度的危险水平或阈值值得保证，

则应进行渗透测试（见A.2），模糊测试和静态代码分析。该风险的深度和广度可以帮助确定渗透和模糊测试应该如何扩展。

如果某种程度的风险水平或阈值需要进行模糊测试，则应进行模糊测试。模糊测试是一种软件测试技术，可用于发现潜

在的网络安全缺陷，可靠性问题和稳定性问题。它通过产生一个系统的随机化输入，努力使其崩溃，或者以不同于预期的方

式工作。模糊测试已被证明是一种经济有效的手段来发现软件中潜在的网络安全缺陷，如缓冲区溢出，拒绝服务攻击和格式

错误，所有这些都可以被潜在的攻击者利用来获取未经授权访问ECU或ECU网络。

脆弱性和渗透测试可由独立的内部网络安全测试团队或外部第三方参与的人员执行。

8.6.11 优化网络安全评估

在软件级阶段完成产品开发时，会对该功能的网络安全评估进行细化。任何以前开放的网络安全问题都应该进行审查，

如果软件层面的产品开发导致任何未决问题的结束，那么应当关闭未决问题，并解释如何关闭问题。无法关闭的问题将转移

到网络安全评估的下一个改进。在此阶段确定的任何新的开放性网络安全问题应包括在评估中。如果知道在发展的后期阶段

解决未决问题的潜在途径，这些建议可以包括在各自的未决问题中。如果任何开放的网络安全问题在这个发展阶段被认为是

可接受的，那么应该提供一个理由来解释为什么公开的问题是可以接受的，并且该问题应该基于所提供的理由实际上“封闭”。

事实上“封闭”的问题，不需要重新审查，除非在后来的发展阶段引入信息，使用于几乎“关闭”问题的理由无效。

 

8.7生产，经营和服务

8.7.1 生产

8.7.1.1 计划

发布生产系统后，供应商应该：向客户提供证据表明过程能力得到了正确的满足和保持。审核客户和供应商之间的协议，

解决和定义每个方的网络安全责任。签署供应商协议，声明他们有权访问，交换和生产监控网络安全相关的特性。及时并根

据供应商协议报告与网络安全相关的事故。 如果发生与网络安全相关的事故，应该对该事故进行分析。在生产车辆发布后，

车辆制造商应该：管理生命周期网络安全注意事项（处置，PII数据/密码删除等）。网络安全问题的监视字段。遵循网络安

全问题的事故响应计划。

8.7.2 操作，维修（维修）

8.7.2.1 现场监测

现场监测过程审查各种来源，以确定应被视为潜在影响网络安全的现场问题和事故。 现场监视过程可以监视从执法，

保险，媒体文章，黑客聊天，其他车辆组织等收集的数据，以确定高风险领域或实时发生的事故。 这里是一个可以收集网

络安全事故信息并与之共享的区域模型。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

图19 - 事故响应小组数据源示例（15）

可以形成一个团队，确定事故的根本原因，识别纠正措施，确保纠正措施的实施，并监控现场的纠正措施，以确定所采

取的预防措施是否满意地解决了事故的根本原因。 然而，监测实地的类似事故，没有发现任何事故，并不表示潜在的脆弱

性已经完全消除。 系统在一段时间内没有被破坏的事实不表示未来的违约不可能发生，或者没有任何尚未被利用的漏洞。

8.7.2.2 事故响应

事故响应过程响应向组织报告或在车辆行业中发生的网络安全事故。这些事故可能是对您组织的网络物理车辆系统的实

际攻击或对其他组织的网络 - 物理车辆系统的攻击。这是一个过程，一旦事故被识别，工作以包含（最小化损失和破坏）

事故，并减轻网络安全事故，如恶意软件感染，黑客入侵，数据泄露等等。定期监控攻击是至关重要的。为处理事故建立明

确的分类程序至关重要。与内部团体（例如IT，人力资源，公共关系，法律）和外部团体（例如执法部门，其他车辆组织的

其他事故响应团队或公共部门）建立关系并建立适当的沟通方式也至关重要。信息共享和分析中心（ISAC）或其他类似论

坛）。聘请外部网络安全供应商帮助确定是否有效解决了该漏洞可能是有益的。

准确，及时地报告潜在事故是有效的网络安全事故管理过程的重要组成部分，因为无论报告发现的潜在事故可能导致重

大后果，无论系统设计如何好或响应或遏制程度如何充分 程序。 例如，其他小组没有意识到经验教训，没有适当解决类似

的漏洞等。正式的网络安全事故报告，取证和升级程序应该到位。 应使所有员工，承包商和第三方用户了解可能对组织资

产的网络安全造成影响的不同类型事故和弱点的报告程序。

建立事故响应能力可以包括以下动作：

创建事故响应策略和计划。

制定执行事故处理和报告的程序。

确定威胁是否是真实的，

根本原因分析，

法证分析，

确定操作影响，

确定商业影响，

知道如何正确处理敏感信息，

记录采取的行动，

通信，

记录经验教训并折回到新设计中。

制定与外部各方就事故进行沟通的准则。

选择团队结构和人员配置模型（例如，技术上胜任，了解车辆系统，培训）

建立事故响应团队与其他团体（内部和外部）之间的关系和沟通渠道。

确定事故是否需要升级：

如果事故导致公共安全问题，

如果事故对公司的声誉或诚信造成不利影响，

如果事故导致财务损失（示例），

车辆盗窃

保修

销售损失

未经授权访问功能/功能

导致更高的保险费用

欺诈性商业交易

如果事故导致隐私损失（示例），

未经授权的个人身份信息（PII）获得

未经授权的车辆跟踪

如果事故导致功能丧失或拒绝服务（示例），

客户不满意

车辆无法启动

确定事故响应团队应提供什么服务。

NIST 800-61计算机事故处理响应指南（15）中提供了构建正确的事故响应小组以及必要功能背后的更多细节。

8.7.2.3 事故响应过程的执行和维护（15）

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

图20 – 事故响应过程示例

组织应该建立一个团队负责检测和分析数据，而其他团队升级（分配优先级，警告员工，及时报告），并解决/消除问

题。 组织应该制定关于事故优先级的书面指南，他们应该使用经验教训过程从事故中获得价值。 一旦组织制定计划并获得

管理层批准，组织应实施计划并每年审查一次，以确保其正在成熟的能力和实现其目标的事故响应。

事故响应小组应使用标准操作程序，具体技术过程或技术，清单和表格。 遵循标准化响应应该使错误最小化，特别是

可能由特别事故处理引起的错误。

以下是处理事故的示例检查表大纲。 清单为处理程序提供了应该执行的主要步骤的一般准则; 它不规定应该遵循的步

骤的确切顺序。

表1 - 事故处理清单（15）

 

 

 

8.8支持开发过程（16）

本节的内容提供了作为网络安全过程基础的一部分应该实施的关键支持过程的高级描述。 如果一个组织目前没有使用

这些支持过程中的一个或多个，则成功实施车辆网络安全过程将更加困难。

8.8.1配置管理

配置管理过程的目的是在产品开发生命周期中管理系统：

确保系统最初创建的原则和一般工作条件可以以受控方式唯一标识和复制。

确保可以追踪系统的早期版本和当前版本之间的关系和差异。

审计和报告系统的配置基线。

满足计划系统配置管理的相关生命周期阶段的适用先决条件。

8.8.2 需求管理

第一个目标是确保关于要求的属性和特性的正确定义。

第二个目标是确保在系统的整个生命周期中一致地管理需求。

维护这些要求（更新用例，确保在要求本身或与其他要求之间不存在矛盾，维持层次结构，从而不发生重复的要求等）。

创建测试程序以验证这些要求已得到满足。

计划定期发布节奏，以便在发布一旦批准和证明可以捆绑多个要求，以达到全球分布。

通过实施要求以及对要求的验证和验证，保持网络安全目标的可追溯性。

满足每个要求中的某些创作属性和内容[明确（明确，可理解），一致，完整（全面），可行，可测试等]。

8.8.3 更改管理

变更管理的目标是分析和控制整个产品生命周期中系统/产品的变更。 需要对给定产品所做的更改的系统规划，控制，

监控，实施和记录。 为此目的，介绍和确定了变革的决策过程，并将责任分配给相关各方，具体包括：

应自动维护更改历史记录，以记录对系统/产品所做的更改。 对于每个修订版本，提供日期，请求更改的原因（和/或更

改请求编号）以及确切更改的说明。

将更改请求发送到“审批委员会”，以批准建议的更改。 确保更改请求的文档包括请求作者，请求的日期，请求更改

的原因，确切更改的描述等。

有一个团队/审批委员会来审查修订，并在发布之前批准请求。

在请求批准时进行影响分析（所有受影响的产品）。 例如，在进行更改之前，将评估对网络安全的潜在影响。

请求批准时提供介绍计划。

确定所有相关方。

为涉及的人员分配责任。

制定计划以实施批准的变更。 这需要包括发布新要求和对现有要求的更改，以及如何发布这些已批准的更改，特别是

如果对多个系统/产品有全局影响和/或影响。 另请参阅配置管理。

不仅需要测试工作产品以验证问题已在组件或系统级别解决，但在修复已经到位后随后对现场中的数据进行监视也应该

发生，以确保更改具有 预期改善的影响。

注意：这里的变化被理解为由于：异常，清除，添加，增强，组件过时等。

注意：配置管理和更改管理同时启动。 定义和维护两个进程之间的接口，以实现更改的可跟踪性。

8.8.4 文档管理

主要目标是为整个系统生命周期制定文档管理策略，以便促进有效和可重复的文档管理流程。 对于每个系统，以下文

档/工件应在文档管理策略中理解：

网络安全计划

功能定义

系统环境

威胁分析和风险评估

 

 

网络安全概念

功能性网络安全要求

网络安全评估/网络安全案例

建议将这些文档安全地存储，并且只允许信任和认证方访问。

应避免文档内和文档之间的信息重复，以帮助可维护性。

注意：文档可以是单个文档的形式，包含工作产品的完整信息或一组包含工作产品的完整信息的文档。

应计划文件编制过程，以便提供文件：

在开发生命周期的每个阶段，为了有效完成阶段以及验证和验证活动，

用于管理网络安全和

作为网络安全评估的输入。

文件应为：

精确，简洁，

结构清晰，

易于由预期用户理解，和可维护，

组织，以便于搜索相关信息。

8.8.5 质量管理

建立类似于QS 9000（17），ISO / TS 16949（18）的内部质量管理体系。

任何网络安全更改应遵循正常的公司质量流程。 也就是说，开发质量文件（设计FMEA，边界图，质量历史报告等）。

事故报告是机密的质量保证文件，应根据组织的政策进行存储和分发。

质量管理应以证据为基础。

应尽早发现过程中出现的任何问题。

每个网关的评估旨在捕获错误。

角色和责任应当清晰明确。

关于这一问题的知识和信息应予以记录和分享。

定期评估应吸取经验教训，并导致持续改进。

与任何监控活动一样，根据确保流程质量的重要程度，确定网络安全指标的优先级是非常有用的。 为了及时实现高质

量的产出，可以进行利益平衡评估的成本。

8.8.6分布式开发的要求（与供应商）

此外，应评估供应商根据公司内部流程开发网络安全系统的能力和适当的风险等级。 供应商选择标准应包括评估供应

商开发和生产此功能的能力，以及他们在Cybersecurity漏洞域中的专业知识（如果有的话）。 应考虑以下项目：

供应商开发网络安全关键系统（如果有的话）的能力证据。

供应商有能力遵循结构良好的开发中的网络安全流程的证据。

供应商质量管理体系的证据。

供应商在开发关键系统时的过去性能和质量历史的证据。

鉴于这是一个新领域，证据可能不是关于网络安全的发展。

证据表明供应商在特性的整个生命周期内提供网络安全支持的能力。

应开发客户和供应商之间的开发接口协议，以便为给定项目建立供应商责任。 所选供应商的责任和期望应适用于关系

的所有方面。 发展接口协议应至少包括：

来自供应商的网络安全负责人，负责监督供应商开发，并作为与客户的主要联系人。

供应商将遵循的网络安全流程协议。

工作产品的协议，将从供应商提供给客户。

将与客户共享的工作产品。

只向客户展示并与客户审查，但不向客户发布的工作产品。

关于发展进程时间安排的协议。

关于计划技术门评审的协议。

他们将在何时何地举行，什么将被审查。

关于已知的网络安全漏洞或企图违约的供应商共享知识的协议。

客户和供应商之间就报告和回应网络安全事故的过程达成的协议。

在开发期间和生产后释放。

一份协议，供应商将在项目的整个生命周期内提供网络安全支持，以及提供此支持的过程。

9. 注意

 

9.1修订指示器

位于左边距中的变换条（l）是为了方便用户定位对本文档的上一版本进行技术修订而不是编辑更改的区域。 文档标题

左侧的（R）符号表示文档的完整版本，包括技术修订版本。 更改条和（R）不在原始出版物中使用，也不在仅包含编辑更

改的文档中。

SAE车辆电气系统安全委员会准备

 

 

附录 A - 网络安全分析技术的描述

 

提供附录A作为进一步研究的参考，并促进设计和工艺改进。 附录A不是网络安全分析技术的全面列表。

A.1威胁分析与风险评估和脆弱性分析方法概述

本附录概述了安全分析技术的样本，包括电子安全车辆入侵保护应用程序（EVITA）程序使用的方法，威胁，漏洞和实

施风险分析（TVRA）方法，操作性关键威胁，资产和漏洞 评估（OCTAVE）方法和HEAling漏洞以加强软件安全和安全

（HEAVENS）方法和攻击树信息。 这不是一个全面的列表，并且此文档没有，此时，建议一个具体的方法。 因此，由每

个组织决定是使用下面描述的方法之一，还是使用不同的方法。 应用其中一些方法的示例在附录C，“威胁分析与风险评

估和脆弱性分析方法的附录概述”中给出。

A.1描述了可用于威胁分析和风险评估（TARA）和漏洞评估的一些方法。 TARA在8.3.3中描述。

脆弱性分析也称为脆弱性评估。 脆弱性分析技术试图识别和分类可能被攻击者利用的正在开发的系统的软件和硬件中

的潜在的网络安全漏洞或漏洞。 一些已识别的漏洞可能比其他漏洞更容易被利用。 因此，对漏洞进行分类以确定哪些漏洞

需要最受关注是有益的。 一旦确定并分类了漏洞，就可以确定适当的网络安全控制措施，以消除漏洞或使漏洞更易于攻击

者利用。

脆弱性分析可以在不同层次进行; 系统级别，硬件级别和软件级别。 一些分析方法，例如攻击树，可以在不同级别使

用。

在进行风险评估时要牢记的一个概念是“剩余风险”的原则。 ISO / IEC 27001：将剩余风险定义为“风险处理后剩余

的风险”（12）。 换句话说，在确定了风险并确定了什么样的网络安全控制将用于减轻风险之后，由于不可能消除所有风

险，在某些层面仍将存在一些剩余风险（残余风险）。 考虑已知的适用网络安全控制措施，重新进行风险评估。 这还可以

提供关于攻击的可能性可能如何改变的信息，以及可能在攻击的严重性中存在什么变化。 有关风险评估的更多信息，请参

阅ISO / IEC 27001。

A.1.1 EVITA方法

EVITA 代表电子安全车辆入侵保护的应用程序。它得到了欧盟委员会的联合资助，它包括一系列的组织，包括米拉，

宝马集团研究和技术，博世，大陆，ESCRYPT，富士通，英飞凌。这个项目的目标是设计、验证和构造车辆车载网络原型

的体系结构，网络安全的相关组件是为了保护敏感数据被篡改和受到危害攻击。为了满足这个目标，其目的是基于ISO/IEC

15408 (7) 的主要方法和策略来推断网络安全功能需求，并且综合采用ISO/DIS 26262过程的系统工程实践。

EVITA考虑四个网络安全目标：

可控性-维护所有车辆的预期可控性性能和ITS功能。

安全-确保车辆使用者和其他公路使用者的功能安全。

隐私-保护隐私的车辆司机和汽车制造商及其供应商的知识产权。

经济性-防止欺诈性商业交易和汽车被盗窃。

对于每个网络安全目标，EVITA项目考虑：

威胁识别：使用“暗侧（dark side）”场景和攻击树来识别通用威胁，因此确定通用的网络安全要求。

威胁分类：根据威胁结果的严重性和成功攻击的概率制定了对威胁风险进行分类的建议。

风险分析：基于威胁分类的风险结果来提出行动建议。

在威胁识别方面，对于EVITA方法开发的暗侧场景方案包括：

可能的攻击动机的识别和分类，

相关攻击者能力（例如技术，财务）的评估，

攻击建模，包括：

识别将满足攻击动机的特定攻击目标，以及

基于用例（20）和（19）中标识的功能，构建可以实现攻击目标的可能的攻击树。

识别的攻击目标成为攻击树中的顶级事故。然后通过识别满足攻击目标的一个或多个攻击目标，其次识别可用于实现攻

 

击目标的一个或多个攻击方法来构造攻击树。有关攻击树的更多信息，请参见A.1.7。

EVITA威胁分类部门的EVITA维系分析和风险分析法是基于ISO 26262 危害分析和风险评估方法在风险评估实践过程

中的良好表现提出的。严重性确定基于ISO 26262严重程度级别，但扩展到考虑非安全相关的结果和多个车辆的潜在后果，

因为ISO 26262中的严格性仅考虑安全相关结果和单个车辆。 表2显示了EVITA威胁分类中使用的严重性表。 红色文本显

示了严重性分类的扩展，它超出了功能安全的使用范围（ISO 26262）。

表2 - EVITA严重性等级

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

表3 - 攻击潜能和攻击概率的评级

 

 

 

 

 

 

 

 

 

 

 

 

 

 

在EVITA中成功攻击的概率基于IT安全评估中使用的“攻击潜能”的概念，并且同时考虑攻击者和系统。对于攻击者，

攻击的可能性考虑了许多因素，例如攻击者确定如何攻击系统和执行成功攻击所需的时间，攻击者所需的专业知识，所需系

统的知识，需要的需要用于专业设备等。每个因子具有多个类别，每个类别被分配有数值;例如，攻击者专业知识的类和相

应的数值是外行（0），熟练（3），专家（6）和多个专家（8）。攻击的可能性还基于分配给每个因素的数值的总和的范

围而分类。攻击潜能的类别有：基本，增强型基本，中等，高和超高。攻击可能性的范围从基本-意味着功能容易攻击，到

超越意味着功能是非常难以攻击。然后基于所确定的攻击可能性来分配攻击概率。表3显示了攻击潜力和攻击概率的评级。

然后使用“风险图”方法组合严重性和攻击概率，以识别与每个威胁相关联的风险。该方法类似于ISO 26262第3部分

（28）的表4“ASIL测定”。然而，与ISO 26262中的ASIL确定不同，没有针对网络安全风险的单一映射，因为在网络安全

中，严重性是一个4分量向量。此外，必须考虑与安全相关的网络安全风险的可控性。表4显示了非安全相关的网络安全威胁

（隐私，财务和运营）的网络安全风险图。表中所示的严重性Si表示Sp，Sf和So，其中Sp表示关于隐私威胁的严重性，Sf

表示关于财务威胁的严重性，并且So表示关于操作威胁的严重性。每个潜在威胁的确定的严重性被映射到表1中所示的适当

分类，以及所确定的攻击概率A = 1-5。严重性和攻击概率的矩阵中的交集确定风险R0 - R6，用于待评估的潜在威胁，其中

R0表示最低风险，R6表示最高风险。

表4 - 隐私，财务和运营网络安全威胁的网络安全风险图

 

 

 

 

 

 

 

 

 

 

 

 

表5 - 安全相关威胁的可控性分类

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

安全相关威胁的风险图略微复杂一些，因为需要确定可控性并将其包括在安全相关风险图中。 可控性分类用于评估人

类以避免与安全相关威胁相关的潜在事故的方式行动的可能性。 可控性被分类为C1-C4，其中C1意味着正常人的反应可以

避免事故，C4意味着人不能以避免事故的方式作用。 表5显示了可控性类别及其相应的定义。

安全相关威胁的风险图包括四个子矩阵; 每个可控性分类的一个矩阵。 因此，对于安全相关的威胁，风险确定是可控

性，严重性和组合攻击概率的组合。 表6中显示了安全相关威胁的风险图的一部分。注意，表6中的不同类别的可控性的风

险级别将不同。

表6 - 安全相关威胁的风险图的部分

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

一旦确定了每个潜在威胁的风险，就会识别网络安全目标，并根据风险级别对威胁进行优先级排序。 风险水平越高，

在实施过程中可以应用越严格。

A.1.2 EVITA方法在威胁和可控性分析在特征级应用（THORP）的使用

除了特定的特征或系统外，应用了开发的EVITA方法。然而，该方法可以适于在特征或系统级应用。在此推荐实践中描

述的过程在特征级应用。本节介绍如何在功能（或系统）级别应用EVITA方法。本节中描述的方法提供了一种系统和一致的

方法来识别与被评估的特征相关的威胁。该方法来自于常用于系统安全工程的着名的HAZOP（危害和可控性分析）方法。

而不是HAZOP，该方法被称为THROP（威胁和可控性分析）。 THROP类似于HAZOP，除了它考虑潜在威胁而不是潜在

危险。类似于HAZOP，THROP从功能角度解决特定功能的风险。基于要分析的特征的主要功能，在功能级别定义威胁。在

特征定义中识别的特征的主要功能被记录在矩阵中，并且指南被应用于功能以识别潜在的威胁。例如，潜在的通用威胁可能

是潜在地恶意地导致特征的不期望的行为。

执行THORP的步骤是：

识别特征的主要功能（这是在特征定义期间完成的），

应用功能的指南来识别潜在的威胁

例如，恶意的非预期的“功能”，恶意的不正确的（太高，太低，... ）“功能”，恶意的“功能”损失，以及

3． 从潜在的恶意行为中确定潜在的最坏情况情景结果

例如，用于恶意损失“功能”威胁的情景可能是失去启动车辆的能力。一旦确定了潜在威胁并确定了潜在的最坏情况，

则可以通过应用8.1.1中描述的EVITA风险评估方法来评估潜在威胁的风险。 然后可以根据风险级别对识别的潜在威胁进行

分级，以便进一步分析的重点可以是最高风险威胁。 然后可以确定最高风险威胁的网络安全目标，并且可以分配和使用唯

一ID来识别每个网络安全目标。 表7显示了一个具有列标题的示例电子表格，可用于在功能级别使用威胁和可控性分析

（THROP）应用EVITA方法。 在C.1中给出了使用THROP在特征级应用EVITA的示例。

表7 - 使用THORP在特征级应用EVITA方法的列标题

 

 

A.1.3 TVRA

TVRA代表威胁，漏洞和实施风险分析，是一种过程驱动的威胁评估/风险评估方法，由2009年制定，并于2010年由欧

洲电信标准协会（ETSI）更新。 当前标准ETSI TS 102 165-1 V4.2.x（2010）TISPAN描述了TVRA如何在10个步骤中完成，

以系统地识别系统中要防止的不需要的事故。 TVRA识别系统中的资产及其相关的弱点和威胁，并通过模拟攻击系统漏洞的

可能性和影响来确定系统的风险。

TVRA的十个步骤概述如下：

1、确定目标系统资产，并指定分析的目标，目的和范围。

2、确定目标，并产生一个关于要解决的网络安全问题的高级别声明。

3、确定功能性网络安全要求（源自步骤2）。

4、库存资产并完善步骤1中的描述，并添加步骤2和3中标识的其他资产。

5、确定威胁，可利用的脆弱性，以及剥削的后果。

6、确定威胁的发生，可能性和影响。

7、确定风险。

8、确定网络安全控制措施以降低风险。

9、执行网络安全控制成本效益分析，以确定应首先实施哪些网络安全控制。

10、实施步骤9中确定的网络安全服务和能力的详细要求。

TVRA是为数据/电信网络而不是网络物理系统（如车辆）中存在的组合控制和数据网络而开发和最适合的。

 

A.1.4 OCTAVE

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

图21 - OCTAVE方法的阶段（21）

OCTAVE是一种过程驱动的威胁评估/风险评估方法，代表了操作性关键的威胁，资产和漏洞评估，它是由软件工程研

究所（SEI）与国防部（DoD）协作于1999年首次开发的， 远程医疗和高级技术研究中心（TATRC）。 OCTAVE旨在解

决国防部需要遵守健康保险可携性和责任法案（HIPAA）安全规则。 国防部的医疗处理设施采用了OCTAVE方法，后来又

通过了一些商业方法。

OCTAVE最适合企业信息安全风险评估。 OCTAVE特别擅长通过逐步的系列研讨会，将具有系统经验的主题专家和具

有安全经验的主题专家聚集在一起，以便为问题域开发一个彻底的组织和技术视图。 在研讨会上完成了一系列详细的工作

表，以确定资产，当前做法，网络安全要求，威胁和漏洞，然后制定减轻风险和保护资产的战略和计划。 图21中示出了

OCTAVE方法的阶段。

OCTAVE研讨会包括由代表组织的业务部门，信息技术（IT）部门和网络安全部门的成员组成的跨学科团队。 还开发

了OCTAVE的两个敏捷变体：一个用于少于100人的组织（OCTAVE-S）和另一个简化的方法，仅关注信息资产（OCTAVE

Allegro）。 OCTAVE Allegro包括图22中所示的八个步骤。这八个步骤通过参加一系列研讨会的参与者完成的三份调查表

和十份单独的工作表完成。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

图22 - OCTAVE 快速路线图（22）

OCTAVE阶段和工艺步骤可与国家标准与技术研究所（NIST）特殊出版物（SP）800-30中的步骤相关，如表8所示。

这些阶段对应于图21中所示的阶段 - 阶段 OCTAVE方法和处理对应于图22所示的步骤。

因为OCTAVE方法是全面的，并且包括来自商业，信息技术和安全的输入，所以它有助于引出可能被忽略的安全相关信

息; 然而，它可能需要大量的时间和资源投入来完成。 OCTAVE方法似乎经常被使用或者甚至专门用于评估现有企业信息

系统中的风险。 车辆的风险评估过程应涵盖从概念阶段到生产，操作和维护的整个产品生命周期，并且应认识到车辆是移

动网络物理系统，而不仅仅是信息系统。

表8 - OCTAVE阶段（21）和工艺步骤与NIST SP 800-30（16）的相关性

 

 

A.1.5 HEAVENS安全模型

“HEAVENS安全模型”侧重于关于车辆电气和/或电子（E / E）系统（23）的威胁分析和风险评估的方法，过程和工

具支持。 目标是提出一个系统的方法来推导车辆E / E系统的网络安全要求。 此外，提出了从概念验证实施和通过使用车辆

用例评估所提出的HEAVENS安全模型获得的结果。 有关详细信息，请参阅HEAVENS交付的“D2安全模型”（23）。

我们在开发HEAVENS安全模型时考虑了威胁分析和风险评估的最先进的技术。 HEAVENS安全模型的主要特点如下：

•拟议的模型同样适用于各种道路车辆，例如客车和商用车辆。 该模型考虑了广泛的利益相关者（例如，OEM，车队

所有者，车辆所有者，司机，乘客等）。

•该模型以威胁为中心，并通过在车辆E / E系统的环境中应用微软的STRIDE方法实现。

•该模型在威胁分析期间建立安全属性和威胁之间的直接映射。 这有助于可视化并及早估计对特定资产的特定威胁的技

术影响（保密性，完整性，可用性）。

•模型将风险评估期间的安全目标（安全，财务，运营，隐私和立法）与影响级别估计进行了映射。 这有助于了解特定

威胁对相关利益相关者（例如OEM）的潜在业务影响。

•该模型提供了基于行业标准的影响级别参数（安全，操作，财务，隐私和立法）的估计。 例如，安全参数与功能安全

标准ISO 26262（24）一致，财务参数基于BSI标准（25），操作参数基于汽车提出的故障模式和效应分析（FMEA） 行业

行动小组（AIAG）（26），隐私和立法参数与“隐私影响评估指南”（27）相关。

•该模型符合成熟的行业标准和举措。 例如，IT安全评估的通用标准和道路车辆功能安全的ISO 26262。

A.1.5.1 HEAVENS安全模型的工作流程

图23 - HEAVENS安全模型的工作流程

 

 

 

 

 

 

 

 

 

 

 

 

图23显示了HEAVENS安全模型的工作流程。 它包括三个组件 - 威胁分析，风险评估和网络安全要求。

•威胁分析 - 对功能用例（图中的In_01）的描述是威胁分析过程的输入。威胁分析产生两个输出：（a）在用例的上下

文中针对每个资产的威胁和资产（图中的Out_01）之间的映射，以及（b）威胁和安全属性之间的映射（图中的Out_02）确

定哪些安全属性由于资产背景中的特定威胁而受到影响。

•风险评估 - 一旦确定了相关资产的威胁，下一步就是对威胁进行排名。这是在风险评估期间做的。威胁和资产之间的

映射与威胁级别（TL）（图中的In_03）和影响级别（IL）（图中的In_04）参数一起用作输入。威胁级别参数（威胁级别（TL））

和影响级别参数（影响级别（IL）在A.1.5.1.2中介绍）。作为风险评估的最终结果，针对与评估对象 /用例的每个资产相关

联的每个威胁识别安全级别（图中的Out_03）。

•安全要求 - 最后，威胁和资产之间的映射（图中的Out_02）以及安全级别（图中的Out_03）被视为制定资产和评估

对象的网络安全要求。网络安全要求是资产，威胁，安全级别和安全属性的函数。衍生的网络安全要求在ISO 26262的功能

安全要求的水平，并且属于概念阶段。后来，在产品开发阶段，软件的网络安全要求。

A.1.5.1.1 威胁分析

在HEAVENS安全模型中，威胁分析指的是识别与评估对象的资产相关联的威胁以及具有安全属性的威胁的映射。 微

软的STRIDE方法（3）被采用用于威胁分析。 虽然STRIDE是用于发现和枚举软件系统中存在的威胁的结构化和定性的安

全方法，但是STRIDE方法的适用性已经扩展到车辆电子电器系统。

 

 

STRIDE通过将威胁与安全属性（真实性，完整性，不可否认性，保密性，可用性，新鲜度和授权）相关联，提供了扩

展原始CIA模型的机会。 每个类别的STRIDE威胁已经映射到一组安全属性。 此映射是静态的，用于在风险评估过程中确

定特定威胁-资产对的安全级别时制定网络安全要求。 STRIDE威胁和安全属性之间的映射如下所示（表9）。

表9 - STRIDE威胁和安全属性之间的映射

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

A.1.5.1.2 风险评估

风险评估是指威胁的排名。 在基于STRIDE方法识别特定用例的威胁 - 资产对之后，对威胁进行排名的风险评估进行，

即，导出每个威胁 - 资产对的安全级别。 安全级别（SL）是安全相关资产满足特定安全级别的安全机制所需强度的度量。

通过在包括威胁和攻击者的定义环境中使用安全级别来平衡风险。 风险评估包括三个步骤：（a）确定威胁级别（TL）：

这对应于风险的“可能性”分量的估计，（b）影响级别（IL）的确定：这对应于 风险的“影响”分量，以及（c）安全级

别（SL）的确定：这对应于最终风险评级。

威胁级别（TL）参数

参数“专业知识”是指对评估对象进行攻击所需的基本原则，产品类型或攻击方法的通用知识水平。确定的水平如下：

ü“ 行人”与专家或精通人士相比是不可知的，没有特殊的专业知识;示例可能包括那些只能遵循随可用工具提供的简单

指令来进行简单攻击，但如果指令或工具不能按预期工作，则无法自己进展的人。

ü“ 通”人员具有关于安全领域的一般知识，并参与业务，例如车间专业人员。熟练的人知道简单和流行的攻击。他

们能够安装攻击，例如，里程表调整和安装假冒零件，通过使用可用的工具，如果需要，能够即兴实现所需的结果。

ü“ 家”熟悉底层算法，协议，硬件，结构，安全行为，所使用的安全性的原理和概念，用于定义新攻击的技术和工

具，密码学，产品类型的古典攻击，攻击方法等。在产品或系统类型中实现。

ü引入了“多个专家”级别，以允许一种情况，在专家级别需要不同的专业领域来进行不同的攻击步骤。

参数“关于评估对象的知识”是指从攻击者的角度来看具有关于评估对象的知识的评估对象和社区大小的信息的可用性。

该参数指向攻击者可以从中获得关于评估对象的知识的来源，并且指示攻击者获得关于评估对象的知识是多么容易或困难。

确定的水平如下：

ü有关评估对象的“公共”信息（例如，从互联网，书店，没有保密协议共享的信息）。

ü有关评估对象的“限制性”信息（例如，在开发者组织内控制并与其他组织共享的知识，例如，在供应商和OEM之

间根据不公开协议）。示例包括要求和设计规范，内部文档。

ü关于评估对象的“敏感”信息（例如，在开发者组织内的离散团队之间共享的知识，其访问仅限于指定团队的成员）。

示例包括限制的ECU配置参数以启用/禁用车辆中的特征，车辆配置数据库和软件源代码。

ü关于评估对象的“关键”信息（例如，只有少数个人知道的知识，在严格需要知道基础和个人承诺的情况下，其访问

受到严格控制）。示例包括秘密根签名密钥。

参数“设备”是指识别或利用漏洞和/或发起攻击所需的设备。

ü攻击者随时可以获得“标准”设备，用于识别漏洞或攻击。该设备可以是评估对象本身的一部分（例如，操作系统中

的调试器），或者可以容易地获得（例如，因特网下载，协议分析器或简单的攻击脚本）。示例包括简单的OBD诊断设备，

常见的IT设备，如笔记本电脑。

ü“ 用”设备不易为攻击者提供，但可以无需过度的努力获得。这可能包括购买中等数量的设备（例如，功率分析工

具，使用跨因特网链接的数百个PC将属于这一类别），或者开发更广泛的攻击脚本或程序。示例包括车载通信设备（例如，

CAN卡），昂贵的车间诊断设备。如果明显不同的测试台由专门设备组成，需要不同的攻击步骤，这将被评为定制。

ü“ 制”设备不能随时提供给公众，因为它可能需要专门生产（例如，非常复杂的软件），或因为设备是如此专门化，

使其分布受到控制，甚至可能受到限制。或者，设备可能非常昂贵。

ü引入了“多重定制”级别，允许一种情况，其中需要不同类型的定制设备用于不同的攻击步骤。

参数“机会窗口”组合攻击者在评估对象上进行攻击所需的访问类型（例如，逻辑，物理）和访问持续时间（例如，无

限制，有限）。不同的级别包括：

ü“ ”：评估对象的可用性非常低。需要进行物理访问以执行车辆部件的复杂拆卸以访问内部构件以对评估对象进行

攻击。

ü“ ”：评估对象的低可用性。对评估对象的有限物理和/或逻辑访问。在不使用任何特殊工具（例如，打开机罩以接

入电线）的情况下对车辆内部或外部的物理接近。

ü“ ”：高可用性和有限的时间。逻辑或远程访问，无物理存在。

ü“ 键”：通过公共/不可信网络实现高可用性，没有任何时间限制（即，评估对象 /资产始终可访问）。逻辑或远程

访问，无物理存在和时间限制，以及对评估对象 /资产的无限制物理访问。示例包括无线或经由因特网（例如，V2X或蜂窝

接口）。

表10 列出了不同的参数和每个参数使用的值。

最后，对于每个威胁 - 资产对，对每个参数的值求和，并定义范围以确定对应于每个标识的范围的威胁级别。 采用五

种不同的威胁级别（无，低，中，高和临界），如表11所示。

 

 

 

 

 

 

 

 

 

 

 

 

影响层级（IL）参数

这是确保车辆乘客，道路使用者和基础设施的安全的一级要求。 评估安全影响的“安全”参数依据ISO 26262（28）：

无伤害

轻度和中度受伤

严重和危及生命的伤害（生存可能性）

危及生命的伤害（生存不确定），致命的伤害

“财务”类别考虑所有直接或间接的财务损失或损害。 直接财务损害可能包括产品责任问题（例如，处罚，召回），

立法问题（例如，由于不符合而造成的处罚），产品功能（例如，由于非法激活可销售功能而导致的业务损失）。 另一方

面，间接财务损害可能包括OEM声誉的损失，市场份额的损失，知识产权侵权等。此外，安全问题可能导致财务损失。 例

如，由于各种安全问题，几个OEM的某些型号的汽车的最近召回对每个OEM都有财务影响。 总而言之，财务损失是OEM

的直接和间接成本的总和，根本原因可能来自任何利益相关者。

“操作”类别包括由车辆功能的不必要的和意外的变化（或失去）引起的操作损坏。 这种操作损害的示例包括车辆的

次要（例如巡航控制）和舒适/娱乐（例如，cd播放器，空调）功能的损失。 但是，在某些情况下，操作损坏可能会导致安

全和财务损失。 例如，以主要和安全相关的车辆功能丧失的形式的操作损害可能影响乘客和道路使用者的安全。 因此，业

务类别对总体影响的影响在安全和金融类别方面相对较低。

“隐私和立法”类别包括由于违反利益相关者（例如，车队所有者，车主，司机）和/或违反法律/法规（例如环境，驾

驶）的侵犯而造成的损害。 隐私和立法合并为一个参数，因为隐私可能通过立法强制执行，并且存在与隐私无关的立法。 通

常，这种损害不具有直接损害，财务和业务维度。 然而，在某些情况下，隐私和立法违规可能导致利益相关者的财务（例

如，罚款，失去某些市场的访问）和操作性损害。 因此，隐私和立法类别对安全和金融类别的影响相对较低。

在HEAVENS模型中，不同的权重分配给不同的影响参数。 “安全”和“财务”参数具有相等的权重，同时估计总体

影响水平。 安全和财务参数的影响可能对利益相关者造成最严重的后果，例如，车辆乘客可能无法生存，组织可能会破产。

另一方面，“业务”以及“隐私和立法”参数对整体影响的影响在安全和财政损失方面相对较低。 为了在影响级别估计期

间反映这一事实，在操作以及隐私和关于安全和财务参数的立法的情况下将相应的因子减小一个量级。 表12显示了不同的

安全水平和估计安全影响的相应值。

表12 - 影响级别参数 - 安全性

 

 

 

 

 

 

 

 

 

 

 

 

财务损害的分类取决于个人利益相关者的财力。 因此，可以适当地表示限额作为总销售额，总利润或类似基值的百分

比，以及将损害赔偿定性地分类为损害类别，而不是定量地计算损害（25）。 表13提出了一种可能的财务损害分类。

表13- 影响级别参数 - 财务

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

我们调整车辆缺陷严重性分类，如FMEA（故障模式和影响分析）（26），以分类操作损害。 这在表14中示出。

已经提到的隐私和立法类别包括由侵犯利益相关者（例如，车队所有者，车主，司机）和/或违反法律/法规（例如环境，

驾驶）的隐私侵犯所造成的损害。 表15显示了为此参数分配不同值的一种可能方式。 有可能将隐私方面与德国BSI（27）

提供的“隐私影响评估指南”保持一致。

 

 

 

表14 - 影响级别参数 – 可控

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

表15 - 影响级别参数 - 隐私和立法

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

最后，将所有影响参数的值相加以估计影响程度（见表16）。

 

 

表16 - 估计影响水平（IL）

 

 

 

 

 

 

 

 

 

 

 

 

安全级别（SL）

在HEAVENS安全模型中，结合威胁级别（TL）和影响级别（IL）导出安全级别，如表17所示。

表17 - 基于威胁级别和影响级别的安全级别

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

A.1.5.1.3安全要求

HEAVENS安全模型的最后一部分涉及基于资产，威胁，安全属性和安全级别导出安全要求。 考虑表18所示的示例。

如第三行所示，资产“总线A上的CAN信号X”具有安全级别“QM”。 因此，可能不需要为此资产制定任何额外的网络安

全要求来处理欺骗威胁。 另一方面，应针对其他两种情况制定网络安全要求。

请注意，一个资产可能存在多个威胁，因此[分析]可能有多个安全级别，基于与资产相关的所有威胁的多个威胁级别。 确

定资产作为整体的安全级别的一种方法是考虑与资产相关联的所有威胁的所有安全级别中的最高安全级别。 另一种方法是

考虑最高威胁级别以及影响级别来定义资产的安全级别。

表18- 推导网络安全要求的示例

 

 

 

 

 

 

 

 

 

A.1.6 攻击树方法

攻击树最初由Schneier（29）描述，后来在车轮网络（30）和EVITA项目（19）中作为缺陷漏洞分析的一种手段。

在Schneier所描述的最基本的形式中，攻击树具有作为顶级节点的攻击目标，并且实现该目标的各种手段（子目标）被

探索以逐步地开发树的“叶” 和分层方式，直到识别出执行攻击的基本级方法。 使用与 / 或逻辑组合子目标，其中：

 

 

 

“或”逻辑表示任何子目标都可以实现其父目标，

“与”逻辑指示需要所有子目标来实现其父目标。

可以通过将布尔值或连续值与每个子目标相关联并在树上传播这些值来分析树。 在最简单的形式中，诸如“可能”或

“不可能”的布尔值可以被分配给基本攻击方法，然后使用布尔代数的规则向上传播到树，以识别可以实现目标的所有可能

的攻击。 类似的分析可以使用连续的数值来执行，例如攻击的成本（货币损失），然后可以用于优先化所需的动作，例如

通过识别将使受影响的利益相关者花费超过一定量的所有成功的攻击 。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

图24 - 通用攻击树

攻击树可以以图形或文本形式表示; 而（29）表示对文本表示的偏好，在许多意义上，攻击树完全类似于通常在可靠性

分析中使用的故障树，并且FTA工具可以适于开发攻击树。

在EVITA攻击树的方法中，提出了由以下级别组成的通用结构：

第0级：攻击目标（类似于故障树中的顶部事故）

第1级：攻击目标

第2级：攻击方法

第3级：（n-1）：中间目标/方法

第n级：资产攻击（执行攻击的基本级方法;类似于故障树中的基本事故）。

认为当成功概率（或其他度量）可以与攻击方法相关联并且这可以在树中的任何级别发生时，已经识别资产攻击。

EVITA方法的概念如下图所示（使用典型的故障树符号表示;尽管专用工具正在用于建模攻击树）：

在这个例子中注意：

“未开发事故”的故障树符号已用于AA4显示需要进一步开发的树的一部分。 这可能是因为需要额外的分析，或者这

可能是在别处进一步发展的树。

资产攻击AA3是两种攻击方法所共有的，可能是对优先级需求的早期指示，需要进一步分析。

资产攻击不限于在攻击树中的特定级别出现; 在上述示例中，资产攻击AA1是实现攻击方法1的直接手段，而其他攻击

方法可能需要资产攻击的组合。

攻击树可以扩展到不同的深度级别; 在早期的产品开发中，可能只能检查高层次的概念; 随着设计的进展，可以分析攻

击的一些更深层的原因。

特别是在概念阶段，攻击树可以支持严重性和概率评估：

在评估严重性时，可以考虑识别出的攻击目标对利益相关者的影响。

在评估概率时，分析可以考虑可能有助于攻击方法的攻击（包括攻击的组合）。

攻击树也可以支持：

通过考虑使用案例和所需的网络安全控制措施来减少资产攻击，从而产生网络安全要求。

网络安全控制的优先级 - 攻击树中重复出现的特定事故或模式可以指示操作的优先级。 附录C提供了一个示例攻击树

分析。

A.1.7软件缺陷漏洞分析概述

在软件漏洞分析中，有许多已知的软件结构，应该避免，以防止代码中的潜在漏洞。 由于许多允许在代码中存在漏洞

的SW结构是已知的，因此已经开发了许多工具来静态分析代码以使用不期望的结构。 许多工具只是寻找不良的结构; 然而，

一些工具还为分析添加了语义组件，以增加在代码中发现潜在漏洞的可能性。 此外，正在进行研究以分析漏洞的目标代码。

A.2网络安全测试方法概述

一般来说，渗透测试的目的是集中在威胁分析中识别的最高风险领域。 测试应该应用于所有外部数据接口（例如，蓝

牙，USB，蜂窝，Wi-Fi，ODB2，HMI）。 这不是一个全面的列表，本文档没有，在这个时候，推荐具体的方法。 因此，

由每个组织决定是否使用下面描述的方法之一，或者是否使用不同的方法。

A.2.1渗透测试的类型

一般来说，pen测试有两种主要类型：

“黑盒”=在黑盒测试中，很少（或没有）预先披露的信息。

“白盒”=在白盒测试中，测试人员可以访问有关系统的所有信息，例如漏洞评估的结果，访问源代码等。

“灰盒”=灰盒测试是白盒测试和黑盒测试之间的一部分，测试人员可以访问系统文档和算法，以及有关系统内部结构

的知识。

有关渗透测试的更多信息，请参阅NIST 800-53，CA-8，渗透测试/独立渗透代理或团队（9）。

A.2.2 Red Teaming 红队技术

红队技术是由美国军队开发的。 使用红队方法，一组内部专家组装成试图攻击系统的“恶意角色”（或红队）。 目标

是红队识别可能被恶意或非恶意攻击者利用的攻击媒介，以获得对系统及其内部网络的访问。 然后工程可以工作以消除这

些可能的攻击矢量或通过识别的攻击矢量减轻攻击的影响。

A.2.3模糊测试

有关Fuzz测试的信息，请参见8.6.10和附录I.

附录 B - 工作产品的示例模板

 

附录B给出了附录A，A.1.4中讨论的OCTAVE工作表的模板示例。 附录B还没有给出附录A中描述的其他方法的实例，

本文件目前没有提出具体方法。 因此，由每个组织决定是否使用附录A，A.1中描述的方法之一，或者是否使用不同的方法。

B.1 OCTAVE工作表

表19 - OCTAVE allegro工作表10，信息资产风险工作表

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

表20 - OCTAVE allegro工作表10，风险缓解部分

 

 

 

 

附录 C - 使用识别的分析的实例

 

附录C给出了附录A，A.1中描述的一些方法的例子。 这不是一个全面的列表，这个文档没有，在这个时候，推荐具体

的方法。 因此，由每个组织决定是否使用下面描述的方法之一，或者是否使用不同的方法。

C.1使用威胁和可控性分析（THORP）在特征级别的EVITA应用示例

特点：远程车辆禁用

创建功能功能定义：描述功能的目的，识别功能的主要功能，并描述网络安全周边。

目的：远程车辆禁用功能旨在由相关机构使用，以在车辆被盗，在高速行驶或其他危险情况下使用等情况下远程禁用车

辆。

示例主要功能：根据权限请求远程禁用车辆。

使用应用于功能的指南对已识别的主要功能执行THROP以识别潜在威胁。

示例潜在威胁：恶意意图禁用。

识别潜在的最坏情况故障情景：使用头脑风暴和专业知识来识别多个潜在的最坏情况故障情景。

示例潜在的最坏情况：车辆被恶意地禁用，没有当局的请求导致车辆的不可用性。 这是一种操作威胁，因为车辆将不

可用于驾驶员。

执行EVITA风险评估：一旦确定潜在威胁和潜在的最坏情况意外情况，将通过应用EVITA风险评估方法，针对每个潜在

的最坏情况意外情况分析潜在威胁的风险。 然后根据最高风险潜在危险情况对威胁进行分类。 一旦所有潜在威胁都被分类，

可以基于确定的风险级别对威胁进行优先级排序，使得更详细的分析可以集中在最高风险威胁上。

下面的表21示出可以用于所描述的示例的示例性电子表格。表中的“威胁ID”列用于提供所标识的每个高风险威胁的唯

一标识符。如果确定潜在威胁不具有需要进行进一步分析活动的风险级别，则不需要“威胁ID”，因为风险评估之后的潜在

威胁被认为不是威胁。此外，该表将在“网络安全目标”（由于空间限制在图20中的表中未示出）的末尾包括列。如果所识

别的潜在威胁在风险评估之后被视为真正的潜在威胁，则将识别网络安全目标并与潜在威胁相关联。用于转向辅助系统的“恶

意故意转向”的潜在威胁的网络安全目标的示例可以是“防止或减轻恶意故意转向发生”。通过对潜在的高级威胁应用脆弱

性分析来确定可能被利用的潜在脆弱性并导致恶意的故意转向威胁，这种高级网络安全目标将转变为功能和技术网络安全要

求。识别漏洞允许识别和实施网络安全控制，以减少导致识别的潜在威胁的成功攻击的可能性。如前所述，人们不能保证威

胁不会显现，然而，可以通过实施所识别的网络安全控制的适当组合来减少威胁的可能性。

表21 - 功能级别的EVITA风险评估示例电子表格

 

 

 

 

 

 

 

 

 

 

 

 

 

 

C.1.1 OCTAVE工作表分析示例

这里提供了来自OCTAVE Allegro流线型流程的一个关键工作表，作为一个工作表如何由汽车制造商或租车公司为假设

的威胁用例完成的示例。对于该用例示例，所有OCTAVE工作表在本文档之外完成，但是为了简洁仅此处示出工作表10。

工作表10将在填写OCTAVE工作表1至9的过程中产生的信息汇集在一起。在使用情况下，不满的机场租赁汽车雇员合法租

用车辆几个星期，并从OBD-II端口和/或CAN下载数据总线，以便学习关于汽车制造和型号的CAN数据分组的细节。不满的

员工设计可以通过经由OBD II端口通过连接到CAN总线的膝上型计算机闪烁引擎控制模块安装的恶意软件。闪回的恶意软件

包含在指定日期激活它的触发器。一旦激活，恶意软件就会向ECM发送一个数据包，从而杀死引擎并导致引擎重新启动。

一旦恶意软件被证明工作，员工将其安装在租赁车队。

表22 - OCTAVE 快速工作表10，信息资产风险工作表 - ECU固件的示例

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

表23 - OCTAVE 快速工作表10的示例，风险缓解部分 - ECU固件

C.2 攻击树例子

作为示例，已经针对潜在特征威胁“恶意有意车辆禁用”开发了攻击树（参见图25的THROP示例）。

关于这个例子，应当注意，它不一定是不完整的，仅仅用于说明原理。

假定预期函数的定义已经存在，例如通过指定用例。在该示例中，假设车辆配备有远程禁用设施，车主可以使用该远程

禁用设施来远程地防止车辆被启动，以及哪些执法机构可能还用于关闭运动中的车辆。

假设该功能通过远程服务中心实现，该远程服务中心可以接收来自车辆所有者或执法机构的与唯一标识符（例如，VIN）

相关联的请求，然后该请求以无线方式向车辆发送命令。车辆配备有接口ECU，其接收无线命令，对其进行认证并将所得的

命令或信息发送到内部车辆系统。

攻击树的开发从考虑潜在攻击者及其动机开始。 在这种情况下，已经指定了通用威胁“恶意故意车辆禁用”，并且这

在树的头部形成“攻击目标”。

然后通过考虑“攻击目标”（即，攻击者可以实现这个总体目标的不同手段）来进行树的开发。 在该示例中，已经识

别两个攻击目标 - 恶意远程禁用车辆和恶意禁用启动。 在这一点上应当注意，虽然许多攻击方法和资产攻击将被发现是这

些攻击目标所共有的，但是结果的严重性可以根据上下文而不同。 例如，单个车辆的启动的恶意禁用不可能具有安全相关

的结果。

树的下一阶段考虑“攻击方法”，即攻击者可以用来实现攻击目标的方法或技术。 这些可以以类似于故障树的方法进

一步细化，直到识别出“资产攻击” - 这些代表通过利用漏洞来执行攻击的基本级方法，并且类似于故障树中的基本事故。

在早期阶段（例如，功能性网络安全概念开发），这些可能是相对高级别，但可以在设计的后期进一步详细阐述。

例如，“恶意远程禁用”的目标可以通过攻击服务中心以生成恶意命令或通过攻击通信信道来实现。 在攻击通信信道

的情况下，利用其他方法来开发，例如，注入恶意消息或攻击车辆中的接口。

在恶意消息的情况下，假定攻击者将需要两次成功的资产攻击 - 利用密钥并产生恶意消息。 这通过在攻击树中使用

“AND”门来表示。

在攻击车辆中的接口的情况下，所示的资产攻击是故意高水平的，并且将随着设计的细节变得已知而进一步发展; 例如，

注入恶意软件，使得攻击者可以执行它们自己的命令。

应当注意，在该示例中，攻击方法“利用服务中心”和“利用远程通信”对于两个攻击目标是共同的，但是通常可能不

是这样。对此的进一步变化是例如存在被描述为“利用密钥：非法获取，修改或断开”但具有唯一标识符的两种资产攻击;

这是为了反映成功攻击的概率可以根据上下文而不同（例如，与另一类型的密钥相比，可以更容易地利用一种类型的密钥）。

最后，应当注意，可以识别网络安全领域之外的攻击方法，例如，获得对服务中心的物理访问或其运营商的社会工程。

这些可以包括在攻击树中，但不会进一步发展。组织的网络安全政策或项目网络安全计划通常会说明采取的方法。

这个攻击目标的攻击树结构的示例如下所示。注意，这是使用典型的故障树工具及其符号（同位素可靠性工作台-合并

故障树+）绘制，虽然用于构建攻击树的专用软件包可用。请注意，本示例中使用的一些符号在其他工具中可能不同：

表24 - “恶意故意车辆禁用”的攻击树结构示例

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

一般来说，工具会自动标记树中的节点; 在此示例中使用以下编号方案：

AG1指的是攻击目标。 通常，将有与特征相关联的多个攻击目标，并且将为每个攻击目标开发单独的攻击树。

AO1，AO2等是指攻击目标。

AM1，AM2等是指攻击方法。为了清楚起见，在本示例中为层次结构中的每个级别选择新的编号序列（AM1，...; AM11 ...;

AM21 ... ）。

AA1，AA2等，是指资产攻击。

图25 - 攻击树

C.3 HEAVENS安全模型的示例

本节用作HEAVENS安全模型的概念验证实现。基于车辆用例的初步结果[介绍]威胁分析和风险评估。车载诊断（OBD）

是当今车辆中非常常见的用例。 如果车辆检测到故障状态，车辆将执行自己的诊断和报告。 为了做到这一点，车辆系统具

有所谓的车载诊断（OBD）。 系统基本上具有使用其仪表盘来请求和呈现信息的能力。 这在各种情况下非常有用，例如请

求和呈现诊断故障代码，受影响的ECU的软件识别等。这种有线诊断和远程诊断的主要区别在于，不需要诊断工具来完成该

过程。 一切都在车辆系统内完成。

C.3.1 HEAVENS威胁分析示例

我们已经根据车载诊断（OBD）用例的高级操作说明开始了威胁分析活动。 创建DFD ，如图26所示。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

图26 - 车载诊断（OBD）用例的数据流图

DFD由两个不同的抽象级别组成，这两个级别在同一个图中显示。 一旦完成DFD并且未发现验证错误，请使用该工具

分析DFD并自动生成与OBD用例的资产相关联的威胁。 表25中显示了来自已识别威胁的提取。

表25 - 与OBD用例相关的威胁

C.3.2 HEAVENS方法的风险评估示例

表26显示了OBD用例的HEAVENS风险评估方法的结果的提取。 在分析期间，[结果是]每个资产 - 威胁对的威胁级别

为“低”，影响级别为“中”（见表26）。 这导致根据分析的安全级别“低”。

表26 - 基于HEAVENS方法的OBD用例的风险评级

 

 

 

 

 

 

 

 

 

 

C.3.3 HEAVENS方法的网络安全要求示例

对于OBD用例的每个资产 - 威胁对的资产，威胁，安全属性和安全级别的映射[建立]如表所示。 导出表的每一行的

Cybersecurity要求。 当前，安全级别[不考虑]，同时导出高级网络安全要求。 然而，预计安全级别将被视为估计所需的强

度和保护级别，同时开发网络安全控制以满足衍生的网络安全要求，以估计所需的。

表27 - OBD用例的资产，威胁，安全属性和安全级别

 

 

 

 

 

安全需求1

DECU应确保存储数据的完整性。

安全要求2

应确保OBD数据响应信号的真实性。

安全要求3

授权用户应能够在需要时使用OBD数据请求信号从DECU提取信息。

附录 D - 安全和隐私控制描述和应用

 

本附录列出了14个安全控制系列和5个隐私控制系列的示例集，以及每个系列中可能适用于车辆系统安全的几个控制。

覆盖的环境范围包括设计，制造，客户操作，维护和处置。 家庭名称和控制名称/标签来自NIST SP 800-53，联邦信息系统

和组织的安全和隐私控制7，其中列出了17个控制系列和240个安全和隐私控制，用于保护信息资产免受安全威胁（9）。 尽

管NIST SP 800-53是为美国联邦政府制定统一的信息安全框架而开发的，但是具有信息安全需求的商业公司也是目标受众。

NIST SP 800-53描述了两种控制定制过程（定制和覆盖），可以用于修改现有基线控制列表，以使其在需要时更适用。

定制是定制基准控制集以实现组织更集中和相关的安全能力的过程。基准集是FIPS 200定义的低，中和高影响信息系统的推

荐控制集合。重叠是一个专门的控制列表，可以满足感兴趣社区的专门需求，技术或独特环境，例如交通运输业。本附录可

以看作是为汽车行业提供的覆盖物的一个小样本。覆盖是完全指定的一组安全控制，增强和补充指导。如果存在适当的基线，

则可以从现有的安全控制基线导出覆盖。存在的主要用于信息系统而不是网络 - 物理车辆系统的现有基线可能忽视了关键

假设或者可能基于假设假设，并且车辆系统的特定覆盖将补救这一点。

覆盖图可以是抽象的以便适用于不同环境中的大类系统，或者它可以是关于系统硬件，固件和软件以及系统操作的环境

的特定。此外，一般车辆工业重叠可以提供定制指导以满足个别汽车制造商的专门要求，业务功能，技术或操作环境。在撰

写本报告时，交通运输行业的重叠部分可能太广泛，无法满足汽车行业的具体需求。为汽车行业创建一个完整的正式覆盖模

板可能是一个有用的平行努力或后续努力到这个SAE推荐做法。除了描述具体的车辆安全控制之外，提供关于在特定技术和

在不同操作环境中应用控制的指导将是有用的。 NIST SP 800-53描述了一个样本覆盖模板，其中包括以下部分：1.识别，

2.覆盖特性，3.应用，4.覆盖概要，5.详细的覆盖控制规范，6.定制注意事项，7.定义和附加信息或说明。

在表28中概述了14个安全控制系列（可能适用于车辆行业）及其相关控制的示例集。列出了控制的一小部分的简短控

制描述，作为读者的示例。 为汽车行业创建完整的正式覆盖模板以及所有相关文档的任务超出了本附录的范围。

表28 - 车辆行业的潜在安全控制系列和控制的示例列表

表28 - 车辆行业的潜在安全控制系列和控制的示例列表（续）

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

表28 - 车辆行业的潜在安全控制系列和控制的示例列表（续）

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

表28 - 车辆行业的潜在安全控制系列和控制的示例列表（续）

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

下表中的隐私控制专门针对车辆系统和组件，包括操作，维护和处置，以及已经建立的公司隐私计划。

表29 - 车辆行业的潜在隐私控制系列和控制的示例列表

 

附录 E - 脆弱性数据库和脆弱性分类计划

 

脆弱性通常被理解为“使系统或应用程序受到威胁的影响的系统的弱点或固有属性”。 一些作者使用“漏洞”一词与

“攻击”一词意义相同。 通常，术语弱点，漏洞和攻击可互换使用。

在讨论脆弱性数据库和分类方案之前，有必要讨论一些相关术语的普遍接受的含义 - 这些术语经常互换使用。

错误/故障

与正确行为的偏差是错误。被判定或假设的错误原因被称为故障（31）。故障的示例可以是用于将未检查长度的输入数

据复制到C / C ++中的固定长度的缓冲器的语句。

弱点

弱点是漏洞的“原因”。一般来说，弱点是安全问题的抽象式。弱点的形成从非常通用的，例如“缺少敏感数据的加密”

到相当具体的，例如“不受控格式字符串”，其可以是“C”语言程序的通用弱点。可能有几个来源导致弱点。由于缺少关

于环境的信息，对弱点的严重性的估计是复杂的。

脆弱性

所有故障不会导致漏洞。脆弱性是一些内部故障，使外部威胁损害系统，导致安全后果（31）。术语脆弱性用于指示由

它们生成的那些故障和特定条件，其可以在攻击的实施中被利用。例如，缺少输入验证错误的存在导致在堆栈中用于某些长

度的输入的适当位置处的缓冲器溢出，其可以被有效地用于注入所需特性的恶意代码。然后系统/应用程序知道有一个“缓

冲区溢出”漏洞。有时，术语漏洞也用于指示应用程序或一组应用程序中的安全问题，例如受影响的共享库的使用。所有漏

洞不需要被利用。脆弱性通常从具体的漏洞抽象，因此有时;在脆弱性和弱点之间没有明确的区别。可以估计利用漏洞的可

能性，因为已知创建工作漏洞是多么复杂。也可以评估严重性。

利用

漏洞是用于部署攻击的实现和或方法。漏洞可以打包为软件程序，或者它可以只是一些长度的数据。漏洞通常与具体应

用或一组应用相关，即如果它们共享共同的漏洞。很容易评估漏洞的严重性，因为成功攻击的后果是已知的，并且还知道有

多少系统受到影响。

不是所有的错误都会导致弱点。 并非所有弱点都会导致漏洞，并非所有漏洞都会导致可用的漏洞。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

图27 - 故障，弱点，漏洞和漏洞之间的关系

以下示例说明了相对于“W32.Blaster.Worm”安全事故的抽象级别：

表30 - 有关软件安全问题的抽象级别的示例

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

在获取脆弱性数据库之前，有必要提出两个主要和当前的努力，即创建一个字典和术语库，然后在脆弱性数据库中使用

它们。

表31 - 漏洞数据库的字典和术语源示例

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

在SAE J3061首次发布时，以下是两个突出的当前和正在运行的漏洞数据库：

表32 - 漏洞数据库的示例

 

 

 

 

 

 

 

 

 

 

 

 

 

 

有几种方法可以分类漏洞。 例如，它们被注入的点，例如生命周期的阶段，或者它们在何处找到，例如在硬件或软件

等中。从产品生命周期的角度来看，弱点可能是实现中的具体缺陷， 设计疏漏，缺少要求和可能被威胁源利用的不充分的

操作程序。 漏洞也可能是由于未应用网络安全控制措施，或者在应用时仍然存在一些弱点。 在学术文献中提出了相当多的

漏洞分类方案。 但是，两个主要目前和有用的努力如下：

表33 - 脆弱性分类方案的示例

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

上述数据库和分类方案关注软件漏洞。 这些数据库没有在网络 - 物理车辆系统中报告的漏洞。 目前正在努力开发一

种在汽车行业内报告和共享漏洞信息的方法。 一个这样的努力是自动ISAC等。

在任何情况下，本节中提出的NCD和CVE，CVSS也可以被车辆部门使用。 该信息可以直接使用或在适应上下文之后

使用。

 

 

 

附录 F - 车辆水平考虑

 

附录F讨论了应在车辆级别处理的网络安全方面。 本附录中的材料不全面，但作为参考进一步研究网络安全的车辆级影

响。

车辆级：

网络安全的一些关键方面是在车辆级别定义的，但会显着影响系统级技术要求。 以下是影响系统级技术网络安全要求

的车辆级决策的示例：

车辆具有什么样的电气结构？

定义车辆内部车辆通信网络的数量和类型。 车辆网络类型的示例包括：CAN，LIN，以太网，MOST，Flexray等。

识别车辆中电子模块/ ECU的数量。

每个ECU（以及带有硬件I / O的传感器）所在的车辆网络。

如何识别每个ECU？

哪些ECU应该被认证以执行其功能？ 如果是这样，怎么办？

哪些ECU将创建哪些消息，

特定ECU的所需硬件功能，

各种ECU所需的软件，可能包括基于ECU功能的要求（例如，影响安全关键系统的ECU可能具有与网络安全相关的特

定要求）。

在车辆级别，防止用户进行未经授权的更改也是重要的，这可能会降低车辆售出后的网络安全。 未经授权的更改的潜

在来源包括：

“调谐器”，可以更改校准设置或软件以获得不同的动力系性能特性。 OEM需要确定允许使用“调谐器”进行哪些更

改，并阻止那些没有或可能减少网络安全的更改。

可能来自DVD，蓝牙配对电话等的软件，并且可能尝试安装在车辆上，而不通知用户或告知用户可能存在的风险。

OEM应分析是否有任何模块，出于网络安全的原因，应该返回到默认工厂条件，甚至禁用/销毁，以防止模块进入旧零

件市场。 对于车辆的使用寿命，OEM应向Salvage Yard操作员提供有关需要特殊处理的项目（例如，从信息娱乐模块中删

除数据的最快方式，需要销毁的特定模块以及如何销毁它们）相对于网络安全 。

OEM应确保其一级供应商（以及可能的二级）知道报告任何可能的网络安全事故的过程，并且该过程应尽可能清晰易

用。

示例体系结构方法：

2014年2月，NIST发布了“改进关键基础设施网络安全框架”（8）。 该框架提供了广泛的指导方针，将风险管理的最

佳实践应用于提高非特定于任何领域的关键基础设施的网络安全和弹性。 它旨在帮助组织将其业务驱动因素和要求与风险

容忍度和资源相结合，以提供最强大的网络安全响应。 它已经确定了强大的车辆结构的特点如下：

识别-保护-检测-响应-恢复

包含可共存的每个原则的元素的架构为各种网络安全风险提供了强大的防御。

上述每个原则的例子，往往使一个架构更安全，是（但不限于）：

1.识别：

a、 捕获现有法规和指南

b、 捕捉业务风险

c、 捕获最安全的网络安全威胁状态（进化）

d、 创建威胁评估和响应策略

 

 

2.保护：

子系统中影响（即启动/终止/提供输入）关键网络安全功能和存储/传输的每个组件网络安全关键数据应由适合于风险级

别的安全机制加以保护。

安全机制 - 保留数据和例程所需的Cybersecurity属性的系统功能。 安全机制包括1.）认证机制（是允许访问某个资源

的代理）2.）完整性机制（防止未经授权的修改/写入消息）3.）机密性机制（防止未经授权的数据读取）。

安全机制：

a、具有来自可能对车辆的操作具有重要影响的安全关键系统和系统的外部访问（例如，Wi-Fi，蓝牙，OBD）的系统的

隔离/划分。

b、访问控制机制，限制对关键ECU的访问，每个ECU的关键模式（诊断模式）及其数据。

c、倾向于限制对关于车辆的操作状态，隐私敏感信息，财务敏感信息，详细设计信息等的信息的访问控制机制。

d、基于中央网关或域控制器的体系结构。

e、在倾向于验证消息的发射机并且在传输中没有被修改的设备之间的通信机制。

f、有效保护维护操作的机制，包括诊断程序和更新程序。

g、使有效攻击方法的逆向工程更困难（例如，代码混淆，最小化面向返回编程（ROP）使用等）所采取的步骤。

以下项目的好处仍在调查中。 以下任何一种的实施仍在研究中，并且存在对现场可行性和客户接受的重大关注。

 

 

1.检测：

一个。 车载网络入侵检测功能，可以检测系统的错误或意外行为。

b。 在运行期间连续监测车辆网络。

C。 报告何时遇到肯定命中的活动防火墙。

2.响应机制：

一个。 对于正侵入或意外行为检测，可能对车辆本地或车外检测做出反应。 例如，从连接的特征中切断安全特征（例

如，跛行回家模式）。

b。 事故报告到云和/或板载日志功能（事故数据记录器）。

C。 创建车辆上的事故的取证日志，允许解释车辆操作。

3.恢复：

一个。 旨在快速，安全地将更新和补丁部署到现场系统的系统，可能通过远程机制（对易受攻击的软件组件进行安全

的空中更新）。

b。 返回给经销商或制造商以获取硬件漏洞。

上述示例如果结合到车辆架构中，将可能使它们对于由于网络攻击而导致的故障更加鲁棒。 然而，当试图优化车内架

构以抵御网络安全威胁时，也应考虑对关键车辆功能（例如制动器，转向，安全气囊等）的隐私和响应时间的关注。 这并

不意味着这是一个全面的列表，或者如果没有这些做法，架构是不安全的。

附录 G - 可用于车辆工业的当前网络安全标准和指南

 

附录G列出了来自各种来源的标准和指南，这些标准和指南可能对车辆行业成员有用，以了解整个网络安全领域，并确

定如何在其组织中实施网络安全的细节。 下表不全面。

表34 - 可能对汽车行业有用的网络安全标准和指南

表34 - 可能对汽车行业有用的网络安全标准和指南（续）

附录 H - 车辆项目意识

 

附录H总结了从2004年开始到现在（即SAE J3061初次发布）的车辆网络安全的关键研究项目。 此列表可能不全面，

因为这是一个快速发展和不断发展的研究领域。

表35 - 车辆网络安全相关研究项目（2004年至今）

 

工具类别	描述 注意：示例工具是非综合性的
静态代码分析器	执行源代码或目标代码分析，而不执行或运行目标程序，这可突出差的编码实践或编码 错误的工具。 示例：Polyspace，C / C ++测试，Insure ++，IDA Pro，堆栈。
动态代码分析器	通过执行或运行目标程序来执行分析以强调可能的运行时错误，性能瓶颈和内存泄漏或 错误的工具。 示例：Veracode，Insure ++，IDA Pro。
网络流量分析器	从实时网络监控或捕获数据以进行实时或离线分析的工具。 网络数据可以根据不同的网 络协议被过滤并且被分析以确定网络是否如它应该执行，或者是否存在存在恶意软件或入侵 或异常的一些证据。 一些网络流量分析器也可以重新注入或重放捕获的数据。 网络流量可 能显示在有线或无线介质上。 示例：CANalyzer，Vehicle Spy，Wireshark，Kismet。
漏洞扫描	扫描网络和软件以进行常见安全配置错误，缺少修补程序或已知代码漏洞的工具。 车辆 上的脆弱性扫描可能是有问题的，因为车辆上的许多设备，代码和消息对于制造商和型号是 唯一的，并且消息也可以是专有的。 针对车辆上的标准Wi-Fi接口的漏洞扫描可以指示已知的 脆弱配置，但是对于其他车辆子系统可能不存在脆弱性信息。 （例如：Codenomicon Appcheck，Blackduck，NESSUS）
模糊器	为系统或应用程序接口生成无效，意外或随机数据的工具，用于检测错误的异常处理或 输入过滤， 这可能导致 程序崩溃或 可能被攻击 者利用的意 外状态。 示例CANbuster， Codenomicon Defensics。
加密 Cracker	可用于破解加密数据的工具。 这些工具通常在密钥空间中搜索将密文转换为纯文本的密 钥。 密文可以包括加密的传输或存储的信息。 示例：Aircrack，Cain和Abel，John the Ripper。
硬件调试器	可用于提取 片上程序代 码或数据并 修改存储器 内容的工具 。 示例：JTAGulator ， OpenOCD。
已知答案测试	可用于确定算法（如加密算法）实现的正确性的工具。 KAT工具通常可与NIST认可的算 法结合使用。
应用测试仪	用于测试应用程序的工具，例如可能存在于车辆域中的Web应用程序或移动应用程序。 示例：Burp Suite，Nikto。
接口扫描器	用于扫描网络接口以开放/侦听连接到设备上运行的服务的工具。 示例：nmap扫描车辆 的Wifi接口。

 

 

 

附录 I - 对车辆行业潜在使用的安全测试工具

 

本附录列出了一些安全测试工具类别和描述，这些测试工具可能对汽车行业的网络安全有潜在的用途。还给出了工具的

一些示例仅用于说明的目的。 SAE不认可或推荐任何这些示例工具或其制造商。完整的潜在测试工具列表超出了本文档的

范围。

此外，工具的选择可以是基于过去的工具或工具提供者的经验，工具特征或能力，技术支持或易于使用的个人或组织决

策，仅仅是列举几个区别。此外，两个或更多个工具在其一般或具体能力方面重叠是常见的。一些工具可能通常被攻击者使

用，但是这些相同的工具也可以被系统开发者用来在他们的产品中的Cybersecurity漏洞被发布之前，甚至在它们被发布之后

测试。

如果网络环境是良好匹配的，则来自信息技术领域的传统安全测试工具可以应用于车辆领域。例如，设计用于在典型的

信息技术网络上使用的网络嗅探工具也可以在车辆以太网网络或车辆Wi-Fi接口上使用。同样，代码分析器可以同样有用于

揭示传统信息技术环境和车辆环境中的潜在问题。相反，以太网/ TCP / IP嗅探器在监测车辆CAN总线业务中是没有用的;需

要CAN总线嗅探器。

网络应力测试仪	旨在生成高网络流量负载以确定网络和连接的设备将如何响应可能表示对系统的拒绝服 务攻击或高用户需求服务的负载的工具。 示例：IxChariot，LoadTest
利用测试器	旨在用于针对系统开发，测试和使用漏洞代码的工具。 示例：Metasploit。

更多文档资料，请关注博大汽车信息安全  公众号BodaSecurity。

本文标签： 信息安全 文档 指南 汽车