Skip to main content

Bedrohungsmodelle - Application Threat Modeling

Damit man eine Anwendung zuverlässig vor Angriffen schützen kann, muss man erst einmal wissen, welche Gefahren bzw. Angriffe ihr überhaupt drohen. Das dafür benötigte Bedrohungsmodell wird im Rahmen des Application Threat Modeling entwickelt.

Bedrohungsmodelle im "Real Life"

Jeder von uns erstellt ständig mehr oder weniger ausgereifte Bedrohungsmodelle. Schon die Überlegung, ob man einen Regenschirm mitnimmt, eine Regenjacke anzieht oder ohne Regenschutz das Haus verlässt, beruht auf einem Bedrohungsmodell: Wie groß ist die Gefahr, dass es regnet, während man draußen unterwegs ist?

Konkreter sieht es schon aus, wenn man sich Gedanken über die Sicherheit seiner Wohnung oder seines Hauses macht. Man fürchtet sich vor Einbrechern und lässt sichere Schlösser einbauen, man hat Angst vor Stürmen und lässt einen morschen Baum neben dem Haus fällen. Theoretisch könnte ein Meteorit aufs Dach fallen, aber das ist so unwahrscheinlich, dass es sich nicht lohnt, das Dach entsprechend stabil zu bauen. Man trifft seine Entscheidungen aufgrund von Wahrscheinlichkeiten und orientiert sich dabei an Erfahrungswerten aus der Vergangenheit. Trotzdem (oder gerade deswegen) wird man nicht alle möglichen Gefahren berücksichtigt und dadurch alle möglichen Gegenmaßnahmen getroffen haben.

Viele Wege führen zum Ziel

Es gibt viele Möglichkeiten für eine Bedrohungsmodellierung, und welcher Ansatz für Sie persönlich am zielführendsten ist, müssen Sie selbst ausprobieren. Es hängt von Ihren Bedürfnisse, Fähigkeiten und Kenntnissen ab, mit welchem Ansatz Sie am besten zu Recht kommen und das beste Ergebnis erzielen. Was für den einen als einzig wahrer Weg erscheint, kann für jemanden anderen ein Umweg oder sogar eine Sackgasse sein.

Eine Bedrohungsmodellierung kann z.B. unter Berücksichtigung der Aspekte Software-Entwurf, Ressourcen und Angreifer erfolgen:

  • Entwurfsgesteuerte Bedrohungsmodellierung geht von den während der Entwicklung sowieso gezeichneten Diagrammen aus und prüft für jedes Element, wie es missbraucht werden kann. Diesen Ansatz verfolgt Microsoft im Rahmen des Bedrohungsmodellierungsprozesses des Security Development Lifecycles.
  • Ressourcengesteuerte Bedrohungsmodellierung geht davon aus, was in Ihrem Programm geschützt werden soll. Zuerst werden alle Ressourcen Ihres Programms sowie alle Ressourcen, mit denen es verbunden ist, aufgelistet, danach werden mögliche Angriffe auf diese Ressourcen ermittelt. Ein Beispiel hierfür ist z.B. eine Datenbank mit vertraulichen Daten, ein möglicher Angriffe das Ausspähen dieser Daten.
  • Angreifergesteuerte Bedrohungsmodellierung beginnt mit der Frage, wer Ihr Programm angreifen könnte und welche Ressourcen ihn interessieren. Davon ausgehend werden dann die möglichen Fähigkeiten der Angreifer und daraus folgend die möglichen Angriffe ermittelt. Im Allgemeinen ist dieser Ansatz nur bedingt brauchbar, da die möglichen Angreifer meist nicht oder zumindest nicht konkret genug bekannt sind, sodass es an einer brauchbaren Grundlage für die weitere Modellierung mangelt. Falls jedoch ein möglicher Angreifer bekannt ist, dessen möglichen Angriffen gezielt begegnet werden soll, kann die "Angreifergesteuerte Bedrohungsmodellierung" gut zur Ergänzung eines anderen Ansatzes verwendet werden.

Entwurfsgesteuerte Bedrohungsmodellierung

Im Folgenden wird ein grundlegender entwurfsgesteuerter Bedrohungsmodellierungsprozess beschrieben, wie er von Microsoft im Rahmen des Security Development Lifecycle verwendet wird:

Vision – Haben Sie eine Vision!
Überlegen Sie, wo und wie Ihre Anwendung eingesetzt wird. Welche Sicherheitsanforderungen gibt es? Was macht Ihre Anwendung sicher? Kurz: Machen Sie sich ein Bild von möglichen Bedrohungen und bereits vorhandener Schutzmaßnahmen.

Model – Erstellen Sie ein Diagramm Ihrer Anwendung mit allen Datenflüssen!
Üblich ist die Verwendung von Kreisen für Code, Kästen für externe Dinge wie Personen, Server usw., Zylinder (oder einfach parallele Linien) für Datenspeicher wie z.B. Datenbanken etc. und Pfeile für Datenflüsse:

Zeichnen Sie Vertrauensgrenzen zwischen den Komponenten ein. Vertrauensgrenzen sind überall da, wo mehr als eine Person oder ein Prozess auf ein Objekt, z.B. eine Datei oder einen Prozess, zugreifen kann. Kreuzen Vertrauensgrenzen etwas anderes als Datenflüsse, muss dies in zwei logische Komponenten aufgeteilt werden. Gegebenfalls muss das Diagramm verfeinert werden.

Identify Threats – Ermitteln Sie mögliche Bedrohungen
Ermitteln Sie für jeden Datenfluss, der eine Vertrauensgrenze überschreitet, und für jedes damit verbundene Element des Diagramms mögliche Bedrohungen anhand des STRIDE-Modells, welches später detailliert vorgestellt wird.

Mitigate – Minimieren Sie die Bedrohungen
Prüfen Sie, ob sich die möglichen Bedrohungen bündeln lassen. Sind die Bedrohungen über alle oder zumindest viele Komponenten verstreut, müssen Sie sie an vielen Stellen abwehren. Können Sie sie in einer oder wenigen Komponenten bündeln, müssen Sie nur diese schützen.Verwenden sie, soweit möglich, Standard-Gegenmaßnahmen wie z.B. die Zugriffskontrolle des Systems. Entwickeln Sie, soweit notwendig, neue Gegenmaßnahmen. Prüfen Sie, ob die verbleibenden Risiken akzeptiert werden können.

Validate – Überprüfen Sie die Ergebnisse
Prüfen Sie, ob die Diagramme korrekt sind. Prüfen Sie, ob für jeden Datenfluss, der eine Vertrauensgrenze überschreitet, und für jedes damit verbundene Element die Bedrohungen nach dem STRIDE-Modell ermittelt wurde. Prüfen Sie, ob für jede Bedrohung Gegenmaßnahmen ergriffen wurden oder das Risiko akzeptabel ist. Gegebenfalls geht es dann wieder beim zweiten Punkt los.

STRIDE

STRIDE ist ein von Microsoft entwickeltes System zur Einordnung von Bedrohungen in sechs Kategorien. Der Name "STRIDE" wurde aus den Anfangsbuchstaben der sechs Kategorien gebildet:

  • Spoofing (Angriffe auf die Authentifizierung, z.B. Vortäuschen einer falschen Benutzeridentität)
  • Tampering (Angriffe auf die Integrität, d.h. Unbefugte Manipulationen an Daten)
  • Repudiation (Angriffe auf die Nicht-Abstreitbarkeit (Non-repudiation), z.B. Abstreiten der Urheberschaft)
  • Information Disclosure (Angriffe auf die Vertraulichkeit, z.B. Preisgabe bzw. Ausspähen von Daten)
  • Denial of Service (Angriffe auf die Verfügbarkeit)
  • Elevation of Privilege (Angriffe auf die Autorisierung, d.h. Privilegieneskalation, das Erlangen höherer Benutzerrechte)

Für jeden Datenfluss, der eine Vertrauensgrenze überschreitet, und für jedes damit verbundene Element des Diagramms müssen alle sechs Kategorien des STRIDE-Modells überprüft werden: Welche Angriffe sind möglich? Wie können sie durchgeführt werden?

Die Bedrohungsmodelle sind ein wichtiger Bestandteil des Security Development Lifecycle, den wir Ihnen bereits in der letzten Folge vorgestellt haben.


 

Autor des Artikels

Dipl.-Inform. Carsten Eilers ( www.ceilers-it.de) ist als freier Berater und Coach für IT-Sicherheit und technischen Datenschutz tätig und als Autor verschiedener Artikel und des Buches "Ajax Security" bekannt.  Seinen Blog finden Sie hier.

 



These postings are provided "AS IS" with no warranties, and confers no rights. Use of included code samples are subject to the terms specified at Microsoft - Information on Terms of Use. The content of these security articles are the own personal opinions from Carsten Eilers.

Microsoft führt eine Onlineumfrage durch, um Ihre Meinung zur -Website zu erfahren. Wenn Sie sich zur Teilnahme entscheiden, wird Ihnen die Onlineumfrage angezeigt, sobald Sie die -Website verlassen.

Möchten Sie teilnehmen?