Kritis Sicherheit Abwehr: Anwendung, typische Fehler, Praxiswissen und saubere Workflows

KRITIS-Abwehr scheitert selten an fehlenden Produkten. Sie scheitert meist daran, dass technische Schutzmaßnahmen ohne Verständnis für den realen Betriebsprozess eingeführt werden. In kritischen Infrastrukturen ist Verfügbarkeit kein abstrakter Sicherheitswert, sondern direkt an Versorgung, Produktion, Transport, Wasseraufbereitung oder Energieverteilung gekoppelt. Genau deshalb unterscheidet sich die Abwehr in OT- und ICS-Umgebungen fundamental von klassischer IT-Sicherheit. Wer Office-Netze absichert, denkt in Patches, EDR, Identity und Cloud-Kontrollen. Wer KRITIS absichert, muss zusätzlich in Taktzeiten, Safety-Funktionen, deterministischer Kommunikation, Legacy-Protokollen, Wartungsfenstern und physischen Prozessfolgen denken.

Der erste saubere Schritt ist daher immer die Trennung zwischen technischem Asset und betrieblicher Funktion. Eine SPS ist nicht nur ein Gerät mit Firmware-Version, sondern Teil einer Kette aus Sensorik, Aktorik, HMI, Engineering-Station, Historian, Fernwartung und Prozesslogik. Ein kompromittierter Knoten kann je nach Einbindung nur lokale Störungen verursachen oder eine ganze Linie, ein Umspannwerk oder eine Wasseraufbereitung beeinflussen. Wer diese Abhängigkeiten nicht dokumentiert, baut Abwehrmaßnahmen blind.

In der Praxis bedeutet das: Vor jeder Härtung steht die Frage, welche Kommunikation für den Betrieb zwingend notwendig ist, welche nur historisch gewachsen ist und welche schlicht nie entfernt wurde. Genau hier entstehen die meisten unnötigen Angriffsflächen. Alte Engineering-Freigaben, dauerhaft offene Fernwartungszugänge, unsegmentierte Layer-2-Bereiche, gemeinsam genutzte Admin-Konten und unkontrollierte Protokolle wie Modbus/TCP oder DNP3 ohne zusätzliche Schutzschichten sind typische Ausgangspunkte für spätere Vorfälle. Vertiefende Grundlagen zu OT-Architekturen und Schutzprinzipien finden sich in Ot Security sowie im Kritis Sicherheit Guide.

Eine belastbare KRITIS-Abwehr betrachtet immer drei Ebenen gleichzeitig: den Prozess, die Kommunikationspfade und die administrativen Eingriffe. Der Prozess beantwortet, was kritisch ist. Die Kommunikationspfade zeigen, wie ein Angreifer lateral vorgehen kann. Die administrativen Eingriffe zeigen, wo legitime Änderungen missbraucht oder unkontrolliert durchgeführt werden können. Erst wenn diese drei Ebenen zusammengeführt werden, entsteht ein realistisches Schutzbild.

Ein häufiger Denkfehler besteht darin, KRITIS-Abwehr als reines Blockieren zu verstehen. In produktionsnahen oder versorgungsrelevanten Netzen ist blindes Blockieren gefährlich. Wenn ein HMI nach einer Firewall-Regeländerung keine Sollwerte mehr schreiben kann oder ein Historian keine Daten mehr erhält, ist der Schaden sofort operativ sichtbar. Gute Abwehr ist deshalb präzise, nachvollziehbar und testbar. Sie reduziert Kommunikationsbeziehungen kontrolliert, dokumentiert Ausnahmen sauber und prüft jede Maßnahme gegen den realen Betriebsablauf.

Wer KRITIS verteidigt, braucht daher kein pauschales Sicherheitskonzept, sondern ein Betriebsmodell für Sicherheit. Dieses Modell definiert, welche Systeme führend sind, welche Kommunikationsbeziehungen erlaubt sind, wie Änderungen freigegeben werden, wie Störungen erkannt werden und welche Reaktion ohne Gefährdung des Prozesses möglich ist. Genau daraus entsteht ein Workflow, der nicht nur auf dem Papier funktioniert, sondern im Ereignisfall tragfähig bleibt.

Die wirksamste Abwehrmaßnahme in KRITIS ist fast immer eine saubere Architektur. Nicht weil Architektur spektakulär wäre, sondern weil sie Angriffswege begrenzt, bevor Signaturen, Regeln oder Analysten überhaupt eingreifen müssen. In OT-Umgebungen bedeutet das vor allem Zonierung, kontrollierte Übergänge und minimale Kommunikationsrechte. Eine flache Infrastruktur mit direkter Erreichbarkeit von Engineering-Stationen, HMIs, Historian, Domänenressourcen und Fernwartungszugängen ist aus Angreifersicht ideal. Jede fehlende Trennung verkürzt den Weg vom initialen Zugriff bis zur Prozessbeeinflussung.

Saubere Segmentierung beginnt nicht mit VLANs allein. VLANs sind organisatorisch nützlich, aber keine Sicherheitsgrenze, wenn Routing, ACLs und Firewall-Policies nicht konsequent umgesetzt werden. In KRITIS-Umgebungen müssen Zonen nach Funktion und Kritikalität gebildet werden: Office/IT, DMZ, zentrale OT-Dienste, Leit- oder SCADA-Ebene, Engineering, Steuerungsebene, Safety-nahe Komponenten und externe Zugänge. Besonders wichtig sind Übergänge zwischen IT und OT sowie zwischen zentraler OT und dezentralen Anlagen. Genau dort werden Kompromittierungen häufig weitergetragen. Für vertiefende Beispiele zu SCADA-nahen Umgebungen lohnt sich Kritis Sicherheit Scada und für Segmentierungsfehler Ot Netzwerk Segmentierung Risiken.

Ein belastbares Modell arbeitet mit expliziten Freigaben statt implizitem Vertrauen. Das heißt: Jede Verbindung wird begründet, dokumentiert und technisch erzwungen. Wenn eine Engineering-Station nur bei Wartung auf eine SPS zugreifen darf, dann darf dieser Pfad nicht 24/7 offen sein. Wenn ein Historian nur lesend Daten aus einer Prozesszone benötigt, dann wird genau dieser Datenfluss erlaubt und nichts darüber hinaus. Wenn Fernwartung notwendig ist, dann über einen kontrollierten Sprungpunkt mit starker Authentisierung, Sitzungsprotokollierung und zeitlicher Freigabe.

• Trenne IT, DMZ, zentrale OT-Dienste und Steuerungsebene mit klaren Sicherheitsgrenzen.
• Erlaube nur dokumentierte Kommunikationspfade mit definiertem Zweck, Richtung und Zeitfenster.
• Behandle Engineering-Zugriffe, Fernwartung und Admin-Pfade als Hochrisiko-Kommunikation.

Industrielle Firewalls sind dabei kein Selbstzweck. Sie müssen das Kommunikationsmodell abbilden. In vielen Netzen stehen Firewalls zwar physisch an den richtigen Stellen, sind aber logisch wirkungslos, weil Any-Any-Regeln, breite Servicegruppen oder pauschale Freigaben für ganze Subnetze konfiguriert wurden. Das ist in KRITIS besonders problematisch, weil solche Regeln oft jahrelang unangetastet bleiben. Gute Regelwerke orientieren sich an realen Datenflüssen, nicht an Organigrammen. Mehr dazu in Industrielle Firewalls Strategie und Industrielle Firewalls Industrie Angriffe.

Ein weiterer häufiger Fehler ist die Vermischung von Safety und Security ohne klare Zuständigkeiten. Safety-Systeme dürfen nicht unkontrolliert in allgemeine OT-Netze eingebunden werden. Gleichzeitig darf Security nicht so umgesetzt werden, dass Safety-Funktionen beeinträchtigt werden. Deshalb müssen Schutzmaßnahmen immer mit Betriebs- und Automatisierungsteams abgestimmt werden. In der Praxis bedeutet das Testfenster, Fallback-Pläne, dokumentierte Rollbacks und eine klare Freigabekette.

Architektur ist dann gut, wenn ein kompromittierter Client nicht automatisch zur Leitwarte, zur Engineering-Station oder zur SPS durchgreifen kann. Genau diese Begrenzung entscheidet darüber, ob ein Vorfall lokal bleibt oder sich zu einem KRITIS-Ereignis entwickelt.

Angriffe auf KRITIS beginnen selten direkt an der SPS. Der typische Weg führt über schwächer geschützte Randbereiche: Office-IT, externe Dienstleister, Fernwartungszugänge, schlecht abgesicherte IIoT-Komponenten, gemeinsam genutzte Admin-Systeme oder Engineering-Workstations mit Mehrfachrolle. Von dort aus wird lateral gearbeitet, bis ein System erreicht ist, das Prozesszugriff, Konfigurationszugriff oder Sicht auf die Anlage ermöglicht. Genau deshalb ist die Vorstellung gefährlich, dass klassische IT-Schutzmaßnahmen allein ausreichen. Sie erkennen oft den initialen Kompromiss, aber nicht die OT-spezifische Ausbreitung oder die Vorbereitung einer Prozessmanipulation.

Ein realistischer Angriffsweg sieht so aus: Ein externer Dienstleister verbindet sich über einen dauerhaft freigeschalteten Fernwartungszugang. Die Authentisierung ist schwach oder ein Zugang wurde wiederverwendet. Nach dem Zugriff wird eine Engineering-Station erreicht, auf der Projektdateien, Zugangsdaten und Netzwerkpfade gespeichert sind. Von dort aus lassen sich SPSen identifizieren, HMIs ansprechen oder Konfigurationsänderungen vorbereiten. In anderen Fällen beginnt der Angriff in der IT und nutzt unzureichend getrennte Domänen, Historian-Anbindungen oder gemeinsame Verwaltungsdienste, um in OT-Zonen vorzudringen. Solche Muster werden in Ot Cyberangriffe Guide und Ot Security Scada Angriffe praxisnah vertieft.

Besonders kritisch sind Protokolle, die historisch für Funktionalität statt für Sicherheit entwickelt wurden. Modbus/TCP kennt standardmäßig weder starke Authentisierung noch Integritätsschutz. DNP3 und andere Industrieprotokolle wurden in vielen Umgebungen lange ohne zusätzliche Schutzmechanismen betrieben. OPC UA bietet deutlich bessere Sicherheitsfunktionen, wird aber in der Praxis oft mit schwachen Zertifikatsprozessen, unsauberen Trust Stores oder zu breiten Berechtigungen betrieben. Wer Protokolle nur funktional betrachtet, übersieht ihre Missbrauchsfläche. Für konkrete Protokollperspektiven sind Modbus Sicherheit Angriffe und Opc Ua Security Ics Sicherheit relevant.

Standardabwehr greift oft zu spät, weil sie auf bekannte Malware-Muster, Host-Indikatoren oder klassische IT-Telemetrie fokussiert ist. In OT-Vorfällen ist das eigentliche Risiko aber häufig nicht die Schadsoftware selbst, sondern die legitime Nutzung vorhandener Funktionen. Ein Angreifer muss keine exotische Malware einsetzen, wenn Engineering-Software vorhanden ist, Projektdateien offen zugänglich sind und Schreibzugriffe technisch möglich bleiben. Das macht die Erkennung schwieriger. Eine legitime Verbindung zur SPS ist nicht automatisch harmlos. Entscheidend ist, ob sie zum richtigen Zeitpunkt, vom richtigen System, mit dem richtigen Zweck erfolgt.

Deshalb muss Abwehr in KRITIS immer verhaltensbasiert denken. Nicht nur: Läuft ein verdächtiger Prozess? Sondern auch: Warum spricht diese Station jetzt mit dieser SPS? Warum wird außerhalb des Wartungsfensters geschrieben? Warum taucht ein neues Engineering-Notebook in einer Prozesszone auf? Warum liest ein HMI plötzlich Registerbereiche, die bisher nie abgefragt wurden? Solche Fragen lassen sich nur beantworten, wenn Baselines vorhanden sind und OT-Telemetrie sauber ausgewertet wird.

Ein weiterer Fehler ist die Überschätzung von Perimeterschutz. Wenn ein Angreifer bereits in der Umgebung ist, entscheidet die interne Härtung. Lokale Admin-Rechte, ungeschützte Projektarchive, Klartext-Credentials in Konfigurationsdateien, fehlende Jump-Hosts und unkontrollierte Dateitransfers sind dann oft wichtiger als die äußere Firewall. KRITIS-Abwehr muss deshalb davon ausgehen, dass einzelne Schutzschichten versagen können. Die Architektur muss den Schaden dann trotzdem begrenzen.

Härtung in KRITIS ist kein Copy-and-Paste aus der IT. Ein ungeprüftes Deaktivieren von Diensten, aggressives Patchen oder das Ausrollen klassischer Security-Agenten kann in OT-Umgebungen zu Instabilität, Timing-Problemen oder Herstellerkonflikten führen. Trotzdem ist Härtung unverzichtbar. Der Unterschied liegt im Vorgehen: kontrolliert, getestet, dokumentiert und immer entlang der betrieblichen Kritikalität.

Engineering-Stationen sind meist die sensibelsten Systeme im OT-Kontext. Sie enthalten Projektdateien, Zugriffswerkzeuge, oft auch Kommunikationspfade zu mehreren Anlagen. Wer eine Engineering-Station kompromittiert, erhält nicht nur Sicht, sondern häufig Änderungsmacht. Deshalb müssen diese Systeme besonders streng behandelt werden: keine allgemeine Internetnutzung, keine E-Mail, keine Mehrfachrolle als Büroarbeitsplatz, keine dauerhafte Verbindung in mehrere Zonen ohne Kontrolle. Lokale Admin-Rechte sind auf definierte Prozesse zu begrenzen, Wechseldatenträger müssen kontrolliert werden, und Projektdateien gehören in nachvollziehbar verwaltete Ablagen statt auf verstreute lokale Verzeichnisse. Ergänzend dazu ist Plc Security Guide hilfreich.

HMIs werden oft unterschätzt, weil sie primär als Anzeige- und Bedienoberfläche wahrgenommen werden. In der Praxis sind sie jedoch häufig mit weitreichenden Rechten ausgestattet, enthalten Prozessbilder, Alarmierungslogik, Rezepturen oder direkte Schreibfunktionen. Ein HMI mit schwacher Härtung ist ein idealer Pivot-Punkt. Deshalb gelten hier klare Mindestanforderungen: unnötige Dienste deaktivieren, Benutzerrechte trennen, Applikationskontrolle prüfen, Protokollierung aktivieren und Remote-Zugriffe strikt begrenzen. Wenn HMIs auf Standardbetriebssystemen laufen, muss zusätzlich geprüft werden, welche Herstellerabhängigkeiten Patches oder Sicherheitssoftware beeinflussen.

Bei SPSen und SCADA-Systemen ist die Härtung stärker hersteller- und anlagenabhängig. Typische Maßnahmen sind Passwortschutz, Rollenmodelle, Schutz vor unautorisierten Downloads, Deaktivierung ungenutzter Kommunikationsdienste, Trennung von Engineering- und Runtime-Kommunikation sowie Absicherung von Backup- und Restore-Prozessen. In Wasser- und Energieumgebungen kommen oft zusätzliche Anforderungen an Nachvollziehbarkeit und Freigabe hinzu, etwa bei Sollwertänderungen oder Rezepturwechseln. Praxisnahe Einordnungen finden sich in Scada Security Abwehr und Plc Security Schutz.

• Engineering-Systeme nur für Engineering nutzen und strikt von Office-Funktionen trennen.
• HMI- und SCADA-Zugriffe rollenbasiert einschränken und Schreibrechte minimieren.
• SPS-Kommunikation auf notwendige Protokolle, Quellen und Zeitfenster begrenzen.

Ein sauberer Härtungsworkflow beginnt immer mit einer Kompatibilitätsprüfung. Welche Herstellerfreigaben existieren? Welche Patches sind validiert? Welche Dienste sind für Runtime, Diagnose oder Lizenzierung notwendig? Danach folgt eine Testphase in einer repräsentativen Umgebung oder in abgestimmten Wartungsfenstern. Erst dann wird produktiv ausgerollt. Jede Änderung braucht einen dokumentierten Rückfallpfad. In KRITIS ist ein Rollback kein Komfort, sondern Pflicht.

Besonders wichtig ist die Integrität von Projektständen. Viele Vorfälle eskalieren, weil niemand sicher sagen kann, welche SPS-Logik produktiv sein sollte und ob eine Änderung autorisiert war. Deshalb gehören Hashes, signierte Freigaben, versionierte Projektarchive und klare Verantwortlichkeiten zum Kern der Abwehr. Ohne vertrauenswürdigen Soll-Zustand ist jede Analyse nach einem Vorfall unsicher.

Härtung ist dann wirksam, wenn sie nicht nur einzelne Systeme absichert, sondern administrative Macht reduziert. Genau dort liegt der Unterschied zwischen kosmetischer und belastbarer KRITIS-Abwehr.

Ohne Sichtbarkeit bleibt KRITIS-Abwehr reaktiv und unscharf. Viele Umgebungen protokollieren zwar Ereignisse, aber nicht in einer Form, die operative Sicherheitsentscheidungen erlaubt. Klassische Syslogs oder Windows-Events allein reichen nicht aus, wenn die eigentliche Gefährdung in ungewöhnlichen OT-Kommunikationsmustern, neuen Assets, veränderten Polling-Raten oder unautorisierten Schreibzugriffen liegt. Monitoring in KRITIS muss deshalb Netzwerk-, Asset-, Protokoll- und Prozesssicht kombinieren.

Der erste Schritt ist passive Sichtbarkeit. In produktionskritischen Netzen wird nicht aktiv gescannt, wenn dadurch Geräte instabil werden könnten. Stattdessen werden SPAN-Ports, TAPs oder sensorbasierte Lösungen genutzt, um Kommunikation mitzulesen. Daraus lassen sich Assets, Kommunikationsbeziehungen, Protokolle, Rollen und zeitliche Muster ableiten. Diese Baseline ist die Grundlage jeder späteren Erkennung. Wer nicht weiß, was normal ist, erkennt keine relevante Abweichung. Gute Einstiege bieten Ot Monitoring Erklaert, Ot Monitoring Ics und Ot Anomalie Erkennung Ics.

Wirklich nützlich wird Monitoring erst, wenn technische Events in betriebliche Kontexte übersetzt werden. Ein neuer TCP-Flow ist nicht automatisch kritisch. Kritisch wird er, wenn er von einer Office-Station in eine Steuerungszone führt, wenn er außerhalb des Wartungsfensters auftritt oder wenn er ein Schreibkommando an eine SPS transportiert. Ebenso ist ein neues Asset nicht per se ein Vorfall. Es wird relevant, wenn es ohne Freigabe in einer sensiblen Zone auftaucht oder bekannte Engineering-Dienste anbietet.

In der Praxis sollten Erkennungsregeln nicht nur auf IOC-Listen basieren, sondern auf Abweichungen von freigegebenen Kommunikationsmustern. Beispiele: neue Master-zu-Slave-Beziehungen in Modbus, ungeplante Schreibzugriffe, Uploads oder Downloads von Logik, Zertifikatsänderungen bei OPC UA, neue Fernwartungssitzungen, ungewöhnliche Broadcast-Muster, plötzliche Kommunikationsspitzen zwischen HMI und SPS oder das Auftreten bisher unbekannter Engineering-Tools. Solche Signale sind oft wertvoller als generische Malware-Indikatoren.

Ein häufiger Fehler besteht darin, Monitoring nur zentral aufzubauen, ohne lokale Betriebsteams einzubinden. Analysten sehen dann zwar Alarme, können aber nicht beurteilen, ob eine Änderung geplant war. Gute KRITIS-Abwehr koppelt Monitoring daher an Change-Prozesse. Wenn eine Wartung freigegeben wurde, muss das Monitoring wissen, welche Systeme, Zeitfenster und Kommunikationsarten erwartet werden. Alles außerhalb dieses Rahmens ist verdächtig. So sinkt die Fehlalarmquote deutlich.

Ebenso wichtig ist die Qualität der Asset-Daten. Viele OT-Umgebungen kennen ihre eigenen Bestände nur unvollständig. Geräte werden umbenannt, ersetzt, temporär angeschlossen oder in Dokumentationen nie nachgezogen. Ein Monitoring-System ohne gepflegte Asset-Kontexte produziert zwar Daten, aber wenig Erkenntnis. Deshalb müssen Inventarisierung, Netzsicht und Betriebsdokumentation zusammengeführt werden.

Monitoring ist kein Luxus und kein später Ausbauschritt. In KRITIS ist es die Voraussetzung dafür, dass Abwehrmaßnahmen zielgerichtet und mit minimalem Betriebsrisiko umgesetzt werden können.

Incident Response in KRITIS unterscheidet sich grundlegend von klassischer IT-Reaktion. In einer Office-Umgebung kann ein kompromittierter Host oft sofort isoliert oder abgeschaltet werden. In einer Prozessumgebung kann genau diese Maßnahme zu Produktionsstillstand, Fehlsteuerung oder Safety-Folgen führen. Deshalb muss die Reaktion immer zwischen Sicherheitsgewinn und Betriebsrisiko abwägen. Das Ziel ist nicht maximale Härte, sondern kontrollierte Eindämmung.

Ein belastbarer OT-Incident-Response-Prozess beginnt lange vor dem Vorfall. Es muss festgelegt sein, wer im Ereignisfall entscheidet, welche Systeme isoliert werden dürfen, welche nur beobachtet werden, welche Kommunikationspfade priorisiert zu kappen sind und welche Änderungen zwingend mit Betrieb oder Leitwarte abgestimmt werden müssen. Ohne diese Vorarbeit eskalieren Vorfälle nicht wegen Technik, sondern wegen Unsicherheit und Zeitverlust. Vertiefende Abläufe finden sich in Ot Incident Response Ics Sicherheit und Ot Incident Response Checkliste.

Die erste Phase ist die Lageklärung. Welche Zone ist betroffen? Handelt es sich um IT-nahe Systeme, zentrale OT-Dienste, HMI, Engineering oder direkte Steuerungskomponenten? Gibt es Hinweise auf Schreibzugriffe, Logikänderungen, neue Benutzer, veränderte Kommunikationspfade oder Prozessanomalien? Parallel dazu muss geprüft werden, welche Maßnahmen betrieblich vertretbar sind. Ein kompromittierter Historian ist anders zu behandeln als eine aktive Engineering-Station mit Zugriff auf mehrere SPSen.

Die zweite Phase ist die kontrollierte Eindämmung. In KRITIS bedeutet das oft nicht sofortiges Abschalten, sondern gezieltes Unterbrechen einzelner Pfade: Fernwartung sperren, Jump-Host deaktivieren, Engineering-Zugänge schließen, bestimmte Firewall-Regeln temporär verschärfen, Benutzerkonten sperren oder Dateitransfers stoppen. Wenn direkte Steuerungskomponenten betroffen sind, muss die Reaktion mit Prozessverantwortlichen abgestimmt werden. In manchen Fällen ist Beobachtung unter erhöhter Kontrolle kurzfristig sicherer als ein harter Cut.

• Vorfall zuerst nach Zone, Funktion und möglicher Prozesswirkung klassifizieren.
• Eindämmung bevorzugt über Kommunikationspfade und Berechtigungen statt blindes Abschalten.
• Jede Reaktionsmaßnahme mit Betrieb, Automatisierung und gegebenenfalls Safety abstimmen.

Die dritte Phase ist die Integritätsprüfung. In OT-Vorfällen reicht es nicht, Malware zu entfernen. Es muss geprüft werden, ob Projektdateien, SPS-Logik, HMI-Konfigurationen, Rezepturen, Benutzerrechte oder Kommunikationsparameter verändert wurden. Genau hier werden viele Teams zu früh fertig. Ein bereinigter Windows-Host ist wertlos, wenn die manipulierte Logik in der Anlage verbleibt. Deshalb gehören Soll-Ist-Vergleiche, Projektvalidierung und gegebenenfalls forensische Sicherung zum Standard. Für die Nachbereitung sind Ot Forensik Ics und Ot Forensik Checkliste relevant.

Ein häufiger Fehler ist die Übertragung klassischer IT-Playbooks auf OT. Begriffe wie Containment, Eradication und Recovery bleiben zwar gültig, ihre Umsetzung ist aber anders. Recovery bedeutet in KRITIS nicht nur Systemwiederherstellung, sondern sichere Rückkehr in einen validierten Prozesszustand. Dazu gehören Funktionsprüfungen, Freigaben, Dokumentation und oft auch engmaschiges Monitoring nach der Wiederinbetriebnahme.

Gute Incident Response endet nicht mit dem Schließen des Tickets. Sie führt zu Architekturverbesserungen, strengeren Freigaben, besseren Baselines und klareren Zuständigkeiten. Sonst bleibt der nächste Vorfall nur eine Frage der Zeit.

Die meisten Schwächen in KRITIS-Umgebungen sind seit Jahren bekannt. Trotzdem tauchen sie in Audits, Assessments und Vorfällen immer wieder auf. Der Grund ist selten fehlendes Wissen, sondern organisatorische Reibung: Betrieb priorisiert Verfügbarkeit, Security fordert Kontrolle, Hersteller setzen Grenzen, Dienstleister arbeiten mit Gewohnheiten, und niemand will die Verantwortung für riskante Änderungen übernehmen. Daraus entstehen Kompromisse, die kurzfristig bequem, langfristig aber gefährlich sind.

Ein klassischer Fehler ist die dauerhafte Freischaltung von Fernwartung. Was als pragmatische Lösung für schnelle Unterstützung beginnt, wird schnell zum Standardzustand. Zugänge bleiben offen, Konten werden geteilt, MFA fehlt oder wird umgangen, Sitzungen werden nicht protokolliert. Im Vorfall ist dann oft unklar, wer wann welche Änderung durchgeführt hat. Ähnlich problematisch sind gemeinsam genutzte Engineering-Accounts oder lokale Administratoren ohne individuelle Nachvollziehbarkeit.

Ein weiterer Dauerfehler ist unvollständige Segmentierung. Formal existieren zwar Zonen, praktisch aber verbinden Ausnahmen alles mit allem. Historian braucht Zugriff, Backup braucht Zugriff, Hersteller braucht Zugriff, Leitwarte braucht Zugriff, und am Ende existiert ein Netz mit vielen nominellen Grenzen, aber wenigen echten Barrieren. Genau solche Umgebungen wirken auf dem Architekturdiagramm sauber und sind in der Realität hoch durchlässig. Typische Ursachen und Fehlmuster werden in Ot Netzwerk Segmentierung Fehler und Ot Security Fehler deutlich.

Sehr häufig ist auch die fehlende Kontrolle über Änderungen. Projektstände liegen mehrfach vor, Backups sind veraltet oder nie getestet, Konfigurationsänderungen werden telefonisch abgestimmt, aber nicht sauber dokumentiert. Nach einem Vorfall lässt sich dann nicht mehr sicher feststellen, ob eine Abweichung legitim oder manipulativ ist. In KRITIS ist das besonders kritisch, weil Wiederherstellung ohne vertrauenswürdigen Soll-Zustand riskant bleibt.

Ein weiterer Fehler ist die falsche Priorisierung von Schwachstellen. Teams investieren viel Zeit in generische CVE-Listen, während offensichtliche operative Risiken bestehen bleiben: ungeschützte Engineering-Stationen, fehlende Jump-Hosts, Klartext-Credentials, offene Dateifreigaben, unkontrollierte USB-Nutzung oder fehlende Protokollierung von Fernwartung. Schwachstellenmanagement muss in KRITIS immer exploitability, Erreichbarkeit, Prozessnähe und Kompensationsmaßnahmen zusammen betrachten. Ein ungepatchtes System in einer stark isolierten Zone kann weniger riskant sein als ein formal aktuelles System mit überbreiten Rechten.

Ebenso problematisch ist die Annahme, dass Herstellerfreigaben jede Sicherheitsdiskussion beenden. Herstellerkompatibilität ist wichtig, aber kein Ersatz für Sicherheitsarchitektur. Wenn ein Agent nicht installiert werden darf, müssen andere Kontrollen greifen: Segmentierung, Applikationskontrolle, restriktive Zugriffe, Monitoring, Härtung des Umfelds. Sicherheit in KRITIS entsteht fast immer aus mehreren abgestimmten Schichten, nicht aus einer einzelnen Maßnahme.

Diese Fehler wiederholen sich, weil sie organisatorisch bequem sind. Saubere Abwehr ist anstrengender: mehr Abstimmung, mehr Dokumentation, mehr Testen, mehr Disziplin. Genau deshalb trennt sich hier belastbare KRITIS-Sicherheit von bloßer Absicht.

KRITIS-Abwehr wird im Alltag nicht durch Ausnahmezustände entschieden, sondern durch Routineprozesse. Änderungen, Wartungen, Updates, Konfigurationsanpassungen, Herstellerzugriffe und Störungsbehebungen sind die Momente, in denen Sicherheitsgrenzen bewusst geöffnet werden. Wenn diese Workflows unsauber sind, entsteht die Angriffsfläche nicht trotz, sondern wegen des Betriebs.

Ein sauberer Change-Workflow beginnt mit einer fachlichen Begründung. Welche Anlage, welches System, welcher Zweck, welches Zeitfenster, welche Kommunikationspfade, welche Rückfalloption? Danach folgt die technische Vorbereitung: betroffene Regeln identifizieren, Monitoring auf erwartete Aktivitäten abstimmen, Backups prüfen, Projektstände sichern, Ansprechpartner benennen. Erst dann wird freigegeben. In vielen Umgebungen läuft es umgekehrt: erst Zugriff, später Dokumentation. Genau das öffnet Missbrauchsfenster.

Besonders kritisch sind temporäre Freigaben, die nie wieder geschlossen werden. Eine gute Praxis ist daher das Prinzip der verfallenden Berechtigung. Fernwartung, Engineering-Zugriffe oder Firewall-Ausnahmen werden mit Ablaufzeit eingerichtet und müssen aktiv verlängert werden. So wird aus einer Ausnahme nicht stillschweigend ein Dauerzustand. Ergänzend dazu sollte jede privilegierte Sitzung nachvollziehbar sein: wer, wann, von wo, mit welchem Zielsystem und welchem Auftrag.

Auch Medien- und Dateitransfers brauchen klare Regeln. In vielen KRITIS-Umgebungen gelangen Updates, Projektdateien oder Diagnosetools per USB oder über Zwischenstationen in die Anlage. Ohne definierte Prüfstrecken, Malware-Scanning, Freigabeverfahren und Hash-Prüfung ist das ein direkter Einfallspfad. Gleiches gilt für mobile Engineering-Notebooks von Dienstleistern. Diese Systeme dürfen nicht implizit vertraut werden, nur weil sie für Wartung benötigt werden.

Ein belastbarer Wartungsworkflow koppelt technische und organisatorische Kontrolle. Das bedeutet: Freigabe durch Betrieb, technische Umsetzung durch autorisierte Personen, begleitendes Monitoring, dokumentierte Ergebnisse und explizite Rücknahme temporärer Rechte. Für Konfigurationsnähe und saubere Umsetzung sind Kritis Sicherheit Konfiguration sowie Ics Security Konfiguration nützlich.

Wichtig ist außerdem die Trennung von Störung und Änderung. Unter Zeitdruck werden beide oft vermischt. Ein akuter Fehler in der Anlage führt dann zu improvisierten Zugriffen, die weder dokumentiert noch abgesichert sind. Gerade in solchen Situationen müssen Minimalregeln gelten: nur definierte Sprungpunkte, nur bekannte Konten, nur freigegebene Werkzeuge, nur dokumentierte Maßnahmen. Sonst wird aus einer Betriebsstörung schnell ein Sicherheitsvorfall oder aus einem Sicherheitsvorfall eine unkontrollierte Prozessänderung.

Saubere Workflows sind keine Bürokratie. Sie sind die technische Voraussetzung dafür, dass legitime Eingriffe von missbräuchlichen Aktivitäten unterscheidbar bleiben. Ohne diese Trennschärfe ist jede spätere Analyse unsicher.

Die Grundprinzipien der KRITIS-Abwehr sind ähnlich, die operative Ausprägung variiert jedoch stark nach Sektor. In der Energieversorgung sind Leit- und Fernwirktechnik, Umspannwerke, Protokolle wie IEC- oder DNP3-nahe Kommunikationsmuster und hohe Anforderungen an Verfügbarkeit prägend. Hier ist die Trennung zwischen zentraler Leitstelle, Fernzugriff, Stationsnetz und Schutztechnik besonders sensibel. Ein falsch gesetzter Filter oder eine unkontrollierte Wartungsverbindung kann weitreichende Folgen haben. Für sektornahe Einordnung bieten sich Kritis Sicherheit Energie und Industrie 4 0 Sicherheit Energie an.

In Wasser- und Abwasserumgebungen sind verteilte Anlagen, Außenstationen, Pumpwerke, Fernwirktechnik und oft lange Lebenszyklen der Komponenten typisch. Häufig existieren Mischumgebungen aus moderner Visualisierung und älteren Steuerungen. Die größte Schwäche liegt hier oft in dezentralen Standorten mit begrenzter physischer Kontrolle und historisch gewachsenen Kommunikationswegen. Ein kompromittierter Fernzugang oder eine schlecht geschützte Außenstation kann als Brücke in zentrale Bereiche dienen. Relevante Vertiefungen sind Kritis Sicherheit Wasser und Scada Security Wasser Sicherheit.

In Fabrikumgebungen dominiert häufig die Mischung aus Produktions-OT, MES, Qualitätsdaten, Robotik, SPS-Landschaften und Herstellerwartung. Hier entstehen Risiken oft durch hohe Änderungsdynamik, viele Lieferanten und enge Taktung. Wenn Produktionsdruck steigt, werden Sicherheitsgrenzen schnell aufgeweicht. Engineering-Laptops, temporäre Freigaben und gemeinsam genutzte Servicekonten sind typische Schwachstellen. Für diese Perspektive sind Kritis Sicherheit Fabrik und Plc Security Fabrik passend.

In der Logistik stehen Fördertechnik, Sortieranlagen, Lagerautomatisierung, SCADA-nahe Steuerung und oft eine enge Verzahnung mit IT-Systemen im Vordergrund. Dadurch entstehen besonders viele Übergänge zwischen klassischen IT-Diensten und OT-Komponenten. Ein Angriff auf zentrale IT kann hier schneller operative Auswirkungen entfalten als in stärker isolierten Umgebungen. Gleichzeitig sind Wartungsfenster knapp und Änderungen häufig. Gute Abwehr braucht deshalb besonders disziplinierte Segmentierung und Monitoring. Dazu passen Kritis Sicherheit Logistik und Scada Angriffe Logistik Sicherheit.

Diese Beispiele zeigen: KRITIS-Abwehr ist nie generisch. Die Technik muss an den Sektor, die Prozesslogik und die Betriebsrealität angepasst werden. Ein Wasserwerk braucht andere Prioritäten als eine Fabrik, eine Leitwarte andere als ein Logistikzentrum. Gleich bleibt nur das Grundprinzip: minimale Rechte, kontrollierte Übergänge, nachvollziehbare Änderungen und schnelle Sichtbarkeit bei Abweichungen.

Wer sektorübergreifend arbeitet, sollte deshalb nicht nur Technologien vergleichen, sondern auch Betriebsmodelle. Viele Fehlentscheidungen entstehen, wenn Maßnahmen aus einem Bereich unreflektiert in einen anderen übertragen werden. Gute Abwehr ist immer kontextgebunden.

Ein wirksames Abwehrmodell für KRITIS muss priorisieren. Nicht jede Umgebung kann sofort vollständig segmentiert, überwacht und gehärtet werden. Entscheidend ist daher die richtige Reihenfolge. Der erste Reifegrad besteht aus Transparenz: Assets, Zonen, Kommunikationspfade, Fernwartung, Engineering-Systeme, kritische Abhängigkeiten. Ohne diese Basis bleibt jede Maßnahme Stückwerk. Der zweite Reifegrad ist Begrenzung: Segmentierung, Jump-Hosts, restriktive Firewall-Regeln, Rollenmodelle, kontrollierte Wartung. Der dritte Reifegrad ist Erkennung: OT-Monitoring, Baselines, Anomalieerkennung, Change-Korrelation. Der vierte Reifegrad ist Reaktion: getestete Playbooks, forensische Sicherung, Wiederanlauf mit validiertem Soll-Zustand.

Wichtig ist, dass diese Reifegrade nicht isoliert betrachtet werden. Monitoring ohne Segmentierung erzeugt viele Alarme, aber wenig Schutz. Segmentierung ohne saubere Workflows wird durch Ausnahmen unterlaufen. Incident Response ohne vertrauenswürdige Backups und Projektstände bleibt riskant. Deshalb muss KRITIS-Abwehr als zusammenhängendes Betriebsmodell aufgebaut werden. Gute Orientierung liefern Kritis Sicherheit Checkliste, Ics Security Checkliste und Ot Sicherheit Checkliste.

Ein praxistauglicher Startpunkt ist die Konzentration auf wenige Hochrisikobereiche: externe Zugänge, Engineering-Stationen, Übergänge zwischen IT und OT, zentrale SCADA- oder Leitkomponenten, ungesicherte Protokolle und fehlende Nachvollziehbarkeit von Änderungen. Wer diese Bereiche sauber in den Griff bekommt, reduziert das reale Risiko oft stärker als durch breit gestreute Einzelmaßnahmen.

Ebenso wichtig ist die Messbarkeit. Sicherheitsfortschritt in KRITIS darf nicht nur aus Richtlinien bestehen. Relevante Fragen sind: Wie viele dauerhafte Fernwartungszugänge existieren? Wie viele Kommunikationsbeziehungen sind dokumentiert und freigegeben? Wie schnell wird ein neues Asset erkannt? Wie viele Engineering-Zugriffe sind individuell nachvollziehbar? Wie lange dauert die Integritätsprüfung nach einer Änderung? Solche Kennzahlen sind operativ aussagekräftig, weil sie direkt mit Angriffsfläche und Reaktionsfähigkeit zusammenhängen.

Ein belastbares Modell akzeptiert außerdem, dass Legacy bleibt. Nicht jede SPS wird ersetzt, nicht jedes Protokoll modernisiert, nicht jedes System agentenfähig. Das ist kein Grund für Resignation, sondern für kompensierende Kontrollen. Segmentierung, Protokollfilterung, Jump-Hosts, passive Überwachung, restriktive Freigaben und saubere Change-Prozesse sind genau dafür da. In KRITIS gewinnt selten die modernste Umgebung, sondern die disziplinierteste.

Am Ende ist Abwehr dann wirksam, wenn sie unter realen Bedingungen funktioniert: bei Zeitdruck, bei Störungen, bei Herstellerzugriffen, bei Schichtbetrieb und bei unvollständiger Information. Genau darauf müssen Architektur, Monitoring und Prozesse ausgelegt sein.