itemis SECURE 23.3
Overview
With SECURE 23.3 we finally introduce the long awaited addition for even better ISO/SAE 21434 coverage: the Concept Phase (also known as "ISO/SAE 21434 Clause 9"). It will greatly improve your analysis results, as it makes them more coherent and helps you document why certain already included aspects like Controls and Assumptions were added to your analysis. Furthermore artifacts from the Security Concept Phase can serve as additional documentation of your efforts towards securing your automotive platform. In addition the update introduces several usability and functionality improvements and updates.
We believe these enhancements will significantly improve your experience with SECURE, making it even more effective for security analysis and documentation. We're dedicated to continually refining our tool, so stay tuned for more improvements in future releases. We appreciate your continued support and look forward to further improvements in future releases as we strive to make SECURE the best tool for your TARA Process needs.
Teaser for the Security Concept Phase
As many customers will already have projects and analyses that were started before our introduction of the Security Concept support, we wanted to help you to the best of our abilities to get up to speed and start with your Security Concept right away. For that you can make use of an automated action that we provide with this version that will add the necessary chunks to your project. Read more about that in the section Help to integrate the Security Concept Phase into existing projects. All the existing examples also received an update and now include the new chunks and furthermore contain new instances of the new types as well.
Security Concept Phase
The concept phase involves consideration of vehicle level functionality, as implemented in items. The item definition forms the basis for the subsequent activities.
In the concept phase you may specify cybersecurity goals for the item (i.a.w. ISO/SAE 21434 clause 9.4), which are the highest level of requirements. For this purpose, cybersecurity risks are assessed, which is derived from existing TARA activities (i.a.w. ISO/SAE 21434 clause 15). In addition, you may specify cybersecurity claims, which are used to explain why risk retention or sharing are considered adequate.
The cybersecurity concept (i.a.w. ISO/SAE 21434 clause 9.5) consists of cybersecurity requirements and requirements on the operational environment, both of which are derived from the cybersecurity goals and based on a comprehensive view of the item. If you already have an existing TARA model, itemis SECURE provides guidance to derive requirements from Assumptions and Controls in your attack trees.
New Element Types
We've introduced new types in accordance with ISO/SAE 21434 to enhance compliance. All of these types are encapsulated within the Security Concept folder.
Requirements
A new chunk reflecting Cybersecurity Requirements has been added. A Requirement can be easily added in the same way as all existing security analysis elements and linked with controls or assumptions.
A Requirement consists of a title, name, and a list of elements. The elements can be either Assumptions or Controls. A Requirement has two types, Operational and Technical, determined by the type of elements it contains. An Operational Requirement references Assumptions, while a Technical Requirement references Security Controls.
If a user attempts to add different types of elements to one Requirement, a warning will be triggered.
We recommend using our assistants to derive Requirements from existing Controls and Assumptions instead of crafting them manually.
Goals
A new chunk reflecting Cybersecurity Goals has been added. A Goal can be easily added in the same way as all existing security analysis elements.
Each Goal comprises a title, name, risk and a list of requirements.
The assigned risk should be a risk that has been treated as Reduced in the Risk Treatment chunk; otherwise, a warning will be triggered. Only technical requirements should be assigned to a Goal; otherwise, a warning will be triggered. Cybersecurity Assurance Level (CAL), cause of compromise and other details are available in the inspector.
We recommend using our assistants to derive Goals from reduced Risks instead of crafting them manually.
Claims
A new chunk type reflecting Cybersecurity Claims has been added. A Claim can be easily added in the same way as all existing security analysis elements.
Each Claim comprises a title, name, risk and a list of requirements.
The assigned risk should be a Risk that has been treated as Shared or Retained in the Risk Treatment chunk; otherwise, a warning will be triggered. Only Operational requirements should be assigned to a Claim; otherwise, a warning will be triggered. Cybersecurity Assurance Level (CAL), cause of compromise and other details are available in the inspector.
We recommend using our assistants to derive Claims from shared or retained Risks instead of crafting them manually.
Security Concepts
A new chunk type reflecting Cybersecurity Concepts has been added. A Concept can be easily added in the same way as all existing security analysis elements.
Each Concept comprises a title, name, a Scope (in the form of a list of System Elements), and a list of Technologies, a list of elements (Goals or Claims).
If neither a Scope nor a single Technology is given, the Concept is not limited to a specific subset of all Goals and Claims and is implicitly meant to cover all Goals and Claims.
We recommend using our assistants to populate the Security Concept based on the given scope instead of assigning Goals and Claims manually.
New Assistants
Alongside the new types we added new assistants to support you in deriving new instances from existing TARA elements like Risks and Controls.
Requirement Assistant
To document the purpose of Controls and Assumptions, the Requirement Assistant will help you create these Technical and Operational Requirements in your project. The assistant suggests adding technical requirements for Controls and operational requirements for Assumptions.
Goal Creation Assistant
Enables effortless creation of Goals for reduced risks — or risks that should lead to Goals based on your custom Risk Model — with pre-assigned meaningful titles.
Claim Creation Assistant
Streamlines the process of creating Claims for risks that have been retained/shared — or risks that should lead to Claims based on your custom Risk Model — with automatic assignment of meaningful titles.
Goals and Claims Assignment Assistant
Assigns relevant requirements to Goals and Claims. A Requirement is relevant for a Goal or Claim, if — based on the Attack Tree of the Goal's or Claim's Risk — the Control or Assumption of the Requirement may influence the calculated Risk Level.
Concept Update Assistant
Facilitates the addition of Goals and Claims to a Concept based on the Concept's Scope and Technologies. It ensures alignment with the risk, targeting the same scope as the concept.
If the Risk of a Goal or Claim targets the same scope as the concept (or a scope that can be derived from the Production Rule Set), then these elements should be added to the Concept as Elements.
Showcasing the new features
We made sure that you will be able to take a look at usages of the new types and assistants in our shipped examples. This should help you get familiar with them and add them to your existing projects.
Help to integrate the Security Concept Phase into existing projects
To support you starting with the Concept Phase in your existing projects, we offer an action to create the basic chunks and assistants such that you are set to immediately begin doing your work of documenting the purpose of Controls and Assumptions.
For that, assuming you don't have any chunks of the new Security Concept Phase yet, there is an action in the context menu of Analysis Solutions, to add all the new Assistants and the default chunks into the selected model.
Changes to existing features due to the Security Concept Phase
We wanted or had to update existing workflows to accommodate for the Security Concept Phase. This was mainly done to be able to "link" existing entities to the new elements and to create a more coherent user experience.
A Risk Treatment now "leads to" either the Goal-type or the Claim-type
As our Risk Model is highly customizable, it is up to you which types of Risk Treatments you make use of. If you want to benefit from the new Security Concept Phase types however, itemis SECURE has to know how they slot into the existing design of Risk Treatments and how their Risks will be taken care of. Therefore, you have to specify whether a Risk treated by your custom Treatments would either lead to Goals or Claims.
:::note Note on migration For the default Treatments provided with itemis SECURE based on the ones that ISO 21434 suggests, we will help you migrate your existing models. If you open your project with the new version, we will do educated guesses based on these sources. For any custom Treatments however it is up to you to provide this information. You can see whether your Risk Model needs any further input either by checking the Composition solution or the MethodConfiguration model, as missing leads to values will result in warnings. Alternatively you can execute the Pre-Update Check (under Migration → Run Pre-Update Check in the main menu) after you already migrated your project, as this will highlight missing leads to values as "migrate manually" results. :::
General Assistant Changes
To improve user experience and bolster traceability, significant changes have been made to Assistant functionality. These enhancements aim to provide users with a more intuitive and efficient workflow when working with Assistants in SECURE.
Adding a New Assistant
Instead of selecting Utilities > Assistant, users now have to add a new Assistant by navigating to Assistants > [Exact Assistant Type] instead. The former context menu entry created for now unspecified assistants that can no longer be created.
Changing Assistant Type
The type of an Assistant cannot be changed after creation. To promote consistency and traceability, users are now required to choose the Assistant type while creating them and will no longer be able to switch between them afterwards. That improves traceability, as switching the type of an existing Assistant previously led to the forgetting of "Rejected" decisions and removal of all rationales.
Unassigned Assistants
If an Assistant in your model lacks a type assignment, it is recommended to simply delete the Assistant and create a new specific one for the intended use case. This ensures accurate type assignments and optimal functionality.
Updated Folder Structure
Assistants are now organized in folders under their respective portion of the solution for new projects. This organizational change reflects the segmentation of Assistants for different segments of SECURE, providing a more structured and easily navigable environment.
Improvements and Fixes
Default visibility of the Assistant's explanation text
We now by default hide the explanation again to save space. You can still inspect the explanation by clicking What's this?.
Fixed unavailable rationale for Risk Assistant
Due to an oversight, the Risk Assistant had no option to provide rationales in case an assistant suggestion was rejected. That was fixed, you now can add a rationale in this assistant as well.
Fixed Risk Treatment chunk
Previously deleting a risk in the risk chunk broke the Risk Treatment chunk. And while deleting a risk in the new version still will leave dangling references that you have to resolve by updating the Risk Treatment to get rid of the broken reference, the UI of the Risk Treatment chunk won't change due to deleting a risk anymore.
Report Comment Obfuscation
To prevent some of the red texts in chunks, we have made changes to the obfuscator. Comments in reports will now be replaced with constant text to avoid confusion.
Cross-Solution References to TARA elements
Attack Steps, Controls, and other elements are now referenceable from other solutions within the same project, promoting seamless integration and collaboration.
Prevent Warnings about Multiple Terminology Profiles
In previous versions, the setup of new projects triggered warnings due to multiple terminology profiles. We've resolved this issue by eliminating the cause of these warnings, ensuring a smoother project setup experience without unnecessary warnings in fresh and empty projects.
Default "AllControls" Scenario Activation
This release addresses an oversight in the "All Controls" scenario within newly created projects. Previously, this scenario failed to declare the activation of all controls. With the fix, the default scenario now accurately represents and activates all controls, ensuring a more robust default setup.
Reduction of Unnecessary Warnings
To enhance user experience, we've streamlined the warning system for Attack Steps without a linked threat class. Instead of several warnings, only one is now issued, which makes the warnings clearer and more concise.
Fixed Name Pattern
Name Patterns had an issue when integrating minus characters or question marks; in such cases, the automatic element numbering would ultimately break. This issue has been addressed in this version. Additionally, an error will appear if your name pattern contains digits. Digits in Name Patterns have always been a problem, but with this new error message, you will now be informed if and why your auto-numbering will break.
Version Mapping
The following table can be used to determine the itemis SECURE version based on the internal plugin version com.moraad.core stored in the .msd file of every solution:
<language slang="l:2bca1aa3-c113-4542-8ac2-2a6a30636981:com.moraad.core" version="<com-moraad-core-version>" />
| com.moraad.core version | itemis SECURE version |
|---|---|
| 90 | 23.3 |
| 89 | 23.2, 23.2.1 |
| 88 | 23.1.1 |
| 87 | 23.1 |
| 86 | 22.4 |
| 81 | 22.3 |
| 80 | 22.2 |
| 78 | 22.1 |
| 74 | 21.3 |