Threat Modeling für Einsteiger: Risiken erkennen, bevor eine Schwachstelle zum Problem wird

Als ich anfing, Sicherheit zu lernen, dachte ich zunächst, die Reihenfolge sei einfach: Listen von Schwachstellen lernen, Tools suchen und dann versuchen, die sichtbaren Lücken zu schließen. In Wirklichkeit ist die Liste der Schwachstellen lang und die Zahl der Werkzeuge wächst ständig. Ohne eine Methode, um zu entscheiden, was zuerst Aufmerksamkeit verdient, fühlt sich der Prozess an, als würde man überall einen Regenschirm mitnehmen, ohne je den Wetterbericht anzusehen.

Genau hier ist Threat Modeling nützlich. Es ist weder eine Tätigkeit nur für große Unternehmen noch ein Thema, das nur bei der Vorbereitung auf Zertifizierungen relevant ist. Es ist eine Denkgewohnheit, um zu erkennen, was geschützt werden muss, wer es möglicherweise stören will und welche Wege dafür genutzt werden könnten. Mit dieser Gewohnheit wird das Lernen von Sicherheitskonzepten zielgerichteter.

Angriffe nicht zufällig erraten

Threat Modeling ist ein systematischer Prozess, um Bedrohungen für ein System abzubilden. Sein Ziel ist nicht, die Zukunft genau vorherzusagen, sondern Überraschungen zu verringern. Wir akzeptieren, dass jedes System Grenzen hat, und treffen dann Sicherheitsentscheidungen in seinem Kontext.

Stell dir ein Haus vor, das vor einer längeren Reise unbeaufsichtigt bleibt. Man kauft nicht sofort jedes Sicherheitsgerät im Laden. Man beginnt mit den Grundlagen: Welche Türen lassen sich von außen öffnen, welche Gegenstände sind am wichtigsten, wer hat die Schlüssel und ist das Licht an der Haustür hell genug? Ein kleines Haus und ein Lager eines Unternehmens haben eindeutig unterschiedliche Risiken. Bei Servern, Webanwendungen und APIs ist es genauso.

Diese Denkweise taucht oft in Materialien zu Sicherheitszertifizierungen auf, auch wenn sie unterschiedliche Namen haben kann. Eine Prüfung kann Risikobewertung, Klassifizierung von Assets, Zugriffskontrolle oder Incident Response behandeln. Threat Modeling hilft, diese Konzepte zu einem Bild zu verbinden: Sicherheitskontrollen werden eingesetzt, weil es ein zu verringerndes Risiko gibt, nicht weil eine Checkliste es verlangt.

Mit Assets beginnen, nicht mit Tools

Ein leicht zu machender Fehler ist, mit der Frage zu beginnen: „Welches Tool soll ich installieren?“ Die nützlichere Frage lautet: „Was ginge verloren, wenn dieses System ein Problem hätte?“ Die Antworten sind Assets. Assets sind nicht nur physische Server. Administratorkonten, Kundendatenbanken, API-Schlüssel, Backup-Dateien, DNS-Konfigurationen und der Ruf eines Dienstes sind ebenfalls Assets.

Versuche, die Assets eines persönlichen Blogs auf einem Homeserver aufzuschreiben. Die Datenbank mit Artikeln und das Administratorkonto sind eindeutig wichtig. Hochgeladene Dateien sind wichtig, weil sie Originalbilder enthalten können. Tokens für Push-Benachrichtigungen und Backup-Zugangsdaten müssen ebenfalls geschützt werden, auch wenn sie auf keiner öffentlichen Seite erscheinen. Sobald diese Liste existiert, werden Prioritäten sichtbar: Das Offenlegen eines API-Schlüssels oder die Übernahme eines Administratorkontos ist meist gefährlicher als eine kleine Änderung am Aussehen einer Seite.

Diese Phase trainiert eine wichtige Fähigkeit beim Lernen für Zertifizierungen: Vertraulichkeit, Integrität und Verfügbarkeit zu unterscheiden. Durchgesickerte Kundendaten sind ein Vertraulichkeitsproblem. Heimlich veränderte Artikel sind ein Integritätsproblem. Eine Website, die bei Bedarf nicht erreichbar ist, hat ein Verfügbarkeitsproblem. Ein Asset kann mehr als einen dieser Aspekte betreffen.

Datenflüsse einfach zeichnen

Um zu beginnen, braucht man kein kompliziertes Diagramm. Papier, eine Notiz-App oder ein Diagramm aus Kästen und Pfeilen reicht aus. Zeichne Benutzer, Browser, Reverse Proxy, Anwendung, Datenbank und Dienste von Drittanbietern. Ergänze dann Pfeile für die Daten, die zwischen ihnen fließen.

Beispielsweise sendet ein Browser einen Benutzernamen und ein Passwort über HTTPS an die Anwendung. Die Anwendung prüft den Passwort-Hash in der Datenbank und erstellt anschließend ein Session-Cookie. Wenn ein Administrator ein Bild hochlädt, wird die Datei auf dem Datenträger gespeichert und ihre Metadaten werden in der Datenbank erfasst. Jede Datenbewegung ist eine Gelegenheit zu fragen: Ist die Verbindung verschlüsselt, ist die Identität des Senders geprüft und wurde die Eingabe validiert?

Vertrauensgrenzen oder Trust Boundaries verdienen besondere Aufmerksamkeit. Das öffentliche Internet und ein internes Netzwerk sind nicht dieselbe Umgebung. Dem Browser eines Besuchers darf nicht so vertraut werden wie einem Anwendungsprozess auf dem Server. Das Gleiche gilt für externe Dienste, die Webhooks oder Tokens empfangen. Diese Grenzen sind wie die Zugangssperre eines Bahnhofs: Jeder darf ankommen, aber nicht jeder darf den Steuerraum der Züge betreten.

STRIDE als Fragenliste verwenden

Für Einsteiger ist das STRIDE-Framework hilfreich, damit man nicht bei den bekanntesten Bedrohungen stehen bleibt. STRIDE ist kein Zauberspruch, der starr angewandt werden muss, sondern eine Fragenliste, um ein System aus mehreren Blickwinkeln zu betrachten:

• Spoofing: Kann sich jemand als Benutzer, Dienst oder Administrator ausgeben?
• Tampering: Können Daten oder Konfigurationen ohne Erlaubnis verändert werden?
• Repudiation: Sind wichtige Handlungen schwer nachzuweisen, weil kein Audit-Log vorhanden ist?
• Information Disclosure: Geben Fehler, Backups oder Endpunkte Daten preis, die geheim bleiben sollten?
• Denial of Service: Kann eine wiederholte Anfrage die Ressourcen des Dienstes erschöpfen?
• Elevation of Privilege: Kann ein gewöhnliches Konto Administratorzugriff erhalten?

Nimm einen Endpunkt zum Hochladen von Bildern als Beispiel. Spoofing weist auf die Notwendigkeit von Authentifizierung hin. Tampering erinnert uns daran, dass Dateiname und MIME-Type eines Benutzers nicht einfach vertraut werden dürfen. Information Disclosure spricht dafür, Upload-Dateien nicht an einem Ort zu speichern, an dem Skripte ausgeführt werden können. Denial of Service lässt uns über Dateigrößenbegrenzungen und Rate Limiting nachdenken. Eine einzige einfache Funktion hat überraschend mehrere Blickwinkel.

Plausible Risiken priorisieren

Threat Modeling ist kein Wettbewerb um die längste Bedrohungsliste. Eine lange Liste, auf die niemand reagiert, wird nur zu einem verstaubten Dokument. Bewerte Eintrittswahrscheinlichkeit und Auswirkung einfach. Risiken mit hoher Wahrscheinlichkeit und großer Auswirkung sollten zuerst bearbeitet werden.

In einer kleinen Anwendung sind ein schwaches Administratorpasswort oder ein im Web offenes Datenbank-Backup oft realistischer als ein hochkomplexes Angriffsszenario. Das bedeutet nicht, dass es keine ausgefeilten Angriffe gibt. Gute Sicherheit beginnt jedoch damit, die Haustür zu schließen, bevor man über Laserzäune wie im Film nachdenkt.

Eine Prioritätsnotiz kann so klein sein:

Asset: Administratorkonto
Bedrohung: Credential Stuffing übernimmt das Konto
Wahrscheinlichkeit: mittel
Auswirkung: hoch
Maßnahme: eindeutiges Passwort, MFA, Rate Limiting, Login-Audit-Log
Status: MFA noch nicht verfügbar, Rate Limiting aktiv

Dieses Format macht das Risiko später erneut prüfbar. Es trennt außerdem bereits vorhandene Maßnahmen von Vorhaben, die noch nicht umgesetzt sind. In der Praxis sollten Entscheidungen wie Risiko akzeptieren, reduzieren, übertragen oder vermeiden bewusst dokumentiert werden.

Threat Modeling ist ein Zyklus, keine einmalige Aufgabe

Systeme verändern sich. Heute gibt es vielleicht nur eine Artikelseite, im nächsten Monat möglicherweise Login, Uploads, eine API oder eine KI-Integration. Jede neue Funktion eröffnet neue Datenflüsse und Vertrauensgrenzen. Führe Threat Modeling daher beim Entwurf einer Funktion, vor großen Deployments und nach Änderungen der Architektur durch.

Ich mache es gern zu einem Teil der Fragen vor dem Klick auf den Deploy-Button: Welche neuen Daten kommen herein, wer darf darauf zugreifen, was passiert bei ungewöhnlichen Eingaben und welche Logs stehen zur Verfügung, wenn etwas schiefgeht? Diese vier Fragen ersetzen weder Penetrationstests noch Code Reviews, aber sie machen beides fokussierter.

Wenn du für eine Zertifizierung lernst, präge nicht nur die Definitionen von STRIDE oder der CIA-Triade auswendig ein. Nimm ein kleines Projekt, zeichne ein Diagramm und erkläre dann den Grund für jede Sicherheitskontrolle. Wenn du Theorie mit einem System verbinden kannst, das du wirklich kennst, werden Prüfungsantworten und technische Entscheidungen sinnvoller.

Schluss

Threat Modeling lehrt, dass Sicherheit nicht bedeutet, jede Möglichkeit zu fürchten. Es geht darum, Aufmerksamkeit gezielt zu wählen. Beginne mit Assets, betrachte Datenflüsse, frage mit STRIDE nach Bedrohungen und priorisiere dann die Risiken, die am plausibelsten sind. Wie beim Aufräumen eines Hauses vor dem Regen sind kleine Schritte vor dem Eintreffen eines Problems oft wertvoller als hektische Reparaturen, nachdem alles nass geworden ist.

Wenn du eine Anwendung oder einen Homeserver baust, erstelle diese Woche ein einfaches Diagramm. Welche Bedrohung wird als erste sichtbar, nachdem du die Datenflüsse abgebildet hast? Schreibe deine Erfahrung in die Kommentare oder teile diesen Artikel mit einem Freund, der gerade erst Cybersecurity lernt.