Jede Sicherheitsgeschichte über OT beginnt heutzutage mit Zero Trust. Und zu Recht. Das Prinzip ist solide: Vertraue nichts implizit, verifiziere wo möglich, beschränke den Zugang und minimiere den Explosionsradius.
Aber versuche das einer Siemens S7-300 aus dem Jahr 2008 zu erklären.
Diese SPS hat keinen TLS-Stack. Keinen Zertifikatspeicher. Keine moderne Authentifizierung. Sie spricht Profinet, MPI oder vielleicht Modbus/TCP. Sie tut seit fünfzehn Jahren genau das, was sie tun muss. Die Linie läuft darauf. Die Operatoren kennen ihr Verhalten. Der Wartungstechniker weiß, welche Kontrollleuchten normal sind. Und irgendwo gibt es noch einen Engineering-Laptop mit Software, die niemand gerne neu installiert.
Diese SPS wird man nicht einfach ersetzen. Nicht weil Sicherheit keine Rolle spielt. Sondern weil die Linie wochenlang stillstehen würde, der Hersteller vielleicht nicht mehr existiert, die Dokumentation unvollständig ist, und niemand genau weiß, was in diesem Programm passiert.
Das ist die Realität der OT-Sicherheit. Nicht die Whitepaper-Version. Die Fabrikboden-Version.
Das Problem mit “Segmentiere es einfach”
Segmentierung wird oft so dargestellt, als ob es eine Frage des Erstellens von VLANs und des Schreibens von Firewall-Regeln wäre. In der IT kann man damit manchmal davonkommen. Endpunkte sprechen TCP/IP, unterstützen TLS, authentifizieren sich gegen einen Identity Provider und können relativ einfach gepatcht werden.
In OT befindet man sich in einem anderen Universum. Geräte, die moderne Sicherheit nicht unterstützen. Protokolle ohne Authentifizierung. Firmware, die nicht gepatcht werden kann. Serielle Verbindungen, die durch Konverter plötzlich im Netzwerk auftauchen. Engineering-Workstations, die sowohl auf die Unternehmens-IT als auch das Prozessnetzwerk zugreifen müssen. Hersteller, die Remote-Zugang über TeamViewer auf einem gemeinsam genutzten Laptop wollen.
Segmentierung in OT ist daher keine Netzwerkfrage. Es ist eine Designfrage. Man muss nicht nur wissen, welche Systeme miteinander kommunizieren — man muss verstehen, warum sie das tun, und was physisch passiert, wenn man diese Kommunikation unterbricht.
Zonen und Conduits: IEC 62443 in der Praxis
IEC 62443 bietet dafĂĽr den richtigen Rahmen: Zonen und Conduits. Eine Zone ist eine Gruppe von Assets mit vergleichbarem Risikoprofil und gleicher Funktion. Ein Conduit ist die kontrollierte Verbindung zwischen Zonen.
In der Praxis: Eine Gruppe von SPSen, die zusammen eine Produktionslinie steuern, bilden eine Zone. Der SCADA-Server, der sie liest, befindet sich in einer anderen Zone. Der Kommunikationspfad zwischen ihnen ist der Conduit — und genau dort setzt man Kontrolle durch.
Der Kernpunkt: Man muss die SPS selbst nicht modernisieren. Eine alte SPS kann kein TLS sprechen, aber das Netzwerksegment darum herum kann absolut begrenzt, überwacht und kontrolliert werden. In OT liegt die Verteidigung nicht innerhalb des Geräts. Die Verteidigung liegt darum herum.
Was man an der Grenze tut
Protokollbewusste Firewalls. Keine Standard-Enterprise-Firewall, die nur Ports sieht. Denn TCP-Port 502 zuzulassen ist nicht dasselbe wie sicheren Modbus-Traffic zuzulassen. Ein Modbus-Lesen ist anders als ein Modbus-Schreiben. Daten lesen ist anders als eine Spule zwingen.
Eine gute OT-Firewall versteht diesen Unterschied. SCADA darf Register lesen. Engineering darf schreiben, aber nur von einer kontrollierten Workstation. Hersteller kommen nur über einen Jump Host rein. Wartungszugang ist temporär, protokolliert und nachverfolgbar.
Unidirektionale Gateways. Wenn eine Zone nur Daten liefern muss — Prozessdaten an einen Historian oder eine Cloud-Plattform — gibt es keinen Grund für bidirektionale Kommunikation. Eine Datendiode ist keine Firewall-Regel. Es ist eine physische Einschränkung. Daten können raus; Traffic kann nicht zurückkommen. Man muss der SPS nicht beibringen, Zertifikaten zu vertrauen. Man stellt einfach sicher, dass kein Rückweg existiert.
Nicht alles muss intelligenter werden. Manchmal muss die Architektur einfach strenger werden.
Monitoring auf dem Conduit. Nicht alles kann blockiert werden — in OT kann eine falsche Firewall-Regel die Produktion stoppen. Aber wenn man Traffic nicht verschlüsseln kann, kann man ihn inspizieren. Deep Packet Inspection auf OT-Protokollen zeigt, welche Befehle über das Kabel laufen.
Eine SPS, die seit drei Jahren nicht modifiziert wurde und plötzlich einen Firmware-Upload erhält, verdient Aufmerksamkeit. Eine Engineering-Workstation, die außerhalb von Wartungsfenstern auf Controller schreibt, verdient Aufmerksamkeit. Ein unbekanntes Gerät, das mit einer Produktionslinie kommuniziert, verdient Aufmerksamkeit.
In OT geht es bei Sicherheit nicht nur ums Blockieren. Es geht darum, normales Verhalten zu verstehen und Abweichungen zu erkennen.
Das Purdue-Modell als Ausgangspunkt
In der Praxis ist das Purdue-Modell noch nützlich — nicht als Dogma, sondern als Gesprächsrahmen. Unten: physische Prozesse und Controller. Darüber: SCADA und HMI. Darüber: Standortoperationen mit Historianern, MES und Engineering-Workstations. Zwischen OT und IT: eine echte DMZ mit Jump-Servern, Patch-Proxies und Datenexporten.
Aber die größten Gewinne kommen oft nicht von der IT/OT-Grenze. Die bekommt normalerweise Aufmerksamkeit. Die vergessenen Grenzen liegen tiefer: zwischen Produktionszellen, zwischen dem Prozessnetzwerk und dem Sicherheitsnetzwerk, zwischen einer alten seriellen Welt und einem neuen IP-Netzwerk.
Das sind genau die Risiken, die niemand mehr sieht, weil das Netzwerk einmal flach aufgebaut wurde und seitdem läuft. Bis es das nicht mehr tut.
NIS2 macht Selbstgefälligkeit schwerer
Mit NIS2 wird OT-Sicherheit weniger optional. Für Sektoren wie Energie, Wasser, Lebensmittelproduktion, Fertigung und andere vitale oder wichtige Prozesse wird es zunehmend notwendig, verhältnismäßige und angemessene Maßnahmen nachzuweisen. “Wir haben eine Firewall zwischen IT und OT” reicht nicht mehr aus.
Man muss erklären können, welche Assets man hat, wie die OT-Umgebung strukturiert ist, welche Kommunikationsflüsse notwendig sind, wie Remote-Zugang gehandhabt wird, und wie Vorfälle erkannt werden.
IEC 62443 hilft dabei. Nicht weil es alles löst, sondern weil es eine Sprache bereitstellt, die für industrielle Umgebungen geeignet ist. Wenn man Segmentierung in Begriffen von Zonen, Conduits und Kontrollmaßnahmen erklären kann, hat man eine Geschichte, die technisch solide und auf Führungsebene handhabbar ist.
Wo man anfängt
Die Versuchung ist, mit Technologie zu beginnen. Firewalls auswählen, VLANs zeichnen, Monitoring-Tools vergleichen.
Fang dort nicht an.
Beginne mit einem Asset-Inventar. Nicht das, was die Dokumentation sagt — was wirklich vorhanden ist. Welche SPSen, Switches, Konverter, Engineering-Laptops, Herstellersysteme und Legacy-Verbindungen existieren tatsächlich?
Dann kartiere die Kommunikation. Welches Gerät spricht mit welchem Gerät, über welches Protokoll, in welche Richtung, und warum? Dieses “Warum” ist entscheidend. Wenn niemand erklären kann, warum zwei Systeme miteinander kommunizieren, hat man entweder ein Risiko gefunden oder eine unnötige Verbindung.
Erst dann zeichne man Zonen. Basierend auf Funktion, Risiko und operativem Zusammenhalt — nicht auf IP-Bereichen.
Und jede Zone und jeder Conduit braucht Ownership. Wer kann Änderungen genehmigen? Wer kontrolliert die Firewall-Regeln? Wer validiert regelmäßig, ob die Kommunikation noch notwendig ist? Ohne Ownership ist Segmentierung eine Zeichnung. Mit Ownership wird sie Kontrolle.
Das Wesentliche
OT-Sicherheit scheitert selten, weil Menschen Zero Trust oder IEC 62443 nicht kennen. Es scheitert, weil diese Modelle zu oft über dem Fabrikboden hängen bleiben.
Eine alte SPS wird keine moderne Sicherheit unterstützen. Eine Modbus-Verbindung wird nicht plötzlich sicher. Eine Linie, die seit fünfzehn Jahren läuft, wird nicht ersetzt, weil die Sicherheitsarchitektur schöner aussähe.
Deshalb beginnt OT-Sicherheit nicht mit Vertrauen, und auch nicht mit Misstrauen. Sie beginnt mit Grenzen.
Man muss einer Siemens S7-300 nicht Zero Trust erklären. Man muss das Netzwerk um sie herum so gestalten, dass sie es nie verstehen muss.