Introduction to ISO 21434 Terms - Continued

Welcome to our second blog post of functionalsafetyfirst.com on Cybersecurity.

In our previous article, we introduced you to some of the key ISO 21434 terms and applied them to the well-known Jeep Cherokee cyberattack. For those who may have missed it, you can find it here.

In this article, we will explore additional ISO 21434 attack-related terminologies, using the same Jeep Cherokee cyberattack as example. 

Attack related terms! - Weakness & Vulnerability

Weakness - is a defect or flaw in an asset that can cause undesirable/unwanted behaviour.

Examples:

• Missing requirement or specification
• Missing/Incorrect implementation of security protocols such as Media Access Control Security (MAC) for communication among ECUs in vehicle network
• Using outdated software without the latest security patches makes vehicles vulnerable to digital break-ins, as attackers may already know and exploit these security gaps

A weakness of an asset may or may not lead to a vulnerability. For example, a defect in the architecture is identified as weakness. But if the vehicle architecture includes robust isolation mechanisms or a gateway that completely prevents communication from the compromised component to any cybersecurity-relevant asset, then there is effectively no attack path to realize harm. 

In such a case, the defect remains a weakness but is not a cybersecurity vulnerability.

Vulnerability - If a weakness can be exploited by attackers as part of an attack path, then this weakness is treated as a vulnerability. In other words, Vulnerability is a cybersecurity-related weakness.

Example:

If an attacker exploits the weakness of incorrect implementation of security protocols among safety critical systems and uses the CAN bus to send malicious commands to other safety critical systems of the vehicle.

Let us now examine a few examples of weaknesses identified in the Jeep Cherokee cyberattack, and analyse how they relate to vulnerabilities, attack or exploitation paths, and the resulting damage scenarios. To better understand these examples, we will first look at the high-level system architecture of the 2014 Jeep Cherokee, and then go into examples of weaknesses.

This architectural context helps explain where the weaknesses and vulnerabilities originated. In this attack, the primary asset was the Uconnect infotainment system, which acted as the main gateway into the vehicle’s internal networks.

The architecture can be broken down into three main domains: 

• Uconnect Head Unit/Radio Module, 
• CAN buses (CAN-IHS & CAN-C), and 
• Other Electronic Control Units (ECUs) attached to those buses.

Figure: 2014 Jeep Cherokee Architecture Diagram

Vulnerability analysis

Vulnerability analysis is a systematic process of identifying weakness and determining if that weakness can be exploited by an attacker as part of an attack path. It is one of the design verification activities in cybersecurity. As an outcome of vulnerability analysis activity, cybersecurity related design and requirements are improved. 

Vulnerability analysis is a continuous activity which happens throughout a product’s entire life—from concept and design phase until cybersecurity support ends. 

This serves two purposes: 

• Proactive Development which works hand-in-hand with concept phase, design and testing activities during product development. Weaknesses found during verification, validation, and testing serve as inputs for this analysis.
• Reactive monitoring during operation helps in managing new threats once the vehicle is in the field. By monitoring field data and threat intelligence, teams can determine if a newly discovered weakness is a real risk that needs a fix. This reactive approach begins with collecting information/threat intelligence) and identifying if that information points to a weakness. If a weakness is identified, vulnerability analysis determines if it's a genuine, exploitable vulnerability.

Vulnerability analysis uses resources like vulnerability databases [E.g., NIST's National Vulnerability Database and MITRE's Common Vulnerabilities and Exposure and techniques like attack trees to map weaknesses to common attack patterns and understand how an asset could be compromised. 

Being Safety Engineers, we cannot but compare the two standards and identify similarities and differences between the two. Here’s our mapping of these terms to the functional safety world.

Cybersecurity today is managed in a largely proactive manner, supported by structured vulnerability disclosure processes and publicly available vulnerability databases. These enable early awareness, systematic analysis, and timely mitigation across the industry. Functional safety, in contrast, predominantly works based on program-specific/context-specific analyses, with limited cross-industry learning from real-world safety incidents.

The absence of a functional safety equivalent to vulnerability databases such as CVE or NIST highlights an opportunity. While functional safety risks are inherently context-dependent and cannot be treated as generic “vulnerabilities,” a structured, anonymized, and industry-wide repository of safety-related faults, contexts and hazardous behaviours—similar to what NHTSA maintains for regulatory non-compliances—could significantly strengthen proactive functional safety management.