Innovation May Be Outpacing Security in Cars
When you put new technology into cars, you’ll inevitably run into security challenges. For example:
- When security researchers demonstrated that they could hack a Jeep over the Internet to hijack its brakes and transmission, it posed a security risk serious enough that Chrysler recalled 1.4 million vehicles to fix the bug that enabled the attack.
- For nearly half a decade, millions of GM cars and trucks were vulnerable to a remote exploit that was capable of everything from tracking vehicles, to engaging their brakes at high speed, to disabling brakes altogether.
- The Tesla Model S’s infotainment system contained a four-year-old vulnerability that could potentially let an attacker conduct a fully remote hack to start the car or cut the motor.
Vehicle manufacturers need to adopt a cybersecurity approach that addresses not only obvious exposures in their car’s software, but also the hidden vulnerabilities that could be introduced by open source components in that software.
Software Used in Autos is Built on a Core of Open Source
Open source use is pervasive across every industry vertical, including the automotive industry. A study conducted in early 2017 by Black Duck’s Center for Open Source Research and Innovation (COSRI) examining findings from the anonymised data of more than 1,000 commercial applications found open source components in 96% of the applications scanned. On average, open source comprised 36% of the code base in these applications.
When it comes to software, every auto manufacturer and their suppliers want to spend less time on what are becoming commodities—such as the core operating system and components connecting the various pieces together—and focus on features that will differentiate their brand. The open source model supports that objective by expediting every aspect of agile product development.
Open source software is not more secure nor less secure than proprietary software; it’s software, and therefore will have vulnerabilities. But the argument could be made that vulnerabilities in open source are more prone to attack since those vulnerabilities are often widely reported. Open source exploits are also often published simultaneously with the announcement of a vulnerability. With open source components making up as much as 90 percent or more of the average commercial application, open source is a rich target for hackers; a single exploit could compromise multiple software and applications, giving attackers the biggest bang for their hacking chops.
Whether open source or proprietary code, most known vulnerabilities also have patches available on the date of their disclosure. The open source community generally does a good job in discovering and reporting vulnerabilities. Over 3,600 open source vulnerabilities were reported in 2016 alone. But an alarming number of companies and individuals simply do not apply patches, sometimes due to lack of time, money, and resources or concerns that the patch might break a currently-working system.
In other cases, it’s a lack of insight—people or organisations are simply unaware of a critical vulnerability or its patch until they’re under attack. Another reason of concern for use of open source in voting machines is, that unlike most proprietary software, open source has a “pull” support model. That is, you are responsible for keeping track of the open source you use, as well as monitoring for vulnerabilities and installing fixes and updates for the open source your voting machine might use. Unless an organisation is aware that a vulnerable open source component is in its software, it’s highly probable that that component will remain unpatched and open to exploit.
Just as lean manufacturing and ISO-9000 practices brought greater agility and quality to the automotive industry, visibility and control over open source will be essential to maintaining the security of automotive software applications.
Examining the Key Principles of Vehicle Cyber Security
The car cybersecurity guidelines follow good security practices, including executive support (Principle 1), risk assessments both internally and through the supply chain (Principle 2), and a plan for addressing vulnerabilities as they arise (Principle 3). It reflects its automotive and manufacturing focus most clearly, however, in Principle 6: “the security of all software is managed throughout its lifetime.”
To mass produce automobiles and maintain an accurate and responsive supply chain, a list of parts is required. The industry solved this over 100 years ago by adopting a “bill of materials” listing every part down to the individual screws and bolts. When a defective part was discovered, using the bill of materials made it simple to track where those parts were used and quickly remediate the issue. Principle 6 reimagines this for tracking and maintaining the hundreds of millions of lines of software in today’s cars.
The Automotive Supply Chain Makes Tracking Code Difficult
Classically we think of software being created by internal development teams. But auto manufacturers rely on hundreds of independent vendors supplying hardware and software components to Tier 1 and 2 vendors as well as directly to OEMs.
The software from each of those vendors is likely to be a mix of custom code written by the vendor and third-party code, both proprietary and open source. With tens of millions of lines of code executing on a growing number of microprocessor-based electronic control units (ECUs) networked throughout the car, understanding exactly which open source components are part of the mix can be extremely difficult for the OEMs. When you add in the fact that over 3,000 open source vulnerabilities are reported every year, the security implications are disturbing.
Product Lifecycles Present Long-term Maintenance Challenges
The average cell phone has a life of 2-3 years, and receives regular operating systems updates and probably hundreds of app updates each year. Similarly, most laptops are replaced after a few years of use, and receive regular updates and patches, and will likely be replaced after 3-5 years. This is the typical lifecycle software vendors are used to addressing.
A modern car, however, is in design for years prior to production, and the average vehicle may be on the road for 10-15 years. Supporting software over that period of time will require a different thought process. Vendors (and open source communities) need to be considered in light of the operational risk they present. Questions vendors need to ask include:
- Will the components you’re using be supported by the open source community in the future?
- Are you prepared to provide ongoing support for projects if the community (or vendor) abandons them?
- What does the release cycle look like?
- How many vulnerabilities has the component had over the last few years compared to the size of the code base? Is the community security-aware?
When Car Safety Becomes a Function of Software, Software Security is Essential
Let’s be clear. The software included in today’s vehicles makes driving safer. Whether it’s collision avoidance or airbags, we have the benefit of sensors and software helping protect drivers and the general public. The terrorist truck attack in Berlin’s Christmas market last year could have been much worse, had the vehicle’s anti-collision software not stopped the truck.
The increased use of software and open source requires a new approach to product safety, and is captured well by the UK guidelines. When a supplier or auto OEM is not aware all the open source in use in its product’s software, it can’t defend against attacks targeting vulnerabilities in those open source components. As open source use continues to increase in the auto industry, effective management of open source security and license compliance risk will become increasingly important.
To defend against open source security threats and compliance risks, both auto OEMS and their suppliers should adopt open source management practices that:
· Inventories the open source used in their applications.
· Maps open source to known security vulnerabilities.
· Alerts on new open source security threats.
· Identifies open source licensing and code quality risks.
· Automates management of open source policies.
By integrating risk management processes and automated solutions into their software supply chain, automakers, suppliers, and technology companies servicing the automotive industry can maximise the benefits of open source while effectively managing their risks.
About the author:
As vice president, security strategy for Black Duck Software, Mike Pittenger is responsible for strategic leadership of security solutions, including product direction and strategic alliances.
If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :
