OT-Security in der Fertigung: NIS2 und CRA auf AWS

NIS2 und CRA: Was gilt ab wann für die Fertigung?

Die europäische Cybersicherheitslandschaft hat sich 2024 fundamental verändert. Während NIS1 noch primär auf Energieversorger und Finanzinstitute zielte, erfasst NIS2 nun ausdrücklich den Fertigungssektor — und das mit deutlich schärferen Anforderungen und Bußgeldern.

NIS2-Zeitplan und Betroffenheit

Die NIS2-Richtlinie hätte bis Oktober 2024 in nationales Recht umgesetzt werden sollen. Deutschland arbeitet am NIS2UmsuCG (NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetz), das voraussichtlich 2025 in Kraft tritt. Für Fertigungsunternehmen gilt:

• Wichtige Einrichtungen (ab 50 MA oder 10 Mio. EUR Umsatz): Maschinenbau, Fahrzeugbau, Medizinprodukte, Chemie, Lebensmittelverarbeitung
• Besonders wichtige Einrichtungen (ab 250 MA oder 50 Mio. EUR Umsatz): Verschärfte Anforderungen, proaktive Meldepflichten, persönliche Haftung der Geschäftsleitung
• Bußgelder: Bis zu 10 Mio. EUR oder 2 % des weltweiten Jahresumsatzes für wichtige Einrichtungen; bis zu 7 % für kritische Sektoren

Cyber Resilience Act (CRA)

Der CRA (EU 2024/2847) gilt ab Dezember 2027 für alle Produkte mit digitalen Elementen. Für die Fertigung bedeutet das: Wer vernetzte Maschinen, Steuerungen, Sensoren oder industrielle Software herstellt oder in Verkehr bringt, muss Cybersicherheit als integralen Bestandteil des Produktlebenszyklus nachweisen. Wesentliche Anforderungen:

• Sicherheitsupdates über mindestens 5 Jahre Produktlebensdauer
• SBOM (Software Bill of Materials) für jedes Produkt
• Schwachstellenmeldepflicht an ENISA innerhalb von 24 Stunden
• Konformitätsbewertung und CE-Kennzeichnung auch für Cybersicherheit

Begriffsklärung: OT-Security im Fertigungskontext

OT-Security (Operational Technology Security)

Schutz von Systemen, die physische Prozesse überwachen und steuern — SPS, SCADA, DCS, industrielle Roboter, CNC-Maschinen. OT-Security unterscheidet sich von klassischer IT-Security durch harte Echtzeitanforderungen, lange Lebenszyklen (10–30 Jahre), proprietäre Protokolle und die potenzielle physische Schadenswirkung bei Systemausfall oder -kompromittierung.

Purdue-Modell (Purdue Enterprise Reference Architecture)

Referenzarchitektur zur Segmentierung von Industriesteuerungssystemen in hierarchische Ebenen (0–5): Feldgeräte (Level 0), Steuerungsebene (Level 1–2), SCADA/MES (Level 3), Enterprise-IT (Level 4), Cloud (Level 5). Das Purdue-Modell definiert, welche Systeme miteinander kommunizieren dürfen — und welche strikt isoliert bleiben müssen.

DMZ (Demilitarisierte Zone) in der OT

Pufferzone zwischen OT-Netz (Level 3) und IT-Netz (Level 4/5). Die OT-DMZ filtert und übersetzt den Datenfluss, ohne direkte Verbindungen zwischen beiden Netzen zu erlauben. Datenaustausch erfolgt ausschließlich über kontrollierte Proxies, Daten-Dioden oder Application-Layer-Gateways.

AWS IoT Device Defender

Verwalteter AWS-Service zur kontinuierlichen Überwachung und Auditierung von IoT-Geräten und industriellen Endpunkten. Device Defender prüft Konfigurationen gegen Sicherheitsbaselines, erkennt anomales Verhalten (unerwartete Verbindungen, Protokollabweichungen) und gibt Alerts bei Verstößen aus. Zentrale Kontrollebene für die Gerätesicherheit im Shopfloor.

SBOM (Software Bill of Materials)

Maschinenlesbare Liste aller Softwarekomponenten, Abhängigkeiten und Versionen, aus denen ein Produkt oder System besteht. Der CRA verlangt SBOMs für alle Produkte mit digitalen Elementen, um bekannte Schwachstellen (CVEs) schnell identifizieren und beheben zu können. AWS Inspector kann automatisiert SBOMs für Container- und EC2-Workloads generieren.

NIS2-Meldepflicht

Dreigliedrige Pflicht zur Meldung erheblicher Sicherheitsvorfälle: Frühwarnung (24 h), vollständige Ereignismeldung (72 h), Abschlussbericht (1 Monat). Als erheblich gilt ein Vorfall, der die Lieferung von Diensten erheblich stört oder erheblichen finanziellen Schaden verursacht.

Das Purdue-Modell auf AWS: Referenzarchitektur für sichere OT/IT-Integration

AWS empfiehlt keine vollständige Migration von OT-Systemen in die Cloud — sondern ein hybrides Modell, das das bewährte Purdue-Schichtenmodell auf eine Cloud-native Architektur überträgt. Die fünf Ebenen werden dabei wie folgt abgebildet:

Der kritischste Übergang ist Level 3.5 — die OT-DMZ. Hier entscheidet sich, ob OT-Systeme durch die Cloud-Anbindung gefährdet werden oder nicht. AWS Network Firewall implementiert an diesem Punkt tiefe Paketinspektion mit industriespezifischen Regeln (z. B. Modbus-Anomalieerkennung). Amazon GuardDuty überwacht den Netzwerktraffic in der DMZ auf Bedrohungsmuster — auch für OT-spezifische Angriffsvektoren wie Protokollmissbrauch und laterale Bewegungen.

Segmentierungsprinzipien

• Least Privilege: Jedes Gerät und jeder Dienst kommuniziert nur mit den Zielen, die es für seine Funktion benötigt
• Default Deny: Alle Verbindungen sind verboten, bis sie explizit erlaubt werden
• Unidirektionale Kommunikation: Von OT nach IT ist Datenübertragung erlaubt; Steuerbefehle von IT nach OT erfordern separate, stark gesicherte Kanäle
• Netzwerksegmentierung: OT-Netz, IT-Netz und Cloud-Netz als getrennte VPCs mit kontrollierten Übergängen

AWS IoT Device Defender: Kontinuierliche Gerätesicherheit im Shopfloor

Fertigungsunternehmen betreiben oft Hunderte oder Tausende von IoT-Geräten und OT-Endpunkten. Jedes dieser Geräte ist ein potenzieller Angriffspunkt. AWS IoT Device Defender schafft eine zentrale, automatisierte Übersicht über den Sicherheitsstatus aller verbundenen Geräte.

Die zwei Kernfunktionen

Audit: Device Defender prüft kontinuierlich die Konfiguration aller IoT-Geräte gegen Best Practices und definierte Security-Policies. Typische Audit-Checks für Fertigungsumgebungen:

• Wird für jedes Gerät ein eindeutiges X.509-Zertifikat verwendet?
• Sind abgelaufene oder widerrufene Zertifikate noch aktiv?
• Haben Geräte übermäßig breite IAM-Permissions?
• Kommunizieren Geräte über nicht autorisierte MQTT-Topics?
• Sind Geräte in mehreren Konten gleichzeitig registriert (Konfigurations-Anomalie)?

Detect: Mithilfe von ML-Modellen und regelbasierten Detektoren überwacht Device Defender das Laufzeitverhalten jedes Geräts. Abweichungen vom erlernten Normalzustand lösen automatisch Alerts aus. Beispiele relevanter Metriken:

• Anzahl ausgehender TCP-Verbindungen (Indikator für C2-Kommunikation)
• Unerwartete Verbindungsziele (Geo-basiert oder domainbasiert)
• Nachrichtenrate (Burst-Anomalien als Indikator für Angriffe)
• Authentifizierungsfehler (Brute-Force-Versuche)

Alerts aus Device Defender fließen automatisch in AWS Security Hub als Findings ein und werden mit CloudWatch-Alarmen und SNS-Benachrichtigungen gekoppelt. Das ermöglicht eine vollautomatische Eskalationskette — von der Anomalieerkennung bis zur Incident-Response-Aktivierung innerhalb von Minuten statt Stunden.

AWS Security Hub: OT/IT-Sicherheitslage auf einen Blick

NIS2 fordert nicht nur, dass Sicherheitsmaßnahmen existieren — sondern dass sie nachweisbar und dokumentiert sind. AWS Security Hub ist das zentrale Dashboard für die Sicherheitslage aller AWS-Ressourcen und liefert genau diese Nachweisbarkeit.

Security Hub aggregiert Findings aus mehreren AWS-Services und gibt eine priorisierte, korrelierte Gesamtbewertung. Für die Fertigungsumgebung relevant:

Security Hub unterstützt das AWS Foundational Security Best Practices (FSBP) Standard sowie den CIS AWS Foundations Benchmark. Für NIS2 empfiehlt Storm Reply zusätzlich das NIST CSF Framework als Compliance-Mapping — es deckt alle technischen Anforderungen aus Art. 21 NIS2 ab und lässt sich im Security Hub als Custom Standard konfigurieren.

Incident Response und die 24-Stunden-Meldepflicht

NIS2 Art. 23 schreibt eine gestufte Meldepflicht vor. Wer nicht vorbereitet ist, scheitert nicht an der Technik, sondern an den Prozessen. Ein strukturierter Incident-Response-Plan ist Pflicht — und AWS-Services liefern die technische Unterstützung dafür.

NIS2-Meldepflicht im Überblick

1. Frühwarnung (24 Stunden): Meldung an BSI oder zuständige CSIRT. Inhalt: Vorfallstyp, erste Bewertung der Schwere, erste Indikation über mögliche grenzüberschreitende Auswirkungen
2. Ereignismeldung (72 Stunden): Aktualisierte Bewertung, Schweregrad, Indikatoren für Kompromittierung, ergriffene Maßnahmen
3. Abschlussbericht (1 Monat): Vollständige technische Beschreibung, Ursachenanalyse, Gegenmaßnahmen, Lessons Learned

AWS CloudTrail liefert das unveränderliche Audit-Log für alle Aktionen in der AWS-Umgebung — essenziell für die Forensik. Amazon GuardDuty erkennt kompromittierte Credentials und ungewöhnliche Aktivitätsmuster und liefert zeitgestempelte Findings mit Kontext. AWS Security Hub korreliert diese Findings und berechnet automatisch den Schweregrad.

Automatisierte Incident-Response-Pipeline

1. GuardDuty oder Device Defender erkennt Anomalie und erzeugt Finding
2. Security Hub aggregiert und priorisiert das Finding (CRITICAL/HIGH/MEDIUM)
3. EventBridge-Regel triggert bei CRITICAL automatisch eine SNS-Benachrichtigung an das Security-Team
4. AWS Systems Manager Automation führt erste Response-Aktionen aus (z. B. Gerät isolieren, Snapshot erstellen)
5. CloudTrail und VPC Flow Logs sichern die forensischen Beweise
6. Automatisch generierter Bericht (via Lambda) strukturiert die 24h-Meldung vor

Mit dieser Pipeline verkürzt sich die Zeit von der Erkennung bis zur abgesandten BSI-Meldung von typischerweise 4–8 Stunden auf unter 1 Stunde — auch nachts und am Wochenende.

Supply-Chain-Security und der Cyber Resilience Act

Der CRA adressiert ein grundlegendes Problem: Viele Cyberangriffe auf Fertigungsunternehmen beginnen nicht beim Angriffsziel selbst, sondern bei einem Zulieferer oder Softwareanbieter. SolarWinds, Log4Shell und der Kaseya-Angriff sind prominente Beispiele dieses Musters.

NIS2 Art. 21 fordert ausdrücklich Sicherheit in der Lieferkette. Fertigungsunternehmen müssen:

• Die Cybersicherheitspraktiken ihrer Lieferanten bewerten
• Vertragliche Sicherheitsanforderungen gegenüber Lieferanten durchsetzen
• Software-Abhängigkeiten ihrer Produkte dokumentieren (SBOM)
• Patch-Management für gelieferte Komponenten sicherstellen

AWS-Dienste für Supply-Chain-Security

• AWS Inspector: Automatisiertes Vulnerability-Scanning für EC2-Instanzen, Container-Images und Lambda-Funktionen. Generiert automatisch SBOMs im CycloneDX-Format — CRA-kompatibel.
• Amazon CodeGuru Security: Statische Codeanalyse für Schwachstellen in Eigenentwicklungen und importierten Bibliotheken
• AWS CodeArtifact: Private Paket-Repository mit Herkunfts- und Integritätsprüfung für alle Software-Abhängigkeiten
• AWS Signer: Kryptografische Signierung von Code und Software-Paketen für verifizierbare Provenance
• Amazon GuardDuty Malware Protection: Erkennt Malware in EC2-Instanzen und Container-Workloads — auch nach Supply-Chain-Kompromittierung

EU-Maschinenverordnung 2023/1230: Cybersicherheit als Designpflicht

Die EU-Maschinenverordnung 2023/1230 löst die Maschinenrichtlinie 2006/42/EG ab und tritt ab Oktober 2027 in Kraft. Sie erweitert das Sicherheitskonzept um eine explizite Cybersicherheitsdimension — mit unmittelbarer Relevanz für Fertigungsunternehmen, die Maschinen herstellen oder betreiben.

Anhang III der Verordnung enthält neue wesentliche Sicherheitsanforderungen für vernetzte Maschinen:

• Schutz vor unberechtigtem Zugriff auf Steuersysteme (Anti-Tampering)
• Sicherer Softwareupdate-Mechanismus mit Integritätsprüfung
• Logging sicherheitsrelevanter Ereignisse
• Dokumentierte Risikoanalyse für Cybersicherheit im Rahmen der CE-Konformitätsbewertung
• Klare Abgrenzung der Schnittstellen zwischen Maschine und externen Systemen

Für die Cloud-Architektur bedeutet das: AWS IoT Greengrass ermöglicht sichere Over-the-Air-Updates für Edge-Devices mit kryptografischer Signaturprüfung. AWS IoT Device Management verwaltet den Lebenszyklus aller verbundenen Geräte inklusive Zertifikatsrotation. CloudTrail protokolliert alle Konfigurationsänderungen nachvollziehbar — ein direkter Beitrag zur Konformitätsdokumentation.

Storm Reply Perspektive: OT-Security als strategische Investition

Storm Reply berät seit über 15 Jahren Fertigungsunternehmen bei der sicheren Cloud-Transformation. Die Erfahrung aus mehr als 50 OT/IT-Projekten zeigt: Der größte Fehler ist es, OT-Security als Compliance-Übung zu behandeln. Wer nur die Mindestanforderungen erfüllt, hat nach dem nächsten Angriff ein Problem — und nach der nächsten Regulierungswelle ebenfalls.

Die erfolgreichen Projekte beginnen nicht mit einem Security-Tool, sondern mit einer Inventarisierung: Welche OT-Geräte existieren im Netz? Welche davon kommunizieren wohin? Welche haben noch Standardpasswörter? Diese Grundlage fehlt in den meisten Fertigungsunternehmen — und ohne sie ist keine Security-Maßnahme wirksam.

Unser bewährter Ansatz für OT-Security auf AWS:

1. OT Asset Discovery (Woche 1–2): Passive Netzwerk-Scans mit Claroty oder Dragos, Import in AWS IoT Device Management
2. Risikobewertung (Woche 3–4): Criticality-Matrix, NIS2-Betroffenheitsanalyse, CRA-Gap-Assessment
3. Quick Wins (Woche 5–8): Netzwerksegmentierung, Device Defender Rollout, Security Hub Aktivierung
4. Incident Response Plan (Woche 9–12): Playbooks für NIS2-Meldepflicht, automatisierte Response-Pipeline
5. Kontinuierliche Überwachung: GuardDuty, Device Defender Detect, monatliche Compliance-Reports

Storm Reply ist AWS Premier Consulting Partner mit Kompetenz in Security und Migration. Wir kombinieren OT-Domänenwissen mit AWS-Cloud-Expertise — und haben die Zertifizierungen, um auch in regulierten Fertigungsumgebungen sicher zu arbeiten.

Vorteile und Herausforderungen auf einen Blick

Vorteile eines AWS-basierten OT-Security-Ansatzes

• Skalierbarkeit: Device Defender überwacht Hunderte oder Tausende Geräte ohne proportionalen Mehraufwand
• Nachweisbarkeit: CloudTrail und Security Hub liefern revisionssichere Logs für BSI-Meldungen und Audits
• Integration: Native Integration zwischen IoT-Services, Security Hub, GuardDuty und CloudTrail ohne Schnittstellenprojekte
• Kosteneffizienz: Pay-per-Use statt teurer On-Premises-SIEM-Lizenzen
• Schnelle Implementierung: Security Hub und GuardDuty sind in Stunden aktivierbar — kein Deployment-Projekt

Typische Herausforderungen

• Legacy-OT-Geräte: Viele SPS und SCADA-Systeme unterstützen keine modernen Authentifizierungsstandards — hier helfen Protokoll-Gateways und Netzwerksegmentierung als Kompensationsmaßnahmen
• OT/IT-Organisationssilos: OT-Teams und IT-Teams haben oft unterschiedliche Verantwortlichkeiten und Kulturen — gemeinsame Security-Governance-Strukturen sind Voraussetzung
• Patching-Restriktionen: Produktionsanlagen können nicht beliebig aktualisiert werden — Wartungsfenster und Risikoabwägungen sind notwendig
• Fehlende Asset-Inventare: Ohne vollständige Inventarisierung ist kein effektives Risikomanagement möglich

FAQ: OT-Security, NIS2 und CRA in der Fertigung

Gilt NIS2 für Fertigungsunternehmen?

Ja. NIS2 erfasst ab Oktober 2024 explizit den Fertigungssektor als wichtige Einrichtung. Unternehmen ab 50 Mitarbeitern oder 10 Mio. EUR Jahresumsatz in kritischen Fertigungsbereichen (u. a. Maschinen, Fahrzeuge, Medizinprodukte, Chemie) fallen unter die Meldepflicht und müssen geeignete Sicherheitsmaßnahmen nachweisen.

Was ist der Unterschied zwischen NIS2 und dem Cyber Resilience Act?

NIS2 regelt die Betriebssicherheit von Netz- und Informationssystemen in Unternehmen (Prozesse, Incident Response, Lieferkette). Der Cyber Resilience Act (CRA) reguliert die Sicherheitseigenschaften von Produkten mit digitalen Elementen — also auch von vernetzten Maschinen, Sensoren und Steuerungen, die Fertigungsunternehmen herstellen oder einsetzen.

Was leistet AWS IoT Device Defender für OT-Security?

AWS IoT Device Defender überwacht kontinuierlich den Sicherheitsstatus von IoT-Geräten und OT-Endpunkten. Es erkennt Abweichungen von definierten Security-Baselines (z. B. offene Ports, unerwartete Verbindungen), führt Audits gegen Best Practices durch und löst automatische Alerts aus. Damit liefert es eine zentrale Sicht auf die Gerätesicherheit im Shopfloor.

Wie lange haben Unternehmen nach einem Sicherheitsvorfall Zeit zur Meldung?

NIS2 schreibt eine mehrstufige Meldepflicht vor: Innerhalb von 24 Stunden muss eine Frühwarnung an die zuständige Behörde (BSI) erfolgen. Innerhalb von 72 Stunden folgt die vollständige Ereignismeldung. Ein abschließender Bericht ist innerhalb eines Monats einzureichen. AWS Security Hub und CloudTrail unterstützen die automatische Erstellung dieser Nachweise.

Was verlangt die EU-Maschinenverordnung 2023/1230 von Herstellern?

Die EU-Maschinenverordnung 2023/1230 (gültig ab Oktober 2027) erweitert die Maschinensicherheit auf vernetzte Maschinen mit Software. Hersteller müssen Cybersicherheit als integralen Bestandteil des Designs nachweisen, Software-Updates sicher gestalten und digitale Risikoanalysen dokumentieren. AWS-Services wie CodeArtifact, Inspector und Systems Manager unterstützen diese Anforderungen.

Kann AWS IoT Greengrass bei Netzwerkausfall weiterarbeiten?

Ja. AWS IoT Greengrass ist als Edge-Runtime konzipiert und arbeitet auch ohne Verbindung zur AWS-Cloud. Lokale Verarbeitung, Lambda-Ausführung und Datenpufferung funktionieren offline. Sobald die Verbindung wiederhergestellt ist, werden gepufferte Daten und Statusänderungen synchronisiert. Das ist essenziell für OT-Umgebungen mit strikten Verfügbarkeitsanforderungen.

Quellen und weiterführende Informationen

• EU-Richtlinie 2022/2555 (NIS2): eur-lex.europa.eu
• EU-Verordnung 2024/2847 (Cyber Resilience Act): eur-lex.europa.eu
• EU-Maschinenverordnung 2023/1230: eur-lex.europa.eu
• BSI: IT-Grundschutz für Industrielle Steuerungssysteme (ICS): bsi.bund.de
• AWS Security Hub Dokumentation: docs.aws.amazon.com
• AWS IoT Device Defender Dokumentation: docs.aws.amazon.com