Planning a route towards better automotive cybersecurity
April 06, 2015
2014 was a tipping point for automotive, where the impacts of code faults in the field and growth in cybersecurity research were felt far beyond softw...
The impacts to everyday life started in late December, where a series of phantom car break-ins were reported in Montreal, Canada. Although no cause was proven, news outlets were quick to point out that wireless devices could easily be built to intercept and relay signals between a car and its remote key. The reality continued with a double dose of news in February, with BMW remotely patching over two million cars against a potential flaw between its ConnectedDrive software and mobile networks, and a United States senator releasing a scathing report of automobile vulnerabilities with a call to manufacturers to do more. Then came a 14-year old hacking into a connected car using $15 worth of electronics, showing everyone that the barrier to hackers is practically nonexistent.
The industry is taking this seriously, with General Motors appointing its first cybersecurity chief and the launch of several initiatives for information collection and education about potential cyber-related threats, such as I Am The Cavalry and Security Innovation’s Automotive Centers of Excellence. With cybercrime poised to cost companies, customers, and governments upwards of $100 billion annually, it’s time to take a look at the policies, processes, and tools that will lead to more secure systems and less frustration with the inevitable onslaught of oversight.
Learning to drive security
Before planning any security initiative it’s important to recognize the reality that few people talk about: even though most organizations rely on developers to manage code security, very few developers actually know how to do it. In a survey of over 1,400 developers, 80 percent missed questions about protecting sensitive data and 74 percent missed questions on threat modeling and security architecture reviews.
Making security education a priority is the silver bullet for development teams. It acts as a catalyst for leadership awareness and drives developers to be more proactive in reducing vulnerabilities before release and smarter when fixing them after. Knowing the technical difference between an HTTP request and an HTTPS request is one thing; knowing the security implications up front to select the right protocol at design time can avoid patching security holes in the field.
A good resource for developers and managers to get started is the Open Web Application Security Project (OWASP), a community-driven, not-for-profit organization helping organizations create and maintain secure applications. OWASP provides awareness, guides, and examples of security best practices, processes, and techniques.
Adopting a new security lifecycle
Security techniques and tools usually fall under the domain of security personnel and IT departments, and rarely find their way onto the desktops of automotive developers. As a result, teams discover vulnerabilities later in the development lifecycle, usually at a higher cost to fix. As systems and software grow more connected and complex the costs to mitigate issues will increase as well, so it makes sense to adopt techniques that pull security back towards the beginning and make it fundamental to the process.
The secure software development lifecycle (SSDL) is a methodology common to non-automotive industries that bake security into all aspects of software development. There are several flavors of the SSDL, such as ones from Microsoft and Cisco, but they all have one goal in common: establishing repeatable activities and artifacts that map to different phases of development. Figure 1 presents a generalized version of an SSDL that can apply to traditional waterfall development or, by making use of automation and integrated tools, fit into agile methodologies.
Avoiding reinvention of the wheel
From an execution perspective, automotive teams can take advantage of security techniques and tools proven in other industries and avoid going through all the trouble again. Bringing in testing and compliance to known security standards, such as the OWASP Top 10 or CWE/SANS Top 25 Most Dangerous Software Errors provides a head start towards measuring and quantifying vulnerabilities in application code bases. Bringing in standard gap analysis tools that do it for you makes it even easier.
Beyond security standards, code could contain a host of memory exploits, network exposures, and user permissions issues that cause security risks. Typically found during runtime scans or penetration testing, these types of problems are difficult to localize and fix, especially within the complexity of the connected car. Static code analysis, a tool familiar to automotive developers for finding programmatic bugs, can find security issues as well, even as the developer is typing in code. There is no earlier point than this to find actual vulnerabilities, so development impacts are minimal.
Arriving in the future
The rapid growth of connected cars emphasizes the importance of getting security under control as soon as possible. Nowhere is this more evident than in the connected car endgame: self-driving cars. Self-driving, or autonomous, cars are the next evolution in transportation and trials are already underway by groups wanting in on the action, from traditional car manufacturers to organizations such as Google and Oxford University. It should come as no surprise that many features in today’s cars are essentially testbeds for future self-driving technology, such as radar-assisted cruise control, adaptive stability control, and automated parking.
Several manufacturers predict self-driving cars will be on the road by 2020, with driverless car trials already underway. Certification and legislation issues aside, the technology challenges are astounding – how can manufacturers develop cars that match, or even exceed, the ability of humans to identify and respond to safety hazards, while at the same time navigating and entertaining the occupants inside?
These future challenges are the challenges of today. Shifting priorities to create systems and software that are secure now ensures a solid path for delivering the same in the technologies to come.
Rogue Wave Software
1., CBC News, Dec. 18, 2014
2., BBC News, Feb. 2, 2015
3., Feb. 9, 2015
4., Forbes, Feb. 23, 2015
5., Reuters, Sept. 23, 2014
6., I Am The Cavalry, Aug. 8, 2014
7., Security Innovation, Feb. 24, 2015
8., The Wall Street Journal, Feb. 17, 2015
9., Aspect Security
12. Cost of remediation source: “Equity Keynote Address,” Barry Boehm, March 19, 2007