Writing good software is hard. Making it secure is even harder. It requires knowhow, an awareness of common programming flaws and discipline; checking input sizes; managing memory allocation and deallocation; addressing string formatting; avoiding dangling pointers – the list goes on and on. More often than not, writing secure code stands in contrast to developers’ natural desire to write code which is “flowing” and to focus on getting the business logic right, rather than on safeguarding every bit of written line.

It comes with little surprise then that while the majority of software vulnerabilities stem from a small list of coding mistakes, the industry average of 40-70 errors per 1000 lines of delivered code still holds true despite years of improved development practices. A fraction of these errors will result in exploitable security issues, but with products deployed with tens of millions of lines of code, this can very quickly translate into compromised system security.

A vulnerability is typically defined as “a weakness which can be exploited by a bad actor”; the term has recently gained popularity in leadership and organizational consultancy literature as a sign of a modern type of management, where leaders and employees alike are encouraged to exercise vulnerability transparency as a better way to drive motivation and performance up, but the underlying assumption of these blessed theories is the presupposition of trust.

Depositphotos_245639624_s-2019

It could have been inspiring to take these notions of vulnerability transparency into the world of software, but what happens when your products are deployed into environments that are hostile by design, such as in the case of vehicles or automotive product security at-large; when, as a manufacturer, you have no control over where and how your products are used; with which systems they will interface and who uses them or could gain access to them, intended or malicious. In this environment the task of managing the vulnerabilities in your code becomes critical.

 

Security Challenges in the Automotive World

There are a few additional factors that exacerbate the challenge of managing vulnerabilities in the world of automotive:

  1. Legacy – vehicle software development is about 50 years old. The typical lifespan of a car is at least 12 years. A vehicle platform changes every 5-7 years but a large part of the legacy hardware and software is carried across from one platform to the next. The primary software language and development tools used by automotive developers are C and C++ which are non-secure by design, and while they give enormous flexibility to the developer, they also provide zero safeguards that could prevent the introduction of security bugs to the system. Though some work has been done to make coding secure with the introduction of coding standards such as MISRA-C, these guidelines are hard to enforce, and in some rich-OS systems adherence is unrealistic.
  2. Supply Chain – the distributed development practice of the automotive industry is unique with its multiple tiers of suppliers, each contributing software to a higher-layer of system integration. A typical car may have between 50-150 different computing units provided by 10-20 different suppliers, where each component may, in turn, have multiple CPUs, dozens of peripheral hardware components and a large number of software packages. With so much 3rd-party code, and given that the OEM is practically responsible for a very small part of the actual coding, software opacity becomes the norm, making it very hard for manufacturers to assess security.
  3. Open Source Software (OSS) – OEMs and suppliers increasingly introduce open source software, mostly based on Linux and Android, and integrate a vast number of libraries from the open-source community. This practice of development is driven by the need to be quicker and more agile in the face of growing customer demand. This reliance on OSS opens up yet another slew of security deterioration.

 

From Best-Practices to Regulation

These are all difficult problems, and have been the focus of the automotive cybersecurity community for the last decade, and various efforts have been made to guide the industry in the right direction; I’ve personally been involved in some of these initiatives and it’s worthwhile to accredit their contribution to the increasing maturity of security practices of the period:

  1. The 2016 SAE J3061 “Cybersecurity Guidebook for Cyber-Physical Vehicle Systems”
  2. The 2016 NHTSA “Cybersecurity Best Practices for Modern Vehicles”
  3. The “Best Practices Guides” by the Auto-ISAC consortium of OEMs and suppliers

Most notably, in recent years the industry has collaborated around the issuance of an international standard – ISO/SAE21434 – an extension to the SAE J3061 work. At about the same time, the United Nations Economic Commission for Europe (UNECE), under the WP.29 workgroup of Harmonization of Vehicle Regulations has moved forward with setting regulations that OEMs and manufacturers will have to meet when it comes to automotive cybersecurity before they can issue vehicle type approval, without which a car may not be sold. Both the ISO standard and the WP.29 work include a directive for the continuous management and monitoring of vulnerabilities through the vehicle lifecycle, from development all the way to after-sales.

What we are witnessing here is the transition of an industry driven by best-practice to a regulated one, like vehicle quality and safety evolved in the past.

 

Security Digital Transformation

Having a clear and regulated process is a big step towards improving the security posture of vehicles, but processes alone are not enough. Managing vulnerabilities at scale in a reality of growing software complexity poses multiple challenges:

  1. Visibility – the automotive industry has traditionally been organized according to the notion of functional components; consequently, OEMs have optimized their asset management systems to manage suppliers’ parts, with little visibility of the internal software composition of those parts. These systems are great in managing complex supply-chain distribution at the level of a hardware component (as well as for mechanical parts) but give little utility when it comes to issues at the software-level. Too often then, the biggest challenge faced by product security teams is getting insights into vulnerabilities and threats on systems where they have very little internal visibility.
  2. Relevancy – another challenge is “cutting through the noise”. NVD, the primary source of software vulnerabilities, reports on average more than 16,000 CVEs every year, of which > 90% have no application in the automotive industry, but without advanced software able to contextualize the data to the actual vehicle surface, security teams spend many hours through thousands of vulnerabilities just to clear them as “irrelevant”.
  3. Traceability – a vulnerability that is found in one component or a development program is likely to be relevant to others but with teams that may work in silos unable to harmonize processes across multiple programs, security practitioners find it hard to “read across” the entire breadth of their development.
  4. Actionability – a key task of the security teams is to govern the development work in addressing vulnerabilities and continuously improving the posture of the system; with different individuals and a disparate organizational structure, this can become a challenge if not managed in an organized and scalable manner.

 

All these challenges stress the need for a Security Digital Transformation of the automotive industry. It’s the realization that only a people+machine approach can provide the scale needed to keep security at bay, and it’s the introduction of automation and workflow technology that is critical to support the transformation of vulnerability management practices required by the new standards and regulations.

 

Wrap Up

Let me wrap-up with a personal note; I have been working in the automotive cybersecurity community since 2013 at Cisco and later at TowerSec and Harman, selling products and services to make our connected cars more secure. As the industry shifts from being best-practice driven to one that is regulated and with the clear need for security digital transformation and automated vulnerabilities management systems, I can clearly see the advent of a new wave of products and technologies that will take us through this transition. I therefore recently joined Cybellum, as it is uniquely positioned to support the industry in this transformation. It enables manufacturers to develop and maintain secure products, both at the development and post-production phases. Using a set of innovative technologies it allows OEMs and suppliers to represent components and software in a cybersecurity digital twin replica, that provides fine-granular visibility of the software at a package level. By monitoring all vulnerability feeds and providing relevant, contextualized data to support workflow management of issues across the organization, Cybellum ensures that product security teams can cope with the upcoming challenges and comply with standards and regulations.

I am more than happy to engage with anyone who subscribes to these challenges and is looking to advance in the security digital transformation journey ahead.

 

 

By ASAF ATZMON

Cybellum's Automotive Strategy Lead. A seasoned manager with over 20 years of experience in general management, innovation, product strategy, product management & marketing and business development. I'm a big believer and advocate for user-driven product design and design thinking methodologies to build a successful product strategy with high chances of a market-product fit. My expertise span a diverse set of domains including Cybersecurity, Automotive, IoT, Networking, Digital TV, IP Television, Content Recommendation, Video Networking, Consumer Web & Mobile.