Bedrohungsanalyse – Threat Analysis

Definition

Die Voraussetzung für die Analyse von Bedrohungen ist ein Verständnis für die allgemeine Definition von Risiko. Dieses Risiko ist die Wahrscheinlichkeit, dass ein Angreifer eine Sicherheitslücke ausnutzen wird, um die Anwendung anzugreifen. Aus der Sicht des Risikomanagements ist Bedrohungsmodellierung der systematische und strategische Ansatz zur Identifizierung der Risiken, sowie das Aufzeigen von Bedrohungen einer Anwendungsumgebung, mit dem Ziel der Risikominimierung und der damit verbundenen Auswirkungen.

Die Bedrohungsanalyse ist die Identifizierung der Gefahren für die Anwendung und beinhaltet die Analyse der einzelnen Aspekte der Anwendung: Funktionalität, Architektur und Design. Ziel ist es, die potenziellen Schwachstellen zu identifizieren und zu klassifizieren, die zu einem Exploit führen könnten.

Vorgehensweise

Im ersten Schritt der Bedrohungsanalyse wurden Datenflüsse, Trust-Boundaries, Prozesskomponenten sowie Entry- und Exit-Points identifiziert.

Datenflüsse zeigen, wie Daten logisch vom einem zum anderen Ende fließen, und ermöglichen die Identifizierung der betroffenen Komponenten durch kritische Punkte, sowie der Steuerung des Ablaufs. Trust-Boundaries („Vertrauens-Grenzen“) zeigen jede Stelle, wo sich das Niveau des Vertrauens ändert. Prozesskomponenten zeigen, wo die Daten verarbeitet werden, wie z.B. vom Web-Server, Anwendungsserver und Datenbankserver.

Entry-Points zeigen, wo Daten in das System eintreten und wo Exit-Points sind, wo die Daten das System wieder verlassen. Ein- und Ausstiegspunkte definieren ein Trust-Boundary.

Eine Auflistung und Kategorisierung von Bedrohungen auf der Grundlage des STRIDE-Modells ist nützlich bei der Identifizierung in Bezug auf die Ziele der Angreifer. Z.B. wenn das Bedrohungsszenario vorsieht die Login-Funktion anzugreifen, würde wahrscheinlich ein Brute-Force Angriff auf das Passwort ausgeführt werden, um die Authentifizierung zu knacken. Oder wenn das Bedrohungsszenario vorsieht, Privilegien eines anderen Benutzers zu erlangen („Elevate Privileges“), würde ein Angreifer wahrscheinlich versuchen, „Forceful Browsing“ durchzuführen.

Es ist wichtig, dass alle möglichen Angriffsvektoren aus Sicht des Angreifers bewertet werden. Aus diesem Grund ist es auch wichtig, Ein- und Ausstiegspunkte zu berücksichtigen, da sie auch die Realisierung von bestimmten Arten von Bedrohungen ermöglichen kann. Die Login-Seite z.B. erlaubt es, Eingabedaten ans System zu senden (Authentifizierungsinformationen). Diese Eingangsdaten, die der Entry-Point akzeptiert, müssen auf potenziell bösartige Absichten validiert werden. Potentiell können sie Schwachstellen ausnutzen – wie SQL-Injection, Cross-Site-Scripting und Buffer-Overflows.

Analyse des Datenflusses

Der Datenfluss, der durch einen Entry-Point geht, sollte dann daraufhin untersucht werden, welche folgenden Komponenten durch ihn bzw. seine durchgereichten Daten bedroht sind. Wenn die folgenden Komponenten als kritisch eingestuft werden können (z.B. wenn sie kritische Daten halten), dann kann dieser Entry-Point auch als kritisch bewertet werden.

In einem End-To-End Datenfluss, könnten zum Beispiel die Eingangsdaten (d.h. Benutzername und Passwort), die unvalidiert von einer Login-Seite weitergeleitet werden, für einen SQL-Injection-Angriff ausgenutzt werden, oder eine Abfrage zum Knacken der Authentifizierung verwendet werden, oder um Daten in der Datenbank zu manipulieren.

Exit-Points könnten als Angriffspunkt des Clients verwendet werden (z.B. XSS-Schwachstellen), oder um Informationen aus dem System an einen Angreifer weiterzuleiten (Information Disclosure). Wenn eine Komponente beispielsweise kritische Daten verwaltet und an einen Exit-Point angeschlossen ist, der keine wirksamen Sicherheitsprüfungen enthält, dann können diese Informationen an eine unautorisierte Person preisgegeben werden.

In vielen Fällen stehen Bedrohungen, die durch einen Exit-Point ausgelöst wurden, in Korrelation zu Bedrohungen eines Entry-Points. Im Beispiel der Login-Seite können Fehlermeldungen, die an den Benutzer über den Exit-Point gehen, nachfolgende Angriffe des Entry-Points erlauben: Account-Harvesting (Meldung „username not found“ liefert Info, ob es einen Benutzernamen gibt oder nicht), oder SQL-Injection (Meldung „SQL exception error“ bei Benutzernamen, die SQL-Befehle enthalten).

Aus der defensiven Perspektive betrachtet erlauben es die so gefundenen Bedrohungen dem Security-Analysten, sich auf spezifische Themen zu fokussieren, damit diese besser gesichert werden können. Noch besser sind diese zu bearbeiten, wenn die Bedrohungen in Kategorien einsortiert werden. Typischerweise wird beim Prozess der Bedrohungsanalyse ein iteratives Vorgehen gewählt, bei dem die zu Beginn der Analyse gefundenen Bedrohungen evaluiert werden.

Bedrohungsbaum – Threat Tree

Im nächsten Schritt werden dann die Bedrohungen bezüglich ihrer Angriffspfade analysiert, sowie bezüglich ihrer Ursachen und der möglichen Eindämmung bzw. Entschärfung. Dazu erstellt man einen Bedrohungsbaum, bei dem die Verwundbarkeiten in Orange dargestellt sind und die Gegenmaßnahmen in Grün (die Ermittlung der Gegenmaßnahmen wird in den folgenden Kapiteln erläutert).

 

Use- und Abuse Cases

Wenn damit die generellen Bedrohungen, Verwundbarkeiten und Angriffsmöglichkeiten ermittelt sind, kann eine tiefere Analyse gemacht werden, um die Use Cases und Abuse Cases zu ermitteln. Abuse Cases sollten identifiziert werden im Rahmen der Aktivitäten des Security Requirement Engineering. Diese Abuse Cases helfen dabei zu illustrieren, wie existierende Schutzmaßnahmen umgangen werden können, oder wo eine Sicherheitslücke existiert.

Ein Use- und Abuse-Case Graph für den Authentifizierungsvorgang ist im Folgenden dargestellt.

 

Letztendlich ist es dadurch möglich geworden, alle gefundenen Bedrohungstypen für alle Komponenten des analysierten Systems zusammenzustellen. Diese können in Bedrohungs-Kategorien einsortiert werden, wie sie STRIDE oder ASF anbieten. Man kann Bedrohungsbäume erstellen um zu sehen, wie eine Bedrohung durch eine Verwundbarkeit entsteht. Und schließlich kann man Use- und Abuse-Cases aufstellen um im Folgenden Gegenmaßnahmen zu ermitteln, um die Bedrohung abzumildern.

Um STRIDE auf dieses Datenflussdiagramm anzuwenden, wird die folgende Tabelle benutzt:

Bedrohungs- Kategorie Beinflusst Prozesse Beeinflusst

Datenhaltung

Beeinflusst externe Entitäten Beeinflusst Datenfluss
Spoofing

X

X

Tempering

X

X

X

Repudiation

X

X

X

Information Disclosure

X

X

X

Denial of Service

X

X

X

Elevation of Privilege

X

Weiter zum 7. Teil