OT Security: Wie Sie Produktionsanlagen und industrielle Steuerungssysteme wirksam schützen

Mitten in der Frühschicht steht die Fertigungslinie. So ein Ausfall kann jederzeit auftreten, und er fällt sofort auf: Die Anlage meldet Störung, die Werker stehen daneben, der Schichtleiter ruft die IT. Ursache ist eine Störung, die aus dem IT-Netz in die Produktion durchgeschlagen ist. Das kann ein Angriff gewesen sein, aber ebenso ein fehlkonfigurierter Switch oder ein ungeplanter Netzwerkscan der IT. Für die Produktion macht das keinen Unterschied. Genau hier setzt OT Security an.

OT Security bezeichnet den Schutz von Operational Technology — also von Steuerungs- und Überwachungssystemen, die physikalische Prozesse in Produktion, Energieversorgung und Gebäudetechnik steuern. Anders als in der IT steht dabei nicht die Vertraulichkeit von Daten an erster Stelle. Oberstes Schutzziel ist die funktionale Sicherheit von Mensch und Anlage; gleichrangig daneben stehen die Resilienz des Prozesses und die Produktivität. Alle drei führen am Ende auf dasselbe hinaus: auf die Verfügbarkeit der Anlage.

Das Wichtigste in Kürze

• • Oberstes Schutzziel ist die funktionale Sicherheit; Resilienz, Produktivität und Verfügbarkeit stehen gleichrangig daneben, Vertraulichkeit rückt nach hinten — das prägt alles von der Patch-Strategie bis zur Reaktion im Ernstfall.

• • Die Vorfälle, die Produktionen tatsächlich treffen, entstehen dort, wo IT-Services in der OT mitbenutzt werden — nicht zwangsläufig an der Netzgrenze selbst.

• • IEC 62443 liefert den Ordnungsrahmen, NIS-2 verlangt seit Dezember 2025 geeignete Maßnahmen — und nimmt die Geschäftsleitung persönlich in die Pflicht: Sie muss die Umsetzung überwachen und haftet dem eigenen Unternehmen gegenüber für schuldhafte Versäumnisse.

• • Der erste Schritt ist immer Transparenz und Sichtbarkeit: Ohne Asset- und Kommunikationsübersicht ist die Segmentierung von Systemen deutlich schwieriger.

Was ist OT Security? Definition und Abgrenzung

Operational Technology umfasst alle Komponenten, die physikalische Zustände messen, steuern oder verändern. Ein IT-Fehler kostet Daten und Zeit, ein OT-Fehler kostet Produktionsmenge, Materialchargen und im schlimmsten Fall Gesundheit.

Die Begriffe bauen aufeinander auf:

• • OT ist der Oberbegriff für alle prozessnahen Technologien.

• • ICS (Industrial Control Systems) sind die Steuerungssysteme innerhalb der OT.

• • SCADA bezeichnet die überlagerte Leit- und Visualisierungsebene.

• • SPS oder PLC ist die Steuerungshardware im Feld, HMI die Bedienoberfläche für den Werker.

Eine ausführliche Einordnung finden Sie in unserem Beitrag zu den Grundlagen von Operational Technology.

Was ist ein OT-Netzwerk?

Ein OT-Netzwerk ist das Datennetz, über das Steuerungen, Sensoren, Aktoren und Leitsysteme einer Anlage kommunizieren. Es überträgt Steuerbefehle und Prozesswerte in Echtzeit, nutzt eigene Industrieprotokolle und reagiert auf Verzögerungen deutlich empfindlicher als ein Office-Netzwerk.

OT Security vs. IT-Sicherheit: die entscheidenden Unterschiede

In der IT gilt Vertraulichkeit vor Integrität vor Verfügbarkeit. In der OT kehrt sich diese Reihenfolge nicht nur um: Ganz oben stehen die funktionale Sicherheit, die Resilienz des Prozesses und die Produktivität — Ziele, die alle auf die Verfügbarkeit einzahlen. Wer das nicht verinnerlicht, produziert Maßnahmen, die technisch korrekt und betrieblich unbrauchbar sind. Ein automatisches Patch-Rollout mitten in der Schicht ist das Standardbeispiel.

Die folgende Gegenüberstellung fasst zusammen, worin sich beide Welten unterscheiden:

Kriterium	IT	OT
Schutzziel-Priorität	Vertraulichkeit, Integrität, Verfügbarkeit	funktionale Sicherheit, Resilienz und Produktivität — und damit Verfügbarkeit; dann Integrität, zuletzt Vertraulichkeit
Systemlebensdauer	3 bis 5 Jahre	15 bis 25 Jahre und mehr
Patchbarkeit	regelmäßig, automatisiert	nur im Stillstand, oft herstellerseitig eingeschränkt
Protokolle	meist authentifiziert und verschlüsselt	Modbus, PROFINET, EtherNet/IP, DNP3 ohne Authentifizierung; Ausnahme OPC UA
Netzwerkteilnehmer	viele, wechselnd, mobil	wenige, statisch, planbar

Die letzte Zeile ist von besonderer Bedeutung, denn sie fehlt in fast allen Vergleichstabellen und entscheidet in der Praxis am meisten. Ein IT-Netz hat viele, ständig wechselnde Teilnehmer. Ein OT-Netz hat dieselbe Steuerung, dieselbe MAC-Adresse und dasselbe Kommunikationsmuster, oft über Jahre.

Daraus folgt ein Vorteil, den man allerdings differenzieren muss. Freizugeben, welche Zone mit welcher über welches Protokoll spricht — eine Zone ist eine Gruppe von Assets mit gleichem Schutzbedarf, mehr dazu weiter unten —, ist robust; solche Regeln überleben Jahre. Geräte am einzelnen Switchport freizugeben, ist dagegen heikel: Tauscht die Instandhaltung nachts einen Antrieb, hat das Ersatzteil eine neue MAC-Adresse. Ohne Freigabeprozess rund um die Uhr steht dann die Linie, oder jemand überbrückt die Sperre. Grundlage für jede dieser Freigabelogiken ist Netzwerksichtbarkeit und Network Access Control.

IT-OT-Konvergenz: warum die Trennung ohne Konzept nicht mehr funktioniert

Das physisch getrennte Produktionsnetz ist Vergangenheit. MES-Anbindung, Predictive Maintenance, ERP-Rückmeldungen und Energiemonitoring erzeugen jeweils eine Verbindung. Das Air Gap existiert meist nur noch als Annahme in einer alten Netzdokumentation.

Zahlenmäßig überwiegen dabei die Übergänge, die niemand als Sicherheitsthema wahrnimmt: die Kopplung an Fertigungsleit- und ERP-Systeme, der Historian als Langzeitarchiv für Prozessdaten, Fileshares, die Anmeldung an HMIs über das Active Directory, das Backup. Am schlechtesten kontrolliert ist aber fast immer der Herstellerzugang. Ein eingehendes VPN öffnet Ihr Netz dabei nicht zwangsläufig dauerhaft — entscheidend ist, ob es kontrolliert wird: enge Firewall-Regeln auf Ziel, Port und Protokoll, starke Authentifizierung, eine pro Einsatz freigegebene statt permanent stehende Verbindung und eine Protokollierung. Fehlen diese Kontrollen, wird aus dem Zugang tatsächlich eine offene Standleitung von außen. Alternativ bringen manche Hersteller eine eigene Box mit; die baut die Verbindung ausgehend auf, verlagert die Vertrauensgrenze dafür zum Hersteller.

Besteht der Hersteller auf seiner eigenen Box, lassen sich meist drei Positionen durchsetzen: Die Box steht in der Übergangszone zwischen IT und OT, nicht in der Fertigungszelle. Die Verbindung ist standardmäßig getrennt und wird pro Einsatz freigegeben. Und Sie erhalten ein Protokoll darüber, wer wann verbunden war. Wie das aussieht, zeigen wir unter Fernwartung von Maschinen und Anlagen.

Wie viel Trennung ist angemessen?

Hier ist Ehrlichkeit wichtiger als jede Best-Practice-Folie: Nicht jeder Betrieb kauft und verwaltet seine Hardware doppelt. Der Mehraufwand ist real und muss begründet werden. Sinnvoll ist deshalb eine abgestufte Betrachtung.

Stufe	Umsetzung	Wann angemessen
1 — Logische Trennung auf vorhandener IT-Infrastruktur	VLANs, Zugriffslisten und Firewall-Regeln auf der bestehenden IT-Hardware; die OT erhält eigene Zonen, aber keine eigene Hardware	Wenige Zonengrenzen, kontrollierter externer Zugriff, kein regulatorischer Druck
2 — Eigene OT-Infrastruktur	Durchgängig eigene Hardware: eigene Firewall am Übergang, eigene Switches, eigene Administration, definierte vermittelnde Systeme, bei Bedarf Datendioden	Mehrere Linien, Fernwartung, MES-Anbindung, prozessgefährdende Ausfallfolgen, KRITIS-, NIS-2- oder Kundenauflagen

Einen Zwischenweg gibt es dabei praktisch nicht: Eine eigene OT-Firewall zu beschaffen und dahinter wieder auf die IT-Switches zu gehen, bringt wenig. Entweder Sie setzen die Trennung logisch auf der vorhandenen IT-Infrastruktur um, oder Sie ziehen sie konsequent mit eigener Hardware durch. Die saubere Herleitung liefert die Risikobeurteilung nach IEC 62443-3-2, auf die wir weiter unten eingehen. Für ein erstes Gespräch reichen zwei Fragen: Was passiert, wenn diese Linie 48 Stunden steht? Und wer außerhalb des Unternehmens hat heute technisch Zugriff darauf?

Schwer ist diese Abwägung vor allem organisatorisch. Die IT kennt die Sicherheitsmechanismen, aber nicht die Prozessrisiken; die Produktion kennt die Anlage, aber nicht die Angriffsvektoren. Wir arbeiten deshalb konsequent als Übersetzer zwischen beiden Seiten und nennen diesen Ansatz Autolinguale IT. Ohne diese Übersetzungsarbeit bleibt jede Netzwerksicherheits-Architektur Theorie.

Bedrohungen und typische Schwachstellen

Die Einstiegspunkte sind selten exotisch. Am häufigsten sind kompromittierte Zugangsdaten aus der Office-IT und Phishing mit anschließender lateraler Bewegung, wie zuletzt bei den EvilTokens-Angriffen auf Microsoft 365. Dazu kommen ungesicherte Fernwartungszugänge, direkt aus dem Internet erreichbare Steuerungen und Wechseldatenträger bei Inbetriebnahmen. Strukturell begünstigt werden diese Wege durch flache Netze, Default-Passwörter, ungepatchte Systeme ohne kompensierende Maßnahme, fehlende Asset-Übersicht und historisch gewachsenes WLAN in der Produktion.

Wie real das ist, zeigt ein aktuelles Advisory: Unter AA26-097A berichtet die US-Behörde CISA seit April 2026 über die iranisch attribuierte Gruppe CyberAv3ngers, die speicherprogrammierbare Steuerungen von Rockwell, Schneider Electric und Siemens in kritischer Infrastruktur manipuliert. Neu daran ist der Zugriff auf die Projektdateien über die Konfigurationssoftware der Hersteller — bis hin zum Deaktivieren von Abschalt- und Alarmfunktionen, sodass eine Anlage in einen unsicheren Zustand geraten kann, ohne dass jemand alarmiert wird.

Was ein Angriff auf die Produktion konkret bedeutet

Pauschale Ausfallkosten pro Stunde kursieren zahlreich, belastbar sind sie selten: Sie vermischen die Auswirkung mit den Kosten der Ursachenbehebung und scheren Branchen mit unterschiedlicher Fertigungstiefe über einen Kamm. Produktiver ist die Frage, was konkret passiert: Lieferungen verzögern sich und lösen Vertragsstrafen aus, der Ruf beim Kunden leidet über die Ausschreibung hinaus, korrumpierte Systeme müssen getauscht statt bereinigt werden, der Wiederanlauf dauert länger als der eigentliche Stillstand, und laufende Chargen werden im Zweifel verschrottet.

So argumentieren Sie ein Budget ohne erfundene Zahlen. Nehmen Sie Ihre meistbelastete Linie und setzen Sie eine Ausfalldauer an, die Sie selbst begründen können; Maßstab ist Ihre Wiederanlaufzeit aus dem Backup, nicht ein Branchenwert. Trennen Sie anschließend zwei Posten. Nachholbar ist der Deckungsbeitrag, den Sie über Sonderschichten teilweise hereinholen; anzusetzen sind dann nur die Mehrkosten. Nicht nachholbar sind Vertragsstrafen, verschrottete Chargen, Requalifizierung und Ersatzhardware. Ohne diese Trennung kippt der erste Einwand aus der Geschäftsführung die ganze Rechnung.

Bekannte Vorfälle und was sie wirklich zeigen

Stuxnet (2010) manipulierte Siemens-Steuerungen in Natanz und war die erste Malware mit nachgewiesener physischer Zerstörungswirkung. Triton (2017) griff erstmals ein Sicherheitssystem an. Bei Colonial Pipeline (2021) traf die Ransomware dagegen die Business-IT; die OT-Segmente blieben intakt, abgeschaltet wurde vorsorglich aus dem Leitstand heraus, um das Produktionsnetz zu isolieren. Bei American Water (2024) meldete das Unternehmen unbefugte Aktivitäten in seinen IT-Netzen, nahm vorsorglich Systeme wie Kundenportal und Abrechnung vom Netz und erklärte in der SEC-Meldung, es gebe keine Hinweise auf eine Beeinträchtigung der Wasser- und Abwasseranlagen. Und bei Jaguar Land Rover (2025) stand die Produktion rund fünf Wochen, den volkswirtschaftlichen Schaden modelliert das Cyber Monitoring Centre auf 1,9 Milliarden Pfund.

Die für Sie relevanten Fälle folgen alle demselben Muster: Es waren IT-Vorfälle mit OT-Konsequenz. Die Ausnahmen sind staatlich getragene Operationen gegen einzelne Anlagen. Für Ihren Betrieb heißt das: Rechnen Sie nicht mit einem Stuxnet, sondern damit, dass ein gewöhnlicher Vorfall in der Office-IT Ihre Produktion zum Stillstand zwingt, weil Sie selbst abschalten.

Safety und Security: zwei Disziplinen, die sich gegenseitig bedingen

Wenn ein Vorfall die Produktion trifft, ist unmittelbar das oberste Schutzziel berührt: die funktionale Sicherheit. Sie ist keine Nebendisziplin der Security, sondern deren Bezugspunkt — und wird trotzdem selten mitgedacht. In der Prozessindustrie ist Security längst eine Safety-Pflicht. Die IEC 61511-1 (Ed. 2, 2016) verlangt in Abschnitt 8.2.4 eine Security-Risikobeurteilung für die Sicherheitseinrichtung, einschließlich aller angebundenen Systeme wie Engineering-Station und Fernzugriff. Im diskreten Maschinenbau greifen stattdessen ISO 13849-1:2023 und IEC 62061:2021. Ab dem 20. Januar 2027 kommt die Maschinenverordnung (EU) 2023/1230 hinzu, die Schutz gegen Korrumpierung der Steuerung zum Bestandteil der Risikobeurteilung und damit der CE-Konformität macht — ein Punkt, den Sie schon heute in Ausschreibungen fordern können.

Der Grund dafür ist grundsätzlicher Natur: SIL-Berechnungen modellieren zufällige Hardwareausfälle, keinen Angreifer. Eine kompromittierte Sicherheitssteuerung entwertet den kompletten Nachweis, ohne dass ein einziges Bauteil defekt wäre. Die Zahlen im Safety-Ordner stimmen weiter, ihre Aussage nicht mehr.

Die Gegenrichtung wird noch häufiger übersehen. PROFIsafe läuft nach dem Black-Channel-Prinzip über den normalen PROFINET-Verkehr und sichert sich selbst durch fortlaufende Nummerierung, Zeitüberwachung mit Quittung, Prüfsumme und einen eindeutigen Codenamen je Verbindung ab. Eine Firewall kann die Sicherheitsfunktion deshalb nicht kompromittieren. Sie kann aber etwas anderes auslösen, denn der sichere Zustand ist ein Anlagenstillstand: Wer Latenz in einen Safety-Kommunikationsweg bringt, erzeugt keinen Sicherheitsvorfall, sondern einen Produktionsausfall. Daraus folgt eine harte Architekturregel: Safety-Kommunikation quert keine Zonengrenze. Die Zone endet an der Zellgrenze.

Das Purdue-Modell: OT-Netzwerke richtig strukturieren

Wenn die Zonengrenze also an der Zelle endet — wo verlaufen dann die übrigen Grenzen? Dafür gibt es einen etablierten Ordnungsrahmen. Das Purdue-Modell, entwickelt von Theodore J. Williams an der Purdue University, ist bis heute die gemeinsame Sprache für OT-Netzarchitektur. Es ordnet die Anlage in Ebenen:

• • Level 0 umfasst Sensoren und Aktoren am physikalischen Prozess.

• • Level 1 enthält SPS, RTU und Sicherheitssteuerungen.

• • Level 2 beherbergt HMI und SCADA-Server einer Linie oder eines Bereichs.

• • Level 3 steht für anlagenweite Systeme wie MES, Historian und OT-Domänencontroller.

• • Level 3.5 ist die IDMZ, die Übergangszone zwischen OT und IT.

• • Level 4 und 5 trennen die Standort-IT von der Konzern-IT.

Zur Nummerierung kursieren zwei Varianten: Nach ISA-95 reicht die Hierarchie nur bis Level 4, in der Security-Praxis hat sich die Aufteilung auf Level 4 und 5 durchgesetzt. Wichtig ist, im Projekt eine Variante zu wählen und sie zu benennen.

Die IDMZ stammt nicht aus dem ursprünglichen Purdue-Modell, sondern aus der Referenzarchitektur von Cisco und Rockwell. In ihr stehen alle Systeme, die zwischen beiden Welten vermitteln: ein Jump Host für die Fernwartung, ein replizierter Historian für das Reporting, ein Server für die Patch-Verteilung. Ihr Prinzip lautet: Keine Session läuft durchgehend von der IT in die OT. Als Entwurfsziel gilt außerdem, dass die Anlage bei einem Ausfall der IDMZ weiterproduziert. Ob das in Ihrem Werk zutrifft, ist eine Messfrage: Prüfen Sie, wie lange der Auftragsvorrat im Fertigungsleitsystem reicht. Der Weg zu einer solchen Struktur führt über Netzwerksegmentierung.

IEC 62443 und der regulatorische Rahmen

Die IEC 62443 ist die maßgebliche Normenreihe für die Sicherheit industrieller Steuerungssysteme. Sie verteilt die Verantwortung auf drei Rollen: Teil 2-1 richtet sich an den Betreiber, Teil 2-4 an Integratoren und Serviceanbieter, die Teile 4-1 und 4-2 an die Hersteller. Für die Praxis am wichtigsten sind Teil 3-2 zur Risikobeurteilung und Teil 3-3 mit den Systemanforderungen; die Kernteile sind als DIN EN IEC übernommen.

Das methodische Herzstück sind Zonen und Conduits. Eine Zone gruppiert Assets mit gemeinsamen Sicherheitsanforderungen, etwa eine Fertigungslinie. Ein Conduit ist die Verbindung zwischen zwei Zonen und wird selbst wie eine Zone behandelt. Jede erhält ein Ziel-Level (SL-T); die Differenz zum erreichten Level (SL-A) ergibt die Maßnahmenliste.

Die Skala reicht von SL 1, dem Schutz gegen zufällige Verletzung, bis SL 4, dem Schutz gegen Angreifer mit erweiterten Ressourcen, IACS-spezifischen Fähigkeiten und hoher Motivation. Das Ziel-Level wird dabei pro Zone aus dem Risiko abgeleitet, nicht pauschal für ein Unternehmen. Und SL 2 ist auf einer Bestandsanlage kein Einstieg, sondern ein Modernisierungsprojekt. Realistisch ist deshalb ein gestaffeltes Vorgehen: SL 2 für neue und modernisierte Zonen, SL 1 mit dokumentierten kompensierenden Maßnahmen für den Bestand, verbunden mit einem festen Zeitpunkt für die Anhebung.

NIS-2 und KRITIS: wen die Pflichten treffen

Das NIS2-Umsetzungsgesetz ist seit dem 6. Dezember 2025 in Kraft; die Anforderungen stehen im neu gefassten BSIG. Betroffen sind rund 29.500 Einrichtungen. Voraussetzung ist immer die Zugehörigkeit zu einem erfassten Sektor; die Unternehmensgröße allein löst keine Pflicht aus. Erst dann greifen die Schwellenwerte: besonders wichtige Einrichtungen ab 250 Beschäftigten, wichtige ab 50 Beschäftigten. Alternativ greifen Finanzkennzahlen, bei denen Umsatz und Bilanzsumme gemeinsam erfüllt sein müssen (§ 28 BSIG). Betreiber kritischer Anlagen sind unabhängig von der Größe erfasst.

Die Meldepflicht ist dreistufig: Frühwarnung binnen 24 Stunden, Meldung mit erster Bewertung binnen 72 Stunden, Abschlussmeldung binnen eines Monats nach dieser 72-Stunden-Meldung. Adressat ist die gemeinsame Meldestelle von BSI und BBK. Praktisch am folgenreichsten ist aber eine andere Neuerung: Die Geschäftsleitung muss die Risikomanagementmaßnahmen umsetzen und ihre Umsetzung überwachen (§ 38 BSIG); verletzt sie diese Pflicht schuldhaft, haftet sie dem eigenen Unternehmen gegenüber für den Schaden. Hinzu kommt eine Schulungspflicht für die Geschäftsleitung selbst. Daneben regelt das KRITIS-Dachgesetz, seit dem 17. März 2026 in Kraft, die physische Resilienz kritischer Anlagen. Für die OT heißt das in beiden Fällen: Die geforderten Maßnahmen enden nicht am Bürotrakt.

Einen praxisnahen Einstieg in die konkreten Maßnahmen bietet das ICS-Security-Kompendium des BSI, das die Normanforderungen in Handlungsempfehlungen für Betreiber übersetzt.

Eine Einordnung in eigener Sache: Wir führen keine Audits durch, erteilen keine Zertifikate und geben keine Compliance-Zusagen. In unseren Projekten arbeiten wir aber nach den Strukturen, die Prüfer und Regulierer erwarten, also mit Zonendokumentation, Nachweisführung und Änderungshistorie. Nicht weil eine Vorgabe uns dazu zwingt, sondern weil es für uns Best Practice ist.

Wer macht was? Zuständigkeiten und Änderungen

OT-Security-Projekte scheitern selten an der Technik. Sie scheitern daran, dass im entscheidenden Moment niemand entscheiden darf. Klären Sie deshalb die wiederkehrenden Entscheidungen, bevor Sie die erste Firewall-Regel schreiben, und zwar schriftlich und mit Namen statt Abteilungen.

Entscheidung	Verantwortlich	Freigabe
Firewall-Regel in einer OT-Zone ändern	IT-Netzwerk	Produktionsleitung bei laufender Linie
Gerätetausch mit Netzfreigabe nachts	Instandhaltung	vorab delegiert, keine Einzelfreigabe
Herstellerzugang gewähren oder entziehen	Anlagenverantwortlicher	Schichtleitung pro Einsatz

Zwei Regeln machen diese Zuständigkeitsmatrix im Alltag tragfähig. Definieren Sie Freeze-Perioden, in denen grundsätzlich nichts geändert wird, etwa im Jahresabschluss oder im Hochlauf. Und legen Sie für jede Änderung vorab einen Rollback-Pfad fest, der in unter fünf Minuten greift und den auch die Rufbereitschaft nachts gehen darf.

Der häufigste undokumentierte Eingriff kommt übrigens nicht von einem Angreifer, sondern vom Servicetechniker des Maschinenbauers, der bei jedem Einsatz Parameter oder Logik ändert. Die Gegenmaßnahme wirkt zugleich gegen die im CISA-Advisory beschriebene Manipulation von Projektdateien: Sichern Sie den Projektstand als Referenz und vergleichen Sie ihn regelmäßig über eine Prüfsumme.

OT Security umsetzen: sieben Schritte

Umsetzen heißt hier nicht, alles auf einmal zu bauen. Ziel der folgenden sieben Schritte ist ein beherrschbarer OT-Betrieb: Sie wissen, was in Ihrem Netz hängt, wer darauf zugreift und was im Fehlerfall passiert. Am Ende stehen ein belastbares Inventar, eine begründete Zonenstruktur, kontrollierte Zugänge, bewertete Schwachstellen, eine funktionierende Alarmierung, ein geübter Notfallplan und eine gemessene Wiederanlaufzeit — zugleich die Nachweisgrundlage, die NIS-2 und IEC 62443 von Ihnen erwarten. Die Schritte bauen aufeinander auf, aber jeder einzelne senkt Ihr Risiko auch dann, wenn die folgenden noch offen sind.

Schritt 1 — Asset Management. Ein brauchbares Inventar unterscheidet sich von einem Netzwerk-Dump durch seine Felder: Hersteller, Typ, Firmware, Projektversion, zugeordnete Zone, Kritikalität, patchbar ja oder nein mit Begründung sowie Ort und Datum des letzten Backups. Bei der Erhebung rät NIST SP 800-82r3 zu ausdrücklicher Vorsicht mit aktiven Scans; in einer Sandia-Studie schwenkte ein Roboterarm nach einem Ping-Sweep um 180 Grad aus. Der Mittelweg heißt Safe Active Scanning: erst passiv lernen, dann gezielt nachfragen. Mit dem OT-Analyzer stellen wir ein Verfahren bereit, das die Topologie mit minimalem Eingriff visualisiert; wie Sie die Anlagen dabei strukturiert erfassen, zeigen unsere Checklisten.

Schritt 2 — Segmentierung und Zonierung. Aus dem Inventar wird eine Zonenstruktur: Zonen nach Prozessgrenzen bilden, Conduits definieren, eine Kommunikationsmatrix erstellen und erst dann das Regelwerk schreiben. Der Grundsatz lautet erst messen, dann filtern. Notieren Sie je Verbindung, wer die Session initiiert, und halten Sie fest, was nicht erlaubt ist. Zwei Dinge bringen die Matrix in der Praxis zu Fall. Das erste ist nicht routbarer Layer-2-Verkehr: PROFINET RT läuft ohne IP-Header, weshalb die Fertigungszelle die kleinste sinnvolle Zone bleibt. Das zweite sind überlappende IP-Bereiche, weil fast jede gelieferte Zelle ab Werk mit 192.168.0.x adressiert ist.

Schritt 3 — Zugriffskontrolle. Jeder Zugang braucht einen Eigentümer, ein Ablaufdatum und eine Protokollierung. Konkret heißt das: Multifaktor-Authentifizierung auch für Herstellerzugänge, Sitzungen über einen Jump Host, auf dem jede Fernwartung zwangsweise umbricht, statt direkt per VPN in die Fertigungszelle, und ein gehärtetes Active Directory, weil es in nahezu jeder Kompromittierungskette vorkommt. Systematisch beschreibt das unser Leitfaden zu Privileged Access Management.

Schritt 4 — Schwachstellenmanagement. Nicht jede Schwachstelle muss gepatcht werden, aber jede muss bewertet sein: bewerten, kompensieren, patchen im geplanten Stillstand. Untersagt ein Hersteller ein Update, lassen Sie sich das schriftlich geben; dahinter steht meist eine verhandelbare Freigabepolitik. Woher die Schwachstellen kommen, beantwortet CERT@VDE, das Advisories deutscher Automatisierungshersteller bündelt. Die Kontrolle über die verwaltbaren Systeme schafft Endpoint Management.

Schritt 5 — Monitoring. In statischen OT-Netzen ist das Signal-Rausch-Verhältnis besser als in der IT, allerdings unter zwei Bedingungen: Die Baseline muss einen vollständigen Produktmix abdecken, und es muss geklärt sein, wer nachts um drei auf einen Alarm was tun darf. Drei Detektionen lohnen sich ab dem ersten Tag, weil sie kaum Fehlalarme erzeugen: ein neues Gerät in einer Zelle, ein Logik-Download auf eine Steuerung und eine Verbindung, die in der Matrix nicht vorgesehen ist. Genau darauf zielen Anomalieerkennung und Bedrohungserkennung ab.

Schritt 6 — Incident Response. Systeme isolieren und neu aufsetzen ist keine Option, wenn ein laufender Prozess daran hängt. Drei Fragen muss der OT-Notfallplan beantworten: Wer entscheidet über einen kontrollierten Herunterfahrvorgang, und wer darf das nachts allein? Wie läuft die Anlage im Handbetrieb weiter? Und wie kommunizieren wir, wenn Mail und Telefonanlage Teil des Vorfalls sind? Die technische Basis ist eine hochverfügbare Infrastruktur mit erprobtem Wiederanlauf.

Schritt 7 — Backup und Wiederanlauf. Dieser Schritt entscheidet, ob ein Vorfall fünf Tage oder fünf Wochen kostet. Ein Runtime-Abzug reicht dafür nicht: Dazu gehören Projektquelle, Firmware-Stand, Antriebsparametrierung, Sicherheitsprogramm mit Prüfsumme, HMI-Rezepte und Lizenzen. Am häufigsten scheitert der Wiederanlauf jedoch an der passenden Version der Engineering-Software, denn ein Steuerungsprojekt lässt sich mit einer anderen Version nicht zurückspielen. Klären Sie außerdem, wem die Projektquelle gehört; liegt sie allein beim Maschinenbauer, können Sie im Schadensfall nicht selbst wiederherstellen. Der aussagekräftigste Test ist banal: einmal jährlich ein Backup auf Ersatzhardware zurückspielen und die Zeit messen. Diese Zahl ist Ihre echte Wiederanlaufzeit.

OT Security Roadmap: die ersten 90 Tage

Vorweg: Kein Betrieb startet bei null, und keine zwei Standorte stehen am selben Punkt. Verstehen Sie die folgenden 90 Tage deshalb nicht als Kalender, sondern als Reihenfolge. Wer bereits ein gepflegtes Asset-Inventar hat, überspringt den ersten Block und gewinnt Zeit für das Zonenkonzept; wer noch keine Übersicht besitzt, braucht für Tag 1 bis 30 unter Umständen zwei Monate. Prüfen Sie also zuerst, welcher Block bei Ihnen wirklich offen ist, und beginnen Sie dort. Das Ziel dieser 90 Tage ist in jedem Fall nicht, die Segmentierung im Betrieb zu haben. Dafür brauchen Sie Stillstandsfenster, und die gibt es zwei- bis dreimal im Jahr. Realistisch erreichbar ist etwas anderes: entscheidungsfähig zu werden. Die folgende Reihenfolge bringt die sieben Schritte in eine Abfolge, die sich ohne Stillstandsfenster durchhalten lässt.

Tag 1 bis 30. Zwei Dinge tun Sie sofort und ohne jede Analyse: verwaiste Fernwartungszugänge abschalten und die direkte Erreichbarkeit aus dem Internet beenden. Beachten Sie dabei, dass eine passive Innenaufnahme Maschinen mit eigener SIM-Karte gar nicht sieht. Diese finden Sie über eine Shodan-Suche auf Ihre eigenen IP-Bereiche und, oft ergiebiger, über die Frage an Einkauf und Instandhaltung, welche Mobilfunk- und DSL-Verträge auf Maschinen laufen. Parallel starten Sie die passive Netzwerkaufnahme, inventarisieren alle Fernwartungszugänge, aktivieren Multifaktor-Authentifizierung und stimmen die Änderung von Default-Passwörtern pro Anlage ab, statt sie pauschal auszurollen.

Tag 31 bis 60. In dieser Phase entsteht das Konzept. Sie erarbeiten die Zonen- und Conduit-Struktur nach IEC 62443-3-2, legen je Zone ein Ziel-Level fest und entwerfen die IDMZ. Parallel verabschieden Sie die Zuständigkeitsmatrix, dokumentieren die NIS-2-Betroffenheit und prüfen, ob zu jeder kritischen Linie ein vollständiges Backup existiert.

Tag 61 bis 90. Jetzt wird gemessen statt geplant. Lassen Sie das Firewall-Regelwerk im Monitor-Modus gegen die Kommunikationsmatrix laufen, setzen Sie zwei Pilotdurchsetzungen an einer unkritischen Linie um, protokollieren Sie einen Rückspieltest und spielen Sie den Notfallplan einmal mit der Produktion durch. Am Ende steht eine Investitionsvorlage; die eigentliche Umsetzung folgt danach, linienweise über neun bis achtzehn Monate.

Ihre Geschäftsleitung muss die Umsetzung nachweislich überwachen. Fünf Kennzahlen machen das möglich: Anteil vollständig inventarisierter Assets, Anzahl aus dem Internet erreichbarer OT-Geräte, Anteil externer Zugänge mit Eigentümer und Ablaufdatum, gemessene Wiederanlaufzeit je kritischer Linie und Zahl der Verbindungen außerhalb der Kommunikationsmatrix.

Was Sie selbst umsetzen können und wo ein Sparringpartner hilft

Vieles davon ist intern machbar, sobald IT und Produktion an einem Tisch sitzen. Anspruchsvoller wird es dort, wo Erfahrung aus vielen Anlagen den Unterschied macht: bei der Bewertung, welche Trennungstiefe wirklich angemessen ist, bei der Kommunikationsmatrix einer gewachsenen Linie und bei der Frage, welche Herstellerforderung verhandelbar ist und welche nicht. Uns geht es dabei nicht darum, Wissen zurückzuhalten. Wir teilen es offen, damit Sie intern Kompetenz aufbauen, sei es als Managed Service oder als Sparringpartner im Projekt. Wie das in der Praxis aussieht, zeigen unsere Referenzen.