It’s a fast moving world, isn’t it?
And vehicles in today’s world are faster. With the Speed one more thing that is increasing is the technological aspects of today’s automotive industry. It looks Day by day vehicle are becoming more user friendly but from and Automotive engineer point view it’s becoming more and more complex.
Connectivity is becoming an important aspect of new era mobility. In the world of Internet of things and Big-Data connection to the external world is prominent. But with more exchange of data to the external world system become more vulnerable.
The connected cars are equipped with a number of new technologies and features that are not possible without an Internet connection. For example, drivers now have the possibility to receive service information and traffic reports through the vehicle’s dedicated cellular connection. They also have the possibility to connect their smart-phone to the vehicle (Bluetooth, Wi-Fi) and use its Internet connection to enable some of the new features of the vehicle’s entertainment center. Through this center they can browse the web, access social networks, stream on-line content, etc. Many other services exist depending on the vehicle type and manufacturer.
According to the Business Insider report, there will be 380 million connected cars on the road By the year 2021.
Even though the connection to the outside world enables many new services, it also exposes the car and its software to a potential remote attack. There has already been a number of successful cyber-attacks on connected vehicles such as the attacks on Jeep Cherokee, Tesla S model, Nissan electric car and Chevrolet Corvette. As the production of these vehicles increases, so will the importance of securing them.
How an Attacker Gets in.
It is important to understand about the attack surfaces (Figure 2) which are exposed and can be used for the attacked. In modern vehicle you will easily find Server connections, Mobile Apps, Cellular network connection, Keyless entry, OBD port, Infotainment system, Wi-Fi Connectivity, Bluetooth, etc. for providing the accessibility to the external world data or means to change the information to the external world and any of these can act as the attack surface for a hacker.
Let’s take an example of Vehicle Cluster (Figure 3). We will analyze Instrument Panel Cluster (IPC) in the below given item to understand what can be the possible attack surfaces, how they can be attacked by some hacker and what can be possible effects of these attack. The system is simplified and abstracted in order to illustrate activities.
Note: The example and its work products are provided for illustrative purposes only and are not intended to imply any particular approach for practical use.
So to understand the complete picture of attack surfaces focusing just on IPC can be a wrong approach. We need to look at complete system which provide the open door for the attacker and a possible vulnerability. Above figure provide a high level model of the IPC interacting with Infotainment system and Gateway ECU. Below in the table there are some possible attack surfaces and how they can be used for attacks are detailed. IPC do not have any direct interface with the external world but still it could be possible to compromise the features of IPC through vulnerability in the externally communicating ECUs like Infotainment or Gateway ECU. IVI and Gateway can have Wi-Fi, Bluetooth, GPS connection, LTE, Multimedia Playback, USB ports etc., all these can act as the attack surfaces if not properly managed.
Analyzing what attacks are possible from these attack surfaces some are listed below. Table 1
Now after the above analysis of the attack surface and the methods let’s understand that what can be the possible functional effects of them in Table 2
These can be possibilities how an attack can be performed by a hacker. MITRE ATT&CK® is a globally-accessible knowledge base of adversary tactics and techniques based on real-world observations. Which can be accessed and used to understand what kind of attacks are possible on a specific attack surface.
Security Concept:
(Figure 4) Security is all about risk mitigation.
We have owners, those who benefit from a product or service (user, manufacturer, business owner, etc.). Owners want to protect assets, anything that has some value in the product or service (data, code, reputation, etc.). Than we have threat agents, a person (malicious hacker, government, etc.) that can manifest a threat, anything that is capable of acting against an asset in a manner that can result in harm. To manifest a threat, the threat agents will explore vulnerabilities (weakness in the system) via an attack vector, a method or pathway used by the threat agent to access or penetrate the target system.
Security as a process throughout Product life cycle: ISO 21434 overview
It’s a common misconception that cyber security is all about technology (hardware and software). Technology is obviously a massive part of cyber security, but alone it is not enough to protect from modern cyber threats. Processes are key to the implementation of an effective cyber Security strategy. Processes are crucial in defining how the Organization’s activities, roles and documentation are used to mitigate the risks. Processes need to adapt with quickly changing cyber threats. (Figure 5).
ISO 21434 helps us defining
Cyber security policies and Process, manage cybersecurity Risk and Foster Cybersecurity culture.
It supersedes and expands on the same basic framework developed by SAE J3061™: Cybersecurity Guidebook for Cyber-Physical Vehicle Systems. ISO 21434 addresses the cyber security within the Vehicles and enables to keep up with the changing technology and attack methods. Its help building a common understanding throughout the supply chain by providing Vocabulary, Objectives, requirement and guidelines.
Let’s briefly see different clauses of the ISO and their major takeaways.
Management of Cyber Security (Clause 5 and 6): These clause realizes the requirements and recommendations related to the implementation of the organizational cyber security policies, rules and processes for overall cyber security management as well for project related cyber security amendment.
Continuous Cyber Security Activities (Clause 7): defines the cyber security activities need to be performed during all the phases of the product lifecycle.
This includes Cyber Security monitoring, Cyber Security event assessment, Vulnerability analysis, Vulnerability Management.
Risk Assessment methods (Clause 8): Defines the methods for determining the cyber security risk. All Risk Scenarios should be assessed against SFOP: Safety, Financial, Operational, and Privacy. Impact Ratings for Each Impact Category is defined in terms of Severe, Major, Moderate, Negligible. Allows for the following approaches for Risk Assessment: Attack Potential-based, Attack Vector-based, CVSS2
Concept Phase (Clause 9): This clause defines the item which is required to perform the subsequent activities. It also provides cyber security risk determination and defines cyber security goals.
Product Development (Clause 10): This clause corresponds to the left leg of the V model defining the specification of cyber security and architectural design and the right leg is about integration and verification activities.
Cyber security Validation (Clause 11): Describes cyber security validation of an item at the vehicle level.
Production (Clause 12): Provide requirements for security aspect of fabrication, Assembly and/or calibration of an item or component.
Operation and maintenance (Clause 13): Describes activities need to be performed after the production which includes incident response and updates to an item or component.
Decommissioning (Clause 14): Describes considerations that relates to decommissioning of an item or component.
Distributed Activities (Clause 15): Supplier management requirements.
Following the V model for development, figure 6 shows the mapping of the nominal V development workflow and ISO 21434 workflow for product development and the corresponding phases.
Designing a secure Automotive Product:
Performing Threat Assessment and Risk Analysis (TARA)
The main aspect of designing a secure product can be to identify the assets which need to be protected. ISO 21434 define the asset as: Something for which the compromise of its cybersecurity properties can lead to damage to an item’s stakeholder. Risk Assessment Methods of ISO 21434 can be followed to understand the methodology of identifying the asset of the item and do Threat and risk assessment (TARA). For TARA it is important to have details of Item, Item-Boundary, function and Architectural design.
In Clause 8 the risk assessment methods defined make use of the following generic modules that can be called systematically, and from any point in the lifecycle:
- Asset Identification: Identification of damage scenarios and assets of an item or component.
One way can be to first identify the components and their functionality of the item. Define all the assets and mention the cyber security property that asset possesses in terms of Confidentiality, Integrity and availability. Than due to compromise of that asset what damage can be done thus it can be understood that whether that asset need to be considered for threat and Risk analysis. ISO 21434 ANNEX G provides an example of how to identify an asset Figure 7.
On the identified assets the Threat Analysis and Risk Assessment is done from which the cyber security goals are identified and thus the cyber security requirements are defined.
- Threat Scenario Identification: The identification of threat scenarios to the cybersecurity properties of the assets under analysis.
There can be various methods to the Threat modeling such as STRIDE. ISO 21434 do not provide any specific method but calls for the Security Engineer decision for selecting the methods. By having an understanding of the damage scenario by brain storming also the threat caused by that damage can be analyzed. It is also important to understand that one damage scenario can result into multiple threat scenarios. A better threat analysis can also include the details of the threat agent, methods, tools, entry point etc. should also be documented for better risk assessment.
ISO 21434 ANNEX G illustrates an example of deriving the threat scenario from the Damage scenario Figure 8.
- Impact Rating: Estimation of the magnitude of damage or physical harm associated with a damage scenario.
It is very important to understand the impact to your system if the threat is exercised. By analyzing the damage scenario through the brain storming itself it can be identified that what impact will the threat will have. ISO 21434 define the basic impact categories As: Safety, Privacy, Operational, and Financial (SPOF). Though these are core impact categories but depending on the stakeholder these categories can be extended Loss of Image, Loss of intellectual property etc. Also the impact rating need to mentioned with the category which are defined in terms of: Sever, Major, Moderate, Negligible.
ISO 21434 ANNEX G illustrates an example of identifying the impact, impact category and impact level derived from the damage scenario Figure 9.
- Attack Path Analysis: Identification and linking of potential attack paths to one or more threat scenarios
It is important to identify the attack path as it leads us to possible vulnerability that an attack surface has. There can be two methodology to do the attack path analysis 1: Top Down Approach: Attack paths are identified base on the experience with known vulnerabilities of the similar system. There are various approached such as attack trees, attack graph, STRIDE etc… 2: Bottom Up Approach: It is also called inductive approach. Here analysis of the known vulnerabilities are done to identify the attack path. One thing is very confusing at this stage is that how it is possible to know all the vulnerabilities and attack paths? There are various data bases available such as National Vulnerability Database (NVD from NIST) and MITRE@ATTACK tool which can be concerned.
ISO 21434 ANNEX G illustrates an example of attack path analysis by attack tree analysis (Figure 10 and Figure G.5).
- Attack Feasibility Rating: The rating of the feasibility of attack paths based on the ease of exploitation.
After analyzing the attack path understanding its feasibility is important. To understand this we do the attack feasibility rating. ISO 21434 defines three method to analyze the attack feasibility rating:
1: Attack Potential based approach: As the core factor includes elapsed time, Expertise, knowledge of item, window of opportunity and equipment.
2: CVSS bases approach: includes attack vector, attack complexity, privileges required and user interaction.
3: Attack vector based approach:
At the initial stages of the product development attack vector based approach can be used as there is insufficient information available to identify attack path.
- Risk Determination: The determination of the risk value of a threat scenario.
Depending on the analysis of the Attack feasibility and Impact rating the matrix is defined to find the level of risk. Risk can be mentioned in the terms of values from 1 to 5 where 1 represents the lower risk level and the 5 represent the highest level. ANNEX J of ISO 21434 provides some sample risk matrix for examples(Figure 11):
Security Defense in depth
Security implementation can be considered to consist of layers namely: Hardware Security, Hardware based services, and software security services. Hardware security forms the base for HW security services and SW security services as it act as security enabler and enforcer. Over the Hardware security runs the Hardware security services and Software security services makes the used of the Hardware security services running over secure hardware in from of firewall, Intrusion detection system, whitelists/blacklists, anomaly detection, secure over-the-air updates, and upgrade capabilities.
Hardware security:
A Trust Anchor is a hardware framework upon which the other elements in the Cybersecurity Strategy rely. In order to secure sensitive material in ways that software cannot modify or manipulate, hardware-protected security anchors are used to establish protected storage behind a hardware barrier. There are many types of HTA such as Trusted Platform Module (TPM), Hardware Security Module (HSM), Smart cards/SIM chips, etc. [ESC-HSM. Some of the major services that HTA include are:
- Key Protection: Any private or secret key used for cryptographic transactions on the ECU shall be stored in a manner to prevent unauthorized disclosure and never be transmitted by any means. Any Public Key shall be protected against modification or substitution
- Memory Protection: Reduces code vulnerabilities by embedding pointer-checking functionality into hardware to prevent buffer overflow conditions that may be exploited by malicious code.
- Cryptographic Accelerators: Offloads encryption workloads to optimized hardware, improving cryptographic performance and making it easier to broadly incorporate symmetric or public key encryption into applications and communications processes.
- Secure code execution environment: Uses cryptographic techniques to create a unique identifier for each approved component, enabling an accurate comparison of the elements of a startup environment against a known good source and arresting the launch of code that does not match.
- Secure boot and software attestation functions: Detects tampering with boot loaders and critical operating system files by checking their digital signatures and product keys. Invalid files are blocked from running before they can attack or infect the system, giving an ECU its trust foundation when operating.
- Device identity directly on the device: Enables manufacturers to know the unique identity of every device, enabling secure identification and preventing unapproved devices from accessing the manufacturer’s network or systems. Technologies such as Intel EPID (Enhanced Privacy ID), which may be built into processors from Intel and others, also protects anonymity by allowing devices to be verified as part of a group instead of by their unique identity.
Additionally Random number generations, Monotonic Counters, JTAG authentication or lockout features etc. can also be there.
Software security
Secure Software can be defined as software developed or engineered in such a way that its operations and functionalities continue as normal even when subjected to malicious attacks. A software system or application offers some sort of services and makes use of varying types of resources. Any one of these components are a potential target of malicious intruders. Securing a software is like securing a device or a gadget that serves you. The level of risk will determine the ease with which it can be vulnerable to attacks. There are many ECUs with different capabilities in a vehicle. It is difficult or impossible to add hardware security capabilities to some of them, so co-operating processors and software-based security are also needed. Architectural techniques and software technologies that can defend the vehicle include:
- Input Data Validation: Data validation is the process of ensuring that input data is accurate and complies with the requirement of the input field. All data originating from outside the software, whether from clients’ or other interface applications, must always be treated as questionable.
- Data Protection and Privacy: Software must not only enforce access control but in addition, encryption as well. Encryption provides better data security and privacy. Data is vulnerable in any state and should be encrypted both in transit and at rest.
- Secure boot: Works with the hardware to ensure that the loaded software components are valid to provide a root of trust for the rest of the system.
- Partitioned operating systems: A commonly used software and hardware combination that isolates different processes or functions, such as externally facing functions from those that drive the vehicle, reducing the complexity of consolidating multiple systems onto a single ECU. Techniques, including virtualization and software containers, make it possible to update or replace individual functions without affecting overall operation, or mirror functions for redundancy and fast fail-over.
- Authentication: Authentication by a physical key for unlocking doors and starting the engine is no longer sufficient and is being augmented by software, as cars offer personalized services across multiple functions and profiles. Electronic keys, passwords, and biometrics need to be managed and authorized to access personal information, such as identity, telemetry, locations, and financial transactions. Similarly, the various ECUs in a vehicle need to authenticate communication to prevent an attacker from faking messages or commands.
- Enforcement of approved and appropriate behavior: It is very common for cyberattacks to try to jump from one system to another or send messages from a compromised component to an uncompromised one. Preventing this network activity is a key to detecting and correcting accidental or malicious threats. These functions can also prevent multicar attacks on an entire series of cars or snowball effects from cascading error propagation.
Network security
With in-vehicle networks carrying a mix of operational and personally identifiable information such as location, navigation history, call history, microphone recording. Protecting messages and data over the communication bus is critical for operational security, privacy, and consumer trust. Common protocols, such as controller area network (CAN), local interconnect network (LIN), media-oriented systems transport (MOST), FlexRay, automotive Ethernet, Bluetooth, Wi-Fi, and mobile 5G and newly proposed protocols, like dedicated short-range communications (DSRC) amplify the threat, as they increase attack vectors. Replacing unsecured legacy protocols with common protocols makes it possible to leverage good security techniques that have been developed in the computer industry. Hardware-assisted technologies that help to secure networks without significantly impeding performance, latency, or real-time response include:
■ Message and device authentication: Verifies that communications are coming from an approved source and protects authentications from being spoofed or recorded and replayed.
■Enforcement of predictably holistic behavior of all systems: Restricts network communications to predefined normal behavior and constrains abnormal types or volumes of messages so that they do not impair the vehicle’s functions.
■Access controls: Explicitly permit communications and messages only between pre-approved systems and sensors, block unapproved and inappropriate messages, and alert security systems about any invalid attempts.
Author:
Jagannath is Vehicle Function Software Construction (Network, Diagnostics, Bootloader) Team Lead and Cyber Security SME (Subject Matter Expert) with almost 9 Years of experience in development of Vehicle ECUs over AUTOSAR and Non- AUTOSAR platforms. Working over the various latest technology such as Automotive Secure Gateway he has done Safe Network communication implementation over Ethernet, W-Fi, CAN-FD as well as complete product security analysis and secure Software development.
Published in Telematics Wire
