itemis SECURE FAQ
Given I have an assumption or any other risk analysis element
When I right click it and select “Find Usages”
Then I see a tool window with a grouped list of usages of that assumption
When I double click an element of it
Then I see the model element (e.g. Attack Step) that references my assumption
Context menu of your model element
Result windows listing the found references
One of the referencing elements
2. There is a file “seca64.exe.vmoptions“: Open it with a text-editor.
Motivation
In case you have multiple distributed teams, which will work on threat analyses (TARAs) collaboratively, you may need a workflow that serves this purpose. You may want to split the TARA for organizational reasons or to make large projects manageable. The team shall be able to refine its target of evaluation (TOE) and create its own TARA iterations. In the end, it shall be possible to have a complete TARA which includes all sub-TARA results.
Workflow
- Use your version control system (e.g., Git)
- Have a common starting point (e.g., “master”)
- Branch off per dedicated team or sub-chunk (e.g., “function1”, “function2”)
- Use tool supported merge to get changes back
The corresponding git graph should look about like this. In this example we have a “master” branch which is synchronized with two feature branches.
Sample Git graph
Showcase
Create a new project and model your initial TOE. Have these changes on a dedicated branch in your version control system, let’s call it “master”. The following example contains two shared components and a common data flow which transfers “D.1”.
Initial System Model
Having this common ground, we may create several branches that shall contain the individual sub-function threat analyses. (e.g., a branch per team or per sub function) The TOE can be refined, and an initial threat analysis can be started independent of each other. In our showcase these branches are called “Sub-Function-1” and “Sub-Function-2”. In the example below, on each branch new components, data flows and data elements have been created. “Sub Function 1 Component” with contained data on the one hand and “Sub Function 2 Component 1” with a data flow to “Shared Component 1” on the other hand.
Changes “Sub Function 1”
Changes in “Sub Function 2”
Once the individual teams are done with their first TARA iteration you may merge back the changes to the common “master”-branch. itemis SECURE supports graphical merging within the tool so that we can see the changes in the model instead of messing with text files. After the merging, the resulting system diagram and security graphing including some example damage scenarios, security objectives and threats looks as follows.
Merged Attack Tree
Merged System Model
Summary
The proposed workflow works flawlessly if we start from a common TARA and take care of potential naming conflicts either beforehand or during the merge process. Starting from a common project is important since this avoids conflicts on lower abstraction levels. (e.g., unique IDs that are used internally)
Either way, it is suggested that the branches are as short-lived as possible and get synchronized from time to time.
itemis SECURE is the perfect solution for analyzing and managing the risks of networked systems. itemis SECURE is an immediately deployable, efficient and accessible tool that can be customized and integrated. With the tool, you are also prepared for the future for upcoming changes and new standards!
Standardization
Supporting security standards including ISO 27005, ISO/SAE 21434 and IEC 62443
Customization
Adaptable for custom assessment and development processes (including TARA)
Modeling
Guided modeling of system and security properties
Reporting
Automated generation of audit compliant documents
Lifecycle Support
Simple update and versioning of analysis iterations
Right now, we don’t explicitly support ports. In many cases, you may create a channel instead of a port. This requires knowing the component at the other end already, yet emphasizes that the security analysis is performed on a concrete system with all the abstract holes being filled with concrete conversation partners.
- Create the data
- Use the Security Goal Assessments to create Security Goals for each data
- Use the Suggestion Overview to make the child data depend on their containing data
You can specify stakeholders, but the corresponding chunk is not added to the project by default. You have to add it with a right-click on the root node of your analysis (or a folder) in the project explorer.
Specify Stakeholders
Assumptions allow you to document constraints like “the backend is secure”. Assumptions can also affect the risk calculation: for example, you can specify that the attack feasibility is always “very low” and connect that assumption with threats that you have identified for the backend.
Asset identification is related to a special entity called “security goals”. After you have modeled your system (or a part of it), you have to decide for each system element, if breaking one or multiple security attributes (e.g. Confidentiality, Integrity, Availability or Authenticity) of the system element might cause damage. If this is the case, you have to create corresponding security goals. The system element becomes an asset if at least one security goal is defined for it. Note: we are going to implement so-called “terminology profiles” that will introduce ISO 21434 terms so that several things will be easier to map.
We don’t allow that Threats act on Data element directly, because we consider them “intangible”. Data can only be threatened during transmission or when it is physically stored somewhere. Thus, Threats may only act on a Component, or Data Flow (or Channel in the future). It then automatically affects the transferred Data. However, this has to be modeled explicitly. The tool helps you to establish the appropriate “threatened-by” relation between Security Goals and Threats if you want to have it. There is one Chunk called Suggestion Overview that evaluates the modeled structure of the System to generate a list of possible relations that you can accept individually or altogether.
We have observed two different ways of thinking about Risks: if damage is in the focus, people prefer to define Risks based on Security Goals, if attack paths and likelihood is in the focus, people prefer Threats. We think that it makes sense to have one Risk for several related elements so that reports become more clear. It depends on your use-case how you define a Risk.
Yes, you can. The mechanism is similar to how you semi-automate the creation of Security Goals and Threats: create or go to an existing Model Assessment chunk and select the corresponding “risk assessment query”:
Risk query
The Risk query was made for the “one-Risk-per-Threat” way of thinking (see above). Note that you can always implement custom logic to automate something with a User Script.
You can do this in the Assessment Model. For example, by default the propagated damage is decreased if it is distributed to multiple independent elements. If you would like to disable damage distribution, you will have to override the default damage adjustment. This can be done in the Assessment Model. Go to “damage aggregators” and focus the damage aggregator of your choice (by default there is only one called “MAX”). In the inspector use Ctrl+Space below “Adjustment of Propagated Damage Potential” and select “AdustDPFunction”. This will show you a method stub where you can implement your own adjustment. For the example case this is simple; you just have to return the unmodified DP. To do so, type “return damagePotential.getDPInfo()”:
Inspector
If an error is displayed you will have to import a dependency. Place the cursor on the marked method and press ALT+Enter and select “import com.moraad.core.runtime”:
Inspector
Then press “Apply” in the main editor (changes are also applied when you leave the editor, e.g. focus another element in the Assessment Model).
If you make a git commit, and make changes to your model, then you’ll be able to see the changes since that commit in the commit view. You can open the commit view by pressing CTRL+V and then 1.
If you commit again and would now like to see the changes from one commit to the other, you can do that from the VCS log view. You can open the VCS log by clicking on the „9: Version Control“ Tab on the bottom left of your screen (Red 1 in the Screenshot) , and then on the tab „Log“ (2 in the Screenshot); or by pressing CTRL+Shift+A, typing „VCS Log“ and hitting return.
For small diffs, you may use the 
Icon to toggle the inline diff viewer at the right hand side (3b in the Screenshot). Make sure that „MPS model viewer“ is selected there (4 in the Screenshot).
For larger diffs, you may click on 
or press CTRL+D to open this diff viewer in a separate window (3a in the screenshot).
In this view, you may also diff between two versions that span a longer time. Simply click on the first commit, hold CTRL, click on the second commit, release CTRL and then right-click and „Compare Versions“ will show the models that differ between the two. Double clicking an entry there will show the diff for that model.
That’s a great illustration for why it is a good idea to have separate commits for every task or session, so that your history becomes easy to inspect.
Separate commits
You can add more system elements in future iterations. Because the tool is model-based, it is mostly easy to find the places that you have to adapt / update after a change.
1. you can split the Risks Chunk into several chunks „Privacy Risks“, „Safety Risks“ etc.
2. Then you can select the desired chunk in the result report chunk (of which you can have multiples by the way, so e.g. one for the safety-people, and another one for the privacy people).
3. The generated html will contain as specified: the Bubble chart for the whole model, but the Risk and scenario tables will only be filled for the risks of the selected chunk.
There is a problem with the Risk Table when available Damage Potentials (DP) or Attack Effort (AE) values are altered. To fix this you have to remove the table and insert it again. Place the cursor somewhere in the table and press Ctrl+Up until it is select completely. Then press Delete to remove it. Press Return or Ctrl+Space to insert a blank table.
Yes, we know about several usability problems. We continuously improve usability with every version.
Each selected element is not only text, but actually part of a tree. The tree can only be assembled following certain rules, thus pasting one part of the tree might just not be allowed at another place. Furthermore, the context of the original tree might not be available at the desired destination. Thumb rule: you shouldn’t use copy&paste except for pure text copies or for elements within one list.
You can undo an action with the shortcut Ctrl+Z, or using the toolbar. itemis SECURE might interpret some of your actions as a sequence of subactions. In this case you might have to use Ctrl+Z multiple times. If you want to redo an action previously undone, you can use Ctrl+Shift+Z.
Because the context actions are context sensitive not all actions are displayed all the time. Please make sure that you have selected the correct element or focused the correct tool window.
For displaying further information on a modeled element you have to select the element to be inspected with the cursor. Usually the name of the element should be selected.
Please make sure that the context actions window is not closed. Clicking on the tab header will open or hide the window.
Merge conflict
Models with conflicts will be displayed red. You can select the model and press “Merge…” to solve the conflicts. This will show you a screen like this:
Merge revision
In this case there is only one change. You can solve this conflict by choosing the left version (press the “>>” icon next to the “x”) or the right version (press the “<<” icon). You can also solve the conflict by typing in the editor in the middle. Press the “x” icon to reject a change.
If there are additional changes without conflicts in the model, you should rely on the tool to merge them automatically first. To do so, click the following icon in the toolbar:
Automatically merge
Note that this button exists twice in the UI: the context of the upper button is the whole model, while the other button works on the root node selected above.
After updating itemis SECURE the internal structures used to store the data might have changed. You have to migrate your project before you can go on. You can safely use the wizard which guides you through the migration process.
We will basically create a project without assessment model composition, include our prepared composition manually to the project paths and then make our Analysis-model depend on its models.
1. Create a security analysis project without any Assessment Model Composition. We will add the composition later on by hand.
Select origin of Assessment Model and Catalog
2. As we can see, the created project contains only the analysis template in the model „Project12“ and no composition. I right-click on the root node now and click on „Project Paths“.
Open Project Paths to add the assessment model composition
3. This view lists only that one solution. I click on the + and select the MyComposition.msd in the folder of my composition so that the composition solution is listed here as well. I click apply.
Project Paths are .msd files that contain one or more solutions, such as analyses or assessment models
To add a solution, select the .msd file in its folder
4. My project view lists both solutions now. What we configured so far is just about the solutions that are listed in the left pane. Let’s now configure the Project12 solution to use our Composition solution. For that, I right-click on the Project12 solution and select „Model Properties“:
Open the model properties to make this solution model depend on the assessment model and catalog model
5. I see that there are no dependencies yet. The solution model should depend on the AssessmentModel and the Catalog though. Let’s click on the plus to start adding them
The solution model so far does not import any other models
6. The „Choose Model“ window opened in front of it. You may need to resize it – sometimes the parts on the right side are important to see. In this case, we want to add the two upper models. For that, I click on AssessmentModel, hold shift and click on Catalog to select both entries and click on „Ok“.
A list of models that are in this project. The right hand side shows the name of their containing solution
7. They are listed now in the model properties. Note that when adding them for the first time, they may appear in red font. That’s okay for now. I hit „Ok“ anyway to close the model properties.
The list of imported models
8. That should be all. When creating a threat now and looking at its instantiates-menu, I can see the threat classes that come from the imported catalog as intended.
The tool now includes the imported models in all of its tooling, such as instantiating a threat class from the catalog
9. The VCS integration supports having multiple VCS roots and also supports using svn externals / git submodules (as far as I know). You can add the respective repositories by opening the project preferences and adding the VCS root of the composition:
The settings allow to configure version control for multiple folders
The integration (in my case git) will then show both repositories in all the views. Peculiarly, if I make a change in both repositories and try to commit them together, I will create a commit in each repository with a shared commit message.
The vcs tooling allows to choose in which repository to change the branch
Committing changes in both repositories at the same time will in fact perform two commits with the same description