Eine kurze Zusammenfassung der wichtigsten Änderungen. Für weitere Details, siehe Changelog.

Protection Goals – Schutzziele

Es wurde ein neues Konzept namens “Protection Goals” hinzugefügt. Diese sind eine Vereinfachung der bereits existierenden Bedrohungskategorien. Standardmäßig werden sechs Schutzziele, darunter z. B. Vertraulichkeit und Integrität, erstellt. Sie können Angriffsvektoren, Bedrodungskategorien und Regeln in der Konfiguration hinzugefügt werden. Projektseitig können ebenso die Schutziele von Angriffsszenarien festgelegt werden. Falls ein Szenario automatisch generiert ist, werden die Schutzziele von der hinterlegten Regel übernommen. Ebenso können bei Systembedrohungen und Assets die betroffenen Schutzziele und deren Auswirkungen (Impact) festgelegt werden.

Angriffsszenarien bringen diese Informationen nun zusammen. Angenommen, ein Angriff betrifft einen Secret Key – das Asset in diesem Fall. Dieser Secret Key wurde hinsichtlich Vertraulichkeit mit Kritisch bewertet, hinsichtlich Verfügbarkeit nur Mittel. Ein Angriffsvektor, der Informationen offenlegt und somit die Vertraulichkeit betrifft, würde dazu führen, dass in der Risikobewertung automatisch der Impact auf Kritisch gesetzt wird. Bei einem anderen Vektor, der beispielsweise “nur” alle Daten löscht, würde der Impact automatisch auf Medium gesetzt werden, da nur die Verfügbarkeit betroffen ist.

Verbesserungen bei der Risikobewertung

Neben den zuvor angesprochenen Automatisierungen wurden noch weitere Aspekte verbessert. In der Konfiguration kann das Risikoakzeptanzlevel festgelegt werden. Falls man alle Risiken, die Mittel oder geringer sind, akzeptieren möchte, muss dafür “Mittel” als akzeptiertes Level eingestellt werden. Sollte bei der Bewertung eines Angriffsszenarios “Mittel” oder “Gering” resultieren, würde die Risikostrategie automatisch auf “Akzeptieren” gestellt werden. Es ist somit ersichtlich,dass die Definition von Gegenmaßnahmen nicht zwingend nötig ist.

Für die Bewertung des Restrisikos wurde ein neuer Wert “Vermieden/Avoided” hinzugefügt. Dazu kann man in der Konfiguration jetzt unterscheiden, ob sich Werte auf die Risiko- oder Restrisikobewertung beziehen. Der neue Zustand kann nützlich sein, wenn z. B. ein Feature entfernt wurde und gar nicht mehr ausgenutzt werden kann.

Traceability

Es ist nun möglich, bei zahlenreichen Objekten Hyperlinks einzufügen. Somit kann eine Verknüpfung zu Bug Tracking und Requirement Tools hergestellt werden. Der umgekehrte Weg, von externem Tool zu TTModeler, ist derzeit in der Entwurfsphase.

Unterstützung von MITRE EMB3D™

Es ist nun möglich, bei Angriffsvektoren auf Threats aus der MITRE EMB3D™-Datenbank zu verlinken. Der Eintrag ist bei Angriffsszenarien sichtbar und wird ebenso im Bericht angegeben.

Projekt-Metadaten

Metadaten wie Versionverlauf und Teilnehmer können jetzt ausführlicher dokumentiert werden.

Verbesserungen bei Checklisten

Bei Anforderungen von Checklisten kann festgelegt werden, ob eine Anforderung für Hardware (Gerät) bzw. Software (App) relevant ist. Somit lassen sich bestimmte Anforderungen auf nicht relevant setzen.

Anforderungen können nun zu Regeln, Angriffsvektoren und Controls verlinkt werden. Somit wird ersichtlich, welche Angriffsszenarien für ein Requirement relevant sind.