In klassischen IT Systemen ist die Antwort auf Sicherheitsfragen meist einfach. Mehr Verschlüsselung. Mehr Monitoring. Mehr Kontrolle. Wenn Performance leidet, wird Hardware nachgerüstet.
In Industrial Control Systems funktioniert diese Logik nicht.
Hier steuern Systeme reale Prozesse. Motoren, Förderbänder, Hydraulikzylinder, Roboterachsen. Ein Steuerzyklus ist nicht nur ein Datenpaket, sondern eine physische Bewegung.
Und genau hier beginnt das Spannungsfeld zwischen Security und Determinismus.
Determinismus bedeutet Vorhersagbarkeit. Ein Steuerbefehl kommt nicht irgendwann an, sondern innerhalb eines exakt definierten Zeitfensters. Typische Steuerungen arbeiten mit Zykluszeiten von wenigen Millisekunden. Safety Systeme reagieren noch schneller.
Wenn Sicherheitsmechanismen eingeführt werden, verändert sich dieses Gleichgewicht.
Ein Beispiel aus der Praxis.
In einer Control Zone läuft eine zentrale Steuerungssoftware. Diese koordiniert Materialflüsse, berechnet Bewegungsprofile, synchronisiert mehrere PLCs und überwacht Sensorwerte. Die Kommunikation mit den Steuerungen erfolgt zyklisch und mit festen Timeout Werten.
Nun wird entschieden, die Kommunikation zwischen Steuerungssoftware und PLC zusätzlich über TLS zu sichern.
Technisch passiert Folgendes.
Jede Verbindung benötigt einen Handshake. Zertifikate müssen geprüft werden. Schlüssel werden ausgehandelt. Pakete werden verschlüsselt und entschlüsselt.
Die unmittelbaren Effekte können sein:
Erhöhte CPU Last auf der Steuerungsinstanz
Erhöhte CPU Last auf der PLC
Vergrößerte Paketgrößen
Verlängerte Antwortzeiten
Verändertes Timeout Verhalten
Die Steuerungssoftware interpretiert verspätete Antworten möglicherweise als Kommunikationsfehler. In der Praxis äußert sich das als sporadischer Anlagenstopp, Timeout Meldung oder unerklärlicher Wiederanlauf.
Das Problem ist nicht die Verschlüsselung selbst. Das Problem ist fehlende Kontextbewertung.
Verschlüsselung ist aus regulatorischer Sicht in vielen Kommunikationspfaden erforderlich. Aber sie darf nicht unreflektiert in deterministische Steuerungsnetze integriert werden.
Entscheidend ist die Differenzierung der Kommunikationspfade.
Kommunikation innerhalb einer isolierten Control Zone ohne externe Exposition besitzt ein anderes Risikoprofil als Kommunikation zwischen Control Zone und Enterprise IT oder Cloud.
Die technische Leitfrage lautet daher nicht, ob verschlüsselt werden soll, sondern wo Verschlüsselung zwingend ist und wo Segmentierung ausreichend ist.
Eine mögliche Differenzierung sieht so aus:
Kommunikation zwischen Enterprise IT und DMZ. Hier ist Verschlüsselung zwingend.
Kommunikation zwischen Remote Access Gateway und Jump Server. Hier sind starke Authentisierung und Verschlüsselung zwingend.
Kommunikation zwischen Steuerungssoftware und PLC innerhalb einer strikt segmentierten Zone ohne externe Anbindung. Hier muss Performance gegen Risiko abgewogen werden.
In vielen robusten Architekturen wird daher folgender Ansatz gewählt:
Interne Echtzeitkommunikation bleibt unverschlüsselt, aber vollständig isoliert und segmentiert.
Externe Schnittstellen werden konsequent verschlüsselt und überwacht.
Übergänge zwischen Zonen werden durch Firewalls und definierte Conduits kontrolliert.
Die Entscheidung muss aus der Risikoanalyse gemäß IEC 62443 3 2 abgeleitet werden. Sie muss dokumentiert und technisch validiert werden.
Ein weiterer Aspekt betrifft die interne Softwarearchitektur.
Moderne Steuerungssoftware arbeitet häufig mit serviceorientierter Kommunikation, internen APIs oder Message Mechanismen. Wird TLS hier eingeführt, stellen sich zusätzliche Fragen:
Wie viele gleichzeitige Verbindungen existieren?
Wie hoch ist die Session Wiederverwendung?
Welche Cipher Suites werden verwendet?
Welche CPU Reserven sind vorhanden?
Wie wirken sich Zertifikatsprüfungen unter Last aus?
Diese Fragen gehören nicht ausschließlich in die IT Abteilung. Sie gehören in ein gemeinsames Architekturreview zwischen OT, Security, Safety und Software Engineering, und unbedingt in ein Testlab.
Ein weiteres Praxisbeispiel verdeutlicht das Problem.
Ein Betreiber führt Deep Packet Inspection im Steuerungsnetz ein, um Transparenz zu erhöhen. Das System analysiert jedes Paket inline. Unter hoher Last steigt die Latenz minimal, aber ausreichend, um sporadische Timeouts auszulösen. Die Anlage stoppt. Nicht wegen eines Angriffs, sondern wegen einer ungetesteten Security Maßnahme. Hier zeigt sich der zentrale Punkt.
Security darf die Systemphysik nicht ignorieren.
Vor Einführung von Verschlüsselung oder Analysemechanismen müssen mindestens folgende Werte gemessen werden:
Zykluszeit vor Einführung
Zykluszeit nach Einführung
CPU Auslastung vorher und nachher
Netzwerklatenz
Jitter
Timeout Verhalten
Diese Werte müssen dokumentiert werden. Nicht nur technisch, sondern auditierbar.
Wenn ein Prüfer fragt, warum ein bestimmter Kommunikationspfad nicht verschlüsselt ist, muss die Antwort lauten:
Risikobewertung durchgeführt
Performance getestet
Safety Auswirkungen analysiert
Entscheidung dokumentiert
Security in ICS ist kein Entweder Oder zwischen Schutz und Performance. Es ist ein Abwägen unter technischen Randbedingungen.
Eine belastbare Architektur trennt daher klar:
Exponierte Zonen mit starker Authentisierung und Verschlüsselung
Interne deterministische Zonen mit Segmentierung und minimalem Overhead
Safety Pfade mit streng kontrollierter Änderungspolitik
Remote Zugänge mit zentraler Kontrolle und Monitoring
Der Unterschied zwischen einer oberflächlichen Compliance Lösung und einer belastbaren industriellen Sicherheitsarchitektur liegt im Verständnis der Systemphysik.
Im nächsten Artikel analysieren wir konkrete industrielle Protokolle wie OPC UA und MQTT und zeigen, wie sich Sicherheitsmechanismen dort technisch und performanceseitig auswirken.
Weitere Artikel
Artikelserie – Industrial Control Systems unter regulatorischen Druck – Artikel 5 – Referenzarchitektur
Artikelserie Digitale ID – Artikel 21 – Infrastruktur ersetzt Gesetz – Wie Standards politische Entscheidung vorstrukturieren
Artikelserie – Industrial Control Systems unter regulatorischen Druck – Artikel 4 – Risikoanalyse nach IEC 62443 3-2
Artikelserie – Industrial Control Systems unter regulatorischen Druck – Artikel 3 – Wann wird eine industrielle Anlage regulatorisch zu einem Produkt und was bedeutet das für Betreiber