Analysis Rules Syntax and Semantic

---

Introduction

This chapter shows on how to develop own analysis rules and shows how these rules can be used to analyze a system.

Threat modeling is an essential approach for identifying, assessing, and mitigating potential vulnerabilities in a system. Typically, it is based on two foundational components:

The System Model

The System Model provides an abstract representation of the system under consideration. This model forms the basis for understanding the components, their interactions, and the boundaries within which the system operates. It is essential for ensuring that every part of the system is accounted for during the threat analysis process.

The Threat Model

The Threat Model serves as a comprehensive knowledge base. It contains information about:

• Known Vulnerabilities with corresponding Threats

• Threat Scenarios and related Exploitation Techniques and Methods

By combining these two components, a robust framework for identifying and addressing potential risks can be developed.

The Principle of ThreatGet

The core principle of ThreatGet lies in the automatic comparison of the System Model with the Threat Model. This comparison identifies potential risks and vulnerabilities within the system.

The process begins with the creation of the system model, which is facilitated by the Diagram Editor. In this editor, the user defines:

• Elements

• Connectors

• Interfaces (also referred to as Ports)

• Boundaries

These components are collectively known as Diagram Components and are used to visually and structurally represent the system.

Diagram Components and Their Properties

Diagram components are characterized by their Properties also referred to as Tagged Values. These properties are defined and assigned within the web-basedInterfaceof the ThreatGet plugin. Tagged Values provide detailed information about each component and play a vital role in the analysis process.

Special Diagram Component: Asset

In addition to the standard diagram components, there exists a unique component called the Asset. Assets are:

• Defined within the project.

• Assignable to Elements and Connectors.

Assets differ from other components as they do not have Tagged Values. Instead, they represent objects of value within the system. Despite lacking properties, assets are crucial for the analysis, especially during the Attack-Tree Analysis.

Understanding Assets

Assets hold significant importance due to their role in identifying and assessing the security and safety of valuable system components. An Asset is defined as an entity of value within the system and can be associated with:

• Elements

• Connectors

Each asset is evaluated based on its three primary Security Attributes:

1. Confidentiality: Ensuring that the asset is accessible only to authorized entities.

2. Integrity: Maintaining the accuracy and reliability of the asset.

3. Availability: Guaranteeing that the asset is accessible when needed.

Damage Scenarios and Impact Categories

Assets are intrinsically linked to one or more Damage Scenarios. These scenarios describe how the security attributes of an asset could be compromised. Each Damage Scenario is assessed across four Impact Categories:

1. Safety: The potential impact on the physical safety of individuals and systems.

2. Operational: The effect on the operational functionality of the system.

3. Financial: The monetary consequences of a security breach.

4. Privacy: The impact on the confidentiality of sensitive information.

Understanding the relationship between assets, damage scenarios, and impact categories is essential for a comprehensive threat analysis. By leveraging this information, ThreatGet provides a structured and efficient way to identify potential vulnerabilities and assess their consequences, enabling better decision-making for system security.

Threat Interdependencies and Attack-Trees

Threats don't occur in a vacuum; while single threats can highlight areas for system improvement, their Interdependencies can significantly amplify risk. One threat can enable another, creating a chain or path of attack steps that an attacker can exploit to achieve a target objective within the system. These dependencies are best described using the concept of Capabilties, which help map how threats interconnect. This section delves into the grammar, syntax, and semantics of these relationships. A comprehensive example of attack-tree generation, following ISO 21434, is provided here.

Use Case Example Device requests Data from Cloud-Server

In order to represent the syntax and semantics of the analysis language we use an example that depicts a daily operation. In this example we take the position of the cloud-operator who wants to ensure that the system and stored data is secure.

System Model

The image illustrates a typical daily operation where a Phone Application requests data from a Cloud service. On the left-hand side, the external device running the application contacts our API service. On the right-hand side, within the Cloud Boundary, resides our system. The API service operates on a dedicated API Server, designed to handle external connections. Its role is to analyze incoming requests, validating both their authenticity and authority to access data. The API Server communicates with the Database Server, retrieving requested data from the Database, which is then returned to the Phone.

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 Cloud 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.

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

• Cloud Boundary: It encompasses almost all components related to our Cloud Service. However, it could be out application that tries to communicate with our system.

Usually, a Boundary is used to represent a border between two interacting systems 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 Servers represent the physical components of our system. The Cloud Boundary is not a real physical component of the system. Instead, in this case, it represents an area in which system components are located which are examined.

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)

• Phone (Device / Mobile Device): This phone depicts any device which could run an application that is capable to interact with our system.
• Application (Software / Application): The application on the phone that requests the data from our cloud service.
• Api Server (Server): One of potential multiple servers operating in our cloud infrastructure. Runs the API service and interacts for example a load balancer.
• API (Software): The application on the Api Server that requests the data from our cloud service. It handles, checks and forwards the requests to the requested Database Server.
• Database Server (Server / Database Server): One of potential multiple servers operating in our cloud infrastructure. Runs the Databases and returns requested Data to our Api-Server.
• Database (Data Store): One of potential multiple Databases running on our Database-Server. It holds User-Data that can be requested.

Note: The Data is displayed as Asset (red A) located on the Database inside the Database Server

The most important Interface (Port) is located on the Api Server Element and establishes the connection between our infrastructure and the Phone.

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 diagram contains two different types of Connectors. All Connectors are also referred to as "Data Connection". The presented system contains only Wired Connectors, i.e. elements that are connected via a cable. The only Wireless Connector describe the communication between the Phone and the Api Server.

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 , 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.

Assets that are located on or connected to an Element play a special role in the analysis. If an Element or a Connector would be affected by a threat, a check is made to determine what type of threat is triggered. For example, if a threat describes a physical manipulation of an element, it is checked whether the asset connected to the Element has the "Availability" security attribute. If this is the case, the linked Damage Scenario is triggered and the asset is part of the analysis result that shows the Impact of the threat.

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

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:

• The Type Filter
• The Tagged Value Filter
• The Interface Filter
• The Relation Filter
• The Connector Filter
• The Flow Filter
• The Capability Filter

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.

The Capability Filter is a special filter and is used to establish the dependencies of threats. It is described on another section of this documentation. You can find it here.

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 Cloud Boundary is 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 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 top-type "Server".

ELEMENT: "Server"

The presented vehicle contains two different Servers:

• Api Server
• Database Server

Example 3

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

The following rule examines only those elements that have the sub-type "Database Server".

ELEMENT: "Database Server"

Result:

As you can see only the Database Server is marked within this example as only they have the Sub Type "Database Server" from the Top Type "Server".

Example 4

We can also use the negated version of the Type Filter in order to exclude certain elements from an analysis:

ELEMENT != "Server"

Example 5

It is also possible to search for multiple types using following anti-pattern:

ELEMENT IN ["Device", "Server"]

It is also possible to exclude multiple types using the negated type filter

ELEMENT NOT IN ["Device", "Server"]

The Interface Pattern

The Interface Pattern allows you to examine the Interfaces of located on 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 of 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:

• The Type Filter
• The Tagged Value Filter
• The Connector Filter
• The Flow Filter
• The Capability Filter

It is 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.

Interfaces can also be checked related to Connectors as they are always the Source and Target of a Connector. This displayed in later section.

The Capability Filter is a special filter and is used to establish the dependencies of threats. It is described on another section of this documentation. You can find it here.

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 system runs exclusively via so-called Connectors.

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

Please notice that the only Element that is not marked is the Cloud Boundary. Elements need Interfaces to communicate. However, Boundaries do not communicate so they don't have Interfaces.

Note: It is important to understand that now the Interfaces are also part of the analysis and therefor also part of the analysis result.

Further Examples

The following rule examines all Device of the type "Device" that are linked to an Interface of the type "Wireless".

ELEMENT: "Device" {
    HAS INTERFACE: "Wireless"
}    

Compared to the previous image, only the "Phone" (Device is the assigned type) is marked as only this device has an Interface of the type "Wireless" and all other interfaces 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 ).

The Source Filter and the Target Filter are not mandatory but highly recommended.

The general structure of such a rule is as follows:

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

Applicable filters for the Connector Pattern:

• The Source Element Filter
• The Source Interface Filter
• The Target Element Filter
• The Target Interface Filter
• The Tagged Value Filter
• The Crosses Filter
• The Capability Filter

In the early stages of the analysis language development, Source Element Filter and Target Element Filter were mandatory. Over time, we decided to make them optional because often Users just want to analyze all Connectors inside a system without restrictions and it reduces the written anti-pattern. However, it still 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 Capability Filter is a special filter and is used to establish the dependencies of threats. It is described on another section of this documentation. You can find it here.

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 a "Device".

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

The system model contains one Element with of the type "Device". 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.

Note: As you can see not only the Connector is part of the analysis result. Source Element, Interface as well as Target Element, Interface are always part of a Connector analysis.

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 any Element that have as Interface of the type "Wireless".

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

The system model contains only one Element with of the type "Device" and a "Wireless" type Interface. This Element is the "Phone" to the left.

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 "Software" ("Application" or "API" is only the label).

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

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

Note: In this case three Connectors are evaluated. First Connector is to the left internally from the "Phone" to the "Application" and the other two Connectors are inside the "Api Server". Remember Connectors are always bi-directional and therefore both Connectors target the "API"

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 "Device" with a "Wireless" Interface.

CONNECTOR {
    SOURCE ELEMENT & 
    TARGET ELEMENT: "Device" &
    TARGET INTERFACE: "Wireless"
}

The system model contains only one Element with the top-type "Device" 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 "Wired" 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: "Wired" & 
    TARGET ELEMENT &
    TARGET Interface: "Wireless"   
}

The only Connector that fulfill this Type Filter are communicating with the "Phone", since all other Connectors inside the system 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 an optional 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. However, we highly recommend to always use source and target specification if you want to use this pattern in order to avoid false positive results.

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

The general structure of such a rule is as follows:

• FLOW { ... }

Applicable filters for the Flow Pattern :

• The Source Element Filter
• The Source Interface Filter
• The Target Element Filter
• The Target Interface Filter
• The Crosses Filter
• The Secured By Filter
• The Includes Filter

The Flow Pattern is similar to the Flow Filter that can be added to the Element Pattern or Interface 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.

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 "Device" and a "Database".

Flow {
    SOURCE ELEMENT: "Device" & 
    TARGET ELEMENT: "Database"
}

The image shows the Flow from the left zo the right.

Please notice the following rule:

Flow {
    SOURCE ELEMENT: "Device" & 
    TARGET ELEMENT: "Server"
}

The system model contains multiple "Servers". The system model contains multiple Flows between the "Device" and the two "Servers". Without further restrictions the analysis engine would produce two results. The first result would contain the Flow between the "Phone" and the first "Server" containing the "API" and the second result would contain the Flow from "Phone" to the "Server" containing the "Database".

In order to analyze only the Flow from "Phone" to " Database Server " we can adjust the Target Element Filter like it follows:

Flow {
    SOURCE ELEMENT: "Device" & 
    TARGET ELEMENT: " Database Server "
}

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:

• The Element Pattern
• The Interface Pattern
• The Connector Pattern
• The Connector Filter

Example 1

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

Element != "Server"

Example 2

The following Element Pattern focuses on all Elements of the type "Server" or "Device".

Element IN ["Server", "Device"]

Example 3

The following Element Pattern focuses on all Elements within the system model whose type is NOT equal to "Server" or "Device".

Element NOT IN [ "Server", "Device"]

Note: As you can see the "Cloud" Boundary is also marked. During analysis the boundaries of a system are also considered as elements

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"
• EVALUATE ATTRIBUTE

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

• The Element Pattern
• The Interface Pattern
• The Connector Pattern
• The Connector 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 "Interface Type". This Tagged Value describes the effective range of the respective Interface. Therefore, the "Wireless" Interface of the "Phone" has the property "Interface Type" with the value "Wireless".

The following rule would therefore only return the "Phone"(Device) as analysis result.

ELEMENT: "Device" {
    HAS INTERFACE {
        HAS ATTRIBUTE "Interface Type" = "Wireless"
    }
}

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 only used 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.

As you can see in the image above, the Tagged Value named "Input Control" has five different values ("Strong", "Moderate", "Weak", "No" "Undefined") which can be assigned to it. This Tagged Value indicates whether incoming data is checked before it is accepted and processed.

• Weak = Validation, check if the input meets a set of criteria (such as a string contains no standalone single quotation marks).
• Moderate = Sanitization, modifies the input to ensure that it is valid (such as doubling single quotes or removing malicious content).
• Strong = Anomaly Detection, detect anomalies in operation of an Element or in communication, also considers timing or frequency of messages.

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 "Server" as a threat even if the Tagged Value "Input Control" is set to "Undefined". The rule from Example 1 would not.

ELEMENT: "Server" {
    HAS INTERFACE {
        HAS ATTRIBUTE "Input Control" != "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 "Input Control" is set to "No", "Undefined" or "Weak".

ELEMENT: "Server" {
    HAS INTERFACE {
        HAS ATTRIBUTE "Input Control" 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.

Note: But this is dependent on the Tagged Value in focus. Varying number of selectable values must be adjusted.

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 "Input Control".

• Moderate = Sanitization, modifies the input to ensure that it is valid (such as doubling single quotes or removing malicious content).
• Strong = Anomaly Detection, detect anomalies in operation of an Element or in communication, also considers timing or frequency of messages.

ELEMENT: "Server" {
    HAS INTERFACE {
        HAS ATTRIBUTE "Input Control" 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 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 the Connectors are connected to. Let's say you want to examine every Connector that starts from any Element but the target Element must or should have the property "Malware Protection". The element type "Server" has the attribute "Malware Protection" but an Element of the type "Software" 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 "Software" does not have this Tagged Value and therefore filters it out.

CONNECTOR {
    SOURCE ELEMENT & 
    TARGET ELEMENT {
        HAS ATTRIBUTE "Malware Protection" != "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 "Malware Protection" != "Strong" |
            HAS NO ATTRIBUTE "Malware Protection"
        )
    }
}

Example 6

The sixth variant is also special because it can be used to determine the Likelihood of a threat to be present inside the system model.

If we think about properties like "Malware Protection" we can assign multiple values:

• Undefined = We don't know whether there is a form of protection.
• No = No Protection installed.
• Weak = Validation, check if the input meets a set of criteria (such as a string contains no standalone single quotation marks).
• Moderate = Sanitization, modifies the input to ensure that it is valid (such as doubling single quotes or removing malicious content).
• Strong = Anomaly Detection, detect anomalies in operation of an Element or in communication, also considers timing or frequency of messages.

It is more likely that a threat occurs if the assigned value is either "Undefined", "No" or just "Weak". We can use this information by applying a special filter to our analysis. We can do this by using the words EVALUATE ATTRIBUTE. The following rule evaluates the property "Malware Protection" from any "Server" inside our system model:

ELEMENT: "Server" {
    EVALUATE ATTRIBUTE "Malware Protection"
}

Normally, a defined rule has a predefined value for its probability of occurrence. However, using this version of the Tagged Value Filter we can override this preset value accordingly to the set value inside the system model.

This allows us to get better results for varying situations.

Further Examples

Adding a Tagged Value Filter to a Connector Pattern:

CONNECTOR {
    HAS ATTRIBUTE "Encrypted" != "Strong"
}

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 optional 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 "Server" we can check if it has no "Strong" "Malware Protection" AND (&) "No" or "Undefined" "Secure Boot" mechanic.

ELEMENT: "Server" {
    HAS INTERFACE {
        HAS ATTRIBUTE "Malware Protection" != "Strong" &
        HAS ATTRIBUTE "Secure Boot" IN ["Undefined", "Strong"]
    }
}

OR Connected Filters

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

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

CONNECTOR {
    (
        HAS ATTRIBUTE "Encrypted" != "Strong" |
        HAS ATTRIBUTE "Trusted" != "Yes"
    )
}

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 or Interface Pattern.

Normally the Connector Pattern includes the optional 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:

• HAS CONNECTOR (Type Filter)? {(Source Element Filter)? (&Source Interface Filter)? ... }
• HAS CONNECTOR (Type Filter)? {(Target Element Filter)? (&Target Interface Filter)? ... }

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

Example 1

The following rule examines all Connectors, originating from a "Device" targeting a "Server". Additionally, the "Server" must be updateable.

ELEMENT: "Device"{
    HAS CONNECTOR {
        TARGET ELEMENT: "Server" {
            HAS ATTRIBUTE "Updateable" != "No"
        }
    }
}

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 "Server" and targeting a "Server" Element . Furthermore, the Source Element must have an incoming Connector from a "Device" Element.

CONNECTOR {
    SOURCE ELEMENT: "Server"{
        HAS CONNECTOR {
            SOURCE ELEMENT: "Software"
        }
    } &
    TARGET ELEMENT: "Server"
}

Example 3

We can also apply the Connector Filter to an Interface Pattern.

The following rule analyzes first if there exists an Element of the type "Device". Then it checks whether this "Device" has a "Wireless"Interfaceand subsequent it checks if there exists a Connector from this specificInterfaceto a "Server".

ELEMENT: "Device"{
    HAS INTERFACE {
        HAS ATTRIBUTE "Interface Type" = "Wireless" & 
        HAS CONNECTOR {
            TARGET ELEMENT: "Server"
        }
    }
}

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 or Interface Pattern.

Normally the Flow Pattern includes the optional 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:

• HAS FLOW {Source Element Filter (& Source Interface Filter)? ...}
• HAS FLOW {Target Element Filter (& Target Interface Filter)?...}

The Flow Filter is exclusive for the Element Pattern and the Interface Pattern.

Example 1

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

ELEMENT: "Database" {
    HAS FLOW {
        TARGET ELEMENT: "Device"
    }
}

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 (CHILD)? Element Pattern
• CONTAINS NO (CHILD)? Element Pattern
• CONTAINS ONLY (CHILD)? Element Pattern
• CONTAINED BY (PARENT)? Element Pattern
• NOT CONTAINED BY PARENT 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 two Elements that are not marked is the "Device" (Phone) to the left and the "Cloud" Boundary. This is because these are 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"
}

Example 3

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

ELEMENT {
    CONTAINED BY PARENT ELEMENT: "Item Boundary"
}

This example shall illustrate the hierarchical levels of the Relation Filter. Compared to the previous example only the "Server" elements are highlighted as they have the "Item Boundary" (Cloud) as a PARENT.

Example 4

We can also check for which Element contains another element.

Following rule analyzes whether there exists an that contains a "Software" element.

ELEMENT {
    CONTAINS ELEMENT: "Software"
}

Please note here that also the "Cloud" is marked as it also contains the "Software" (API).

Example 5

We can also use multiple levels of hierarchy to check the relations of elements.

ELEMENT {
    CONTAINS ELEMENT: "Server" {
        CONTAINS CHILD ELEMENT: "Database"
    }
}

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:

• CROSSES Element Pattern

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

• The Connector Pattern
• The Flow Pattern
• The Connector Filter
• The Flow Filter

Example 1

The following rule examines all Connectors inside the system that cross an Element of the type "Item Boundary".

CONNECTOR {
    CROSSES ELEMENT: "Item 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 "Device" Element and target a "Database".

Flow {
    SOURCE ELEMENT: "Device" & 
    TARGET ELEMENT: "Server"
    CROSSES ELEMENT: "Item Boundary"
}

Further Examples

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

ELEMENT {
    HAS CONNECTOR {
        TARGET ELEMENT &
        CROSSES ELEMENT: "Item 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: "Server" {
    HAS FLOW {
        TARGET ELEMENT: "Application"&
        CROSSES BOUNDARY
    }
}

The Secured By Filter

A Secured By Filter can be used to examine whether Connectors and Flows are enclosed within an Element or Boundary.

Overall, it is the counter part to the Crosses Filter

A Connector is secured by a Boundary or Element if the Source Element or Target Element are both contained by the same Boundary or Element .

General Structure:

• SECURED BY Element Pattern

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

• The Connector Pattern
• The Flow Pattern
• The Connector Filter
• The Flow Filter

Example 1

The following rule examines all Connectors inside the system that are enclosed an Element of the type "Item Boundary".

CONNECTOR {
    SECURED BY ELEMENT: "Item Boundary"
}

Example 2

Since a Flow can consist of several Connectors and Elements, all Connectors of a single Flow must be secured by one defined Element in order that the Flow is secured.

The following rule examines all Connectors within a Flow originating from a "Software" Element and target a "Server" secured by a "Server".

Flow {
    SOURCE ELEMENT: "Software" & 
    TARGET ELEMENT: "Server"
    SECURED BY ELEMENT: "Server"
}

Further Examples

The following rule illustrates the usage of the Secured By Filter in a Connector Filter.

ELEMENT {
    HAS CONNECTOR {
        TARGET ELEMENT &
        SECURED BY ELEMENT: "Item Boundary"
    }
}

Since the rule contains no type-filters, all Connectors that are secured by a Boundary are marked.

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

ELEMENT: "Server" {
    HAS FLOW {
        TARGET ELEMENT: "Software" &
        SECURED BY ELEMENT
    }
}

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 because 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:

• INCLUDES (NO|ONLY)? Element Pattern
• INCLUDES (NO|ONLY)? Connector Pattern
• INCLUDES (NO|ONLY)? Interface Pattern
• INCLUDES FIRST Connector Pattern
• INCLUDES LAST Connector Pattern

This filter is exclusive for:

• The Flow Pattern
• The Flow Filter

Example 2

The following rule examines whether there exists a Flow originating from a "Software" with an Interface targeting a "Database", that includes any ELEMENT that does NOT have a "Strong" "Trusted" value.

FLOW {
    SOURCE ELEMENT: "Software" & 
    TARGET ELEMENT: "Database" &
    INCLUDES ELEMENT {
        HAS ATTRIBUTE "Trusted" != "Strong"
    } 
}

Example 2

The following rule examines whether the system model contains a Flow originating from a "Device" with an Interface that can take wireless connections and determined by the Tagged Value "Interface Type" set to "Wireless", targeting a "Database", that includes no Element that does NOT have a "Strong" "Malware Protection" mechanism.

FLOW {
    SOURCE ELEMENT: "Device" & 
    SOURCE INTERFACE {
        HAS ATTRIBUTE "Interface Type" = "Wireless"
    } &
    TARGET ELEMENT: "Database" &
    INCLUDES NO ELEMENT {
        HAS ATTRIBUTE "Malware protection" = "Strong"
    } 
}

Note: Be aware that double negations inside the Includes Filter can lead to False Negatives

Example 3

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

FLOW {
    SOURCE ELEMENT: "Device" & 
    SOURCE INTERFACE {
        HAS ATTRIBUTE "Interface Type" = "Wireless"
    } &
    TARGET ELEMENT: "Database" &
    INCLUDES ONLY ELEMENT {
       (
            HAS ATTRIBUTE "Malware Protection" != "Strong" |
            HAS NO ATTRIBUTE „Malware Protection"
       )
    } 
}

Please notice the last Tagged Value Filter "Malware Protection" != "Yes" and the last part HAS NO ATTRIBUTE "Malware Protection". This case checks whether the attribute is present and is not assigned to the value "Strong" 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 "Malware Protection" 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.

The specified Connector is highlighted in blue.

Example 4

The following rule examines whether the system model contains a Flow originating from a "Device" with an Interface that can take wireless connections and determined by the Tagged Value "Interface Type" set to "Wireless", targeting a "Database", that includes any CONNECTOR that does NOT have a "Strong" "Encryption".

FLOW {
    SOURCE ELEMENT: "Device" & 
    SOURCE INTERFACE {
        HAS ATTRIBUTE "Interface Type" = "Wireless"
    } &
    TARGET ELEMENT: "Database" &
    INCLUDES CONNECTOR {
        HAS ATTRIBUTE "Encrypted" != "Strong"
    } 
}

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: "Server" &
    TARGET ELEMENT: "Database" &
    INCLUDES ONLY CONNECTOR {
        HAS ATTRIBUTE "Trusted" != "No"
    } &
    CROSSES ELEMENT
}

Example 6

We can also analyze the First and Last Connector of a Flow by using the Includes Filter.

This is the same as we would analyze the Source Element or the Target Element

For example we could analyze whether the first Connector of the Flow crosses a Boundary and the last Connector must originate from a "Server".

FLOW {
    SOURCE ELEMENT &
    TARGET ELEMENT: "Database" &
    INCLUDES FIRST CONNECTOR {
        CROSSES ELEMENT: "Item Boundary"
    } &
    INCLUDES LAST CONNECTOR {
        SOURCE ELEMENT: "Server"
    } 
}

This allows us not only to focus on the starting and ending element.

Further Reading: Attack-Tree Generation

This chapter introduced the basics of the Analysis Rule Language, laying the groundwork for understanding its application in cybersecurity threat analysis.

As a continuation, this documentation includes another chapter dedicated to the generation of attack-trees, which helps visualize and analyze potential attack paths here.

Additionally, this chapter introduces the concept of the Capability Filter, a mechanism for modeling and filtering attack steps based on an adversary's capabilities. Its practical usage is demonstrated through a use case based on ISO 21434, illustrating how this approach can enhance structured threat analysis in the automotive cybersecurity domain.

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})?

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

**Connector** _pattern           ->  (**Connector** _pattern (| **Connector** _pattern)+)
                                CONNECTOR (type_filter)? ({**Connector** _filters})?

flow_pattern                ->  (flow_pattern (| flow_pattern)+)
                                FLOW ({flow_filters})?

element_filters             ->  element_filters (& element_filters)+
                                ( element_filters (| element_filters)+ )
                                tagged_value_filter
                                relation_filter
                                **Connector** _filter
                                flow_filter
                                capability_filter
                                interface_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)+ )
                                source_element_filter
                                target_element_filter
                                source_interface_filter
                                target_interface_filter
                                tagged_value_filter
                                crosses_filter
                                capability_filter
                                secured_by_filter

flow_filters                ->  flow_filters (& flow_filters)+
                                ( flow_filters (| flow_filters)+ )
                                source_element_filter
                                target_element_filter
                                source_interface_filter
                                target_interface_filter
                                crosses_filter
                                secured_by_filter
                                flow_includes_filter

source_element_filter       ->  SOURCE element_pattern

target_element_filter       ->  TARGET element_pattern

source_interface_filter     ->  SOURCE interface_pattern

target_interface_filter     ->  TARGET interface_pattern

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"
                                EVALUATE ATTRIBUTE "key"

relation_filter             ->  CONTAINS (NO)? (CHILD)? element_pattern
                                (NOT)? CONTAINED BY (PARENT)? element_pattern

**Connector** _filter            ->  HAS (NO)? CONNECTOR (type_filter)? ({**Connector** _filters})?

flow_filter                 ->  HAS (NO)? FLOW ({flow_filters})?

crosses_filter              ->  CROSSES (NO)? element_pattern

secured_by_filter           ->  (NOT)? SECURED BY element_pattern

flow_includes_filter        ->  INCLUDES (element_pattern | **Connector** _pattern | interface_pattern)
                                INCLUDES NO (element_pattern | **Connector** _pattern | interface_pattern)
                                INCLUDES ONLY (element_pattern | **Connector** _pattern | interface_pattern)
                                INCLUDES FIRST **Connector** _pattern
                                INCLUDES LAST  **Connector** _pattern

component_capability_filter ->  REQUIRES CAPABILITY "capability_key" >= "capability_value"
                                PROVIDES CAPABILITY "capability_key" := "capability_value"