Cloud-Kapazität wird knapp, CIOs müssen jetzt planen
Bernhard Liebl
7 Min. Lesezeit 63 Prozent. So stark ist das Cloud-Geschäft von Google zuletzt im Jahresvergleich gewachsen, ...
Zum Beitrag
Werks-Geräte, Sensoren und Edge-Devices galten lange als Domäne der OT-Teams – für die CIOs wenig relevant. NIS2 hat das geändert. Wer jetzt nicht klärt wer die Governance trägt, läuft in den nächsten Audit mit offenem Flanke.
6 Min. Lesezeit
Das Wichtigste in Kürze
NIS2 macht OT zum CIO-Thema. Betreiber wesentlicher Einrichtungen in KRITIS-Sektoren müssen Edge-Devices und OT-Komponenten in ihren ISMS-Scope aufnehmen.
Governance-Lücke ist real. CISOs kennen die Sicherheitsanforderungen, aber nicht die OT-Assets. CIOs kennen die Assets, aber nicht den NIS2-Scope. Niemand trägt beides.
Board-Haftung ist persönlich. NIS2 macht Management-Mitglieder persönlich haftbar für Compliance-Versäumnisse – nicht nur die IT-Abteilung.
Incident-Meldepflicht gilt auch für OT-Incidents. 24-Stunden-Frühwarnung, 72-Stunden-Notifikation – auch wenn der betroffene Sensor im Werk steht.
Asset-Inventar ist der Anfang. Wer nicht weiß welche Edge-Devices im Netz hängen, kann sie weder schützen noch melden.
Was ist Industrial IoT im NIS2-Kontext? Industrial IoT bezeichnet vernetzte Geräte in Produktions-, Energie- und Infrastrukturumgebungen: Sensoren, Steuerungssysteme (PLCs, DCS), Edge-Gateways und Condition-Monitoring-Systeme. Sobald diese Geräte über Edge-Layer mit dem Corporate-Netzwerk verbunden sind, fallen sie für NIS2-betroffene Unternehmen in den ISMS-Scope. Der Unterschied zu klassischer IT-Security: OT-Geräte laufen oft ohne Patching-Möglichkeit, mit proprietären Protokollen und Laufzeiten von 10-20 Jahren.
Der Mechanismus der die Situation verändert hat ist simpel: NIS2 weitet den Anwendungsbereich gegenüber der ersten NIS-Richtlinie erheblich aus. Betroffen sind jetzt auch mittlere Unternehmen ab 50 Mitarbeitern oder 10 Mio. € Umsatz in bestimmten Sektoren – Energie, Verkehr, Wasser, Gesundheit, digitale Infrastruktur und verarbeitendes Gewerbe für kritische Produkte.
Das Ergebnis: Viele Unternehmen die bisher nicht im Regulierungsbereich standen, müssen jetzt ein vollständiges ISMS nachweisen – inklusive aller vernetzten Geräte. Und das umfasst in produzierenden Unternehmen typischerweise mehrere hundert bis mehrere tausend OT-Komponenten.
35.000+
KRITIS-betroffene Unternehmen in DE
Quelle: BSI-Schätzung NIS2-Scope, 2024
24 h
Frühwarn-Pflicht bei erheblichem Incident
Art. 23 NIS2-Richtlinie
10 Mio €
Maximalbußgeld wesentliche Einrichtungen
oder 2% des weltweiten Jahresumsatzes
Wer trägt die Governance: CIO oder CISO?
Die ehrliche Antwort lautet: das ist die offene Frage in den meisten DACH-Unternehmen. Die typische Situation sieht so aus: Der CISO kennt die NIS2-Anforderungen und die IT-Sicherheitsarchitektur, hat aber keinen Überblick über OT-Assets und keinen direkten Zugriff auf Werks-Systeme. Der CIO hat die Netzwerksicht und trägt die IT-Infrastruktur-Verantwortung, aber OT lag traditionell beim Produktions- oder Werksteam.
Aspekt
CIO
CISO
NIS2-Pflichten
Compliance-Framework-Verantwortung
Technische Sicherheitsmaßnahmen
OT-Asset-Inventar
Netzwerksicht vorhanden
Oft kein direkter Zugriff
Incident-Meldung
Nicht immer zuständig
Formell oft Erstverantwortlicher
Board-Reporting
Regelmäßige Board-Verbindung
Oft nur bei Incidents präsent
Die strukturelle Antwort die NIS2 erzwingt: Eine der beiden Rollen muss Ownership für den gesamten Asset-Scope übernehmen – und das Board muss das aktiv entscheiden. Nicht als Delegation, sondern als formelle Zuweisung die im ISMS dokumentiert ist.
Was Board-Reporting zu OT-Security jetzt enthalten muss
NIS2 schreibt explizit vor dass das Management regelmäßig über Cybersicherheitsrisiken informiert wird und Schulungen absolviert. Das bedeutet: OT-Security-Risiken müssen aus dem Technik-Reporting herausgehoben und in einem Format aufbereitet werden das Vorstands-Entscheidungen informiert.
Drei Elemente die in jedem Board-Report zu OT-Security fehlen:
Erstens: Anzahl und Kritikalität ungemanagter OT-Assets. Kein Inventory ist ein Risiko das sich quantifizieren lässt. Wenn von 800 OT-Devices 300 nicht im ISMS erfasst sind, ist das eine Board-Aussage.
Zweitens: Patch-Status und Known-Vulnerability-Exposure. OT-Geräte die seit Jahren keine Updates bekommen haben und bekannte CVEs enthalten, sind auditierbar und meldepflichtig wenn sie betroffen sind.
Drittens: Segment-Isolation-Status. Wie viele OT-Devices haben unkontrollierten Zugang zum Corporate-Netzwerk? Das ist die Frage die ein Auditor als erstes stellt.
Häufige Fragen
Gilt NIS2 auch für mittelständische Industrieunternehmen die nicht explizit KRITIS sind?
Ja, wenn sie in einen der regulierten Sektoren fallen und die Schwellenwerte überschreiten. NIS2 unterscheidet zwischen „wesentlichen Einrichtungen“ (größere Unternehmen in kritischen Sektoren) und „wichtigen Einrichtungen“ (mittelgroße Unternehmen). Auch „wichtige Einrichtungen“ unterliegen Sicherheitspflichten und Aufsicht – nur mit etwas geringeren Maximalstrafen. Produzierendes Gewerbe für kritische Produkte (Medizinprodukte, Chemie, Automotive) ist explizit im Scope.
Wie unterscheidet sich NIS2-Compliance von ISO 27001 für OT-Umgebungen?
ISO 27001 ist ein freiwilliger Standard mit wählbarem Scope. NIS2 ist gesetzliche Pflicht mit definiertem Scope. In der Praxis: Unternehmen mit ISO 27001 Zertifizierung haben eine gute Ausgangsbasis, aber der OT-Scope muss oft explizit erweitert werden. NIS2 fordert zusätzlich konkrete technische Maßnahmen (Supply-Chain-Security, Verschlüsselung, MFA) und Meldepflichten die über einen ISO 27001-ISMS-Nachweis hinausgehen.
Was sind die ersten drei Schritte für einen CIO der OT-Governance übernehmen muss?
Erstens: vollständiges OT-Asset-Inventar erstellen (Tools wie Claroty, Dragos oder Nozomi helfen bei passiver Netzwerkerkennung ohne Produktionsstörung). Zweitens: Netzwerksegmentierung zwischen OT und IT prüfen und dokumentieren wo die Grenzen tatsächlich verlaufen. Drittens: mit dem CISO formell klären wer welche Teile der NIS2-Anforderungen verantwortet und das in den ISMS-Dokumenten verankern.
Wie funktioniert die 24-Stunden-Meldepflicht bei einem OT-Incident in der Praxis?
Bei einem erheblichen Incident (signifikante Betriebsunterbrechung oder Auswirkung auf andere) muss innerhalb von 24 Stunden eine Frühwarnung an die zuständige Behörde (in Deutschland BSI) gesendet werden. Innerhalb von 72 Stunden folgt eine ausführlichere Meldung, nach einem Monat ein Abschlussbericht. Das erfordert intern klare Eskalationspfade und vordefinierte Meldevorlagen – die in den meisten OT-Umgebungen fehlen.
Welche Technologien helfen bei der OT-Security-Governance ohne Produktionsunterbrechung?
Passive Netzwerkerkennung (keine aktiven Scans die Steuerungssysteme stören könnten), OT-spezifische SIEM-Integration (Splunk OT Security, Microsoft Sentinel mit OT-Konnektoren) und Asset-Management-Plattformen die IT und OT in einer Ansicht zusammenführen. Wichtig: OT-Geräte reagieren anders auf Scans als IT-Geräte – aggressive Scanning-Verfahren aus der IT können in OT-Umgebungen Ausfälle verursachen.
Lesetipps der Redaktion
Quelle Titelbild: Pexels