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 at ZF 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.”