SAE车联网系统网络安全指南

车联网系统网络安全指南CybersecurityGuidebookforCyber-PhysicalVehicleSystems

目录1.范围 21.1目的 21.2何时应用网络安全流程 22.参考文献 23.定义和缩写词 23.1API 23.2ASF-应用程序安全框架（ApplicationSecurityFrame） 23.3ASIL-汽车安全完整性等级（AutomotiveSafetyIntegrityLevel） 23.4攻击潜力（ATTACKPOTENTIAL） 24.系统安全与系统网络安全的关系 74.1系统安全与系统网络安全工程的类比 74.2系统安全和系统网络安全的独特方面 75.网络物理车辆系统（CPS）的网络安全指导原则 75.1了解系统的网络安全潜力 75.2了解关键的网络安全原则 85.3考虑车主对系统的使用 85.4在概念和设计阶段实施网络安全 95.5在开发和验证中实施网络安全 95.6在事件响应中实施网络安全 95.7车主变更时的网络安全注意事项 106.网络安全流程概述 116.1定义明确、结构合理的流程的动机 116.2过程框架 116.2.1网络安全综合管理 116.2.2概念阶段 116.2.3产品开发 116.2.4生产、运营和服务 116.2.5支持流程 116.3里程碑和大门审查 117.全面管理网络安全 117.1网络安全文化 117.2衡量网络安全流程的合规性 117.3识别和建立沟通渠道 127.4制定和实施培训和指导 127.5操作和维护活动 127.5.1事件响应过程 127.5.2现场监测过程 128.流程实施 128.1将网络安全流程与集成通信点分开应用于安全流程 128.2将网络安全流程与ISO26262之后制定的安全流程相结合 128.3概念阶段 128.3.1特征定义 128.3.2网络安全生命周期的启动 128.3.3威胁分析和风险评估 128.3.4网络安全概念 128.3.5确定功能性网络安全要求 128.3.6初始网络安全评估 138.3.7概念阶段审查 138.4产品开发：系统级 138.4.1系统级产品开发的启动（规划） 138.4.2系统级漏洞分析 138.4.3将功能网络安全概念细化为技术网络安全概念 138.4.4规定网络安全技术要求 138.4.5系统设计 138.4.6特性集成和测试 138.4.7网络安全技术要求的验证/确认 138.4.8最终网络安全评估/网络安全案例 138.4.9最终网络安全审查 138.4.10生产放行 138.5硬件层面的产品开发 138.5.1背景 138.5.2在硬件层面启动产品开发 138.5.3硬件级漏洞分析 148.5.4硬件网络安全要求规范 148.5.5硬件网络安全设计 148.5.6硬件级集成和测试 148.5.7硬件级漏洞测试和渗透测试 148.5.8硬件网络安全要求的验证/确认 148.5.9完善网络安全评估 148.6软件层面的产品开发 148.6.1软件级产品开发的启动（规划） 148.6.2软件网络安全要求规范 148.6.3软件体系结构设计 148.6.4软件漏洞分析 148.6.5软件单元的设计和实现 148.6.6软件实现代码评审 148.6.7软件单元测试 148.6.8软件集成和测试 148.6.9软件网络安全要求的验证/确认 158.6.10软件漏洞测试和渗透测试 158.6.11完善网络安全评估 158.7生产、运营和服务 158.7.1生产 158.7.2操作、服务（维护和修理） 158.8支持过程（16） 158.8.1配置管理 158.8.2需求管理 158.8.3变更管理 158.8.4文件管理 158.8.5质量管理 158.8.6分布式开发要求（与供应商） 169.注意事项 169.1修订指标 16附录A网络安全分析技术说明 16附录B工作成果模板示例 16附录C使用已识别分析的示例 16附录D安全和隐私控制说明和应用 16附录E漏洞数据库和漏洞分类方案 16附录F车辆级别注意事项 16附录G可能对汽车行业有用的当前网络安全标准和指南 16附录H车辆项目意识 16附录I车辆行业潜在用途的安全测试工具 16

范围本推荐做法提供了有关车辆网络安全的指导，是根据行业、政府和会议文件中正在实施或报告的现有做法创建并扩展的。最佳实践旨在灵活、务实和适应性强，可进一步应用于车辆行业以及其他网络物理车辆系统（如商用和军用车辆、卡车、公共汽车）。其他专有的网络安全开发流程和标准可能已经建立，以支持特定制造商的开发流程，并且可能不会在本文件中全面体现，但是，本文件中包含的信息可能有助于完善现有的内部流程、方法等。本推荐做法为网络安全建立了一套与网络物理车辆系统相关的高级指导原则。这包括：定义一个完整的生命周期过程框架，该框架可以在每个组织的开发过程中进行定制和利用，以将网络安全从概念阶段到生产、运营、服务和废弃纳入网络物理车辆系统。提供有关设计、验证和验证网络物理车辆系统时使用的一些常见现有工具和方法的信息。为车辆系统提供网络安全的基本指导原则。为车辆网络安全方面的进一步标准开发活动奠定基础。附录提供了需要注意的额外信息，可用于帮助提高功能设计的网络安全性。附录中确定的大部分信息都是可用的，但一些专家可能不知道所有可用信息。因此，附录概述了其中一些信息，以进一步指导将网络安全构建为网络物理车辆系统。概述的目的是鼓励进行研究，以帮助改进设计，并确定应用公司内部网络安全流程的方法和工具。附录A-C-描述威胁分析和风险评估、威胁建模和漏洞分析的一些技术（如攻击树）以及何时使用这些技术。附录D-I-提供对车辆行业可用信息的了解。附录D-概述了可在设计阶段考虑的来自NISTSP800-53的网络安全和隐私控制样本。附录E-提供了一些可用漏洞数据库和漏洞分类方案的参考资料。附录F-描述车辆级别的注意事项，包括电气架构的一些良好设计实践。附录G-列出了车辆行业可能感兴趣的当前网络安全标准和指南。附录H-概述从2004年开始的车辆网络安全相关研究项目。附录I-描述了车辆行业可能感兴趣的一些现有安全测试工具。请参阅定义部分，以了解整个文档中使用的术语。1.1目的就像系统安全一样，网络安全应该被纳入设计，而不是在开发结束时添加。将网络安全构建到设计中需要从概念阶段到生产、运营、服务和废弃的适当生命周期过程。本文档提供了一个完整的生命周期流程框架，可以根据公司特定的流程进行定制。本文件中描述的过程框架类似于ISO26262《道路车辆功能安全》（1）中描述的程序框架。这两个过程是不同的，但是相关的，需要集成通信，以保持组织安全过程输出与其网络安全过程输出之间的一致性和完整性。一个组织可以自由地维护两个过程之间具有适当交互水平的独立过程，或者尝试直接集成这两个过程。本文件中描述的网络安全流程框架可以针对单个组织的应用程序（集成或单独）进行定制。1.2何时应用网络安全流程对于可能被视为网络安全关键网络物理车辆系统的系统，可以对与操作、隐私（如PII、窃听）、财务、声誉等相关的潜在威胁进行初步简短评估，并对风险进行初步估计，以确定所考虑的系统是否应遵循网络安全流程。用于确定网络安全流程适用性的威胁分析和风险评估的快速评估版本可能包括一次简短的头脑风暴和讨论会议，以考虑与该功能相关的潜在威胁，并考虑威胁的潜在风险是否足够高，以保证遵循网络安全流程。初始评估的风险评估部分可能基于经验或专家判断，而不是严格的评估过程。潜在的头脑风暴可能来自黑客聊天和会议获得的知识、以前的经验、检查表等。在确定风险时可能考虑的问题示例包括从财务、安全、隐私或操作方面对影响程度的估计，以及攻击可能涉及车队还是单车。对于潜在的安全相关车辆特征，建议对潜在的安全威胁进行初步的短期评估，以确定是否存在任何潜在的高风险安全相关威胁。如果初步评估表明可能存在高风险的安全相关威胁，则应采用网络安全程序。如果初步评估没有发现任何高风险的潜在安全相关威胁，则可能不需要对低风险的安全相关威胁应用网络安全流程；由组织决定什么是低风险，以及是否需要解决与低风险安全相关的威胁。为了确保考虑到所有潜在的安全相关威胁，网络安全专家应与安全专家进行沟通。请注意，遵循该过程的决策依据是已识别的安全相关威胁的已识别潜在风险，而不是相应的潜在危险是否为ASIL评级（a、B、C或D）。这是因为安全相关威胁的威胁风险可能较低，而相应的危险可能被评估为高ASIL；ASIL评级与与安全相关威胁相关的潜在风险之间没有直接对应关系。参考文献1.ISO26262第8部分第一版，“支持过程，道路车辆——功能安全”，11-15-2011。2.BarbaraJ.Czerny。“系统安全和系统安全工程：异同和基于ISO26262过程框架的系统安全工程过程”，SAE技术论文2013-01-1419，SAE世界大会和展览会，2013年。3.B.波特。”MicrosoftSDL威胁建模工具。载于：网络安全2009.1（2009），第15-18页。ISSN:11353-4858。DOI：/10.1016/s1353-4858（09）70008-X。网址：/science/article/pii/s135348580970008x（同上，第37页）。4.IvánArce、KathleenClarkFisher、NeilDaswani、JimDelGrosso、DannyDhillon、ChristophKern、TadayoshiKohno、CarlLandwehr、GaryMcGraw、BrookSchoenfield、MargoSeltzer、DiomidisSpinellis、IzarTarandach和JacobWest。“避免十大软件安全设计缺陷”，IEEE计算机学会，2014年。5.全球联盟，全球汽车制造商，“汽车技术和服务”，2014年11月12日。6.NIST，SP800-88，第1版，“介质消毒指南”，2014年12月。7.ISO/IEC15408“信息技术——安全技术——信息技术安全评估标准”，（3部分）。8.NIST，第1版，“改善关键基础设施网络安全的框架”，2014年2月12日。9.NISTSP800-53，第4版，“联邦信息系统和组织的安全和隐私控制”，2014年4月。10.FIPSPub199。“联邦信息和信息系统安全分类标准”，2004年2月。11.ISO（国际标准化组织）。“ISO12207——系统和软件工程——软件生命周期过程”，2008年。12.ISO（国际标准化组织）。“ISO/IEC27001:-信息技术-安全技术-信息安全管理系统-要求”。国际标准化组织。2015年1月27日。13.ISO（国际标准化组织）。“ISO/IEC27002：信息技术-安全技术。信息安全控制实施规范”2008。14.ISO（国际标准化组织）。“ISO/IEC29119：国际软件测试标准”，2014年9月10日。15.NIST800-61修订版2，“计算机安全事件处理指南”，2012年8月。16.NIST特别出版物800-30第1版，“风险评估指南”，2012年9月。17.克莱斯勒公司、福特汽车公司、通用汽车公司，QS9000第三版，“质量体系要求”，1998年10月。18.ISO/TS16949:2009“质量管理体系”，2008年12月。19.Ruddle，Alastair，Ward，David等人，EVITA项目可交付成果D2.3：“基于黑暗面场景的汽车车载网络的安全要求”1.1版，2009年12月30日。20.EVITA可交付成果D2.1：“电子安全相关用例的规范和评估”，2009年。21.伍迪，卡罗尔。“应用OCTAVE：从业者报告”，软件工程研究所，2006年5月。22.Caralli、Richard、JamesStevens、LisaYoung和WilliamWilson。“OCTAVEAllegro简介：改进信息安全风险评估过程”，软件工程研究所，2007年5月。23.M.Islam等人，可交付D2安全模型。HEAVENS项目，可交付成果D2，第1版。2014年12月。24.ISO（国际标准化组织）。道路车辆.功能安全ISO26262:2011。（同上，第17、30、40、42、44页）。25.BSI标准100-4，2009年第1.0版，德国联邦信息安全局（BSI）。26.汽车工业行动小组，“潜在故障模式和影响分析”，2008年。27.“隐私影响评估指南”，2011年，德国联邦信息安全办公室（BSI）。28.ISO（国际标准化组织）。道路车辆.功能安全.第3部分：概念阶段（ISO26262-3-2011）。ISO26262-3:2011。2011年（引用第18页）。29.Schneier，Bruce，“秘密与谎言——网络世界中的数字安全”，Wiley，ISBN978-0-471-45380-2。30.AmerAijaz1、BerndBochow2、FlorianD¨otzer3、AndreasFestag4、MatthiasGerlach2、RainerKroh5和TimLeinm¨uller5，“对车车间通信系统的攻击——分析”。31.rmatik.uni-erlangen.de/~dulz/fkom/06/Material/11/Security/NOW_TechReport_Attacks_on_Inter_Vehicle_Communications.pdf。32.AvizienisA，LaprieJ-C，RandellB，LanwehrC，“可靠和安全计算的基本概念和分类法”，IEEE独立和安全计算汇刊。2004年1月至3月。33.MITRE公司，“常见弱点枚举，社区开发的软件弱点类型词典”，2006-2014，/.34.MITRE公司，“常见漏洞和暴露”，1999-2014，/cve/index.html.35.安全焦点，“BugTraq”，2010，/archive.36.NIST，“国家漏洞数据库”，/.37.MITRE公司，“共同弱点评分系统”，2006-2014年，/cwss/cwss_v1.0.1.html.38.NIST，“通用漏洞评分系统”，/cvss.cfm.3.定义和缩写词3.1API应用程序编程接口3.2ASF-应用程序安全框架（ApplicationSecurityFrame）基于系统分解方法确定威胁的威胁分类工具。3.3ASIL-汽车安全完整性等级（AutomotiveSafetyIntegrityLevel）ISO26262中的一种危害分级方法。3.4攻击潜力（ATTACKPOTENTIAL）成功实施潜在攻击的可能性。3.5攻击面未经授权的用户（“攻击者”）可以尝试向环境输入数据或从环境中提取数据的不同点（“攻击向量”）。3.6攻击树分析（ATA）一种分析方法，用于确定攻击者通过系统可能导致顶级威胁的潜在路径。3.7黑匣子测试在对所测试的系统一无所知的情况下进行测试。测试期间未提供任何规范、硬件信息、软件代码等。3.8CAN-控制器局域网一种串行通信网络。以下标准提供了与CAN协议及其某些汽车变体相关的细节：SAEJ1939、SAEJ2411、ISO11898、ISO15765-2。3.9C认证C、C++、Java和Pearl的安全编码标准。由CERT编码倡议团队开发。3.10CPU-中央处理器计算机系统（微控制器）中执行计算机主要功能并控制系统各部分的部分。3.11常见漏洞枚举（CVE™)CVE旨在允许漏洞数据库和其他功能链接在一起，并促进安全工具和服务的比较。3.12通用漏洞评分系统（CVSS）漏洞评分系统。3.13常见弱点列举（CWE™)CWE是由MITRE合作主办的“软件弱点类型的正式列表”。3.14常见弱点评分系统™是一种评分系统，可以帮助与软件安全相关的利益相关者评估报告的软件弱点，并在适用的情况下确定其优先级。3.15网络攻击源自智能行为的对系统网络安全的攻击，即故意试图（特别是在方法或技术的意义上）逃避网络安全服务并违反系统网络安全政策的智能行为。3.16网络物理系统（CPS）一种协作计算元素控制物理实体的系统。3.17网络物理车辆系统（CPAS）车辆嵌入式控制系统，其中在系统的计算元件和物理元件以及系统周围的环境之间存在紧密耦合。3.18网络安全为保护网络物理系统免受未经授权的访问或攻击而采取的措施。3.19网络安全评估对某个功能的网络安全水平的评估，将在整个开发过程中进行完善，并提供适当的论据和证据来支持每个开发阶段的网络安全声明。网络安全评估在每个主要里程碑进行审查。3.20网络安全案例在完成所有里程碑式审查之后，在功能发布用于生产之前，进行最终的网络安全评估。网络安全案例提供了最终论证和证据，证明设计和开发的功能满足其网络安全目标。3.21网络安全概念在概念阶段开发，用于描述该功能的高级网络安全策略。在系统级别的产品开发过程中，网络安全概念将细化为技术网络安全概念。3.22网络安全控制为消除潜在漏洞或降低漏洞被利用的可能性而为功能规定的管理、操作和技术控制（如保障措施或对策）。3.23网络安全至关重要由于系统中的漏洞可能被外部实体直接或间接利用，网络物理系统可能会发生损失的系统。3.24网络安全目标根据威胁分析和风险评估结果确定的功能实现网络安全的目标。这些是最高级别的网络安全要求，将推动功能和技术网络安全要求的发展和完善。3.25网络安全机制技术网络安全控制添加到该功能中，以消除潜在的漏洞或降低漏洞被利用的可能性。3.26网络安全潜力某件事可能发生的风险或可能性的程度。3.27网络安全计划定义了规划和监督网络安全活动的职责。3.28网络安全审查审查，可能由一个技术审查小组进行，以评估工作产品在开发过程的各个阶段的技术方面。3.29DIS国际标准草案3.30DOD国防部3.31DREAD-损伤再现性可利用性受影响的用户和可发现性基于系统分解方法确定威胁的威胁分类工具。3.32DVD-数字视频光盘一种具有高信息存储容量的设备。3.33ECU-电子控制单元为车辆提供功能的模块。3.34以太网一种串行通信网络。3.35ETSI欧洲电信标准协会3.36EVITA-电子安全车辆入侵保护应用欧洲共同体于2007年至2013年发起的一个项目。主要用于设计、验证和原型车辆车载网络的网络安全构建块。3.37特性用于在车辆级别实现功能的系统或系统阵列，其中应用了网络物理车辆系统的网络安全过程。3.38故障树分析（FTA）一种演绎分析技术，从顶级危险开始，向下确定可能导致危险发生的潜在单点和多点故障组合。3.39FLEXRAY一种串行通信网络。3.40模糊测试一种可用于发现潜在安全缺陷的软件测试技术。3.41灰箱测试在已知有关正在测试的功能的部分信息的情况下进行测试。例如，提供了一些功能规范，但没有提供产品源代码。因此，仍然需要一些特别的方法来尝试确定漏洞。3.42GPS全球定位系统，用于导航。3.43黑客从利益相关者的角度来看，非法试图访问或获得系统访问权限，意图获得某些东西或造成损失的人；例如，名声、金融、恐怖袭击。3.44黑客聊天在线博客或会议等，黑客在其中就他们试图做的事情进行对话。3.45黑客入侵未经授权的访问。3.46HAZOP在功能安全的背景下，危险和可操作性分析是一种结构化和系统化的技术，用于识别特征的潜在危险；该方法使用引导词和头脑风暴来尝试识别潜在的危险。3.47天堂消除漏洞以增强软件安全性3.48HMI人机界面3.49HSM-硬件安全模块一种物理计算设备，用于保护和管理数字密钥以进行强身份验证并提供加密处理。3.50公顷硬件模块3.51IEC-国际电工委员会组编写行业标准。3.52事件对系统的攻击可能已经成功，也可能没有成功。3.53ISAC-信息共享和分析中心安全相关信息的中央存储库。该组织的目的是在所有成员之间共享每个组织关于网络安全攻击和漏洞的信息。3.54ISO/TS国际标准化组织/技术规范3.55I/O输入/输出3.56信息技术资源管理活动。4.系统安全与系统网络安全的关系系统安全（超出监管要求）是指系统不会对生命、财产或环境造成危害的状态。系统网络安全是指系统不允许利用漏洞导致损失的状态，如财务、运营、隐私或安全损失。安全关键系统是指如果系统不按预期或期望运行，可能会对生命、财产或环境造成危害的系统。网络安全关键系统是指如果系统因系统中可能存在的漏洞而受到损害，则可能导致财务、操作、隐私或安全损失的系统。所有安全关键系统都是网络安全关键系统，因为直接或间接对安全关键系统的网络攻击可能导致潜在的安全损失（图1）。并非所有的网络安全关键系统都是安全关键的，因为对网络安全关键的系统的网络攻击可能导致安全损失以外的损失；即隐私、运营或财务。这两个领域也有关联，因为系统安全工程的要素和系统网络安全工程的元素之间存在一些重叠，但这两个工程学科之间的要素并不相同（图2）。非安全关键的网络安全关键系统的一个例子是从驾驶员那里获取个人信息的娱乐系统。如果该系统受到损害，可能会给驾驶员带来经济或隐私损失，但很可能不会对驾驶员造成身体伤害；因此，该系统是网络安全关键的，但不是安全关键的。一个既具有网络安全关键性又具有安全关键性的系统示例是转向辅助系统。转向辅助系统是安全关键，因为如果它表现出故障行为，可能会对车辆乘员造成潜在伤害。转向辅助系统也是网络安全的关键，因为如果系统被攻击者破坏，并注入恶意的故意转向动作，也可能对车辆乘员造成潜在伤害；在网络安全中，这将被分析为潜在的安全损失。4.1系统安全与系统网络安全工程的类比4.2系统安全和系统网络安全的独特方面5.网络物理车辆系统（CPS）的网络安全指导原则本节介绍的网络安全指导原则适用于汽车行业的各种公司。由于每家公司都可能有自己的内部流程来管理其产品开发，因此本推荐做法提供了一套可供公司内任何组织应用的网络安全指导原则。以下指导原则是根据微软的安全开发生命周期（SDL）指导原则（3）和IEEE的避免十大软件安全设计缺陷（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显示了网络物理车辆系统的总体网络安全工程流程框架，该框架考虑了从概念阶段到生产、运营和服务的整个生命周期。图中所示的生命周期类似于ISO26262道路车辆功能安全标准（1）中的过程框架。选择这种类似的生命周期是为了允许具有基于ISO26262的安全流程的组织使用网络安全和安全之间的通用框架来促进：利用网络安全和安全共同的组织现有安全流程的各个方面，例如支持流程程序和模板，开发量身定制的网络安全流程，鉴于网络安全和安全这两个领域之间的相互关系，保持两者之间的一致性。流程框架包括网络安全管理、核心网络安全工程活动和支持流程。核心网络安全工程活动包括概念阶段活动、系统、硬件和软件级别的产品开发活动以及生产、运营和维护活动。支持过程活动包括适用于不同生命周期阶段的活动，如配置管理、变更管理等。6.2.1网络安全综合管理网络安全管理包括两个方面：（1）网络安全的综合管理；以及2.）在开发生命周期的特定阶段内管理网络安全活动。网络安全整体管理的一部分包括：创建、培养和维持网络安全文化，支持和鼓励在组织内有效实现网络安全，建立方法以帮助确保遵守已采用的网络安全工程流程，识别和建立网络安全方面所需的内部和外部沟通渠道，开发和实施培训和指导，以提高网络物理车辆系统的网络安全能力，纳入扩展的现场监控流程，包括监控黑客聊天（包括可能发生潜在攻击/漏洞对话的在线和会议）、报告未成功的攻击等。，纳入事件响应流程非常重要，应包括攻击事件报告程序以及攻击事件调查、解决和行动程。图3-总体网络安全流程框架在概念阶段，网络安全活动的管理可能包括指派一名网络安全经理来监督网络安全活动，并负责规划和监督网络安全行动，包括制定网络安全计划。在产品开发过程中，网络安全活动的管理可能包括：开始初步网络安全评估，该评估将在整个开发过程中进行完善，并在主要里程碑进行审查，最终形成最终网络安全评估（网络安全案例），识别并监督审查，以确认适当的活动得到了正确执行。任何与网络安全有关的未决问题都将被记录下来，并说明适当的后续行动。如果先前的网络安全评估中包含公开的网络安全问题，则应在更新的评估中解决这些问题。网络安全问题的最终评估是网络安全案例。在网络安全案件中，任何公开的网络安全问题都将得到解决，或者将包括一个理由，说明为什么公开的问题是可以接受的，并提供支持这些说法的最终论据和证据。6.2.2概念阶段图4显示了概念阶段的活动流程。功能定义活动是定义正在开发的功能，包括确定边界和网络安全边界，以及确定外部依赖项和资产。定义该功能阐明了未来分析活动的边界和范围。定义明确的范围有助于绑定未来的分析活动，以便更高效、更有效地完成分析。网络安全生命周期的启动包括制定网络安全计划计划，该计划描述了作为网络安全生命期一部分要开展的活动。威胁分析和风险评估（TARA）活动用于识别和评估系统的潜在威胁，并确定与每个已识别威胁相关的风险。TARA的结果将推动未来的分析活动，将未来的分析重点放在风险最高的网络安全威胁上。网络安全目标是针对风险最高的潜在威胁确定的。在最高级别上，网络安全目标可能与潜在威胁相反；例如，如果潜在威胁是恶意制动，则最高级别的网络安全目标可能是防止或降低恶意制动发生的可能性，或减轻恶意制动的潜在后果。一旦确定了最高级别威胁的网络安全目标，就可以制定网络安全概念来描述该功能的高级网络安全策略。从网络安全概念和网络安全目标中，可以确定并推导出高级别的网络安全要求。然后可以在产品开发阶段进一步完善这些高级网络安全要求。在概念阶段结束时，可以进行初步的网络安全评估，以评估为该功能提出的网络安全状态。图4-概念阶段活动6.2.3产品开发生命周期的产品开发阶段包括系统级的产品开发、硬件级的产品研发和软件级的产品研制。图5显示了产品开发阶段的概述，以及系统级设计阶段的产品开发与硬件和软件级的产品开发之间的关系。注：迭代发生在生命周期的许多阶段；然而，没有描述这些迭代以避免使图过于复杂。图5-系统、硬件和软件级别的产品开发之间的关系产品开发：系统级产品开发：硬件级产品开发：软件级6.2.4生产、操作和服务生产阶段的活动包括与可能影响生产过程的任何网络安全相关要求有关的生产计划，包括与确保生产过程特定部分安全有关的要求。与网络安全相关的生产要求可能包含在现有的生产计划中。系统的网络安全要求可能会影响在制造设施中将软件闪存到ECU上的特定过程，例如要求用于闪存的工具是安全的。操作阶段包括操作和服务。服务包括正常的维护活动和维修。操作过程中任何特定于网络安全的要求都应记录在适当的文件中（如车主操作手册）。关于服务，任何可能对网络安全产生不利影响的维护和修复活动都应在生命周期的早期阶段确定，并应规定在维护和修复期间如何维护网络安全的适当程序；例如，维护程序和维修程序。可能影响网络安全的服务包括重新闪烁ECU、连接车载诊断端口、远程信息处理系统更新、车辆/云计算接口等。操作阶段还包括执行和维护网络安全活动总体管理中定义和建立的现场监控流程，以及执行网络安全活动整体管理中定义并建立的事件响应程序。6.2.5支持流程一些支持过程活动应与作为系统安全工程过程一部分应用的活动相同，以符合ISO26262。建议将这些流程集成到公司现有的产品开发流程中。其中包括：配置管理、文档管理、变更管理等。ISO26262中使用的其他支持流程活动可以针对网络安全进行定制。其中包括：网络安全要求的管理、处理分布式开发的要求等。分布式开发要求旨在帮助确保以下内容：供应商有能力根据客户组织内部网络安全流程开发和生产网络安全关键功能，在供应商和客户之间建立并维护适当的沟通渠道，同意网络安全工作产品，在客户访问工作产品的关键里程碑建立适当的审查，评估并同意任何可能影响网络安全的变更，审查并同意最终的网络安全案件，及时向客户报告供应商可能意识到的任何网络安全问题等。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.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硬件级漏洞测试和渗透测试