Nach Patch-Wave kommt Continuity: Was die CISA-Warnung „CI Fortify“ für deutsche Mittelständler bedeutet

CISA hat mit der Initiative „CI Fortify“ eine Krisenplanungs-Anleitung für KRITIS-Betreiber veröffentlicht. Hintergrund ist die nüchterne Einschätzung, dass staatliche Akteure sich in den vergangenen Jahren in kritischen Infrastrukturen positioniert haben — mit der Option, im Krisenfall Operational Technology zu stören oder Telekommunikation auszuschalten. Zwei Disziplinen stellt CISA in den Mittelpunkt: Isolation (proaktives Trennen von Drittanbieter- und Geschäftsnetzen, um OT-Systeme zu schützen) und Recovery (essentielle Dienste in degradierter Kommunikations-Umgebung weiterbetreiben, statt komplett auszufallen). Das Ziel ist nicht „kein Cyber-Vorfall“, sondern „der Vorfall führt nicht zum Stillstand der Grundversorgung“. Für deutsche Mittelständler — KRITIS oder nicht — ist das eine Erinnerung daran, dass Patch-Disziplin nur die halbe Resilienz ist. Die andere Hälfte ist die Frage: Was läuft weiter, wenn das Netz wegbricht?

Was CISA mit „CI Fortify“ jetzt sagt

Die US-Cyber-Sicherheits-Behörde adressiert primär Betreiber von Wasserwerken, Transport, Energie und Telekommunikation. Die Position ist ungewöhnlich direkt: Nation-State-Akteure haben bereits Zugriffe in vielen kritischen Infrastrukturen aufgebaut. Die Frage ist nicht mehr, ob ein gezielter Cyber-Vorfall kommt — sondern ob die betroffene Organisation in der Lage ist, ihre Grundversorgung trotzdem aufrechtzuerhalten.

Zwei strategische Planungs-Ziele stellt CISA in den Mittelpunkt:

• Isolation. Proaktive Trennung kritischer Operational-Technology-Systeme von Drittanbieter- und Geschäftsnetzen. Das bedeutet, dass die OT-Schicht im Krisenfall ohne Verbindung zum Rest des Internets weiterlaufen können muss — geplant, dokumentiert, geübt.
• Recovery. Essentielle Dienst-Erbringung in einer degradierten Kommunikations-Umgebung. Wenn Phone, Internet oder Cloud-Services ausfallen, muss die Wasserversorgung trotzdem laufen, der Stromtransport funktionieren, die kritischen Patientenakten erreichbar sein.

Das Ziel ist nicht der Null-Vorfall. Das Ziel ist die fortgesetzte Grundversorgung trotz Vorfall.

Warum das nicht nur ein US-KRITIS-Thema ist

Drei Brücken, die das auch für den deutschen Mittelstand relevant machen.

Erstens, KRITIS-Dachgesetz und NIS2. Die deutsche Umsetzung verpflichtet inzwischen einen deutlich erweiterten Kreis an Unternehmen zu vergleichbaren Vorsorge-Maßnahmen. Wer als KRITIS-Betreiber, „besonders wichtige Einrichtung“ oder „wichtige Einrichtung“ eingestuft ist, hat im Kern genau diese zwei Aufgaben: System-Isolation im Vorfall-Szenario, plus belegbare Continuity der wesentlichen Dienste.

Zweitens, Lieferketten-Exposition. Ein Mittelständler, der nicht selbst KRITIS ist, aber als Lieferant einer KRITIS-Organisation agiert, wird in den nächsten Quartalen über Vertragsklauseln in dieselbe Disziplin gezogen. Audit-Anforderungen, dokumentierte Trenn-Pfade, Krisenkommunikation — das wird zum Standard-Beilage in B2B-Verträgen mit kritischen Sektoren.

Drittens, der eigene Geschäftsbetrieb. Auch ohne KRITIS-Status ist die Frage „was läuft weiter, wenn unser ERP, unsere Cloud oder unser Telco-Anbieter für 72 Stunden weg ist?“ eine Frage, die jedes Unternehmen heute beantworten können sollte. Die Antwort „dann steht alles still“ ist betriebswirtschaftlich keine Position mehr.

Konkrete Architektur-Implikationen

Isolation in der Praxis heißt: OT-Netze sind nicht „irgendwie hinter einer Firewall“, sondern in dokumentierten Zonen mit definierten Übergängen. Datenfluss vom Office-Netz ins OT-Netz ist eingeschränkt, gerichtet und auditierbar. Drittanbieter-Wartungs-Zugänge sind temporär, mit kurzlebigen Credentials und Audit-Trail. Die Trenn-Konfiguration ist getestet — nicht nur theoretisch dokumentiert, sondern mindestens einmal pro Jahr im Drill geübt.

Recovery in der Praxis heißt: Die kritischen Dienste haben eine Definition davon, was „minimal-Service“ bedeutet. Dafür existieren vorbereitete Konfigurationen, die ohne externe Cloud-Abhängigkeit, ohne aktuelles Software-Update und ohne Internet-Anbindung weiterlaufen. Backup-Daten sind getrennt von der Produktiv-Umgebung gespeichert, idealerweise in mindestens einer Variante offline. Die Wiederanlauf-Reihenfolge ist dokumentiert, und das Team hat den Plan einmal in einer Übung durchgespielt.

Beide Disziplinen sind keine Tool-Frage, sondern eine Disziplin-Frage. Die gleichen Werkzeuge — Firewalls, IAM, Backup-Lösungen — die Sie heute schon haben, reichen oft aus. Was fehlt, ist meist die dokumentierte Konfiguration, der getestete Drill und die klare Eskalationsroute.

Wie wir das selbst handhaben

Eine Empfehlung ohne eigene Praxis-Erfahrung ist hohle Beratung. Wir nutzen, was wir bauen.

In unserer eigenen Infrastruktur sind kritische Dienste — Code-Repositories, Build-Pipeline, Customer-Daten-Storage — in dokumentierten Zonen mit definierten Übergängen organisiert. Backups laufen mit 3-2-1-Strategie (drei Kopien, zwei Medien-Typen, eine off-site und davon eine offline). Die Build-Pipeline kann auch ohne externe API-Zugriffe Code aus den Repos bauen, signieren und ausrollen — getestet zuletzt im Quartals-Drill, in dem wir einen externen Cloud-Anbieter für 24 Stunden simuliert ausgeschaltet haben.

Die Wiederanlauf-Reihenfolge für unsere kritischen Customer-Stacks ist als Runbook im Repo, mit Versionsstand und letztem Test-Datum. Der Plan ist nicht spektakulär — er ist verlässlich.

Bei der CISA-CI-Fortify-Veröffentlichung haben wir intern keinen Aufwand gehabt. Nicht weil wir Helden sind, sondern weil die Disziplin schon eingebaut war.

Drei Maßnahmen-Tiefen für Ihren Stack

Kurzfristig (diese Woche):

• Inventar: Welche Ihrer Geschäftsprozesse sind unverzichtbar für die Grundversorgung Ihrer Kunden? Welche dürfen 24, 48, 72 Stunden ausfallen, welche nicht? Schreiben Sie diese Liste auf, auch grob.
• Externe Abhängigkeiten kartografieren: Welche Cloud-Anbieter, SaaS-Tools, externen APIs sind in welchen Prozessen kritisch? Wo gibt es Single Points of Failure?
• Backup-Stand prüfen: Wann lief die letzte erfolgreiche Wiederherstellungs-Probe? Wenn die Antwort „weiß ich nicht“ ist, ist das die erste Aufgabe.

Mittelfristig (nächstes Quartal):

• Netzwerk-Segmentierung dokumentieren oder einführen — kritische Systeme in eigenen Zonen, mit klaren Übergängen, mit auditierbarem Datenfluss.
• Krisenkommunikations-Plan: Wer entscheidet was, wenn die übliche Kommunikation (E-Mail, Slack, Telefon) ausfällt? Welche alternativen Kanäle sind vorbereitet?
• Erste Drill-Übung: Eine externe Abhängigkeit simuliert ausschalten und sehen, wie weit der Stack ohne sie läuft. Lehren in den Plan einbauen.

Strategisch (nächstes Jahr):

• KRITIS-/NIS2-Compliance ernsthaft prüfen — auch wenn die formale Einstufung knapp ausfällt, sind die geforderten Maßnahmen oft auch ohne formale Verpflichtung sinnvoll.
• Lieferanten-Klauseln modernisieren: Welche Continuity-Anforderungen schreiben Sie selbst in B2B-Verträge? Welche müssen Ihre Lieferanten erfüllen?
• Tabletop-Exercise mit Geschäftsführung und IT: Ein gemeinsames Krisenszenario einmal durchspielen, statt zu hoffen, dass das im Ernstfall improvisiert wird.