汽车互联可以给用户带来巨大便利，但同时也将汽车系统暴露在互联网所带来的负面风险之中，因此汽车生产商必须迅速采取措施，以确保车辆不会成为黑客攻击的受害者。SAE即将发布一份最佳做法（Best Practices） 建议，协助整车厂通过实施结构清晰的项目，以保证汽车在全生命周期中都可获得有效的保护。

SAE J3061推荐规程《信息物理汽车系统网络安全指南(Cybersecurity Guidebook for Cyber-Physical Vehicle Systems)》是首部针对汽车网络安全而制定的指导性文件。近日，SAE举行了一次网络研讨会，数位与会的SAE委员会成员参与探讨了一系列重要问题，包括规范相关标准及其在保护网联汽车安全方面的作用。

本次会议的讨论范围覆盖了J3061号指南的全部内容。会议开始时，发言人首先介绍了起草J3061号指南的初衷。

全球供应商ZF TRW公司高级技术专家、安全评估员及网络安全员Barbara Czerny表示，“（与网络安全有关的）潜在威胁众多，包括经济损失、知识产权盗用、汽车性能降低，以及商业运营受到影响等等。”

网络安全与汽车质量和车辆安全等因素一样，也需要从一开始就坚持贯彻，始终不变，但要做到这点并不容易。汽车的绝大多数系统都可能受到网络安全的影响，换言之，网络攻击的目标可能是车辆安全系统、信息娱乐系统，也可能是车上的其他电子系统。

Czerny指出，汽车厂商必须采用系统工程的方法保护网络安全。如果车辆遭受网络攻击，其关键安全系统和其他电子控制系统均有可能受到影响。举例来说，黑客有可能盗取存储在车载信息娱乐系统中的密码或其他个人信息。目前人们最担心的，还是网络安全对汽车安全的潜在影响。

汽车安全和网络安全有时并无过多交集，但也有很多时候，两者是紧密联系在一起的。如果有黑客计划通过网络入侵来敲诈整车厂，一定会首先从车辆的安全系统下手。过去工程师需要关注的仅仅是车辆硬件和软件之间的配合，而如今他们还要考虑更多的问题，比如外来入侵者是否有可能通过某些方法影响车辆的关键功能，比如车速控制等。

汽车咨询公司Horiba MIRA的功能性安全主管David Ward表示，“很多系统都有可能造成汽车发生意外加速等状况，网络安全系统也不例外。”

与其他电子系统相比，网络安全系统需要更高的灵活性，因为网络威胁时刻都会发生变化。我们必须及时拿出预防措施，应对黑客攻击，在车辆的整个生命周期中为其提供有效保护。我们必须开发出全面的安全保障策略，有效应对常规问题，并对网络攻击做出敏捷的反应。

福特汽车公司车内系统安全专家Lisa Boran表示，“网络系统安全也必须考虑到车主变更的情况。作为整车厂，我们所制定的规划必须包含一个能够准确判断事件性质的响应机制。当此类事件发生时，所有人都应该知道需要通知哪些人员来处理相关问题。

SAEJ3061规程已于2016年1月发布，同时SAE相关委员会成员已经开始准备相关配套文件。例如，J3101号文件《路面车辆硬件保护措施的应用(Hardware Protected Security in Ground Vehicle Applications)》。设计团队可以采取一些措施，为车辆提供多重保护，比如将验证秘钥存储在微控制器的受保护区域中。

菲亚特克莱斯勒全球汽车网络安全策略师Bill Mazzara表示，“对硬件的安全防护，也可以帮助应对一些针对软件的威胁。”

在网络研讨会上，与会发言人不断重申，网络安全系统的开发必须从车辆设计阶段就开始进行，并贯彻整个车辆研发过程始终，而不是在研发后期才添添补补。专家们同时指出，认证机制在网络安全领域并不能发挥太大作用，其按部就班的工作机制并不适合复杂多变的网络环境。

网络安全系统一般采用纵深防御(Defense in Depth)技术，这样一来即使某层防御被突破，其他程序也能补上缺口。此外，分层防御还能保证问题发生时可以得到有效控制，不会迅速蔓延至车辆的其他系统。

Czerny表示，“没有哪个系统是100%安全的，遵循结构化流程有助于降低网络攻击得手的可能性。结构完善的流程还能应对不断变化的威胁。”

在车辆的生命周期很长，而网络攻击的技术始终在发生变化，因而系统只有不断升级才能有效保持防御能力。美国国家高速公路安全局（简称NHTSA）电子系统安全研究部负责人Cem Hatipoglu表示，网络攻击信息的共享可以造福所有整车厂，帮助他们在遭受大规模攻击前及时发现威胁。

Cem说:“我们希望整个汽车行业能够建立一个信息共享的分析中心，以便在问题大规模爆发前及时互通可疑情况。如果我们等到问题发生时再采取行动，那就太晚了。我们必须尽早发现问题。”

打造灵活的系统，以保证汽车在整个生命周期中有效应对各种威胁并不容易，因为这需要对车辆进行长时间的监测，甚至长达数年。正因为如此，J3061号指南仅仅是SAE推荐的最佳做法，并非研发者必须遵守的规范。

Czerny表示，“J3061只是根据目标而提出的建议，并非强制性规定，公司完全可以根据自身的要求打造适合自己的解决方案。”

研讨会期间，J3061号指南的起草者还强调了这份SAE标准文件和ISO26262功能性安全标准之间的相似之处。这两份文件都要求设计团队尽可能寻找潜在问题，并采取措施消除或降低风险。此外，这两份文件都认同应当集中精力处理最危险的问题。

Ward表示，“风险评估应当包括对袭击动机的侦测，而严重等级则用于评估可能遭受的损失规模。”

不过，这两份标准也有明显不同。其中最重要的一点差别是，在功能性安全问题上只需考虑开发人员可能发生的疏漏，但在网络安全领域，还必须同时考虑到其他因素，包括黑客乃至车主的行为。

Ward表示，“功能性安全隐患一般源于系统故障、软件或硬件失效。但在网络安全中，还必须同时考虑恶意或意外行为可能造成的影响，比如有些车主出于好奇，也有可能对车辆进行一些不当操作，从而影响车辆的网络安全。”

开发人员在分析系统安全的弱点和潜在威胁时，必须分析事故的严重级别，以及汽车功能受其影响的可能性，还应评估发动者发动攻击的难度。

Ward表示，“判断安全威胁发生的概率，基本上就是在判断攻击者发动有效攻击的概率。研发人员必须分析发动攻击所需的技术水平、攻击者是否需要掌握细节信息，或者攻击者是否已经掌握了可以帮助他们突破安全防线的情报。”

很多评估网络风险等级的措施，与实现功能性安全要求的流程都有相似之处。研讨会上有专家指出，SAE指南文件与ISO26262标准的理念有很多相似之处。设计团队可以先寻找系统的潜在薄弱点，采取措施消除或减小其风险，然后再重新“走”一遍分析流程。

利用现有的流程来设计网络安全防御项目，不但可以节省大量时间，效果也更好。现有的质量控制和功能性安全流程都有助于帮助整车厂从最初的车辆设计环节就开始贯彻安全系统。

Czerny说：“大多数组织都有成熟的流程架构，企业完全可以对其加以利用。网络安全和功能性安全是相互关联的，网络安全要进行威胁分析和风险评估，功能性安全也同样需要分析和风险评估。攻击树分析(Attack-tree Analysis)和故障树分析(Fault-tree Analysis)是非常相似的。”

与会专家指出，现有流程的效果都可以在最新的网络安全研发项目中得到体现。

Ward表示，“如果没有完整的质量控制流程作为基础，上层建筑也不会稳固。企业必须建立良好的质量管理流程。”

作者：Terry Costlow

来源：SAE《汽车工程杂志》

翻译：SAE 上海办公室

SAE security guideline set to provide structure for connected vehicles

Connectivity opens vehicle systems to the dark side of the Internet, forcing automakers to quickly develop strategies to ensure that they don’t join the litany of corporations hit by hack attacks. SAE is nearing the release of a best practices document that will help OEMs create structured programs that provide protection that will remain effective throughout vehicle lifetimes.

SAE Recommended Practice J3061, "Cybersecurity Guidebook for Cyber-Physical Vehicle Systems," is the first document tailored for vehicle cybersecurity. Several members of the committee recently participated in an SAE webinar to discuss the standard and its role in protecting connected vehicles.

The session covered the full scope of J3061. Spokespersons opened by highlighting the many motivating factors behind its creation.

“Potential impacts include finances, theft of intellectual property, vehicle performance can be compromised, and interference with business operations,” said Barbara Czerny, Senior Technical Specialist, Safety Assessor and Cybersecurity atZF TRW.

Security will be similar to factors like quality and safety that must be considered from the concept phase and beyond. That’s a tall order, since cyber security spans most vehicle systems. For example, attacks can focus on safety, infotainment, or other electronic systems.

Czerny noted that companies need to take an overarching systems-engineering approach to cyber security. Cyber assaults can impact safety-critical systems as well as other electronic controls. For example, a hacker may steal passwords or other personal information stored on the radio head unit. Potential impacts on safety will be a primary concern.

Though safety and cyber security will sometimes have little overlap, they will often be tightly intertwined. Safety systems may be a primary target for hackers who want to extort money from an OEM. Engineering teams that have focused only on hardware and software they put in the car will now have to think about ways that outsiders may alter the performance of critical vehicle functions like speed control.

“Hazards like unintended acceleration may involve several systems,” said David Ward, Head of Functional Safety at Horiba MIRA Ltd. “Cyber security may be the source of that issue.”

Cyber security systems need more flexibility than most other aspects of vehicle electronics. Threats will change over time, and preventive technologies will have to evolve to meet attacks by hackers throughout vehicle lifetimes. A comprehensive security strategy should address routine events as well as attack responses.

“Computer security must also consider what happens when vehicle ownership changes,” said Lisa Boran, Global Security Attribute Leader at Ford Motor Co. “Corporate plans should include an incident response plan that identifies incidents and makes sure they’re valid. Everyone should know which team members need to be informed about incidents.”

Though J3061 won’t be formally released until early in 2016, SAE committee members are already busy working on supporting documentation. For example, J3101 will address the growing need for "Hardware Protected Security in Ground Vehicle Applications." Steps such as storing authentication keys in protected areas on microcontrollers will help design teams add another layer of protection.

“Hardware protected security offers improved security against software-only threat vectors,” said Bill Mazzara, Fiat Chrysler Global Vehicle Cybersecurity Strategist.

Throughout the Webinar, speakers continually noted that cyber security must be built into the designs, not added on during the development cycle. They also noted that certification may not be beneficial in cyber security because it fosters a check-the-box mentality that won’t work well in the complex, ever-changing cyber security field.

Security programs will typically use defense in depth techniques so that, if one preventive measure fails, another will pick up the slack. Layered defenses also help ensure that any problems that occur are kept in check before they spread to other vehicle systems.

“No system can be 100% safe,” Czerny said. “Following a structured process helps reduce the likelihood of a successful attack. A well-structured process also provides a means to react to a constantly changing threat landscape.”

The changes in hacking techniques over the lifetime of a vehicle will force strategists to plan for updates. Cem Hatipoglu, Chief, Electronic Systems Safety Research Division, at NHTSA, noted that OEMs may benefit from sharing information on attacks. That could help automakers spot attacks before they spread throughout vehicle fleets.

“We encourage the vehicle industry to set up an information sharing and analysis center,” he said. “There’s a need to disseminate information on anomalies seen on one vehicle before there are issues with a lot of vehicles. If we wait until accidents happen, it will be too late. We need to find issues earlier.”

The need to monitor vehicles for years highlights the complexity of building flexible systems that can meet varying types of threats over long lifetimes. J3061 was therefore written as a best practices document, not a specification that tells developers what they must do.

“The standard is goal-based rather than prescriptive so companies can tailor their solutions to their requirements,” Czerny said.

Throughout the webinar, the J3061 developers stressed the similarities between the new SAE document and the ISO 26262 functional safety standard. Both ask design teams to find as many potential problems as possible, then take steps to eliminate or mitigate them. In both standards, the most dangerous issues should get the most attention.

“Risk includes detection and motivation,” Ward said. “The analysis of severity includes the amount of losses that can occur.”

However, there are noticeable differences. Foremost among them is that developers are the only humans involved in functional safety issues. The actions of hackers and even vehicle owners must be taken into account by those working in the cyber security world.

“Functional safety is very much based on hazards caused by malfunctioning systems, failures in hardware or software,” Ward said. “In cyber security, people need to consider malicious action and unintended actions; a curious owner may do something to the car, for example.”

When developers are analyzing vulnerabilities and potential threats, they need to rank them on both severity and likelihood of an incident that impacts some aspect of vehicle operations. They should also examine the amount of effort required to mount an assault.

“Determining the probability of a security threat is typically based on the probability of an attacker making an effective attack,” Ward said. “People need to look at the skill level that’s needed, whether the attackers needs detailed knowledge, or whether it’s based on things that are readily known.”

Many of the steps taken to determine the level of risk are similar to the processes used to meet functional safety requirements. Webinar speakers noted that there are many similarities with the ISO 26262 methodologies. Design teams can figure out potential vulnerabilities and eliminate or mitigate them, then run through the analysis processes again.

Utilizing existing processes to set up cyber security programs will save plenty of time and improve results. Both quality programs and functional safety processes can be used to help build the base for baking security into designs.

“Most organizations have process frameworks established; companies can leverage this,” Czerny said. “Cyber security and functional safety are related activities. Cyber security has threat analysis and risk assessment versus hazard analysis and risk assessment for functional safety. Attack-tree analysis and fault-tree analysis are similar.”

Speakers noted that any new programs for security can’t reduce the effectiveness of existing processes.

“If you don’t have an established quality process, what you put on top of it won’t be reliable,” Ward said. “Companies need to have a quality management process in place.”

Author: Terry Costlow
Source: SAE Automotive Engineering Magazine