Risk Determination and Treatment

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:

  • Name: Usually an identifier, e.g., "R.1"
  • Title: a short, meaningful outline of the risk. This title will be auto-generated, if left empty. (e.g. Spoofing on CAN Bus).
  • Impact Category: Shows the Risk Level per Impact Category. This is useful to see which Impact Category is the cause for the Risk. (e.g. Safety)
  • Stakeholders: Shows the Risk Level per Stakeholder and Control Scenario, having the Stakeholder as root. This is useful to show the road user impact next to the business impact.
  • Control Scenarios: Shows the Risk Level per Control Scenario and Stakeholder; having Control Scenarios as root. This is useful to show the road user impact next to the business impact.
  • Caused by: Lists the Threat Scenarios or Attack Steps that cause this Risk. We recommend one risk per Threat Scenario. The Risk Assistant takes care of having at least one Risk per Threat Scenario.

Risk Assistant

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:

Risk Treatment Decision

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:

  • Av: Avoidance via assumptions or removal of the threatened asset,
  • R: Reduction via mitigating controls,
  • SoT: Share or Transfer with someone, e.g. supplier, group, team,
  • Ac : Acceptance of the current risk level.

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. End Iteration stores the current decisions as a snapshot and creates a new iteration which might include additional risk. Delete will delete the current iteration. Update 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

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 Control Groups chunk. The chunk can be added from the context menu of you TARA model via New RootsUtilitiesControl 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 Control scenarios . 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.

Propagation Expressions

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:

  • must: an attacker must overcome a combination of all provided path elements, e.g., an Attack Step’s Attack Feasibility and its preparing attack step
  • may: an attacker may choose the weakest option of the provided path elements, e.g., picking the highest-feasibility Attack Step of a Threat Scenario

Security Elements

Security Elements can be expressed in the same terms as propagation expressions: as expressions with may and must. This table shows how they relate:

Element Propagation path
Threat scenario
An attacker must overcome the Attack Steps from the Attack Tree expression.
In any case, the attacker must accept the transformations which arise from this elements dampedBy assumptions.
Attack Step
An attacker must overcome all of these:

- the locally declared Attack Feasibility

- exploit the threats from the PreparedBy expression

- the controls from the mitigatedBy expression
An attacker may choose to

- either break the Controls-declared Attack Feasibility (transformations of the Control are not active), or

- 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 effect of the transformations.
- 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., AND(C.1, A.1)) are synonymous. Moving a transformation from A.1 to C.1 won’t change the calculation results, assuming no other uses of A.1 and C.1).