The pillars of automotive risk management
Posted: February 24, 2024
Abstract
The automotive industry grapples with inherent software and hardware risks, necessitating collaboration across various organizational departments.
Key stakeholders, including Research and Development (R&D), risk management, compliance teams, and specialized entities like the Vehicle Security Operations Center (VSOC) and Product Security Operations Center (PSOC), must collectively address these challenges. To achieve a comprehensive understanding and assessment of risks, it is imperative to aggregate, integrate, and analyze diverse threat sources such as component/vehicle abstract models, vulnerabilities, threat intelligence, and the Vehicle/Cloud Intrusion Detection System (IDS), among others.
This article aims to delve into the myriad threat sources, elucidate the process of risk assessment, and highlight the value generated for stakeholders within both Original Equipment Manufacturers (OEM) and their supplier organizations. Emphasizing a secure-by-design approach, the discussion will encompass the unique considerations and benefits for each user involved in ensuring the safety and integrity of automotive systems.
The challenge
The automotive industry needs to address these challenges:
- OEMs and Tier 1/2 suppliers need to cyber secure the vehicles and follow the ISO/SAE 21434 Road Vehicles Cybersecurity Engineering standard for UN Regulation No. 155 – Cybersecurity and cybersecurity management system compliance required for certification for vehicle type homologation and approval
- The sources of the risks required to be addressed in ISO/SAE 21434 originate from:
- System abstract model (Clause 15)
- Vulnerabilities (Clause 8)
- Penetration testing (Clause 10)
- Real-time security events (Clause 15)
- The vulnerabilities and threats need to be analyzed and assessed in the whole context
- Risks must be mitigated and reduced to an acceptable level in an optimal fashion
- The whole process needs to be cost-effective, efficient and effective
High-level process
To optimize risk management, both OEMs and their Tier 1/2 suppliers must implement a robust system ensuring the production of cyber-secure and regulation-compliant vehicles. Various methods exist for achieving this objective, ranging from manual text and spreadsheets to fully automated, state-of-the-art solutions. As the industry increasingly embraces automated, product-based processes, our focus is on reviewing and evaluating the components integral to constructing such a solution.
Within an integrated framework, information sourced from diverse channels needs to be channeled into a central tool for normalization, analysis, and risk management. A critical challenge is the lack of standardization in information exchange among different products. In addition, compounded by complex and sometimes restricted interfaces due to security considerations, these issues often lead to manual processes, resulting in the use of outdated or untrusted information sources.
“A critical challenge is the lack of standardization in information exchange among different products.“
A notable example is the Software Bill of Materials (SBOM), which, in a trusted and connected environment, would ideally propagate seamlessly along the supply chain using standard APIs. However, due to trust issues, OEMs and Tier 1 suppliers often hesitate to rely on SBOM information from their suppliers further down the chain. Instead, they opt for dedicated tools to scan and reverse engineer images for SBOM extraction and additional information.
This article will propose solutions, outline methods, and provide guidance on industry best practices to achieve effective risk management. By addressing these challenges, we aim to steer the industry toward a more secure and standardized approach in pursuit of our risk management objectives.
The following figure depicts the concept:
Figure 1 – Solution architecture overview
Pillars of risks
Considering the sources of information, including instances of bi-directional information exchange, we will identify key contributors and explore the unique value each imparts to the overall process. It’s important to highlight that this approach is designed to foster synergy, whereby the collective value exceeds the sum of its components. This synergistic integration ensures that the information exchange between various sources enhances the effectiveness and efficiency of the entire system.
The following picture focuses on the pillars:
Figure 2 – Solution architecture – sources
Security requirements stand out as a pivotal source of information, though they are not a threat in themselves but rather a derivative thereof. Frequently, these requirements originate from OEMs that have conducted their own early Threat Analysis and Risk Assessment (TARA) processes, leading to the formulation of specific security requirements. These requirements are subsequently cascaded down the supply chain to Tier 1 suppliers and beyond. Notably, as a current industry trend where OEMs are seen increasingly developing software in-house, becoming their own Tier 1 suppliers, the application of these security requirements extends to them as well.
The market offers a plethora of requirement management products, some tailored specifically for the automotive industry, facilitating the organized and systematic handling of these security requirements throughout the supply chain.
System abstract model
This constitutes the output of the engineering process undertaken by OEMs and Tier 1 suppliers, encompassing components like sensors, actuators, ECUs, domain controllers, High Power Computers (HPC) equipped with hypervisors, and more. The model also incorporates network topology and configuration, inclusive of wired and wireless interfaces.
It is essential to recognize that, historically, the industry adhered to a waterfall development model (plan your work and work your plan). However, both the software industry as a whole and, specifically, the automotive sector have transitioned to an Agile way of working. This shift implies that the entire information and model are not available from day zero but are continuously updated, refined, and clarified over time.
As a consequence of this iterative approach, modeling tools must support multiple levels of abstraction. Notably, not all tools in the market offer this capability, as some are designed to support a single flat model.
Additionally, as the system model evolves incrementally, an ongoing incremental TARA process becomes essential. This iterative nature is particularly evident as the backlog is detailed, translated into user stories and incorporated into sprints. This leads to new security requirements that need to be addressed. Unfortunately, not all tools available in the market align with and support this process. Many adhere strictly to the ISO/SAE 21434 waterfall-like V-model which is not inherently adaptable to the iterative nature of the Agile development process. Iterations in the TARA are specified only for extreme cases such as new threats discovered after-market and as a result, appropriate mitigations need to be implemented.
Vulnerabilities (based on binary image and source code)
As opposed to the system abstract model, vulnerabilities are a concrete item from which information can be extracted. This is achieved during and after the R&D process such as compiling flags and other misconfiguration, Static Code Analysis (SCA), Common Vulnerabilities and Exposure (CVEs), Common Weakness Enumeration (CWEs), etc. Dynamic techniques and simulations also exist.
The vulnerabilities discovered need to be fed into the system for the generation of threat scenarios that lead to damage scenarios. Not all items discovered are relevant and maintain their original perceived Common Vulnerability Scoring System (CVSS Scores) all along the way. For example, a critical vulnerability found in the operating system relates to a floppy disk driver. However, there are no floppy disks in the vehicle, so it is not relevant and does not need to be addressed. Similarly, a network interface vulnerability found in an ECU that is located behind two gateways can be disregarded since the local network segment can be regarded as secure.
To improve the value derived from vulnerabilities, they can be augmented by integrating threat intelligence information, thereby adjusting the prioritization level for handling each vulnerability. For instance, a medium CVSS score vulnerability might receive higher priority if threat intelligence information reveals it as a favored attack vector utilized by hackers targeting the specific OEM.
A variety of tools are available in the market, some are generic and widespread for the embedded field, while others are more appropriate and specialized for the automotive world. There is a huge diversity in quality and quantity between the results generated by the numerous tools.
Penetration testing
Penetration testing resents the final line of defense before production. While any discovery at this stage might be considered an escape bug—a manifestation of a development process failure—acknowledging the inevitability of human errors is crucial. Instances of intrusions detected post-production or, worse, successful cyber-attacks on operational vehicles highlight potential shortcomings in the penetration testing process, indicating that certain vulnerabilities eluded detection (as well as preceding security measures).
“Swift bug fixes during the initial phases are not only cost-effective but also prevent significant delays in software delivery.”
It is essential to recognize that not all vulnerabilities and attack methods are known during the penetration testing stage, and additional vulnerabilities may surface over time. This is a common occurrence in the dynamic landscape of cybersecurity, including zero-day attacks. Information gleaned from penetration testing, whether conducted manually or automatically, should seamlessly flow into a testing management tool for thorough analysis. Embracing a “shift left” approach, this integration should ideally occur during the development phase, aiding R&D teams in promptly addressing identified issues in the early stages of development. Swift bug fixes during the initial phases are not only cost-effective but also prevent significant delays in software delivery.
The market offers a variety of reliable automatic penetration testing and testing management tools, with a distinct advantage lying in tools specialized for the automotive industry—whether integrated or part of a comprehensive tool managing the entire cybersecurity process.
Real-time security events (IDS)
The true last line of defence and the only security dedicated, devoted and independent component in the vehicle. In some cases, this is also an active component functioning as an Intrusion Detection and Prevention System (IDPS). This function can be distributed in the vehicle, defending the network and/or the individual software components. In any case, all qualified security events are dispatched to the VSOC and through the Security Information and Event Management (SIEM) system feed the risk management system. The security events are analyzed in context by the risk management system to assess the potential impact on the vehicle and indicate how to take protective measures to minimize and reduce the risk scenarios that can lead to damage scenarios.
IDPS solutions exist in the market protecting the vehicle Car Area Network (CAN), Automotive Ethernet, Vehicle-to-everything (V2X) and the running software itself, such as Endpoint Detection and Response (EDR). They vary much in the method they operate, effectivity, form factor, etc.
Threat Intelligence
This type of information source holds the power to impact not only the severity but also, significantly, the priority assigned to security requirements and controls in response to emerging threats. By leveraging threat intelligence inputs, the R&D team gains the ability to strategically prioritize the implementation of security measures and tools. This proactive approach enables the organization to fortify its defenses more effectively.
Furthermore, the Risk Management group, armed with insights from threat intelligence, plays a crucial role in directing the entire organization to acknowledge and address these threats. This guidance ensures a focused allocation of resources in an efficient and targeted manner, enhancing the organization’s overall capability to defend against evolving threats.
Moreover, as previously noted, integrating vulnerability management with threat intelligence information significantly enhances the efficacy of the TARA process, amplifying its value proposition.
One can find companies offering this kind of specialized service or products that facilitate it.
The entire risk management solution must be constructed upon the aforementioned pillars. It’s important to note that not all components are universally present; for instance, intrusion detection can theoretically be achieved solely by monitoring vehicle telemetrics and identifying anomalies in behavior based on this information.
The comprehensive risk management system should ideally consist of seamlessly integrated products. However, as a general guideline, the number of integrations should be minimized, with a preference for all-encompassing, one-stop-shop solutions. These integrated products should efficiently cover diverse areas including system modeling, test management, and TARA within a unified framework.
Data fusion risk management in the context of TARA
The comprehensive solution caters for:
- One integrated solution, a single source of truth for all potential sources of risk
- Risk scoring in context relative to the full system model
- Driving efficiency in risk management by eliminating the manual fusion of component risk in a given architecture
The following picture focuses on the process:
Figure 3 – Solution architecture – process and output
The crucial aspect lies in the concept of “In context”: while numerous tools individually execute specific functionalities mentioned earlier, the meaningfulness of these processes emerges when they are collectively orchestrated. The comprehensive operation necessitates the fusion of information from all sources, enriching each source with pertinent insights from others to create a holistic view. Only when this synthesis occurs does the process attain completeness, enabling the optimal prioritization of risks and correct sequencing of mitigations.
This holistic approach ensures that risks are prioritized with precision, culminating in the production of a cyber-secure vehicle. This security is sustained not just during production but also throughout the aftermarket period when the vehicle has been on the road for numerous years. The amalgamation of information from various sources ensures a robust and enduring cybersecurity framework for the entire lifecycle of the vehicle.
Here are a few items that would be integrated into the system:
- Digital Twin (System Model)
- Item type
- Profiling
- Functionality
- Safety criticality
- Interfaces
- Connectivity
- Surroundings
- Topology
- Damage scenarios
- Affected asset
- Classification
- Violated security properties
- Impacts
- Safety incidents
- Catalog references
- Threat scenarios
- Type
- Results in Damage scenarios
- Attack path
- Attack steps
- Attack vectors
- Threat catalog references
- Feasibilities
- Risk level
- Threat CAL
- Risk treatment
- Controls
- Controls mitigation catalog reference
- Threat intelligence
- Threat actors
- Attack scenarios
- Image information
- OS type
- Version
- Size
- Date created
- Vendor
- Partitions
- Functions
- Software packages
- Dependency map
- Vulnerabilities
The aforementioned sources, along with additional inputs, are channeled into the comprehensive risk management system. This system processes the information and disseminates it to the pertinent users. It’s important to highlight that the information flow is often bidirectional, allowing each component within the system to exchange information either through the central risk management module or via a mesh network. Some of the processes may involve:
- Map image information to the system model
- Map image information, SBOM to system model and items
- Generate threat scenarios
- Add item information derived from updated vulnerabilities mapped to existing or new threat scenarios
- Add vulnerabilities to threat scenarios
- Generate threat scenarios with appropriate risk severity
- Add and update mitigations to attack step controls
- Map mitigations as new controls on attack steps
- Update security goals and claims
The product of the risk management system
The following picture focuses on the system output and beneficiaries:
Figure 4 – Solution architecture – beneficiaries
Users of the system who can enjoy the value created include but are not limited to:
- R&D
- Risk Management
- Compliance
- VSOC
- PSOC
While not all organizations may necessarily involve all the mentioned bodies in the process, it is highly crucial and valuable to strive for their inclusion.
Output and value generated include among others:
- Extended system model
- Threat and damage scenarios
- Traceability to goals and claims
- TARA reports
- Integrations to other tools
The benefits of such a system are:
- Synchronized single source of truth with information sharing and reuse
- Enhanced knowledge and value created
- Risks scored relative to the full system
- Focus on addressing the prioritized real severe risks
- Suitable for complex environments and agile way of work
- Continual compliance left shift during design for R&D and aftermarket for VSOC
- Ensures customer success and overloads works when needed
- Cost savings
- Fewer human resources
- Better risk assessments
- More efficient risk remediation
Summary
Risk management is an indispensable process for every participant in the automotive industry, driven by regulatory requirements and the imperative to deliver cyber-secure vehicles. To meet these objectives, it is essential to amalgamate all potential sources of information into a unified and comprehensive risk management system that caters to the diverse needs of both the OEM and its suppliers. The challenge lies in implementing such a system in a manner that is both effective and efficient.
