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

In kritischen Infrastrukturen entstehen Sicherheitsrisiken nicht erst dann, wenn Schadcode in ein Netz gelangt. Der eigentliche Ausgangspunkt liegt fast immer früher: unvollständige Asset-Transparenz, falsch verstandene Kommunikationsbeziehungen, unklare Verantwortlichkeiten zwischen IT, OT und Instandhaltung sowie Änderungen im Betrieb ohne belastbare Freigabeprozesse. Genau dort entstehen die Lücken, die später als technische Schwachstellen sichtbar werden.

KRITIS-Umgebungen unterscheiden sich grundlegend von klassischen Office- oder Rechenzentrumsumgebungen. In der OT zählt nicht primär Vertraulichkeit, sondern zuerst Verfügbarkeit, Prozessstabilität und sichere physische Zustände. Ein falsch gesetztes Paketfilter-Rule-Set, ein ungeprüftes Firmware-Update oder eine unkontrollierte Fernwartungsverbindung kann reale Auswirkungen auf Energieversorgung, Wasseraufbereitung, Logistik oder industrielle Produktion haben. Wer Risiken in KRITIS bewerten will, muss daher technische Schwachstellen immer mit Prozessfolgen verknüpfen.

Ein typischer Fehler ist die Übertragung reiner IT-Sicherheitslogik auf OT-Systeme. In IT-Netzen ist aggressives Patchen, Scannen und Isolieren oft Standard. In OT-Netzen kann genau dieses Vorgehen Störungen auslösen. Alte SPSen, proprietäre Gateways, serielle Protokollwandler und HMI-Systeme reagieren teilweise empfindlich auf Traffic-Muster, die in IT-Umgebungen harmlos wären. Der Unterschied wird in Unterschied It Und Ot Security Fehler und Ot Security Ics besonders deutlich.

Risiko bedeutet in KRITIS deshalb nicht nur: Ein Angreifer könnte eindringen. Risiko bedeutet: Ein Angreifer, ein Fehlkonfigurationsfehler oder ein interner Bedienfehler könnte einen Prozesszustand erzeugen, der Sicherheitsfunktionen umgeht, Messwerte verfälscht, Stellgrößen verändert oder Wiederanlaufzeiten massiv verlängert. Diese Perspektive ist entscheidend, weil viele Organisationen ihre Schutzmaßnahmen noch immer an CVE-Listen statt an Prozessauswirkungen ausrichten.

Saubere Workflows beginnen mit einer belastbaren Frage: Welche Systeme beeinflussen direkt oder indirekt einen kritischen Prozess? Dazu gehören nicht nur PLCs, RTUs, Engineering-Stationen und SCADA-Server, sondern auch Historian-Systeme, Jump Hosts, Fernwartungszugänge, Zeitquellen, Lizenzserver, Backup-Infrastrukturen und oft übersehene IIoT-Komponenten. Gerade die Verbindung zwischen klassischer OT und moderner IIoT-Anbindung erweitert die Angriffsfläche erheblich, was in Kritis Sicherheit Iiot Sicherheit und Ot Security Iot Sicherheit vertieft wird.

Wer KRITIS-Risiken realistisch bewerten will, muss drei Ebenen gleichzeitig betrachten: technische Exponierung, betriebliche Abhängigkeit und mögliche physische Wirkung. Erst aus dieser Kombination entsteht ein verwertbares Lagebild. Ein offener Port allein ist noch kein prioritäres Risiko. Ein offener Port auf einer Engineering-Station mit Schreibzugriff auf SPS-Logik in einem kritischen Prozesssegment ist dagegen hochrelevant.

Die häufigste Fehlannahme lautet, dass Angriffe auf KRITIS immer hochkomplexe Zero-Day-Kampagnen erfordern. In der Praxis beginnen viele Vorfälle mit Standardproblemen: schwache Fernwartung, gemeinsam genutzte Konten, fehlende Netzwerksegmentierung, unkontrollierte Übergänge zwischen Office-IT und OT oder Engineering-Laptops mit Mehrfachnutzung. Der Angreifer braucht oft keinen direkten Exploit gegen eine SPS, wenn bereits ein administrativer Pfad über Windows-Systeme, VPN-Zugänge oder schlecht abgesicherte Remote-Desktop-Strecken existiert.

Besonders kritisch sind Übergangszonen. Dazu zählen Terminalserver für Dienstleister, Datendrehscheiben zwischen ERP und Produktionsnetz, Historian-Replikation, OPC-Kommunikation, Wartungsmodems und IIoT-Gateways. Diese Systeme verbinden unterschiedliche Vertrauensbereiche und werden deshalb häufig zum Pivot-Punkt. Ein kompromittierter Jump Host ist in KRITIS oft gefährlicher als eine einzelne verwundbare SPS, weil darüber legitime Managementpfade missbraucht werden können.

Typische Angriffsflächen in KRITIS sind:

• Fernwartungszugänge ohne starke Authentisierung, ohne Sitzungsaufzeichnung und ohne zeitliche Freigabe
• Engineering-Stationen mit Internetkontakt, Office-Nutzung oder unkontrolliertem Datenaustausch per USB
• Flache Netzsegmente, in denen HMI, PLC, Historian und Wartungssysteme ohne harte Trennung kommunizieren
• Legacy-Protokolle ohne Authentisierung oder Integritätsschutz wie Modbus/TCP oder ältere DNP3-Implementierungen
• Unsichtbare Schatten-Assets wie unmanaged Switches, Medienkonverter, serielle Gateways oder Testsysteme

Gerade industrielle Protokolle werden oft missverstanden. Das Risiko liegt nicht nur in fehlender Verschlüsselung, sondern in der Semantik der Befehle. Wer Schreibzugriffe auf Register, Coils oder Konfigurationsbereiche ausführen kann, beeinflusst Prozesse direkt. Bei Modbus ist das besonders offensichtlich, weshalb Modbus Sicherheit Risiken, Modbus Sicherheit Angriffe und Modbus Sicherheit Konfiguration in vielen Umgebungen Pflichtlektüre sind.

Auch scheinbar moderne Protokolle sind nicht automatisch sicher. OPC UA kann starke Sicherheitsmechanismen bieten, wird aber in der Praxis oft mit schwachen Zertifikatsprozessen, unsauberen Trust Stores oder unsicheren Fallback-Konfigurationen betrieben. DNP3 wiederum wird in Energie- und Versorgungsumgebungen häufig historisch gewachsen eingesetzt, mit allen Risiken veralteter Implementierungen. Wer diese Protokolle nur auf Port-Ebene betrachtet, verpasst die eigentliche Angriffslogik.

Ein weiterer realistischer Einstiegspunkt ist die Lieferkette. Dienstleister bringen Software, Projektdateien, Firmware, Konfigurationsstände und mobile Systeme mit. Wenn Freigaben, Prüfsummen, Signaturen und Testumgebungen fehlen, wird jede Wartung zum potenziellen Einfallstor. In KRITIS ist deshalb nicht nur die technische Härtung wichtig, sondern auch die Kontrolle darüber, wer wann mit welchem Werkzeug und welchem Freigabestatus Änderungen einbringt.

Viele Risikoanalysen in KRITIS scheitern nicht an fehlenden Tabellen, sondern an falschen Annahmen. Häufig werden Assets inventarisiert, Schwachstellen eingesammelt und dann nach CVSS sortiert. Das erzeugt Aktivität, aber nicht zwingend Sicherheit. Ein CVSS-Score sagt wenig darüber aus, ob ein Asset überhaupt erreichbar ist, welche Rolle es im Prozess spielt und welche physischen Folgen eine Manipulation hätte.

Ein klassisches Beispiel: Ein veralteter Webserver auf einem isolierten Reporting-System erhält hohe Aufmerksamkeit, während eine Engineering-Station mit lokal gespeicherten Projektdateien, Standardpasswörtern und direktem Schreibzugriff auf mehrere SPSen kaum priorisiert wird. Aus Sicht des Betriebs ist die Engineering-Station fast immer kritischer. Risiko in KRITIS ist daher immer eine Funktion aus Erreichbarkeit, Berechtigung, Prozessnähe und Wiederherstellbarkeit.

Ebenso problematisch ist die Vermischung von Safety und Security ohne klare Schnittstellen. Beide Disziplinen beeinflussen sich, sind aber nicht identisch. Eine Safety-Funktion kann vorhanden sein und trotzdem durch Security-Schwächen indirekt gefährdet werden, etwa wenn ein Angreifer Messwerte manipuliert, Alarme unterdrückt oder Bedieneroberflächen täuscht. Umgekehrt kann eine Security-Maßnahme den Betrieb stören, wenn sie ohne Prozessverständnis eingeführt wird.

Besonders häufig treten folgende Analysefehler auf:

• Bewertung einzelner Systeme ohne Betrachtung der Kommunikationskette und der abhängigen Prozessschritte
• Fokus auf bekannte Schwachstellen statt auf missbrauchbare legitime Funktionen und Berechtigungen
• Unterschätzung von Wartungszugängen, Engineering-Workstations und Dienstleisterkonten
• Keine Trennung zwischen theoretischer Verwundbarkeit und praktisch ausnutzbarem Angriffspfad
• Fehlende Einbindung von Betrieb, Instandhaltung, Leittechnik und Netzwerktechnik in die Bewertung

Ein belastbarer Workflow beginnt deshalb mit Szenarien statt mit Produktlisten. Beispiel: Was passiert, wenn ein Angreifer über einen Fernwartungszugang auf einen Jump Host gelangt, von dort eine Engineering-Station erreicht und anschließend Sollwerte oder Logikbausteine verändert? Welche Erkennung existiert? Welche Freigaben greifen? Wie schnell fällt die Abweichung auf? Welche manuellen Rückfallebenen gibt es? Erst solche Fragen machen Risiken greifbar.

Hilfreich ist dabei die Kopplung von Risikobewertung und Architekturprüfung. Themen wie Zonierung, conduits, Einbahnkommunikation, Firewall-Regeln, Protokollfreigaben und Monitoring dürfen nicht separat betrachtet werden. Wer tiefer in strukturierte OT-Risikobetrachtung einsteigen will, findet ergänzende Perspektiven in Ot Risikomanagement Industrie Sicherheit, Ot Risikomanagement Fehler und Kritis Sicherheit Checkliste.

Ein weiterer Fehler ist die Annahme, dass dokumentierte Architektur gleich gelebte Architektur ist. In vielen Anlagen stimmen Netzpläne, VLAN-Zuordnungen, Firewall-Regeln und tatsächliche Kommunikationsbeziehungen nicht mehr überein. Änderungen wurden im Störungsfall schnell umgesetzt, aber nie sauber zurückgeführt. Genau diese Drift erzeugt blinde Flecken, die in Audits oft unentdeckt bleiben, bei Vorfällen aber sofort relevant werden.

Wenn in KRITIS schnell wirksame Sicherheitsverbesserungen umgesetzt werden sollen, liefern drei Bereiche den größten Effekt: saubere Netzwerksegmentierung, kontrollierte Fernwartung und belastbares Identitätsmanagement. Diese drei Hebel reduzieren nicht jede Schwachstelle, aber sie begrenzen Reichweite, Geschwindigkeit und Wirkung eines Angriffs.

Segmentierung wird oft auf VLANs reduziert. Das reicht nicht. Ein VLAN ohne restriktive Kommunikationskontrolle ist keine Sicherheitsgrenze. In KRITIS müssen Zonen nach Funktion und Kritikalität definiert werden: Feldgeräte, Steuerungsebene, HMI/SCADA, Historian, Engineering, DMZ, Fernwartung, Office-IT, externe Partner. Danach werden erlaubte Kommunikationsbeziehungen explizit freigegeben und alles andere blockiert. Besonders wichtig ist die Trennung von Engineering-Systemen und operativer Laufzeitkommunikation.

Fernwartung ist in fast jeder KRITIS-Umgebung notwendig, aber sie darf nicht dauerhaft offen sein. Sichere Fernwartung bedeutet: zeitlich begrenzte Freigabe, personengebundene Konten, starke Mehrfaktor-Authentisierung, Protokollierung, Sitzungsaufzeichnung, Freigabe durch den Betrieb und idealerweise technische Begrenzung auf definierte Zielsysteme. Ein pauschaler VPN-Tunnel mit breitem Netz-Zugriff ist ein wiederkehrendes Hochrisiko.

Identitäten sind in OT oft das schwächste Glied. Gemeinsame Administrator-Konten, lokale Standardpasswörter, nicht dokumentierte Service-Accounts und fehlende Trennung zwischen Bedienung, Wartung und Engineering schaffen ideale Bedingungen für Missbrauch. In KRITIS muss nachvollziehbar sein, wer welche Änderung wann und mit welchem Zweck durchgeführt hat. Ohne diese Nachvollziehbarkeit wird Incident Response unnötig schwer.

Ein praxistauglicher Mindeststandard umfasst:

• harte Segmentierung zwischen Office-IT, OT-DMZ, Engineering und Prozessnetz
• Jump-Host-Prinzip statt direkter Fernzugriffe auf HMI, PLC oder SCADA
• personalisierte Konten statt Shared Accounts für Wartung und Engineering
• temporäre Freigaben mit Ticketbezug und dokumentiertem Änderungszweck
• Firewall-Regeln auf Basis realer Kommunikationsbedarfe statt pauschaler Any-Any-Ausnahmen

Gerade industrielle Firewalls werden häufig falsch eingesetzt. Viele Installationen filtern nur grob nach IP und Port, obwohl Protokollverständnis, Richtungssteuerung und Regelhygiene entscheidend wären. Wer Segmentierung ernsthaft verbessern will, sollte Industrielle Firewalls Industrie Angriffe, Industrielle Firewalls Strategie und Ot Netzwerk Segmentierung Risiken gemeinsam betrachten.

Ein sauberer Workflow sieht so aus: zuerst Kommunikationsaufnahme, dann Kritikalitätsbewertung, danach Zonendesign, anschließend Regeldefinition im Review mit Betrieb und Leittechnik, dann Test in Wartungsfenstern und erst danach produktive Aktivierung. Wer direkt filtert, ohne Kommunikationsrealität zu kennen, erzeugt Störungen. Wer gar nicht filtert, akzeptiert unnötige Seitwärtsbewegung im Angriffsfall.

In KRITIS ist die Protokollebene entscheidend, weil dort nicht nur Daten transportiert werden, sondern Prozessbedeutung. Ein Paket ist nicht einfach Traffic. Es kann ein Schreibbefehl auf ein Register sein, ein Zeitabgleich, ein Download einer Logik, eine Änderung eines Sollwerts oder eine Statusabfrage mit operativer Relevanz. Genau deshalb reicht klassische Netzsicht nicht aus.

Modbus/TCP ist das bekannteste Beispiel für funktionale Einfachheit mit hohem Missbrauchspotenzial. Viele Implementierungen kennen weder Authentisierung noch Integritätsschutz. Wenn ein System Schreibzugriffe akzeptiert und das Netz nicht sauber segmentiert ist, kann ein Angreifer Registerwerte verändern, Ausgänge beeinflussen oder Prozesszustände verfälschen. Besonders kritisch wird es, wenn HMI und PLC denselben Kommunikationspfad nutzen und keine Trennung zwischen Lese- und Schreiboperationen existiert.

DNP3 ist in Energie- und Versorgungsumgebungen weit verbreitet. Auch hier liegt das Risiko nicht nur in fehlender Kryptografie älterer Installationen, sondern in der betrieblichen Rolle des Protokolls. Telemetrie, Steuerbefehle und Zustandsmeldungen sind für Netzführung und Betrieb essenziell. Werden diese Daten manipuliert oder verzögert, entstehen Fehlentscheidungen im Leitstand. Ergänzende technische Hintergründe finden sich in Dnp3 Sicherheit Risiken und Dnp3 Sicherheit Strategie.

OPC UA wird oft als sichere Alternative dargestellt. Das ist nur teilweise richtig. Das Protokoll bietet Sicherheitsmechanismen, aber deren Wirksamkeit hängt vollständig von der Implementierung ab. Unsichere Zertifikatsverteilung, akzeptierte Self-Signed-Zertifikate ohne Prüfung, veraltete Cipher Suites oder falsch konfigurierte Security Policies können den Schutz massiv schwächen. In gemischten Umgebungen mit Altanlagen wird zudem häufig auf unsichere Kompatibilitätsmodi zurückgefallen. Wer OPC UA einsetzt, sollte Opc Ua Security Ics Sicherheit und Opc Ua Security Best Practices nicht isoliert, sondern im Kontext der Gesamtarchitektur betrachten.

Ein praxisnaher Prüfpunkt ist immer die Frage: Welche Befehle sind technisch möglich, welche davon betrieblich notwendig und welche davon aktuell unkontrolliert erreichbar? Viele Umgebungen erlauben deutlich mehr als nötig. Lesende Verbindungen könnten schreibend sein, Engineering-Protokolle sind dauerhaft offen, Diagnosefunktionen bleiben im Produktivbetrieb aktiv und Protokollwandler übernehmen unbemerkt Vertrauensstellungen zwischen Segmenten.

Auch Protokollkonverter und Gateways sind oft unterschätzte Risiken. Sie übersetzen nicht nur Daten, sondern häufig auch Sicherheitsannahmen. Ein serielles Altgerät hinter einem Ethernet-Gateway wird plötzlich aus einem größeren Netz erreichbar. Wenn dabei keine zusätzliche Zugriffskontrolle greift, entsteht aus einer ursprünglich lokal begrenzten Funktion ein netzweit missbrauchbarer Pfad.

Beispiel für eine risikoorientierte Protokollprüfung:

1. Kommunikationspartner identifizieren
2. Nur lesende vs. schreibende Funktionen trennen
3. Engineering- und Diagnosefunktionen separat erfassen
4. Erreichbarkeit über Zonen und Firewalls prüfen
5. Authentisierung, Integrität und Logging bewerten
6. Prozessauswirkung pro Befehlsklasse dokumentieren

Diese Art der Prüfung ist deutlich wertvoller als eine reine Portliste, weil sie technische Möglichkeit und betriebliche Wirkung zusammenführt.

Viele KRITIS-Organisationen haben Logs, aber keine echte Sichtbarkeit. Das Problem liegt selten in fehlenden Daten, sondern in fehlendem Kontext. Ein klassisches SIEM aus der IT erkennt vielleicht fehlgeschlagene Logins oder Malware-Indikatoren, aber nicht zwingend eine ungewöhnliche Schreiboperation auf einem SPS-Register, eine neue Engineering-Session außerhalb des Wartungsfensters oder eine veränderte Kommunikationsbeziehung zwischen HMI und Controller.

OT-Monitoring muss deshalb passiv, protokollbewusst und prozessnah sein. Passiv, weil aktive Scans oder aggressive Abfragen Systeme stören können. Protokollbewusst, weil reine NetFlow-Daten oft nicht reichen. Prozessnah, weil nur die Verbindung zwischen Kommunikationsereignis und Anlagenzustand eine belastbare Bewertung ermöglicht. Ein Alarm ist erst dann relevant, wenn klar ist, ob er Diagnoseverkehr, legitime Wartung oder eine unautorisierte Änderung repräsentiert.

Besonders wertvoll sind Baselines. In stabilen OT-Umgebungen wiederholen sich Kommunikationsmuster stark. Genau das macht Abweichungen erkennbar: neue Kommunikationspartner, neue Funktionscodes, ungewöhnliche Schreibzugriffe, veränderte Polling-Raten, neue Firmware-Downloads, Zeitabweichungen oder Engineering-Aktivität außerhalb definierter Fenster. Solche Muster sind oft aussagekräftiger als klassische IOC-Listen.

Ein häufiger Fehler ist die Einführung von Monitoring ohne Betriebsabstimmung. Dann entstehen viele Alarme, aber keine verwertbaren Entscheidungen. Gute Erkennung in KRITIS braucht abgestimmte Use Cases: Welche Ereignisse sind wirklich kritisch? Wer bewertet sie? Welche Eskalationswege gelten? Welche Maßnahmen sind im laufenden Betrieb zulässig? Ohne diese Fragen bleibt Monitoring ein Dashboard ohne Wirkung.

Praxisnah ist die Kombination aus Netzwerktransparenz, Asset-Kontext und Change-Korrelation. Wenn ein neues Kommunikationsmuster erkannt wird, muss sofort sichtbar sein, ob dafür ein genehmigtes Wartungsfenster existiert, welcher Dienstleister aktiv ist und welche Systeme betroffen sind. Genau hier liefern Ot Monitoring Beispiele, Ot Monitoring Schutz und Ot Anomalie Erkennung Ics wertvolle Ergänzungen.

Ein belastbarer Monitoring-Workflow in KRITIS umfasst mindestens Asset-Erkennung, Kommunikationsbaseline, Protokollanalyse, Alarmpriorisierung nach Prozessnähe und Rückkopplung in Incident Response. Besonders wichtig ist die Trennung zwischen Beobachtung und Eingriff. Nicht jedes verdächtige Ereignis darf sofort technisch blockiert werden. In manchen Anlagen ist kontrolliertes Beobachten zunächst sicherer als eine spontane Isolation, die den Prozess gefährden könnte.

Gute Erkennung bedeutet daher nicht maximale Lautstärke, sondern präzise, betriebsverträgliche Sichtbarkeit. Wer jede Abweichung gleich behandelt, überlastet das Team. Wer nur auf Malware wartet, übersieht die meisten OT-spezifischen Vorfälle.

Incident Response in KRITIS unterscheidet sich fundamental von IT-Standardvorgehen. Ein kompromittierter Office-Client kann oft sofort isoliert werden. Eine Engineering-Station, ein HMI oder ein Kommunikationsserver in einer laufenden Anlage dagegen nicht immer. Die falsche Reaktion kann den Schaden vergrößern, Alarme auslösen, Bedienbarkeit verlieren lassen oder einen unsicheren Prozesszustand erzeugen.

Deshalb beginnt OT-Incident-Response nicht mit dem reflexhaften Ziehen des Netzwerkkabels, sondern mit Lagebewertung. Welche Systeme sind betroffen? Welche Rolle haben sie im Prozess? Gibt es Redundanzen? Welche manuellen Betriebsmodi stehen zur Verfügung? Welche Safety-Funktionen bleiben aktiv? Welche Kommunikationsbeziehungen dürfen keinesfalls abrupt unterbrochen werden? Erst danach wird entschieden, ob segmentiert, beobachtet, umgeleitet oder isoliert wird.

Ein praxistauglicher Ablauf trennt zwischen technischer Kompromittierung und betrieblicher Gefährdung. Nicht jeder Malware-Fund auf einem OT-nahen Windows-System bedeutet sofortige Prozessgefahr. Umgekehrt kann eine scheinbar kleine Konfigurationsänderung an einem Kommunikationsserver hochkritisch sein, wenn dadurch Steuerbefehle fehlgeleitet werden. Incident Response muss deshalb immer mit Betrieb und Leittechnik abgestimmt sein.

Wichtige Maßnahmen sind vorbereitete Notfallpfade: bekannte Kontaktketten, dokumentierte Abschaltkriterien, definierte Freigaben für Netztrennung, Offline-Backups von Projektständen, verifizierte Wiederanlaufprozeduren und klare Regeln für Dienstleisterzugriffe im Vorfall. Ohne diese Vorbereitung wird im Ernstfall improvisiert, und Improvisation ist in KRITIS fast immer teuer.

Forensik spielt ebenfalls eine besondere Rolle. Flüchtige Daten, Engineering-Projektstände, Controller-Konfigurationen, Firewall-Regeln, Historian-Daten und HMI-Änderungen müssen gesichert werden, ohne den Betrieb unnötig zu stören. Wer nur klassische Windows-Artefakte sammelt, verpasst oft die entscheidenden OT-Spuren. Ergänzende Perspektiven bieten Ot Incident Response Ics Sicherheit, Ot Forensik Ics und Ot Forensik Tools.

Ein häufiger Fehler ist die zu späte Einbindung des Betriebs. Wenn Security-Teams erst nach technischer Analyse mit der Leitwarte sprechen, fehlen oft entscheidende Hinweise: ungewöhnliche Prozessschwankungen, manuelle Eingriffe, Wartungsaktivitäten oder bekannte Störungen. In KRITIS ist die Leitwarte keine nachgelagerte Informationsquelle, sondern Teil der Primärsensorik.

Minimaler OT-IR-Entscheidungsablauf:

- Prozesskritikalität des betroffenen Systems bestimmen
- aktuelle Betriebsart und Redundanzen prüfen
- mögliche Auswirkungen einer Isolation bewerten
- forensische Sicherung priorisieren
- nur abgestimmte Eindämmungsmaßnahmen umsetzen
- Wiederanlauf mit verifizierten Ständen vorbereiten

Diese Reihenfolge verhindert, dass technische Sauberkeit über betriebliche Sicherheit gestellt wird.

Ein realistisches Energieszenario beginnt nicht mit einem direkten Angriff auf Schutztechnik, sondern mit einem kompromittierten Fernwartungszugang eines Dienstleisters. Über diesen Zugang wird ein Jump Host erreicht, von dort eine Engineering-Station, auf der Projektdateien und Zugangsdaten lokal gespeichert sind. Der Angreifer verändert keine Logik sofort, sondern beobachtet zunächst Kommunikationsmuster, Betriebszeiten und Reaktionsabläufe. Erst später werden gezielt Parameter oder Kommunikationspfade manipuliert. Die eigentliche Stärke des Angriffs liegt in der Geduld und im Missbrauch legitimer Werkzeuge.

Im Wassersektor sind häufig verteilte Standorte, Außenstationen und heterogene Kommunikationswege das Problem. Alte RTUs, Funk- oder Mobilfunkanbindungen, gemeinsam genutzte Wartungskonten und begrenzte Vor-Ort-Präsenz schaffen ideale Bedingungen für lange unentdeckte Kompromittierungen. Besonders kritisch sind Manipulationen an Messwerten und Alarmierungen. Wenn Füllstände, Druckwerte oder Dosierparameter verfälscht werden, kann der Betrieb zunächst plausibel wirken, obwohl der Prozess bereits aus dem sicheren Bereich driftet. Vertiefende technische Beispiele finden sich in Kritis Sicherheit Wasser Angriffe, Plc Security Wasser und Scada Security Wasser Sicherheit.

In der Produktion ist die größte Gefahr oft die Kombination aus Zeitdruck und Änderungsroutine. Ein ungeplanter Stillstand führt dazu, dass temporäre Freigaben dauerhaft bestehen bleiben. Eine Firewall-Regel für den Dienstleister wird nicht zurückgebaut, ein Engineering-Laptop bleibt im Produktionsnetz, ein Testkonto bleibt aktiv. Wochen später nutzt ein Angreifer genau diese Reste. Der Vorfall wirkt dann wie ein externer Angriff, ist aber in Wahrheit das Ergebnis unkontrollierter Betriebsänderungen.

Auch SCADA-Systeme werden häufig überschätzt oder unterschätzt. Überschätzt, weil ihnen zentrale Kontrolle zugeschrieben wird, obwohl viele kritische Funktionen dezentral in PLCs oder RTUs liegen. Unterschätzt, weil Manipulationen an Visualisierung, Alarmierung und Bedienlogik enorme Wirkung haben können, selbst wenn die Feldlogik unverändert bleibt. Wer Bediener täuscht, beeinflusst Entscheidungen. Dazu passen Kritis Sicherheit Scada Sicherheit und Ot Security Scada Angriffe.

Ein weiteres Praxisproblem ist die Wiederherstellung. Viele Organisationen haben Backups, aber keine verifizierten Restore-Pfade für OT-spezifische Komponenten. Projektstände sind unvollständig, Firmware-Versionen nicht dokumentiert, Lizenzabhängigkeiten unbekannt, Hardware-Revisionen nicht kompatibel. Im Vorfall zeigt sich dann, dass Wiederanlauf nicht an fehlenden Daten scheitert, sondern an fehlender Integrationsfähigkeit. KRITIS-Sicherheit endet deshalb nicht bei Prävention, sondern umfasst immer auch belastbare Recovery-Fähigkeit.

KRITIS-Sicherheit scheitert selten an fehlenden Einzelmaßnahmen. Sie scheitert an unsauberen Abläufen. Ein sauberer Workflow reduziert Risiken nicht nur technisch, sondern organisatorisch. Er sorgt dafür, dass Änderungen nachvollziehbar, testbar und betrieblich tragfähig sind. Genau das ist in OT wichtiger als Aktionismus.

Der erste Schritt ist immer die belastbare Bestandsaufnahme. Dazu gehören Assets, Kommunikationsbeziehungen, Verantwortlichkeiten, Wartungswege, Protokolle, Abhängigkeiten und Wiederherstellungsinformationen. Ohne diese Basis ist jede Härtung blind. Danach folgt die Kritikalitätsbewertung: Welche Systeme beeinflussen Sicherheit, Verfügbarkeit oder Prozessqualität direkt? Welche Systeme sind nur unterstützend? Welche Übergänge verbinden Vertrauenszonen?

Erst auf dieser Grundlage werden Maßnahmen priorisiert. In vielen Umgebungen ist es sinnvoller, zuerst Fernwartung zu kontrollieren und Engineering-Systeme zu härten, statt sofort jedes Altgerät patchen zu wollen. Ebenso bringt eine saubere OT-DMZ oft mehr als punktuelle Endpoint-Maßnahmen auf einzelnen HMI-Rechnern. Priorisierung bedeutet, die größten Angriffshebel zuerst zu schließen.

Ein praxistauglicher Workflow besteht aus klaren Phasen:

• Transparenz schaffen: Assets, Kommunikationspfade, Verantwortliche und Wartungszugänge erfassen
• Risiken szenariobasiert bewerten: Angriffspfad, Prozessnähe, Auswirkung und Wiederherstellbarkeit zusammenführen
• Architektur härten: Segmentierung, Firewall-Regeln, Jump Hosts, Identitäten und Protokollfreigaben bereinigen
• Erkennung aufbauen: Baselines, Alarmregeln, Change-Korrelation und Eskalationswege definieren
• Wiederherstellung üben: Restore, Projektstände, Ersatzhardware und manuelle Betriebsmodi verifizieren

Wichtig ist die Reihenfolge. Wer ohne Transparenz segmentiert, blockiert produktive Kommunikation. Wer ohne Wiederherstellungsplanung härtet, riskiert lange Ausfälle bei Fehlkonfigurationen. Wer ohne Betriebsbeteiligung überwacht, erzeugt Alarmmüdigkeit. Gute KRITIS-Workflows sind deshalb interdisziplinär: OT, IT, Leittechnik, Instandhaltung, Netzwerktechnik, Safety und Management müssen an denselben Entscheidungen beteiligt sein.

Für die operative Umsetzung helfen strukturierte Referenzen wie Kritis Sicherheit Guide, Kritis Sicherheit Tools, Ot Sicherheit Checkliste und Ics Security Best Practices. Entscheidend bleibt jedoch, dass jedes Werkzeug und jede Maßnahme in den realen Betriebsablauf eingebettet wird.

Ein sauberer Workflow endet nicht mit der Implementierung. Er braucht Review-Zyklen. Neue Anlagen, neue Dienstleister, neue IIoT-Sensorik, neue Fernwartungsanforderungen und neue regulatorische Vorgaben verändern die Risikolage laufend. KRITIS-Sicherheit ist deshalb kein Projekt mit Enddatum, sondern ein kontrollierter Betriebsprozess.

Compliance kann ein Mindestniveau erzwingen, aber sie ersetzt keine belastbare Sicherheitsfähigkeit. Reife KRITIS-Sicherheit zeigt sich daran, wie gut eine Organisation reale Störungen verhindert, erkennt, begrenzt und übersteht. Das bedeutet: bekannte Kommunikationspfade, kontrollierte Änderungen, nachvollziehbare Identitäten, getestete Wiederherstellung und ein gemeinsames Lageverständnis zwischen Security und Betrieb.

Ein reifer Betreiber kennt nicht nur seine kritischen Assets, sondern auch deren Vertrauenskette. Welche Engineering-Station darf welche SPS programmieren? Welche HMI darf welche Tags schreiben? Welche Firewall-Regel existiert aus welchem Grund? Welche Dienstleisterkonten sind aktiv? Welche Projektstände sind freigegeben? Diese Fragen müssen ohne langes Suchen beantwortbar sein. Wenn das nicht möglich ist, liegt das Risiko nicht nur in Technik, sondern in fehlender Steuerbarkeit.

Ebenso wichtig ist die Fähigkeit, zwischen normaler Betriebsabweichung und Sicherheitsvorfall zu unterscheiden. In OT gibt es viele legitime Unregelmäßigkeiten: Wartungsfenster, Lastwechsel, Umschaltungen, Redundanztests, Firmware-Aktionen. Reife Sicherheit erkennt, wann eine Abweichung erwartbar ist und wann sie auf Missbrauch hindeutet. Dafür braucht es nicht nur Tools, sondern Erfahrungswissen, dokumentierte Baselines und saubere Kommunikation.

Ein weiterer Reifeindikator ist die Qualität von Übungen. Tabletop-Übungen, Wiederanlauftests, Fernwartungsreviews und kontrollierte Architekturprüfungen zeigen schnell, ob Prozesse tragfähig sind. Wenn im Übungsszenario niemand sicher sagen kann, welche Systeme bei einer Kompromittierung isoliert werden dürfen, ist das ein ernstes Warnsignal. Dasselbe gilt, wenn Projektstände nicht eindeutig einem Anlagenzustand zugeordnet werden können.

Wer den Reifegrad erhöhen will, sollte nicht nur mehr Technik einkaufen, sondern die Grunddisziplinen stärken: Asset-Qualität, Änderungsmanagement, Segmentierung, Monitoring, Forensikfähigkeit und Wiederherstellungsroutine. Ergänzend helfen vertiefende Inhalte wie Ot Sicherheit Fortgeschritten, Ot Security Strategie und Kritis Sicherheit Abwehr.

Am Ende trennt robuste KRITIS-Sicherheit von bloßer Pflichterfüllung vor allem eines: die Fähigkeit, technische Details mit Prozessrealität zu verbinden. Wer nur Systeme schützt, aber den Betrieb nicht versteht, bleibt angreifbar. Wer nur den Betrieb kennt, aber technische Angriffspfade ignoriert, ebenfalls. Erst die Verbindung beider Sichtweisen schafft echte Widerstandsfähigkeit.