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 ore multiple threat scenarios.
Attack steps have the following attributes:
[Ctrl+Space]you can add the current attack step to a threat scenario.
@). The selection of a value for each factor is done by pressing @[Ctrl+Space]in each cell.
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.
On attack steps, controls, and their classes, the attack feasibility is described in terms of
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.
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:
The inspector of a control features the same attributes as for an attack step.
A control has three propagation branches: An attacker may choose to either
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.
The path to break a control is described with its own feasibility rating.
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.
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 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:
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: