Goal: Identification of risks based on recorded threat scenarios and attack steps. Risks illustrate the risk level present on a threat scenario, attack step, or security control. A risk element can be used to determine the impacted stakeholder, related impact categories and see the control scenarios side by side.
A risk has the following properties:
You may create the above mentioned risk elements manually. However, to speed things up, it is recommended to use the risk assistant which will suggest creating a risk for each threat scenario in order to be inline with the ISO/SAE 21434 suggestion.
As with all assistants, you can either accept suggestions which results in creating a risk for the assessed threat scenario. Alternatively, you can reject the suggestion and give it a rationale. The following image depicts the assistant after generating the links between threat scenarios TS.7, TS.8 and TS.9 and its corresponding risk elements R.2, R.3 and R.1:
The risk treatment chunk allows tracking the treatment decisions per risk side by side with the rationale per decision.
The available risk treatment decisions originate from the risk model in your method configuration. By default, the following treatment decisions are available:
You may create multiple snapshots of the current decisions and run multiple iterations. An iteration is numbered, has a defined end date, tracks the last change and lists the risk treatment decisions. % stores the current decisions as a snapshot and creates a new iteration which might include additional risk. %[Delete] will delete the current iteration. % makes sure, that the list includes all risk that have been modeled as part of the TARA. %[<] and [>] navigates to the previous or next treatment iteration.
Control groups allow the definition of a set of controls. These control groups ease the definition of control scenarios. Instead of listing all individual controls in each control scenario, you may re-use control groups. Control groups can be declared within the % chunk. The chunk can be added from the context menu of you TARA model via %New Roots > Utilities > Control Groups.
The inspector of a security control allows you to group security controls in control groups for a later usage in control scenarios (cf. section
). To add a group, open the inspector of a control and type the desired name into it. It will be highlighted in red. After that, run the completion (
[Ctrl+Space]) to create the group. It will then be highlighted in blue:
To add another group, just hit
@ or @[Return] as usual. Existing groups can be selected with
[Ctrl+Space]. This means, you can either create new control groups in-line within the control, or in the above mentioned control groups chunk.
Risk is calculated by propagating attack feasibility and transformations together up the attack tree, and then propagating the resulting impact and risk down from each threat scenario. itemis SECURE then picks the path that yielded the highest risk and displays it.
The graph of security entities is being declared based on
propagation expressions, such as
AND(attack step 1, attack step 2). With such propagation expressions, attack feasibility options and transformations need to be combined with one of two flavors:
Security elements can be expressed in the same terms as propagation expressions: as expressions with
must. This table shows how they relate:
An attacker must overcome the attack steps from the
In any case, the attacker must accept the transformations which arise from this elements
An attacker must overcome all of these:
- the locally declared
- exploit the threats from the
- the controls from the
An attacker may choose to
- either break the controls-declared
- realize a threat scenario which is threatening the control (transformations of the control are not active), or
- don’t break any of the two above and accept the
- An attacker must accept the effects listed in all attack paths that contain this assumption.
- Note that the effect of a control and a may-choose-weakest-connected assumption, e.g.,