声明

本文是学习GB-T 38628-2020 信息安全技术 汽车电子系统网络安全指南. 下载地址 http://github5.com/view/764而整理的学习笔记,分享出来希望更多人受益,如果存在侵权请及时联系我们

汽车电子系统网络安全活动

7.1 概念设计阶段

7.1.1 概述

概念设计阶段的活动流程如图4所示包括系统功能定义、网络安全过程启动、风险评估与目标确定、网络安全策略设计、网络安全需求识别、初始网络安全评估及概念设计阶段检查等。

1. 概念设计阶段活动流程

7.1.2 系统功能定义

组织宜明确汽车电子系统中被开发的、可以实施网络安全的子系统及其功能的适用范围并对其进行如下内容的分析

a) 子系统的物理边界

b) 子系统的网络边界

c) 子系统的信任边界

d) 子系统的网络安全边界。

7.1.3 网络安全过程启动

在启动汽车电子系统的网络安全生命周期过程时组织宜制定相应的网络安全计划包括但不限于以下内容

a) 需要执行的网络安全活动

b) 确定各项活动的负责人

c) 明确各项活动的开始时间和截止时间

d) 明确各项活动状态的报告和监督规则。

7.1.4 威胁分析及风险评估

组织宜对汽车电子系统开展威胁分析及风险评估以便系统性地识别汽车电子系统可能面临的网络安全威胁并对网络安全风险进行合理的估算为确定汽车电子系统的网络安全目标、采取相应的风险处置措施提供依据。掌握威胁分析及风险评估的技术在产品的早期开发阶段实施能够尽量降低在产品生命周期较晚阶段发现问题而导致的昂贵修复代价另外随着产品开发过程的不断深入威胁分析及风险评估活动还可以适时地针对产品的逐步细化而不断地迭代为产品各开发阶段的网络安全评估提供依据。

汽车电子系统的威胁分析及风险评估活动宜按照GB/T 18336—2015、GB/T 20984—2015、GB/T 31509—2015和GB/T 31722—2015等标准内容并结合汽车行业的实践经验开展主要可包括以下步骤

a) 准备确定威胁分析及风险评估的目标与范围。

b) 功能定义识别汽车电子系统主要功能和需要被保护的资产。

示例汽车电子系统需要保护的资产可主要从以下方面考虑

——车载设备包括ECU、传感器、执行器、网络通信设备等

——运行于在设备上的功能安全关键和非功能安全关键的应用

——ECU内部、ECU之间、ECU和传感器/执行器之间、ECU和网络通信设备及应用程序之间的数据链路。

c) 威胁分析识别来自组织外部或内部各种渠道的、针对汽车电子系统资产的潜在威胁并进行分析可包括如下内容威胁模型、系统功能用例分析、数据流/控制流分析、安全边界分析、攻击树分析等。组织可综合应用各种分析技术形成规范化的分析流程。在威胁分析过程中需要综合考虑威胁来源、威胁动机或攻击动机等因素对威胁进行合理的分类。

示例针对汽车电子系统的攻击动机可能是获取车辆信息获取驾驶员信息对驾驶员、乘客等个人身体和精神造成伤害扰乱行业经济或造成大规模基础设施损坏恐怖袭击使攻击者获得声誉获取经济利益获取其他利益。

注一种常用的分类方法是将威胁分为仿冒、篡改、抵赖、信息泄露、拒绝服务、特权提升等几种类型。

d) 脆弱性分析分析针对汽车电子系统资产可能的攻击途径和漏洞其目标是基于汽车电子系统的具体实现识别其中的薄弱环节或缺陷以便对风险评估提供依据。可参考通用的信息系统脆弱性数据库针对已发现的脆弱性对汽车电子系统的实现进行分析或开展渗透测试检验相关脆弱性是否真的存在。另外组织还需要建立或参考本行业相关机构所建立的专业性脆弱性或漏洞数据库以便针对汽车电子系统进行特定的脆弱性分析。

e) 风险评估基于威胁和脆弱性分析的结果主要从两个方面对风险等级进行估算一是威胁可能造成影响的严重程度二是威胁成功实施攻击的概率。综合这两方面的评估数据对每个具体的资产威胁明确其风险等级。

注1有关汽车电子系统典型网络安全风险参见附录A。

注2对于威胁可能造成结果的严重程度可从对汽车的功能安全、隐私、经济、操控性等方面的影响进行综合分析对于威胁成功实施攻击的概率可综合考虑多方面因素包括攻击所需要花费的时间包括识别漏洞、开发攻击程序、成功安装程序等的时间、专业知识、对被攻击对象的了解程度、机会的时间窗口和对特殊设备的要求等。

f) 风险处置根据风险等级对资产威胁进行优先级排序尤其需要识别出高风险等级的威胁并评估各个资产威胁的风险等级是否处于可接受的水平如果风险等级属于不可接受的宜考虑应用适当的方法或风险控制措施使系统的残余风险降低到可接受的范围。

示例1

针对附录A中所描述的ECU“CAN总线访问”可能面临的网络安全风险可采取的风险控制措施是提供CAN总线的安全通信功能软件实现通信数据的防篡改、抗重放机制。

示例2

针对附录A中所描述的车载网关“FOTA/SOTA”可能面临的网络安全风险可采取的风险控制措施是实现安全的FOTA/SOTA过程防止车载网关固件/软件或数据在其更新过程中被仿冒、篡改或信息泄露。

示例3

针对附录A中所描述的车载接入设备USB接口可能被非授权访问的网络安全风险可采取的风险控制措施是对USB接口实施安全访问控制并通过安全日志对访问事件进行记录以便及时发现可能出现的非授权访问。

7.1.5 网络安全目标确定

组织宜基于风险评估结果中识别的高风险威胁尤其是最高风险威胁来确定网络安全目标。

示例1

针对车辆与外部环境的4G通信攻击者可能会嗅探4G信号中的数据流这将影响车辆外部通信数据的机密性可能导致敏感信息的泄露。因此相应的网络安全目标是保证车辆外部4G通信数据的机密性需要采取加密通信数据的措施。

示例2

攻击者基于读取的4G通信数据信息可能攻击车辆系统的其他部分比如篡改发送给车内网关的远程控制指令导致更为严重的安全事故。相比前一种情况该威胁的风险程度更高相应的网络安全目标则是防止车辆的远程控制指令被篡改保证数据的完整性需要采取的措施是针对关键数据信息进行完整性校验。

7.1.6 网络安全策略设计

组织宜确定满足网络安全目标所需的策略包括但不限于

a) 每个网络安全目标所对应的风险

b) 满足网络安全目标的、可行的策略

c) 针对不同类别的威胁制定网络安全策略设计说明。

7.1.7 网络安全需求识别

组织宜从确定的网络安全目标中提取和识别网络安全需求或者通过对网络安全策略的细化定义具体的网络安全需求。

7.1.8 初始网络安全评估

组织宜开展初始网络安全评估主要用于描述当前阶段系统功能对于网络安全的各项要求形成的初始评估报告内容可包括但不限于

a) 通过风险评估所确定的所有网络安全目标

b) 每个网络安全目标所对应的风险

c) 在当前阶段的所有网络安全未决问题。

7.1.9 概念设计阶段检查

组织宜在概念设计阶段活动完成时进行阶段检查以确保概念阶段所有活动均已完成并产生适宜的输出主要检查以下内容

a) 网络安全计划

b) 系统功能定义

c) 风险评估结果

d) 网络安全目标

e) 网络安全策略设计

f) 网络安全需求

g) 初始网络安全评估结论。

7.2 系统层面产品开发阶段

7.2.1 过程步骤概述

图5展示了系统层面产品开发过程的V型图。

1. 系统层面产品开发过程

在系统层面产品开发启动之后进入网络安全技术需求定义环节包括如下活动执行系统层面的威胁分析或漏洞分析将网络安全策略具体化为网络安全技术策略例如将高层的网络安全策略采用具体的工程术语进行描述再进一步导出并细化网络安全技术需求。

在系统设计环节可以创建系统上下文来定义系统硬件和软件之间的接口、关键的数据流和它们在系统中的存储和处理过程。使用系统上下文系统层面产品的网络安全技术需求被分配到硬件和/或软件中。一旦完成这个步骤就能够开始硬件层面产品开发和软件层面产品开发的活动了。

在完成硬件和软件层面的产品开发之后进行硬件和软件的集成与测试重点是针对系统的网络安全测试可以采用漏洞测试、渗透测试等具体的测试方法。基于集成测试的结果验证网络安全技术需求是否得到满足之后针对系统进行网络安全评估最后是产品的正式发布。

7.2.2 系统层面产品开发启动

组织宜针对系统层面产品开发启动网络安全活动具体可包括

a) 制定系统层面产品开发的计划并明确其中的网络安全相关内容与要求

b) 成立网络安全小组具体负责产品开发过程中网络安全相关的技术及管理方面的工作确定小组的关键成员与职责。

7.2.3 系统层面漏洞分析

宜由网络安全小组对系统的潜在威胁展开漏洞分析找到系统被攻击可能性较高的区域可包括以下步骤

a) 将系统内的资产进行分类并按重要性和价值对各类资产进行综合评级宜按照GB/T 30279—2013的内容进行安全漏洞等级划分

b) 找到评级较高的资产中的漏洞和威胁

c) 设计修补漏洞、对抗威胁的具体措施。

注1相比概念设计阶段在系统层面阶段会有更多的细节信息出现因此有必要开展系统层面的漏洞分析

注2分析过程中宜进行充分沟通以确保系统的网络安全需求能够被充分定义和管理。

7.2.4 网络安全策略具体化

组织宜将概念设计阶段的网络安全策略具体化为网络安全技术策略主要针对系统中网络安全风险较高的部分在系统层面定义能够保护其功能和数据的网络安全设计。

7.2.5 确定网络安全技术需求

组织宜结合实际情况进一步确定网络安全技术需求可包括以下步骤

a) 建立系统的功能列表确定每一项功能的类别

b) 建立系统上下文

c) 定义系统接口包括软件硬件的接口、数据流、数据存储和数据处理的要求

d) 通过功能列表和系统接口逐项确定可以实现的功能并确定其满足系统上下文的技术需求。

7.2.6 系统设计

组织开展系统设计时宜遵循已制定的过程、工具使用及具体流程要求设计能满足其功能需求和网络安全需求的系统。

7.2.7 系统集成和测试

在系统功能的集成和测试工作中组织可通过测试确认如下内容

a) 子系统之间的通信是否正确以及子系统之间通信的网络安全需求是否得到满足

示例1

对于车体控制电子系统中各个ECU、传感器、执行器之间的通信需要确认车辆内部总线比如CAN总线、以太网上通信的网络安全包括每条总线上通信的安全以及通过网关进行连接的不同总线之间通信的安全主要测试并确认通信数据的完整性、合法性及抗重放等机制。

示例2

对于车载服务电子系统包括各种车载接入设备如IVI、T-BOX等与外部环境比如后台服务器之间通信的网络安全主要测试并确认通信数据的机密性、完整性及真实性。

b) 系统是否可以针对威胁实施相应的对抗措施

c) 进行整车级的系统集成与测试以便确认所有的系统功能可以正确地协同工作并满足整车级网络安全需求。

7.2.8 网络安全验证

为确保所应用的安全技术能够满足系统的网络安全技术需求组织宜通过独立的网络安全测评团队对其有效性程度进行验证可采用的验证方法包括

a) 漏洞测试确定用于降低漏洞风险的系统需求已被实现

b) 渗透测试通过模拟对系统的实战攻击验证系统能够有效地实施相应的安全措施

c) 模糊测试通过大量的数据或信号对系统功能进行压力测试判断系统是否会在设定的情况下产生漏洞或出现异常的行为

d) 使用其他测试方法或工具进行的检验与验证。

7.2.9 系统层面网络安全评估

在完成网络安全验证之后组织宜通过独立的网络安全测评团队进行网络安全评估生成网络安全状况说明对系统的网络安全状态进行评判。主要内容包括

a) 产品各阶段的网络安全需求是否都得到了满足

b) 产品开发过程中的未决问题是否被妥善处理

c) 对于未被处理的网络安全问题提供解释性文件说明可以接受此网络安全问题的原因。

7.2.10 系统层面产品开发阶段检查

组织在产品发布前宜通过独立的技术专家小组进行系统层面产品开发阶段检查其目的主要在于对本阶段各项活动及其输出内容的完整性、一致性和正确性进行再次检查确认。具体的检查内容可包括但不限于

a) 确认系统层面漏洞分析及其结果的正确性和完整性

b) 确认网络安全技术策略、对概念阶段网络安全策略设计的具体化过程的完整性、一致性和正确性

c) 确认网络安全技术需求、网络安全技术策略和对概念阶段网络安全需求的细化过程的完整性、一致性和正确性

d) 确认系统的功能集成过程、集成测试过程和测试结果的完整性、一致性和正确性

e) 确认漏洞和渗透测试过程以及测试结果的完整性、一致性和正确性

f) 确认网络安全需求的有效性检验和验证过程的完整性、一致性和正确性

g) 确认网络安全状况说明及系统层面网络安全评估过程的完整性、一致性和正确性。

7.2.11 产品发布

通过网络安全评估及检查后产品可进入到发布阶段这一阶段的安全活动可包括

a) 制定产品正式投入生产阶段的网络安全相关计划

b) 制定车辆所有权变更和寿命终止时的网络安全相关计划。

7.3 硬件层面产品开发阶段

7.3.1 概述

图6展示了硬件层面产品开发过程及其与系统层面产品开发关系的V型图。

1. 硬件层面产品开发过程

硬件层面网络安全需求宜从系统层面产品开发阶段分配给硬件的网络安全需求中导出并在硬件层面产品开发过程中进一步细化。组织需要进行硬件的漏洞分析以帮助识别潜在的漏洞和所需要的网络安全控制措施这些控制措施能够覆盖所识别出来的潜在漏洞。在硬件集成及其功能测试之后可将漏洞测试和渗透测试应用于硬件设计并进行硬件层面网络安全需求的验证和评估在此初始的网络安全评估会被进一步细化。

7.3.2 硬件层面产品开发启动

组织宜针对硬件层面产品开发启动网络安全活动具体可包括

a) 确定所有与硬件相关的网络安全需求包括功能安全、隐私、财务、业务、法律和法规等方面

b) 定义网络安全与硬件/软件和功能安全之间的关系

c) 确定硬件网络安全测试和评估的范围。

7.3.3 硬件层面漏洞分析

组织宜开展硬件层面漏洞分析以便识别、量化其网络安全风险并进行优先级排序。

示例针对汽车电子系统硬件漏洞的具体分析方面可包括但不限于

a) ECU硬件本身是否存在设计上的缺陷或者漏洞比如缺乏防信号干扰、防逆向分析等机制导致其易受到相应的攻击而信息泄露。

b) 用于调试的JTAG接口是否在最终硬件产品中移除如果未移除是否采取了相应的访问控制措施比如在非调试状态下关闭该接口。如果该接口被非法访问可能导致恶意程序被植入系统。

c) 用于车辆诊断的OBD接口是否对该接口采取了相应的访问控制措施。OBD接口如果被非法利用非授权设备可能通过未受保护的OBD总线与汽车网关通信读取网关内的敏感数据甚至直接读写车内总线发送伪造控制信息严重干扰汽车正常功能。

d) 串口、USB以及各种无线通信接口是否采取了相应的访问控制措施。未受保护的接口访问可能导致访问者身份被仿冒、数据泄露、访问数据被篡改等风险。

7.3.4 确定网络安全需求

组织宜结合实际情况进一步确定硬件层面的网络安全需求可包括如下内容

a) 检查并根据需要更新系统上下文

b) 明确硬件是如何支持整个系统所需要实现的网络安全目标和任务的

c) 定义其他方面的约束包括组织内部或外部的威胁、法律法规要求和成本约束等。

7.3.5 硬件设计

组织宜对硬件层面的网络安全进行设计满足设计层级安全要求具体包括系统设计方案、硬件组件选型、安全组件、实施如PCB布局和配置安全漏洞如调试端口安全配置等这些漏洞并非孤立存在而是相互影响的因此硬件设计漏洞宜从系统层级综合考虑分析。

示例1

为ECU硬件设计防信号干扰、防逆向分析等机制。

示例2

用于调试的JTAG接口在最终硬件产品中移除该接口或者设计相应的访问控制措施比如在非调试状态下关闭该接口。

示例3

针对OBD接口采取相应的访问控制措施防止OBD接口被非法利用。

示例4

针对串口、USB以及各种无线通信接口根据各种接口的不同特点设计相应的访问控制措施保护对这些接口的访问。

7.3.6 硬件集成和测试

组织宜对集成后的硬件进行网络安全测试可包括

a) 进行漏洞测试以验证已知或潜在的漏洞是否已被修复

b) 进行渗透测试模拟攻击者绕过网络安全控制措施并取得系统控制权的行为以验证硬件设计是否可以抵御此类威胁

c) 测试宜由具备相应资质的、独立的测评团队来进行。

7.3.7 网络安全验证

组织宜对硬件层面网络安全需求的有效性进行检验和验证以确定硬件设计是否能产生符合需求所预期的效果。该验证活动宜由独立的网络安全测评团队进行。

7.3.8 细化网络安全评估

组织宜通过独立的网络安全测评团队开展本阶段细化的网络安全评估活动主要评估先前的未决问题可包括以下步骤

a) 评估未决问题是否已得到解决如果尚未解决则进入下一步

b) 根据硬件层面产品开发的情况决定是否接受该问题。如果接受则需要提供解释性文件说明可以接受此网络安全问题的原因如果不接受则继续标识为未决问题以便在后续的产品开发过程中进行处理。

7.3.9 硬件层面产品开发阶段检查

组织在硬件层面产品开发阶段最后宜通过独立的技术专家小组参照6.5节内容进行阶段检查。

7.4 软件层面产品开发阶段

7.4.1 概述

图7展示了软件层面产品开发过程及其与系统层面产品开发关系的V型图。

1. 软件层面产品开发过程

软件层面网络安全需求宜从系统层面产品开发阶段分配给软件的网络安全需求中导出并在软件层面产品开发过程中进一步细化。软件架构设计之后进行漏洞分析以帮助识别潜在的设计漏洞和所需要的网络安全控制措施这些控制措施能够覆盖所识别出来的潜在漏洞。在软件单元设计和实现之后还可以进行软件单元设计及实现层面的漏洞分析之后进行软件单元测试、软件集成和网络安全测试。为了验证软件的网络安全需求可应用漏洞测试和渗透测试等方法。最后进行网络安全评估之前的网络安全评估会被进一步细化。

7.4.2 软件层面产品开发启动

组织宜针对软件层面产品开发启动网络安全活动具体可包括但不限于

a) 为软件生命期的各阶段进行计划、调度和分配资源

b) 定义可被重用的软件组件并明确为满足网络安全功能所需要的质量活动

c) 确定软件开发过程的支持工具定义工具的可信级别、参考手册和指导教程

d) 选择适宜的软件开发方法

e) 选择程序设计语言和建模语言

f) 计划软件的集成和测试过程要求尤其是网络安全测试的过程与要求。

7.4.3 确定网络安全需求

组织宜结合实际情况进一步确定网络安全需求具体可包括如下内容

a) 检查并根据需要更新系统上下文

b) 明确软件是如何支持整个系统所需要实现的网络安全目标和任务的

c) 定义与网络安全相关的软件非功能性参数如性能要求、存储空间需求、可靠性要求等

d) 定义软件开发其他方面的约束包括组织内部或外部的威胁、法律法规要求和成本约束等。

7.4.4 软件架构设计

组织宜注重从安全方面考虑软件架构设计可包括不限于如下内容

a) 保持数据的机密性、完整性和可用性的设计

b) 采用分区的软件架构和隔离技术保障软件层面的安全

c) 提供错误检测和错误恢复功能

d) 提供日志和审计功能。

7.4.5 软件层面漏洞分析

组织宜基于软件的架构设计进行漏洞分析并建立威胁模型具体可包括以下步骤

a) 分析系统功能用例

b) 基于软件架构设计针对给定的系统功能用例导出软件的数据/控制流图

c) 确定软件的信任边界给予通过信任边界的数据或控制特别的关注

d) 构建攻击树

e) 基于数据/控制流图和攻击树进行软件的威胁分析对威胁进行分类并排序

注一种常用的分类方法是将威胁分为仿冒、篡改、抵赖、信息泄露、拒绝服务、特权提升等几种类型。

f) 确定所需的软件网络安全控制根据情况可选择降低或缓解风险、接受风险、揭示风险例如使用告警标签或消除风险。

7.4.6 软件单元设计和实现

组织开展软件单元设计和实现过程可参考行业内的相关规范如MISRA C、CERT C等建立软件编程规范网络安全方面可包括但不限于如下内容

a) 对输入信息和数据进行有效性验证

b) 使用安全的字符串禁止对已过时或废弃的API的调用禁止使用非安全的函数

c) 禁止使用没有长度限制的字符串或数组可能导致缓冲区溢出

d) 使用静态和动态的代码分析方法识别可能存在的软件漏洞。

7.4.7 软件实现的分析与评估

组织在软件实现的分析与评估过程中可开展的网络安全活动包括但不限于

a) 对代码和数据结构进行分析以便查找可能对系统造成或引入的漏洞和风险

b) 评估可能由开发工具引入的风险

c) 评估函数、类、模块等软件单元之间数据传输的一致性

d) 分析第三方软件库的脆弱性。

7.4.8 软件单元测试

组织开展软件单元测试过程中宜遵循以下要求

a) 从软件的最下层开始对所有软件单元开展测试包括测试软件的输入、输出、数据流/关键路径、边界条件、错误处理、异常处理、故障和恢复处理等

b) 考虑与安全有关的测试内容

c) 一旦有软件单元未通过测试则立即采取纠正措施并在软件单元修改后进行回归测试以确保修改的软件单元不会对其他单元产生不利影响包括安全方面的影响。

7.4.9 软件集成和测试

软件集成完成后组织宜检验相应的网络安全需求是否得到满足包括如下内容

a) 对所有的数据接入点例如无线接口、以太网接口、USB接口和CAN接口等进行模糊测试

b) 进行渗透测试和漏洞测试可由独立的内部团队或外部第三方团队实施

c) 记录测试结果和剩余风险

d) 制定处理剩余风险的行动计划

e) 编写软件的操作指南。

7.4.10 网络安全验证

组织宜基于软件测试的结果以及其他相关信息对软件层面网络安全需求的有效性进行检验和验证。该验证活动宜由独立的网络安全测评团队进行。

7.4.11 细化网络安全评估

组织宜通过独立的网络安全测评团队开展本阶段细化的网络安全评估活动主要评估先前的未决问题可包括以下步骤

a) 评估未决问题是否已得到解决如果尚未解决则进入下一步

b) 根据软件层面产品开发的情况决定是否接受该问题。如果接受则需要提供解释性文件说明可以接受此网络安全问题的原因如果不接受则继续标识为未决问题以便在后续的产品开发过程中进行处理。

7.4.12 软 件层面产品开发阶段检查

组织在软件层面产品开发阶段最后宜通过独立的技术专家小组参照6.5节内容进行阶段检查。

7.5 产品生产、运行和服务阶段

7.5.1 现场监测

7.5.1.1 监测能力

具有联网功能的汽车电子产品宜具备网络安全监测能力。当汽车或相关基础设施被公众使用时可实施现场监测以便通过监测日常事件获得有关网络安全的威胁预警根据预定程序向相关组织提供事件报告并及时发布公告和安全须知。

7.5.1.2 分析评估

组织还可通过多种渠道采集来的数据对现场出现的问题和事件进行分析评估以找出威胁网络安全的事件源数据来源可包括

a) 从执法部门、保险机构、媒体、其他整车企业等方面收集数据

b) 来自其他相关方的网络安全事件信息汇总和共享的数据。

7.5.2 事件响应

针对整车、相关基础设施、应用服务可能或已出现的网络安全事件组织宜制定事件响应的相关内容目的是限制事件的影响范围降低事件的网络安全威胁程度最小化损失和损害并避免类似安全事件的再次发生。

事件响应具体可包括以下活动

a) 设置专门的机构负责检查和分析事件数据、管理事件确定各种事件的优先级、向相关人员发送事件预警、及时报告问题和处理事件

b) 通过书面文档定义事件的优先级

c) 创建事件响应策略和计划内容可包括事件处理、报告的流程确认威胁的真实性的方法分析导致事件的原因并记录证据确定事件对于组织运营的影响正确处理敏感信息的方法记录事件响应所采取的行动与相关方进行沟通、交流的渠道和内容总结经验教训以及将其应用到后续产品开发和设计中的考虑

d) 一旦组织制定的事件响应计划获得管理层批准组织应确保其得以实施至少每年评审一次以保障它的成熟度和实现事件处理目标的能力

注 可通过事件响应计划演练的方式验证其可行性。

e) 事件响应团队宜综合运用标准化操作流程、专业技术流程、检查清单参见附录C和表格以尽量避免响应中可能出现的错误。

示例

针对汽车电子系统的网络安全漏洞事件可采用远程软件升级的方式进行漏洞修复保证升级过程本身的安全性且在升级前对软件进行严格的安全测试验证和评估。

7.5.3 事件跟踪管理

针对已出现的网络安全威胁与安全事件组织宜对事件的发现、分析及处理的全过程进行记录与跟踪其目的主要是促进管理流程的持续优化以便尽可能地降低网络安全事件的威胁程度最小化其可能造成的损失或损害进一步形成典型事件案例避免类似安全事件的再次发生。

事件跟踪管理可包括以下内容

a) 对已知事件进行定期排查、处理与记录

b) 对未知事件开展研究并分类制定相应的标准化处理流程

c) 对事件记录进行归档并规定其有效的保存时间。

延伸阅读

更多内容 可以点击下载 GB-T 38628-2020 信息安全技术 汽车电子系统网络安全指南. http://github5.com/view/764进一步学习

联系我们

JG-T148-2018 JG T148-2018钢管散热器.pdf