Bedrohungsmodellierung wie im Sonnensystem: IT-Sicherheit verstehen

Stellen Sie sich unser Sonnensystem als ein komplexes IT-Netzwerk vor – jedes Objekt folgt spezifischen Gesetzen, interagiert mit seiner Umgebung und ist potenziellen Bedrohungen ausgesetzt. Diese Analogie hilft, das Konzept der Bedrohungsmodellierung zu veranschaulichen, einer systematischen Methode zur Identifikation und Bewertung von Sicherheitsrisiken in technischen Systemen.

Doch warum gerade dieser kosmische Vergleich? Weil er verdeutlicht: Ein System lässt sich nur dann effektiv schützen, wenn man seine Strukturen, Abhängigkeiten und potenziellen Angriffsvektoren vollständig versteht. Genau wie ein Astronom die Bahnen der Planeten kartiert, muss ein IT-Sicherheitsexperte die Datenflüsse und Komponenten einer Anwendung analysieren – bevor ein „kosmischer Zusammenstoß“ wie ein Datenleck oder ein Systemausfall die Stabilität gefährdet.

Die STAR-Methode: Ein systematischer Ansatz zur Risikoanalyse

Die Bedrohungsmodellierung folgt oft der STAR-Methode, einem strukturierten Framework, das in vier Phasen unterteilt ist: Scope, Threats, Assessment und Review. Diese Herangehensweise stammt ursprünglich aus der Softwareentwicklung, lässt sich aber auf jede technische Umgebung übertragen – von Cloud-Infrastrukturen bis hin zu vernetzten IoT-Geräten.

1\. Scope: Wo beginnt und endet unser System?

Bevor Risiken bewertet werden können, muss das zu schützende System genau definiert werden. Hier kommt das Data Flow Diagram (DFD) ins Spiel – eine visuelle Darstellung aller Komponenten und ihrer Interaktionen. Ähnlich wie ein Astronom die Planetenbahnen kartiert, identifiziert das DFD:

• Prozesse: Aktive Systeme wie Server, APIs oder Anwendungen, die Daten verarbeiten.
• Datenspeicher: Datenbanken, Dateisysteme oder Cloud-Speicher, in denen Informationen abgelegt sind.
• Externe Entitäten: Nutzer, Drittanbieter oder andere Systeme, die mit dem eigenen Ökosystem interagieren.
• Vertrauensgrenzen: Logische oder physische Barrieren, die unterschiedliche Sicherheitszonen trennen (z. B. interne Netzwerke vs. öffentliche APIs).

In einer Cloud-Umgebung wird diese Analyse komplexer. Hier müssen zusätzliche Faktoren berücksichtigt werden:

• Shared Responsibility Model: Die Aufteilung der Sicherheitsverantwortung zwischen Cloud-Anbieter und Kunde.
• IAM-Rollen: Berechtigungsstrukturen, die den Zugriff auf Ressourcen regeln.
• Serverless-Architekturen: Dynamische Funktionen, die ohne feste Infrastruktur laufen.

Das Ziel ist klar: Ein vollständiges Bild der Umgebung zu zeichnen, um potenzielle Angriffswege frühzeitig zu erkennen. Dabei helfen Fragen wie:

• Woher könnte eine Bedrohung kommen?
• Welche Systeme wären betroffen?
• Wie schwerwiegend wäre der Schaden?

2\. Threats: Welche Risiken lauern im System?

Sobald das System kartiert ist, folgt die Identifikation möglicher Bedrohungen. Hier bewährt sich das STRIDE-Modell, eine von Microsoft entwickelte Taxonomie, die sechs Hauptkategorien von Sicherheitsrisiken definiert:

• Spoofing (Vortäuschung): Unberechtigte Identitätsübernahme (z. B. durch gestohlene Zugangsdaten).
• Tampering (Manipulation): Unerlaubte Änderungen an Daten oder Systemen (z. B. SQL-Injection).
• Repudiation (Leugnung): Fehlende Nachweisbarkeit von Aktionen (z. B. manipulierte Log-Dateien).
• Information Disclosure (Datenlecks): Ungewollte Preisgabe sensibler Informationen (z. B. durch Schwachstellen wie Heartbleed).
• Denial of Service (DoS): Verfügbarkeitsstörungen durch Überlastung (z. B. DDoS-Angriffe).
• Elevation of Privilege (Rechteausweitung): Unautorisierter Zugriff auf höhere Berechtigungen (z. B. durch Exploits).

Diese Kategorien helfen, Bedrohungen strukturiert zu betrachten – ähnlich wie ein Astronom zwischen natürlichen Phänomenen (z. B. Sonnenstürmen) und künstlichen Risiken (z. B. Weltraumschrott) unterscheidet. Die zentrale Frage lautet immer: Was könnte schiefgehen, und wie wahrscheinlich ist es?

Ein Beispiel aus der Praxis: Ein E-Commerce-System könnte durch Tampering gefährdet sein, wenn Angreifer Bestelldaten in der Datenbank ändern. Oder durch Denial of Service, wenn Bots die Server mit Anfragen überfluten.

3\. Assessment: Wie gehen wir mit den Risiken um?

Nach der Identifikation folgt die Bewertung. Hier stehen vier strategische Optionen zur Auswahl:

• Milderung (Mitigation): Risiken reduzieren, z. B. durch:
• Verschlüsselung sensibler Daten (AES-256 für Daten im Transit).
• Implementierung von Firewalls und Intrusion-Detection-Systemen.
• Regelmäßige Sicherheitsupdates für Abhängigkeiten.

• Beseitigung (Elimination): Risiken komplett eliminieren, z. B. durch:
• Abschaltung veralteter Systeme.
• Deaktivierung unsicherer Protokolle wie FTP zugunsten von SFTP.

• Übertragung (Transfer): Verantwortung delegieren, z. B. durch:
• Nutzung von Managed-Security-Services.
• Versicherung gegen Cyberangriffe.

• Akzeptanz (Acceptance): Risiken bewusst tragen, wenn:
• Die Kosten für Gegenmaßnahmen den potenziellen Schaden übersteigen.
• Keine praktikable Lösung existiert (z. B. bei seltenen, aber schwerwiegenden Angriffsszenarien).

Um diese Entscheidungen zu fundieren, greifen Sicherheitsexperten auf etablierte Frameworks zurück:

• OWASP ASVS: Ein Standard für die Bewertung der Sicherheit von Anwendungen.
• NIST SP 800-53: Ein Katalog von Sicherheitskontrollen für Bundesbehörden der USA.
• MITRE CWE: Eine Datenbank bekannter Schwachstellen.

Ein konkretes Beispiel: Statt vage von „Datenverschlüsselung“ zu sprechen, sollte das Team definieren, welche Daten mit welchem Algorithmus geschützt werden – etwa durch die Vorgabe: „Alle Kundendaten im Transit müssen mit TLS 1.3 verschlüsselt werden.“

4\. Review: Kontinuierliche Anpassung ist der Schlüssel

Bedrohungsmodellierung ist kein einmaliger Prozess, sondern eine dynamische Disziplin. Systeme entwickeln sich weiter – neue Features werden hinzugefügt, Abhängigkeiten ändern sich, und Angreifer finden neue Angriffsmethoden. Daher ist ein regelmäßiges Review essenziell:

• Nach jedem größeren Update sollte das Modell überprüft werden.
• Neue Bedrohungen (z. B. Zero-Day-Exploits) müssen in die Analyse einfließen.
• Feedback aus Vorfällen hilft, Lücken in der aktuellen Modellierung zu identifizieren.

Tools wie Microsoft Threat Modeling Tool oder OWASP Threat Dragon unterstützen diesen Prozess, indem sie automatisch DFDs generieren und STRIDE-Analysen durchführen.

Fazit: Warum Bedrohungsmodellierung unverzichtbar ist

Die Bedrohungsmodellierung ist kein theoretisches Konstrukt, sondern ein praktisches Instrument, um Sicherheitsrisiken frühzeitig zu erkennen und zu minimieren. Ob in einer lokalen Anwendung, einer Cloud-Umgebung oder einem vernetzten Ökosystem – das Prinzip bleibt gleich: Wer die Schwachstellen seines Systems kennt, kann gezielt gegensteuern.

Die STAR-Methode bietet dabei eine klare Struktur, während Frameworks wie STRIDE oder OWASP ASVS die Analyse vereinfachen. Doch unabhängig vom gewählten Ansatz gilt: Sicherheit ist kein Zustand, sondern ein Prozess. Regelmäßige Überprüfungen und Anpassungen sind der Schlüssel, um auch zukünftigen Bedrohungen einen Schritt voraus zu sein.

Für Entwickler und Sicherheitsverantwortliche bedeutet das: Beginnen Sie mit der Modellierung – denn wie im Weltraum gilt auch in der IT: Wer seine Umgebung nicht versteht, kann sie nicht schützen.