Planning a route towards better automotive cybersecurity

April 6, 2015 OpenSystems Media

The impacts to everyday life started in late December, where a series of phantom car break-ins were reported in Montreal, Canada[1]. 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[2], and a United States senator releasing a scathing report of automobile vulnerabilities with a call to manufacturers to do more[3]. 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[4].

The industry is taking this seriously, with General Motors appointing its first cybersecurity chief[5] and the launch of several initiatives for information collection and education about potential cyber-related threats, such as I Am The Cavalry[6] and Security Innovation’s Automotive Centers of Excellence[7]. With cybercrime poised to cost companies, customers, and governments upwards of $100 billion annually[8], 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[9], 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[10] and Cisco[11], 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.


21
Figure 1: Secure software development lifecycle (SDLC)[12]
(Click graphic to zoom)

 

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[13] or CWE/SANS Top 25 Most Dangerous Software Errors[14] 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

www.roguewave.com

@roguewaveinc

linkedin.com/company/rogue-wave-software

opsy.st/RogueWaveSoftwareGooglePlus

youtube.com/user/roguewavesoftware

References:

1. Phantom car break-ins in Montreal area baffle authorities, CBC News, Dec. 18, 2014

2. BMW fixes security flaw that left locks open to hackers, BBC News, Feb. 2, 2015

3. Markey Report Reveals Automobile Security and Privacy Vulnerabilities, Feb. 9, 2015

4. 14-year old hacks connected cars with pocket money, Forbes, Feb. 23, 2015

5. General Motors appoints its first cybersecurity chief, Reuters, Sept. 23, 2014

6. “I Am The Cavalry” Calls for Collaboration with Automotive Industry to Improve Public Safety, I Am The Cavalry, Aug. 8, 2014

7. Security Innovation Launches Automotive Centers of Excellence, Security Innovation, Feb. 24, 2015

8. Auto Makers Fall Behind in Anti-Hacking Efforts, Executives in Several Industries Say, The Wall Street Journal, Feb. 17, 2015

9. 2014 State of Developer Application Security Knowledge Report, Aspect Security

10. Microsoft Security Development Lifecycle

11. Cisco Secure Development Lifecycle

12. Cost of remediation source: “Equity Keynote Address,” Barry Boehm, March 19, 2007

13. OWASP Top 10

14. CWE/SANS Top 25 Most Dangerous Software Errors

 

Roy Sarkar, Rogue Wave Software
Previous Article
Drone safety, what's next?

For unmanned aerial vehicles (UAVs) or drones that fly in commercial air space, it is reasonable to require...

Next Article
GENIVI Alliance: What's so special about securing the vehicle?

In a recent survey of software decision-makers in many of the top 20 automakers, the issue of vehicle secur...