Release Notes

Open initiative for an exchange format

You might already know our exchange format XSAM. Starting from this, we are just launching an initiative to form an open community which aims at establishing a cross-vendor, cross-tool XML-based format for eXchanging Security Analysis Models. We call it openxsam.io. If you are interested in joining the initiative, please contact us at security-analyst@itemis.de.

 

Additionally, we still have the knowledge base at https://www.security-analyst.org about general security analysis processes and norms.

Important Changes

Damage Transformation

Assumptions may now declare to transform or remove damage more expressively. Given the assumption “The attacker won’t harm himself”, the assumption may now declare to remove all relevant safety damage (S3, S2, and S1, in the screenshot below). It could also declare to transform damage from one scenario to another, such as a failsafe-state would transform a “crash” damage scenario into a “non-operational” damage scenario. Similarly, an assumption may now remove damage scenarios or transform a particular damage level into another.

Damage Mitigation with Controls

So far, a control that was not overcome had the effect to remove all damage. “Removing all damage” effectively required any successful attack to a threat to also break its controls. A control can be broken by investing its own attack efforts or breaking an asset on which the control depends. So far, all controls implicitly had the effect “Remove All Damage”.

Starting from this release, “remove all damage” is only the default effect of a control. Given an insurance, the control can now declare to only reduce the financial damage and leave safety damage as is. To do that, just replace the effect “Remove All Damage” with “F2 -> F0” and this will transform all damage of F2 (“Personal bankruptcy” in ISO21434) downto F0. An attacker is now expected to choose: breaking the control or accepting its effect. If the control has a high attack-feasibility and only reduces the damage a bit, accepting the control’s effect may now yield a higher risk than breaking it.

Note, that the effect of a control and an AND-connected assumption are synonymous. For example, if a threat is mitigated by AND(C.1, A.1), putting a transformation into C.1 or A.1 will have the same calculation result.

Preparing future assistance: Assumption Catalog and Controls act on system elements

In preparation of improving our suggestions, assumptions and control classes may now reference one or more assumption classes, and controls may now declare on which TOEE they act. As part of that, controls now have a derived title which by default bases on their acted-upon system element. We plan to let assistants use this information in future releases.

Changes to our XSAM exchange format

XSAM is our eXchange format for Security Analysis Models:

  • With this release, the whole analysis and assessment model is transferable via XSAM, except for real program code
  • XSAM files may be forced to be imported into the current target model with CTRL+Shift+A, typing “Import XSAM File to Current Model” and hitting Return. This will overwrite their contained model ids if any.
  • We fixed a bug that related to importing references in descriptions and propagation expressions (things like mitigatedBy=”AND(C.1, A.2) ). It now correctly finds elements that have been just created during this import.
  • References support type-wildcards now, such as target=”name/*/Integrity”
  • As announced above, we’ve initiated creating a non-proprietary subset of our format: openxsam.io

Various Fixes and Improvements

  • The ISO21434 example was not only migrated to this version, but also went through some content-wise rework
  • When creating a new chunk, the empty element will ease typing something right away
  • Show notification after exporting to XSAM to allow copying the path or contents of the exported file
  • There is no more exception when trying to visualize an empty sequence
  • Added some missing columns to the table views
  • The project tree on the left hand side doesn’t show “generation required” anymore. We didn’t like that 😉

Migration from earlier Versions

See: Update and Migration Notes

Version Mapping

The following table can be used to determine the Security Analyst version based of the internal plugin version “com.moraad.core” that is stored in the .msd file of every solution:

com.moraad.core version Security Analyst version
37 2.5.1
41 2019.2.0
44 2019.3.0
46 2019.3.1
48 2019.4.0
49 2019.4.1
54 2020.2.1
55 2020.1.1
58 2020.2.0
59 2020.2.1
61 20.3