In Industrieunternehmen galt Cybersicherheit lange als Teil der Büro-IT. Firewall, Virenschutz, Passwörter, Backups – während das Produktions- oder Energiesystem davon getrennt nach seiner eigenen technischen Logik lief.

Mit der Konvergenz von IT und OT ist diese Trennlinie verschwunden. SPS, Wechselrichter, Gebäudeautomation, SCADA, Gateways und Fernwartungsverbindungen können heute Teil desselben digitalen Risikoraums sein. Die Folgen bleiben dennoch physisch: stillstehende Produktion, fehlerhafte Regelung, ausfallende Energieversorgung oder nicht verfügbare Dienste.

Die NIS2 hebt das Management von Cyberrisiken deshalb auf die Ebene der Unternehmensleitung und der Organisation. Die IEC 62443 liefert dazu einen industriellen Sicherheitsansatz und ein Anforderungssystem, mit dem sich die OT-Umgebung auch technisch ordnen lässt.

NIS2 ist keine Einkaufsliste für Technik

Die NIS2-Richtlinie der Europäischen Union hat für 18 kritische Sektoren einen einheitlicheren Rahmen für Cybersicherheit geschaffen. Mittlere und große Unternehmen in ihrem Anwendungsbereich müssen geeignete Maßnahmen zum Risikomanagement sowie Prozesse zur Meldung von Sicherheitsvorfällen einführen. Die Richtlinie betont zudem ausdrücklich die Verantwortung der Geschäftsleitung.

Das ist eine wichtige Veränderung: Cybersicherheit lässt sich nicht unbegrenzt an einen Systemadministrator oder einen externen Dienstleister delegieren. Die Leitung muss verstehen und steuern, welche digitalen Abhängigkeiten den grundlegenden Betrieb gefährden.

Die NIS2 schreibt nicht vor, welche Firewall welches Herstellers anzuschaffen ist. Sie verlangt ein risikobasiertes Vorgehen, unter anderem:

  • Bewältigung von Sicherheitsvorfällen;
  • Aufrechterhaltung des Betriebs und Wiederherstellung;
  • Sicherheit der Lieferkette;
  • Schwachstellenmanagement;
  • Zugriffskontrolle;
  • Kryptografie und Kommunikationssicherheit;
  • Sicherheitsbewusstsein;
  • Bewertung der Wirksamkeit der Maßnahmen.

Ob eine bestimmte Organisation tatsächlich in den Anwendungsbereich fällt und welche nationalen Anforderungen für sie gelten (in Ungarn setzt das Gesetz XXIII von 2023 die NIS2 um), ist im Einzelfall anhand von Sektor, Größe, Dienstleistung und dem anwendbaren nationalen Recht festzustellen. Das Management technischer Risiken liegt jedoch auch dann im geschäftlichen Interesse, wenn ein Unternehmen letztlich nicht verpflichtet ist.

Warum ist das OT-Risiko besonders?

OT-Systeme haben lange Lebenszyklen. Anlagen, die zehn oder zwanzig Jahre alt sind, nicht mehr unterstützte Betriebssysteme oder Steuerungen, die sich ohne Produktionsstillstand kaum aktualisieren lassen, sind keine Seltenheit.

Außerdem gilt in der OT:

  • Verfügbarkeit und physische Sicherheit haben Vorrang;
  • Änderungen müssen wegen des Prozessrisikos getestet werden;
  • viele Geräte wurden nie für eine feindliche Netzwerkumgebung ausgelegt;
  • Fernzugriffe durch Hersteller oder Wartungsdienstleister sind häufig;
  • das Inventar der Anlagen und Geräte ist oft lückenhaft;
  • die Verantwortung verteilt sich auf IT, Automatisierung, Betrieb und Lieferanten.

Eine herkömmliche IT-Sicherheitsrichtlinie einfach zu übernehmen, reicht daher nicht aus.

Die Rolle der IEC 62443

Die Normenreihe ISA/IEC 62443 behandelt die Cybersicherheit industrieller Automatisierungs- und Steuerungssysteme über den gesamten Lebenszyklus. Sie richtet sich nicht nur an den Betreiber: Sie legt Anforderungen und Rollen auch für Gerätehersteller, Systemintegratoren und Anlagenbetreiber (Asset Owner) fest.

Ein zentraler Baustein des Ansatzes ist die Bildung risikobasierter Zonen und geregelter Kommunikationsverbindungen (Conduits) zwischen ihnen.

In eine Zone gehören Geräte mit ähnlichem Risiko und ähnlichem Schutzbedarf. Datenflüsse zwischen den Zonen dürfen nur über festgelegte Wege und Protokolle und nach festgelegten Regeln erfolgen.

Diese Denkweise ist wesentlich präziser als „Wir haben eine Firewall zum Internet“. Ein Angriff oder Fehler kann nämlich auch von innen ausgehen – über eine Fernwartungsverbindung, vom Laptop eines Lieferanten oder aus einem kompromittierten IT-System.

Die erste unbequeme Aufgabe: ein Inventar der Geräte und Datenverbindungen

Man kann nicht schützen, wovon man nicht weiß, dass es existiert.

Der erste wirkliche Schritt zur OT-Sicherheit ist deshalb meist nicht die Installation eines neuen Produkts, sondern die Erfassung der realen Umgebung:

  • welche SPS, HMIs, Zähler, Wechselrichter und Gateways in Betrieb sind;
  • mit welcher Firmware- und Softwareversion;
  • über welches Netz sie erreichbar sind;
  • mit wem und über welches Protokoll sie kommunizieren;
  • wer vor Ort und aus der Ferne auf sie zugreifen kann;
  • welcher Geschäfts- oder physische Prozess von ihnen abhängt;
  • was bei ihrem Ausfall oder ihrer Kompromittierung geschieht.

Das Inventar sollte keine statische Excel-Tabelle bleiben. Es lohnt sich, auch Änderungen, Zuständigkeiten, Ereignisse und Dokumente in ein nachvollziehbares System einzubinden.

Fernzugriff ist eine typische Schwachstelle

Industrielle Systeme benötigen häufig Unterstützung durch den Hersteller oder Integrator. Das Problem ist nicht der Fernzugriff an sich, sondern der unkontrollierte, dauerhafte und direkte Zugriff.

Für eine belastbare Lösung ist festzulegen:

  • wer die Verbindung aufbauen darf;
  • ob eine Mehrfaktor-Authentifizierung erforderlich ist;
  • welches konkrete System erreichbar ist;
  • in welchem Zeitfenster;
  • ob eine Freigabe vor Ort oder durch die Leitung erforderlich ist;
  • ob die Sitzung protokolliert werden kann;
  • wie die Berechtigung entzogen werden kann;
  • was bei Beendigung des Liefervertrags geschieht.

Eine Lösung nach dem Muster „AnyDesk ist auf dem Rechner, falls man es braucht“ ist bequem, aber keine Sicherheitsarchitektur.

Die Lieferkette gehört zur OT

In einem industriellen System bestimmt nicht nur das eigene Team die Sicherheit. Hardwarehersteller, Firmware-Lieferant, Integrator, Telekommunikationsanbieter und Cloud-Plattform können gleichermaßen Teil der Risikokette sein.

In der technischen Spezifikation und in den Verträgen sollten deshalb unter anderem geregelt sein:

  • der Support- und Update-Zeitraum;
  • die Art der Meldung von Schwachstellen;
  • die Anforderungen an Zugriff und Protokollierung;
  • Angaben zu Komponenten und Versionen;
  • die Zusammenarbeit während eines Sicherheitsvorfalls;
  • die Rückgabe von Daten und Konfigurationen.

Hier trifft die Lieferkettenperspektive der NIS2 auf den lebenszyklus- und rollenbasierten Ansatz der IEC 62443.

Funktionierende Sicherheit statt bloßer Compliance

Das Abhaken einer Auditliste allein stoppt keinen Angriff. Das eigentliche Ziel ist, dass die Organisation ihre kritischen Prozesse kennt, die Angriffsfläche verringert, Auffälligkeiten erkennt, die Ausbreitung begrenzt und den Betrieb nachweislich wiederherstellen kann.

OrigSmart ist in diesem Umfeld nicht bloß als Plattform zur Datenvisualisierung zu verstehen. Die gemeinsame Verwaltung von Feldgeräten, Gateways, Netzwerkverbindungen, Identitäten, Ereignissen und ausführbaren Prozessen hilft dabei, Sicherheitsanforderungen in technischen Betrieb zu überführen.

In den von OrigSmart betreuten Projekten ist Sicherheit als Teil der Architektur zu planen: segmentierte Verbindungen, minimal notwendige Berechtigungen, protokollierte Ereignisse, kontrollierter Fernzugriff, lokaler Fallback-Betrieb und nachvollziehbare Maßnahmen.

Die NIS2 macht deutlich, dass Cyberrisiken auf Organisationsebene ernst genommen werden müssen. Die IEC 62443 hilft, dies in die technische Realität von OT-Systemen zu übersetzen.

Sprechen wir über Ihr Projekt

Quellen

Hinweis: Dieser Artikel dient der allgemeinen fachlichen Information und stellt keine Rechts- oder Compliance-Beratung dar.