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 andere Welt der Operational Technology:

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

OT-Komponentenklassen:

OT (Operational Technology):
  → Oberbegriff für Technologie die physische Prozesse steuert
  → Umfasst: ICS, SCADA, DCS, PLC, RTU, HMI, Safety Systems

ICS (Industrial Control Systems):
  → Kategorie von Steuerungssystemen für industrielle Prozesse
  → Untertypen: SCADA, DCS, PLC-basierte Systeme

SCADA (Supervisory Control and Data Acquisition):
  → Überwachungs- und Steuerungssystem für verteilte Anlagen
  → Beispiele: Stromnetze, Wasserwerke, Pipelines
  → Kommuniziert mit Remote Terminal Units (RTUs) über WAN

DCS (Distributed Control System):
  → Für kontinuierliche Prozesse in einer Anlage
  → Beispiele: Chemiefabriken, Raffinerien, Kraftwerke

PLC (Programmable Logic Controller):
  → Industrierechner für diskrete/sequentielle Steuerung
  → Programmiert in Ladder Logic, Structured Text, FBD (IEC 61131-3)
  → Beispiele: Siemens S7-300/400/1200/1500, Allen-Bradley, Schneider Modicon

RTU (Remote Terminal Unit):
  → Feldgeräte für Remote-SCADA-Kommunikation
  → Oft in abgelegenen Standorten (Pumpstationen, Umspannwerke)
  → Kommuniziert per DNP3, IEC 60870-5-101/104

HMI (Human Machine Interface):
  → Bedienoberfläche für Prozessvisualisierung und Steuerung
  → Läuft oft auf Windows-Systemen mit langer Lebensdauer

SIS (Safety Instrumented System):
  → Physische Sicherheitssysteme (Notabschaltung, Überdruckschutz)
  → Separat von PLC/SCADA (IEC 61511)
  → TRITON-Angriff zielte auf SIS (größtes bekanntes OT-Sicherheitsrisiko!)

EWS (Engineering Workstation):
  → Programmierlaptop für PLCs
  → Historian: Zeitreihendaten-Speicher (OSIsoft PI)

Bekannteste OT-Angriffe (Fallstudien)

Historische OT-Angriffe:

Stuxnet (2010) - Erstes bekanntes OT-Cyberweapon:
  Ziel: Iranische Urananreicherungsanlage (Natanz)
  Methode:
  → USB-Stick als Einstiegspunkt (Siemens Engineering-Workstation)
  → Siemens Step 7 PLC-Programmier-Software infiziert
  → PLCs (Siemens S7-315) für Zentrifugen manipuliert
  → Zentrifugen liefen mit falschen Drehzahlen → physischer Schaden
  → SCADA zeigte NORMALE Werte (Manipulation der Anzeige!)
  Lektion: Air-Gap allein schützt nicht; Software-Integrität kritisch

TRITON/TRISIS (2017) - Safety-System-Angriff:
  Ziel: Petrochemische Anlage (Saudi-Arabien)
  Methode:
  → Triconex Safety Instrumented System (SIS) angegriffen
  → SIS verhindert Anlagenkatastrophen (Explosion, Feuer)
  → Angreifer: SIS zum Scheitern bringen → phys. Explosion ermöglichen
  → Zufällig entdeckt: SIS löste Fail-Safe-Mode aus
  Lektion: Safety-Systeme sind Angriffsziele; expliziter Schutz nötig

Industroyer/Crashoverride (2016) - Ukrainisches Stromnetz:
  Ziel: Ukrainischer Stromverteilung-SCADA
  Methode:
  → IEC 61850, IEC 60870-5-104, IEC 60870-5-101 Protokolle nativ gesprochen
  → Leistungsschalter ferngesteuert → Stromausfall in Kiew
  → Wiper-Komponente: Substation-Workstations zerstört
  Lektion: Industrieprotokolle haben keine inhärente Authentifizierung

Colonial Pipeline (2021):
  → Ransomware im IT-Netz, aber OT-Abschaltung aus Vorsicht
  → Kompromittierte VPN-Credentials als Einstiegspunkt

Häufige heutige Angriffsvektoren:
  1. Kompromittierter IT/OT-Übergang:
     → Fernwartungs-VPN für Maschinenhersteller
     → Shared-Credentials für SCADA-Fernzugriff
     → IT-Active-Directory mit Domänen-Trust zur OT-Umgebung

  2. Supply-Chain (Lieferanten):
     → Software-Updates von Hersteller (analog SolarWinds für OT)
     → USB-Service-Laptops von Technikern
     → Remote-Service-Verbindungen ohne MFA

  3. Legacy-Protokoll-Schwachstellen:
     → Modbus: kein Auth, kein Encryption, keine Integritätsprüfung
     → DNP3: kein Auth (ohne Secure Authentication v5)
     → BACnet (Gebäudeautomation): oft direkt im Internet exponiert

  4. Schlecht gesicherte HMI/SCADA-Webinterfaces:
     → Internet-exponierte SCADA-Web-Oberflächen (Shodan!)
     → Standard-Credentials (admin/admin, root/root)
     → Ungepatchte Web-Schwachstellen (SQL Injection in SCADA-Webinterface!)

Industrielle Protokolle und ihre Sicherheitseigenschaften

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

Modbus (1979):
  Transport: TCP (Port 502) oder Seriell (RS-485)
  Sicherheit: KEINE Authentifizierung, KEINE Verschlüsselung
  Problem: Jeder im Netz kann Befehle an Modbus-Geräte senden
  Funccodes die kritisch sind:
    FC 05: Schreibt Single Coil (Aktor EIN/AUS!)
    FC 06: Schreibt Single Register
    FC 15: Schreibt Multiple Coils
    FC 16: Schreibt Multiple Registers
  Schutz: Whitelist erlaubte Funccodes per Firewall

DNP3 (1993):
  Einsatz: Stromnetze, Wasserwerke (SCADA↔RTU)
  Sicherheit: Basis-DNP3 = keine Auth; DNP3 Secure Authentication v5 = HMAC
  Problem: Viele Implementierungen noch ohne SAv5
  Angriff: Industroyer nutzte DNP3-Modul gegen ukrainisches Stromnetz

IEC 60870-5-104:
  Einsatz: Europäisches Stromnetz (ähnlich DNP3, TCP/IP)
  Sicherheit: Kein Authentication in Basisspezifikation
  Erweiterung: IEC 62351 (Security für IEC 60870-5/61850)

Profinet (Siemens):
  Transport: Ethernet Layer 2 oder UDP
  Sicherheit: optional (Profinet Security Level 2 ab 2022)
  Stärke: industrielle Echtzeit-Anforderungen

EtherNet/IP (Rockwell/Allen-Bradley):
  Transport: TCP/UDP
  Sicherheit: optional seit CIP Security (2017)
  Stärke: IT-Netzwerk-kompatibel

OPC UA (Unified Architecture):
  Transport: TCP (Port 4840) oder HTTPS
  Sicherheit: integriert! TLS, Authentifizierung, Signierung
  Rolle: "sichere" IT/OT-Brücke, SCADA↔ERP-Kommunikation
  Empfehlung: OPC UA als Standard für neue OT-Implementierungen

Schlussfolgerung:
  → Legacy-Protokolle (Modbus, DNP3-ohne-SAv5) = keine inhärente Sicherheit
  → Sicherheit muss netzwerkseitig erzwungen werden (Firewall, IDS, Segmentierung)
  → Neue Implementierungen: OPC UA oder CIP Security bevorzugen

Purdue-Referenzmodell und IEC 62443

ISA/IEC 62443 Purdue-Referenzarchitektur:

Level 5 - Enterprise Network (IT):
  → ERP (SAP), Office-Systeme, E-Mail, Internet
  → Benutzer-Workstations, Active Directory
  ─────────────────────── DMZ / Firewall ──────────────────────
Level 4 - Site Business Planning & Logistics:
  → Produktionsplanung, MES (Manufacturing Execution System)
  → Datenhistorianer (OSIsoft PI, AspenTech), Data Diode
  ─────────────────────── Firewall ────────────────────────────
Level 3.5 - Industrial DMZ:
  → Data-Diodes, unidirektionale Gateways
  → Patch-Management-Server, Antivirus-Updates
  → Remote-Access-Jump-Hosts
  ─────────────────────── Firewall ────────────────────────────
Level 3 - Site Manufacturing Operations:
  → SCADA-Server, Historian Collector, OT-DMZ
  → Engineering Workstations
  ─────────────────────── Firewall ────────────────────────────
Level 2 - Area Supervisory Control:
  → DCS Controllers, HMIs, Local Historian
  → Alarm-Management-Systeme
  ─────────────────────── Level-2-Netz ───────────────────────
Level 1 - Basic Control:
  → PLCs, RTUs, Flow Controllers, Drives
  ─────────────────────── Feldbus ─────────────────────────────
Level 0 - Physical Process:
  → Sensoren, Aktoren, Ventile, Motoren

Sicherheitsprinzip: Traffic von oben nach unten kontrolliert
  Level 5 darf NICHT Level 1 direkt erreichen!
  KEINE direkte Verbindung zwischen Level 5 und Level 0-2!
  DMZ als Puffer: nur definierte, kontrollierte Kommunikation
  Data Diodes wo möglich: physisch nur eine Richtung möglich

IEC 62443 - Standard für Industrial Security

IEC 62443 Normenfamilie:

IEC 62443-1: Allgemeines (Terminologie, Modelle)
  → Rollen: Asset Owner, System Integrator, Component Supplier

IEC 62443-2-1: Security Management System
  → ISMS für industrielle Automatisierung (vergleichbar ISO 27001 für OT)
  → Risikobeurteilung und Behandlung

IEC 62443-2-4: Service Provider Requirements
  → Anforderungen an Systemintegratoren und Dienstleister

IEC 62443-3-2: Security Risk Assessment
  → Methodik für OT-Risikobeurteilung

IEC 62443-3-3: System Security Requirements and Security Levels (SL):
  SL 0: Kein spezifischer Schutz
  SL 1: Schutz gegen unbeabsichtigte Fehler / Fehlbedienung
  SL 2: Schutz gegen absichtliche einfache Angriffe (normale Mittel)
  SL 3: Schutz gegen sophistizierte Angriffe (IIOT-Fachkenntnisse)
  SL 4: Schutz gegen State-Level-Angriffe (Stuxnet-Niveau)

  Target SL → wird durch Risikoanalyse bestimmt
  Achieved SL → aktueller Ist-Zustand
  Capability SL → maximales SL der Komponente/Lösung

  SL-Einstufung nach Risikoanalyse:
  → Kritische KRITIS-Anlagen: SL 3-4
  → Standard-Produktion: SL 2
  → Nicht-kritische Automationszellen: SL 1

IEC 62443-4-1: Secure Development Lifecycle (für Hersteller)
  → Security-by-Design für ICS-Komponenten
  → Patch- und Vulnerability-Management-Prozesse

BSI ICS-Security-Kompendium:
  → Kostenlos: bsi.bund.de/ICS
  → Deutsch, für Betreiber kritischer Infrastrukturen
  → Top 10 Bedrohungen + Maßnahmen für ICS

Zone und Conduit Modell

IEC 62443-3-3: Zones and Conduits:

Zone:
  → Logische Gruppierung von Assets mit gleichem Schutzbedarf
  → Beispiel Zone "Reaktor-Steuerung": PLCs, HMIs, RTUs des Reaktors

Conduit:
  → Kommunikationsweg zwischen Zones
  → JEDER Conduit ist eine Angriffsfläche → muss geschützt werden!
  → Conduit-Kontrollen: Firewall, Data Diode, VPN, DMZ

Zone-Definition-Prozess:
  1. Asset-Inventarisierung (alle OT-Komponenten erfassen)
  2. Kommunikationsbeziehungen kartieren (wer spricht mit wem?)
  3. Ähnliche Assets gruppieren (gleiche Funktion/gleicher Betreiber)
  4. Zonen-Boundaries definieren (Firewall, VLAN, physische Trennung)
  5. Conduits identifizieren und dokumentieren
  6. Security Level pro Zone festlegen (Risikoanalyse!)

Beispiel: Wasserwerk-Zonenmodell:
  Zone 1: IT-Büronetz (SL 1)
           ↕ Conduit A (Firewall + DMZ)
  Zone 2: SCADA-Netz (SL 2)
    ├─ Zone 2a: Leitwarte (SCADA-Server, HMI)
    │           ↕ Conduit B (Layer-3-Firewall, Whitelist-Regeln)
    └─ Zone 2b: OT-Netz (SL 2)
         ├─ Zone 3: Pumpensteuerung Nord (PLCs, RTUs) [SL 3]
         │           ↕ Conduit C (Data Diode → nur lesend)
         └─ Zone 4: Chlorierung (Safety-Krit.) [SL 4]

Firewall-Regeln für OT-Conduits:
  # Whitelist-Only! (kein "Deny Rest" als Fallback)
  # Erlaubt: Historian-Collector → PLC (TCP/102 - Siemens S7)
  # Erlaubt: HMI → PLC (OPC-UA, Port 4840)
  # ALLES andere: DENY + LOG

Segmentierungsarchitektur

Defense-in-Depth für OT:

Ebene 1: Physische Trennung
  → Air-Gap für ultrahohe Sicherheitsanforderungen (SIS, militärisch)
  → Data Diode: Hardware-erzwungene Einwegkommunikation
    Anbieter: Owl Cyber Defense, Waterfall Security, Advenica
    Use Case: OT-Historian → IT-Analytics ohne Rückkanal

Ebene 2: Industrial DMZ
  → Intermediäre Zone zwischen IT-Netz (Level 4) und OT-Netz (Level 3)
  → Enthält: Historian-Replika, Patch-Server, Jump-Host, Antivirus-Update-Server
  → IT-Systeme greifen nur auf IDMZ zu (nie direkt OT)

  Was in der DMZ leben darf:
  ✓ Antivirus-Update-Server (Pull aus IT, Push in OT)
  ✓ Patch-Management-Server
  ✓ Remote-Access-Jump-Host (für Fernwartung)
  ✓ Active-Directory-Read-only-Domain-Controller
  ✓ Historian-Replikation
  ✗ Internet-Zugang (NEIN!)
  ✗ E-Mail-Clients im OT-Netz
  ✗ Domain-Trust zwischen IT-AD und OT-AD

  Firewall-Regeln IT→IDMZ:
    ALLOW: ERP-Server → Historian-Replika-IDMZ TCP:1433 (Read-Only!)
    ALLOW: Patch-Server-IT → Patch-Depot-IDMZ TCP:445
    DENY: ANY → OT-Core

  Firewall-Regeln IDMZ→OT:
    ALLOW: Historian-Replika → OT-Historian TCP:5450 (PI-Protokoll)
    ALLOW: Jump-Host → PLC-IPs TCP:102 (S7comm) - NUR während Wartung!
    DENY: ANY → OT-Core (Default)

Ebene 3: Mikrosegmentierung innerhalb OT
  → Prozesslinien als separate Zonen
  → PLC-Zone, HMI-Zone, Engineering-Zone, Safety-Zone GETRENNT
  → Safety-Zone: physisch isoliert, KEINE IP-Verbindung zu anderen Zonen!

Ebene 4: OT-IDS/IPS
  → Passive Anomalie-Erkennung auf OT-Traffic
  → Alarm bei: unbekannter PLC-Befehl, unbekannte Kommunikationsbeziehung

Praktisches Beispiel - Chemiefabrik:
  Zone A: Enterprise (IT-Netz)
  Zone B: IDMZ (Historian-Replika, Patch-Server, MES-Proxy)
  Zone C: Production Control (SCADA, Historian, Engineering WS)
  Zone D: Reactor-PLC (SPS für Reaktoren - nur interner Traffic!)
  Zone E: Packaging-PLC (SPS für Abfüllung)
  Zone F: Safety (SIS - physisch isoliert, keine IP!)
  Conduit C→D: Whitelist Modbus FC03/04 only
  Conduit C→F: Physisch: Serial only (kein Ethernet!)

Asset Management für OT-Systeme

OT-Asset-Inventar - Besonderheiten:

Warum schwieriger als IT:
  → Keine Standard-Management-Schnittstellen (kein WMI, kein SNMP-Standard)
  → Aktive Scans können OT-Systeme beeinträchtigen/abstürzen!
  → Alter: 15-30 Jahre, undokumentierte Konfigurationen
  → Wechselnde Verantwortlichkeiten: IT kennt OT nicht, OT kennt IT nicht

Asset Discovery Methoden (sicherheitsgeordnet):

1. Passive Netzwerkanalyse (bevorzugt):
   Nozomi Networks Guardian:
     → Passiver Sensor am SPAN-Port/Mirror-Port
     → Erkennt automatisch: Gerätetyp, Hersteller, Firmware, Protokoll
     → Kommunikationsmatrix: welches Gerät spricht mit welchem?
     → Baseline-Erstellung: normales Verhalten definieren
     → Unterstützt 300+ OT-Protokolle

   Claroty Continuous Threat Detection:
     → Passives Asset-Discovery (kein Scan! Nur Netzwerk-Tap)
     → IT/OT-Asset-Konvergenz in einer Plattform
     → ICS-Protokoll-Deep-Inspection: Modbus, EtherNet/IP, OPC-UA, DNP3

   Dragos Platform:
     → OT-spezifisches Threat Detection System
     → Asset Discovery als Nebenprodukt des Monitorings
     → Threat-Gruppen-Zuordnung (Dragos kennt OT-Bedrohungsgruppen)

   Microsoft Defender for IoT (ehem. CyberX/Azure Defender for IoT):
     → Agentlos, Microsoft-Integration: Sentinel, Defender for Endpoint
     → Gute Asset-Discovery für gemischte IT/OT-Umgebungen

2. Aktive Abfrage (Vorsicht!):
   → Nur mit Hersteller-Freigabe und in Wartungsfenstern
   → Siemens: eigene TIA Portal-Discovery
   → Rockwell: FactoryTalk AssetCentre
   → Generic NMAP: NIEMALS in OT-Netz!

   # Nmap OT-Fingerprinting (nur in Wartungsfenstern!):
   nmap --script s7-info -p 102 192.168.1.0/24
   nmap --script modbus-discover -p 502 192.168.1.0/24
   # S7-CPUs können abstürzen!

Asset-Datenbank Mindestfelder:
  □ Hersteller + Modell (z.B. Siemens S7-315)
  □ Firmware-Version (z.B. V2.6.1)
  □ Hardware-Revision
  □ IP-Adresse + MAC-Adresse
  □ VLAN / Netzwerksegment / Zone
  □ Physischer Standort (Schaltschrank, Halle)
  □ Funktion (was steuert dieses Gerät?)
  □ Prozess-Kritikalität (Ausfall = Produktionsstopp?)
  □ Kommunikationspartner (Kommunikationsmatrix)
  □ Letztes Firmware-Update / Next-Maintenance-Window
  □ Verantwortlicher (OT-Engineer + Backup)
  □ Wartungsvertrag (Hersteller-Support aktiv?)

OT-Schwachstellenmanagement und Patch-Management

Das OT-Patch-Dilemma:

Warum OT-Patches so schwierig sind:
  → Windows XP, CE: keine Patches mehr (EOL)
  → PLC-Firmware: Update erfordert Produktionsstopp + Test + Hersteller-Zertifizierung
  → Einige Systeme: nur 1× pro Jahr im Wartungsfenster patchbar
  → Hersteller-Zertifizierung: bestimmte Windows-Patches können PLC-Software brechen!
  → Raffinerie: 1h Produktionsausfall = 100.000+ EUR

Patch-Prozess für OT:
  1. Schwachstellen-Information (RSS-Feeds abonnieren!):
     → CISA ICS-CERT Advisories: us-cert.gov/ics
     → Siemens ProductCERT: siemens.com/cert
     → Schneider Electric EVITA / PSIRT
     → ABB PSIRT: abb.com/support/cybersecurity
     → NIST NVD: nvd.nist.gov

  2. Risikoanalyse:
     → CVSS ≥ 9.0: sofortige Prüfung (aber: Verfügbarkeit prüfen!)
     → Exploitability: öffentliche Exploits verfügbar?
     → Netzwerk-Erreichbarkeit: Internet-exposed? Air-gapped?

  3. Test in Staging:
     → Identisches System (wenn möglich)
     → Hersteller-Freigabe erforderlich (Safety-Systeme!)
     → Regressionstest: alle Steuerungsfunktionen OK?

  4. Deployment:
     → Maintenance-Window koordinieren (Produktion stoppen)
     → Rollback-Plan: Image-Backup vor Patch
     → Notfall-Kontakt: Hersteller-Support bereit?

Patch-Priorisierung für OT:
  KRITISCH (sofort im nächsten Wartungsfenster):
    → CVSS ≥ 9.0 AND Exploit verfügbar AND Gerät hat Netzwerkzugang
    → Bekannte Ausnutzung durch APT-Gruppen (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 OR interne Systeme ohne Netzwerkzugang

Kompensatorische Sicherheitsmaßnahmen (wenn Patch nicht möglich):
  1. Netzwerksegmentierung: verwundbare Komponente isolieren
  2. Virtual Patching: IPS-Signatur blockt bekannten Exploit netzwerkseitig
  3. Application Whitelisting: nur erlaubte Programme
     McAfee Solidcore (ePolicy) für HMI-Systeme
     Carbon Black (App Control) für OT-Windows
  4. Monitoring: ungepatchte Systeme doppelt überwachen
  5. Schreibschutz: PLCs in read-only-Modus
  6. Deaktivierung: nicht benötigte Dienste und Ports

Sicherheitsarchitektur: Air Gap und sichere Remote-Zugänge

Air Gap, Data Diodes und sichere Remote-Zugänge:

Echter Air Gap:
  → Physisch getrennt: kein Netzwerkkabel, kein WLAN
  → Datentransfer: USB-Sticks (Stuxnet-Vektor!), Laptops
  → Problem: wartungsintensiv, USB = Risiko
  → Schutz: USB-Blocker, USB-Desinfektion (Qubes-basiert)

Data Diode (physisch erzwungene Einweg-Kommunikation):
  → Hardware-Bauteil: Daten können nur in eine Richtung fließen
  → Physik: optische Übertragung ohne Rückkanal
  → Anbieter: Owl Cyber Defense, Waterfall Security, Advenica

Secure Remote Access (Maintenance/Vendor Access):
  # PROBLEM: Angreifer nutzen VPN-Zugänge von Drittanbietern
  # Colonial Pipeline: Compromised VPN credentials

  Anforderungen:
  → Jump-Server / Bastion Host in OT-DMZ
  → MFA für ALLE Remote-Zugänge (kein Passwort allein!)
  → Session-Recording: alle Aktionen aufzeichnen
  → Time-Limited Access: automatisch nach X Minuten ablaufend
  → Least-Privilege: nur auf benötigte Systeme
  → Lieferanten: eigene Accounts, keine Shared-Credentials

  Technologie-Stack:
  → CyberArk Privileged Remote Access
  → Claroty Secure Remote Access
  → Eigenlösung: Jumpserver (SSH Bastion) + PAM

  Privileged Access Workstation (PAW) für OT:
  → Separater Laptop, nur für OT-Admin-Zugriff
  → Kein E-Mail, kein Browser, keine USB-Laufwerke
  → BitLocker verschlüsselt, EDR aktiv

OT Security Monitoring und SIEM-Integration

Anomalie-Erkennung in OT-Umgebungen:

Baseline-Erstellung:
  → OT-Umgebungen haben sehr stabiles, vorhersehbares Verhalten
  → PLC kommuniziert immer mit SCADA-Server, nie direkt mit Internet
  → Kommunikationsmatrix: wer spricht mit wem? (Whitelist-Ansatz)
  → Abweichungen = hochverdächtig
  → Baseline-Periode: 2-4 Wochen normalen Betrieb aufzeichnen

OT-Monitoring Best Practices:
  □ Passives Monitoring NUR (aktiver Scan kann PLCs abstürzen lassen!)
  □ Alerts auf: neue Geräte, neue Verbindungen, unbekannte Protokoll-Befehle
  □ Keine direkten Verbindungen vom OT-SIEM ins Internet
  □ 24/7 OT-SOC oder MDR-Service für kritische Anlagen

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 (Ladder Logic Upload!) außerhalb Wartungsfenster
  □ Modbus-Schreibbefehl (FC05/06/15/16) von unbekannter Quelle
  □ Engineering-Workstation mit aktivem PLC-Programmiersoftware außerhalb Wartung
  □ Direktverbindung OT → Internet (Exfiltration!)
  □ Passwortänderung auf OT-System
  □ USB-Gerät an HMI angeschlossen (wenn USB-Monitoring vorhanden)

Log-Quellen für OT-SIEM:
  → Firewall-Logs (IT/OT-Grenze): kritischste Log-Quelle
  → Windows Event Logs von HMIs und Engineering WS
  → SCADA-Audit-Logs (wenn vorhanden)
  → Historian-Änderungslogs
  → Network Traffic (passiv via SPAN-Port)
  → VPN-Logs (Remote Access Protokollierung!)

OT-SIEM Integration:
  → Nozomi Guardian → Sentinel/Splunk/QRadar Integration
  → Claroty → eigene Plattform + SIEM-Forwarding
  → Dragos → eigene Plattform
  → Microsoft Sentinel: Defender for IoT (native Integration)

Incident Response für OT

OT-IR unterscheidet sich fundamental von IT-IR:

IT vs. OT: Grundsätzlicher Konflikt:
  IT-IR-Paradigma: System sofort isolieren/abschalten
  OT-Realität: Abschalten = Produktionsstillstand, Sicherheitsrisiko!
    Beispiel: Pumpe läuft bei 2.000 RPM → sofortiger Stop → Druckschlag → Rohrbruch!
    Beispiel: Kraftwerk → Lastabwurf → Netzinstabilität!
  OT-IR-Prinzip: Safety first - dann Availability - dann Security

OT-IR-Team Zusammensetzung:
  □ OT-Security-Analyst (technische Analyse)
  □ Process Engineer (versteht physische Konsequenzen von Aktionen!)
  □ Safety Engineer (SIS-Expertise)
  □ OT-Netzwerk-Spezialist
  □ IT-IR-Experte (für IT-Seite des Pivots)
  □ Behörden-Kontakt (KRITIS: BSI, Bundesnetzagentur)

IR-Prozess OT:

Phase 1 - Erkennung:
  → Anomalie-Alert von Nozomi/Claroty/Dragos
  → ODER: Physische Auffälligkeit (Steuerungsfehler, ungeplante Aktionen)
  → ERSTE FRAGE: Ist die Anlage physisch sicher? SIS korrekt?
  □ Enthält Incident physische Sicherheitsrisiken? → Safety-Team einschalten!
  □ Ausbreitung auf Safety-Systeme? → NOT-Abschaltung prüfen mit Operations!
  □ Produktionsstillstand akzeptabel? → Erst mit Plant Manager entscheiden!

Phase 2 - Bewertung (innerhalb 1 Stunde):
  □ Betroffene Assets identifizieren (ohne zu isolieren!)
  □ Netzwerk-Captures starten (ohne Traffic zu verändern)
  □ Manuelle Überwachung stärken (Prozessoperatoren informieren)
  □ OT-Hersteller kontaktieren (Siemens, Rockwell PSIRT)
  → Ist es ein IT-Incident mit OT-Auswirkung? (Ransomware im IT-Netz)
  → Ist OT direkt kompromittiert? (PLC-Konfiguration verändert?)
  → Kann Anlage weiter im Notbetrieb laufen?

Phase 3 - Containment (mit Operations-Freigabe, ohne Produktionsstopp wenn möglich):
  □ Kompromittierte Kommunikationspfade blocken (Firewall-Änderung)
  □ Betroffene Workstations isolieren (NICHT PLCs!)
  □ Backup-HMIs / Engineering-Workstations bereitstellen
  □ Umschalten auf manuelle Steuerung wenn möglich
  NIEMALS: Einfach Stromstecker ziehen bei laufendem Prozess!
  Option: Verdächtiges OT-System auf manuelle Steuerung umschalten
  Option: Kompromittiertes HMI isolieren (anderen HMI als Backup)

Phase 4 - Forensik (OT-schonend):
  → Passive Forensik bevorzugen: Netzwerk-Capture
  → PLC-Memory-Dump: herstellerspezifische Tools (nicht Standard-IT-Tools!)
  → PLC-Backup und Zustandsaufnahme: Ladder Logic, Inputs/Outputs
  → PCAP vom Zeitraum des Incidents (wenn Recorder vorhanden)
  → Flüchtige PLC-Daten: Speicher sehr begrenzt, schnell überschrieben
  → Timestamps: OT-Systeme oft mit falscher Systemzeit (kein NTP!)
  → Chain of Custody: ISO/IEC 27037 Prozesse

Phase 5 - Recovery:
  □ PLC-Programme auf Integrität prüfen (Hash-Vergleich!)
  □ PLC-Firmware aus verifizierten Backups wiederherstellen
  □ HMI-Image von goldenem Backup-Image
  □ Safety-System-Zertifizierung erneuern (wenn SIS betroffen!)
  □ Forensik: Prozesshistoriendaten sichern als Beweis
  □ Kommunikationsmatrix validieren: ist alles wieder normal?
  □ Monitoring intensivieren: 30 Tage erhöhte Aufmerksamkeit

Phase 6 - Reporting:
  → KRITIS-Meldung: BSI (24h Frühwarnung wenn erheblicher Vorfall)
  → Versicherungs-Dokumentation
  → Lessons Learned: Sicherheitslücke schließen

Regulatorische Anforderungen

NIS2-Pflichten für OT-Betreiber:

Wer ist betroffen (NIS2 / BSIG §2):
  → Energieversorgung (Strom, Gas, Öl, Fernwärme)
  → Wasser/Abwasser
  → Digitale Infrastruktur (RZ, Cloud, CDN)
  → Gesundheitswesen (Krankenhäuser, Labore)
  → Transport (Schiene, Luft, See, Straße)
  → Finanzen (Kreditinstitute, Marktinfrastruktur)
  → Öffentliche Verwaltung
  → OT-Systeme explizit in NIS2-Scope!

Wesentliche Anforderungen NIS2 Art. 21:
  □ Risikoanalyse und Sicherheitspolitiken (§6 BSIG)
  □ Incident Handling und Business Continuity
  □ Supply-Chain-Sicherheit (Lieferanten!)
  □ Bewertung der Wirksamkeit von Sicherheitsmaßnahmen
  □ Zugangskontrolle, Asset Management, MFA
  □ Kryptografie und Verschlüsselung

Meldepflichten (BSIG §30, nach BSI-Meldestelle):
  → Frühwarnung: 24h nach Kenntnis (erheblicher Vorfall)
  → Erstmeldung: 72h (Art, Ausmaß, Auswirkungen)
  → Abschlussbericht: 1 Monat (vollständige Analyse, Maßnahmen)

BSI IT-Grundschutz Bausteine für ICS:
  IND.1:  Allgemeine ICS
  IND.2.1: Speicherprogrammierbare Steuerung (SPS)
  IND.2.2: Speicherprogrammierbare Steuerung Siemens S7
  IND.2.3: Sensoren und Aktoren
  NET.3:  Router und Switches (auch OT-Segmente)

NIST SP 800-82 Rev. 3 (2023):
  → US-amerikanischer Leitfaden für ICS-Security (kostenlos)
  → Sehr praktisch: konkrete Empfehlungen je OT-Technologie

Checkliste kritische OT-Maßnahmen:
  □ Netzwerksegmentierung: IT und OT strikt getrennt
  □ Purdue-Modell implementiert: Kommunikationsrichtungen enforced
  □ Asset-Inventar: alle OT-Komponenten erfasst
  □ Remote-Zugang: MFA + Session-Recording + JIT-Zugang
  □ Backup PLC-Programme: versionsweise gesichert, regelmäßig getestet
  □ Patch-Management: Prozess definiert, Risikoanalyse je Patch
  □ Anomalie-Erkennung: Nozomi oder Claroty oder Defender for IoT
  □ IR-Plan: OT-spezifische Playbooks, Hersteller-Kontakte
  □ Lieferanten-Management: Access-Reviews, Vertragliche Sicherheitsanforderungen
  □ Schulung: OT-Operator für Social Engineering, Phishing sensibilisiert