The Security Analyst is the perfect solution for analyzing and managing the risks of networked systems. The Security Analyst 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!
Supporting security standards including ISO 27005, ISO/SAE 21434 and IEC 62443
Adaptable for custom assessment and development processes (including TARA)
Guided modeling of system and security properties
Automated generation of audit compliant documents
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.
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”:
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()”:
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”:
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.
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. Security Analyst 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.
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:
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:
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 Security Analyst 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.
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“.
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.
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“:
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
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“.
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.
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.
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 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.