In Produktionsumgebungen, in denen OT-Cybersicherheitsprogramme umgesetzt werden, zeigt sich immer wieder ein bestimmtes Muster. Das Audit wird ohne Beanstandungen abgeschlossen. Die Kontrollmaßnahmen sind dokumentiert. Alle Anforderungen des Rahmenwerks sind erfüllt. Und doch stimmt vor Ort etwas nicht – die Bediener finden Umgehungslösungen, die Reaktionszeiten haben sich verlangsamt oder ein Wartungsfenster ist komplexer geworden, als es sein sollte.
Die Systemprüfung wurde bestanden. Aber der Betrieb hat sich nicht verbessert.
Dies ist kein Versagen bei der Umsetzung. Es handelt sich um eine strukturelle Diskrepanz, die den Kern der Cybersicherheits-Compliance im Bereich der operativen Technik (OT) bildet und für deren Bewältigung die meisten Sicherheitsrahmenwerke nie konzipiert wurden.
Normen wie IEC 62443 und regulatorische Anforderungen wie NIS2 wurden entwickelt, um dort für Einheitlichkeit zu sorgen, wo zuvor keine herrschte. Sie legen fest, welche Kontrollmaßnahmen vorhanden sein müssen, welche Dokumentation zu führen ist und welche Governance-Strukturen eingerichtet werden müssen. Für Organisationen, die ihre Rechenschaftspflicht gegenüber Prüfern, Aufsichtsbehörden und Vorständen nachweisen wollen, erfüllen sie einen klaren Zweck.
Frameworks beantworten jedoch eine ganz bestimmte Frage: Sind die richtigen Dinge definiert?
Sie gehen nicht darauf ein: Was passiert, wenn dies in einer Produktionslinie umgesetzt wird, in der seit elf Jahren dieselbe SPS-Firmware läuft?
OT-Umgebungen sind keine homogenen Systeme, die nur darauf warten, gesichert zu werden. Es handelt sich um vielschichtige, heterogene und oft unzureichend dokumentierte Sammlungen von Geräten mit gegenseitigen Abhängigkeiten, die bei der Installation nicht erfasst und seitdem nicht mehr überprüft wurden. Altsysteme dominieren. Ausfallzeiten werden in realen Produktionskosten gemessen. Und die Beziehungen zwischen den Systemen – was mit was kommuniziert, unter welchen Bedingungen, mit welcher Toleranz gegenüber Änderungen – werden oft nur von denjenigen verstanden, die sie seit Jahren betreiben.
Compliance-Rahmenwerke gehen von einem Grad an Standardisierung aus, der in den meisten bestehenden Produktionsumgebungen schlichtweg nicht gegeben ist. Genau diese Annahme ist der Grund für die entstandene Lücke.
Ein produktionsorientiertes Framework für Hersteller, die ihre Betriebsabläufe sichern müssen, ohne sie zu beeinträchtigen.
In der Praxis hat es einen Namen, auch wenn er in Sicherheitsberichten selten auftaucht: konform, aber instabil.
Alle erforderlichen Kontrollmaßnahmen sind vorhanden. Die Prüfkriterien sind erfüllt. Auf dem Papier sieht die Sicherheitslage solide aus. Und doch ist der Betrieb der Anlage schwieriger als zuvor. Nicht dramatisch – keine einzelne Kontrollmaßnahme hat zu einem Zusammenbruch geführt –, aber betrieblich hat sich etwas verändert.
Drei Situationen veranschaulichen dieses Muster auf einheitliche Weise.
Die Segmentierung von OT-Netzwerken ist zu Recht eine grundlegende Kontrollmaßnahme in jedem seriösen OT-Sicherheitskonzept. Das Ziel ist die Eindämmung – die Begrenzung des Schadensumfangs im Falle eines Vorfalls. In einer Produktionsumgebung jedoch, in der bestimmte Systeme über Grenzen hinweg kommunizieren, die das Konzept nun als separate Zonen definiert, unterbricht eine starre Umsetzung bestehende Arbeitsabläufe. Manuelle Ausnahmeregelungen werden zur Routine. Die Bediener passen sich an, doch jede solche Umgehungslösung verursacht Reibungsverluste und untergräbt die Governance-Logik, die durch die Segmentierung eigentlich durchgesetzt werden sollte.
Das Installieren von Patches auf OT-Systemen wird im Rahmen von Normen wie IEC 62443-2-1 und den aus NIS2 abgeleiteten Anforderungen zunehmend zur Pflicht. Es wird ein Zeitplan erstellt, dokumentiert und eingehalten. Produktionssysteme in der Fertigung verfügen jedoch nicht über Wartungsfenster, die mit den Release-Zyklen der Anbieter übereinstimmen. Das Einbringen von Patches in Live-Umgebungen zum falschen Zeitpunkt führt zu Instabilität – und diese Instabilität hat oft länger anhaltende Auswirkungen auf den Betrieb als die Sicherheitslücke, die damit geschlossen werden sollte.
Die Reduzierung von Berechtigungen ist eine bewährte Sicherheitspraxis. Rollenbasierter Zugriff, zeitlich begrenzte Sitzungen, eine Architektur nach dem Prinzip der geringsten Berechtigungen – all dies ist vertretbar und überprüfbar. Wenn Zugriffsrichtlinien jedoch angewendet werden, ohne zu berücksichtigen, wie Betreiber und Anbieter unter realen Produktionsbedingungen tatsächlich mit den Systemen interagieren, ist das Ergebnis vorhersehbar: Es entstehen gemeinsam genutzte Konten, Zugriffskontrollen werden umgangen, und das Governance-Modell, das auf dem Papier solide wirkte, weicht bereits von der tatsächlichen Situation vor Ort ab.
In jedem Fall sind die Kontrollmechanismen theoretisch korrekt. Die Diskrepanz liegt in der Umsetzung – genauer gesagt darin, dass vor der Einführung keine operative Validierung stattgefunden hat.
Was dies besonders schwierig macht, ist die Tatsache, dass sich OT-Umgebungen bei Veränderungen anders verhalten als IT-Umgebungen. In der IT sind Sicherheitsverbesserungen in der Regel additiv. Eine Kontrollmaßnahme wird eingeführt, das System passt sich an, und die Sicherheitslage verbessert sich. Unbeabsichtigte Folgen treten zwar auf, sind aber in der Regel begrenzt und behebbar.
In der Betriebstechnik haben kleine Änderungen weitreichende Folgen. Ein Kommunikationsfluss, der jahrelang zuverlässig funktioniert hat, beruht auf zeitlichen Annahmen, die nirgendwo schriftlich festgehalten sind. Eine Segmentierungsregel, die in einem Netzwerkdiagramm übersichtlich aussieht, berührt einen veralteten SCADA-Handshake, den nur ein Ingenieur des Herstellers verstanden hat. Ein Firmware-Update, das in einer Laborumgebung validiert wurde, verhält sich anders in einer Anlage, in der seit sechs Tagen dieselbe Produktionscharge ohne Neustart läuft.
Die gegenseitigen Abhängigkeiten sind real. Oft sind sie nicht dokumentiert. Und Compliance-Rahmenwerke bilden sie nicht ab – weil sie dazu nicht in der Lage sind. Kein Standard kann die spezifische Betriebslogik der Systeme einer bestimmten Anlage vorhersagen.
Aus diesem Grund ist die Betriebsstabilität der wichtigste Maßstab für den Erfolg von Sicherheitsmaßnahmen in OT-Umgebungen, nicht die Ergebnisse von Audits. Ein Sicherheitsprogramm, das zwar die Compliance gewährleistet, aber die Stabilität beeinträchtigt, hat die Risikosituation des Unternehmens nicht verbessert – es hat das Risiko lediglich verlagert.
Die langfristige Folge von Compliance-orientierten OT-Sicherheitsprogrammen, die die Auswirkungen auf den Betrieb außer Acht lassen, ist eine ganz bestimmte Art von organisatorischer Abdrift.
Sicherheitsteams sorgen für die Einhaltung der Compliance-Vorgaben. Die operativen Teams passen sich den dadurch entstehenden Reibungsverlusten an – lokal, informell und ohne Dokumentation. Kontrollmaßnahmen werden auf Betriebsebene angepasst. Workarounds werden fester Bestandteil des täglichen Betriebs. Governance und operative Realität driften langsam auseinander.
Nach einer gewissen Zeit bestehen Diskrepanzen zwischen dem, was im Compliance-Rahmenwerk dokumentiert ist, und dem, was tatsächlich vor Ort geschieht. Die Prüfung wird weiterhin bestanden – denn die dokumentierten Kontrollmaßnahmen sind nach wie vor vorhanden. Doch die tatsächliche Sicherheitslage des Unternehmens, die im Ernstfall entscheidend ist, wird informell von Mitarbeitern verwaltet, deren Hauptanliegen darin besteht, den Produktionsbetrieb aufrechtzuerhalten.
Das ist kein Mangel an Disziplin. Es ist eine strukturelle Folge davon, dass Framework-Logik auf Umgebungen angewendet wird, für die die Frameworks nicht konzipiert wurden.
Der erforderliche Wandel besteht nicht darin, von der Einhaltung der Vorschriften zur Nichteinhaltung überzugehen. Die Anpassung an die Vorschriften gemäß NIS2 und IEC 62443 ist eine legitime Verpflichtung für produzierende Unternehmen, die in kritischen Sektoren tätig sind, und die damit verbundene Rechenschaftspflicht auf Führungsebene ist angemessen. Die Frage ist nicht, ob die Vorschriften eingehalten werden sollen – vielmehr geht es darum, was die Einhaltung allein nicht leisten kann.
Über die Frage „Halten wir die Vorschriften ein?“ hinaus müssen Führungskräfte in der Fertigung, die für die OT-Sicherheit verantwortlich sind, sich fragen:
Diese Fragen stehen nicht im Widerspruch zur Compliance. Sie sind es, die die Compliance nachhaltig machen – sie verhindern, dass sich die Kluft zwischen dem Sicherheitsmodell und der Praxis im Laufe der Zeit vergrößert.
Cybersicherheitsprogramme für die Betriebstechnik, die die Abläufe im Betrieb, Produktionsbeschränkungen und das tatsächliche Verhalten der Systeme berücksichtigen, sorgen nicht nur für die Einhaltung der Vorschriften. Sie sichern diese auch langfristig, da die implementierten Kontrollmaßnahmen so gestaltet sind, dass sie von der Anlage tatsächlich aufrechterhalten werden können.
