NIS2 trifft Shopfloor

Die Anforderungen von NIS2 sind hoch: Sie fordert von Unternehmen, Maßnahmen nach dem Stand der Technik zu definieren und umzusetzen, die ihrem spezifischen Risiko und den potenziellen Auswirkungen eines Vorfalls entsprechen. Indem sie Technik, Betrieb und Organisation verbinden sollen, müssen sie strategischer Natur sein.

Die NIS2-Richtlinie deckt alle Bedrohungen ab; Cyberangriffe zählen ebenso dazu wie Fehlbedienungen, physische Störungen oder Betriebsfehler, sobald sie Auswirkungen auf IT- oder OT-Systeme haben können. Daraus entstehen sehr konkrete Aufgaben: Unternehmen müssen ihre Assets und Architektur kennen, Vorfälle identifizieren und schnell entschärfen. Sie müssen die betriebliche Kontinuität sichern, ihre Lieferketten hinsichtlich Sicherheitsaspekten bewerten, Systeme sicher beschaffen und warten, außerdem die Wirksamkeit ihrer Sicherheitsmaßnahmen belegen und eine "Basishygiene" etablieren. Was darunter im Detail zu verstehen ist, legt die NIS2 nicht fest. Zusätzlich zu NIS2 können neue sektorspezifische Vorgaben kommen. Deshalb ist es entscheidend, dass ein Security-Programm lernfähig bleibt.

Unternehmen den Rücken stärken

Für alle gilt: Kein Tool kann Governance ersetzen, aber geeignete OT-Werkzeuge können Unternehmen den operativen Rücken stärken und Evidenz über die Implementierung der Sicherheitsmaßnahmen liefern. Zwei Beispiele zeigen, warum IEC 62443-2-1 sicherheitsrelevant und konkret ist.

Beispiel 1: Ein scheinbar harmloser Change

Ein typischer Vorfall beginnt harmlos: Ein Dienstleister ändert außerhalb des Change-Fensters schnell ein VLAN- oder ein Portprofil. Dies bleibt unbemerkt, denn die Linie läuft weiter. Doch plötzlich entstehen unerwünschte Verbindungen zwischen Zonen, etwa zwischen Office-Netz und Steuerungsnetz oder zwischen Safety-Segment und IACS (Industrial Automation and Control Systems). Ein gutes CM-Set-up, wie es in der IEC 62443-2-1 beschrieben wird, erkennt die Abweichung, vergleicht sie mit einer Baseline und zeigt den Unterschied nachvollziehbar an. Versionierte Konfig-Back-ups beschleunigen die Rückkehr zum freigegebenen Zustand, ohne dass Techniker im Störfall "nach Gefühl" etwas unternehmen. Diese Technik ersetzt kein Change-Board, doch sie verhindert, dass Sicherheitslücken im Prozess unbemerkt zu technischen Risiken führen.

Beispiel 2: Ein unbekanntes Gerät an einem Port

Ein unbekanntes Gerät hängt plötzlich an einem Switchport in der Produktion. In diesem Moment zählt Kontext: In welcher Zone befindet sich der Port, welche Conduits verbinden ihn mit anderen Bereichen und welche Systeme kann das Gerät potenziell erreichen? Handelt es sich um eine Safety-Zone mit sicherheitsgerichteten Funktionen, um eine Steuerungszone mit direktem Einfluss auf den Prozess oder lediglich um einen weniger kritischen Bereich? Die Antwort entscheidet darüber, ob ein Produktionsstillstand, eine Gefährdung von Personen oder nur ein begrenztes Betriebsrisiko droht.

Ein NET-Programm nach IEC 62443-2-1 stellt sicher, dass diese Zusammenhänge vorab strukturiert sind. Es fordert dokumentierte Zonen und Conduits, klar definierte Verantwortlichkeiten für Netzbereiche, geregelte Änderungsprozesse für Netzkonfigurationen sowie überwachte Übergänge zwischen Zonen. Monitoring-Systeme unterstützen diese Transparenz, indem sie neue Geräte, Topologieänderungen oder Firmware-Abweichungen umgehend sichtbar machen und Ereignisse nachvollziehbar dokumentieren. Auf dieser Grundlage lassen sich vorbereitete technische Maßnahmen gezielt umsetzen und Entscheidungen entlang festgelegter Verantwortlichkeiten treffen.

Der Weg zur Auditfähigkeit

Bei Audits ist es unerheblich, ob ein bestimmtes Tool eingesetzt wird. Entscheidend ist vielmehr, dass alle operativen Anforderungen erfüllt werden. Dazu gehören beispielsweise Inventarberichte mit einer dokumentierten Topologie, Event-Logs oder Nachweise über Wiederherstellungen, Konfig-Back-ups inklusive Historie, nachvollziehbare Änderungen, transparente Firmware-Versionen sowie lückenlos rückverfolgbare technische Gegenmaßnahmen. Gleichzeitig müssen Unternehmen Belege über organisatorische Aspekte wie Richtlinien und Rollen, Eskalationswege, Schulungen und Lieferantenvorgaben vorlegen, außerdem eine Risikologik, die erklärt, warum Controls so gewählt wurden. Genau hier hilft die Unterscheidung "operativer Beweis" versus "organisatorischer Beweis" aus dem OT-Alltag. OT-orientierte Netzwerkmanagement-Lösungen, wie beispielsweise die Software MXview One von Moxa, sammeln operative Beweise, während Governance-Artefakte in Management- und Qualitätsprozessen zusammengetragen werden.

Drei Schritte, die sofort Wirkung zeigen

Doch wie sollten Unternehmen am besten vorgehen, um das zu erreichen? Ein erster Schritt besteht darin, Risiken an ihren Auswirkungen auszurichten: Welche Anlagen und Abhängigkeiten würden bei einem Vorfall die Produktion, Safety oder Lieferfähigkeit am stärksten treffen? Im nächsten Schritt lohnt es sich, IEC 62443-2-1 als eine Art Landkarte zu nutzen und die operativen Schwergewichte zuerst zu stärken. Dazu zählen üblicherweise das Asset-Inventar, die Change-Kontrolle, Monitoring/Alarmierung sowie Back-up/Recovery. Zum Schluss braucht jedes Werk eine Beweislogik, die zum Risiko passt: Welche Reports, Logs und Protokolle belegen CM, Event, Avail, welche Dokumente belegen Org, User, Comp, Net Und Data? Wer diese beiden Ebenen verbindet, nimmt NIS2 die Abstraktheit und sorgt für eine auditfähige Compliance im Shopfloor.

Compliance ist kein Produkt, das man installiert, sondern ein Programm, das entwickelt und realisiert werden muss. NIS2 setzt den Erwartungsrahmen, IEC 62443-2-1 ordnet die Umsetzung, und ein diszipliniertes OT-Betriebsmodell macht daraus Praxis – im Alltag wie im Audit.

Laurent Liou, Product Marketing Manager, Moxa Europe