OT/ICS Industrial Security: Schutzkonzepte für Industrieanlagen und KRITIS

Operational Technology (OT) bezeichnet Hard- und Software, die physische Geräte, Prozesse und Infrastrukturen direkt steuert und überwacht. OT-Systeme wurden für Zuverlässigkeit und langes Leben entworfen, nicht für Cybersicherheit: PLCs mit 20-jähriger Laufzeit, proprietäre Protokolle ohne Authentifizierung, Windows-XP-HMIs die nicht mehr gepatcht werden können. Gleichzeitig wächst die Vernetzung von OT und IT (Industrie 4.0) und damit die Angriffsfläche rapide. Stuxnet, Triton und die Ukraine-Angriffe beweisen: kritische Infrastrukturen sind reale Angriffsziele mit physischen Konsequenzen.

OT vs. IT: Grundlegende Unterschiede

Die klassische IT-Sicherheit priorisiert die CIA-Triad (Confidentiality, Integrity, Availability) in dieser Reihenfolge. OT-Sicherheit dreht diese Prioritäten um: Verfügbarkeit kommt zuerst, da Ausfälle Leben kosten oder Umweltkatastrophen verursachen können. Weitere Unterschiede:

Merkmal	IT-Sicherheit	OT-Sicherheit
Priorität	CIA-Triad	AIC-Triad (Verfügbarkeit zuerst)
Patches	schnell möglich	Maintenance-Fenster, Lieferanten-Approval
Lifecycle	3-5 Jahre	15-30+ Jahre
Downtime	tolerierbar	kann Leben kosten / Umweltkatastrophe
Protokolle	TCP/IP-Standard	Modbus, DNP3, OPC-UA, Profinet, EtherNet/IP
Updates	automatisch	manuell, getestet, oft nie
Isolation	manchmal	historisch air-gapped, aber zunehmend IT-vernetzt

OT-Komponentenklassen: OT ist der Oberbegriff für Technologie die physische Prozesse steuert (umfasst ICS, SCADA, DCS, PLC, RTU, HMI, Safety Systems). ICS (Industrial Control Systems) ist die Kategorie der Steuerungssysteme mit Untertypen SCADA, DCS und PLC-basierten Systemen. SCADA (Supervisory Control and Data Acquisition) überwacht und steuert verteilte Anlagen wie Stromnetze, Wasserwerke und Pipelines. PLCs (Programmable Logic Controller) sind Industrierechner für diskrete Steuerung (Siemens S7, Allen-Bradley, Schneider Modicon). Safety Instrumented Systems (SIS) sind physische Sicherheitssysteme für Notabschaltungen - TRITON zielte gezielt auf SIS-Systeme.

Bekannteste OT-Angriffe (Fallstudien)

Stuxnet (2010) war das erste bekannte OT-Cyberweapon und zielte auf die iranische Urananreicherungsanlage in Natanz. Der Angriff nutzte USB-Sticks als Einstiegspunkt, infizierte Siemens Step-7-PLC-Programmiersoftware und manipulierte PLCs für Zentrifugen so, dass sie mit falschen Drehzahlen liefen und physisch beschädigt wurden - während das SCADA-System normale Werte anzeigte. Lektion: Air-Gap allein schützt nicht; Software-Integrität ist kritisch.

TRITON/TRISIS (2017) griff ein Safety Instrumented System einer petrochemischen Anlage in Saudi-Arabien an mit dem Ziel, das SIS zum Scheitern zu bringen und damit physische Explosionen zu ermöglichen. Der Angriff wurde zufällig entdeckt, als das SIS den Fail-Safe-Mode auslöste. Lektion: Safety-Systeme sind aktive Angriffsziele und brauchen expliziten Schutz.

Industroyer/Crashoverride (2016) zielte auf ukrainische Stromverteilungs-SCADA und sprach IEC-Industrieprotokolle (61850, 60870-5-104, 60870-5-101) nativ. Leistungsschalter wurden ferngesteuert, was in Kiew zu Stromausfällen führte. Lektion: Industrieprotokolle haben keine inhärente Authentifizierung.

Colonial Pipeline (2021): Ransomware im IT-Netz führte zur vorsorglich-freiwilligen OT-Abschaltung. Einstiegspunkt waren kompromittierte VPN-Credentials.

Häufige heutige Angriffsvektoren sind der kompromittierte IT/OT-Übergang (Fernwartungs-VPN für Maschinenhersteller, Shared-Credentials, IT-Active-Directory mit Domänen-Trust), Supply-Chain-Angriffe über Lieferanten (USB-Service-Laptops, Remote-Service ohne MFA), Legacy-Protokoll-Schwachstellen (Modbus ohne Auth, DNP3 ohne Secure Authentication) sowie schlecht gesicherte HMI/SCADA-Webinterfaces mit Standard-Credentials oder ungepatchten Schwachstellen.

Industrielle Protokolle und ihre Sicherheitseigenschaften

OT-Protokolle wurden für Reliabilität entworfen, nicht für Sicherheit:

Modbus (1979): Transport über TCP (Port 502) oder Seriell. Keine Authentifizierung, keine Verschlüsselung - jeder im Netz kann Befehle senden. Kritische Funktionscodes: FC 05 (Single Coil schreiben = Aktor EIN/AUS), FC 06, FC 15, FC 16. Schutz: per Firewall nur erlaubte Funktionscodes whitelisten.

DNP3 (1993): Eingesetzt in Stromnetzen und Wasserwerken für SCADA-zu-RTU-Kommunikation. Basis-DNP3 hat keine Authentifizierung; DNP3 Secure Authentication v5 ergänzt HMAC, ist aber in vielen Implementierungen noch nicht aktiv. Industroyer nutzte ein DNP3-Modul für den Ukraine-Angriff.

IEC 60870-5-104: Europäisches Stromnetz-Protokoll ähnlich DNP3. Keine Authentifizierung in der Basisspezifikation; IEC 62351 ergänzt Security-Funktionen.

OPC UA: TCP (Port 4840) oder HTTPS mit integrierter TLS-Sicherheit, Authentifizierung und Signierung. OPC UA ist die empfohlene Wahl für neue OT-Implementierungen als sichere IT/OT-Brücke.

Schlussfolgerung: Legacy-Protokolle (Modbus, DNP3 ohne SAv5) haben keine inhärente Sicherheit - Schutz muss netzwerkseitig durch Firewall, IDS und Segmentierung erzwungen werden.

Purdue-Referenzmodell und IEC 62443

Das ISA/IEC-62443-Purdue-Referenzmodell schichtet OT-Netze in Levels mit strikten Kommunikationsgrenzen:

• Level 5 - Enterprise Network (IT): ERP, Office-Systeme, E-Mail, Internet, Active Directory
• Firewall / DMZ
• Level 4 - Site Business Planning: Produktionsplanung, MES, Datenhistorianer, Data Diode
• Firewall
• Level 3.5 - Industrial DMZ: Data-Diodes, Patch-Management-Server, Remote-Access-Jump-Hosts
• Firewall
• Level 3 - Site Manufacturing Operations: SCADA-Server, Historian, Engineering Workstations
• Firewall
• Level 2 - Area Supervisory Control: DCS Controllers, HMIs, Local Historian
• Level 1 - Basic Control: PLCs, RTUs, Flow Controllers
• Level 0 - Physical Process: Sensoren, Aktoren, Ventile, Motoren

Das Sicherheitsprinzip ist eindeutig: Level 5 darf Level 1 nicht direkt erreichen. Die Industrial DMZ dient als Puffer - nur definierte, kontrollierte Kommunikation ist erlaubt. Data Diodes erzwingen dort, wo möglich, physisch nur eine Kommunikationsrichtung.

IEC 62443 - Standard für Industrial Security

Die IEC-62443-Normenfamilie definiert Security-Level (SL) für OT-Systeme:

• SL 0: Kein spezifischer Schutz
• SL 1: Schutz gegen unbeabsichtigte Fehler und Fehlbedienung
• SL 2: Schutz gegen einfache absichtliche Angriffe mit normalen Mitteln
• SL 3: Schutz gegen sophistizierte Angriffe mit IIoT-Fachkenntnissen
• SL 4: Schutz gegen State-Level-Angriffe (Stuxnet-Niveau)

Der Target-SL wird durch Risikoanalyse bestimmt: kritische KRITIS-Anlagen erfordern SL 3-4, Standard-Produktion SL 2, nicht-kritische Automationszellen SL 1. IEC 62443-4-1 regelt den Secure Development Lifecycle für ICS-Komponentenhersteller.

Zone und Conduit Modell

IEC 62443-3-3 definiert Zones (logische Gruppierungen von Assets mit gleichem Schutzbedarf) und Conduits (Kommunikationswege zwischen Zones). Jeder Conduit ist eine Angriffsfläche und muss durch Firewall, Data Diode, VPN oder DMZ kontrolliert werden.

Der Zone-Definition-Prozess umfasst: Asset-Inventarisierung, Kommunikationsbeziehungen kartieren, ähnliche Assets gruppieren, Zonen-Boundaries definieren, Conduits identifizieren und dokumentieren, Security Level pro Zone per Risikoanalyse festlegen.

Beispiel Wasserwerk: Zone 1 (IT-Büronetz, SL 1) ist über eine DMZ-Firewall mit Zone 2 (SCADA-Netz, SL 2) verbunden. Innerhalb des SCADA-Netzes sind Leitwarte, Pumpensteuerung (SL 3) und Chlorierung (SL 4, Safety-kritisch) als separate Sub-Zonen mit Whitelist-Firewall-Regeln oder Data Diodes abgegrenzt.

Segmentierungsarchitektur

Physische Trennung (Air Gap): Für ultrahohe Sicherheitsanforderungen (SIS, militärisch). Datentransfer nur über USB-Sticks (selbst Stuxnet-Vektor!) oder Laptops. Schutz: USB-Blocker und USB-Desinfektion.

Data Diodes: Hardware-Bauteile die durch optische Übertragung ohne Rückkanal physisch erzwingen, dass Daten nur in eine Richtung fließen. Anbieter: Owl Cyber Defense, Waterfall Security, Advenica. Typischer Use Case: OT-Historian zu IT-Analytics ohne Rückkanal.

Industrial DMZ: Intermediäre Zone zwischen IT-Netz (Level 4) und OT-Netz (Level 3). Erlaubte Inhalte: Antivirus-Update-Server, Patch-Management-Server, Remote-Access-Jump-Host, Read-only-Domain-Controller, Historian-Replikation. Nicht erlaubt: Internet-Zugang, E-Mail-Clients im OT-Netz, Domain-Trust zwischen IT-AD und OT-AD.

Mikrosegmentierung innerhalb OT: PLC-Zone, HMI-Zone, Engineering-Zone und Safety-Zone müssen getrennt sein. Die Safety-Zone ist physisch isoliert ohne IP-Verbindung zu anderen Zonen.

Asset Management für OT-Systeme

OT-Asset-Inventar ist schwieriger als IT-Inventar: Es gibt keine Standard-Management-Schnittstellen, aktive Scans können OT-Systeme beeinträchtigen oder zum Absturz bringen, und Systeme sind oft 15-30 Jahre alt mit undokumentierten Konfigurationen.

Passive Netzwerkanalyse (bevorzugte Methode): Nozomi Networks Guardian und Claroty erkennen über SPAN-Port-Sensoren automatisch Gerätetyp, Hersteller, Firmware und Protokoll und erstellen eine Kommunikationsmatrix. Microsoft Defender for IoT bietet agentenlose Discovery mit nativer Sentinel-Integration.

Aktive Abfrage darf nur mit Hersteller-Freigabe und in Wartungsfenstern erfolgen. Generisches NMAP darf niemals in OT-Netzen eingesetzt werden - S7-CPUs können dabei abstürzen.

Mindestfelder der Asset-Datenbank: Hersteller und Modell, Firmware-Version, IP- und MAC-Adresse, VLAN/Zone, physischer Standort, Funktion (was steuert dieses Gerät?), Prozess-Kritikalität, Kommunikationsmatrix, letztes Firmware-Update, verantwortlicher OT-Engineer sowie aktiver Wartungsvertrag.

OT-Schwachstellenmanagement und Patch-Management

OT-Patches sind aus mehreren Gründen schwierig: Windows XP und CE erhalten keine Patches mehr, PLC-Firmware-Updates erfordern Produktionsstopp, Hersteller-Zertifizierung und Test, und in manchen Anlagen gibt es nur ein Wartungsfenster pro Jahr.

Patch-Priorisierung für OT:

• Kritisch (sofort im nächsten Wartungsfenster): CVSS ≥ 9.0 AND Exploit verfügbar AND Gerät hat Netzwerkzugang, oder bekannte Ausnutzung durch APT-Gruppen laut ICS-CERT-Alert
• Hoch (innerhalb 3 Monate): CVSS 7.0-9.0 AND Gerät ist von außen erreichbar
• Mittel (nächstes geplantes Wartungsfenster): CVSS 4.0-7.0 AND interne Systeme
• Niedrig: CVSS < 4.0 oder interne Systeme ohne Netzwerkzugang

Wenn ein Patch nicht möglich ist, kommen kompensatorische Maßnahmen in Frage: Netzwerksegmentierung der verwundbare Komponente, Virtual Patching durch IPS-Signaturen, Application Whitelisting (McAfee Solidcore, Carbon Black für OT-Windows), erhöhtes Monitoring, Schreibschutz (PLCs in Read-only-Modus) sowie Deaktivierung nicht benötigter Dienste und Ports.

Schwachstellen-Informationsquellen für OT: CISA ICS-CERT Advisories (us-cert.gov/ics), Siemens ProductCERT, Schneider Electric PSIRT, ABB PSIRT sowie NIST NVD.

OT Security Monitoring und SIEM-Integration

OT-Umgebungen haben sehr stabiles, vorhersehbares Verhalten: Ein PLC kommuniziert immer mit dem SCADA-Server, nie direkt mit dem Internet. Dieser Whitelist-Ansatz macht Abweichungen hochverdächtig. Baseline-Zeitraum: 2-4 Wochen normalen Betriebs.

Kritische OT-Events für SIEM-Alerting:

• Neues Gerät im OT-Netz (unbekannte MAC-Adresse)
• Erstmalige Kommunikation zwischen zwei Geräten
• PLC-Konfigurationsänderung außerhalb Wartungsfenster
• Modbus-Schreibbefehl (FC05/06/15/16) von unbekannter Quelle
• Direktverbindung OT zu Internet
• USB-Gerät an HMI angeschlossen

Wichtig: Nur passives Monitoring! Aktive Scans können PLCs zum Absturz bringen.

OT-SIEM-Integration erfolgt über Nozomi Guardian, Claroty oder Microsoft Defender for IoT als Datenquellen, die in Sentinel, Splunk oder QRadar integriert werden.

Incident Response für OT

OT-IR unterscheidet sich fundamental von IT-IR. Das IT-IR-Paradigma "System sofort isolieren/abschalten" kollidiert mit der OT-Realität: Eine Pumpe die bei 2.000 RPM läuft kann nicht sofort gestoppt werden ohne Druckschlag und Rohrbruch zu riskieren. Das OT-IR-Prinzip lautet: Safety first - dann Availability - dann Security.

Das OT-IR-Team muss neben OT-Security-Analysten und Netzwerkspezialisten zwingend einen Process Engineer (versteht physische Konsequenzen von Aktionen!) und einen Safety Engineer (SIS-Expertise) umfassen.

Phase 1 (Erkennung): Erste Frage ist immer: Ist die Anlage physisch sicher? Enthält der Incident physische Sicherheitsrisiken? Nur mit Plant-Manager-Freigabe wird der Produktionsstillstand akzeptiert.

Phase 2 (Bewertung, binnen 1 Stunde): Assets identifizieren ohne zu isolieren, Netzwerk-Captures starten, manuelle Überwachung stärken, OT-Hersteller kontaktieren (Siemens, Rockwell PSIRT). Klären: IT-Incident mit OT-Auswirkung (Ransomware im IT-Netz) oder direkte OT-Kompromittierung?

Phase 3 (Containment, mit Operations-Freigabe): Kompromittierte Kommunikationspfade per Firewall blocken, betroffene Workstations isolieren (NICHT PLCs!), Backup-HMIs bereitstellen. Einfach den Stromstecker ziehen bei laufendem Prozess ist niemals eine Option.

Phase 4 (Forensik, OT-schonend): Passive Forensik bevorzugen. PLC-Memory-Dumps erfordern herstellerspezifische Tools, nicht Standard-IT-Forensik-Tools. OT-Systeme haben oft keine NTP-Synchronisierung - Timestamps sind zu validieren.

Phase 5 (Recovery): PLC-Programme auf Integrität prüfen (Hash-Vergleich), PLC-Firmware aus verifizierten Backups wiederherstellen, Safety-System-Zertifizierung erneuern wenn SIS betroffen, Kommunikationsmatrix validieren und 30 Tage erhöhtes Monitoring.

Phase 6 (Reporting): KRITIS-Meldung ans BSI (24h Frühwarnung bei erheblichem Vorfall), Versicherungs-Dokumentation, Lessons Learned.

Regulatorische Anforderungen

NIS2 betrifft explizit OT-Betreiber in den Sektoren: Energie (Strom, Gas, Öl, Fernwärme), Wasser/Abwasser, digitale Infrastruktur, Gesundheitswesen, Transport und Finanzen.

Wesentliche NIS2-Anforderungen (Art. 21): Risikoanalyse und Sicherheitspolitiken, Incident Handling und Business Continuity, Supply-Chain-Sicherheit, Wirksamkeitsbewertung von Sicherheitsmaßnahmen, Zugangskontrolle, Asset Management, MFA sowie Kryptografie und Verschlüsselung.

Meldepflichten nach BSIG §30: Frühwarnung innerhalb 24h nach Kenntnis, Erstmeldung mit Art, Ausmaß und Auswirkungen binnen 72h, Abschlussbericht mit vollständiger Analyse nach 1 Monat.

BSI IT-Grundschutz-Bausteine für ICS: IND.1 (Allgemeine ICS), IND.2.1 (Speicherprogrammierbare Steuerung), IND.2.2 (Siemens S7), IND.2.3 (Sensoren und Aktoren).

Checkliste kritischer OT-Maßnahmen:

• Netzwerksegmentierung: IT und OT strikt getrennt, Purdue-Modell implementiert
• Asset-Inventar: alle OT-Komponenten erfasst
• Remote-Zugang: MFA + Session-Recording + JIT-Zugang
• Backup PLC-Programme: versioniert gesichert und regelmäßig getestet
• Patch-Management: Prozess definiert mit Risikoanalyse je Patch
• Anomalie-Erkennung: Nozomi, Claroty oder Defender for IoT
• IR-Plan: OT-spezifische Playbooks mit Hersteller-Kontakten
• Lieferanten-Management: Access-Reviews und vertragliche Sicherheitsanforderungen
• Schulung: OT-Operatoren für Social Engineering und Phishing sensibilisiert