Analysis Rules: Attack-Tree Example

---

Introduction

This chapter extends the definition of the Analysis Rule Language, building on the foundational concepts introduced here. Please read this document first in order to understand the following rules.

The focus here is on the identification of Threat Interdependencies and the subsequent derivation of Attack-Trees. Cyber threats and attacks do not occur in isolation; instead, they typically involve multiple interconnected attack steps. In most cases, the ultimate target—such as a database containing valuable information—is not directly accessible but requires an attacker to traverse multiple security barriers. By leveraging the concept of Capabilities and the corresponding Capability Filter, we can simulate the sequential steps of a multi-level attack. This allows us to construct an attack graph, which serves as the foundation for extracting structured attack-trees, enabling a deeper understanding of potential attack pathways.

Use Case Example based on ISO/SAE 21434

In order to adequately represent the syntax and semantics of the analysis language, we present a use case example that originates from the automotive domain. The presented example was derived from the security standard ISO/SAE DIS 21434 "Road vehicles - Cybersecurity engineering" from February 2020 Annex G.

A modern vehicle contains a complex electronic infrastructure. Most cars have a full infotainment system and additional driving assistants as standard equipment. In addition to the necessary electronic control units (ECU), vehicles include an increasing number of externally accessible interfaces such as Bluetooth, WIFI, and Cellular communication. Due to the trend towards autonomous driving, vehicle-to-vehicle communication is also indispensable and offers further potential vulnerabilities that an attacker could exploit. Improving the security of a vehicle is an essential influencing factor for its overall safety and that of its occupants.

System Model

The image above illustrates the adopted system model from ISO/SAE DIS 21434, page 82, as modeled inside the ThreatGet Diagram Editor. This documentation provides guidance on using the analysis language of ThreatGet, based on the presented system model. Additionally, a use case example demonstrates how cybersecurity-critical information can be translated into the formal analysis language for automated analysis.

Before diving into the technical details, this document explains the individual diagram components and outlines what this model represents at a higher abstraction level.

Use Case Overview

The use case diagram depicts a selected portion of the internal electronic infrastructure of a vehicle. This scenario is designed to illustrate a hypothetical situation in which an attacker attempts to negatively influence the behavior of the vehicle’s Headlamp System.

The objective of this example is to showcase:

1. How ThreatGet identifies potential vulnerabilities.

2. How diagram components interact in the system model.

3. The transformation of critical cybersecurity data into a structured format for analysis.

By focusing on the Headlamp System, this use case highlights the practical applications of ThreatGet in addressing real-world cybersecurity challenges.

Note: The definition of diagram components is described in the Administration/Managing Elements section.

The diagram contains one Boundary called "Item Boundary". It encompasses almost all components related to internal CAN communication inside the vehicle and describes different levels of membership within the system.

Boundaries are modeled to describe a separation between logically or legally separate operating system elements.

• Car: Depicts the physical hull of the vehicle using an "Encasement" element. It includes all diagram components except the "External Interactor" element on the left side. An "External Interactor" could be for example a Backend Server sending update data to the car.

• Item Boundary: A boundary that includes all system components that are directly or indirectly involved in controlling or displaying the light settings. Especially focusing on the communication elements linked to internal "CAN Bus" system.

The original system model of ISO/SAE 21434 does not include the "Car" element. This encasement was added to clearly show which elements are located in the vehicle's physical envelope and are therefore not directly accessible to an attacker. Another adjustment concerns the Operational Environment element which is declared as "Headlamp System" in the original diagram. This encasement was also added as these components are normally also physically separated from the other electronical elements of the car.

Usually, a boundary is used to represent a border between two interacting elements with different levels of privilege. They are usually also used to depict potential attack surfaces and simplify the analysis as they indicate possible attack points. In this case, the Car represents the physical shell of the vehicle. However, the Item Boundary is not a real physical component of the vehicle. Instead, in this case, it represents an area in which system components are located which are examined in this specific case.

The diagram contains several diagram components whose functions and types are described in the following listing. The labels displayed for the elements are only the names of the elements, which can be freely chosen by the user while constructing the diagram. The names of the components are irrelevant for the analysis, only their component types. Therefore, the exact types are highlighted in the brackets in each case in the following list.

We use the following notation: Label (TOP Type / SUB Type) : "Further Description". (The SUB Type is only displayed if it varies from the TOP Type)

• External Interactor (External Interactor): An external interactor is a component that can or wants to interact with the vehicle. This can be, for example, a server that sends updates or an attacker that negatively affects the vehicle. Data transmitted to the car is always done by a wireless communication.
• Navigation ECU (Control Unit / Network Communication Control Unit): Manages the direct connections to the externally accessible interfaces of the vehicle. Therefore, it is responsible for the incoming and outgoing data traffic. For example, a driver connects his mobile phone via Bluetooth to use the hands-free system during a call. It is also responsible for the data displayed on the dashboard, such as speed and light settings.
• Gateway ECU (Control Unit / Network Communication Control Unit): Connects several communication channels of various sources and forwards the transmitted data in the defined direction of the receiver. For example, it transmits the vehicle speed or the engine temperature to the navigation control unit that displays the information for the driver.
• Headlamp Switch (Device): Represents the physical lever or switch right next to the steering wheel. It allows the driver to adjust or switch the lights on and off.
• Body Control ECU (Control Unit): Monitors all other settings made by the driver, such as the operation of the indicators or the windscreen wipers. It forwards the changes to the respective actuators.
• CAN BUS (Shared Medium / Wired Bus): Represents the CAN Communication Network within the vehicle.
• Power Switch Actuator (Actuator): Receives the incoming requests regarding the light setting and adjusts the light accordingly.
• Camera (Sensor): The vehicle has a camera that faces in the direction of travel and detects oncoming vehicles and sending data to the corresponding Camera ECU which in turn gives inputs to the Power Switch Actuator.
• Camera ECU (Control Unit): If the headlights are switched on, and a vehicle approaches, this control unit sends a dimming command to the Light Switch Actuator. As soon as the other vehicle is no longer in the field of vision of the camera, the lights are turned back on to original brightness.
• Other ECUs (Control Unit): This element depicts all other ECUs which are part of the Car but not in the focus of the analysis. It shall show that the Gateway ECU also delegates communication to other components inside the car environment.
• Integrity of Headlight (Asset): An asset that indicates whether the integrity of the vehicle's head light is violated. This means that someone or something is negatively affecting the lights.
• Availability of Headlight (Asset): An asset that indicates whether the availability of the vehicle's head light is impaired. Meaning the light of a vehicle should always be under control of the driver.

Note: All Interfaces (Ports) are displayed within the diagram as small rectangles with a undirected arrow on the borders of the elements. These Interfaces define inside their properties whether the communication is wireless or wired. Inside the Car Boundary all connections are wired.

The most important Interface (Port) is located on the Car element and establishes the connection between the Car and the External Interactor. This Interface depicts the Cellular as well as the Bluetooth interface of the Car.

It is essential to understand that the electronic control units are not individually connected. Instead, they communicate via a shared Control Area Network, also called CAN BUS (Shared Medium). This network can be understood as the nervous system of the automobile and the individual ECUs as individual body parts. The communication or so to speak data exchange between components is done via CAN Messages. These messages contain data that is used to transport information or instructions to these components.

The diagram contains two different types of Connectors. All Connectors are also referred to as "Data Connection". The presented vehicle contains only Wired Connector, i.e. elements that are connected via a cable. The only Wireless Connector describe the communication between the External Interactor and the Car.

Threat Model

Table G.6 on page 86 of the ISO/SAE 21434 standard lists the identified threats for the use case example. One of the specified threats refers to the loss of integrity of a CAN Message. An attacker could violate the integrity of a CAN Message, controlling the light by injecting unauthorized malicious messages into the network. This spoofing attack can force the headlights to turn off unexpectedly. While driving at night or in poor light conditions, this may lead to a severe accident.

The standard describes several possible attack scenarios. One of them, which is used in the following to introduce the analysis language, is described below:

The attack scenario describes an exploit of a Wireless Interface of the Navigation ECU to access the internal network of the vehicle. If the interface does not implement an authentication or input validation mechanism, the attacker is able to transmit malicious data to the vehicle.

The special characteristic of this attack path is the distance of the attacker from the attacked object. As described in the previous section: the Wireless Interface connects the vehicle to the regular mobile network. Therefore, the adversary can act remotely and thus not endanger himself.

Once the malicious data, e.g. a manipulated firmware, has been transmitted, the Navigation ECU could be compromised due to its direct connection to the interface. Via the compromised control unit, the attacker gains access to the internal CAN BUS network. This enables the attacker to read the exchanged data on the network if it is not encrypted, manipulate messages if they do not have tamper protection, or inject manipulated messages. In the scenario described in the standard, malicious CAN Messages are injected. These are addressed to the Power Switch Actuator and transport the request to turn off the lights. If the Gateway ECU does not implement a restriction on forwarding data, the message reaches the Light Switch Actuator and influences the behavior of the headlights.

Now that the use case example has been presented and a possible attack scenario has been described, the following sections show how the analysis language of ThreatGet can be used to perform an automated analysis. The examples that relate to this attack scenario are marked within the sections:

• Identifying the "Navigation ECU"
• Accessing the "Wireless Interface"
• Attacking the "Navigation ECU" by exploiting the "Wireless Interface"
• Exploiting the "Navigation ECU"
• Analyzing the internal communication
• Exploiting the internal "CAN" communication system

The Analysis Language of ThreatGet

The threat model is based on a set of rules that can also be defined within the web interface. The rules are specified using a Domain-Specific Language, which will be described throughout the following sections. The rules are based on previously defined diagram components, because only what is known can be queried.

A rule consists of a title, a description, an assigned threat type, an impact estimation, a likelihood estimation, and, most importantly, the so-called Anti-Pattern.

The anti-pattern represents the heart of every rule. It expresses threats in a human as well as machine-readable language. Each anti-pattern describes an undesirable condition inside a system.

The basic concept of the Analysis Language is explained here. This chapter extends this definition by the Capability Filter which defined below.

The Requires and Provides Filters

To be able to define a continuous propagation through the threat analysis, pre- and postconditions are required. Those can be defined in the web interface as Capabilities.

This filter is only applicable to Elements Connectors and Interfaces.

To model a precondition, the Requires Filter is used. For a postcondition, the Provides Filter.

General structure for the Requires Filter:

• REQUIRES CAPABILITY "name" >= "value"

General structure for the Provides Filter:

• PROVIDES CAPABILITY "name" := "value"

REQUIRES|PROVIDES CAPABILITY is used for local pre-/postconditions, whereas REQUIRES|PROVIDES ATTACKER CAPABILITY is used for global ones.

We provide examples of how this filter can be applied throughout this document.

The use of this filter is no different to the other filters in the language. However, the analysis of a capability is changed and queried on individual diagram components at runtime of the analysis. This distinguishes it from other filters such as the Tagged Value Filter, which statically queries how a value is set within the system.

Step 1: Identifying the "Navigation ECU"

All Elements of the diagram have a Top Type and a Sub Type. You can specify a Type Filter for the Element Pattern, indicating that only the Elements with the specified type should be analyzed by the analysis rule.

The following rule examines only those elements that have the sub-type "Control Unit".

ELEMENT : "Control Unit"

The presented vehicle contains four different control units:

• Navigation ECU
• Gateway ECU
• Car Body ECU
• Camera ECU
• Other ECUs

If we would like to be more specific, we could also search for a specific kind of Control Unit by searching for a defined Sub Type.

ELEMENT : "Network Communication Control Unit"

As you can see only the Navigation ECU and the Gateway ECU are marked within this example as only they have the Sub Type "Network Communication Control Unit" from the Top Type "Control Unit".

With this, we have already completed the first step. We now know which control units are present in the system. In the next step, we will find out which of these control units can be addressed externally and remotely. So that their communication can be abused to penetrate the vehicle. * Using the interface and tagged value filter to distinguish the wireless interfaces

Step 2: Accessing the "Wireless Interface"

We can use the Interface Filter to query information regarding the interfaces of elements. Our target is to locate all interfaces with the property "Network Technology" set to "Wireless".

We start with an Element Pattern as the foundational structure, establishing a consistent framework for interaction. Interfaces, within this context, can only be queried in relation to their corresponding element or the connectors that link them. Additionally, we query the property "Network Technology" by checking for "wireless" and "undefined", as the latter may indicate that the information is simply unknown rather than explicitly non-wireless.

ELEMENT {
    HAS INTERFACE {
        HAS ATTRIBUTE "Network Technology" IN ["Wireless", "undefined"]
    }
}

As you can see in the image only one element the "Car" Encasement and only one Interface located on this element are marked. This marked interface represents the Antenna of the vehicle which connects the vehicle to the mobile network.

We can now extend this rule with a Provides Filter

ELEMENT {
    HAS INTERFACE {
        HAS ATTRIBUTE "Network Technology" IN ["Wireless", "undefined"] & 
        PROVIDES CAPABILITY "Access" := "true"
    }
}

The Provides Filter states, that the attacker has "Access" to this Interface and can now proceed the attack targeting the "Navigation ECU".

Step 3: Attacking the "Navigation ECU" by exploiting the "Wireless Interface"

We can now analyze the connection from the "Wireless" Interface targeting our "Navigation ECU" Element. Therefore, we use the Connector Pattern. We analyze whether the Source Interface is "Wireless" and we evaluate the "Access Control" and "Input Control" property of this interface as well as the Target interface which is the interface of the target "Network Communication Control Unit".

CONNECTOR {
    SOURCE ELEMENT &
    SOURCE INTERFACE {
        HAS ATTRIBUTE "Network Technology" = "Wireless" &
        EVALUATE ATTRIBUTE "Access Control" & 
        EVALUATE ATTRIBUTE "Input Control" &
        REQUIRES CAPABILITY "Access" >= "true"
    } &
    TARGET ELEMENT "Network Communication Control Unit" &
    TARGET INTERFACE {
        EVALUATE ATTRIBUTE "Access Control" & 
        EVALUATE ATTRIBUTE "Input Control" &
        PROVIDES CAPABILITY "Access" := "true"
    } 
}

In the Requires Filter, the >= checks the order in which the values in the capability are put. In Access, the value true has the highest position, therefore it will only trigger if there is "Access" to the Source Interface.

By evaluating the "Access control" and "Input control" properties, we estimate and influence the probability parameter of the analysis result. We do not check whether a value is set to a specific value. We only want to know how likely it is that such a threat can occur.

Finally, the attacker is granted "Access" to the Target Interface located on our "Network Communication Control Unit" (Navigation ECU) as we provide the "Access" on the target Interface.

Step 4: Exploiting the "Navigation ECU"

Now that the attacker has "Access" to the Interface of our "Navigation ECU" it is possible that this "Network Communication Control Unit" can be compromised.

We check in this step whether the Navigation ECU is "Updatable" from "Remote" and we check if it has some form of "Malware Protection".

ELEMENT "Network Communication Control Unit" {
    HAS INTERFACE INTERFACE {
        REQUIRES CAPABILITY "Access" >= "true"
    } &
    HAS ATTRIBUTE "Updatable" IN ["Weak", "Undefined"] & 
    EVALUATE ATTRIBUTE "Malware Protection" &
    PROVIDES CAPABILITY "Control" := "True"
}

Please notice following points: * We check "Updatable" for the "Network Communication Control Unit" (Navigation ECU) with the values "Weak" and "Undefined". "Weak" = unchecked, an update without checking of the received source file. And we also check for "undefined" as we might not know how this update is performed. * We provide the "Control" Capability to the "Network Communication Control Unit". * We EVALUATE the ATTRIBUTE "Malware Protection" and can derive the likelihood for this threat.

Step 5: Analyzing the internal communication

Now that the attacker has "Control" over the Navigation ECU it is likely that the structure of CAN Messages inside the vehicle is open to the attacker. This allows the adversary to gain information on how the system communicates internally. We can express this with the following rule by analyzing the Connectors.

CONNECTOR {
    TARGET ELEMENT "Network Communication Control Unit" {
        REQUIRES CAPABILITY "Control" >= "True"
    } &
    SOURCE ELEMENT "Control Unit" &
    SECURED BY ELEMENT "Encasement" &
    EVALUATE ATTRIBUTE "Encrypted" &
    PROVIDES CAPABILITY "Discovery" := "True" 
}

Please notice following points: * We check only Connectors that are SECURED BY ELEMENT "Encasement". This ensures that only internal data is analyzed. * We EVALUATE the ATTRIBUTE "Encrypted" from the incoming Connector targeting our "Control Unit" (Navigation ECU). * We provide the "Control" Capability to the "Discovery" on the incoming Connector.

Discovery consists of techniques an adversary may use to gain knowledge about the system and internal network. These techniques help adversaries observe the environment and orient themselves before deciding how to act. They also allow adversaries to explore what they can control and what’s around their entry point in order to discover how it could benefit their current objective. Native operating system tools are often used toward this post-compromise information-gathering objective.

As you can see in the image above, the only connection targeting our Navigation ECU is coming from the Gateway ECU.

Step 6: Exploiting the internal "CAN" communication system

In the final step of this use case scenario, an Asset within the system is compromised through the exploitation of the internal CAN Message infrastructure.

The attack begins with the adversary leveraging an externally accessible interface to gain access to the system. From this entry point, control over the Navigation ECU is established. By monitoring internal messaging, the attacker learns how messages are structured, transmitted, and processed within the system.

With this acquired knowledge, the adversary can craft and inject manipulated CAN Messages into the CAN Bus. If the system lacks adequate countermeasures, these fraudulent messages propagate through the network, targeting critical vehicle functions. For example, the attacker could send malicious CAN frames to the Body Control ECU or the Camera ECU, which then interpret these messages as legitimate commands. Consequently, this manipulation could lead to unintended and unsafe behavior, such as unauthorized activation or deactivation of vehicle lighting.

We can express this attack using a Flow Pattern.

FLOW {
    SOURCE ELEMENT "Network Communication Control Unit" {
        REQUIRES CAPABILITY "Control" >= "True"
    } &
    TARGET ELEMENT "Control Unit" {
        PROVIDES CAPABILITY "IMPACT" := "True" 
    } &
    SECURED BY ELEMENT "Encasement" &
    INCLUDES NO ELEMENT {
        HAS ATTRIBUTE "Network Filtering" = "Strong"
    }
}

Please notice following points: * We check all Flows that are SECURED BY ELEMENT "Encasement". Therefore all other "Control Units" are affected * We analyze whether the Flow includes NO Element with the property "Network Filtering" set to "Strong" as this might be a counter measure to this threat. * We assign the Capability "IMPACT" to all targeted "Control Units". If we assign a Capability to an element inside the system model, it is evaluated whether this capability is also focusing the Asset located on the element.

As the Body Control ECU as well as the Camera ECU both hold an Asset related to the Availability of the light, these assets are automatically violated as soon as the underlying "Control Unit" is affected by a capability.

This results in the following Attack-Tree:

This scenario underscores the necessity of implementing robust security mechanisms, such as message authentication, anomaly detection, and intrusion detection systems, to mitigate the risk of such attacks.