Since July 2024, all control units in vehicles must be developed in accordance with the ISO/SAE 21434 standard, also known as ISO 21434. The lack of a corresponding security certificate in accordance with ISO 21434 can affect the homologation of the entire vehicle and, in the worst case, result in road approval not being granted. In order to be able to carry out a well-founded Threat Analysis and Risk Assessment (TARA), it is essential to identify the relevant assets. This blog article explains what an asset is, how it is defined in the automotive context and how to systematically identify them.
Asset Definition
Before we can start identifying assets, it is important to clarify the term “asset” in the context of product cybersecurity and apply it to control units. What may seem trivial at first turns out to be much more complex than expected.
ISO 21434 offers a rather vague definition of an asset. According to the standard, an asset is an object with value or an object that contributes to value. This broad definition leaves a lot of room for interpretation, which has both advantages and disadvantages.
The National Institute of Standards and Technology (NIST) offers several definitions from which we should choose the most appropriate one.
Definition from NIST SP 800-160v1r1 (Status 01.09.2024):
„Anything that has value to a person or organization.“
This definition is extremely imprecise and offers too much room for interpretation, which is why it is not sufficient in the context of control units.
Definition from NISTIR 7693 und NISTIR 7694 (Status 01.09.2024):
„Anything that has value to an organization, including, but not limited to, another organization, person, computing device, information technology (IT) system, IT network, IT circuit, software (both an installed instance and a physical instance), virtual computing platform (common in cloud and virtualized computing), and related hardware (e.g., locks, cabinets, keyboards).“
This definition also remains too general, as control units require a finer granularity and a more precise asset definition is necessary.
Definition from NIST SP 800-160 Vol. 2 Rev. 1 (Status 01.09.2024):
„An item of value to stakeholders. An asset may be tangible (e.g., a physical item such as hardware, firmware, computing platform, network device, or other technology component) or intangible (e.g., humans, data, information, software, capability, function, service, trademark, copyright, patent, intellectual property, image, or reputation). The value of an asset is determined by stakeholders in consideration of loss concerns across the entire system life cycle. Such concerns include but are not limited to business or mission concerns.“
This definition best captures the essence of the term “asset” in the automotive security context. It may not be perfect, but it comes closest to practice.
In order to formulate an optimal definition for embedded systems, we need to refine the above definition and adapt it to the specific context. A suitable suggestion is:
An asset is an item of value for the stakeholders concerned. An asset can be tangible (e.g. physical items such as smart sensors or integrated circuits, firmware, microcontrollers) or intangible (e.g. personal data, key material, configuration parameters, functionalities, services, intellectual property or other data/information/configuration parameters). The value of an asset is determined by the stakeholders with regard to potential losses over the entire product life cycle.
How to identify assets
Now that we have a definition of what assets are, we can go ahead and start identifying assets. The first question to ask is where do these assets come from? According to ISO 21434, they can come from the item definition and cybersecurity specifications. The question is: Is that enough? A clear “no”. These documents can help to identify assets, but depending on the level of detail in the documentation of both, it can be easy or impossible to identify assets.
Possible assets
The following assets can usually be found on control units:
- Firmware
- Key material (asymmetric keys, symmetric keys)
- Flags that are used to lock in-house debug interfaces
- Any information that must not be changed.
- Configuration parameters
- Individual functions of the control unit e.g. CAN message for door opening
Depending on the specification of the control unit, a wide variety of assets can be identified.
Asset origin / sources
According to ISO/SAE 21434:2021-08, the item definition and cyber security requirements should generally be sufficient. But what happens if an asset was overlooked in the software specification? Or if a new asset is identified during the vulnerability analysis? New assets can also be discovered unexpectedly during the Threat Assessment and Risk Analysis (TARA) and during the creation of the cyber security concept.
The following diagram clearly summarizes the possible sources for the identification of such assets.
Practical implementation of asset identification
In our example, we examine a fictional door control unit (DCU) that utilizes various memory components for different functions. Additionally, communication occurs between two microcontrollers within the unit.
According to the item definition, the DCU is structured as follows:
MCU1: Contains a bootloader that allows for the flashing of new firmware images. MCU1 also manages the primary logic responsible for executing all specified functions, such as locking and unlocking the doors and operating the windows.
MCU2: Also equipped with a bootloader for flashing new firmware images. This MCU handles the reading and processing of sensor data, which it then transmits to MCU1 upon request.
EEPROM: This memory component is used to store configuration parameters, such as controlling the speed of window movements. Additionally, it stores a public key used for the update process.
NAND: As the door control unit drives an integrated display within the door, some image sequences are stored in this external memory. The NAND storage is also used to keep the previous firmware of MCU1 and MCU2 as part of a dual-bank process.
RAM: An external RAM component is utilized because the internal RAM is insufficient for temporarily storing the new firmware during the update process.
This example illustrates the various types of memory and their specific roles within the DCU, which are crucial for the proper functioning and security of the system.
The various levels at which potential assets can be identified, as described above, are presented below:
1. Item Definition
- Firmware MCU1
- Firmware MCU2
- Public key (bootloader)
- Image sequences (depending on whether changes are permitted by the organization)
- Functions (e.g. open window, close window)
Configuration parameters for setting the window opening speed
2. Cyber Security Concept
Let’s assume that during the detailed specification of a measure from the Threat Assessment and Risk Analysis (TARA), it turns out that a certain public key for ensuring communication integrity has not been identified. It is also discovered that a logical flag has been overlooked which, if activated, switches the update process to an insecure flashing process – a kind of backdoor for developers. These examples are project-specific and are for illustrative purposes only. In this context, the following assets have been identified that need to be included in the overall list:
- Public key for SecOC
- Flag for bypassing the secure update process (backdoor)
3. Threat Assessment and Risk Analysis (TARA)
The result of the TARA are measures that must be implemented to secure the assets. Let’s assume that one of these measures is the implementation of a secure diagnostic function. It could be determined that a public key is required to ensure secure communication at vehicle level. The asset identified in this context would be as follows:
- Public key for secure diagnostics
This is just an example. It is quite possible that the need for a public key is not yet recognized at this point. In such a case, this asset would only be identified as part of the cyber security concept or in the software specification.
4. Software Specification / Software Development
Once the cybersecurity concept has been created, a more detailed specification must be made in the software domain. This could reveal that an additional flag has been specified that offers the option of disabling secure diagnostics. In addition, the software engineer may discover that the system requirements provide for a data specified by the customer to be stored securely and protected against manipulation. The following assets can be derived from these findings:
- Flag to disable secure diagnostics
- Customer-specific data
5. Vulnerability Management
- JTAG locking register
6. Customer Specification
In today’s development environment, the number of specifications provided by the customer has increased significantly and can include up to 20,000 to 30,000 requirements. This large volume of requirements makes the identification of assets much more difficult. It is therefore essential to promote comprehensive security awareness at all levels of product development. Each level must be able to recognize security-relevant requirements and inform the cyber security team accordingly.
One example of this is the customer’s requirement for secure boot, which was not taken into account in the cyber security concept as it was not identified as a necessary measure in the Threat Assessment and Risk Analysis (TARA). Despite this gap in the cyber security concept, the customer still demands the implementation of Secure Boot. It is therefore crucial to identify and secure the relevant assets in this case too, even if Secure Boot was not classified as a measure. The following asset was identified in the customer specifications:
- Public key for Secure Boot
