Erhebung von MisUse Cases

Ziel:

Das Ziel von MisUse Cases ist die Definition von Anwendungsfällen, die eine missbräuchliche Verwendung des Systems enthalten und deren Auftreten zu einem Nachteil für einen Stakeholder oder ein Unternehmen führen kann. Auf diese Weise können potentielle Sicherheitsrisiken früh erkannt und in der Entwicklung berücksichtigt werden.

Beschreibung:

Bei der Definition des Systemverhaltens ist es nicht nur wichtig, das korrekte Verhalten zu spezifizieren, sondern auch, wie das System reagieren soll, wenn Umgebung oder Benutzer nicht wie vorgesehen agieren, beziehungsweise ein bewusster Missbrauch vorliegt.

Eine weit verbreitete Technik zur Beschreibung von funktionalen Systemanforderungen ist die Beschreibung mit Use Cases (Anwendungsfälle). Die hier beschriebene Erhebung von MisUse Cases (Missbrauch-Anwendungsfälle), ist eine Methode um Fehlerverhalten zu erheben und spezifizieren.

Grundlegende Konzepte

Use Cases

Ein Use Case spezifiziert normalerweise das typische oder normale Ablaufen einer Benutzeraufgabe. Alternativen oder Ausnahmen in Bezug auf Mißbrauch sind nur eingeschränkt möglich zu erfassen.

MisUse Cases

Ein MisUse Case ist entweder ein Use Case, in dem der Aktor eine böse Absicht hat oder die Umgebung sich nicht wie erwartet verhält. So gilt es beispielsweise hinsichtlich der Systemsicherheit (Security) böse Aktoren, die unerlaubt in das System eindringen wollen, zu berücksichtigen. Ein Beispiel für unerwartetes Verhalten im Bereich „Safety“ wäre das Verhalten des ABS-Systems, wenn ein Reifen geplatzt ist.

MisUse Cases werden hauptsächlich verwendet um die Umgebung oder das Verhalten von (bösen) Aktoren zu analysieren, um hieraus neue Anforderungen (Use Cases) zu identifizieren. Es ist nicht immer notwendig, die MisUse Cases im Anforderungsdokument detailliert zu spezifizieren. Allerdings ist das komplette Weglassen ebenfalls nicht empfehlenswert, da sie eine wichtige Quelle für Entscheidungen sind (so genannte „Rationales“).

(Es wird nicht vorausgesetzt, dass funktionale Anforderung bereits erfasst sind oder dass sie mit Use Cases erfassen werden. Dennoch sind MisUse Cases normalerweise eine Ergänzung zu existierenden Use Cases.richtig?)

Optionen und Kriterien

Für MisUse Cases gelten dieselben Qualitätskriterien wie für normale Use Cases.

Die Methode ergänzt die normalen Anforderungsprozesse. Der Einsatz von MisUse Cases ist deshalb wie üblich durch Priorisierung und Kosten-Nutzungs-Analyse getrieben.

Vorgehen

Vorbereitung

Um MisUse Cases gezielt einsetzen zu können, müssen zuerst die kritische Ressourcen oder Aktivitäten identifiziert werden. Eine kritische Ressource ist zum Beispiel die Zugangsinformation zu einem Server, persönliche Daten oder ein Auto. Eine kritische Aktivität ist zum Beispiel „ Bremsen“ oder „im Dunkeln fahren“. Diese Art von Information ist teilweise bereits im existierenden Anforderungsdokument zu finden, aber auch oftmals in anderer Unternehmensdokumentation oder kann mit Hilfe von Experten ermittelt werden.

Erhebung und Spezifikation

Identifizierung von Aktoren/Gefahrenquellen

Der erste Schritt zur Erhebung und Spezifikation von MisUse Cases ist das Identifizieren von Gefahrenquellen oder der bedrohenden Aktoren. Beim Autofahren ist zum Beispiel das Wetter eine Gefahr und ein bedrohender Aktor ein Autodieb.  Die Analyse bezieht sich auf die kritischen Ressourcen, die in den Vorbereitungsschritten identifiziert wurden.

Um die Analyse konform zu der üblichen Use Case-Analyse zu halten, ist daher beispielsweise auch das Wetter als Aktor zu modellieren.

Erhebung von MisUse Cases

Basierend auf den in Schritt 1 identifizierten Aktoren und existierenden Use Cases sind die einzelnen MisUse Cases zu identifizieren. Ein MisUse Case ist ein spezieller Use Case eines Aktors, der die Ausführung dieses Use Case behindert (siehe Abbildung 1).

[Abbildung 1 MisUse Case Beispiel]

In Abbildung 1 ist also „Dieb“ der bedrohende Aktor und „Auto klauen“ der MisUse Case. Dieser MisUse Case bedroht den Use Case „Auto fahren“.

Konsistenzprüfung und Ergänzung von existierenden Use Cases

Um den Missbrauch zu vermeiden, sind neue Use Cases einzuführen. Um beispielsweise den Autodieb zu vermeiden, kann man das Auto abschließen (siehe Abbildung 2).

[Abbildung 2 Vermeidung von Missbrauch]

Der neue Use Case „Auto abschließen“ ist die neue Anforderung an das System. Wie vorher genannt, ist es nicht immer notwendig den MisUse Case (in der Abbildung „Auto klauen“) im Detail zu spezifizieren. Dennoch sind die neuen Use Cases wie alle andere Use Cases zu spezifizieren.

Sobald neue Use Cases (MisUse Cases oder normale Use Cases) identifiziert und spezifiziert sind, besteht die Möglichkeit, daß bereits existierende Use Cases überarbeitet werden müssen.

Deshalb ist es notwendig die Konsistenz des neuen und der bereits existierenden Use Cases zu überprüfen.

Verfeinerung und Iteration

Der Anforderungsprozess ist immer iterativ, das Vorgehen bei MisUse Cases auch. Die neuen Use Cases müssen vielleicht verfeinert werden und führen zu neue Use cases in anderen Teilen des Systems. Zum Beispiel, kann „der Dieb“ neue MisUse Cases ergreifen, um die neuen Use Cases weiter zu bedrohen (siehe Abbildung 3).

[Abbildung 3 Vollständige Beispiel]

Beide, Use Cases und MisUse Cases, können und sollen verfeinert werden, um das vollständige Verhalten zu erfassen.

Qualitäts-Überprüfung

Die qualitätsüberprüfenden Maßnahmen sind für MisUse Cases dieselben wie für Use Cases auch, das heißt, Reviews, Simulierung und Prototypen. Zu überlegen ist aber, wer in den Qualitätsprozessen beteiligt ist. Zum Beispiel ist es nicht möglich, die bösen Aktoren zu involvieren. Stattdessen müsste man Security-Experten einbinden. Bei den im Beispiel angeführten wetterabhängigen MisUse Cases bräuchte man Experten, wie man mit Umweltbedingungen am besten umgeht.

Diese Technik erfüllt folgende Praktiken:

Funktionale Anforderungen erheben
Nichtfunktionale Anforderungen erheben

Literaturverweis:

Eliciting security requirements with misuse cases
Misuse cases: use cases with hostile intent