To receive more content on automotive cybersecurity, follow us on Linkedin.
We believe that one of the major pains in the industry right now is the multitude of available guidelines and best practices. ENISA’s report provides a great overview of what’s out there..
Between the EU’s C-ITS, NHTSA, Auto-ISAC, UNECE, BSI, ETSI, SAE J3061 and ISO 21434, there are more than enough guidelines and regulations, repeating in many cases the same or similar requirements and recommendations. The report not only provides a great overview of these standards and best practices, but also summarizes them into very clear guidelines.
However, there are many challenges in adhering to these guidelines. In these blogs series we will address some of these challenges and offer possible solutions.
But first, let’s make some order in what’s ahead of us. The report suggests to organize this huge task into the following categories:
- Policies – Which procedures and policies we should have that will ensure proper automotive security.
- Organisational Practices – How should we behave as an organization that will ensure proper automotive security.
- Technical Practices – Which technical practices we should implement to ensure proper automotive security.
The report provides policies guidelines in four categories:
1. Security by design
Among other recommendations, the guidelines suggest a “shift left security” approach. Consider security already in early stages of the design. In addition, implement a Secure Development Lifecycle (SDL) approach and DevSecOps such that security is taken care of during each development phase.
Our experience suggests that there are two major obstacles on the way towards this goal:
- Software obscurity through supply chain – The reality of the automotive market is that OEMs buy subsystems from Tier-1s, and Tier-1s buy software and components from Tier-2s. This leaves OEMs with software binaries that were developed elsewhere, without enough practical controls to truly enforce security practices early in the development process.
- Lacking tools – Most tools available in the market only provide a partial answer for automotive software:
- Source-code analysis tools – do not analyze the entire software stack including the OS or framework itself, third-party software libraries, or any other security risks that may enter the final product – the firmware.
In addition, there are various software development standards that are commonly used in the automotive industry, but general purpose tools do not support them.
- Binary analysis tools – do not support the binary formats that are in use in the industry, many of them proprietary. In addition, most do not support the CPU architectures that are common in automotive.
2. Privacy by design
The guidelines suggest that local and international privacy regulations must be implemented, together with Privacy Impact Assessments (PIA) and regular privacy audits.
Indeed, our own experience is that this is a serious issue. Many types of privacy information leaks are found in real world firmware. Among the findings are default passwords, plain text passwords, email addresses (for example: developers email addresses), IP addresses and more. Apparently, this information is inadvertently added during the build process and is not detected by pre-compilation security means.
As the report suggests, proper security technologies and processes should be put in place to prevent privacy information leakage. These mechanisms must validate and prevent privacy information leakage every external deliverable prior to its release.
3. Asset management
The report suggests vendors to maintain an inventory of their assets – the components and their accompanying software. In addition, vendors must implement a change management process.
Managing assets and risks is challenging. As cars and subsystems transform from mechanics and electronics to software and data, different risks are introduced.
- Cyber security vulnerabilities – Maybe the most obvious risks. Systems are faced with publicly known vulnerabilities, zero-day hacks, and various security related hardening misconfigurations.
- Adherence to standard industry practices – There are many industry-specific regulations, standards and best practices related to the software design lifecycle. These practices relate to the design, development and maintenance of software. Not adhering to these practices may carry varying levels of risk to the organisation.
- Software licensing risks – Using open-source speeds up development but requires a careful review of each software library’s license. With tens to hundreds of libraries used in each product, tracking licenses across the entire company becomes a tremendous challenge.
Keeping track of the above for each car model and its subsystems is a real challenge. Once a security risk or concern is identified, vendors should be able to drill-down to the exact list of on-the-road VINs affected by the risk, or in the case of suppliers, the list of product serial numbers.
This mapping between physical asset types, each specific asset id, and each software revision, is the essence of a risk-focused asset management system that maintains not only the metadata about the assets themselves but also the details about the risks for these assets.
4. Risk and Threat Management
Here, the report asks vendors to “adopt an approach to risk management dedicated and suitable for the automotive sector, considering emerging threats and attack scenarios targeting smart cars” (guideline PS-11). It also asks to perform “cybersecurity risk analysis from the very early stages” (PS-12) but also to regularly (“every 6 months or more frequently”) monitor security vulnerabilities, in particular for post-production vehicles (PS-13).
The main challenge here is indeed the frequency of vulnerabilities monitoring. Take for example an AGL based component. Just in the last three months there were 138 vulnerabilities reported for the Linux kernel, potentially affecting such a component. It is therefore irresponsible to perform this monitoring at 6 months intervals. The reason it is mentioned as an example in the guidelines is the fact that the industry is currently having difficulties in keeping up with anything more frequent.
To summarize the Policies guidelines:
To meet ENISA’s guidelines in the Policy category, a solution must:
- Manage assets, not just vulnerabilities – Keep track of vehicles, components and versions, and map them to identified risks.
- Analyze closed source binaries with no need for source code.
- Support automotive CPU architectures such as Arm®, TriCore™, Renesas and more.
- Support automotive binary formats.
- Detect cyber security and other risks automatically and continuously, from early development phases to post-production on-the-road car fleets.
- Detect the privacy violations and different kinds of information leakage.
- Provide the facilities to become an integral part of a DevSecOps flow – namely the ability to automatically perform all of the above analysis as part of the development lifecycle.
Note: One item that seems to be missing from the report is compliance to software coding standards – mainly AUTOSAR and MISRA, which are very common in the automotive industry. While these are not an end goal by themselves, they are very common means to reach that goal.
Cybellum Security Suite comes to the rescue
Cybellum Security Suite is a complete risk assessment solution for automotive components. It provides visibility to closed source automotive software, exposing cybersecurity threats – both publicly known and zero-day issues as well, using static and dynamic analysis engines.
It is fully automatable and integrates with software management systems and issue tracking software, enabling a DevSecOp approach to automotive security.
Automotive cyber security challenges can only be addressed by risk assessment software that is designed for automotive. Cybellum Security Suite provides such a solution. It enables OEMs and suppliers alike to automatically assess their existing components for an entire range of risks.
For a demonstration of how Cybellum Security Suite can change how your organization performs software risk assessment, contact us.
In the next part – Part 2, we will cover organizational practices. We will review guidelines for the relationship with suppliers, and training for employees and external parties. In addition, software and incident management guidelines will be reviewed as well.
Did you find this interesting? Share it with others: