Berathek Methode

Anwendungsfälle konzentrieren sich naturgemäß auf das, was das System tun sollte. Aber auch das Verhalten, das vermieden werden sollte, ist ein Verhalten, das durch Anwendungsfälle untersucht werden kann. Ein solcher Missbrauchsfall ist somit das Gegenteil eines normalen Anwendungsfalls. Der Missbrauchsfall beschreibt Funktionen des Systems, die gerade nicht zugelassen sein sollten. Darin wird eine abgeschlossene Folge von Aktionen beschrieben, die zu Verlusten für das Unternehmen oder einen bestimmten Interessenvertreter führt. Ausgeführt wird der Missbrauchsfall durch einen Misactor. Auch er ist das Gegenteil eines normalen "Akteurs" eines Anwendungsfalles. Er ist jemand, der - absichtlich oder unabsichtlich - Missbrauchsfälle einleitet und den das System dabei nicht unterstützen sollte. Mit dieser Herangehensweise lassen sich nicht funktionale Anforderungen für ein System herleiten.

Mit Missbrauchsfällen kann der Fokus früh auf Sicherheit gelegt werden. Sicherheitsfragen werden oft als Probleme auf Design-Level angesehen. Endbenutzer und das Management der beschaffenden Organisation sind aber möglicherweise nicht in der Lage, die technischen Details von Sicherheitsbedrohungen und Gegenmaßnahmen zu diskutieren. Aber sie werden Sicherheitsbedenken haben. Sehen Sie, wie diese von Missbrauchsfällen erfasst werden, werden sie mehr Vertrauen in das System haben. Bei Sicherheit geht es sowohl um organisatorische Abläufe, als auch um die technische Sicherheit. Missbrauchsfälle können dazu beitragen, die Diskussion über die Sicherheit weiter zu vertiefen und dies in einem Format, das die Endbenutzer verstehen und so daraus lernen können. Wenn Gegenmaßnahmen als erstklassige Anforderungen beschrieben werden, ist es einfach, sie zu realisieren. Missbrauchsfälle zeigen, warum eine bestimmte Verteidigung im System eingeführt wurde, was die spätere Wartung und Neugestaltung angesichts sich ändernder Bedrohungen erleichtern wird.

Ein Hauptproblem bei der Verwaltung von nicht funktionalen Anforderungen ist, wie man das Anforderungsdokument organisiert und funktionale und zusätzliche nicht funktionale Anforderungen miteinander in Beziehung setzt. Missbrauchsfälle lösen dieses Problem für eine große Klasse von nicht funktionalen Anforderungen. Sicherheitsanforderungen sind nur ein Beispiel. Nicht funktionale Anforderungen an Sicherheit, Verfügbarkeit und Robustheit geben an, was nicht passieren darf und fallen daher auch in die Klasse der Missbrauchsfälle. Damit können die funktionalen und eine große Klasse von nicht funktionalen Anforderungen gleich hergeleitet und modelliert werden. Aufgrund der Ähnlichkeit von Missbrauchsfällen und Anwendungsfällen können diese verglichen werden, um zu untersuchen, ob ein Anwendungsfall unbedingt notwendig ist. Vielleicht kann er eingespart werden und damit entfällt auch ein Missbrauchsfall.

Werden Missbrauchsfälle zusammen in SysML / UML UseCase Diagrammen dargestellt, so kann es verschiedene Zusammenhänge zwischen ihnen geben. Es kann eine "include"- oder "extends"-Beziehung von einem Missbrauchsfall zu einem gewöhnlichen Anwendungsfall geben. In diesem Fall wird eine normale Systemfunktion für den Missbrauch verwendet. Es gibt noch zwei weitere Beziehungen, "prevent" und "detect", die von Anwendungsfällen zu Missbrauchsfällen gehen. Damit werden Funktionen angegeben, die Missbrauch verhindern oder aufdecken. Aufgrund der wichtigen Zusammenhänge zwischen Nutzung und Missbrauch ist es sinnvoll, sie im gleichen Diagramm darzustellen. Dann ist aber ein deutlicher Unterschied in der Darstellung erforderlich, um Verwirrung zu vermeiden, z.B. können die Elemente invers dargestellt werden.

Anwendungskriterien

Die Methode bringt besondere Vorteile, wenn

Sicherheitslücken im System frühzeitig entdeckt werden sollen
ein Use-Case Modell für das System vorhanden ist
IT-Security Strategien untersucht werden sollen.

Die Methode kann negative Wirkungen haben, wenn

IT-Security keine Rolle spielt
Missbrauch toleriert werden kann
keine Modellierung gewünscht ist.

Voraussetzungen

Die normalen Anwendungsfälle des Systems sind bekannt und dokumentiert. Mögliche Missbrauchsfälle sind untersucht worden. Zur Dokumentation kann ein SysML- / UML-Tool, aber auch eine einfache Textdatei verwendet werden.

Durchführung

Benenne den Missbrauchsfall. Hier sollte ein aktives Verb mit einem Nomen verwendet werden. Viele Angriffsszenarien haben eine Namen, der in Klammern angefügt werden kann. Z.B. “Überfluten mit e-mails (DoS)”
Benenne den Misactor. Dieser kann durch eine Persona beschrieben sein. Im allgemeinen ist es jedoch schwierig eine charakterisierung des Misactors zu erstellen.
Ordne dem Missbrauchsfall einen Misactor zu. Dies entspricht dem Actor für Anwendungsfälle.
Beschreibe den Missbrauchsfall.

Tipp

Es können folgende Kategorien verwendet werden:
- Primary Actor: Im Missbrauchsfall ist dies der Misactor.
- Trigger: Die Bedingung, die den Missbrauchsfall auslöst. Wenn dies nicht angegeben wird, so kann die Gefahr dauerhaft bestehen.
- Precondition: Diese Bedingung beschreibt die Zustände des Systems, die den Missbrauchsfall ermöglicht.
- Worst case threat: Beschreibt das schlimmste Ergebnis, wenn der Missbrauch erfolgreich ist.
- Main Success Scenario: Beschreibung des normalen Weges des Misactors mit Eingriffen im System, der mit einem Erfolg für den Misactor und einem Fehler für das System endet.
- Extensions: Weitere Möglichkeiten, den Missbrauch zu begehen. Dies sind auch mögliche Wege, die der Misactor nutzt, um zum Beispiel Hindernisse oder Capture-Points zu umgehen.
- Captur Points: Möglichkeiten, wie der Missbrauch verhindert und in bestimmten Schritten erkannt werden kann.
Beschreibe ergänzende Informationen.

Tipp

Es können folgende Kategorien verwendet werden:
Es können folgende Kategorien verwendet werden:
- Prevention guarantee: Beschreibt das gewünschte Ergebnis der Prävention gegen den Missbrauch.
- Detection guarantee: Beschreibt die gewünschten Entdeckungswahrscheinlichkeit.
- Related business rules: Es ist nützlich genau zu verstehen, welche Geschäftsregeln in jedem Missbrauchsfall verletzt werden. Dadurch lassen sich möglicherweise Situationen entdecken, in denen die Geschäftsregeln selbst zu schwach formuliert sind und damit den Missbrauch fördern.
Identifiziere die Anwendungsfälle oder andere Missbrauchsfälle, die vom Missbrauchsfall mit verwendet werden. Diese werden in der Beschreibung des Missbrauchsfalls gekennzeichnet oder können über eine “include”oder “extend” Beziehung an den Missbrauchsfall gebunden werden.
Identifiziere die Anwendungsfälle, die den Missbrauchsfall entdecken. Diese werden in der Beschreibung des Missbrauchsfalls gekennzeichnet oder können über eine “detect” Beziehung an den Missbrauchsfall gebunden werden. Sind diese noch nicht beschrieben, so müssen sie als normale Anwendungsfälle beschrieben werden.
Identifiziere die Anwendungsfälle, die den Missbrauchsfall verhindern. Diese werden in der Beschreibung des Missbrauchsfalls gekennzeichnet oder können über eine “protect” Beziehung an den Missbrauchsfall gebunden werden. Sind diese noch nicht beschrieben, so müssen sie als normale Anwendungsfälle beschrieben werden.
Diskutiere die Missbrauchsfälle mit Experten für IT-Security oder anderer Sicherheitsfelder. Es ist wichtig die Gegenmaßnahmen auf ihre Wirksamkeit zu untersuchen.

Beschreibung des Produktes

Ein UseCase - Misuse kann ein einfaches Textdokument sein, oder in einem SysML / UML-Tool erstellt sein. Aus den UseCase - Misuse können nicht funktionale Anforderungen hergeleitet werden oder konkrete Abwehrreaktionen bestimmt werden.