Threat Modeling – Bedrohungsanalyse
Mit dieser Abhandlung soll der Prozess der Bedrohungsanalyse erklärt werden. Lesen Sie auf den folgenden 9 Seiten detaillierte Inhalte mit Beispielen und Anleitungen. Viele der Inhalte sind angelehnt an frei verfügbare Inhalte der OWASP-Webseite des Open Web Application Security Projekts, lizensiert mit der Creative Commons Attribution ShareAlike 3.0 license (CC-BY-SA).
- 1. Teil: Einleitung
- 2. Teil: Analyse der Anwendung
- 3. Teil: Datenfluss-Diagramm
- 4. Teil: Ermittlung und Einstufung von Bedrohungen
- 5. Teil: Security Controls – Maßnahmen zur Bedrohungsabwehr
- 6. Teil: Bedrohungsanalyse – Threat Analysis
- 7. Teil: Einstufung von Bedrohungen – Ranking of Threats
- 8. Teil: Gegenmaßnahmen
- 9. Teil: Zusammenfassung
Einleitung – was ist Threat Modeling?
Im Umfeld des IT-Security Consultings ist einer der Bausteine das Thema Threat Analysis– auf deutsch: Bedrohungsanalyse. Dabei handelt es sich um ein Vorgehensmodell, das die Analyse eines Softwaresystems in ein systematisches Schema überführt, damit im Rahmen eines Kundenauftrags ein definiertes Ergebnis erarbeitet und letztendlich abgeliefert werden kann.
Ziel dieser Abhandlung ist es, die Bedrohungsanalyse in eine strukturierte Form zu überführen. Anhand von Tabellen und Definitionen können die Begriffe und Entitäten des zu untersuchenden IT-Systems in eine Struktur gebracht werden, die es letztendlich erlaubt, Bedrohungen zu erkennen und zu managen.
Threat Modeling ist der strukturierte Ansatz, die Sicherheit eines IT-Systems zu analysieren. Dabei werden Risiken identifiziert, quantifiziert und adressiert, um im Anschluss ans Risk Management übergeben werden zu können.
Die hier verwendete Methode der Analyse eines Softwaresystems versucht, systematisch die Komplexität zu reduzieren, indem bei der Quellcodeanalyse gezielt die Stellen analysiert werden, an denen Interaktion mit Schnittstellen und anderen Hotspots stattfinden. Dieser „In-Depth First“ Ansatz hat gegenüber dem „Breadth First“ Ansatz den Vorteil, dass, anstatt den vollständigen Quellcode zu analysieren zu müssen, man sich sofort den kritischen und für die Sicherheit maßgeblich relevanten Teil fokussieren kann, anstatt sich einer meist kaum überschaubaren Fülle an Quellcode gegenüberzusehen und Gefahr läuft, den Faden zu verlieren.
Folgende 3 Phasen sind in diesem Prozess vorgesehen
- Zerlegen der Anwendung– („decompose the application“)
- Bedrohungen erkennen und einstufen– („determine and rank threats“)
- Bestimmen von Gegenmaßnahmen und Entschärfungen/Risikominderung– („determine countermeasures and mitigation“)
In allen 3 Phasen wird das Analyseergebnis ausführlich dokumentiert, so dass in der darauffolgenden Phase darauf aufgebaut werden kann. Das resultierende Dokument stellt das Threat Model dar – das Bedrohungsmodell der Applikation.
Was kann auf Bedrohungen hin analysiert werden?
Im Prinzip kann fast alles auf Bedrohungen hin untersucht werden:
- Applikationen
- Prozesse
- Systeme
- Physische Umgebungen
- etc.
Bei der Untersuchung kann also vom Großen und Ganzen bis zu kleinen Einheiten hin alles untersucht werden. Bei ersten Untersuchungen sowie bei Erweiterungen eines Systems ist die Detailtiefe naturgemäß unterschiedlich, weshalb es üblich erscheint, besonders exponierte Teile besonders zu fokussieren.
Wann sollte untersucht werden?
Der Lebenszyklus eines Softwaresystems beginnt bereits in der Designphase, geht dann in die Implementierungsphase und schließlich in die Betriebsphase, in der dann die Wartung- und Weiterentwicklungsphase zyklisch stattfindet. Threat Modeling sollte in allen Phasen stattfinden, unterscheidet sich aber inhaltlich in den einzelnen Phasen.
Frühe Design-Entscheidungen
In der frühen Phase des Designs sollten folgende Überlegungen angestellt werden:
- Welche Daten sollten gespeichert bzw. nicht gespeichert werden?
- Bei Passwörtern und ähnlichen Informationen reicht es meistens aus, nicht die Information selbst zu speichern, sondern nur einen sicheren Hash, der abgeglichen werden kann.
- Tokenisierung von Kreditkartendaten oder Hashing / Verschlüsslung?
- Authentifizierungs-Design
- Je nach Anwendungstyp und Prozess-Kontext sind unterschiedliche Designs erforderlich
- Verschlüsslungs-Design
- Welche Art und Stärke der Verschlüsselung ist angemessen? Welche Standard-Algorithmen sollten dazu ausgewählt werden?
- Reduktion der Angriffsfläche
- Nur so viele Informationen wie nötig preisgeben, Schnittstellen einfach halten
Threat Modeling existierender Systeme
- Erlaubt die Identifikation von bisher unbekannten Bedrohungen und potentiellen Schwachstellen.
- Einmal durchgeführt, ermöglicht es, dass Korrekturen vorgenommen werden können, selbst wenn das Basisdesign nicht so einfach geändert werden kann.
- Kann auch an kleineren Teilen des Systems gemacht werden, um dann kombiniert schnellere Ergebnisse zu liefern.
- Sollte auch durchgeführt werden, wenn in einer frühen Phase die Bedrohungsanalyse gemacht wurde, da weitere Bedrohungen im Lauf der Zeit entstehen und sich das System weiterentwickelt.
- Im Mittelpunkt können stehen: Vermögenswerte, Angreifer oder das System selbst.
Im Fokus der weiteren Betrachtung wird in diesem Dokument von existierenden Systemen ausgegangen, die untersucht werden.