Lisa Boran, an in-vehicle security expert and Security Attribute Leader at Ford Motor Company, was recently interviewed by “Autotech Daily” about the importance of establishing procedures that would enable designers to vet the security of each element in any electronic system.
Here’s what Boran, who also is the chair of SAE’s Automotive Security Guidelines and Risk Management subcommittee, had to say in the August 4, 2015, “Viewpoint” interview (requires membership to view).
Seeking Best Practices in Automotive Cyber Security
Recent news media reports give the mistaken impression that the auto industry has not been addressing the challenges of cyber security for their increasingly connected vehicles. In fact, there is intensive global activity underway concerning this critical subject through a variety of consortia, industry groups and standards-setting organizations.
One of the key objectives is to establish best practices that help designers ensure the system architectures they develop are made secure from unwanted breaches at each step in the process. SAE International is deeply involved in this important effort through its Vehicle Electrical Systems Security Committee. Chairing the committee’s SAE Automotive Security Guidelines and Risk Management team is Lisa Boran, an in-vehicle security expert and Security Attribute Leader at Ford Motor Co. She describes the group’s goals and objectives.
When did SAE’s work in this area begin?
The Vehicle Electrical Systems Security Committee, a voluntary group, was formed in 2011. We began by listing all the cyber security concerns. Then we voted to determine priorities and set up two subcommittees to pursue them. Our group focuses on guidelines and risk analysis. The second subcommittee is looking at hardware guidelines to help system designers choose which microprocessors to use in specific applications. The focus of our subcommittee is not on the end result but rather the procedure used to get there. We are developing methodologies that apply to virtually any electronic system in a vehicle. We’re not telling developers which tools to use, but we are showing them options along with the pros and cons on each one. The ultimate objective is to provide designers with a methodology that enables them to vet the security of each element in a network as well as the system overall.
Is the group working toward a cyber security standard for vehicles?
That would be an eventual goal, but that is not our immediate priority. We’re not trying to tell system developers which processes and steps to use, but we will provide a list of options that are available. The architectures of vehicle electronics networks are and will continue to be unique to the manufacturer, so we don’t envision a single solution. Each network depends on the desired elements and features to be included, and the specifics of the security countermeasures they need are likely to be unique as well. All this involves a different perspective on the traditional engineering process. Vehicle engineers are accustomed to designing a system to perform under prescribed conditions, and then conducting failure mode analyses to confirm it will do what it should. That requirement won’t go away. But cyber security raises another issue: How could an intended function be exploited by a hacker to do something malicious? To put it another way, cyber security means designing a system to perform a desired function, while limiting its ability to do anything else.
How is the trend toward greater vehicle connectivity impacting this issue?
As vehicles gain more electronic features, the number of possible entry points to the onboard electronic network increases. These potential vulnerabilities require designers to consider the security of each breachable component and how it might allow access to otherwise unrelated electronics elsewhere in the vehicle. Our subcommittee’s mission is to establish best practices for making these evaluations.
What happens if someone invents an entirely new electronic option for vehicles?
Any new feature, whether electronic or mechanical, introduces a potential weakness or vulnerability to the previous system. For electronics, there’s always the possibility a new feature introduces an interface or software attack point. The concern isn’t that a vulnerability is possible, it’s to recognize the threat and deal with it.
There are three levels of assessment that any electronic feature should consider. First is the standard engineering analysis, FMEA (failure modes and effects analysis), that is routine in the industry today. The second is a hazard assessment such as the ISO 26262 standard. Finally there’s TARA (threat analysis and risk assessment) that covers malicious attack questions not necessarily covered in the first two assessments.
How is SAE moving forward with this work?
Our group—which includes representatives of companies, suppliers, independent researchers and government agencies—has developed an initial list of best-practice processes and steps for developers that is undergoing peer review now. When it’s finalized, probably by autumn, the document will become generally available. There also are common points between our work and the needs of other parts of the transportation industry. Certainly the automotive guidelines would apply to commercial vehicles. Aerospace has other certification standards and requirements, but they also have planes with linked networks and systems just as with passenger vehicles.