J3061《信息物理融合系统网络安全指南》
J3061《信息物理融合系统网络安全指南》
文章转载自“解读: J3061车辆系统功能安全及信息安全概述”
车辆系统功能安全及信息安全
SAE出台的J3061《信息物理融合系统网络安全指南》，旨在通过统一全球标准，来推动汽车电气系统与其他互联系统之间安全流程的建立。
文档中，详细定义了一个结构化的网络安全流程框架，用于指导建设安全要求极高的计算机系统。整份标准，始终在强调汽车网络安全的系统工程性，即从项目初始就应将信息安全纳入到系统设计中考量，并在其整个生命周期中提供有效保护，也就是贯穿于车辆产品设计、研发、制造、维修、回收等各环节。
长期以来，汽车毋庸置疑一直注重系统功能安全的可靠性，并在不断增强车辆主被动安全能力，该文件的出台则意味着首次将汽车信息安全提升到与功能安全等同重要亦或更甚的位置。
汽车系统功能安全与汽车网络安全关系相互渗透，System Safety指的是该系统不会对人身安全，财产以及环境造成伤害。System Security则是指安全系统难以被其他人恶意利用车辆漏洞导致经济损失，驾驶操控失误，隐私盗取及功能安全的损坏，如车速不受到远程控制等。因此，任何功能安全关键（Safety-Critical）的系统本身都是信息安全关键（Cyber Security-Critical）的系统，例如在对Satety-Critical系统进行网络攻击时，必然会有出现功能安全事故的风险，反之则不然。
两者关系如图中所示，举个例子，如存在安全漏洞的车载娱乐信息系统，则可认为是Cyber Security-Critical，但即使直接对其进行直接安全攻击，也并非一定会引起直接的驾驶功能破坏及人身安全损失，只是会引起部分私人信息的泄漏等。因此它就不属于Safety Critical。
另一个提到的案例是转向辅助系统，假如该系统软件存在安全漏洞，且被攻击者利用，那么在驾驶过程中就有可能会因被**实现远程控制后而导致出现人身安全风险，即该Safty Critical系统属于Cyber Security Critical。
对于造车过程，车辆对于保证System Safety与System Cyber Security的目标一致，且都应从架构功能设计之初就将Safety及Security纳入到系统中，而非在成熟产品做漏洞修补防护。
车辆功能安全在前期验证过程中需进行危险性分析及风险评估，同样汽车信息安全也需要进行威胁性分析与风险评估。对于更容易进行识别的功能危险性分析来说，传统车辆的评估流程已非常完善，能对车辆潜在的安全风险逐个进行功能测试，如碰撞试验等，即可逐个排除。但信息安全的威胁性分析则更为复杂，对整车以及各个子网部件，存在太多未知的攻击漏洞及攻击方式，且需要站在攻击者的立场上，使用非传统式的漏洞分析，渗透及统计学技术进行分析，对于传统汽车人员来说，难度相对较大。
图为汽车信息安全的风险分级，基于下图ISO26262中的ASIL分级方式改进而来，对于各主机厂及公司发展汽车信息安全有很强的现实参考意义。
但两个安全体系之间的流程框架可以相互借鉴的，如在进行功能安全的风险评估时会利用故障树分析（FTA），同样，在网络安全系统中，会使用攻击树分析技术（ATA）。
在故障树分析技术中，分析者会识别出并且寻找出会引起最高风险事件的单点或多点硬件故障。但对于攻击树分析技术，我们则并不关心这些单点或多点的硬件故障，而是所有攻击者会利用来攻击车辆系统的潜在途径，因此通过网络安全措施可以找到并消除漏洞或者使其更难被利用。
最后，信息安全与功能安全最大的挑战在于，主被动安全技术已发展到成熟，但车辆信息安全的风险来源于黑客技术的快速迭代发展，这意味着车辆将会与更新速度迅速的黑客技术进行直接对抗。
汽车信息安全的系统工程性，即System Security应与传统车辆System Safety一致，从项目研发初始即将信息安全纳入到系统设计考量中，并进行全生命周期的有效防护。
汽车信息安全流程架构
文档中详述了一个定义明确（well-defined）且结构良好（well-structed）的汽车信息安全控制流程，后面简称WDWS Process。该过程通过建立一个可重复且结构化的系统，有效地识别出会被利用攻击的威胁与漏洞，并能在系统设计过程中针对已识别的信息漏洞做出有效控制，且可贯穿整个车辆生命周期，从概念阶段，到产品，运营以及售后服务。
参照车辆传统系统功能安全标准ISO26262定义的流程架构，针对车辆信息安全架构做了以下定制，如下图：
图中所示的流程架构由信息安全管理（the management of CyberSecurity），核心信息安全工程活动（Core CyberSecurity engineering activities）以及支持过程（supporting process）构成，核心信息安全工程活动包括了概念阶段的活动，整车系统、软硬件层面的开发活动及生产，运营，维修的活动。而支持过程则包括生命周期中其他阶段的活动，如配置管理（configuration management）以及变更管理（change management）等等。
产品概念阶段，信息安全工程活动体现为：
- 分配一个Cybersecurity Manager，负责对安全活动进行监督与审计，并制定出针对安全活动的具体项目计划（cyber security program plan）。
产品开发阶段，信息安全工程活动包括：
- 起草初步的信息安全评估方案，保证其贯穿于后续开发流程，且在关键时间节点对其进行review，并在最终的网络安全评估中进行验收。
- 用于评估及判别确认所有适当的活动是否都合理执行。
产品概念阶段
图中绘制出的是在概念阶段执行的活动流程，包括识别出网络安全限定的边界、系统外部的依赖关系及资产（asset），以便后续更高效、高质量地完成对圈定范围内活动的分析。
网络安全生命周期的启动步骤包括提及的对整个安全项目计划的制定，Threat Analysis and Risk Assessment（TARA）则是用来识别评估系统中潜在的威胁，并评估相应风险。网络安全目标可由评估得到的最高风险级别的威胁决定。
例如，系统中存在恶意制动的漏洞，那么*别的目标即可设定为阻止或者降低恶意制动攻击的发生，或减轻恶意制动引起的后果。在此概念阶段定义的目标以及需求在后续的产品开发阶段会被进一步发展，同样在最后的评估阶段中将会被作为主要的评估项。
产品开发阶段
产品开发阶段由系统层面开发、硬件层面开发以及软件层面开发组成。具体发展过程关系如下：
产品开发：系统级别
下图所示的是在汽车系统级开发时参考的V图，为了将信息安全的概念融入到汽车系统的设计工程语言中，在此过程中会对整车系统的脆弱性与威胁性进行风险分析，针对此进行信息安全需求与策略的定义。
此时系统安全文档可以逐步开始制定，定义内容有：系统的软硬件接口，关键数据流，系统内部的存储与处理。同时对软硬件层的网络安全策略及需求也可开始定义与分配，一旦完成，后续软件层、硬件层的开发就可以正式开始。
当硬件级别与软件级别的产品开发结束，并且完成两者集成与功能测试后，信息安全相关的脆弱性与渗透测试将也会按照既定的信息安全需求，基于该集成系统进行。最后会在车辆量产前完成最终的安全审计。
产品开发：硬件级别
下图所示的是在汽车硬件级开发时参考的V图：
在此环节中，开发过程将严格遵守系统级开发时制定的信息安全硬件需求，完成设计后，会对硬件进行脆弱性分析，以确保发现设计过程中存在的漏洞，并针对漏洞制定响应的安全控制措施。
详细流程如下图所示：
产品开发：软件级别
下图所示的是在汽车软件级开发时参考的V图：
在此环节中，开发过程将严格遵守系统级开发时制定的信息安全软件需求，完成设计后，会对软件进行脆弱性分析，以确保发现设计过程中存在的漏洞，并针对漏洞制定响应的安全控制措施。在完成软件各单元的测试后，会进行软件单元的集成与调试，此时将再次进行脆弱性分析与渗透测试，并对之前的信息安全评估结果进行更新。
详细流程如图所示：
软件集成及测试过程
软件安全规范定义
针对软件安全需求的定义，第一步需明确系统中对应的硬件及软件接口，数据流，数据存储，数据处理以及用于支持Cyber Security的功能组件。
第二步是理解软件如何实现对系统目的或任务的支持，包括信息安全的功能，例如防止未经授权的访问以及检测出篡改行为等。例如，当软件检测到了篡改行为，应记录下（做出report）此篡改行为，并及时更改所有此网络系统相关**以防止旨在保护的信息受到威胁。若此时系统软件对保护数据实施擦除操作以进行防护，也许这也是攻击者所预期的后果，因此所有的安全策略应减少且减轻意想不到的后果。另一个措施是推行签名检测，以防止经篡改数据被安装或执行在此系统下。
软件架构设计
软件架构进行设计时需考虑：
所使用的数据类型，数据如何流动，系统如何进行错误检测，系统如何从错误中恢复。总之所期望得到的结果即为传统信息安全中的CIA三要素：保密性（Confidentiality）、完整性（Integrity）、可获得性（Availability）。
保密性（Confidentiality）
通俗地说，即具有一定保密程度的信息只能让有权读到或更改的人读到和更改。完整性（Integrity）
指在存储或传输信息的过程中，原始的信息不允许被随意更改。可获得性（Availability）
对于信息的合法拥有和使用者，在他们需要这些信息的任何时候，都应该保障他们能够及时得到所需要的信息。
对数据流的分析可有效地对软件进行分割与隔离，以防止当系统受攻击时出现扩散感染。且为防止软件受到攻击后无法正常运行，软件系统需具备错误检测以及恢复的能力。假如此错误不可恢复，则软件系统应恢复到一个预先定义好的安全模式，并通知所有相关软件模块此错误。
假如一个无法运行的软件可以在提醒其他模块此错误后完成恢复功能，它也应将已恢复到正常工作状态的情况告知给各模块。
日志中需对所有错误，失败以及恢复状态进行记录，以用于后续通过分析记录来识别异常、入侵目的以及系统的鲁棒性。
软件漏洞测试
系统的风险预测中，威胁模型(Threat Modeling)是首要且最为重要的步骤，能为设计团队明确在网络安全验证阶段需添加的安全测试环节与安全审计对象。
威胁建模过程中，关注目标主要为软件组件之间的数据流与控制关系，系统各功能用例的输入输出口。任何有数据及控制信息通过的边界都需予以足够关注。
威胁模型的第一个步骤为分解应用程序或者是程序用例。该步骤主要用于了解应用程序是如何与外部实体进行数据交互并于何处对数据进行存储与处理；应用程序是如何去发现潜在的攻击入口。信息会被记录在威胁模型中，并绘制出数据流图来来显示出进入系统的不同路径，并强调出各路径所需要的访问权限。
第二个步骤中，会采用威胁分级模型对威胁进行分级，常见的有STRIDE, ASF, DREAD模型。
最后一个阶段中，安全控制包括减少或减轻风险，接受风险，披露（disclosure）风险（警告标识），终止风险。在具体案例中具体选择实施哪个控制决定于该措施所需的成本以及此风险被识别到的成本。
软件开发及实施注意
ECU软件设计过程中，与ISO26262要求一致，良好的代码规范须被予以足够重视，如：
- 输入校验（Input validation）
- 输入检查（Input Sanitization） (防止SQL注入)
- 安全字符串函数的使用，不安全函数的使用
- 未定义边界长度的字符串或数组的使用，会引起buffer的溢出
- 领域特殊性，SQL, web等网络技术在CAN领域的应用
- 使用标准安全编程语言(MISRA C,CERT C)
- 静态与动态类型的分析