Imprint Privacy policy Terms & Conditions Sitemap

Attack Path Analysis

Goal: Identification and Estimation of Attack Steps that realize the Threat Scenarios and Damage Scenarios

Attack Steps are modeled in Risk Analysis chunks, by creating “Attack Step”-elements. Attack Steps are realizing one or multiple Threat Scenarios.

Attack Steps have the following attributes:

  • Name: usually an identifier, e.g., "AS.2"
  • Title: a short, describing outline of the attack step
  • Instantiated Threat Class: It is recommended to instantiate a threat class from the Threat Catalog. In general, these classes feature predefined feasibility categories for known attacks.
  • Acts on: Attack Steps need an element of the architecture where they can be executed. These elements can be documented here as a list by pressing Enter.
  • Threatens: List of realized Threat Scenarios. An Attack Step threatens a number of Threat Scenarios. This relation is only displayed here because it is defined at the Threat Scenario itself. However, by selecting the “plus” sign and pressing Ctrl+Space you can add the current Attack Step to a Threat Scenario.
  • Mitigating Controls: In case Security Controls have been documented in the analysis, they can be selected here to act against Attack Steps.
  • Preparation Steps: Some attacks need preparing Attack Steps to be executed first. You can define single Attack steps or build a complex tree using logical expressions.
  • Feasibility Rating per Category: You can estimate the Attack Feasibility to implement the Attack Step via the feasibility model’s Feasibility Categories. Furthermore, you can inspect the accumulated ratings. These fields aggregate the childrens' feasibility (of Attack Steps or Controls) blended with the local rating. The given initial factors can be expanded to include Feasibility Categories for a consecutive attack by executing the intention add Feasibility Categories for consecutive Attack on the Attack Step Alt+Enter . The selection of a value for each factor is done by pressing Ctrl+Space in each cell.
  • Resulting risk level: Shows the Risk Level, based on the Feasibility Level and Impact Level, optionally per cybersecurity property and stakeholder.

The estimation of the Attack Feasibility is based on Feasibility Categories. itemis SECURE will suggest Feasibility Categories automatically from the instantiated Threat Class. They will be shown in gray color and can be replaced manually by your own estimation.

The following attributes can also be edited in the inspector of an Attack Step element:

As usual, name, title, and description can be set. If required, you can overwrite the computed feasibility values by explicit ones: Navigate to the respective fields and press Ctrl+Space. Any explicit value requires you to specify a reason in the rationale field. Furthermore, the aggregation logic for feasibility and impact can be overridden and a link to external artifacts included.

Derivation of Attack Feasibility Ratings

On Attack Steps, Controls, and their classes, the Attack Feasibility is described in terms of Feasibility Options.
By default, Attack Steps, Controls, and classes derive their feasibility options from their refined/ instantiated classes (gray).

However, the derived value may be overridden by selecting a gray inherited value (e.g. Eq1) and picking a different value via Ctrl+Space (e.g. Eq2) . When overriding a value, its text turns blue, and the inspector allows to provide a rationale. Whenever this factor changes in the elements catalog class, it will no longer have an effect on this element. To start deriving it again, simply delete the overriding level, and the gray derived level will appear again.

Furthermore, you can inspect the accumulated ratings. These fields aggregate the childrens' feasibility (of Attack Steps or Controls) blended with the local rating.

In the figure above, Ex2 is derived and Eq2 is overridden.

This derivation works similarly for the feasibility options of Threat Classes and Control Classes when they refine other classes.

It may be desirable to override a derived level with the same value to decouple an element from its class. Often times, if an element has an overridden level that equals to its derived value and also the rationales are equal (or both are null), then it may still be desirable to remove it, so that changes in the catalog automatically spread into projects. That’s what the migration remove redundant feasibility option assignments does. You can find it in the main menu under Migration → Migrations → Language Migrations → c.moraad.core. It will remove only level assignments that are exactly identical to the overridden value, so running this migration does not effect the current outcome of the analysis.

Controls

Goal: Identification and Estimation of Security Controls for the Mitigation of Attack Steps

Security Controls are defined comparable to Attack Steps and Threat Scenarios in a Risk Assessment chunk via the following attributes:

  • Name: usually an identifier, e.g. "C.1"
  • Title: a short, describing outline of the control
  • Instantiated Control Class: Controls can optionally instantiate Control Classes from the catalog – including pre-evaluated Feasibility Categories.
  • Threatened by: Security Controls may be threatened by one or many Threat Scenarios. This relationship can be defined via boolean expressions.
  • Mitigating Attacks: The Attack Steps mitigated by this control are listed here. The actual assignment is done on the attack step itself.
  • Effect: What happens if the attacker chooses to neither overcome the control’s own Attack Feasibility nor break any of its dependencies? By default, the impact will be reduced to none, removing this Attack Path from consideration.
  • Attack Feasibility: Similarly to Attack Steps, Controls are estimated regarding the Attack Feasibility that is necessary to break the control (based on Feasibility Categories for Initial and Consecutive Attacks).

The inspector of a control features the same attributes as for an Attack Step.

The three Alternatives of a Control

A control has three propagation branches: An attacker may choose to either

  • accept its effect, or
  • break it by putting in the effort that is described by its own feasibility rating, or
  • bypass it by breaking some of its dependencies as described by the `Threatened by` relationship of the control.

Accept

Controls start with `Remove all impact` as their effect. Which means, there is no risk along its paths as long as the control is intact. Whenever this was changed to some other effect (e.g. S3->O2, transforming safety impacts to operational in case of a failsafe state), there might be some remaining impact and risk.

Break

The path to break a control is described with its own feasibility rating.

Bypass

In the Attack Paths that bypass a Control, its own Feasibility Ratings and its described effects are not considered. Note the following gotcha: This differs from the Attack Steps, where the own Feasibility Rating of an Attack Step is part of the preparatory paths.

Control Scenarios

Goal: A side-by-side Comparison of Security Concepts

In some assessments it is interesting to evaluate the effect of different Security Concepts (collections of Security Controls) on the identified risks. In general, a risk takes every present control into account when calculating the Risk Level. To exclude or include sets of controls from these calculations, a “scenario” can be added to a Security Analysis Chunk. A Control Scenario is not selected per risk. Only one Control Scenario can be active at a time per project.

Using the Controls attribute, you can specify which controls shall be included in the calculations. Every other control will be discarded (in the scope of this scenario). Below, you see two scenarios. The first one includes All controls (a special, pre-defined group), and the second scenario includes no controls.

Every Risk Element now includes a new line for each scenario and displays the modified Risk Level.

Visualization

Larger analyses tend to incorporate a considerable amount of Damage Scenarios, Attack Steps, Threat Scenarios, and Controls, including relations in between. A graphical visualization, a dependency graph, is helpful to obtain a better understanding of the modeled information. This visualization can be opened from the main toolbar or with a right-click on one of the displayable elements and then selecting View Graph.

The graph is rendered starting with the selected element including all elements that can be reached following the modeled relations (“threatened by”, “mitigated by”, “depends on”). The graph can be rendered following these relations downwards, i.e., following the original direction, upwards, i.e., following the opposite direction, (i.e., “threatens”, “mitigates”, and “is dependency of”), and both directions.

The nodes of the rendered graph can be selected and used as new starting point; use the buttons in the tool window just above the graph. The visible content for each element can be switched using the remaining toolbar buttons, e.g., short vs. long name, Impact and Attack Feasibility vs. Feasibility Categories. Attack Trees can be exported as PNG or SVG with the corresponding buttons in the toolbar.

When Impact and Attack Feasibility are displayed, you can click on the corresponding box to highlight the path of all elements that affect the calculated value.

Assumptions

Assumptions are required properties of a system that are needed to accomplish cybersecurity goals. Assumptions can be divided into environmental assumptions, which capture characteristics of the environment of an item, and Analysis Assumptions, which document all non-environmental assumptions within the project. This is usually an ongoing task in the analysis.

Created elements of the assumption contain the following attributes:

  • Name: usually used as an identifier, e.g., “A.1”.
  • Title: a short, meaningful outline of the assumption.
  • Description: The description is specified in the Inspector.
  • Limiting the Risk Level: Setting the maximum Risk Level limit.
  • Limiting the Impact Level: Setting the maximum Impact Level limit.
  • Limiting the Feasibility Level: Setting the maximum Feasibility Level limit.
  • Further dampening Effects: Assumptions may add further dampening effects, for example Impact Transformations. It is possible to transform entire Damage Scenarios into others (e.g. DS.1 => DS.2), or transforming selective Impact Options (e.g. RU.O2 -> RU.O1). Furthermore, Damage Scenarios and Options can be removed, if transformed to NULL. Last, Assumptions can be used to remove the entire impact of an Attack Path. This Attack Path will be considered impossible then.

Damage Scenario Assignment Assistant

The Damage Scenario Assignment Assistant walks the tree of the item and considers threatened cybersecurity properties and suggests potential missing relations between Damage Scenarios and realizing Threat Scenarios. Damage Scenarios will be listed here side by side with potential Threat Scenarios that might threaten it. Accepting a suggestion will realize the current Damage Scenario with the applied Threat Scenario. As usual, you can reject suggestions and give it a rationale or reset existing links.

The suggestions of the Damage Scenario Assignment can be configured by the user. The configuration is stored in separate chunks next to the Method Configuration Models:

  • Production Rules: These rules define the relations between elements in the SUD. These relations are traversed to find possible Damage Scenarios that might be realized by a Threat Scenario. Starting point is the SUD element to which the originating Damage Scenario (via the qualified assets) is assigned. Examples for relations are “Subfunction”, “Parent Function”, “Subcomponent”, “Parent Component” etc.
  • Security Property Matrix: This matrix describes how security properties depend on each other. For example, if integrity is broken, confidentiality is also affected, but if availability is broken, this does not affect confidentiality. Such dependencies can be configured for each kind of SUD element individually, e.g., if the integrity of a component is broken, this will probably affect confidentiality, integrity, and availability of the functions mapped to the component, but if the integrity of a function is broken, this probably does not affect any class of any component the function is mapped to.

Threat Scenario Identification Risk Determination and Treatment