Zero Trust im Ernstfall: gezielt eindämmen

Zero Trust wird meist als Zugriffsprojekt eingeführt: VPN ablösen, Anmeldungen absichern, Berechtigungen aufräumen. Was das Modell für die Incident Response bedeutet, kommt in solchen Projekten oft zu kurz. Der Unterschied zeigt sich aber genau dann, wenn ein Konto kompromittiert ist oder ein Server auffällig wird. Wer jeden Zugriff einzeln prüft, kann ihn im Ernstfall auch einzeln entziehen.

Vom Netzstecker zum feinen Hebel

In klassisch aufgebauten Netzen sind die Mittel zur Eindämmung grob. Das Team schaltet das VPN ab, trennt ein ganzes Segment oder nimmt einen Server vom Netz. Das bremst den Angreifer womöglich, trifft aber auch alles, was mit dem Vorfall nichts zu tun hat. Entsprechend lange zögern Teams, bevor sie diesen Hebel ziehen.

Eine Zero-Trust-Architektur nach NIST SP 800-207 lässt jeden Zugriff über einen Entscheidungspunkt laufen, der Identität, Gerätezustand und Richtlinie bewertet. Ein Durchsetzungspunkt setzt das Ergebnis um, und zwar nicht nur bei der Anmeldung, sondern während der gesamten Sitzung (mehr dazu in unserem Beitrag über Identität als Motor von Zero Trust). Für die Incident Response ändert sich damit vor allem eines: Es gibt Hebel in mehreren Stärken. Ein Team kann eine erneute Anmeldung erzwingen, Rechte auf das Nötigste zurückschneiden, Sitzungen widerrufen, ein Gerät aussperren oder einen einzelnen Verbindungsweg zwischen zwei Workloads schließen. Alles andere bleibt in Betrieb.

Ein Hebel wirkt nur, wenn er vorbereitet ist

Das NIST hat seine Empfehlungen zur Incident Response im April 2025 grundlegend überarbeitet. Revision 3 der SP 800-61 ordnet sie den sechs Funktionen des Cybersecurity Framework 2.0 zu und versteht Incident Response als festen Teil des Risikomanagements. Die Vorbereitung ist damit kein Vorspiel, sondern Teil des laufenden Betriebs. Ob ein Team im Ernstfall gezielt eindämmen kann, entscheidet sich also vorher.

Jeder Hebel braucht zuerst eine Zuständigkeit. Wer darf nachts eine Sitzung widerrufen, wer ein Produktivsystem isolieren? Fehlt diese Festlegung, wird diskutiert, während der Angreifer weiterarbeitet. Wohin das führen kann, zeigt der OpenAI-Bericht zum Hugging-Face-Vorfall: Das Monitoring schlug Ende Juni an, die Evaluierung lief trotzdem weiter.

Ebenso wichtig ist das Wissen, was ein Eingriff trifft. Wer einen Verbindungsweg schließt, muss wissen, welche Anwendungen davon abhängen. Die US-Behörde CISA behandelt das Erfassen dieser Abhängigkeiten in ihrem Leitfaden zur Mikrosegmentierung vom Juli 2025 als eigenen Schritt, noch bevor die erste Richtlinie entsteht. Im Ernstfall beantwortet diese Karte die wichtigste Frage vor jedem Eingriff: Was funktioniert danach noch?

Und schließlich muss jeder Hebel geübt sein. Wie lange dauert es, einen Workload zu isolieren? Greift ein widerrufener Zugang wirklich überall? Solche Fragen gehören in eine Übung und nicht in die erste Stunde eines echten Vorfalls.

Widerrufen ist nicht gleich ausgesperrt

Ein Detail zeigt, warum sich diese Übung lohnt. In Cloudflare Access lassen sich die Sitzungen eines Nutzers mit wenigen Klicks für alle Anwendungen widerrufen. Ist das Konto beim Identity Provider aber noch aktiv, kann sich derselbe Nutzer kurz darauf neu anmelden, mit gestohlenen Zugangsdaten also auch der Angreifer. Dauerhaft wirkt der Widerruf erst, wenn das Konto beim Identity Provider gesperrt ist. Wer diese Reihenfolge nicht kennt, hält einen Vorfall für eingedämmt, obwohl er es nicht ist.

Ähnliches gilt für die Telemetrie. Zero Trust protokolliert jede Zugriffsentscheidung mit Identität, Gerät, Ressource und Zeitpunkt. Für die Analyse taugen diese Daten aber nur, wenn sie lange genug aufbewahrt werden und auch dann erreichbar sind, wenn Teile der Umgebung kompromittiert sind. Das BSI zählt Protokolldaten und ihre Aufbewahrung ausdrücklich zur Vorbereitung auf Sicherheitsvorfälle.

Was das für die NIS-2-Meldung bedeutet

Seit dem 6. Dezember 2025 gilt in Deutschland das NIS-2-Umsetzungsgesetz. Besonders wichtige und wichtige Einrichtungen müssen erhebliche Sicherheitsvorfälle dem BSI melden: mit einer frühen Erstmeldung binnen 24 Stunden nach Kenntnis, einer Folgemeldung binnen 72 Stunden und einer Abschlussmeldung spätestens einen Monat nach der Folgemeldung. Schon in der Erstmeldung fragt das BSI nach den getroffenen Maßnahmen und danach, ob der Vorfall unter Kontrolle ist.

Nach 24 Stunden lassen sich diese Fragen nur beantworten, wenn klar ist, welche Identitäten, Geräte und Anwendungen betroffen sind und welche Hebel bereits gezogen wurden. Protokollierte Zugriffsentscheidungen und vorbereitete Eindämmungsstufen liefern genau diese Antworten. Wie wir Unternehmen bei den Pflichten unterstützen, zeigt unsere Seite zu NIS-2-Compliance.

Fragen für die nächste Übung

Mit diesen Fragen lässt sich prüfen, wie gut die eigene Vorbereitung trägt:

1. Welche Eindämmungsstufen sind festgelegt, von der erneuten Anmeldung bis zur Isolation, und wer darf welche Stufe auslösen, auch nachts und am Wochenende?
2. Wird beim Widerruf einer Sitzung auch das Konto beim Identity Provider gesperrt, und wer übernimmt das?
3. Gibt es eine aktuelle Karte, welche Anwendungen und Workloads voneinander abhängen?
4. Werden Zugriffsentscheidungen lange genug protokolliert, und sind die Protokolle auch bei einer kompromittierten Umgebung erreichbar?
5. Wie lange dauert es nachweislich, einen Workload oder ein Gerät zu isolieren, und wann wurde das zuletzt geübt?
6. In welcher Reihenfolge werden Zugriffe nach dem Vorfall wieder freigegeben, und wer bestätigt, dass ein System bereinigt ist?

Wie KAEMI unterstützt

Wir setzen beide Seiten von Zero Trust als Managed Service um. Mit Cloudflare One wird jeder Zugriff an Identität und Gerätezustand gebunden und lässt sich im Ernstfall gezielt entziehen. Mit Mikrosegmentierung auf Basis von Illumio entsteht die Karte der Abhängigkeiten, und kompromittierte Workloads lassen sich isolieren, ohne den übrigen Betrieb anzuhalten. Wo Ihre Umgebung heute steht, von der Identität bis zu Log- und Flow-Daten, klärt ein Zero-Trust-Readiness-Workshop.

Quellen: NIST SP 800-61 Rev. 3, „Incident Response Recommendations and Considerations for Cybersecurity Risk Management“ (April 2025); NIST SP 800-207, „Zero Trust Architecture“ (August 2020); CISA, „Microsegmentation in Zero Trust, Part One: Introduction and Planning“ (29. Juli 2025); BSI, Informationen zur NIS-2-Meldepflicht nach § 32 BSIG; Cloudflare-Dokumentation zur Sitzungsverwaltung in Access.