Configuration Aspects Copy link to clipboard

The Method Configuration is split up in three main parts and an optional fourth:

• Impact Model: defines security properties, impact levels, stakeholder, impact categories, and impact options.
• Feasibility Model: defines attack feasibility levels (AFL), feasibility options, and attack feasibility table.
• Risk Model: defines risk levels, risk matrix, risk treatments, propagation operations, as well as feasibility and impact combinators.
• Trust Model: defines trust levels, and trust boundary categories (optional).

You can access it from the project navigation:

Note: If using attack vector or CVSS-based rating, the feasibility model cannot be modified. Instead, the factors are based on CVSS 3.0 and are limited to: attack vector (AV), attack complexity (AC), privileges required (PR), user interaction (UI).

Impact Model Copy link to clipboard

The Impact Model is a requisite element of the Method Configuration that defines the security properties, impact levels, impact categories, impact options as well as stakeholders. The rating values which are configured and declared in each element are not static, they are customizable in order to meet your internal requirements. The following properties can be configured:

• Security Properties
• Impact Levels
• Stakeholders
• Impact Categories
• Impact Scaling Options
• Impact Options

Security Properties

Security Properties such as Confidentiality, Integrity, Availability, Authenticity, Authorization and Non-Repudiability can be configured in this section. Its primary focus is the balanced protection of these attributes while maintaining a focus on efficient policy implementation, all without impeding organization productivity. The configuration of the security properties is editable within this section, just simply hit “Enter” and a new line will appear to add any other category (e.g. authenticity) and type in the name and descriptive title.

Impact Levels

The Impact Levels capture the potential effect resulting from a compromise of the impact categories, by default expressed as a value of negligible, moderate, major and severe. The magnitude of harm that can be expected to result from the consequences of threatening impact categories, e.g. safety, financial, operational, or privacy. These values are not static; thus, you can modify them according to your own requirements. You may specify a name, descriptive title as well as a numeric borderline value for the specific impact levels. The color can be adjusted in the inspector per impact level.

Stakeholders

Stakeholders such as the road users, OEMs or business units on which the impact implies can be declared in this chapter. This prepares for analyzing risks per stakeholder while only maintaining a single TARA. You can fine-tune the stakeholders as needed.

Impact Categories

The Impact Categories reflect the area of impact and/or physical harm associated with a damage scenario. The damage scenarios must be assessed against potential adverse consequences to stakeholders in the independent impact categories of safety, financial, operational, and privacy (SFOP) which is the minimum set of categories based on the ISO 21434 standard regulation. If further impact categories are considered beyond SFOP, then those categories must be documented. While SFOP are core categories used to rate impact on the road user, additional categories can be defined here.

Impact scaling Options

In case more than one item or component is impacted, you can scale accordingly in damage scenarios based on the following scaling options. The impact scaling options can be extended and consist of a name, descriptive title and the numeric scaling factor which shall be applied.

Impact Options

Impact Options declare what options per category are applicable when rating damage scenarios. Furthermore, a category is assigned to one ore many stakeholders. The declared ratings are visible once you click on the + to expand the view as visualized in the image below. An impact option consists of a name, descriptive title and a numeric value. The numeric value is used to conclude to one of the declared impact levels per damage scenario.

Feasibility Model Copy link to clipboard

The Feasibility Model is an important part of the Method Configuration and contains the Attack Feasibility Levels (AFLs), the Feasibility Options and the Attack Feasibility Table. The following properties can be configured:

• Attack Feasibility Levels (AFLs)
• Feasibility Option
• Attack Feasibility Table

Attack Feasibility Levels

AFLs show the potential feasibility level that can result from an attack. By default, the four levels Very Low, Low, Medium and High are defined. In general, lower values have a more critical impact on the AFL, however this can be modified if required. Furthermore, you can rename, expand or even change the threshold values of each level. You can add more AFLs with a simple enter. Make sure that your cursor is in an existing AFL. The image below shows the default AFLs:

Feasibility Options

Feasibility Options are the evaluation criteria for AFLs. The itemis SECURE already includes the following categories by default:

The categories and values which are already configured are not static, they are customizable in order to meet your internal requirements. That means you can delete or add further categories and you can configure the corresponding levels according to your needs.

Attack Feasibility Table

In addition to an Initial Attack Feasibility Assessment, itemis SECURE also offers the possibility to perform Consecutive Attack Feasibility Assessments. The Final Attack Feasibility combines the Initial Attack Feasibility and the Consecutive Attack Feasibility. This is obtained using the following table:

The table shown above is stored by default in the itemis SECURE. The Attack Feasibility Table can also be personalised by simply overwriting the existing values.

Risk Model Copy link to clipboard

The Risk Model is a requisite element of the Method Configuration that defines the isk levels, risk matrix and propagation / aggregation options. The following properties can be configured:

• Risk Levels
• Risk Matrix
• Risk Treatment Options
• Propagation Operations

Risk Levels

In this section you can define your set of risk levels that shall be used in the corresponding risk analysis. By default, we start with 5 risk levels, aligned with the ISO/SAE 21434. You may add new levels and rename them. The color can be adjusted in the Risk Level’s Inspector.

Risk Matrix

The Risk Matrix defines how Attack Feasibility and Impact conclude to a Risk Level. The Attack Feasibility definitions originate from the Feasibility Model. Impact level definitions originate from the impact model.

Risk Treatment Options

For each identified risk you may want to decide for a appropriate Risk Treatment Option. The available options can be configured here. As a starting point, the following options are available:

Propagation Operations

In this chapter you may tailor the propagation related properties to your needs. Whenever you make changes in this section, make sure to apply the Method Configuration via the tool bar button in order to apply the changes to your TARA:

The following properties can be configured:

• Feasibility Combinators

Feasibility combinators can be created or adjusted here. The default “Acc” accumulates the options and impact transformations.

• Impact Combinators

Impact combinators can be created or adjusted here. The default “Max” takes the maximum out of all rated impact categories.

• Default Feasibility Combinator

Select the active / default combinator which shall be used in your TARA.

• Default Impact Combinator

Select the active / default combinator which shall be used in your TARA.

• Propagation operations

Define the semantics and name of your propagation operations. (e.g. rename the “may” operator to “or”).

• Default propagation operations

Define the propagation operation which shall be created when introducing new elements via assistants.

Trust Model Copy link to clipboard

In contrast to the previous three method configuration models that are essential for the calculation of risk levels in your project, the Trust Model can be seen as an optional addition to the general processes that itemis SECURE is assisting in. It serves as the main configuration point to assess the trust boundaries between components and the trust level differences that data flows bridge. Currently, trust models and the subsequent elements related to the trust model are only used to suggest an order of operation when deriving your threat scenarios, but they won’t influence anything beyond that, especially not having any influence on the calculated risk levels. For a deeper explanation on the Trust Analysis, check the respective section in the TARA chapter.

The following properties can be configured:

• Trust Levels
• Trust Boundary Categories

Trust Levels

In this section, you can define your set of trust levels, that shall be used in the corresponding trust analysis. By default, we start with 5 trust levels. You may add new levels, or remove or rename existing ones. The color can be adjusted in the trust level’s Inspector. A trust level has a trust rating that indicates the trustworthiness of this level. A lower trust rating represents a lower trustworthiness, and a higher rating represents a higher trustworthiness. All trust ratings have to be positive, therefore a rating of 1 represents the lowest possible trustworthiness but the scale has no defined upper bound.

Trust Boundary Categories

In the trust analysis process of a project, itemis SECURE will ultimately derive trust boundaries from trust levels. These trust boundaries are essential for identifying and visualizing trust level discrepancies, especially when data is transferred between components with varying trust levels. See the Trust Analysis section for more details on trust boundaries. To visually differentiate trust boundaries of different severity, the trust model defines trust boundary categories. Trust boundaries will automatically be sorted into these categories. A trust boundary category consists of an upper limit for the trust boundary’s rating and a color specification. The rating of trust boundaries can range from 0 to the highest defined trust level rating. If no matching trust boundary category is found for a trust boundary, no highlighting will take place.