The loss of life or any extensive damage due to a cyberattack on a vehicle would have enormous ramifications. The car’s brand would be irreparably damaged, together with immense financial losses. From a financial perspective, an OEM (Original Equipment Manufacturer) should invest in preventing anything close to such a financial and public relations disaster. Fortunately, we needn’t wait for OEMs to decide to invest in cybersecurity. By 2024, Tier 1 suppliers and OEMs have a shared goal to secure cars against cyber events by complying with regulations such as The UNECE World Forum for Harmonization of Vehicle Regulations (WP. 29) (UN – R155) or the Chinese GB/T.
Reaching compliance requires deploying vulnerability management processes by both OEMs and Tier 1 suppliers. At times, the process of deploying vulnerability management processes is similar, and at other times, diverge completely. This article reviews the various components and phases of the process in regard to both OEMs and Tier 1s.
The Vulnerability Management Process
Vulnerability management is a continuous process designed to improve the safety and security of vehicles. One part of this process maps the software components used in the ECUs (Electronic Control Unit) otherwise known as the SBOM (Software Bill of Material) and matches them against known CVEs (Common Vulnerabilities and Exposures). The attack feasibility is analyzed, possible lateral movement and attack vectors are identified, the risk to the ECU and/or the vehicle is determined; and finally, a proposed mitigation plan is generated with the target of risk minimization.
This entire process is documented and reported to obtain the regulatory cybersecurity certification that is required for vehicle type approval. This continuous process needs to be carried out for many years after the vehicle is introduced as vulnerabilities may be discovered at any stage. As a general rule, by following standardizations such as ISO/SAE 21424 will inevitably lead OEMs and Tier 1s to comply with the regulations.
Let’s examine the various phases in the vehicle lifecycle that are relevant for vulnerability management.
Software Development
Historically, Tier 1 suppliers have developed the software running in ECUs. OEMs integrated the ECUs into the vehicle, demonstrating that Tier 1s were the players most invested in vulnerability management at this stage. In comparison, OEMs’ interest was focused on the vehicle as a system, analyzing kill chains and threats to the vehicle. However, in recent years the dominant trend has led OEMs to take more responsibility for software development. Volkswagen’s vw.os (Volkswagen Operating System) and Mercedes-Benz MB.OS are two prime examples.
In some brands, Tier 1s are manufacturing the IVI (In-Vehicle Infotainment) but are required by the OEM to integrate third-party software applications, such as a navigation applications. In others, the CGW (Connected Gate Way) Tier 1 is required to install the IDPS (Intrusion Detection and Prevention System) from a vendor selected by the OEM.
Furthermore, since a major source of future income for OEMs is expected to flow from services, OEMs invest significant resources in developing their own proprietary software. Many OEM groups have already established their own central software development organizations, for example the Stellantis SWX initiative, Volkswagen CARIAD, among others.
This OEM developed OS might be shared among brands within the OEM group or even by brands that belong to other OEMs. Various software applications running on top of this OS also requires monitoring.
Early vulnerability detection and timely mitigation reduce overall development costs and time, by enabling R&D teams to address issues while still in their initial phases. In many cases, detecting a vulnerability closer to the ECU’s delivery leads to extensive software refurbishing, and additional extensive testing, resulting in late delivery and increased expenses.
Proposed course of action
The OEM and the Tier 1 must adhere to a very similar process by following SecSDLC (Secured Software Development Life Cycle), monitoring and addressing any discovered vulnerabilities. Many issues can be avoided beforehand by using the latest library version, while in parallel, verifying that there are no critical or major CVEs (Common Vulnerability and Exposure) relevant to the design and planned implementation.
OEMs perform the process and instruct their Tier 1s to follow a specific procedure and to develop according to standards such as A-SPICE (Automotive Software Performance Improvement and Capability dEtermination) and ISO/SAE 21434. Tier 1s must then document and report the software status.
OEMs should periodically inspect, either independently or by proxy, that their Tier 1s are following the process correctly. Tiers 1s are required to document the development process and provide OEMs with reports supported by evidence and artifacts that prove their claim of proper secured development process.
OEMs and Tier 1s must document the entire SBOM, including all the components originating from the supply chain. This SBOM should be conveyed to the OEM asset management system using a standard API (Application Programming Interface) such as SPDX (Software Package Data Exchange), CycloneDX or SWID (SoftWare Identification).
This information must be kept up to date and reflect the actual current state of the ECU version.
In this area, the industry still has long way to go. Currently, the SBOM information provided by Tier 1s is usually incomplete, outdated, and created without standard interfaces.
In case the SBOM is not available, the vulnerability management product can perform an automatic SBOM discovery process, for example, by reverse engineering the image and extracting the relevant information out of it. In general, this method has merit in that it doesn’t need to relay on any external source of information since it’s self-contained using the image exclusively. Note this method is not perfect since the discovery is not complete in many cases. This varies from tool to tool. However, this is the best independent method available.
Not everything is about security! As part of the supply chain management, OEMs can score their Tier 1s based on the safety and security of the software provided in the ECU. Having this as a consideration in the vendor selection, OEMs can then opt to work alongside those Tier 1s that provide a safer product with fewer critical vulnerabilities.
Certification for cybersecurity compliance for vehicle type approval
Tier 1s are not required to pass any certification but they need to support the OEM’s certification. Therefore, the Tier 1 should ideally provide full and updated information (as mentioned above) at the end of the development phase.
The OEM has a very different role. It must collate the information from internal and Tier 1 sources into a central asset management system to assess the vehicle’s end-to-end vulnerability.
When the SBOM for one of the components is not available in its entirety, or it is not trusted (and some claim this should be the process in any case), a reverse engineering process should be conducted to extract the SBOM.
The vulnerability management process should be conducted by the OEM to generate the vehicle report required for the audit. To provide a full picture, information from Tier 1s should be included in the report because it’s used to establish if the vehicle and all its components are cybersecurity safe and adhere to regulation requirements.
All the aggregated material including the reports, evidence, and artifacts should be submitted and presented by the OEM to be inspected by the auditor. The successful completion of the entire process, including CSMS (Cyber Security Management System), will eventually merge into the expected cybersecurity certification required for the vehicle type approval.
Postproduction Vulnerability Monitoring and Risk Mitigation
A continuous vulnerability monitoring process must be conducted while the vehicle is on the road.
Tier 1s must monitor their ECUs, and immediately inform OEMs if they discover a critical or severe vulnerability. Tier 1s must relate the potential impact of the vulnerability, and propose a mitigation plan, for example a software update (over the air, next schedule service, recall, etc.)
OEMs must monitor the entire fleet, receive feeds from their Tier 1s, and perform at the VSOC (Vehicle Security Operations Center). This is a process of forensics and analysis that determines the best course of action to mitigate a new threat. The OEM process is much more comprehensive and complex requiring a higher skill level and qualifications. The VSOC can be home grown by the OEM, outsourced to an MSSP (Managed Security Services Provider) or a combination of the two approaches.
Tier 1s and OEMs need to take action to mitigate newly discovered vulnerabilities by taking corrective action to remediate the vulnerability. This can be done for example by applying a patch to a library, updating a package to a new version or replacing with an alternative software. The new image will be installed on the vehicle fleet for example by using FOTA (Firmware Over the Air).
Whenever there is a new software release, the entire vulnerability management process must be executed to ensure the cybersecurity of the software taking into account possible lateral movements and kill chains.
Conclusions and Insights
By working in parallel, OEMs and Tier 1s can manage and minimize the risks resulting from software and hardware vulnerabilities. Keep in mind that the OEM is the stakeholder for vehicle risk management. The Tier 1 risk management is relatively minor to the ECU.
Tier 1s and software-developing OEMs need to start the monitoring process in the early stages as part of the SecSDLC (Secure Software Development LifeCycle). It is imperative that Tier 1s provide OEMs with the necessary documentation for cybersecurity certification to obtain type approval.
For auditing, OEMs must aggregate their own material in addition to their Tier 1s material.
The entire process needs to be automated by using a top-quality automated vulnerability management product for optimization, data storage, quality improvement, cost reduction, and delivery schedule shortening.
OEMs and Tier 1s that lack the capacity, knowledge, or incentive to perform vulnerability management should outsource this activity to a trusted and experienced service company that can support and perform the entire process using an automated product for the reasons mentioned above. The vulnerability management process, through the entire lifecycle of the vehicle, is imperative for safety and a must for regulatory compliance.
