Fragen Sie einen Compliance-Manager eines beliebigen registrierten Versorgungsunternehmens, was ihm schlaflose Nächte bereitet, und nur sehr wenige werden antworten: „die Standards“. Die Standards sind schriftlich fixiert. Sie können gelesen, interpretiert und debattiert werden. Was tatsächlich für schlaflose Wochen vor einem Audit sorgt, ist etwas völlig anderes: die Diskrepanz zwischen dem, was eine Organisation zu tun glaubt, und dem, was sie tatsächlich zu einem bestimmten Datum für ein bestimmtes Asset belegen kann – und zwar mit einem Nachweis, der nicht nachträglich aus dem Gedächtnis rekonstruiert wurde.

Diese Lücke hat sich mit der zunehmenden Komplexität von Operational-Technology-Umgebungen (OT) weiter vergrößert. Eine Leitstelle, die einst ein paar Dutzend relevante Geräte verwaltete, überwacht heute Umspannwerke, Erzeugungsanlagen, Fernwirksysteme (RTUs) und herstellerunterstützte Systeme, die über Hunderte von Kilometern verteilt sind. Jedes einzelne dieser Assets kann eine Compliance-Verpflichtung begründen. Jede Verpflichtung erfordert Nachweise. Und Nachweise erledigen sich – im Gegensatz zu Richtlinien – nicht von selbst.

Dieser Druck hat eine ganz neue Kategorie von NERC-CIP-Compliance-Software hervorgebracht. Das Versprechen ist verlockend: Tabellenkalkulationen ersetzen, freigegebene Ordner ausmustern und eine Plattform die administrative Last tragen lassen. Die Realität ist differenzierter. Einige Plattformen reduzieren den Audit-Aufwand tatsächlich und verbessern gleichzeitig die Transparenz der IT-/OT-Sicherheit. Andere verlagern die manuelle Arbeit lediglich in eine schönere Benutzeroberfläche, sodass dieselben Mitarbeiter dieselbe Abstimmung vornehmen müssen – nur mit zusätzlichen Abonnementkosten.

Dieser Blog wurde für diejenigen geschrieben, die diese Entscheidung treffen müssen. Er schlüsselt die neun wichtigsten Funktionen auf, auf die es beim Vergleich von NERC-CIP-Compliance-Software ankommt, erklärt, wie diese in der Praxis erfolgreich umgesetzt werden, und stellt die Fragen vor, die zeigen, ob eine Plattform in einer realen Umspannwerk-Umgebung standhält oder nur in einer Demo-Umgebung.

Warum NERC CIP keine reine Dokumentationsübung mehr ist

Die Critical-Infrastructure-Protection-Standards basieren auf einer einfachen Prämisse: Betreiber, die den zuverlässigen Betrieb des Verbundnetzes (Bulk Electric System) beeinflussen können, müssen ihre kritischen Cyber-Assets identifizieren, schützen, überwachen und all dies nachweisen können. In den Anfangsjahren bestand dieser Nachweis größtenteils aus Beschreibungen. Teams schrieben Verfahrensanweisungen, sammelten Screenshots und legten Ordner an.

Drei Faktoren haben dies dauerhaft verändert.

Der erste Faktor ist die Skalierung. Digitale Umspannwerke, Fernwartungszugänge, cloudbasierte Prozessdatenarchive (Historians) und dezentrale Erzeugung haben die Anzahl der betroffenen Systeme vervielfacht. Eine manuelle Nachverfolgung, die für eine einzelne Leitstelle funktionierte, wird bei fünfzig Standorten unpraktikabel.

Der zweite Faktor ist die Taktung. Viele Anforderungen sind keine jährlichen Ereignisse, sondern wiederkehrende Fristen. Sicherheitsupdates müssen mindestens alle 35 Kalendertage auf ihre Anwendbarkeit hin überprüft werden. Änderungen der Baseline-Konfiguration müssen bei Systemen mit der höchsten Kritikalität in einem ähnlichen Zyklus überwacht werden. Berechtigungsprüfungen müssen mindestens einmal pro Kalendervierteljahr verifiziert werden. Berechtigungsüberprüfungen folgen einem 15-monatigen Zyklus. Ein verpasster Zyklus ist kein Versehen, sondern eine dokumentierte Abweichung.

Der dritte Faktor sind die finanziellen Konsequenzen. Bußgelder bei Verstößen können beträchtliche Summen pro Verstoß und Tag erreichen. Das größte öffentlich beigelegte Durchsetzungsverfahren in der Geschichte der Standards betraf ein einzelnes registriertes Unternehmen, umfasste 127 separate Verstöße und endete mit einem Vergleich in Millionenhöhe. Was in diesem Fall auffiel, war nicht das Vorhandensein hochentwickelter Angreifer – es gab keine. Die Feststellungen konzentrierten sich auf unvollständige Asset-Inventare, inkonsistente Prozesse über Geschäftsbereiche hinweg und eine Dokumentation, die nicht belegen konnte, was tatsächlich getan worden war.

Die teuersten Compliance-Fehler in diesem Sektor betrafen selten eine tatsächliche Sicherheitsverletzung. Sie betrafen Organisationen, die solide Arbeit leisteten, diese aber nicht nachweisen konnten.

Diese Unterscheidung ist bei der Bewertung von Software von entscheidender Bedeutung. Eine Plattform, die das Sicherheitsniveau verbessert, aber nicht auditierbare Nachweise liefert, wird bei einer Überprüfung dennoch durchfallen. Eine Plattform, die ansprechende Berichte auf der Grundlage veralteter Daten generiert, scheitert auf eine andere, weitaus gefährlichere Weise: Sie wiegt die Organisation in einer trügerischen Sicherheit.

Was NERC-CIP-Compliance-Software in einer OT-Umgebung tatsächlich leisten muss

Compliance-Tools für Unternehmen wurden für Umgebungen entwickelt, in denen Endgeräte aggressiv gescannt und Agenten problemlos bereitgestellt werden können und in denen ein Neustart eher eine Unannehmlichkeit als ein betriebliches Ereignis darstellt. Prozessnetzwerke (OT) funktionieren so nicht.

Ein Schutzrelais kann nicht ohne Rücksicht auf sein Antwortverhalten abgefragt werden. Eine speicherprogrammierbare Steuerung (PLC), die einen kontinuierlichen Prozess steuert, verträgt keine ungeplante Installation von Software-Agenten. Serielle Geräte an Legacy-Bussen melden sich nicht von selbst bei der Netzwerkidentifikation an. Viele Assets unterliegen Supportvereinbarungen der Hersteller, die einschränken, was auf ihnen installiert werden darf. Und in vielen Anlagen sind die Personen, die für die Compliance-Nachweise zuständig sind, auch für den reibungslosen Betrieb der Prozesse verantwortlich. Jede Minute zusätzlicher manueller Aufwand konkurriert daher direkt mit dem operativen Betrieb.

Die entscheidende Frage bei der Evaluierung lautet daher nicht: „Deckt diese Plattform die Standards ab?“ Das behaupten fast alle Anbieter. Die Frage ist vielmehr, ob sie Nachweise unter betrieblichen Bedingungen erfassen, strukturieren und verteidigen kann, die nie für Compliance-Zwecke konzipiert wurden.

Die folgenden neun Funktionen entscheiden über diesen Erfolg.

Abbildung 1: Die neun Funktionen, die Versorgungsunternehmen vergleichen sollten, gruppiert nach dem jeweiligen Ergebnis.

Die 9 Funktionen, die Versorgungsunternehmen vergleichen sollten

1. Automatisierte und kontinuierliche OT-Asset-Inventarisierung

Alles Weitere hängt hiervon ab. Klassifizierung, Baselines, Patch-Management, Zugriffskontrolle und Berichterstellung übernehmen die Genauigkeit – oder die Fehler – der zugrunde liegenden Asset-Liste. Wenn Compliance-Feststellungen auf eine Ursache zurückgeführt werden, ist ein unvollständiges Inventar eine der häufigsten Fehlerquellen.

Eine leistungsfähige Plattform baut das Inventar nach Möglichkeit passiv auf, indem sie die Netzwerkkommunikation überwacht, ohne Datenverkehr zu erzeugen, der eine Regelschleife stören könnte. Sie sollte Hersteller, Modell, Firmware-Version, installierte Software, Netzwerkposition und Kommunikationsbeziehungen identifizieren. Zudem muss sie Bereiche abdecken, die eine rein passive Überwachung nicht erfassen kann: seriell angebundene Geräte, Air-Gap-Segmente und Systeme, die nur bei aktiver Abfrage antworten.

Was Sie bei der Evaluierung testen sollten: Bringen Sie ein Gerät in einem Testsegment online und prüfen Sie, wie lange die Plattform benötigt, um es zu erkennen, zu klassifizieren und der richtigen Netzwerkzone zuzuordnen – und ob dies ohne manuelle Dateneingabe geschieht.

2. Identifizierung und Klassifizierung von BES-Cyber-Systemen

Sobald Assets bekannt sind, müssen sie Systemen zugeordnet und nach ihrer Kritikalität (High, Medium, Low Impact) klassifiziert werden. Diese Einstufung bestimmt, welche Anforderungen gelten. Eine falsche Klassifizierung birgt Risiken in beide Richtungen: Eine zu geringe Einstufung führt zu Verstößen, eine zu hohe Einstufung belastet den Betrieb über Jahre hinweg unnötig mit Anforderungen für Systeme, die dies gar nicht erfordern.

Starke Plattformen unterstützen die Klassifizierung als lebendigen, dokumentierten Prozess und nicht als einmalige Tabellenkalkulation. Sie protokollieren die angewendeten Kriterien, bewahren die Argumentation hinter jeder Entscheidung auf, kennzeichnen Assets, deren Rolle oder Konnektivität sich geändert hat, und unterstützen den 15-monatigen Überprüfungszyklus, ohne dass die gesamte Bewertung von Grund auf neu erstellt werden muss.

Was Sie fragen sollten: Schlägt die Plattform bei der Erkennung eines neuen Assets eine Klassifizierung inklusive Begründung vor, oder fügt sie lediglich eine Zeile hinzu und wartet auf die manuelle Entscheidung eines Mitarbeiters?

3. Mapping von Kontrollmaßnahmen auf Anforderungen (Control-to-Requirement Mapping)

Hier scheitern viele Evaluierungen. Eine Plattform listet die Standards auf, zeigt einen Compliance-Prozentsatz an, und die Demonstration wirkt vollständig. Eine Liste von Anforderungen ist jedoch kein Kontroll-Mapping.

Ein effektives Mapping verbindet jede Anforderung mit der spezifischen technischen oder prozessualen Kontrollmaßnahme, die sie erfüllt, dem System oder Standort, an dem diese Maßnahme greift, der verantwortlichen Person und dem Nachweisdokument, das dies belegt. Dieser Kette folgt ein Auditor. Fehlt ein Glied, beschreibt das Unternehmen lediglich eine Absicht, anstatt eine wirksame Kontrolle nachzuweisen.

Dieses Mapping sollte auch umgekehrt funktionieren. Wenn sich eine Firewall-Regel ändert oder eine Kontrollmaßnahme außer Kraft gesetzt wird, sollte die Plattform sofort anzeigen, welche Anforderungen davon betroffen sind – bevor das nächste Audit dies aufdeckt.

4. Erfassung, Archivierung und Reproduzierbarkeit von Nachweisen

Nachweise sind das eigentliche Produkt, das Compliance-Teams liefern müssen. Alles andere dient nur der Unterstützung.

Der entscheidende Unterschied liegt zwischen Nachweisen, die kontinuierlich erfasst werden, und solchen, die nachträglich zusammengetragen werden. Ein Screenshot, der während der Audit-Vorbereitung erstellt wird, zeigt die Konfiguration im aktuellen Zustand. Er sagt nichts über die letzten achtzehn Monate aus. Eine kontinuierliche Erfassung dokumentiert Zustandsänderungen mit Zeitstempeln, Zuordnung der Quelle und dem Kontext, der den Nachweis revisionssicher macht.

Die Aufbewahrung ist ebenso wichtig. Audit-Zeiträume können mehrere Jahre zurückreichen. Eine Plattform, die nur rollierende, aktuelle Daten speichert, zwingt die Teams genau dann zur manuellen Recherche in Archiven, wenn der Druck am größten ist.

Was Sie überprüfen sollten: Fordern Sie einen spezifischen Nachweis an, der genau achtzehn Monate in der Vergangenheit liegt – keinen heute generierten Bericht, sondern den damals erfassten Datensatz mit lückenlosem Herkunftsnachweis (Chain of Custody).

5. Überwachung von Konfigurations-Baselines und Änderungen

Das Baseline-Management gehört zu den betrieblich anspruchsvollsten Bereichen der Standards. Systeme müssen über dokumentierte Baseline-Konfigurationen verfügen, Änderungen müssen autorisiert und dokumentiert werden, und diese Änderungen müssen in einem definierten Zyklus überwacht werden – bei Systemen mit höchster Kritikalität mindestens alle 35 Kalendertage.

Hier decken sich Compliance und tatsächliche IT-/OT-Sicherheit am deutlichsten. Eine nicht autorisierte Konfigurationsänderung ist sowohl ein Compliance-Verstoß als auch eines der frühesten Anzeichen für ein Eindringen oder fehlerhafte technische Eingriffe.

Eine leistungsfähige Plattform pflegt Baselines automatisch, erkennt Abweichungen, unterscheidet durch Integration in das Change Management autorisierte von unbefugten Änderungen und hält eine vollständige Versionshistorie vor. Schwächere Plattformen speichern lediglich ein Dokument namens „Baseline“ und verlangen vom Anwender einen manuellen Abgleich.

Was Sie fragen sollten: Erkennt die Plattform eine Änderung der Firmware-Version auf einer Steuerung im Feld (SCADA/PLC) oder nur auf Servern und Workstations?

6. Schwachstellen- und Patch-Management für die betriebliche Praxis

Die Anforderungen an das Patch-Management werden häufig missverstanden. Es wird nicht verlangt, dass jeder Patch sofort installiert wird. Es wird verlangt, dass Patches in einem wiederkehrenden 35-Tage-Zyklus auf ihre Anwendbarkeit hin überprüft werden und dass das Unternehmen innerhalb von 35 Kalendertagen nach Abschluss dieser Prüfung entweder den Patch einspielt, einen datierten Minderungsplan (Mitigation Plan) dokumentiert oder einen bestehenden Plan aktualisiert.

Diese Strukturierung ist bewusst gewählt. Regulierungsbehörden wissen, dass eine laufende Turbine nicht willkürlich gepatcht werden kann. Was sie jedoch nicht akzeptieren, ist Untätigkeit – eine Schwachstelle, die nie bewertet wurde, oder ein Minderungsplan, der nur als mündliche Absprache zwischen zwei Ingenieuren existiert.

Gute Software verfolgt den Bewertungszyklus, gleicht Sicherheitswarnungen mit den tatsächlich in der Umgebung vorhandenen Asset-Versionen ab, unterstützt strukturierte Minderungspläne mit Verantwortlichen und Prüfdaten und priorisiert nach dem tatsächlichen betrieblichen Risiko statt nach generischen Schweregraden (Severity Scores). Eine kritische Schwachstelle auf einem isolierten Gerät ohne Fernzugriff erfordert oft weniger Eile als eine mittelschwere Schwachstelle auf einem System, das über einen Fernzugriffspfad erreichbar ist.

7. Access Governance und wiederkehrende Überprüfungen

Die Anforderungen an die Zugriffskontrolle sind vielschichtig: Wer ist autorisiert, wofür besteht die Autorisierung, ist diese noch gültig, wie schnell wird sie beim Ausscheiden eines Mitarbeiters entzogen und wie wird der Fernzugriff kontrolliert und überwacht. Die Überprüfungen erfolgen vierteljährlich für Autorisierungsnachweise und im 15-Monats-Zyklus für die Berechtigungsgenauigkeit. Der Entzug des Zugriffs nach dem Ausscheiden von Mitarbeitern bemisst sich in Tagen, nicht in Wochen.

Die betriebliche Herausforderung besteht darin, dass OT-Zugriffe an vielen Stellen gleichzeitig verwaltet werden – in Domain-Konten, lokalen Gerätekonten, gemeinsamen Engineering-Credentials, Herstellerkonten, Remote-Access-Gateways und physischen Zutrittssystemen. Ein manueller Abgleich ist langsam und fehleranfällig. Gemeinsam genutzte oder lokale Konten auf Feldgeräten sind die Stellen, an denen Überprüfungen am häufigsten scheitern.

Eine starke Plattform konsolidiert diese Quellen in einer einzigen, prüfbaren Ansicht, dokumentiert den Abschluss von Prüfungen als eigenständigen Nachweis und kennzeichnet Konten, die auf Geräten existieren, aber im Autorisierungsnachweis nicht auftauchen.

8. Vorfallserkennung und Meldungsbereitschaft (Incident Readiness)

Die Fristen für meldepflichtige Vorfälle betragen oft nur eine Stunde ab dem Zeitpunkt der Feststellung, wobei versuchte Kompromittierungen bis zum Ende des nächsten Kalendertages zu melden sind. Diese Zeitvorgabe ist nicht einzuhalten, wenn der Reaktionsprozess erst mit der Suche nach grundlegenden Fakten beginnt.

Meldungsbereitschaft bedeutet, dass die für eine Bewertung und Meldung erforderlichen Informationen bereits vorliegen: Welche Assets waren beteiligt, wie hoch ist deren Kritikalität, was wurde wann geändert, wer hatte Zugriff und welche Netzwerkkommunikation ging dem Ereignis voraus. Eine Plattform, die hier unterstützt, verkürzt die erste Stunde von einer aufwendigen Untersuchung auf eine reine Bestätigung.

Sie sollte auch die Übungs- und Dokumentationsanforderungen für Notfallpläne unterstützen – denn ein Notfallplan, der nie getestet wurde, erweist sich meist im ungünstigsten Moment als unzureichend.

9. Berichterstattung, Erstellung von Audit-Paketen und Selbsteinschätzung

Diese letzte Funktion wird bei Präsentationen oft zuerst gezeigt, bei der Evaluierung jedoch zuletzt bewertet. Dashboards sind schnell erstellt und optisch ansprechend. Entscheidend ist jedoch, ob die Plattform ein Nachweispaket genau so strukturieren kann, wie ein Auditor es erwartet: nach Anforderungen geordnet, mit angehängten Nachweisdokumenten, eindeutigen Quellenangaben und lückenlosen Datumsangaben.

Ebenso wertvoll ist eine ehrliche interne Berichterstattung. Die nützlichsten Plattformen zeigen auf, wo Nachweise lückenhaft sind, welche Kontrollen nur auf Behauptungen beruhen und wo Fristen ablaufen. Ein Tool, das immer einen perfekten Compliance-Status anzeigt, hilft nicht weiter – es verzögert lediglich eine Diskussion, die später unter ungünstigeren Bedingungen geführt werden muss.

Die folgende Tabelle fasst zusammen, was für jede Funktion zu überprüfen ist.

Was reale Vorfälle über Compliance-Lücken offenbaren

Untersuchungsergebnisse und öffentliche Sicherheitsvorfälle zeichnen ein klares Bild. Die entscheidenden Fehler sind selten exotischer Natur. Meist handelt es sich um alltägliche Lücken, die bestehen blieben, weil sie schlicht nicht erkannt wurden.

Eine bekannte Schwachstelle, ein ungepatchtes Edge-Gerät und zehn Stunden Sichtbarkeitsverlust

Im März 2019 erlebte ein Energieversorger im Westen der USA den ersten öffentlich bekannten Cyber-Vorfall in dieser Region, der den Netzbetrieb beeinträchtigte. Die Ursache war kein hochentwickelter Angriff. Eine bekannte Schwachstelle in einer internetseitig erreichbaren Firewall wurde ausgenutzt, was dazu führte, dass die Geräte über einen Zeitraum von etwa zehn Stunden hinweg ständig neu starteten. Jeder Neustart unterbrach die Kommunikation zwischen der Leitstelle und den entfernten Wind- und Solaranlagen für jeweils mehrere Minuten.

Die Stromerzeugung selbst war nie gefährdet, wohl aber die Transparenz. Die Bediener in der Leitstelle verloren in kurzen, wiederkehrenden Abständen jegliche Sicht auf die verteilten Standorte und konnten den Zustand der Assets, für die sie verantwortlich waren, nicht überprüfen.

Besonders aufschlussreich ist, dass ein Firmware-Update zur Behebung dieser Schwachstelle bereits verfügbar war. Das Unternehmen hatte es lediglich nicht eingespielt – und, was noch schwerer wiegt, nicht erkannt, dass diese spezifischen Geräte an einer kritischen Schnittstelle saßen, deren Ausfall die Sichtbarkeit des gesamten Betriebs beeinträchtigen würde. Genau an dieser Schnittstelle müssen Asset-Inventar, Patch-Evaluierung und Netzwerktopologie-Erkennung ineinandergreifen.

Das Millionen-Dollar-Dokumentationsproblem

Das größte öffentlich bekannte Verfahren in der Geschichte der Standards resultierte nicht aus einem gezielten Angriff. Es resultierte aus 127 über mehrere Geschäftsbereiche und Jahre hinweg angehäuften Verstößen. Diese betrafen die inkonsistente Umsetzung von Prozessen, von deren ordnungsgemäßer Durchführung das Unternehmen fest ausging.

Mehrere Schwachpunkte zogen sich durch die Ergebnisse: Assets, die zwar relevant, aber nicht im Inventar erfasst waren, Nachweise, die für den geforderten Zeitraum nicht erbracht werden konnten, und Prozesse, die in verschiedenen Teilen der großen Organisation unterschiedlich gehandhabt wurden. Jede einzelne Lücke für sich war geringfügig. In ihrer Gesamtheit führten sie zum teuersten Compliance-Verfahren der Branche.

Für jeden, der Software bewertet, definiert dieser Fall den Maßstab. Die Frage ist nicht, ob eine Plattform Compliance ansprechend darstellen kann, sondern ob sie diese Lücken aufgezeigt hätte, als sie noch klein und korrigierbar waren.

Angriffe, die das Bild von Steuerungssystem-Infiltrationen verändert haben

Im Dezember 2015 führten koordinierte Angriffe auf drei Stromnetzbetreiber in der Ukraine dazu, dass rund 225.000 Kunden vorübergehend ohne Strom waren. Die Angreifer manipulierten die Steuerungssysteme nicht durch rohe Gewalt. Sie verschafften sich legitime Vorrechte für den Fernzugriff, analysierten die Umgebung in aller Ruhe und nutzten dann die werkseigenen Tools der Betreiber gegen sie selbst: Sie öffneten Leistungsschalter über die regulären Schnittstellen, überschrieben die Firmware von Seriell-zu-Ethernet-Konvertern, um eine Fernwartung zu verhindern, löschten Bediener-Workstations und blockierten die Telefonhotline des Energieversorgers, um die Reaktion zu verzögern.

Ein Jahr später zeigte ein zweiter Angriff auf ein Umspannwerk Schadsoftware, die direkt in Industrieprotokollen kommunizieren und gültige Steuerbefehle senden konnte, ohne dass dafür eine aktive Bediener-Sitzung kompromittiert werden musste. Im Jahr 2022 wurde eine weiterentwickelte Version dieser Schadsoftware gegen Hochspannungs-Umspannwerke eingesetzt, jedoch erkannt, bevor sie Schaden anrichten konnte. Im gleichen Zeitraum wurde ein modularer Werkzeugkasten bekannt, der speziell für die herstellerübergreifende Manipulation von speicherprogrammierbaren Steuerungen (PLC) entwickelt wurde – das erste bekannte Tool, das für den wiederholten Einsatz in unterschiedlichen Industrieumgebungen konzipiert wurde, anstatt auf ein einzelnes Ziel zugeschnitten zu sein.

Der gemeinsame Nenner ist, dass legitime Zugriffe, valide Protokollbefehle und unmonitored Konfigurationsänderungen die bevorzugten Pfade der Angreifer sind. Genau das sind die Bereiche, die laut den Standards kontrolliert und lückenlos dokumentiert werden müssen. Deshalb sind Compliance-Nachweise und sicherheitsrelevante Telemetriedaten zunehmend identisch.

Der Ausfall, der im Büronetzwerk begann

Im Mai 2021 stellte ein großer Betreiber einer Kraftstoffpipeline den Betrieb auf einer Länge von rund 5.500 Meilen ein, nachdem ein Ransomware-Angriff seine Bürosysteme (IT) infiziert hatte. Die eigentlichen Steuerungssysteme (OT) waren nicht betroffen. Der Betreiber stoppte den Betrieb, weil er die Grenze zwischen der betroffenen IT-Umgebung und der OT-Umgebung nicht mit Sicherheit bestimmen konnte und die Abrechnungssysteme ausgefallen waren.

Die daraus resultierenden Versorgungsengpässe an der US-Ostküste und die darauffolgenden regulatorischen Reaktionen machten eines deutlich: Die Folge mangelnder Transparenz bei der Netzsegmentierung ist nicht nur ein Einbruchsrisiko. Es ist die Unfähigkeit, unter Druck schnelle und sichere betriebliche Entscheidungen zu treffen. Dokumentierte Netzgrenzen, aktuelle Asset-Daten und eine klare Zuordnung von Zugriffsrechten sind das, was es einem Betreiber ermöglicht, den Betrieb aufrechtzuerhalten, wenn die Antwort gesichert lautet: „Das Prozessnetzwerk ist nicht betroffen.“

Abbildung 2: Compliance-Nachweise entstehen auf allen Ebenen des Prozessnetzwerks. Deshalb ist die Konsolidierung – und nicht die reine Erfassung allein – der entscheidende Erfolgsfaktor.

Risiken und Herausforderungen bei der Softwareauswahl

Das Dashboard statt der Datenbasis kaufen

Visuelle Aufbereitung ist am einfachsten zu realisieren, aber am schwersten objektiv zu bewerten. Ein Compliance-Prozentsatz ist nur so viel wert wie die Daten, die dahinterstehen. Bevor Sie sich von einer Kennzahl beeindrucken lassen, fragen Sie, welche Daten diese erzeugt haben, wie aktuell diese sind und was mit der Kennzahl passiert, wenn ein Asset keine Daten mehr sendet. Wenn ein Gerät verstummt und sich die Kennzahl nicht verändert, ist sie lediglich Dekoration.

Der blinde Fleck bei seriellen und nicht routingfähigen Geräten

Viele Plattformen basieren auf der Analyse des Netzwerkverkehrs, was in gerouteten Netzwerken gut funktioniert, andernorts jedoch kaum. Umspannwerke und Industrieanlagen enthalten einen erheblichen Anteil an Geräten, die über serielle Verbindungen, isolierte Engineering-Netzwerke und Punkt-zu-Punkt-Verbindungen angebunden sind. Diese Assets sind oft die ältesten, betriebskritischsten und am wenigsten dokumentierten. Eine Plattform, die diese Geräte stillschweigend ignoriert, liefert ein unvollständiges Inventar.

Nachweise, die mit der Zeit an Wert verlieren

Nachweise haben eine begrenzte Halbwertszeit. Ein mit vollständigem Kontext erfasster Datensatz ist über Jahre hinweg revisionssicher. Ein einfacher Screenshot ohne Zuordnung der Quelle wird bereits nach wenigen Monaten fragwürdig, insbesondere bei Personalwechseln. Viele Organisationen stellen dies erst fest, wenn der zuständige Ingenieur das Unternehmen verlassen hat und niemand mehr erklären kann, was der Beleg eigentlich zeigt.

Enterprise-Tools im Prozessnetzwerk (OT)

Standard-Sicherheitsplattformen für die Unternehmens-IT werden oft in die OT ausgerollt, da bereits Lizenzen vorhanden sind. Wirtschaftlich ist das verlockend, die Ergebnisse sind es oft nicht. Aggressive Scans, die Installation von Agenten auf leistungsschwachen Geräten und IT-typische Annahmen über Wartungsfenster berufen erhebliche betriebliche Risiken. Es gibt dokumentierte Fälle aus verschiedenen Branchen, in denen routinemäßige IT-Scans Steuerungssysteme gestört haben, die nie für solche Datenmengen ausgelegt waren. Compliance-Software für die OT muss auf Risikominimierung ausgelegt sein.

Low-Impact-Assets als Aufwandstreiber unterschätzen

Eine Einstufung als „Low Impact“ reduziert zwar die Anzahl der anwendbaren Anforderungen. Sie entbindet jedoch nicht von Pflichten bezüglich Richtlinien, Schulungen, physischer Sicherheit, elektronischer Zugriffskontrolle, Vorfallsreaktion und dem Umgang mit temporären Geräten (Transient Devices). Auch das Interesse von Angreifern verringert sich dadurch nicht. Der oben beschriebene Vorfall von 2019 betraf genau diese Kategorie. Plattformen, die sich nur auf High- und Medium-Impact-Systeme konzentrieren, lassen den größten Teil der Geräte unüberwacht.

Der folgende Vergleich zeigt, was sich bei einer erfolgreichen Implementierung dieser Funktionen ändert.

Praktische Empfehlungen zur Evaluierung von NERC-CIP-Compliance-Software

Beginnen Sie mit Ihren konkreten Nachweispflichten, nicht mit der Feature-Liste

Dokumentieren Sie vor dem Gespräch mit Anbietern, wofür die meiste Arbeitszeit aufgewendet wird. Welche Anforderungen kosten am meisten Zeit? Welche Nachweise sind am schwersten zu erbringen? Wo gab es beim letzten Audit Rückfragen? Dieses interne Bild bildet Ihre Bewertungskriterien. Ohne diese Vorarbeit wird jede Präsentation beeindruckend wirken – denn genau dafür sind sie konzipiert.

Bestehen Sie auf einem Proof of Value (PoV) in einer realen Umgebung

Präsentationen basieren auf sorgfältig vorbereiteten Daten. Implementieren Sie eine begrenzte Teststellung in einem repräsentativen Umspannwerk oder einer Anlage – idealerweise an einem Standort mit einem Mix aus moderner und älterer Technik. Messen Sie, wie viele Assets tatsächlich erkannt werden im Vergleich zu den bekannten Geräten, wie viel manueller Pflegeaufwand nötig ist und wie sich die Plattform bei unbekannten Geräten verhält.

Bewerten Sie die Fehlerszenarien, nicht nur den Idealfall

Fragen Sie, was passiert, wenn ein Sensor die Verbindung verliert, wenn ein Gerätetyp unbekannt ist, wenn eine Schnittstelle ausfällt oder wenn Datenquellen widersprüchliche Informationen liefern. Plattformen, die Unklarheiten transparent aufzeigen, sind vertrauenswürdiger als solche, die Lücken stillschweigend mit Annahmen füllen. Ein unbemerktes Versagen ist die gefährlichste Eigenschaft, die ein Compliance-Tool haben kann.

Lassen Sie sich die Betriebssicherheit schriftlich bestätigen

Fordern Sie eine detaillierte Dokumentation darüber an, was die Plattform im Netzwerk tut: jede aktive Abfrage, jede Protokollinteraktion, jede Anforderung an Agenten. Bestätigen Sie die Kompatibilität mit den Supportvereinbarungen der Hersteller für kritische Geräte. Jegliche Zurückhaltung bei der Bereitstellung dieser Details sollte bereits als Ausschlusskriterium gewertet werden.

Überprüfen Sie die Integration in bestehende Arbeitsabläufe

Compliance-Daten müssen mit dem Change Management, Ticketsystemen, Identitätsmanagement und der bestehenden Überwachung verknüpft werden. Eine Plattform, die sich nicht in bestehende Workflows integrieren lässt, führt zu redundanter Datenhaltung – und diese weicht unweigerlich mit der Zeit voneinander ab.

Planen Sie Personalwechsel ein

Erfahrene OT- und Compliance-Spezialisten gehen in den Ruhestand. Mit ihnen geht wertvolles implizites Wissen verloren. Prüfen Sie, ob die Plattform auch die Entscheidungswege dokumentiert – warum ein Asset so klassifiziert wurde, warum ein bestimmter Minderungsplan gewählt wurde – oder ob sie nur das nackte Ergebnis speichert. Systeme, die den Kontext mitspeichern, sichern das Wissen bei Personalwechseln. Systeme, die nur Daten speichern, tun dies nicht.

Nutzen Sie die folgenden Fragen als Leitfaden für Gespräche mit Softwareanbietern.

Wie Shieldworkz Organisationen unterstützt

Shieldworkz unterstützt Versorgungsunternehmen, Kraftwerksbetreiber, Industrieunternehmen und Betreiber kritischer Infrastrukturen (KRITIS) dabei, Compliance-Vorgaben und Sicherheitsanforderungen effizient zu vereinen – ohne dass parallele Programme die Ressourcen Ihrer Ingenieure binden. Unser Ansatz orientiert sich an der realen Funktionsweise von OT-Umgebungen. Das bedeutet: Wir schaffen Transparenz ohne betriebliche Risiken, und Nachweise entstehen automatisch als Nebenprodukt der kontinuierlichen Überwachung, statt als separates administratives Projekt.

• Umfassende OT-Asset-Erkennung und -Inventarisierung jedes verbundenen und nicht routingfähigen Assets in Umspannwerken, Anlagen und Außenstellen, einschließlich seriell angebundener Geräte, die durch reine Datenverkehrsanalyse nicht sichtbar sind.

• Unterstützung bei der revisionssicheren Systemklassifizierung, die Einstufungsentscheidungen samt Begründung dokumentiert, wiederkehrende Überprüfungszyklen abbildet und veränderte Asset-Rollen oder -Konnektivitäten automatisch kennzeichnet.

• Mapping von Kontrollen auf Anforderungen, das jede Vorgabe mit einer spezifischen Maßnahme, einem Verantwortlichen und dem entsprechenden Beleg verknüpft – inklusive Rückverfolgbarkeit bei Änderungen.

• Kontinuierliche Nachweiserfassung mit präzisen Zeitstempeln, Quellenzuordnung und Aufbewahrungsfristen, die auf die vollen Audit-Zeiträume abgestimmt sind, sodass Nachweise direkt abgerufen statt mühsam rekonstruiert werden.

• Überwachung von Konfigurationen und Baselines, die Baselines automatisch pflegt, autorisierte von unbefugten Änderungen unterscheidet und die lückenlose Versionshistorie aller Geräte auf der Steuerungsebene (SCADA/PLC) sichert.

• Unterstützung von Schwachstellen- und Patch-Workflows, die wiederkehrende Prüfzyklen überwacht, Sicherheitswarnungen mit den real eingesetzten Versionen abgleicht und strukturierte Minderungspläne dokumentiert, falls Patches betrieblich nicht möglich sind.

• Zentralisierte Access Governance, die Domain- und lokale Konten, gemeinsam genutzte Zugänge, Hersteller- und Fernzugriffe in einer einzigen Ansicht zusammenführt und den Abschluss der Prüfungen als Nachweis archiviert.

• Vorfallsmeldungsbereitschaft, die im Moment der Erkennung alle Kontextdaten zu Assets, Zugriffen und Änderungen bereitstellt, damit Bewertungen und Meldungen innerhalb der engen Fristen erfolgen können.

• Erstellung von Audit-Paketen, strukturiert nach Anforderungen, mit verknüpften Belegen und intakten Quellen – ergänzt durch ehrliche interne Berichte, die Schwachstellen aufzeigen, bevor es ein Auditor tut.

• Beratungs- und Implementierungskompetenz durch Ingenieure mit praktischer Erfahrung in Kraftwerken und Umspannwerken. Wir unterstützen Sie bei Audits, Sicherheitsarchitekturen, Netzsegmentierung, Programmerstellung und im laufenden Betrieb.

Unser Ziel ist klar definiert: Wir reduzieren den manuellen Aufwand für Ihre bereits stark beanspruchten Teams, verbessern die tatsächliche Transparenz in der Prozesslandschaft und machen die Audit-Bereitschaft zu einem dauerhaften Zustand statt zu einer wiederkehrenden Ausnahmesituation.

Fazit

Die Auswahl von NERC-CIP-Compliance-Software ist keine reine Beschaffungsentscheidung. Es ist die Entscheidung darüber, wie ein Unternehmen verlässliche Fakten über seine eigene OT-Umgebung gewinnt – und wie es diese gegenüber Regulierungsbehörden, der Geschäftsführung oder im Falle eines Vorfalls zweifelsfrei nachweisen kann.

Die neun in diesem Leitfaden beschriebenen Funktionen sind wertvoll, weil sie messbar und überprüfbar sind. Ein Asset-Inventar lässt sich mit der Realität abgleichen. Der Abruf von Nachweisen kann gezielt für einen Zeitpunkt vor achtzehn Monaten angefordert werden. Die Konfigurationsüberwachung lässt sich direkt an einer Feldsteuerung (SCADA/PLC) statt nur an einem Server testen. Die Struktur der Audit-Ausgabe kann vor Vertragsunterzeichnung geprüft werden. Eine Plattform, die in allen neun Bereichen überzeugt, reduziert die administrative Last und verbessert gleichzeitig die IT-/OT-Sicherheit. Eine Plattform, die nur in der Demo glänzt, wird früher oder Later scheitern – meist im ungünstigsten Moment.

Unternehmen, die diese Herausforderung erfolgreich meistern, teilen eine Gemeinsamkeit: Sie betrachten Compliance nicht als temporäres Projekt, sondern als kontinuierliche operative Disziplin, gestützt durch Systeme, die fortlaufend überwachen und lückenlos protokollieren. Der regulatorische Nutzen ist spürbar, der Sicherheitsgewinn für die Infrastruktur ist noch weitaus größer.

Compliance belegt, was Sie getan haben. Transparenz zeigt Ihnen, was gerade passiert. Die richtige Plattform liefert beides aus einer Hand.

Weitere Ressourcen:

Umfassender Leitfaden zu Network Detection and Response (NDR) im Jahr 2026 finden Sie hier
Checkliste zur Vorbereitung auf die interne Überwachung der Netzwerksicherheit gemäß NERC CIP-015 für Energieversorger hier
OT SOC Grundlagen-Leitfaden hier
Managed SOC Service hier
Sicherheitswarnungen zur OT-Bedrohungslage - Nahost hier
NIS-2-Richtlinie: Erreichen der NIS-2-Compliance durch IEC 62443 hier
Was sind Wechselmedien? Risiken, Richtlinien und OT-Sicherheitslösungen für die Industrie hier
Kostenlose Richtlinien-Vorlage für Wechselmedien für OT- und IT-Teams hier