Skip to content

THREATGET Rules

Introduction

Typically, threat modelling is based on two components. The first component is called the System Model. The system model contains an abstract representation of the system under consideration.

The second component is the so-called Threat Model. The threat model represents a knowledge base of known vulnerabilities, threats, threat scenarios, including their exploitation techniques and methods.

The principle of THREATGET is based on the automatic comparison of these two models. The system model is created by the user within the Enterprise Architect plugin. For this purpose, the user defines the Elements, Assets, Connectors, Interfaces (Ports) and Boundaries in the web-based interface that can be used during the definition of it. Elements, assets, connectors, interfaces and boundaries are also referred to as diagram components.

Diagram components are largely described by their properties. These properties are also defined in the web-based interface and assigned to the components. The properties are called Tagged Values within the THREATGET plugin.

Note: An asset represents a form of value to the system. An asset can be associated with element functions or connectors. Assets have two main attributes: Impact Category and Cybersecurity Property.

Full Formal Syntax and Semantics Definition

As part of this documentation we developed a fully formal syntax and semantics for the THREATGET analysis language. It can be downloaded here

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 shows the adopted system model from ISO/SAE DIS 21434 page 82, modeled in Enterprise Architect.

In this documentation, we show how to use the analysis language of THREATGET based on the presented system model. Furthermore, the use case example demonstrates how cybersecurity-critical information can be transferred into the formal analysis language to be used for automated analysis.

Before that, we describe the individual diagram components and what this model represents on a higher abstraction level.

The use case diagram displays a selected part of the entire internal electronic infrastructure of a vehicle. It is intended to illustrate a fictitious scenario in which an attacker attempts to influence the behavior of the "Headlamp System" of a vehicle negatively.

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

The diagram contains three Boundaries : "Car Boundary", "Item Boundary", "Logical Boundary". Together they encompass almost all components and describe different levels of membership within the system.

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

  • Car Boundary: Describes the physical hull of the vehicle. It includes all diagram components except the "Backend Server" element in the left upper corner.
  • Item Boundary: It includes all system components that are directly or indirectly involved in controlling or displaying the light settings.

The original system model of ISO/SAE 21434 does not include the "Car Boundary". This boundary 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 Item Boundary which is declared as "Headlamp System" in the original diagram.

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 Boundary 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 (Type) : "Further Description".

  • 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): 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): 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 (Human Machine Interface): 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.
  • CAR Body 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): 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.
  • 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 directing 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.

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 Navigation ECU.

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 the 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 particular scenario described in the standard, malicious CAN Messages are injected. These are addressed to the Light 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:

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 analysis language is essentially based on five patterns, each referring to one of the diagram components. This approach ensures that the language remains modular and can be extended as required. The language structure has been inspired by the data format JSON. It requires little additional writing overhead and still offers a readable hierarchical format.

A pattern examines whether an Element, Asset, Connector, Interface or Flow exists within the diagram or not. An assigned type can further restrict each pattern except the Flow Pattern. The concept of Flows is explained within the corresponding pattern and filter section (Flow Pattern, Flow Filter). The assigned type indicates that a pattern only matches components of this type.

A pattern can, but does not necessarily, have filters assigned. A filter specifies additional conditions that a pattern must meet in order to correspond to a threat. Overall there exist nine different filters. These can be used, for example, to examine the assigned tagged values (properties) of a component, the connections between components, or the relationships between components.

The following picture illustrates the concept of patterns and filters.

Patterns and Filters Concept

However, due to the system model structure, not all filters can be applied to all patterns. For example, Boundaries cannot be assigned properties, so they cannot be filtered accordingly. Another example is that only Elements can be filtered by their connectors to other Elements, since Elements are the only diagram component connected via Connectors (Data Connections).

This may seem very complex initially, but all the terms used in the description will be explained throughout this document and examples. Furthermore, we link each pattern with its possible filters.

The full specification of the language can be found at the bottom of the page.

The Element Pattern

Let's start with the simplest, but most important and most frequently used pattern.

The Element Pattern allows you to examine the Elements within in the system model.

Each pattern starts with a specific keyword. The Element Pattern has the initial keyword "ELEMENT" (Element | element).

The general structure of such a rule is as follows:

  • ELEMENT -> Element Pattern without any type specification or additional filters
  • ELEMENT Type Filter -> Element Pattern focusing on a specific type
  • ELEMENT { .... } -> Element Pattern with additional filters (...)
  • ELEMENT Type Filter { .... } -> Element Pattern with type and further filters (...)

Applicable filters for the Element Pattern :

Since the filters will be explained in the following sections, this section is limited to the use of the Element Pattern in combination with the simplest form of the Type Filter.

Example 1

Each pattern of the analysis language is initialized by a specific keyword, as described before. The keyword is already sufficient to create a valid analysis rule. The keyword "ELEMENT" indicates that all elements within the diagram should be examined.

ELEMENT

Note: As you can see the boundaries are also marked in this case. Boundaries are inside the diagram their own component as they cannot have connections to other elements or boundaries. However, during the analysis, boundaries are treated like elements.

Example 2

All Elements of the diagram have a top-type and a sub-type. You can specify a typefilter 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

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

The Asset Pattern

The Asset Pattern allows you to examine the Assets within in the system model.

The Asset Pattern has the initial keyword "ASSET" (Asset | asset).

The general structure of such a rule is as follows:

  • ASSET -> Asset Pattern without any type specification or additional filters
  • ASSET Type Filter -> Asset Pattern focusing on a specific type
  • ASSET { .... } -> Asset Pattern with additional filters (...)
  • ASSET Type Filter { .... } -> Asset Pattern with type and further filters (...)

Applicable filters for the Asset Pattern :

It is the only pattern besides the Interface Pattern that cannot be used as an initial pattern for an analysis rule. This pattern can only be used within the Asset Filter. The Asset Filter, in turn, can only be assigned to the Element Pattern. Therefore, we already anticipate a little bit and add a so-called Asset Filter to an Element Pattern.

Example 1

The following analysis examines all elements that are linked to an asset. 

ELEMENT {
    HOLDS ASSET
}

As described in System Model, the internal communication of the vehicle runs exclusively via so-called "CAN Messages". Within the diagram, the links of the Assets are normally hidden in order to avoid overloading the diagram. For this example, the Asset Connectors are displayed to clearly visualize the result of the analysis. This analysis shows which Elements are linked (HOLD) to an Asset.

The typefilter of the Asset Pattern works the same as the ELEMENT Pattern.

Further Examples

The following rule examines all Elements of the type "Control Unit" that are linked to an ASSET.

ELEMENT : "Control Unit" {
    HOLDS ASSET
}

Compared to the previous rule, the "Light Switch Actuator" is not marked as it is of the type "Control Unit". However, both Assets are still marked as both are linked to the "Camera ECU" (Control Unit).

The Interface Pattern

The Interface Pattern allows you to examine the Interfaces of Elements within in the system model.

The Interface Pattern has the initial keyword "INTERFACE" (Interface | interface).

The general structure of such a rule is as follows:

  • INTERFACE -> Interface Pattern without any type specification or additional filters
  • INTERFACE Type Filter -> Interface Pattern focusing on a specific type
  • INTERFACE { .... } -> Interface Pattern with additional filters (...)
  • INTERFACE Type Filter { .... } -> Interface Pattern with type and further filters (...)

Applicable filters for the Interface Pattern :

It is with the Asset Pattern the only pattern that cannot be an initial pattern for an analysis rule. This pattern can only be used within the Interface Filter. The Interface Filter, in turn, can only be assigned to the Element Pattern. Therefore, we already anticipate a little bit and add a so-called Interface Filter to an Element Pattern.

Example 1

The following analysis examines all elements that have an interface. 

ELEMENT {
    HAS INTERFACE
}

As described in System Model, the internal communication of the vehicle runs exclusively via so-called Connectors.

The typefilter of the Interface Pattern works the same as for any other pattern.

Please notice that the only elements that are not marked are the Boundaries. Elements need Interfaces to communicate. However, Boundaries do not communicate so they don't have Interfaces.

Further Examples

The following rule examines all Elements of the type "Control Unit" that are linked to an INTERFACE.

ELEMENT : "Control Unit" {
    HAS INTERFACE : "Wireless"
}

Compared to the previous image, only one "Control Unit" is marked as only the "Navigation ECU" has an Interface of the type "Wireless" and all other "Control Units" communicate by "Wired" connectors.

The Connector Pattern

The previous patterns of the analysis language were used to analyze single diagram components.

The Connector Pattern is used to analyze the direct connections between two Elements and their Interfaces.

The Connector Pattern has the initial keyword "CONNECTOR" (Connector | connector).

Since a Connector always connects two Elements, each Connector Pattern contains a mandatory Source Element Filter and a Target Element Filter. These are added to the pattern inside the curly brackets. There are also an optional Source Interface Filter and a Target Interface Filter that can be used to specify which Interfaces of each Element.

The general structure of such a rule is as follows:

Applicable filters for the Connector Pattern :

In the early stages of the analysis language development, Source Element Filter and Target Element Filter were optional. Over time, we decided to make them mandatory because it makes sense to think about where a Connector originates and where it terminates. Many threats to systems exist in their Connectors, especially in those that cross a Boundary, because Elements, which communicate across that border, disclose an attack surface or have different privilege levels. Furthermore, source and target of a Connector Pattern are part of the analysis result.

The Connector Pattern is similar to the Connector Filter that can be added to the Element Pattern.

The Source Element Filter

The Source Element Filter is used to specify where a Connector originates from.

The following rule examines all Connectors that originate from an "Control Unit". 

CONNECTOR {
    SOURCE ELEMENT : "Control Unit" & 
    TARGET ELEMENT
}

The system model contains three Elements with of the type "Control Unit". The target Element is not further specified, therefore, the Connector can terminate at any Element. The Interfaces are also marked as they are the entry points of a connector to an element.

The Source Interface Filter

The Source Interface Filter can be used to specify where a Connector originates from with focus on the Interface.

We know that we already push a little bit forward but this concept is almost the same as the Source Element Filter

The following rule examines all Connectors that originate from an "Control Unit" that have an Interface of the type "Wireless". 

CONNECTOR {
    SOURCE ELEMENT : "Control Unit" & 
    SOURCE Interface : "Wireless" & 
    TARGET ELEMENT
}

The system model contains only one Element with of the type "Control Unit" and a "Wireless" type Interface. This Element is the "Navigation ECU" in the right upper corner. However, the Connector focusing the this interface is an incoming Connector. Therefore, this anti-pattern would not consider this connector as it is specified that the Source not the Target Interface should be a "Wireless".

The Target Element Filter

The Target Element Filter is used to specify where a Connector terminates.

The following rule examines all Connectors that target the "Actuator" ("Light Switch Actuator" is only the label).

CONNECTOR {
    SOURCE ELEMENT  & 
    TARGET ELEMENT : "Actuator"
}

The system model contains one Element with the top-type "Actuator". The source Element is not further specified, therefore, the Connector can originate from any Element.

Please note that the Asset are not marked. This is due to the fact that this Asset is only linked to the Element not logically connected to transfer data.

The Target Interface Filter

The Target Interface Filter is used to specify where a Connector terminates with focus on the Interface.

The following rule examines all Connectors that target the "Control Unit" with a "Wireless" Interface.

CONNECTOR {
    SOURCE ELEMENT  & 
    TARGET ELEMENT : "Control Unit" &
    TARGET Interface : "Wireless"
}

The system model contains only one Element with the top-type "Control Unit" and a "Wireless" Interface. The source Element is not further specified, therefore, the Connector can originate from any Element.

Example 1

The following rule examines all Connectors within the system model, since the Connector Pattern does not have a specific type, and neither does the Source Element Filter and the Target Element Filter. 

CONNECTOR {
    SOURCE ELEMENT  & 
    TARGET ELEMENT
}

The result of this analysis rule would include all elements and all connectors of the system model.

Example 2

The following rule examines all Connectors within the system model that originate from a "Wireless" Interface and that terminate at a "Wireless" Interface.

Connector is the diagram component name. "Wireless Flow" is the assigned type.

CONNECTOR {
    SOURCE ELEMENT  & 
    SOURCE Interface: "Wireless" & 
    TARGET ELEMENT &
    TARGET Interface: "Wireless"   
}

The only Connector that fulfill this type filter are communicating with the "Navigation ECU", since all other Connectors inside the vehicle are communicating with "Wired" Interfaces.

The Flow Pattern

The previous Connector Pattern can be used to analyze direct connections between two Elements.

The Flow Pattern is used to analyze connections between two Elements with several intermediate steps without explicit definition.

A Flow is defined as an alternating sequence of Elements and Connectors, starting with an Element and ending at an Element. By this definition, even a single Connector constitutes a Flow.

The Flow Pattern is very similar to the Connector Pattern as it has also a mandatory Source Element Filter and Target Element Filter. However, the Flow Pattern is the only pattern that cannot be assigned a type filter because it consists of two different diagram components.

It is also possible for the Flow Pattern to define the Source Interface as well as the Target Interface. Similar to the Connector Pattern these filters are optional.

The Flow Pattern has the initial keyword "FLOW" (Flow | flow).

Since a Flow consists of Connectors and connects two Elements, each Flow Pattern also contains a mandatory Source Element Filter and a Target Element Filter. These are added to the pattern inside the curly brackets.

The general structure of such a rule is as follows:

Applicable filters for the Flow Pattern :

The Flow Pattern is similar to the Flow Filter that can be added to the Element Pattern.

Flow Pattern Explained

The image below illustrates the concept behind a Flow in more detail.

On the left side is the Source Element and on the right side the Target Element. In between there are several Elements which are not specified more precisely, but which are all connected by Connectors.

Flows General Concept

During the analysis of a Flow pattern all Flows, also called paths, between two Elements are searched and returned as analysis result.

In order to prevent infinite loops, each Flow/Path may contain each Element only once. This ensures that modeled loops in the system model do not affect the analysis procedure.

Example 1

The following rule examines all Flows within the system model. 

Flow {
    SOURCE ELEMENT  & 
    TARGET ELEMENT
}

The syntax is quite similar to the Connector Pattern. However, the analysis result is different, as the Flow Pattern does not only analyze direct connections, but all paths between each Element and all other Elements.

Therefore, we encourage every user of this analysis language to think about the possible Source Element and Target Element of a Flow Pattern to avoid overflowing analysis results.

Example 2

The Flow Pattern cannot be assigned a type-filter. However, it can be assigned to the Source Element Filter and the Target Element Filter

The following rule examines all Flows within the system model between a "Control Unit" and an "Actuator". 

Flow {
    SOURCE ELEMENT: "Control Unit" & 
    TARGET ELEMENT: "Actuator"
}

The system model contains multiple "Control Units" and one "Actuator". The system model above shows the Flows between these Elements.

The Type Filter

In the previous patterns and filter the simplest form of the Type Filter was already introduced. It was shown how this filter can be used to check the respective diagram components for their top and subtypes. However, the Type Filter can be extended to analyze different situations of patterns. For example, to define that an anti-pattern can also apply to multiple diagram components of different types.

General Structure:

  • : "Type"
  • : != "Type"
  • : IN ["Type", "Type", ... ]
  • : NOT IN ["Type", "Type", ... ]

The Type Filter can be added to the following patterns and filter:

Example 1

The following Element Pattern focuses on all Elements within the system model whose type is not equal to "Control Unit".

Element != "Control Unit"

Example 2

The following Element Pattern focuses on all Elements of the type "Control Unit" or "Actuator", that are connected to an Asset.

Element IN ["Control Unit", "Actuator"]{
    HOLDS Asset
}

Example 3

The following Element Pattern focuses on all Elements within the system model whose type is not equal to "Actuator" or "Control Unit".

Element NOT IN [ "Actuator", "Control Unit"]

The Tagged Value Filter (Property Filter)

A Tagged Value Filter, also called Property Filter can be used to distinguish Elements, Connectors, Boundaries, Interfaces and Assets in terms of their defined Tagged Values. The syntax of this filter is quite similar to the previous Type Filter.

General Structure:

  • HAS ATTRIBUTE "key" = "value"
  • HAS ATTRIBUTE "key" != "value"
  • HAS ATTRIBUTE "key" IN ["value", "value", ... ]
  • HAS ATTRIBUTE "key" NOT IN ["value", "value", ... ]
  • HAS NO ATTRIBUTE "key"

The Tagged Value Filter can be added to the following patterns and filter:

Example 1

The system model contains only one "Wireless" Interface. It differs by from the other Interfaces its type and in the assigned value of the Tagged Value, which is called "Network Technology". This Tagged Value describes the effective range of the respective Interface. The "Wireless" Interface called which is part of the "Navigation ECU" has a larger effective range than for example a "Bluetooth Interface". Therefore, the "Wireless" Interface of the "Navigation ECU" has the property "Network Technology" with the value "Wireless".

The following rule would therefore only return the "Navigation ECU" as analysis result.

Element : "Control Unit" {
    HAS INTERFACE {
        HAS ATTRIBUTE "Network Technology" = "Wireless"
    }
}

Tagged Value Filter for Wireless Interfaces

Regarding the threat scenario the attack described focuses on the "Navigation ECU" and its "Wireless" interface, since it is the only component communicating with the external world.

In step 3 we will see how we can use multiple Tagged Value filters in order to check whether an Interface is "Wireless" and "Secure". * Using multiple Tagged Value Filters to narrow the threat

Example 2

In the previous Example 1, the first variant of the Tagged Value Filter was presented, which checks whether a given Tagged Value has exactly the one defined value. This first variant is to be used only if you know exactly which value would lead to a threat for a diagram component. The second variant is the negated form of the first variant and allows to point out a threat when several values would represent that threat.

Wireless Authentication multiple Values

As you can see in the image above, the Tagged Value named "Authentication" has three different values ("No", "Yes", "Undefined") which can be assigned to it. This Tagged Value indicates whether only authenticated connections and data transfers are allowed.

Since users may not always be directly aware of the real value of a Tagged Value, each of them has the default value "Undefined".

The following rule would identify the "Control Unit" as a threat even if the Tagged Value "Authentication" is set to "Undefined". The rule from Example 1 would not.

Element : "Control Unit" {
    HAS INTERFACE {
        HAS ATTRIBUTE "Authentication" != "Strong"
    }
}

Therefore, you should prefer using this variant over the first one in order to avoid overlooking "Undefined" values.

Example 3

The third variant is used to examine whether the value of a Tagged Value is within a list of values.

The following rule examines whether the value of Tagged Value "Authentication" is set to "No", "Undefined" or "Weak".

Element : "Control Unit" {
    HAS INTERFACE {
        HAS ATTRIBUTE "Authentication" IN ["undefined", "No", "Weak"]
    }
}

Compared to the rule from example 2, this rule describes the same threat. The rule in example 2 is only shorter.

Example 4

The fourth variant is the negated form of the third, and is used to examine whether the value of a Tagged Value is not within a list of values.

Consider we have the value "Strong" to the Tagged Value "Authentication". For example, the value "Strong" would describe that two-factor authentication is required. Furthermore, the value "Moderate" would describe that you have to authenticate to send data to this interface.

Element : "Control Unit" {
    HAS INTERFACE {
        HAS ATTRIBUTE "Authentication" NOT IN ["Strong", "Moderate"]
    }
}

Example 5

The fifth variant is a little bit special because it solves a certain problem regarding on how the analyzer works.

It is used to check whether a certain property not defined at all for a certain Element, Connector, Interface, Asset or Boundary.

So why do we need this special form. Imagine you want to examine all connectors in a system. But you do not know all the properties of all the elements to which the connectors are connected. Let's say you want to examine every connector that starts from any element but the target element must or should have an "Anomaly Detection". The element type "Control Unit" has the attribute "Anomaly Detection" but an actuator for example does not. Nevertheless it should be shown that this element is connected to a connector. The following rule would not recognize this case, because the analyzer recognizes that the element "Actuator" does not have this Tagged Value and therefore filters it out.

CONNECTOR {
    SOURCE ELEMENT & 
    TARGET ELEMENT {
        HAS ATTRIBUTE "Anomaly Detection" != "Strong"
    }
}

However, in conjunction with the fifth variant and in conjunction with a logical OR (|) we can check both cases and thus make our analysis more accurate.

CONNECTOR {
    SOURCE ELEMENT & 
    TARGET ELEMENT {
        (
            HAS ATTRIBUTE "Anomaly Detection" != "Strong" |
            HAS NO ATTRIBUTE "Anomaly Detection"
        )
    }
}

Further Examples

Adding a Tagged Value Filter to a Connector Pattern:

CONNECTOR {
    SOURCE ELEMENT & 
    TARGET ELEMENT &
    HAS ATTRIBUTE "Encrypted" != "Strong"
}

Adding a Tagged Value Filter to a Asset Pattern:

Asset{
    HAS ATTRIBUTE "Cybersecurity Attribute" IN ["Integrity", "Confidentiality"]
}

Multiple Filters

In the previous section we showed how the Tagged Value Filter can be used within certain patterns to examine the assigned Tagged Values.

Within the Further Examples we presented the following rule:

CONNECTOR {
    SOURCE ELEMENT & 
    TARGET ELEMENT &
    HAS ATTRIBUTE "Encrypted" != "Strong"
}

This rule consists of a Connector Pattern and three different filters. The mandatory Source Element Filter and Target Element Filter and a Tagged Value Filter. All three filters are connected by means of a logical AND (&). Therefore, all three filters must be satisfied for the anti-pattern to be fulfilled.

AND Connected Filters

You can connect as many filters as you wish.

Regarding the threat scenario the attack focuses on a "Wireless" communication that provides No or Weak "Authentication" on the side of the Target Element.

Element : "Control Unit" {
    HAS INTERFACE {
        HAS ATTRIBUTE "Network Technology" = "Wireless" &
        HAS ATTRIBUTE "Authentication" NOT IN ["Strong", "Moderate"]
    }
}

OR Connected Filters

The previous section showed how you can connect multiple filters using a logical AND (&), indicating that all filters have to satisfied. You can also connect multiple filters using a logical OR (|). In this case only one of them has to be satisfied to trigger the threat.

The following rule examines all Connectors that have the Tagged Value "Encrypted" set to an value unequal to "Strong" OR (|) are not considered "Trusted".

CONNECTOR{
    SOURCE ELEMENT & 
    TARGET ELEMENT &
    (
        HAS ATTRIBUTE "Encrypted" != "Strong" |
        HAS ATTRIBUTE "Trusted" != "Yes"
    )
}

The Asset Filter

The Asset Filter is used to examine whether an Element or Connector is linked to a specified Asset.

General Structure:

The Asset Filter can be added to the following patterns and filter:

Example 1

The following rule examines all Elements of the type "Actuator" that are connected to an Asset, with the Tagged Value "Impact Category" equal to "Operational".

ELEMENT : "Actuator" {
    HOLDS Asset {
        "Impact Category" = "Operational"
    }
}

The Connector Filter

A Connector Filter is similar to the Connector Pattern, but it is a filter that can be added to an Element Pattern.

Normally the Connector Pattern includes a mandatory Source Element Filter and Target Element Filter. However, since it is a filter that is added to a pattern, it only requires one of them. The Element specified within the pattern is the counterpart to the respective Source Element or Target Element.

We can also add a Source Interface or Target Interface to analyze the system more clearly.

General Structure:

The Connector Filter is exclusive to the Element Pattern and the Interface Pattern.

Example 1

The following rule examines all Connectors, originating from a "Control Unit" targeting another "Control Unit". Additionally, the "Electronic Control Unit" must be updateable.

ELEMENT : "Control Unit"{
    HAS CONNECTOR{
        TARGET ELEMENT : "Control Unit" {
            HAS ATTRIBUTE "Updates" IN ["Yes", "Remote"]
        }
    }
}

Example 2

The following rule highlights the nested concept of the analysis language.

The Connector Pattern examines whether there exists a Connector originating from an Element of the type "Control Unit" and targeting a "Shared Medium" Element. Furthermore, the Source Element must have an incoming Connector from a "HMI" (Human Machine Interface) Element.

CONNECTOR {
    SOURCE ELEMENT: "Control Unit"{
        HAS CONNECTOR {
            SOURCE ELEMENT: "HMI"
        }
    } &
    TARGET ELEMENT : "Shared Medium"
}

Example 3

Regarding the threat scenario the attacker must transfer malicious data to the "Control Unit" labelled "Navigation ECU". Using this control unit the adversary can analyze the internal communication of the vehicle and inject a malicious "CAN Message" to influence it.

The following rule examines whether there exists a Connector originating from the insecure "Wireless" Interface of the "Navigation ECU".

Element : "Control Unit" {
     HAS INTERFACE {
        HAS ATTRIBUTE "Network Technology" = "Wireless" &
        HAS ATTRIBUTE "Authentication" NOT IN ["Strong", "Moderate"]
    }
    HAS CONNECTOR {
        TARGET ELEMENT : "Control Unit"
    }
}

The Flow Filter

A Flow Filter is similar to the Flow Pattern, but it is a filter that can be added to an Element Pattern.

Normally the Flow Pattern includes a mandatory Source Element Filter and Target Element Filter. However, since it is a filter that is added to a pattern, it only requires one of them. The Element specified within the pattern is the counterpart to the respective Source Element or Target Element.

General Structure:

The Flow Filter is exclusive for the Element Pattern.

Example 1

The following rule analyzes whether the system model includes an Element of the type "HMI" that has an outgoing Flow to an Element of the type "Actuator".

ELEMENT: "HMI" {
    HAS FLOW {
        TARGET ELEMENT: "Actuator"
    }
}

The Element Relation Filter

The Element Relation Filter is used to examine the relations of an Element to other Elements or Boundaries.

Due to the structure of the system model, an Element can only contain other Elements but no Boundaries.

The Element Relation Filter does not only examine the direct child and parent relations of an Element or Boundary, but all hierarchical levels.

Note: Elements and Boundaries are two different diagram components but they are both analyzed by the Element-Pattern.

General Structure:

  • CONTAINS Element Pattern
  • CONTAINS NO Element Pattern
  • CONTAINS ONLY Element Pattern
  • CONTAINED BY Element Pattern
  • NOT CONTAINED BY Element Pattern

The Relation Filter is exclusive for the element Pattern.

Example 1

The following rule examines all Elements that are not contained by any Element or Boundary.

ELEMENT {
    CONTAINED BY ELEMENT
}

Please note the only Element that is not marked is the "External Interactor" in the right upper corner. This is because it is not contained by any other element.

Example 2

The following rule examines all Elements that are contained by a Boundary of the type "Item Boundary". 

ELEMENT {
    CONTAINED BY ELEMENT : "Item Boundary"
}

This example shall illustrate the hierchical levels of the Relation Filter.

As you can see all Elements contained by the "Item Boundary" are also contained by the "Car Boundary". But in this case only the "Item Boundary" is considered.

Example 3

Regarding the threat scenario the attacker must hack the "Navigation ECU" in order to analyze the internal communication of the vehicle and to inject corrupt "CAN Messages".

If the "Navigation ECU" is updateable from remote but is not contained by "Hardware Based Security" and has no "Secured Boot" mechanism, the attacker might transfer malicious data to the control unit and force it to reboot in order to compromise it.

ELEMENT : "Control Unit"{
    HAS ATTRIBUTE "Updates" = "Remote" & 
    HAS ATTRIBUTE "Secure Boot" NOT IN ["Strong", "Moderate"] &
    HAS ATTRIBUTE "Hardware Based Security" NOT IN ["Strong", "Moderate"] &
    NOT CONTAINED BY ELEMENT {
        HAS ATTRIBUTE "Secure Boot" NOT IN ["Strong", "Moderate"] &
        HAS ATTRIBUTE "Hardware Based Security" NOT IN ["Strong", "Moderate"]
    } 
}

After the "Navigation ECU" has been compromised, the adversary is able to analyze the "CAN Messages" and learn from the provided information.

Further Example

The original system model used in this documentation does not contain an Element that is contained in another Element. Therefore, the following image shows an adapted version of the system model, which is intended to illustrate that, for example, a "software" is installed on an "Control Unit", which in turn contains an application. This system model and the following rule is purely for demonstration purposes of this Relation Filter.

It checks whether the system model shows that an element of type "Electronic control unit" contains another element of type "Software", which in turn contains an element of type "Application".

ELEMENT : "Control Unit" {
    CONTAINS ELEMENT : "Software" {
        CONTAINS ELEMENT : "Application"
    }
}

In this extended system model only the "Body Control ECU" contains a "Software" with a running "Application", therefore only this is marked by the rule.

This example is also intended to show how Elements can be modeled together to describe their relationships alongside the Connectors.

This rule is also intended to clarify how relationships between elements can be specified in nested patterns and filters.

The Crosses Filter

A Crosses Filter can be used to examine whether Connectors and Flows cross an Element or Boundary.

A Connector crosses a Boundary or Element if the Source Element or Target Element are not contained by the same Boundary or Element.

General Structure:

The Crosses Filter can be added to the following patterns and filters:

Example 1

The following rule examines all Connectors of the type "Wireless Flow" that originate from a "Backend" Element and target an "Interface".

CONNECTOR{
    SOURCE ELEMENT : "External Interactor" & 
    TARGET ELEMENT : "Control Unit"
    CROSSES BOUNDARY
}

Example 2

Since a Flow can consist of several Connectors and Elements, multiple Connectors of a single Flow can also cross different Boundaries.

The following rule examines all Connectors within a Flow originating from a "External Interactor" Element and target an "Actuator".

Flow {
    SOURCE ELEMENT : "External Interactor" & 
    TARGET ELEMENT : "Actuator"
    CROSSES BOUNDARY
}

Further Examples

The following rule illustrates the usage of the Crosses Filter in a Connector Filter. It is the same rule 

ELEMENT {
    HAS CONNECTOR {
        TARGET ELEMENT &
        CROSSES BOUNDARY
    }
}

Since the rule contains no type-filters, all connectors that cross a Boundary are marked.

The following rule illustrates the usage of the Crosses Filter in a Flow Filter.

ELEMENT : "Control Unit" {
    HAS FLOW {
        TARGET ELEMENT : "Actuator"&
        CROSSES BOUNDARY
    }
}

The Includes Filter

As described within the section of the Flow Pattern it is neither possible to add a type filter to the pattern nor can you add a Tagged Value Filter. This is due to the fact that a Flow consists of multiple Elements and Connectors.

However, it is possible to examine the Elements and Connectors within a Flow using the Includes Filter.

General Structure:

This filter is exclusive for:

Example 1

The following rule examines whether the system model contains a Flow originating from a "Control Unit" with an Interface that can take wireless connections and determined by the Tagged Value "Network Technology" set to "Wireless", targeting an "Actuator", that includes no Element that does NOT provide a "Forward Restriction" mechnism. A forward restriction mechanism checks the incoming "CAN Messages" and examines their content. This mechanism would prevent an attack targeting the CAN Message system of the vehicle.

FLOW {
    SOURCE ELEMENT : "Control Unit" {
        HAS INTERFACE {
            HAS ATTRIBUTE "Network Technology" = "Wireless"
        }
    } &
    TARGET ELEMENT: "Actuator" &
    INCLUDES NO ELEMENT {
        "Forward Restriction" = "Yes"
    } 
}

Example 2

In order to avoid the double negation you can use the third variant of the Includes Filter.

The following rule is the rule reformulated form of the Example 2.

FLOW {
    SOURCE ELEMENT : "Control Unit" {
        HAS INTERFACE {
            HAS ATTRIBUTE "Network Technology" = "Wireless"
        }
    } &
    TARGET ELEMENT: "Actuator" &
    INCLUDES ONLY ELEMENT {
       (
            HAS ATTRIBUTE "Forward Restriction" = "Yes" |
            HAS NO ATTRIBUTE  "Forward Restriction"
       )
    } 
}

Please notice the last Tagged Value Filter "Forward Restriction" != "Yes" and the last part HAS NO ATTRIBUTE "Forward Restriction". This case checks whether the Attribute is present and is not assigned to the value "Yes" and the second part checks whether the Attribute is not present at all. We need this extra case as not all Elements have the property "Forward Restriction" assigned. So in the case of ONLY we need to check both cases.

With these examples we want to help you avoiding issues thinking in double negations. Therefore, we recommend using this rule from Example 3.

Example 3

The previous three examples showed how you can use the Includes Filter within a Flow Pattern to analyze the Elements contained by a Flow.

The following rule is similar to Example 1. It shows how to use Includes Filter in order to examine whether a Flow includes a specified Connector. In this case, it is specified that the Flow must contain a Connector originating from a "Control Unit" and must target an Element of the type "Shared Medium".

FLOW {
    SOURCE ELEMENT : "Control Unit" {
        HAS INTERFACE {
            HAS ATTRIBUTE "Network Technology" = "Wireless"
        }
    } &
    TARGET ELEMENT: "Actuator" &
    INCLUDES CONNECTOR{
        SOURCE ELEMENT: "Control Unit" &
        TARGET ELEMENT: "Shared Medium"
    } 
}

The specified connector is highlighted in blue.

Example 5

The previous example showed how the Includes Filter can be used to examine a Flow for a single Connector.

The following rule examines all Connectors contained by the Flow whether they are either "Trusted" = "Yes" or "undefined".

It is also checked whether the Flow crosses a Boundary.

FLOW {
    SOURCE ELEMENT: "Control Unit" &
    TARGET ELEMENT: "Actuator" &
    INCLUDES ONLY CONNECTOR{
        SOURCE ELEMENT &
        TARGET ELEMENT &
        HAS ATTRIBUTE "Trusted" != "No"
    } &
    CROSSES ELEMENT
}

Please note that the Source Element Filter and Target Element Filter within the Includes Filter is mandatory if you want to examine a Connector.

Example 6

Regarding the threat scenario we have presented now all patterns and filters that are necessary to describe the final attack.

The attacker sends a corrupt "CAN Message" via the manipulated "Navigation ECU" which is forwarded by the internal communication system of the vehicle to the "Light Switch Actuator" because none of the Elements within the path implements a "Forward Restriction" mechanism.

FLOW {
    SOURCE ELEMENT : "Control Unit" {
        HAS INTERFACE {
            HAS ATTRIBUTE "Network Technology" = "Wireless"
        }
    } &
    TARGET ELEMENT: "Actuator" &
    INCLUDES ONLY ELEMENT {
        "Forward Restriction" != "Yes"
    }
}

To express this process, we use two Includes filters. The first one checks if the Flow contains only Elements which have no "Foward Restriction" and the second one checks if each Connector within the Flow transports an Asset of the type "CAN Message".

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 webinterface 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 capability >= value
  • REQUIRES ATTACKER CAPABILITY capability >= value

General structure for the Provides Filter:

  • PROVIDES CAPABILITY capability := value
  • PROVIDES ATTACKER CAPABILITY capability := value

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

Example 1

In this example, an attacker is able to read from the data store. Furthermore, the data store does not support a secure boot, hence cannot detect if any changes in the configuration file have been made. This can lead to the attacker changing it to allow them to modify the data.

ELEMENT : "Data Store" {
    REQUIRES CAPABILITY "Read" >= "true" &
    "Secure Boot" != "yes" &
    PROVIDES CAPABILITY "Modify" := "true" 
}

In the Requires Filter, the >= checks the order in which the values in the capabiity are put. In Read, the value true has the highest position, therefore it will only trigger if there is read access to the data store.

The Provides Filter makes sure, that after the attack has been finished the attacker is able to modify the data, and has therefore been set to true.

Full Syntax Description

This section contains a description of the entire syntax of the THREATGET analysis language.

The language consists of a set of production rules. Each rule describes how a non-terminal symbol can be "replaced" or "extended" by a string consisting of non-terminal symbols and terminal symbols.

In addition, it should be explained that a terminal symbol is a fixed part of the language syntax. In contrast, a non-terminal symbol must be replaced by its corresponding production rule.

The following table lists all production rules of the language.

On the left side are the non-terminal symbols, and on the right side the respective symbols to replace the non-terminal ones.

A non-terminal symbol can have several alternatives by which it can be replaced. Each of them is displayed in a separate line.

Expressions in THREATGET come with different quantifiers. They imply how often a specific expression can occur within a rule. Below you can find the list of quantifiers.

(...)?      -> zero or one time
(...)*      -> zero, one or multiple times
(...)+      -> one or multiple times
(...|...)   -> logical OR                       Parentheses are mandatory part of the Syntax
...&...     -> logical AND          

query                       ->  query (& query)+              
                                query (| query)+             
                                pattern

pattern                     ->  element_pattern
                                connector_pattern
                                flow_pattern

element_pattern             ->  (element_pattern (| element_pattern)+)
                                ELEMENT (type_filter)? ({element_filters})?

asset_pattern               ->  (asset_pattern (| asset_pattern)+)
                                ASSET (type_filter)? ({asset_filters})?

interface_pattern           ->  (interface_pattern (| interface_pattern)+)
                                INTERFACE (type_filter)? ({interface_filters})?

connector_pattern           ->  (connector_pattern (| connector_pattern)+)
                                CONNECTOR (type_filter)? {  
                                        source_element_filter 
                                        (& source_interface_filter)? 
                                        & target_element_filter 
                                        (& target_interface_filter)? (& connector_filters)}

flow_pattern                ->  (flow_pattern (| flow_pattern)+)
                                FLOW {source_filter & target_filter (& flow_filters)}

source_element_filter       ->  SOURCE element_pattern

target_element_filter       ->  TARGET element_pattern

source_interface_filter     ->  SOURCE interface_pattern

target_interface_filter     ->  TARGET interface_pattern

element_filters             ->  element_filters (& element_filters)+
                                ( element_filters (| element_filters)+ )
                                tagged_value_filter
                                asset_filter
                                relation_filter
                                connector_filter
                                flow_filter
                                capability_filter

asset_filters               ->  asset_filters (& asset_filters)+
                                ( asset_filters (| asset_filters)+ )
                                tagged_value_filter
                                capability_filter

interface_filters           ->  interface_filters (& interface_filters)+
                                ( interface_filters (| interface_filters)+ )
                                tagged_value_filter
                                connector_filter
                                flow_filter
                                capability_filter

connector_filters           ->  connector_filters (& connector_filters)+
                                ( connector_filters (| connector_filters)+ )
                                tagged_value_filter
                                crosses_filter
                                asset_filter
                                capability_filter


flow_filters                ->  flow_filters (& flow_filters)+
                                ( flow_filters (| flow_filters)+ )
                                crosses_filter
                                flow_includes_filter

type_filter                 ->  : "type"
                                : != "type"
                                : IN ["type" (, "type")*]
                                : NOT IN ["type" (, "type")*]

tagged_value_filter         ->  HAS ATTRIBUTE "key" = "value"
                                HAS ATTRIBUTE "key" != "value"
                                HAS ATTRIBUTE "key" IN ["value" (, "value")*]
                                HAS ATTRIBUTE "key" NOT IN ["value" (, "value")*]
                                HAS NO ATTRIBUTE "key"

asset_filter                ->  HOLDS asset_pattern
                                HOLDS NO asset_pattern

relation_filter             ->  CONTAINS element_pattern
                                CONTAINS NO element_pattern
                                CONTAINS ONLY element_pattern
                                CONTAINED BY element_pattern
                                NOT CONTAINED BY element_pattern
                                CONTAINED BY ONLY element_pattern

connector_filter            ->  HAS (NO)? CONNECTOR (type_filter)? { 
                                            source_element_filter 
                                            (& source_interface_filter)?  
                                            (& connector_filters)? }
                                HAS (NO)? CONNECTOR (type_filter)? { 
                                            target_element_filter 
                                            (& target_interface_filter)? 
                                            (& connector_filters)? }

flow_filter                 ->  HAS (NO)? FLOW { source_element_filter 
                                                    (& source_interface_filter)? 
                                                    (& flow_filters)? }
                                HAS (NO)? FLOW { target_element_filter 
                                                    (& target_interface_filter)? 
                                                    (& flow_filters)? }

crosses_filter              ->  CROSSES element_pattern

flow_includes_filter        ->  INCLUDES (element_pattern | connector_pattern)
                                INCLUDES NO (element_pattern | connector_pattern)
                                INCLUDES ONLY (element_pattern | connector_pattern)
                                INCLUDES FIRST (element_pattern | connector_pattern)
                                INCLUDES LAST (element_pattern | connector_pattern)

component_capability_filter ->  REQUIRES (ATTACKER)? CAPABILITY "capability_key" >= "capability_value"
                                PROVIDES (ATTACKER)? CAPABILITY "capability_key" := "capability_value"