Can connected cars be secure cars? The growing concern over software security in the automobile industry
February 01, 2015
Software glitches are responsible for an estimated 60-70 percent of automotive recalls. Here are some strategies to ensure your code is bulletproof.
Recent statistics about automobile safety are hard to miss these days. Attention-grabbing headlines have exploded both in mainstream and social media, and you can hardly read a blog without seeing one of them: “Hands-Free Driving is Not Trouble Free.” “Toyota Widens Recall of Cars with Takata Airbags.” “Hacked Driverless Cars Could Cause Chaos in London.”
As sensational as these headlines are, the concern is real. Technology is moving faster than the government’s attempts to regulate, and nobody wants to stifle innovation, much less slow the consumer’s access to more and better bells and whistles on their cars. Although it seems like an overnight development, automotive manufacturing has followed a long road of innovation since the dawn of the electro-mechanical era of the 1970s through to today. Only now we’re at a tipping point. Innovation no longer starts and ends with a car’s mechanical components; software has now taken over as the kingpin of the automobile industry, not because software in cars is a new development, but because of the sheer volume of code powering cars and the resulting complexity.
Estimates are that 60-70 percent of vehicle recalls are due to software glitches[1]. Cars are run by networks of computers, wireless connections, and electronic control units (ECU), offering the potential for hackers to access critical car controls such as steering and braking. Cars today also can easily connect to smart devices and the Internet, so it’s easy to see how those critical systems can be exposed. Exposed systems could mean scenarios including drivers losing control of cruise control mechanisms, braking systems, and other safety-critical operations.
So we’ve come to the “connected car.” While nebulous, this term is appropriate in describing this phenomenon. Most new cars coming off the production line today really are connected; they can easily communicate with other devices both inside and outside the vehicle. Smart devices sync to deliver in-car infotainment, to provide diagnostic information for the mechanic, and to enable extra convenience controls such as navigation, roadside assistance, and parking apps.
It’s not just new models either. Older cars are increasingly connected using new systems, like O2’s Car Connection solution, which links drivers to their cars via smartphones, providing diagnostic information directly to the phone and to tools like a vehicle finder.
So what controls the functionality in today’s cars? We’ve heard that today’s average high-end car has 100 million lines of software code[2], and anyone can appreciate the magnitude of that number, at least on the surface. (Especially when it’s contrasted with the space shuttle which, according to NASA, only contains 400,000 lines of code.[3]) But what does that number really mean? What does it mean to the consumer? To the automotive software supply chain?
It means that all of those millions of lines of code – regardless of where they come from – need to be bulletproof. Stakes are high. And, in vehicles, when software doesn’t work the way it’s intended, it’s serious.
The new role of the automobile manufacturer: Software security experts
The business of keeping automotive software secure is a dicey one. Today’s connected car is assembled from pieces, parts, and code from various companies that make up the supply chain to the manufacturer, and the end result is what ultimately ends up on the showroom floor. For manufacturers with roots in mechanics, it’s increasingly difficult to get their processes up to date around the vastly different needs of hardware and software. The complexity that comes with the shift to the Internet of Things, devices, and communications networks is additive to existing processes and systems. Now, managers at car manufacturers need to ensure security within everything that makes up their cars. These same managers are also tasked with quickly adding the latest and greatest features to stay competitive.
Security often takes a back seat when financial pressure mounts. It begs the question: How much thought has actually gone into the software security of automobiles before they are released? Security has not always been part of the day-to-day workflow in the development world. Developers might not even know what they should be doing as individuals to ensure the code they’re writing does not have security problems. And, typical development team leads may have not implemented the proper software tools, education on standards, and how to comply and production processes to make the job of ensuring security seamless.
Manufacturers need to recognize that they are not only supplying cars, they are now cyber security managers as well. Although automobile hacks have yet to become commonplace, they do happen. Recently in Canada, authorities attributed “phantom” car break-ins to hacking, and found that a simple program could be written in a matter of hours that jammed the message from the key fob to the car, disabling the locking system.[4]
Securing the supply chain
From the computer screen to the assembly line, manufacturers should now consider themselves attack vectors who are responsible for everything that goes into their products, not just what’s directly within their own development groups.
It’s important to remember that the development process has evolved. Once a single developer or team of developers created code to solve a problem. Now, software development is very much akin to an art form, as developers assemble parts from various sources and skillfully coordinate their functions to create a cohesive, working product in the end.
For instance, a company provides a manufacturer with the software that controls airbags. Developers for the airbag company may have incorporated open source software to visualize testing data, or they may have grabbed some prefab code to create reports. Some code controlling the airbag was written from scratch – but that could up as little as one percent of a total application. Another nine percent comes from the rest of the development team, and as much as 90 percent of any application could come from other sources – commercial software packages, outsourced development, open source, and legacy custom code. “It just doesn’t fly anymore to pass responsibility for security to another party – whether it’s the manufacturer to the supplier, or the supplier to the manufacturer,” says Stephane Raynaud, automotive account liaison for Rogue Wave Software. “It makes sense to leverage pre-built functionality; every participant on the supply chain has to make sure every bit of it is safe and secure.”
Protecting companies and consumers: Know what’s in your code – all of it.
How can companies protect themselves – their reputations, their financial stability, and their customers? They can do it by knowing, understanding, and taking responsibility for all of the code that makes up their product – not just what their own developers have written.
The automobile industry could take a page from the playbook of telecom companies who faced a similar challenge several years ago when their devices suddenly became the only thing standing between the consumer and complex, embedded software code. These companies learned quickly that they could not pass all of the responsibility to the companies that supply the features in their product. They also learned that their product was only as strong as their weakest supplier’s code.
The bottom line is that companies need to open the aperture of what they’re securing, and they need to do it before they become the subject of dramatic news headlines. And, those who are part of the supply chain need to tighten processes. Putting security first means three things:
1. Policies
Organizations need to implement policies to take the guesswork out of how to ensure the security of its code. Successful policies are easy to follow, easily accessible, and properly educate the workforce so that developers know and understand security issues and how it is applies to their workflows.
Management should implement these two types of policies:
- Operations policies – These are documented policies outlining the tools that are approved for use in an organization, the agreed upon processes, and testing practices and test suites – all of which are designed to ensure optimal code security. Typically these decisions and policies are managed by an enterprise architecture group.
- Open source software policies – Designed to outline how an organization manages the open source in its code base, these policies cover how open source is used and when it is considered appropriate in the development process. More and more organizations are implementing groups within existing company functions to create and manage policies around open source code.
2. Processes
Clear processes are key to secure software development. Teams from both the automobile manufacturers and the companies within their supply chains need to agree that security processes are important, and then mandate consistent application as non-negotiable. Organizations can start by educating their own workforces on the importance of security and defining how each how each individual plays an important role in releasing secure products.
Though top-level management may direct the need for processes, front line development managers should deploy processes that bring security into developers’ existing workflows and manage them ongoing. Processes should be seamlessly integrated with builds to ensure important steps aren’t forgotten, overlooked intentionally, or are too difficult to maintain. Processes should include:
- Building automated test suites
- Teaching secure coding practices
- Putting processes in place for acquisition and monitoring of open source
- Making tools readily available and updated regularly
And, anything developed by internal teams should apply to the supply chain. When accepting code from suppliers, manufacturers have a right to ask what processes are in place, and even require contractually that clean practices be applied.
3. Tools
Knowledge goes a long way, but developers can only do so much to ensure secure code. Human error and hidden threats need advanced tools built that expose issues to the developer. Management should provide their development teams with automated, easy-to-use tools that operationalize policies and procedures. These tools should be built into processes, and automate the detection of critical security issues. Ease of use will determine if they get used, and if used, can encourage good coding practices. Developers may have some fear about processes cutting into their creativity, so managers need to demonstrate how easy certain tools are to use, empowering them even more toward innovation. In short, providing the right tools means better, more secure software with less effort by the individual developer.
Development managers can help ensure secure software development:
- Open source scanning and support – As open source has become a large component of virtually any application, the first step is to discover what and where OSS is across all code lines. Also, ask these questions: Can the OSS be supported during any failures? Which packages have security vulnerabilities? How can we better manage our OSS use?
- Static code analysis – Static code analysis is the process of analyzing the health of source code without actually executing it. Developers should be able to identify and correct problems with code before it is ever checked in, saving time earlier in the development process.
- Dynamic code analysis – As a complement to static code analysis, dynamic code analysis is the process of executing code in real time to find security errors while it is running. Developers in complex environments using extensive memory and compute resources should have a dynamic code analysis tool at their disposal to perform simultaneous debugging of many processes and threads at once.
Setting the bar higher
As cars become more connected, and our dependency on the software that powers them grows, the need for advanced tools to ensure security in code will grow too. Stand out organizations in the automotive industry will set the tone for other companies by not only creating higher standards for their developers, but by demanding the same level of excellence from their entire software supply chain. Progressive development managers today are already taking steps to defend their companies against worst case scenarios by providing expert knowledge, policies, processes, and tools to their developer workforce.
References
[1] http://www.automotiveworld.com/megatrends-articles/connected-cars-connected-era
[3] http://www.nasa.gov/mission_p+ages/shuttle/flyout/flyfeature_shuttlecomputers.html
[4] http://www.cbc.ca/player/News/Canada/Montreal/ID/2642436500
Rogue Wave Software www.roguewave.com @roguewaveinc opsy.st/RogueWaveSoftwareGooglePlus linkedin.com/company/rogue-wave-software youtube.com/user/roguewavesoftware