Fuer Kritische Infrastruktur: Anwendung, typische Fehler, Praxiswissen und saubere Workflows

Bei kritischer Infrastruktur geht es nicht nur um den Schutz von Daten, sondern um die Aufrechterhaltung essenzieller Versorgung, Steuerung und Verfuegbarkeit. Ein Sicherheitsvorfall in einem normalen Buero-Netzwerk ist bereits teuer. Ein Vorfall in Energieversorgung, Wasser, Gesundheit, Verkehr, Telekommunikation oder industriellen Versorgungsprozessen kann dagegen physische Auswirkungen, regulatorische Meldepflichten, Lieferunterbrechungen und gesellschaftliche Folgeschaeden ausloesen. Genau deshalb unterscheidet sich die Bewertung einer Cyberversicherung fuer KRITIS deutlich von Policen fuer Standard-IT.

Versicherer betrachten in KRITIS-Umgebungen nicht nur klassische Office-IT, sondern die gesamte Angriffsoberflaeche: Active Directory, Fernwartung, VPN-Zugaenge, Lieferantenkonten, Backup-Zonen, Cloud-Dienste, Leitstellen, Historian-Systeme, Engineering-Workstations, Jump Hosts, Segmentierung zwischen IT und OT sowie die Frage, ob ein Angriff von der Verwaltungsdomäne in produktionsnahe Systeme springen kann. Wer hier nur an Antivirus und Firewall denkt, versteht das Risiko nicht tief genug.

In der Praxis scheitern viele Organisationen bereits an der sauberen Beschreibung ihrer Umgebung. Im Antrag wird oft von einem homogenen Sicherheitsniveau ausgegangen, obwohl in Wirklichkeit mehrere Reifegrade parallel existieren: moderne Cloud-Identitaeten, veraltete Windows-Server, proprietaere OT-Komponenten, externe Wartungszugriffe und schlecht dokumentierte Sonderfreigaben. Genau diese Brueche sind spaeter im Schadenfall kritisch. Was im Antrag als durchgaengig abgesichert dargestellt wurde, muss im Incident belastbar nachweisbar sein.

Besonders relevant ist die Trennung zwischen versicherbarem Cyberereignis und betrieblichem Ausfall mit Mischursachen. Faehrt eine Leitstelle herunter, weil ein Hypervisor kompromittiert wurde, ist die Kausalkette anders zu bewerten als bei einem Stromproblem, einem Bedienfehler oder einem Hardwaredefekt. In KRITIS muss deshalb jede Versicherung mit technischer Realitaet abgeglichen werden. Wer nur Preise vergleicht, landet schnell bei einer Police, die im Ernstfall auf Ausschluesse verweist. Ein erster Einstieg in Grundlagen findet sich unter Was Ist Das, fuer KRITIS reicht diese Basissicht aber nicht aus.

Hinzu kommt, dass KRITIS-Betreiber haeufig hybride Landschaften betreiben. Teile laufen on premises, andere in Cloud-Umgebungen, wieder andere in abgeschotteten OT-Segmenten. Dadurch entstehen Deckungsluecken an den Uebergaengen. Ein Beispiel: Die Identitaetsverwaltung liegt in Azure, die Alarmierung in einer SaaS-Plattform, die Betriebsdaten in lokalen Segmenten, die Fernwartung ueber VPN und Bastion Hosts. Ein erfolgreicher Angriff auf Identitaeten kann dann indirekt OT-nahe Prozesse beeinflussen. Wer solche Szenarien nicht im Vorfeld mit dem Versicherer abgleicht, riskiert Diskussionen ueber Obliegenheiten, Sicherheitsstandards und Meldefristen. Fuer Umgebungen mit starkem Cloud-Anteil sind auch Fuer Cloud Infrastruktur und Fuer Ot Umgebungen relevant, weil KRITIS heute fast nie rein lokal betrieben wird.

Die Kernfrage lautet daher nicht, ob eine Cyberversicherung sinnvoll ist, sondern ob sie technisch zur realen Betriebsarchitektur passt. In KRITIS ist eine Police nur dann belastbar, wenn Sicherheitsanforderungen, Nachweise, Incident-Prozesse und Wiederanlaufplanung exakt zu den tatsaechlichen Abhaengigkeiten der Umgebung passen.

Die groesste Fehleinschaetzung in KRITIS besteht darin, nur bekannte Assets zu bewerten. In echten Assessments zeigt sich regelmaessig, dass die dokumentierte Umgebung kleiner und sauberer wirkt als die operative. Alte Admin-Konten, vergessene Fernwartungszugriffe, unvollstaendige Netzwerkplaene, gemeinsam genutzte Service-Accounts und historisch gewachsene Ausnahmen sind keine Randfaelle, sondern Standard. Versicherer fragen deshalb zunehmend nach Asset-Management, Segmentierung, MFA, Logging, Backup und Incident-Prozessen. Die Frage ist nicht, ob diese Kontrollen existieren, sondern ob sie fuer alle kritischen Pfade gelten.

Ein typischer Angriffsweg beginnt nicht in der SPS oder im SCADA-System, sondern in der Office-IT: Phishing, kompromittierte Zugangsdaten, schwache VPN-Absicherung, fehlende Härtung von Jump Hosts oder ein unsauber gesichertes Identitaetssystem. Von dort aus erfolgt die laterale Bewegung in Management-Netze, Backup-Infrastruktur oder Administrationssysteme. Gerade in Umgebungen mit Fernwartung und Lieferantenanbindung ist die Eintrittswahrscheinlichkeit hoch. Wer das Risiko nur als OT-Thema betrachtet, blendet die eigentliche Vorstufe des Angriffs aus. Deshalb muessen Themen wie Fuer Vpn Umgebungen, Fuer Active Directory und Identity Management in die Versicherungsbewertung einbezogen werden.

Technisch sinnvoll ist eine Erfassung entlang von Wirkpfaden statt entlang von Organigrammen. Nicht die Abteilung ist entscheidend, sondern die Frage, welche Systeme fuer den Betrieb unverzichtbar sind, welche Abhaengigkeiten bestehen und ueber welche Ketten ein Angreifer Wirkung erzeugen kann. Ein kompromittierter Fileserver ist in einem Buero aergerlich. In KRITIS kann derselbe Fileserver Konfigurationsdateien, Engineering-Projekte, Schichtplaene, Notfallkontakte oder Dokumentation enthalten, ohne die der Wiederanlauf massiv verzoegert wird.

• Kritische Prozesse zuerst identifizieren: Versorgung, Steuerung, Leitstelle, Alarmierung, Fernwartung, Notbetrieb, Wiederanlauf.
• Danach die technischen Abhaengigkeiten erfassen: Identitaeten, Netzwerkpfade, Admin-Systeme, Backup, Virtualisierung, Historian, Datenbanken, Cloud-Dienste.
• Zum Schluss die Sicherheitskontrollen je Pfad pruefen: MFA, Segmentierung, Logging, Härtung, Patchstand, Offline-Backups, Ueberwachung.

Diese Reihenfolge ist wichtig. Viele Teams beginnen mit Tools und verlieren den Blick fuer die betriebliche Wirkung. Versicherer interessieren sich aber am Ende fuer Schadenhoehe, Ausfalldauer und Nachweisbarkeit angemessener Schutzmassnahmen. Wer seine Umgebung entlang von Wirkpfaden modelliert, kann Deckungssummen, Sublimits und Ausschluesse viel praeziser bewerten.

In KRITIS-Umgebungen mit industriellen Komponenten lohnt sich ausserdem die Trennung zwischen direkt steuernden Systemen und indirekt betriebsrelevanten Systemen. Ein Angriff auf E-Mail oder Dokumentenmanagement kann bereits genug Chaos erzeugen, um den Betrieb zu stoeren, auch wenn die eigentliche OT formal unangetastet bleibt. Genau deshalb greifen reine OT-Betrachtungen zu kurz. Themen aus Fuer Scada, Fuer Industrieanlagen und Fuer Energieversorger zeigen, wie eng digitale und physische Prozesse gekoppelt sind.

Viele Antragsfragen wirken simpel, sind technisch aber hoch aufgeladen. Die Frage nach MFA ist ein gutes Beispiel. In der Praxis ist nicht entscheidend, ob MFA irgendwo aktiviert wurde, sondern ob sie fuer privilegierte Konten, Remote-Zugaenge, Cloud-Administrationsportale, VPN, Backup-Konsole und kritische Management-Systeme verpflichtend ist. Ein Versicherer wird im Schadenfall nicht akzeptieren, dass MFA nur fuer Standardnutzer aktiv war, waehrend Domain-Admins oder externe Wartungskonten ausgenommen wurden. Deshalb sind Mfa Pflicht und Sicherheitsanforderungen keine Formalien, sondern harte Leistungsfaktoren.

Aehnlich kritisch ist das Thema Backup. In KRITIS reicht es nicht, taegliche Sicherungen zu besitzen. Entscheidend ist, ob Wiederherstellung unter Incident-Bedingungen moeglich ist. Sind Backups logisch vom Produktivnetz getrennt? Gibt es unveraenderbare oder offline faehige Kopien? Sind Wiederanlaufzeiten getestet? Koennen Konfigurationsdaten von OT-Komponenten, Historian-Daten, Rezepturen, Schluesselmaterial und Administrationsskripte reproduzierbar wiederhergestellt werden? Eine Police kann zwar Deckt Datenwiederherstellung vorsehen, aber wenn die Sicherungen technisch unbrauchbar sind, bleibt der operative Schaden bestehen.

Versicherer achten ausserdem auf Patch- und Vulnerability-Management. In KRITIS ist das komplexer als in Office-IT, weil Wartungsfenster, Herstellerfreigaben und Betriebsunterbrechungen Grenzen setzen. Trotzdem wird erwartet, dass ein dokumentierter risikobasierter Prozess existiert. Nicht jedes System muss sofort gepatcht werden, aber jedes ungepatchte System braucht Kompensationsmassnahmen: Segmentierung, Application Control, eingeschraenkte Kommunikation, Monitoring oder Jump-Host-Zwang. Wer veraltete Systeme ohne dokumentierte Risikobehandlung betreibt, liefert dem Versicherer im Schadenfall eine Angriffsflaeche fuer Leistungsverweigerung.

Ein weiterer Schwerpunkt ist Logging und Nachvollziehbarkeit. Ohne zentrale Zeitbasis, manipulationsarme Protokollierung und definierte Aufbewahrung ist weder Forensik noch Kausalitaetsnachweis sauber moeglich. Gerade in KRITIS mit Mischumgebungen aus Windows, Linux, Netzwerkkomponenten, OT-Gateways und Cloud-Diensten ist das anspruchsvoll. Aber ohne diese Daten laesst sich weder der Eintrittsweg noch der Umfang des Vorfalls belastbar rekonstruieren. Das ist relevant fuer Deckt Forensik, fuer die Schadenmeldung und fuer regulatorische Kommunikation.

Auch organisatorische Kontrollen werden geprueft, allerdings nicht losgeloest von der Technik. Awareness ohne technische Durchsetzung ist wertlos. Ein Notfallplan ohne Kontaktlisten, Eskalationsmatrix und Entscheidungsbefugnisse scheitert in der ersten Stunde. Ein Auditbericht ohne Nachverfolgung offener Findings ist nur Papier. In KRITIS muessen Sicherheitsmassnahmen nachweisbar gelebt werden. Deshalb spielen Nis2, Kritis Anforderungen und Incident Response Team in der Versicherbarkeit eine groessere Rolle als in weniger kritischen Branchen.

Wer eine Police abschliesst, sollte jede Antragsantwort technisch verifizieren. Nicht nach Bauchgefuehl, sondern anhand von Konfigurationen, Reports, Testprotokollen und Freigaben. In Penetrationstests zeigt sich regelmaessig, dass die Selbsteinschaetzung deutlich optimistischer ist als die reale Lage. Genau dort entstehen spaeter die teuersten Konflikte.

In KRITIS sind nicht nur Deckungszusagen relevant, sondern vor allem die Stellen, an denen Formulierungen unscharf werden. Viele Policen decken Cyberereignisse, aber nicht jede Form von Folgeschaden in derselben Tiefe. Besonders heikel sind Betriebsunterbrechung, physische Auswirkungen, Ausfaelle bei Dienstleistern, Alt-Systeme, Kriegsklauseln, grobe Obliegenheitsverletzungen und nicht gemeldete Risikoaenderungen. Wer nur auf Schlagwoerter wie Ransomware oder Incident Response schaut, uebersieht die eigentlichen Streitpunkte.

Ein klassischer Konflikt entsteht bei Mischschaeden. Beispiel: Ein Angreifer kompromittiert einen Fernwartungszugang, veraendert Konfigurationen, stoert die Prozessfuehrung und fuehrt dadurch zu Produktionsstillstand oder Versorgungsunterbrechung. Die Frage lautet dann: Ist der gesamte Schaden als Cyberereignis gedeckt, oder nur bestimmte Kostenbestandteile wie Forensik, Krisenkommunikation und IT-Wiederherstellung? Gerade in KRITIS mit OT-Bezug muss die Police klar regeln, wie digitale Ursache und physische Folge zusammenhaengen.

Ein weiteres Missverstaendnis betrifft Dienstleister und Lieferketten. Viele Betreiber verlassen sich auf externe Rechenzentren, Cloud-Plattformen, Fernwartungsfirmen oder spezialisierte Integratoren. Fällt ein externer Dienst aus oder wird kompromittiert, ist nicht automatisch jeder Eigenschaden voll gedeckt. Deshalb muessen Klauseln zu Drittanbietern, Sublimits und Wartezeiten genau gelesen werden. Themen wie Deckt Cloud Ausfaelle, Deckt Lieferkettenangriffe und Fuer Lieferkettenangriff sind in KRITIS keine Nebensaetze, sondern Kernbestandteile.

Problematisch sind auch unklare Definitionen von Stand der Technik oder angemessenen Sicherheitsmassnahmen. Wenn eine Police verlangt, dass marktuebliche Schutzmassnahmen umgesetzt sind, muss klar sein, was fuer die konkrete Umgebung darunter faellt. In einer KRITIS-Landschaft mit Legacy-Komponenten kann nicht jedes System modernisiert werden. Dann braucht es dokumentierte Ausnahmen, kompensierende Kontrollen und Management-Freigaben. Ohne diese Dokumentation wirkt ein technisch begruendeter Sonderfall im Schadenfall schnell wie Fahrlässigkeit.

• Unklare Formulierungen zu Betriebsunterbrechung und Ausfallzeiten fuehren spaeter zu Streit ueber den eigentlichen Schadenumfang.
• Alt-Systeme, Sonderfreigaben und Herstellerrestriktionen muessen vor Vertragsabschluss offen beschrieben werden.
• Dienstleister, Cloud-Anteile und Fernwartung brauchen eigene Betrachtung, weil hier oft Sublimits oder Ausschluesse greifen.

Besondere Aufmerksamkeit verdienen Meldefristen und Abstimmungspflichten. Manche Versicherer verlangen fruehe Einbindung ihrer Partner fuer Forensik, Rechtsberatung oder Krisenkommunikation. Wer vorschnell Systeme neu aufsetzt, Logs loescht oder externe Dienstleister ohne Abstimmung beauftragt, kann den Nachweis erschweren und Leistungen gefaehrden. Das gilt vor allem dann, wenn parallel regulatorische Meldungen, Betriebsentscheidungen und technische Sofortmassnahmen laufen.

Vor Vertragsabschluss sollten deshalb Vertragsbedingungen, Kleingedrucktes und Ausschluesse nicht juristisch isoliert, sondern gemeinsam mit Technik, Betrieb und Krisenverantwortlichen gelesen werden. Nur so wird sichtbar, ob die Police zur realen Angriffs- und Ausfalllogik der Umgebung passt.

Im Ernstfall entscheidet nicht die Police allein, sondern die erste Stunde. In KRITIS kollidieren drei Ziele sofort miteinander: Betrieb stabilisieren, Beweise sichern und Versicherungsbedingungen einhalten. Wer nur eines davon priorisiert, produziert Folgeschaeden. Ein uebereilter Reboot kann volatile Artefakte vernichten. Ein zu langes Warten auf Freigaben kann den Ausfall verlaengern. Ein unkoordinierter Eingriff externer Dienstleister kann die Kausalkette unklar machen.

Deshalb braucht KRITIS einen Incident-Workflow, der vorab geuebt wurde. Die technische Einsatzleitung muss wissen, welche Systeme isoliert werden duerfen, welche nur beobachtet werden, welche Daten zuerst gesichert werden und wann der Versicherer informiert wird. Parallel muessen Rechtsabteilung, Management, Betrieb, OT-Verantwortliche und Kommunikation eingebunden werden. In vielen Vorfaellen scheitert die Lage nicht an Malware, sondern an widerspruechlichen Entscheidungen zwischen IT, Produktion und Krisenstab.

Ein belastbarer Ablauf beginnt mit Triage: Was ist betroffen, was ist kritisch, was ist nur Indikator? Danach folgt Containment entlang der Wirkpfade. Nicht jedes kompromittierte System wird sofort abgeschaltet. In OT-nahen Umgebungen kann kontrollierte Beobachtung sinnvoller sein als hartes Trennen, wenn sonst die Versorgung gefaehrdet wird. Gleichzeitig muessen forensische Sicherungen priorisiert werden: Speicherabbilder, Logexporte, Firewall-Events, VPN-Logs, EDR-Telemetrie, Authentifizierungsdaten, Cloud-Audit-Trails und Konfigurationsstaende.

Ein typischer Minimalablauf kann so aussehen:

1. Incident klassifizieren und Kritikalitaet festlegen
2. Betroffene Wirkpfade identifizieren
3. Sofortmassnahmen mit Betriebsfreigabe abstimmen
4. Beweissicherung vor irreversiblen Eingriffen starten
5. Versicherer und definierte Partner fristgerecht informieren
6. Kommunikations- und Meldepflichten parallel ausloesen
7. Wiederanlauf nur auf verifizierter Basis beginnen

Wichtig ist die Reihenfolge. Viele Teams beginnen mit Wiederherstellung, bevor sie den Eintrittsweg verstanden haben. Das fuehrt zu Reinfektionen, unvollstaendiger Bereinigung und Diskussionen ueber vermeidbare Mehrkosten. Gerade wenn eine Police Deckt Incident Response oder Deckt Betriebsausfall umfasst, muss der Schadenverlauf nachvollziehbar dokumentiert werden. Sonst bleibt unklar, welche Ausfallzeit durch den Angriff und welche durch chaotisches Krisenmanagement entstanden ist.

In KRITIS sollte ausserdem vorab festgelegt sein, welche Systeme als Gold-Images, welche als forensische Beweistraeger und welche als priorisierte Wiederanlaufkandidaten gelten. Ohne diese Klassifizierung wird im Incident nach Gefuehl gearbeitet. Das ist in hochkritischen Umgebungen zu riskant. Gute Vorbereitung verbindet Notfallplan, It Forensik und Business Continuity zu einem einzigen operativen Ablauf statt zu drei getrennten Dokumenten.

In klassischen IT-Umgebungen ist die Reaktion auf einen Vorfall oft standardisierbar: isolieren, analysieren, bereinigen, wiederherstellen. In OT- und SCADA-nahen Umgebungen funktioniert dieses Muster nur eingeschraenkt. Systeme haben lange Lebenszyklen, proprietaere Protokolle, enge Herstellerbindungen und hohe Anforderungen an Verfuegbarkeit. Ein Security-Team kann nicht einfach jede verdächtige Komponente neu aufsetzen, wenn dadurch Steuerungslogik, Safety-Funktionen oder Prozessstabilitaet gefaehrdet werden.

Fernwartung ist dabei einer der haeufigsten Risikotreiber. Externe Integratoren, Hersteller und Servicepartner benoetigen Zugriff auf Anlagen, Gateways oder Management-Systeme. In vielen Umgebungen wurden diese Zugaenge historisch eingerichtet und spaeter nie sauber konsolidiert. Gemeinsame Konten, fehlende MFA, dauerhaft offene Tunnel, unzureichende Protokollierung und zu breite Berechtigungen sind typische Befunde. Im Schadenfall stellt sich dann nicht nur die Frage, wie der Angriff erfolgte, sondern auch, ob diese Zugaenge dem Versicherer korrekt offengelegt wurden.

Ein weiterer Schmerzpunkt ist die Segmentierung. Auf dem Papier existieren oft IT-, DMZ- und OT-Zonen. In der Praxis finden sich aber Ausnahmen: Engineering-Laptops mit Mehrfachanbindung, Fileshares ueber Zonengrenzen, direkte Admin-Verbindungen, Backup-Jobs in sensible Segmente oder Monitoring-Systeme mit zu weitreichenden Rechten. Ein Angreifer braucht keine perfekte Durchgaengigkeit. Ein einziger schlecht kontrollierter Uebergang reicht, um aus der Office-IT in produktionsnahe Bereiche zu gelangen.

Besonders kritisch ist die Frage, wie weit Wiederherstellung in OT ueberhaupt automatisierbar ist. Viele Komponenten lassen sich nicht wie virtuelle Server aus Snapshots zurueckholen. Konfigurationen, Firmware-Staende, Lizenzbindungen, Hersteller-Tools und physische Vor-Ort-Einsaetze spielen eine Rolle. Eine Police, die pauschal Datenwiederherstellung oder Serverausfall abdeckt, bildet diese Realitaet nur teilweise ab. Deshalb muessen Betreiber mit OT-Bezug sehr genau pruefen, ob Themen aus Fuer Fernwartungssysteme, Fuer Produktionsnetzwerke und Und Ot Security in der Vertragslogik sauber beruecksichtigt sind.

Aus Pentest-Sicht zeigen sich in OT-nahen Umgebungen immer wieder dieselben Muster: zu viel Vertrauen in Netzgrenzen, zu wenig Kontrolle privilegierter Konten, fehlende Session-Aufzeichnung bei Fernwartung, ungetestete Wiederanlaufverfahren und unvollstaendige Inventare. Diese Schwachstellen sind nicht nur technische Risiken, sondern direkte Versicherungsrisiken, weil sie den Unterschied zwischen beherrschbarem Incident und langem Versorgungsausfall ausmachen.

Eine hohe Deckungssumme klingt gut, sagt aber ohne Schadensmodell wenig aus. In KRITIS entstehen Kosten nicht linear, sondern in Wellen. Zuerst fallen Sofortkosten an: Incident Response, Forensik, externe Spezialisten, Rechtsberatung, Krisenkommunikation. Danach folgen Wiederherstellung, Ersatzbetrieb, Ueberstunden, Dienstleisterkoordination und technische Härtung. Die teuerste Welle ist oft der Betriebsausfall, insbesondere wenn Versorgung, Produktion oder vertragliche Leistungspflichten betroffen sind. Wer nur die Gesamtsumme betrachtet, uebersieht, dass einzelne Kostenarten durch Sublimits begrenzt sein koennen.

Ein Beispiel: Die Police nennt eine hohe Gesamtsumme, begrenzt aber Forensik, PR, Datenwiederherstellung oder Betriebsunterbrechung jeweils separat. In einem KRITIS-Fall kann bereits die erste Woche Incident Response einen erheblichen Teil des Forensik-Sublimits verbrauchen, waehrend der eigentliche Wiederanlauf noch gar nicht begonnen hat. Deshalb muessen Deckungssummen immer gegen realistische Szenarien gerechnet werden, nicht gegen Wunschvorstellungen.

Technisch sinnvoll ist eine Szenariorechnung entlang konkreter Ausfallbilder. Was kostet der Ausfall der Leitstelle fuer 12 Stunden? Was kostet der Verlust zentraler Authentifizierung? Was passiert, wenn Backup und Virtualisierung gleichzeitig betroffen sind? Wie teuer wird ein Vorfall, wenn externe Hersteller fuer OT-Komponenten vor Ort benoetigt werden? Solche Fragen sind deutlich wertvoller als pauschale Marktvergleiche. Wer trotzdem Preise einordnen will, sollte Kosten Kritis, Deckungssumme und Leistungsumfang immer gemeinsam betrachten.

• Gesamtsumme ohne Blick auf Sublimits fuehrt zu falscher Sicherheit.
• Betriebsunterbrechung muss gegen reale Wiederanlaufzeiten gerechnet werden, nicht gegen optimistische Planwerte.
• Externe Spezialisten, Hersteller und Vor-Ort-Einsaetze koennen in OT-nahen Faellen den Kostenblock massiv vergroessern.

Auch Selbstbehalte muessen operativ verstanden werden. Ein hoher Selbstbehalt kann fuer grosse Betreiber tragbar sein, wenn dafuer wichtige Leistungsbausteine sauber gedeckt sind. Ein niedriger Selbstbehalt hilft dagegen wenig, wenn kritische Kostenarten ausgenommen oder stark begrenzt sind. In KRITIS ist die Frage nicht nur, wie teuer die Police ist, sondern wie gut sie den wahrscheinlichsten Schadenpfad abbildet.

Ein weiterer Punkt ist die Dauer der Entschaedigung. Manche Policen decken Ausfallkosten nur fuer bestimmte Zeitfenster oder nach Wartezeiten. In OT- und KRITIS-Umgebungen kann der Wiederanlauf aber deutlich laenger dauern als in Standard-IT, weil Herstellerabhaengigkeiten, Safety-Pruefungen, Vor-Ort-Freigaben und regulatorische Abstimmungen Zeit kosten. Wer diese Realitaet nicht in die Vertragspruefung einbezieht, steht trotz hoher Versicherungssumme schnell mit einer Finanzierungsluecke da.

Der haeufigste Fehler ist eine zu optimistische Selbstauskunft. In Workshops zeigt sich oft, dass Fachbereiche von unterschiedlichen Realitaeten ausgehen. Das Security-Team sagt, MFA sei aktiv. Der Betrieb weiss, dass fuer bestimmte Alt-Systeme Ausnahmen existieren. Die OT-Abteilung nutzt externe Wartungskonten, die im zentralen IAM nicht auftauchen. Das Management geht von getesteten Backups aus, obwohl nur Dateiwiederherstellung geprueft wurde, nicht der komplette Wiederanlauf. Genau solche Widersprueche werden im Schadenfall sichtbar.

Ein zweiter Fehler ist unvollstaendige Dokumentation. Nicht jede Umgebung braucht Hochglanz-Dokumente, aber KRITIS braucht belastbare Nachweise. Dazu gehoeren Netzplaene, Zonenmodell, Asset-Liste, Rollen- und Berechtigungskonzepte, Backup-Nachweise, Restore-Tests, Patch-Ausnahmen, Lieferantenlisten, Fernwartungsfreigaben, Logging-Konzept und Incident-Rollen. Ohne diese Unterlagen wird jede Diskussion mit Versicherer, Forensik und Aufsicht unnötig schwer.

Drittens werden technische Ausnahmen oft nicht als Risikoaenderung verstanden. Ein temporaer geoeffneter Fernwartungskanal, eine neue Cloud-Anbindung, ein externer Dienstleister mit Admin-Rechten oder ein ungeplanter Betrieb alter Systeme veraendern die Risikolage. Wenn solche Aenderungen nicht intern bewertet und gegebenenfalls vertraglich gespiegelt werden, entsteht eine Luecke zwischen Antrag und Realbetrieb. Das ist besonders kritisch in Umgebungen mit Legacy-Anteilen oder Sondertechnik.

Viertens fehlt haeufig die Verbindung zwischen Audit und Betrieb. Findings aus Assessments, Penetrationstests oder Herstellerhinweisen werden zwar dokumentiert, aber nicht konsequent nachverfolgt. Im Incident ist dann bekannt, dass eine Schwachstelle existierte, aber unklar, warum sie offen blieb und welche Kompensationsmassnahmen galten. Aus Sicht eines Versicherers ist das ein schlechtes Bild. Themen wie Penetrationstest, Vulnerability Management und Patchmanagement muessen deshalb in den Regelbetrieb integriert sein.

Ein praxisnaher Ansatz ist, jede Antragsantwort mit einem internen Evidenzpaket zu hinterlegen. Nicht fuer den Papierstapel, sondern fuer den Ernstfall. Wenn im Antrag steht, dass privilegierte Zugaenge durch MFA geschuetzt sind, sollte es dazu Systemlisten, Richtlinien, Ausnahmeregister und technische Reports geben. Wenn Backups als getrennt beschrieben werden, braucht es Architekturbelege und Restore-Protokolle. Wenn Segmentierung behauptet wird, muessen Firewall-Regeln, Zonenplaene und Freigabeprozesse nachvollziehbar sein.

Wer diese Disziplin aufbaut, verbessert nicht nur die Versicherbarkeit, sondern auch die Incident-Faehigkeit. Denn im Vorfall zaehlt nicht, was theoretisch vorgesehen war, sondern was nachweisbar umgesetzt wurde.

Ein realistisches Szenario in KRITIS beginnt mit einem externen Wartungszugang. Ein Dienstleister nutzt ein dauerhaft freigeschaltetes Konto fuer mehrere Anlagenstandorte. MFA ist fuer das zentrale VPN aktiv, nicht aber fuer den nachgelagerten Jump Host. Das Konto wird ueber Passwortwiederverwendung kompromittiert. Der Angreifer meldet sich ausserhalb der ueblichen Wartungszeiten an, bewegt sich auf einen Administrationsserver, extrahiert Zugangsdaten und erreicht schliesslich Systeme, die fuer Konfigurationsverteilung und Betriebsdaten relevant sind.

Die erste Auffaelligkeit ist kein Verschluesselungsbildschirm, sondern inkonsistentes Verhalten im Betrieb: verzögerte Datenaktualisierung, fehlerhafte Alarme, ausbleibende Synchronisation. Das Team interpretiert die Stoerung zunaechst als technisches Problem. Waehren dieser Zeit sammelt der Angreifer weitere Berechtigungen und manipuliert Sicherungsjobs. Erst als mehrere Systeme gleichzeitig ausfallen, wird ein Cybervorfall erkannt. Zu diesem Zeitpunkt sind Logs teilweise ueberschrieben, Session-Daten fehlen und die Kausalkette ist bereits schwerer nachvollziehbar.

Im guten Fall greift nun ein vorbereiteter Workflow. Der Fernzugang wird kontrolliert getrennt, betroffene Segmente werden isoliert, volatile Daten gesichert, der Versicherer informiert und ein forensisches Team eingebunden. Parallel werden Notbetriebsoptionen aktiviert. Weil die Umgebung vorab sauber dokumentiert wurde, kann schnell entschieden werden, welche Systeme priorisiert wiederhergestellt werden und welche als Beweistraeger unangetastet bleiben. Die Police uebernimmt Forensik, Incident Response, Teile der Wiederherstellung und den nachweisbaren Betriebsausfall.

Im schlechten Fall passiert das Gegenteil: Admins setzen Systeme vorschnell neu auf, Dienstleister arbeiten parallel ohne zentrale Koordination, Logs werden geloescht, der Versicherer wird zu spaet eingebunden und die Ausfallzeit verlaengert sich durch Reinfektion. Dann wird aus einem beherrschbaren Vorfall ein Grossschaden mit Streit ueber Obliegenheiten, Dokumentation und Schadenhoehe.

Der Unterschied zwischen beiden Verlaeufen liegt selten in einem einzelnen Tool. Er liegt in Vorbereitung, Transparenz und Entscheidungsdisziplin. Genau deshalb muessen KRITIS-Betreiber Themen wie Fernwartung, Remote Zugriff und Bei It Notfall nicht isoliert, sondern als zusammenhaengenden Risikopfad betrachten.

Aus technischer Sicht ist die wichtigste Lehre: Der eigentliche Schaden entsteht oft nicht beim initialen Zugriff, sondern in der Phase zwischen erster Kompromittierung und strukturierter Reaktion. Wer diese Phase verkuerzt, reduziert nicht nur Ausfallzeit, sondern verbessert auch die Chance, dass Versicherungsleistungen ohne vermeidbare Konflikte greifen.

Eine belastbare Basis entsteht nicht durch den Vertragsabschluss, sondern durch die Verbindung von Technik, Betrieb und Nachweisfuehrung. Der erste Schritt ist eine ehrliche Bestandsaufnahme. Welche Systeme sind fuer Versorgung und Steuerung kritisch? Welche Abhaengigkeiten bestehen zu Identitaeten, Virtualisierung, Backup, Cloud, Fernwartung und Drittanbietern? Welche Alt-Systeme koennen nicht kurzfristig modernisiert werden? Welche Ausnahmen existieren bereits? Ohne diese Transparenz bleibt jede Police ein Blindflug.

Der zweite Schritt ist Priorisierung nach Wirkung. Nicht jede Schwachstelle ist gleich kritisch. Ein fehlender Patch auf einem isolierten Testsystem ist anders zu bewerten als ein schwach geschuetzter Jump Host mit Zugang zu produktionsnahen Segmenten. KRITIS braucht deshalb risikobasierte Entscheidungen mit dokumentierten Kompensationsmassnahmen. Genau hier treffen sich Sicherheitsarchitektur und Versicherbarkeit.

Der dritte Schritt ist Uebung. Incident-Response-Playbooks, Restore-Tests, Kommunikationswege und Eskalationsentscheidungen muessen unter realistischen Bedingungen geprobt werden. Besonders wertvoll sind Tabletop-Uebungen mit Betrieb, Technik, Management, Recht und externen Partnern. Dabei sollte nicht nur der Angriff simuliert werden, sondern auch die Frage, wann der Versicherer informiert wird, welche Freigaben benoetigt werden und wie Beweissicherung gegen Wiederanlauf abgewogen wird.

Der vierte Schritt ist kontinuierliche Anpassung. KRITIS-Landschaften veraendern sich laufend: neue Dienstleister, neue Cloud-Dienste, neue Fernwartungspfade, neue regulatorische Anforderungen. Eine einmal passende Police kann nach einem Jahr bereits Luecken haben. Deshalb muessen technische Aenderungen, Risikoanalysen und Vertragspruefung zusammenlaufen. Hilfreich sind dabei auch Querschnittsthemen wie Risikoanalyse, Und Nis2 und Und Disaster Recovery.

Am Ende gilt fuer KRITIS ein einfacher Grundsatz: Versicherbar ist nur, was technisch verstanden, organisatorisch beherrscht und im Ernstfall nachweisbar ist. Wer seine Umgebung sauber modelliert, Sicherheitsmassnahmen realistisch bewertet, Incident-Workflows uebt und Vertragsdetails an der Betriebsrealitaet misst, reduziert nicht nur das Risiko eines Grossschadens. Er verbessert auch die Chance, dass die Versicherung im entscheidenden Moment nicht zum Streitfall, sondern zum wirksamen Baustein der Krisenbewaeltigung wird.