NIS-2 Netzwerkkomponenten: Cisco Meraki konform betreiben

29.000 Unternehmen in Deutschland fallen unter NIS-2. [Quelle einfügen] Jedes betreibt Switches, Router und Firewalls. Jedes Gerät ist nach §30 BSIG dokumentations-, härtungs- und auditpflichtig. Cisco Meraki ist in deutschen Mittelstands- und KRITIS-Umgebungen weit verbreitet. Im Auslieferungszustand erfüllt die Plattform die NIS-2-Anforderungen nicht. Dieser Beitrag zeigt, was konkret nachzuziehen ist, welche Lücken bleiben und wie der Übergang in 90 Tagen organisiert wird.

NIS-2 Netzwerkkomponenten: Was §30 BSIG konkret verlangt

§30 BSIG fordert technische und organisatorische Maßnahmen nach Stand der Technik für alle Netzwerk- und Informationssysteme. Die Norm ist als Auffangtatbestand formuliert. Jede Komponente, die Datenverkehr transportiert, terminiert oder filtert, fällt darunter. Das umfasst Switches, Router, Firewalls, Access Points, SD-WAN-Gateways sowie deren Management-Plane. Das Bundesministerium des Innern dokumentiert die Umsetzungspflichten zum BSIG in der laufenden Ressortabstimmung.

Konformität bedeutet vier nachweisbare Bausteine. Erstens: dokumentierte Risikoanalyse pro Asset-Klasse. Zweitens: Patch-Management mit definierter Reaktionszeit, üblich sind 48 Stunden für kritische CVEs [Quelle einfügen]. Drittens: segmentierte Netze mit Layer-3-Trennung zwischen Funktionsbereichen. Viertens: Logging mit 12-Monats-Retention außerhalb des überwachten Systems selbst. [Quelle einfügen]

Die NIS-2-Richtlinie verlangt in Artikel 21 explizit Lieferkettensicherheit und die Bewertung direkter Lieferanten. Übersetzt heißt das: Hersteller-Audits, SBOM-Anforderungen und EU-Datenresidenz für Management-Clouds gehören in den Vertrag. Der Marketingprospekt ist dafür nicht der richtige Ort.

Nichtkonformität ist sanktionsbewehrt. Bußgelder reichen bis 10 Mio. € oder 2 % des weltweiten Umsatzes. [NIS-2-Richtlinie Art. 34, Link einfügen] Hinzu kommt persönliche Vorstandshaftung nach §38 BSIG. Wer dies operativ einordnen will, beginnt mit der NIS-2 Compliance Übersicht.

Cisco Meraki im NIS-2-Kontext: Stärken und Lücken

Das Meraki Dashboard ist ISO-27001- und FedRAMP-zertifiziert. EU-Datencenter stehen in Deutschland (Frankfurt) und den Niederlanden (Amsterdam) zur Verfügung. Die Wahl der Datenregion ist organisationsweit pro Tenant konfigurierbar. Für NIS-2-Pflichtige in der EU ist die EU-Region zwingend.

Automatisches Firmware-Management ist die operative Stärke der Plattform. Sicherheitspatches lassen sich nach Wartungsfenster planen und werden ohne manuellen Eingriff ausgerollt. Damit ist die §30-Anforderung an zeitnahes Patchen technisch abgedeckt. Die organisatorische Pflicht zur Dokumentation des Patch-Status pro Gerät bleibt jedoch beim Betreiber.

Die erste Lücke: Default-Konfigurationen sind nicht NIS-2-konform. MFA ist nicht erzwungen, lokale Admin-Accounts existieren parallel zum SAML-Login, API-Token rotieren nicht automatisch. Die zweite Lücke: Cloud-Management-Abhängigkeit. Verliert die Organisation die Dashboard-Verbindung, laufen die Geräte mit letztem Stand weiter, aber Konfigurationsänderungen sind unmöglich. Ein dokumentierter Notfallplan inklusive lokaler Backup-Konfigurationen ist Pflicht.

Dritte Lücke: Logging. MX-Firewalls liefern IDS/IPS und Advanced Malware Protection (AMP), aber die Meraki-eigene Log-Retention reicht nicht für 12 Monate. Syslog-Export an ein externes SIEM (Splunk, Elastic, Sentinel) ist Voraussetzung. Vierte Lücke: Meraki MV-Kameras werden häufig als physische Sicherheitssysteme klassifiziert, sind technisch jedoch Netzwerkkomponenten mit eigener IP-Schnittstelle. Sie unterliegen denselben Härtungs- und Logging-Pflichten wie ein Access Point.

Konkrete Härtungs-Checkliste für Meraki-Deployments

Die folgenden Maßnahmen sind in einer NIS-2-pflichtigen Meraki-Umgebung Pflicht, nicht optional.

Identität und Zugang. MFA für alle Dashboard-Accounts erzwingen. Lokale Admin-Accounts deaktivieren. SAML-SSO mit dem Identity Provider (Entra ID, Okta, Keycloak) koppeln. Just-in-Time-Provisionierung über SCIM aktivieren, damit Personalabgänge automatisch entzogen werden.

API-Sicherheit. Organisations-übergreifende API-Keys auf 90 Tage Rotation setzen. [Quelle oder BSI-Grundschutz-Referenz einfügen] Jeden API-Zugriff über das Audit-Log nach Splunk oder Elastic spiegeln. Read-only-Keys für Monitoring strikt von Write-Keys für Konfigurationsänderungen trennen.

Segmentierung. VLANs für OT, IT, Gäste, IoT und Sicherheitssysteme strikt getrennt. Zwischen den Segmenten Layer-3-Firewall-Regeln mit explizitem Default-Deny. OT-Verkehr nie ins Office-VLAN routen. Sicherheitssysteme (Kameras, Zutrittskontrolle, Patrouillenroboter) erhalten ein eigenes Segment.

Kryptografie. Site-to-Site-VPN ausschließlich mit AES-256-GCM und IKEv2. Legacy-Cipher (3DES, MD5, SHA1) deaktivieren. Pre-shared Keys mit mindestens 32 Zeichen und 12-Monats-Rotation. Wo verfügbar: Zertifikatsbasierte Authentifizierung statt PSK.

Logging. Syslog-Export an externes SIEM aktivieren. Mindestens Severity-Level Informational für Firewall-Events, Notice für Switch-Events. Logs außerhalb der Meraki-Cloud archivieren, da die Plattform-eigene Retention für §30 BSIG nicht ausreicht.

Asset-Register. Geräte-Standorte, Seriennummern, MAC-Adressen, Firmware-Versionen und letzte Patch-Termine dokumentieren. §30 BSIG verlangt vollständiges Asset-Inventar. Eine wöchentliche JSON-Extraktion über die Meraki-API in eine CMDB ist Mindeststandard.

Lieferkettensicherheit: Cisco als Hersteller unter NIS-2

NIS-2 Artikel 21 Absatz 2(d) verlangt Bewertung der Sicherheitspraktiken direkter Lieferanten. Der Hersteller einer kritischen Netzwerkkomponente ist immer ein direkter Lieferant im Sinne der Norm. Die Bewertung ist dokumentationspflichtig und prüfbar.

Cisco veröffentlicht PSIRT-Advisories und betreibt einen formellen CVE-Disclosure-Prozess. Damit ist die Transparenzanforderung dokumentarisch erfüllt. Was fehlt, ist die vertragliche Absicherung. Folgende Klauseln gehören in den Rahmenvertrag oder die SLA: Notifikationspflicht bei Sicherheitsvorfällen innerhalb 24 Stunden, Bereitstellung einer SBOM für jede Major-Release. Hinzu kommen eine EOL-Roadmap mit mindestens 5 Jahren Vorlauf [Quelle einfügen] und definierte Reaktionszeiten für kritische Patches.

Das Cisco Trust Portal liefert auditfähige Zertifikatsnachweise (ISO 27001, SOC 2, FedRAMP, Common Criteria). Diese Nachweise gehören in das eigene Compliance-Dossier, mit Versionierung und Ablaufdatum. Bei KRITIS-Einsatz nach KritisV ist zusätzlich die BSI-Vertrauenswürdigkeitserklärung nach §9b BSIG für kritische Komponenten zu prüfen. Die KritisV definiert Schwellenwerte und Sektoren, die NIS-2-pflichtige Netzwerkkomponenten betreiben.

Die operative Konsequenz: Lieferantenbewertung ist kein einmaliger Beschaffungsschritt, sondern jährlicher Review-Prozess. Die KRITIS-Dachgesetz Checkliste listet die parallelen Pflichten für physische Komponenten.

Integration mit physischem Perimeterschutz

NIS-2 erfasst Netzwerk und physische Sicherheit als integrierten Geltungsbereich. Getrennte Compliance-Silos zwischen IT und Werkschutz sind nicht mehr zulässig. Das BBK koordiniert die sektorübergreifende Umsetzung genau in dieser Logik.

Konkret: Quarero-Patrouillenroboter QR-2 und QR-3 nutzen Meraki-MR-Access-Points für die WLAN-Backhaul-Verbindung, mit LTE-Fallback bei AP-Ausfall. Die Roboter-Telemetrie läuft über ein dediziertes VLAN mit Layer-7-Firewall-Regel, isoliert von Office- und OT-Netz. Die Datenströme: Live-Video an das VMS, Sensor-Heartbeat an die Leitstelle, Eventlogs an das SIEM.

Meraki MV-Kameras und die LiDAR-Daten des QR-3 mit LiDAR und Drohnenerkennung werden im selben SIEM korreliert. Doppel-Detektion (Kamera-Bewegung plus LiDAR-Objekt) reduziert Fehlalarme um 60 bis 80 % gegenüber Einzelsensorik. [Quelle einfügen] Operativ heißt das: Streifenleitstand und Network Operations Center arbeiten auf derselben Event-Pipeline.

Der dokumentierte Incident-Response-Prozess deckt beide Domänen ab. Eine Netzwerkanomalie (laterale Bewegung im OT-VLAN) und ein Perimeterbruch (LiDAR-Detektion am Zaun) lösen denselben Eskalationspfad aus. Tabletop-Übungen testen beide Szenarien quartalsweise. Eine reine IT-Übung erfüllt die NIS-2-Anforderung nicht. Praktische Umsetzung siehe Perimeterschutz im Industriepark.

Vorstandshaftung bei nicht-konformen Netzwerkkomponenten

§38 BSIG normiert persönliche Haftung der Geschäftsleitung für Umsetzung und Überwachung der Risikomaßnahmen. Die Norm ist scharf formuliert. Delegation an die IT-Leitung entlastet nicht. Der Vorstand muss das Risikomanagementsystem genehmigen, dokumentiert prüfen und selbst Schulungen durchlaufen.

Versicherbar ist die Haftung nur, wenn dokumentierte Sorgfaltspflicht nachgewiesen wird. Das schließt Lieferantenbewertung, Audit-Trails und Schulungsnachweise ein. D&O-Versicherer prüfen diese Unterlagen vor Deckungszusage. Im Schadensfall erfolgt dieselbe Prüfung erneut. Fehlt der Nachweis, fällt die Deckung. BaFin-aufsichtspflichtige Unternehmen unterliegen zusätzlich MaRisk AT 7.2 mit verschärften Dokumentationspflichten zur IT-Governance.

Operativ entscheidend ist die Beweislastumkehr. Bei einem Vorfall muss der Vorstand aktiv Compliance nachweisen. Nicht die Behörde beweist den Verstoß, sondern die Geschäftsleitung beweist die Sorgfalt. Wer keinen aktuellen Audit-Bericht und keine Schulungshistorie vorlegt, hat verloren. Das Verfahren ist dann bereits entschieden. Details zur Haftungsfrage stehen in Vorstandshaftung unter NIS-2.

Audit-Vorbereitung: Was Prüfer bei Meraki-Setups verlangen

Prüfer verlangen bei Meraki-Umgebungen sechs Artefakte. Das gilt für BSI-Prüfungen, beauftragte Auditoren und Wirtschaftsprüfer im Rahmen der Jahresabschlussprüfung. Wer diese vorhält, übersteht das Audit ohne Nachforderungen.

1. Vollständige Asset-Liste. MAC-Adresse, Seriennummer, physischer Standort, Firmware-Version und letzter Patch-Termin pro Gerät. Format: CSV oder CMDB-Export, kein PDF.

2. Konfigurations-Exporte. JSON via Meraki-API mit Zeitstempel, mindestens quartalsweise archiviert in einem schreibgeschützten Repository. Versionsdiff bei jeder Änderung dokumentiert.

3. MFA-Nachweis. Screenshots oder API-Export, der MFA-Aktivierung für 100 % der Dashboard-Accounts belegt. Kein Ausnahmekonto. Service-Accounts laufen über API-Keys mit getrenntem Rotations-Audit.

4. Penetrationstest-Berichte. Jährlich erneuert, Fokus auf Cloud-Management-Plane und API-Endpunkte. Externer Anbieter mit OSCP- oder CREST-Zertifizierung.

5. Incident-Response-Playbook. Benannte Rollen, Eskalationskette, Recovery Time Objective (RTO) unter 4 Stunden für kritische Netzwerksegmente. [Quelle einfügen] Letzter Test maximal 12 Monate alt.

6. Schulungsnachweise. Administratoren und Geschäftsleitung nach §38 Absatz 3 BSIG. Inhalte, Teilnehmerliste, Prüfungsergebnis, Wiederholungsintervall.

Fehlt eines dieser Artefakte, ist das Audit-Ergebnis "wesentliche Feststellung". Bei zwei Fehlern wird die Konformität insgesamt verneint.

Nächste Schritte: 90-Tage-Plan zur NIS-2-Konformität

Der folgende Zeitplan ist in mittelständischen Umgebungen mit 200 bis 2.000 Meraki-Geräten umsetzbar. Voraussetzung: ein dedizierter Projektleiter und Vorstandsmandat.

Tag 1 bis 14: Bestandsaufnahme. Asset-Inventar über Meraki-API extrahieren. Organisation auditieren: Wie viele Admin-Accounts, wie viele API-Keys, welche Datenregion, welche Lizenzklasse pro Gerät. MFA und SAML-SSO erzwingen. Lokale Accounts deaktivieren oder mit MFA absichern.

Tag 15 bis 45: Technische Härtung. VLAN-Segmentierung produktiv schalten. Layer-3-Firewall-Regeln mit Default-Deny umsetzen. SIEM-Anbindung über Syslog produktiv. Lieferantenverträge mit Cisco und Distributoren nachverhandeln: 24-Stunden-Notifikation, SBOM, EOL-Roadmap.

Tag 46 bis 75: Organisatorische Reife. Incident-Response-Playbook schreiben und in Tabletop-Übung testen. Geschäftsleitung nimmt teil, nicht nur die IT. Schulungen für Administratoren und Vorstand abschließen, inklusive Prüfung und Zertifikat.

Tag 76 bis 90: Auditierung. Externes Audit beauftragen. Restmaßnahmen aus dem Audit-Bericht schließen. Compliance-Dossier finalisieren mit allen sechs Artefakten aus dem vorherigen Kapitel.

Parallel zur Netzwerkebene ist der physische Perimeterschutz zu prüfen. NIS-2 und KRITIS-Dachgesetz verlangen integrierte Sicht. Wer Wachschutz zukauft, vergleicht die Kostenbasis über den Wachschutz TCO-Vergleich. Wer auf autonome Patrouille umstellt, prüft das Robotics-as-a-Service Modell, da CapEx-Anschaffung in 2025 selten budgettauglich ist.

Die operative Konformitätsprüfung beginnt mit einem strukturierten Self-Assessment. Der Einstieg dafür liegt in der NIS-2 Compliance Übersicht. Dort sind Templates für Asset-Register, Lieferantenbewertung und Incident-Response-Playbook hinterlegt, die direkt in eine Meraki-Umgebung übertragbar sind.