Unternehmens-Cybersecurity: Was es für einen Hersteller elektrischer Ausrüstungen bedeutet, eine wichtige Einrichtung nach NIS2 zu sein

Der vorherige Brief betrachtete Cybersecurity aus Produktsicht: Anforderungen des Cyber Resilience Act, Zertifizierung nach RED 2014/53 und IEC 62443 als Vorwegnahme des technischen Rahmens. So operativ diese Betrachtung auch ist, sie deckt nur die Hälfte des Problems ab.

Die andere Hälfte liegt in der Organisation, die das Produkt entwickelt, in die Produktion überführt und über seine zehnjährige kommerzielle Lebensdauer hinweg aktualisiert. Ein Lastenheft, das „sichere Firmware, Secure Boot, SBOM“ fordert, setzt implizit voraus, dass hinter dieser Firmware ein Unternehmen steht, das strukturiert genug ist, um über den gesamten Produktlebenszyklus ein vertrauenswürdiger Lieferant zu bleiben. Deshalb beschränkt sich der europäische Regulierungsrahmen seit 2024 nicht mehr darauf, technische Anforderungen an das Produkt zu stellen: Er hat substanzielle Pflichten auf die Organisation des Herstellers ausgeweitet und benennt ausdrücklich, wer in den Geltungsbereich fällt.

Für Herholdt Controls ist dieser Geltungsbereich eine formale Tatsache.

Wichtige Einrichtung nach NIS2: Was sich seit dem 12. April 2025 geändert hat

Die NIS2-Richtlinie (Richtlinie (EU) 2022/2555) wurde in Italien mit dem Gesetzesdekret 138/2024 umgesetzt, das seit dem 16. Oktober 2024 in Kraft ist. Die Norm identifiziert zwei Kategorien von Einrichtungen, die spezifische Cybersicherheitspflichten erfüllen müssen: wesentliche Einrichtungen, typischerweise Betreiber kritischer Infrastrukturen (Energie, Verkehr, Gesundheit, Finanzwesen), und wichtige Einrichtungen, die in strategischen Sektoren tätig sind, deren Unterbrechung erhebliche Auswirkungen auf Wirtschaft oder Gesellschaft hätte.

Die nationale zuständige NIS-Behörde, die italienische Agentur für Cybersicherheit (ACN), führte zwischen Oktober 2024 und April 2025 den Registrierungs- und Klassifizierungsprozess der Einrichtungen durch. Die Organisationen reichten eine vorläufige Erklärung ein; ACN bewertete sie anhand der im Dekret festgelegten Kriterien (Tätigkeitssektor, Größe, Rolle in der Lieferkette wesentlicher Einrichtungen) und erließ eine formale Feststellung der Aufnahme in die nationale Liste.

Mit der Feststellung des Generaldirektors der ACN vom 12. April 2025 wurde Herholdt Controls als wichtige Einrichtung im Zusammenhang mit der Herstellung strategischer elektrischer Ausrüstungen identifiziert (NACE-Code C/27, verarbeitendes Gewerbe). Die Feststellung bringt einen Umfang substantieller Pflichten mit sich: technische, operative und organisatorische Maßnahmen zum Management von Cyberrisiken; Meldung erheblicher Vorfälle an CSIRT Italia (Frühwarnung innerhalb von 24 Stunden, vollständige Meldung innerhalb von 72 Stunden, Abschlussbericht innerhalb eines Monats); Pflicht zum Risikomanagement der eigenen Lieferkette; Verwaltungsstrafen von bis zu 7 Millionen Euro oder 1,4 % des weltweiten Jahresumsatzes bei Nichteinhaltung.

Für einen Lieferanten elektrischer Ausrüstungen, die für kritische Infrastrukturen bestimmt sind, ist die Aufnahme in die NIS2-Liste keine bürokratische Folge. Sie ist die öffentliche Formalisierung einer Risikoexposition, die das Dekret faktisch als systemisch betrachtet.

Was sich für Käufer von einer NIS2-Einrichtung ändert

Der für den Markt wichtigste Effekt betrifft nicht unmittelbar die registrierte Einrichtung. Er betrifft ihre Kunden.

NIS2 verpflichtet regulierte Einrichtungen formell dazu, das Risiko ihrer Lieferkette zu managen. Praktisch bedeutet das: Jeder Stromnetzbetreiber, jeder Rechenzentrumsbetreiber und jeder als wesentlich oder wichtig eingestufte EVSE-Betreiber muss heute die Cybersecurity-Position seiner kritischen Lieferanten dokumentieren, die damit verbundenen Risiken bewerten und, sofern die Bewertung dies erfordert, formell nur Lieferanten qualifizieren, die eine nachweisbare Sicherheits-Baseline erfüllen.

Ein Lieferant, der heute auf eine Frage wie „Was ist Ihr NIS2-Geltungsbereich, und welche technischen und organisatorischen Maßnahmen haben Sie daraus abgeleitet?“ nicht mit formalen Dokumenten antworten kann, wird systematisch aus den Beschaffungspipelines regulierter Kunden ausgeschlossen. Nicht aufgrund einer kommerziellen Entscheidung des Kunden, sondern aufgrund der regulatorischen Verpflichtung des Kunden selbst.

Deshalb ist die ACN-Klassifizierung von Herholdt Controls als wichtige Einrichtung nicht nur eine interne Tatsache: Sie ist ein Qualifikationsnachweis, den regulierte Kunden ihren Risikodateien zur Lieferkette beilegen können und der den Onboarding-Dialog messbar und dokumentenbasiert macht, nicht mehr rein ermessensabhängig.

NIST Cybersecurity Framework: die architektonische Entscheidung

Die Sicherheitsmaßnahmen, die Herholdt Controls infolge der NIS2-Klassifizierung eingeführt hat, wurden auf Grundlage des NIST Cybersecurity Framework 2.0 strukturiert, das im Februar 2024 vom National Institute of Standards and Technology der Vereinigten Staaten veröffentlicht wurde.

Das NIST-Framework ist in Europa nicht verpflichtend und ersetzt nicht die formalen Pflichten aus dem italienischen Gesetzesdekret 138/2024. Es ist jedoch der weltweit am häufigsten eingesetzte internationale Referenzrahmen für die operative Strukturierung eines unternehmensweiten Cybersecurity-Programms und wird von ACN ausdrücklich als akzeptabler Standard für die Selbstbewertung von Risikomanagementmaßnahmen anerkannt.

Die Wahl des NIST CSF als architektonischer Rahmen folgt drei methodischen Kriterien. Erstens: Abdeckung. Die sechs Funktionen des Frameworks (Govern, Identify, Protect, Detect, Respond, Recover) decken den gesamten Zyklus des Cyberrisikomanagements ab, von Governance bis Incident Response, ohne Lücken, die eine Integration separater Frameworks erfordern würden. Zweitens: Reife. Das NIST CSF entwickelt sich seit 2014 kontinuierlich weiter, und Version 2.0 integriert zwölf Jahre Lessons Learned aus Organisationen jeder Größe und Branche. Drittens: Übersetzbarkeit. Jede CSF-Funktion lässt sich präzise auf spezifische Kontrollen angrenzender Standards abbilden (ISO/IEC 27001, IEC 62443, SOC 2), sodass das Framework eine Infrastruktur bildet, auf der spätere formale Zertifizierungen aufgebaut werden können, ohne das Sicherheitsprogramm neu zu entwerfen.

Auf den operativen Kontext eines Herstellers elektrischer Ausrüstungen angewendet, werden die sechs CSF-Funktionen zu klar getrennten operativen Domänen.

• Govern: Definition der Sicherheitsverantwortlichkeiten auf Leitungsebene, Unternehmensrichtlinien, Budgetzuweisung.
• Identify: Inventarisierung der Assets (Hardware, Software, Daten, Prozesse), Analyse von Abhängigkeiten, Bewertung des geschäftlichen Kontexts.
• Protect: Zugriffskontrollen, Verwaltung von Zugangsdaten, Schulung des Personals, Datenschutz, Netzwerksegmentierung.
• Detect: kontinuierliches Monitoring von Ereignissen und Erkennung von Anomalien.
• Respond: Eindämmung eines Vorfalls, interne und externe Kommunikation, Koordination mit Behörden.
• Recover: Wiederherstellung von Funktionen, Lessons Learned, kontinuierliche Verbesserung.

Keine dieser sechs Domänen ist lediglich eine interne Best Practice von Herholdt Controls. Jede ist ein Nachweisbereich, der gegenüber einer Aufsichtsbehörde dokumentiert werden kann.

SOC und SIEM: die operative Ebene der Detection

Die Funktionen Detect und Respond des NIST-Frameworks lassen sich nicht durch schriftliche Policies erfüllen. Sie erfordern operative Werkzeuge, die Netzwerk und Systeme 24 Stunden am Tag, sieben Tage die Woche beobachten und die Zeit zwischen Beginn eines Vorfalls und seiner Identifizierung auf ein Zeitfenster reduzieren, das mit den Meldepflichten vereinbar ist.

Herholdt Controls hat für diese Funktion zwei komplementäre Instrumente implementiert: ein SIEM (Security Information and Event Management) und ein SOC (Security Operations Center).

Das SIEM ist die technische Plattform, die die von jedem System der Unternehmensinfrastruktur erzeugten Logs in Echtzeit sammelt, normalisiert und korreliert: Firewalls, Mailserver, Domänencontroller, Endpoints, Business-Anwendungen und Produktionsautomatisierungssysteme. Die Normalisierung ermöglicht es, Ereignisse aus heterogenen Quellen einheitlich zu behandeln; die Korrelation ermöglicht es, Muster zu erkennen, die einzeln betrachtet unsichtbar wären. Ein einzelner fehlgeschlagener Authentifizierungsversuch auf einem Administratorkonto ist Hintergrundrauschen. Fünftausend fehlgeschlagene Versuche von geografisch verteilten IP-Adressen innerhalb von sechzig Minuten, korreliert mit einem erfolgreichen Zugriff auf dasselbe Konto, sind ein laufender Credential-Stuffing-Angriff.

Das SOC ist das Team, intern oder als qualifiziertes Outsourcing, das mit den vom SIEM erzeugten Daten arbeitet. Es empfängt die von Korrelationsregeln generierten Alerts, bewertet sie anhand vordefinierter Prioritätskriterien, unterscheidet False Positives von tatsächlichen Vorfällen und aktiviert den Response-Prozess, wenn ein Vorfall bestätigt wird. Ein SIEM ohne SOC ist ein Werkzeug ohne Interpretation: Es erzeugt Alerts, die niemand liest. Ein SOC ohne SIEM ist ein Team ohne Sichtbarkeit: Es muss sich auf Basis von Ad-hoc-Meldungen ein Bild davon machen, was geschieht.

Das Vorhandensein beider Elemente, korrekt integriert und mit Korrelationsregeln, die auf den spezifischen operativen Kontext kalibriert sind (Elektronikfertigung, Embedded-Firmware-Entwicklung, Komponentenlieferkette), ist die operative Baseline, die NIS2 von einer wichtigen Einrichtung erwartet.

Incident Response Plan, Playbook, BIA, Disaster Recovery

Die Erkennung eines Vorfalls ist nicht das Ende des Prozesses. Sie ist der Anfang.

Ein Cybersecurity-Vorfall in einem Fertigungsunternehmen kann viele Formen annehmen: Kompromittierung eines internen Kontos, Ransomware auf einer Netzwerkfreigabe der Entwicklung, Exfiltration technischer Dokumentation, Manipulation eines Firmware-Binaries in der Build-Kette, ein Denial-of-Service-Angriff auf einen exponierten Dienst. Jede dieser Formen erfordert eine andere Reaktion, mit unterschiedlichen Zeiten, Akteuren und Verfahren. Die Reaktion im Moment des Vorfalls zu improvisieren, ist der schnellste Weg, einen eindämmbaren Vorfall in eine systemische Krise zu verwandeln.

Deshalb hat Herholdt Controls vier operative Dokumente formalisiert, die zusammen den Response-Plan bilden:

1. Der Incident Response Plan (IRP) ist das übergeordnete Dokument. Er definiert Rollen und Verantwortlichkeiten während eines Vorfalls, Kriterien zur Einstufung der Schwere, interne Eskalationsregeln, Kommunikationskanäle mit Behörden (CSIRT Italia, ENISA, regulierte Kunden) und Medien sowie verpflichtende Meldefristen unter NIS2. Er beschreibt nicht, wie einzelne Szenarien gehandhabt werden: Er definiert den gemeinsamen prozeduralen Rahmen.
2. Das operative Playbook arbeitet eine Ebene darunter. Für jedes plausible Szenario (Ransomware, Kompromittierung eines privilegierten Kontos, Datenexfiltration, Firmware-Manipulation, physisches Eindringen in Entwicklungssysteme) beschreibt es Schritt für Schritt die operativen Maßnahmen: wer zuerst kontaktiert wird, welche Systeme sofort isoliert werden müssen, welche forensischen Beweise zu sichern sind, welche externe Kommunikation autorisiert ist. Das Playbook ist das Dokument, das das operative Team um drei Uhr morgens öffnet, wenn das SIEM den Alert generiert hat; es verwandelt eine schriftliche Prozedur in unter Druck ausführbare Handlungen.
3. Die Business Impact Analysis (BIA) beantwortet eine andere Frage: Wenn ein System ausfällt oder ein Dienst kompromittiert wird, welche Auswirkungen hat das auf den Geschäftsbetrieb, und in welcher Reihenfolge müssen Systeme wiederhergestellt werden? Die BIA klassifiziert jeden Geschäftsprozess nach Kritikalität und definiert für jeden ein RTO (Recovery Time Objective: wie lange das System maximal down bleiben darf) und ein RPO (Recovery Point Objective: wie viele Daten man sich leisten kann zu verlieren). Systeme zur Konfiguration metrologischer Firmware haben ein deutlich engeres RTO als ein internes Dokumentenmanagementsystem; Firmware-Signatursysteme haben ein im Wesentlichen nulltolerantes RPO. Die BIA übersetzt diese Unterschiede in eine operative Wiederherstellungssequenz.
4. Der Disaster-Recovery-Plan (DR) ist das technische Dokument, das für jedes in der BIA identifizierte kritische System die Infrastruktur, Verfahren und Ressourcen beschreibt, die erforderlich sind, um es innerhalb der festgelegten Parameter wiederherzustellen. Automatische Backups, regelmäßige Restore-Tests, redundante Infrastruktur, geografische Replikation kritischer Daten, vorkonfigurierte Notfallumgebungen. Ein DR-Plan, der geschrieben, aber nie getestet wurde, ist kein Plan: Er ist eine Absichtserklärung. Die regelmäßige Validierung der tatsächlichen Wiederherstellungszeiten ist integraler Bestandteil des Dokuments.

Zusammen schließen die vier Dokumente den Zyklus des NIST-Frameworks: Erkennung → Reaktion → Wiederherstellung → Verbesserung. Ohne diesen Abschluss ist eine frühe Erkennung eines Vorfalls eine Information, die nicht in Handlung übersetzt wird.

Was das für einen OEM-Kunden bedeutet

Für einen OEM, der heute ein Lastenheft für einen Lieferanten elektrischer Ausrüstungen für eine vernetzte Infrastruktur schreibt, sind Fragen zur unternehmensweiten Cybersecurity-Position des Lieferanten ebenso strukturell geworden wie Fragen zum Produkt.

• Ist der Lieferant von der national zuständigen Behörde als NIS2-Einrichtung (wesentlich oder wichtig) eingestuft? In welcher Kategorie, und seit wann?
• Welches Framework für Informationssicherheitsmanagement wird angewendet (NIST CSF, ISO/IEC 27001, branchenspezifischer Rahmen)?
• Gibt es ein 24/7 operatives SOC (intern oder als qualifiziertes Outsourcing), das mit einem SIEM integriert ist? Welche Kennzahlen zu Mean Time To Detect und Mean Time To Respond werden angegeben?
• Sind Incident Response Plan und operatives Playbook formale Dokumente, die regelmäßig aktualisiert und durch Übungen getestet werden? Welche Szenarien decken sie ab?
• Gibt es eine aktuelle Business Impact Analysis, die kritische Prozesse mit ihren RTO/RPO identifiziert? Wie häufig wird der Disaster-Recovery-Plan getestet?
• Benachrichtigt der Lieferant seine Kunden formell über erhebliche Sicherheitsvorfälle, die Auswirkungen auf deren Infrastruktur haben können, innerhalb welcher Fristen und mit welchem Detaillierungsgrad?

Ein Lieferant, der diese Fragen mit formalen, dokumentierbaren Referenzen beantwortet (NIS2-Identifikationscode, Mapping der NIST-Maßnahmen, Nachweise aus Übungen, DR-Testberichte), hat organisatorische Cybersecurity in seine Prozesse integriert. Ein Lieferant, der mit allgemeinen Grundsatzerklärungen antwortet, erklärt ein Reifegradniveau, das er erst nach Vertragsunterzeichnung aufbauen müsste – in einem Markt, in dem regulierte Kunden es sich nicht mehr leisten können, dieses Risiko einzugehen.

Für Kunden, die Herholdt Controls heute als Lieferanten elektrischer Ausrüstungen für vernetzte Infrastrukturen bewerten, ist der Ausgangspunkt der Due Diligence keine Absichtserklärung. Es ist ein italienischer Verwaltungsakt vom 12. April 2025, der das Unternehmen namentlich benennt.