We need to talk about the item definition – the work product of ISO/SAE 21434 that forms the basis for all work in cybersecurity engineering for automotive systems. To do this, we’re going to expand a little. Imagine you want to build a house. But without a floor plan and without a blueprint. The result: nothing fits together. Pipes go nowhere, windows don’t fit into the walls, etc. This is exactly what happens if the creation of the work product item definition is skipped or approached incorrectly. With fatal consequences for cyber security.
Jan-Peter von Hunnius
The proper preparation of the item definition is the cornerstone for cyber security and the systematic reduction of cyber risks in a development project. The item definition is by no means just a document that has to be created somehow. Rather, a well-founded item definition is a roadmap, a dictionary and a crystal ball all in one.
It creates the prerequisites for precisely understanding the system to be developed, identifying attack vectors and finally carrying out a comprehensive threat and risk analysis (TARA) can be carried out. Anyone looking for shortcuts at this critical point must expect serious consequences.
The following will therefore explain in more detail why a well-structured item definition is so important and what role it plays in the overall picture of vehicle cyber security:
- to avoid unnoticed security risks,
- to ensure that gateways for attacks and points of attack do not (surprisingly) increase
- and that cyber security protection mechanisms are implemented proactively (and not reactively).
What is the item definition along the ISO/SAE 21434?
Essentially, the item definition describes the system you want to develop. Specifically, the following contents are worked out:
- Boundaries and interfaces (input and output): What goes into the system, how is data processed internally, what goes out of the system and how does the system interact with its environment?
- Functions and architecture: How is the system structured, what exactly does it do and how do the system components interact with each other?
- Assumptions and restrictions: What rules does the system follow and what constraints does it operate under?
Think of this structured elaboration of answers as a high-resolution map of your system. Without this granular map, all downstream risk mitigation processes, such as TARA and the needs-based development of cybersecurity concepts, are nothing more than trying to navigate in the fog without navigation.
Without an appropriate definition of the item, security analysts and cybersecurity specialists work with insufficient knowledge of the system. This makes it virtually impossible to adequately consider all critical attack possibilities and security risks and their possible consequences.
It is therefore not surprising that ISO/SAE 21434, the world’s leading standard for cybersecurity in the automotive industry, requires the careful development of the work product of the item definition in order to lay the foundation for comprehensive cybersecurity.
Deep dive into the item definition of ISO/SAE 21434: What exactly does the item definition describe?
Okay, let’s take a closer look at what the item definition actually describes.
Boundaries and interfaces
The boundaries of an item define what exactly the item interacts with (input/output) and where its scope ends. Input can be sensor data, messages from other systems, but also software updates that are delivered over-the-air. Output includes, for example, actuator signals that control the steering or communication messages that are sent to other electronic control units (ECUs).
Defining the boundaries of an item also includes identifying the physical and logical access points, including diagnostic interfaces such as JTAG, network interfaces (CAN, Ethernet, LIN, I2C, SPI, etc.) and the internal data flow between software components.
Overlooking internal interfaces in particular is a common (and serious) mistake, as these can become gateways for cyber attacks.
Incorrect configurations at the system boundaries are often exploited by attackers to gain unauthorized access.
An unprotected diagnostic port could, for example, enable an attacker to bypass authentication, inject malicious firmware and even change safety-critical vehicle behavior, e.g. disable braking systems or manipulate cruise control.
Understanding the boundaries and interfaces is therefore crucial in order to be able to fully and correctly identify threats and possible attack paths in the TARA later on.
Functions and architecture
The functions of an item define its intended purpose, while the architecture describes how these functions are implemented in the system.
A carefully crafted and documented item definition describes both primary and secondary functions (e.g. diagnostics) and records how the item interacts with other components in the vehicle and whether it works differently under different conditions, e.g. under normal driving conditions compared to emergency or diagnostic scenarios.
Error states and fallback mechanisms are also taken into account to ensure that the item retains a certain level of functionality and security in the event of a failure.
A thorough understanding of the item’s operating states, such as startup, normal operation, fail-safe mode and shutdown, helps to identify vulnerabilities in each of these phases.
For example, the bootloader phase is particularly vulnerable due to uninitialized security mechanisms. Attackers could also manipulate the fail-safe mode in order to deactivate critical safety functions, e.g. to prevent the activation of an emergency braking system or to put an electric power steering system into a non-responsive state.
In order to systematically identify potential vulnerabilities and attack paths later on, it is important to understand exactly how information and data flows between the individual components.
In addition to defining the system functions and the system architecture, the item definition must pay particular attention to the data flows of security-critical data.
Certain types of data are inherently security-critical, as they can be exploited for unauthorized tracking, data breaches or identity theft.
In contrast to keys for encryption, which are always explicitly protected, operational data such as location history, driving behavior or vehicle telemetry often remain unprotected unless they are identified at an early stage as assets requiring special protection.
These data types often only become assets worthy of protection within the TARA, which require protection mechanisms such as anonymization, encryption or strict guidelines for access control.
Assumptions and limitations
Each item definition is based on certain assumptions and must work within predefined constraints. Assumptions should be made explicit to avoid misinterpretation and incorrect cybersecurity planning.
Environmental assumptions may include the expected exposure to physical manipulation.
Operational assumptions can refer to whether the element always has access to secure firmware updates or whether it is assumed that it only interacts with authenticated components.
Regulatory action can also be taken here. For example, compliance with standards such as ISO/SAE 21434, ISO 24089 and UN R155/R156 can be mandatory.
Physical restrictions such as power limitations and the position in the vehicle can also fundamentally influence cyber security by determining which security mechanisms are necessary or even possible.
For example, firmware encryption may not be practical for control units with low computing power due to performance limitations.
If the assumptions and restrictions regarding an item are not correctly defined in the item definition, engineers may assume that firmware and message encryption is available when in fact it is not. This can lead to incorrect risk assessments and ultimately unprotected sensitive data.
Carefully defining assumptions and constraints ensures that cybersecurity risk assessments are based on realistic expectations rather than theoretical possibilities.
Ignoring these factors can quickly lead to incorrect threat modeling and ineffective cybersecurity measures.
Who defines the item according to ISO/SAE 21434? + Who defines the item and when?
The responsibility for defining the item varies depending on the level of the automotive supply chain and the phase of the product life cycle. In practice, different actors contribute to the definition of items at different times to ensure that all relevant aspects are taken into account.
In the concept and early development phase, OEMs define items at system level, such as an advanced driver assistance system (ADAS), an infotainment system or a powertrain control module.
The OEM’s task is to ensure that the item definition is consistent with the overall architecture of the vehicle, the functional requirements and the cyber security guidelines.
At this stage, cross-functional teams including systems engineers, cybersecurity specialists, security experts (and ideally regulatory and industry standards compliance teams!) work closely together to ensure the item definition is complete and consistent.
As development progresses, Tier 1 suppliers assume responsibility for defining items at subsystem level, such as an AEB module (Autonomous Emergency Braking) or an electric power steering system.
Tier 1 suppliers ensure that the item definition meets the OEM’s requirements and that all functional and safety-relevant aspects are consistently integrated at component level.
They work closely with cybersecurity experts to assess potential threats and document assumptions and limitations to facilitate the subsequent implementation of TARA.
Tier 2 suppliers and component manufacturers typically define specific hardware and software components such as sensors, electronic control units, actuators or network communication modules.
Their main focus is to ensure that their components meet the cyber security requirements of Tier 1 and OEM customers.
Tier 2 suppliers also document potential security limitations (e.g., the aforementioned performance limitations, cryptographic capabilities, and software update mechanisms) to ensure compliance with cybersecurity best practices.
Item Definition: Safety and Security?
Although safety and security aspects often overlap, they are traditionally handled by independent teams.
The integration of safety and security into a standardized item definition requires a high degree of coordination between safety engineers, cyber security teams and compliance experts.
This coordination effort usually pays off by ensuring that cybersecurity risks are considered along the functional threats, which usually leads to a more resilient system design.
Item Definition: Out of sight out of mind?
Important to understand: The item definition is not a one-off document. It must evolve throughout the vehicle lifecycle to reflect system updates, security patches and any changes to compliance requirements.
As new threats emerge, vehicle configurations change or cybersecurity standards evolve, the item definition needs to be revised. This is the only way to ensure that it remains relevant.
Specifically, the item definition must be addressed in at least these cases:
- During development: If system requirements, architecture or functional design change, the item definition must be updated to take new security aspects and dependencies into account.
- Software updates and patches: With every firmware or software update, the item definition should be re-evaluated to take into account possible new vulnerabilities or changes in system behavior.
- Changes to regulatory compliance: When new legally binding or industry-specific regulations (e.g. UN R155, ISO/SAE 21434, ISO 24089) introduce new safety requirements, the item definition must be revised to continue to meet the requirements of regulations and industry standards for state-of-the-art development.
- Vehicle platform integration: If an item is integrated into several vehicle platforms with different architectures, the item definition must take into account different operating environments, potential new interfaces and different attack surfaces.
- Incident response: If (new) vulnerabilities are discovered in the post-production phase, updates to the item definition can help the cybersecurity teams involved to assess the impact and determine appropriate countermeasures.
By defining responsibilities at each stage and continuously updating the item definition as a dynamic document, automotive and vehicle companies ensure that they manage cyber security proactively rather than reactively.
This structured approach not only proactively reduces security risks, but also supports compliance with evolving industry standards and can initiate a beneficial positioning of proper cybersecurity as a business driver when properly structured organizationally.
Next in the process: Why is the item definition so important for TARA?
The TARA methodology process is about identifying threats and possible damage scenarios, assessing risks and defining measures to limit damage.
This is actually logical: you need a clear understanding of the system under consideration. Precisely with the item definition. The connection is therefore obvious: an insufficiently elaborated item definition leads to incorrect risk assessments within the TARA.
For example, if an input is overlooked, a whole category of attack vectors can remain undetected, leaving vulnerabilities unaddressed.
For example, if the wireless capability of an ECU is not captured in the item definition, remote attack vectors may be completely overlooked in the TARA. Such omissions can ultimately create an entry point through which attackers can exploit unsecured channels, gain control of an ECU and thus carry out a massive attack on a vehicle’s internal network.
The meaning of the inputs in the item definition
As already mentioned, an item definition should precisely list the inputs from the environment and the internal interfaces within the system. To illustrate this, possible entry points for attackers are mentioned in this context:
- In an ADAS system, the inputs can include camera and radar signal data. Both can represent a potential attack vector if inadequately secured. Internal communication between the components takes place via Ethernet? Another potential gateway for attacks.
- A physical diagnostic port in every control unit can enable firmware updates. Without appropriate assumptions and security measures, this port becomes a gateway for attackers.
- Most electronic control units communicate via CAN, making this communication channel a prime target for attackers. Without proper security mechanisms, attackers can inject malicious CAN messages to disable safety functions, control actuators or even disable critical vehicle functions.
- The flash memory of an electronic control unit can be connected to the microcontroller via an SPI line. This line can be intercepted by an attacker in order to read or even change the software during transmission or in the flash memory.
The importance of outputs in the item definition and effects at vehicle level
In practice, the outputs of an item – be it commands to actuators or data sent to other control units – can have a serious impact on cyber security. A vulnerability in a single item can trigger an entire cascade in the vehicle:
- A compromised ADAS system could send incorrect commands that lead to steering or braking errors.
- An airbag control unit could fail to deploy the airbags in the event of an accident, which would have a direct impact on the physical safety of the occupants. Or, perhaps even more dangerously, an airbag could be falsely deployed without an accident, depriving the driver of visibility at high speeds.
How does the item definition form the basis for TARA methodology?
As already mentioned at the beginning, the item definition plays a decisive role as the basis for the implementation of the TARA methodology in accordance with ISO/SAE 21434 and thus ultimately for cyber security throughout the entire life cycle of the item and the vehicle.
Below is a visual representation of how the various components and elements of the Work Product Item Definition are linked to those of the TARA:
The functions and data streams of the item definition are usually the main candidates for the assets, the objects to be examined in TARA. It should be noted here: In some cases, data must also be explicitly protected from cybersecurity threats and thus treated as assets, especially when personally identifiable information (PII) is involved.
As already mentioned, the inputs and the internal interfaces of the item usually represent the main attack vectors. Accordingly, they are used to analyze the threat and attack paths in the TARA process. (Reading tip: Rethinking cyber security risk assessments in vehicle development)
The outputs of the item definition in turn form the basis for clarifying the extent to which an attacker or an exploited vulnerability can cause damage to the item or vehicle. The following therefore applies to the item definition: the outputs become the main source of possible damage scenarios.
Another focus is on the assumptions. The assumptions made in the item definition must be taken into account during TARA development, with particular relevance for out-of-context developments.
The challenge of “out-of-context” developments
Let us now look at the “out-of-context” elements from the point of view of the item definition. These are components that have been developed without consideration of a specific vehicle or operating environment. Although this approach offers flexibility, it also introduces new problems: the need to make specific assumptions.
But what does that mean? Specifically, for example, a component is being developed that is to be used in various vehicles or vehicle platforms in the future. Accordingly, not all conditions can be specified in advance and assumptions are necessary.
If you work “out of context” here, you are forced to rely on assumptions. For example:
- The environment: Is the item used in a car or in a truck? In the city or off-road? ADAS system or inverter for an electric powertrain? How is it protected in the vehicle?
- Interfaces: What other systems will it interact with? Are these systems secure?
- Feasibility of attacks: Is the component accessible in its operating environment?
These assumptions are not arbitrary placeholders. Rather, they form the entire backbone of the cyber security strategy. If incorrect assumptions are made at this critical point, the TARA will be flawed and the risk analysis and assessment of potential damage will be largely useless.
An example of this is an airbag control unit, which is assumed to be installed in a tamper-proof housing and only accessible from the inside. If this assumption is not correct, the device could be vulnerable to physical attacks. This would make many attacks much easier than the TARA previously created on the basis of the assumptions would suggest.
Without a solid item definition that documents these types of assumptions, it becomes nearly impossible to fully and accurately identify threats in TARA.
Conversely, when developing a platform, it is also necessary to inform the customers who will later use a component about the assumptions made in the best possible way. Otherwise, it may happen that a component is used under completely different conditions (e.g. the physical situation in the vehicle may be completely different to that assumed by the manufacturer), meaning that the security analyses (and cyber security requirements) that were created in advance for the platform no longer fit in practice.
It is also important that the assumptions made can also be understood outside the item definition, e.g. in a dedicated cybersecurity manual. (In relation to the example, for example: Please install protected inside the vehicle).
Common practice: Use an ISO/SAE 21434-compliant item definition template
First of all: hats off! I’m glad you’ve read this far. You will agree: A correct item definition seems complex and quite time-consuming. You are not alone in this assessment. Creating a comprehensive item definition requires time, expertise and a systematic approach.
In vehicle development practice, it is therefore not uncommon to use ISO/SAE 21434 templates to create your own item definition with the help of a prepared template, which is complete and consistent on the one hand and meets the requirements of ISO/SAE 21434 on the other.
The ISO/SAE 21434:2021 Item Definition Template of the CYEQT Knowledge Base was developed by cybersecurity experts with years of experience in global OEM and Tier-X development projects and is 100% compliant with the requirements of ISO/SAE 21434. Key advantages of the template at a glance:
- Guided sections: From input and output to assumptions and operating environments, every critical detail is covered.
- Practical checklist: From internal interfaces to known weak points, nothing is overlooked.
- Efficiency: Save time and reduce the risk of errors with a structured format.
To summarize: Effective vehicle cybersecurity starts with the item definition
Do not be confused by the sheer volume of work products and elaborations of ISO/SAE 21434 (among others): The Item Definition is not just another document. It is always the first line of defense in cyber security for any development project.
The item definition closes the gap between the understanding of a given system and the protection actually required against threats to that very system.
Skipping them or only tackling them half-heartedly is like building a house on sand: It may hold for a while, but eventually the cracks will become clearly visible through the shaky foundation.
The clear recommendation for practitioners is therefore: take the time to define the item correctly, completely and accurately. Because in the world of automotive cybersecurity, there should be no room for speculation.
