Misuse Case. Gefahren für das System ermitteln.
Wozu braucht man Misuse Cases, welche Vorteile bieten sie und wie werden sie erstellt?
Misuse Cases sind "umgedrehte" Use Cases, mit denen Sie Funktionen erfassen, die ein System nicht zulassen sollte. Dadurch finden Sie Sicherheitsanforderungen, die die Qualität des Systems erhöhen.
Ein Misuse Case kann einen Use Case gefährden (attack). Andersherum ist ein Anwendungsfall im Stande, Misuse Cases abzuschwächen bzw. zu verhindern (prevent). Daher gibt es zwei neue Beziehungsarten im Use Case-Diagramm.
Ein Misuse Case ist immer mit einem MisActor verbunden: Eine Person, die bewusst oder unbewusst Schaden am System verursacht.
Was muss die Software können? Welche Funktionen soll sie bereitstellen? Typische Fragen, die Sie im Requirements Engineering zu klären versuchen. Sie erstellen dafür Anwendungsfälle und nutzen in der Regel Use Case-Diagramme zur Visualisierung. Das funktioniert gut mit funktionalen Anforderungen. Wie gehen Sie aber mit Zielen und Wünschen der Stakeholder um, die nicht dazu gehören? “Das System muss absolut sicher sein!” hören Sie zum Beispiel Ihren Kunden sagen. Gut, denken Sie. Er stellt eine Sicherheitsanforderung, die die Qualität des Systems erhöhen soll. Aber die ist ziemlich breit gefasst und schwer nachprüfbar. Können Sie daraus einen Use Case formulieren? Leider lautet die Antwort dafür: Nein, Anwendungsfälle eignen sich nur für funktionale Anforderungen – also Beschreibungen implementierbarer Funktionalitäten. Um auch Qualitätsanforderungen (nicht-funktionale Anforderungen) ableiten zu können, müssen Sie genau anders herum denken: Was soll das System NICHT können? Oder in diesem Fall: Was darf das System nicht zulassen, damit es sicher ist? Und dann kommen die sogenannten Misuse Cases ins Spiel.
So arbeiten Sie mit Misuse Cases in der Praxis
Erfahren Sie hier mehr zu Requirements Modelling
mit objectiF RPM oder objectiF RM »
Was ist ein Misuse Case?
Misuse Cases wurden erstmals im Jahre 2001 durch Guttorm Sindre und Andreas Opdahl, zwei norwegischen Professoren im Bereich Entwicklung von Informationssystemen, für Anforderungen im Bereich der System-Sicherheit beschrieben. Sie ergänzen den bekannten Anforderungsprozess mit Use Cases und Use Case-Diagrammen. Einen Misuse Case können Sie sich als „umgedrehten“ Use Case vorstellen – also eine Funktion, die in einem System nicht umsetzbar sein sollte. Er bietet Ihnen einen weiteren Blickwinkel auf das System, um Sicherheitsanforderungen zu ermitteln. Vor allem diese Anforderungen sind laut des Kano-Modells für die Zufriedenheit Ihrer Stakeholder von immenser Bedeutung.
Vorteile von Misuse Cases
Qualität wird erhöht, da nicht-funktionale Anforderungen Beachtung finden
Entwickler und Kunden können das System besser verstehen
Modell ist leicht verständlich und einfach anwendbar
Maßnahmen sind sofort sichtbar, da Gefahr und Gegenmaßnahme visualisiert werden
Gefahrenanalyse ist frühzeitig möglich
Gefahren können kundenspezifisch erkannt werden
Rückverfolgbarkeit ist sichergestellt, wenn Funktionalitäten zur Erhöhung der Sicherheit überarbeitet werden müssen
Definition des Misuse Case – kurz und knapp:
Ein Misuse Case beschreibt, welche Funktion ein System nicht zulassen darf.
Sie brauchen ihn, um nicht-funktionale Anforderungen wie Sicherheitsanforderungen zu ermitteln.
Ein Misuse Case ist immer mit einem MisActor verbunden.
Wie erstellen Sie Misuse Cases?
Misuse Cases lassen sich wie auch Use Cases mithilfe eine Vorlage rein textuell in einer Use Case-Spezifikation erfassen. Notwendige Informationen sollten mindestens der Name und die Beschreibung sein. Sie können auch die Handlungsabfolge – den sogenannten Flow – angeben, der zum Erfolg des Misuse Cases und damit dem Scheitern des Systems führt. Außerdem lassen sich die umgedrehten Anwendungsfälle ebenfalls in einem Use Case-Diagramm darstellen. Wie bei Use Cases empfiehlt es sich, beide Methoden in Kombination zu verwenden.
Die Erstellung von Misuse Cases ist eng mit der Erstellung von Use Cases und damit dem Requirements Engineering verbunden. Wenn Sie ein Use Case Diagramm modellieren, dann binden Sie am besten auch gleich die Misuse Cases ein. Auf diese Weise erhalten Sie einen Überblick über die Funktionalitäten, aber auch die Gefahren für das System. Die Erstellung des Diagramms mit den Use Cases, Misuse Cases und ihren Beziehungen zueinander erfolgt in einem iterativen Prozess.
Lesen Sie hier, um mehr über Use Case-Diagramme zu erfahren »
Der Erstellungsprozess setzt sich aus folgenden Schritten zusammen:
- Ermitteln Sie die Funktionalität des Systems und erstellen Sie Use Cases
- Identifizieren Sie Gefahren oder bedrohende Aktoren für das System und erstellen Sie Misuse Cases bzw. MisActors
- Verbinden Sie Misuse Cases mit denjenigen Use Cases, die sie gefährden
- Ermitteln Sie Funktionalitäten, die Misuse Cases verhindern können, und verbinden Sie die Anwendungsfälle miteinander
- Wiederholen Sie die Schritte 1 – 4 und verfeinern Sie Anwendungsfälle und Misuse Cases
Wie auch Use Cases können Sie Misuse Cases durch Testfälle prüfen, sodass Sie mit Modellierung des Use Case-Diagramms gleichzeitig Testfälle anlegen können. Allerdings prüfen Sie Misuse Cases dadurch, ob eine unerwünschte Funktionalität erfolgreich verhindert werden kann.
Übrigens ist es auch möglich, Misuse Cases abstrakter zu betrachten. Zum Beispiel kann ein Akteur zum MisActor werden, wenn er einer schlechten Benutzeroberfläche ausgesetzt ist:
Misuse Case im Vergleich zum Use Case
Eigenschaften eines Use Case
Funktionale Anforderungen ableitbar
Schafft Wert für die Organisation bzw. Stakeholder
Lässt sich rein textuell und/oder in einem Use Case-Diagramm erfassen
Mit einem Akteur verbunden
Mit Use Cases durch include-Beziehung verbunden
Mit Use Cases durch extend-Beziehung verbunden
Prüfbar durch Testfälle (Funktionalität erfüllt)
Eigenschaften eines Misuse Case
Nicht-funktionale Anforderungen ableitbar (Qualitätsanforderungen)
Verhindert Wertverlust für die Organisation bzw. Stakeholder
Lässt sich rein textuell und/oder in einem Use Case-Diagramm erfassen
Mit einem MisActor verbunden
Mit Use Cases durch attack-Beziehung verbunden
Mit Use Cases durch prevent-Beziehungen verbunden
Prüfbar durch Testfälle (unerwünschte Funktionalität verhindert)
Beziehung zwischen Use Cases und Misuse Cases
Misuse Cases stehen mit Use Cases in Verbindung. Für diese Verbindung stützen Sie sich auf die Enthält- und Erweiterungsbeziehung, die Sie bereits aus dem Use Case-Diagramm kennen. Wie schon erwähnt, kann ein Misuse Case die Funktionalität eines Anwendungsfalls bedrohen. Für solch eine Beziehung wird dann die include-Beziehung abgewandelt und mit einem Signalwort wie threatens oder attacks versehen.
Wenn ein Use Case einen Misuse Case verhindern bzw. bis zu einem gewissen Grad entschärfen kann, dann verbindet man diese Anwendungsfälle mit einer extend-Beziehung und dem Signalwort mitigates oder prevents.
Nutzen Sie ein Tool für Ihre Misuse Cases und MisActors.
Mehr zu Requirements Engineering mit objectiF RPM und objectiF RM »
Beispiel von Misuse Cases in einem Use Case-Diagramm
Ein Autobesitzer möchte sein Fahrzeug sichern, indem er es durch die schlüssellose Keyless Go-Technik verriegelt. Ein Dieb hingegen möchte das Fahrzeug stehlen – er gefährdet das System und ist deshalb der MisActor. Dies gelingt dem Dieb, sofern er das Schloss des Fahrzeugs aufbrechen oder das Funksignal des Keyless Go Systems des Fahrzeugs abfangen kann. Diese beiden Tätigkeiten repräsentieren somit Misuse Cases. Weil der Dieb das Funksignal zur Verriegelung des Autos abfangen könnte, gefährdet dieser Misuse Case den Anwendungsfall Fahrzeug schlüssellos verriegeln und eine attack-Beziehung entsteht. Von beiden Anwendungsfällen lässt sich eine Qualtitätsanforderung an das System ableiten: Es muss die Dauer der Signalübetragung erkennen, um einen Eingriff durch einen Dritten identifizieren zu können.
Gleichzeitig kann der Use Case Fahrzeug schlüssellos verriegeln verhindern, dass der Dieb das Fahrzeug stiehlt – eine prevent-Beziehung verbindet die beiden Anwendungsfälle.
Nutzen Sie Misuse Cases für Ihre Projekte
Ein System besteht nicht nur aus Funktionen, die Sie direkt implementieren können. Stattdessen werden Sie auf Anforderungen Ihrer Stakeholder treffen, die Qualitäts- und Leistungsmerkmale wie Performance, Zuverlässigkeit, Skalierbarkeit oder Sicherheit betreffen. Leider lassen sich solche nicht-funktionalen Anforderungen schwer als Use Cases formulieren. Nur mit Misuse Cases können Sie einen Blick auf Ihr System schaffen, der auch Qualitätsmerkmale – vor allem bezüglich der Sicherheit – abdeckt. Und dadurch erst das System richtig entwickeln. Setzen Sie ein Tool ein, das Ihnen eine textuelle Vorlage zur Erstellung von Misuse Cases bietet und mit dem Sie Use Case-Diagramme erzeugen, um Ihre Use Cases, Misuse Cases, Akteure, MisActors und ihre Beziehungen zueinander zu visualisieren.