Art. 21(2)(e) NIS 2 + CIR §6.7 + §6.8

NIS 2 Netzsicherheit nach Artikel 21(2)(e)

NIS 2 verlangt Sicherheit bei Erwerb, Entwicklung und Wartung Ihrer Netz- und Informationssysteme. Artikel 21(2)(e) ist die Pflicht, CIR (EU) 2024/2690 §6.7 und §6.8 sind die netzspezifischen Vorgaben, und §30(2) Nr. 5 BSIG ist die deutsche Umsetzung.

Simon OrzelSimon Orzel·

Die Kurzfassung

Artikel 21(2)(e) ist Punkt fünf auf der Liste der zehn Cybersicherheitspflichten unter NIS 2. Er deckt den gesamten Lebenszyklus von Netz- und Informationssystemen ab: wie Sie sie beschaffen, wie Sie sie entwickeln und wie Sie sie sicher betreiben. CIR (EU) 2024/2690 §6 operationalisiert das in mehreren Unterabschnitten. Die netzspezifischen Stücke sind §6.7 (Netzsicherheit) und §6.8 (Netzsegmentierung).

§6.7 ist der schwierigere Teil. Zwölf konkrete Maßnahmen, von der Dokumentation der Netzarchitektur über DNS-Hygiene bis zur sicheren E-Mail-Kommunikation. §6.8 ist der einfachere: Teilen Sie das Netz in Zonen, basierend darauf, was jede Zone leisten soll, und halten Sie Produktion, Test und Administration getrennt.

Deutschland setzt dieselbe Pflicht über §30(2) Nr. 5 BSIG um. Das BSI verweist auf IT-Grundschutz NET.1 (Netze und Kommunikation) und NET.3.2 (Firewall) als praktischen Umsetzungsweg. Diese Seite geht die Richtlinie, die CIR und die deutsche Ebene in dieser Reihenfolge durch.

Die Rechtsquelle
Drei Ebenen übereinander. Die Richtlinie. Die Durchführungsverordnung. Die deutsche Umsetzung. Alle drei sagen dasselbe in unterschiedlichen Worten.

Artikel 21(2)(e) NIS 2 Richtlinie (2022/2555)

Sicherheit bei Erwerb, Entwicklung und Wartung von Netz- und Informationssystemen, einschließlich Management und Offenlegung von Schwachstellen.

Punkt (e) auf der Liste in Artikel 21(2). Er deckt den vollen Lebenszyklus Ihrer Netz- und IT-Systeme ab, nicht nur den laufenden Betrieb. CIR §6 bricht das in mehrere Unterabschnitte herunter. §6.7 und §6.8 sind die netzspezifischen.

CIR (EU) 2024/2690, Anhang §6.7 und §6.8

§6.7 Netzsicherheit. Die betroffenen Einrichtungen treffen geeignete Maßnahmen, um ihre Netz- und Informationssysteme vor Cyberbedrohungen zu schützen. §6.8 Netzsegmentierung. Die betroffenen Einrichtungen segmentieren ihre Systeme […] in Netze oder Zonen entsprechend den Ergebnissen der Risikobewertung […]; sie trennen auch ihre eigenen Systeme und Netze von Systemen und Netzen Dritter.

Weil es eine Verordnung ist (keine Richtlinie), gilt sie unmittelbar als EU-Recht. §6.7 listet zwölf konkrete Maßnahmen, von dokumentierter Netzarchitektur bis DNS- und E-Mail-Hygiene. §6.8 listet acht Segmentierungsmaßnahmen, darunter DMZ, getrennte Administrationsnetze und Trennung von Produktion und Entwicklung/Test.

§30(2) Nr. 5 BSIG (Deutschland)

Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung von informationstechnischen Systemen, Komponenten und Prozessen, einschließlich Management und Offenlegung von Schwachstellen.

Deutschland übernimmt den EU-Text fast wörtlich. Das BSI verweist anschließend auf IT-Grundschutz NET.1 (Netze und Kommunikation) und NET.3.2 (Firewall) als anerkannten Umsetzungsweg für die §6.7- und §6.8-Details.

Die drei Stücke aus CIR §6.7 und §6.8
CIR teilt Netzsicherheit auf zwei Unterabschnitte auf. Wir gruppieren sie in drei: Dokumentation und Zugriffskontrollen aus §6.7, Protokoll- und Geräte-Hygiene aus §6.7, und Segmentierungsregeln aus §6.8.
§6.7.2(a)-(f)

Netz dokumentieren, interne Zugriffe kontrollieren

Halten Sie ein aktuelles und klares Diagramm der Netzarchitektur. Definieren und wenden Sie Kontrollen an, um interne Domänen vor unautorisiertem Zugriff zu schützen. Sperren Sie Verbindungen und Dienste, die nicht gebraucht werden. Definieren Sie separate Kontrollen für Fernzugriffe, auch für Dienstleister. Verwenden Sie Admin-Systeme nicht für andere Zwecke. Schalten Sie ungenutzte Verbindungen und Dienste ab oder verbieten Sie sie ausdrücklich.

§6.7.2(g)-(l)

Geräte-, Protokoll-, DNS- und E-Mail-Hygiene

Beschränken Sie, wo angemessen, den Zugriff auf zugelassene Geräte. Lassen Sie Dienstleisterzugänge nur nach Freigabeanfrage und nur für ein festgelegtes Zeitfenster zu (zum Beispiel für Wartung). Lassen Sie System-zu-System-Kommunikation nur über vertrauenswürdige Kanäle laufen, logisch, kryptografisch oder physisch getrennt, mit sicherer Endpunkt-Identifikation. Planen und beschleunigen Sie die Migration auf moderne Netzwerkprotokolle. Übernehmen Sie moderne interoperable E-Mail-Standards, um E-Mail-Schwachstellen zu schließen. Wenden Sie bewährte Verfahren für DNS-Sicherheit und Routing-Hygiene auf ein- und ausgehenden Verkehr an.

§6.8

Nach Risiko segmentieren, Produktion von Test und Administration trennen

Segmentieren Sie Ihre Systeme in Netze oder Zonen anhand des Ergebnisses der Risikobewertung aus §2.1, nicht nach Bequemlichkeit. Berücksichtigen Sie funktionale, logische, physische und ortsbezogene Beziehungen zwischen vertrauenswürdigen Systemen. Erteilen Sie Zugriff auf eine Zone auf Basis ihrer Sicherheitsanforderungen. Setzen Sie für Betrieb oder Sicherheit unverzichtbare Systeme in gesicherte Zonen. Betreiben Sie eine DMZ. Beschränken Sie Zugriffe in und zwischen Zonen auf das, was Betrieb und Sicherheit erfordern. Betreiben Sie ein dediziertes Administrationsnetz, getrennt vom Betriebsnetz. Halten Sie Administrationskanäle vom übrigen Netzverkehr getrennt. Trennen Sie Produktionssysteme von Entwicklung und Test, inklusive Backups.

Zwei Regeln, die alles andere prägen
Zwei Grundregeln liegen unter §6.7 und §6.8. Sie entscheiden, ob Ihr Netz die Norm wirklich erfüllt oder nur so aussieht.

Nach Risiko segmentieren, nicht nach Bequemlichkeit

CIR §6.8.2 koppelt Segmentierung an §2.1: Die Risikobewertung sagt Ihnen, welche Zonen Sie brauchen und wie streng die Grenzen zwischen ihnen sein müssen. Ein flaches Netz mit einer Firewall ist keine Segmentierung. Zonen nach dem, was ein Geschäftsbereich tatsächlich tut, und nach dem Risiko, das er trägt, sind es. Wenn Sie nicht auf die Zeile in der Risikobewertung zeigen können, die eine Zone begründet, haben Sie keine Segmentierung im Sinne der Norm.

Architektur dokumentieren, aktuell halten

§6.7.2(a) steht aus gutem Grund an erster Stelle. Alles andere in §6.7 und §6.8 hängt an einem dokumentierten und aktuellen Netzdiagramm. Auditoren schauen zuerst auf das Diagramm. Wenn es nicht existiert oder zwei Jahre alt ist, wird jede andere Kontrolle schwerer prüfbar. Behandeln Sie das Diagramm als lebendes Dokument, nicht als einmalige Visio-Datei.

Wie nationale Aufsichten das in der Praxis führen
Die EU setzt die Regel. Jedes Land setzt sie um. Die Substanz bleibt gleich. Die lokale Mechanik unterscheidet sich.
Deutschland

BSI / §30(2) Nr. 5 BSIG / IT-Grundschutz

Das BSI verweist auf IT-Grundschutz NET.1 (Netze und Kommunikation) für allgemeines Netzdesign und NET.3.2 (Firewall) für Perimeter und Segmentierung. Beide Bausteine bilden die §6.7- und §6.8-Maßnahmen fast eins zu eins ab. Wenn Sie ein Grundschutz-konformes Netz betreiben, können Sie die bestehende Dokumentation als Evidenzbasis nutzen.

EU-weit

ENISA Technical Implementation Guidance

Die ENISA TIG deckt Artikel 21(2)(e) und die CIR-§6-Unterabschnitte ab, inklusive Netzsicherheit und Segmentierung. Sie ordnet die Anforderungen ISO/IEC 27001:2022 (A.8.20 Netzsicherheit, A.8.21 Sicherheit von Netzdiensten, A.8.22 Netztrennung) und NIST CSF 2.0 PR.IR (Technology Infrastructure Resilience) zu. Wenn Sie einen dieser Standards bereits betreiben, können Sie die Controls wiederverwenden.

Andere Mitgliedstaaten

Nationale Umsetzungsgesetze

Andere Mitgliedstaaten setzen Artikel 21(2)(e) in eigenen Gesetzen um (Niederlande: Cyberbeveiligingswet, Österreich: NISG, Belgien: NIS2-Wet). Die Substanz ist identisch, weil das CIR-§6-Detail die genannten Sektoren unmittelbar bindet. Was sich unterscheidet, ist die zuständige Behörde und welche nationale Umsetzungsguidance Sie neben der CIR lesen.

Drei Fallen, die wir ständig sehen
Drei Sätze, die in fast jedem Audit-Vorgespräch fallen. Alle drei lassen eine §6.7- oder §6.8-Lücke offen, die ein Auditor findet.
  • Wir haben eine Firewall, also sind wir abgedeckt.

    Eine Firewall ist gut. Sie ist nicht ganz §6.7. §6.7.2(a) verlangt eine dokumentierte und aktuelle Netzarchitektur. §6.7.2(c) verlangt, dass ungenutzte Verbindungen und Dienste standardmäßig gesperrt sind. §6.7.2(f) verlangt, dass ungenutzte Dienste ausdrücklich verboten oder deaktiviert sind. §6.8 verlangt Segmentierung nach Risiko. Eine Firewall ohne diese vier Stücke erfüllt eine Zeile aus §6.7, nicht den Abschnitt.

  • Produktion und Test laufen im gleichen Netz, das ist einfacher.

    §6.8.2(h) ist eindeutig: Produktionssysteme für Livedienste müssen von Entwicklung und Test getrennt sein, inklusive Backups. Das ist eine der am schwersten nachzurüstenden Lücken und eine der am leichtesten zu findenden für Auditoren. Ein gemeinsames Subnetz für Prod und Test übersteht die §6.8-Prüfung nicht.

  • Unsere Admins greifen vom normalen Arbeitsplatz auf die Firewall zu.

    §6.8.2(f) verlangt ein dediziertes Administrationsnetz für Systeme. §6.8.2(g) verlangt, dass Administrationskanäle vom übrigen Netzverkehr getrennt sind. Wer sich von einem Arbeitsplatz, auf dem auch E-Mail und Browser laufen, auf eine Firewall einloggt, bricht beides. Setzen Sie einen dedizierten Jump-Host oder eine Privileged Access Workstation ein, auf einem separaten Management-VLAN.

Wie Mittelstandsbetriebe das tatsächlich machen

Ein typisches Mittelstandsnetz mit 60 bis 250 Mitarbeitenden hat bereits eine Firewall und oft eine DMZ. Die §6.7- und §6.8-Lücken, die wir sehen, sind meistens dieselben drei: kein dokumentiertes Netzdiagramm, kein dediziertes Administrationsnetz, und Prod und Test im gleichen Subnetz. Jede davon ist einmal billig aufzuschreiben und später teuer nachzurüsten.

Pragmatische Reihenfolge: das aktuelle Netz auf eine Seite zeichnen, nach dem segmentieren, was jede Zone tatsächlich tut (Office, Server, DMZ, OT oder Produktion, Administration), aufschreiben welche Verbindungen zwischen Zonen erlaubt sind und warum, und Admin-Zugänge in ein separates Management-VLAN mit Jump-Host ziehen. Das deckt §6.7.2(a), den Segmentierungskern von §6.8 und die Trennung des Administrationsnetzes nach §6.8.2(f) und (g) ab. Der Rest ist Hygiene, die daraus folgt.

Wie wir das auf der Plattform abbilden

Das PRO-Modul auf der Plattform hält das Verzeichnis der Netzarchitektur, die Segmentierungsregeln und das Register des Administrationsnetzes. Sie tragen jede Zone ein, was sie tut, wohin sie verbunden ist und welche Zeile aus der Risikobewertung sie begründet. Diagramm und Segmentierungslogik liegen an einem Ort, nicht verteilt zwischen einer Visio-Datei und einer Confluence-Seite.

Änderungen am Netz werden mitgeschrieben, sobald sie passieren, sodass §6.7.2(a) ein lebendes Dokument bleibt statt einer Momentaufnahme. Der Audit-Trail erfasst, wer was wann geändert hat. Das ist die Evidenz, nach der ein Auditor fragt, wenn er prüft, ob die Dokumentation die Realität abbildet.

Quellen
  • Richtlinie (EU) 2022/2555 (NIS 2), Artikel 21(2)(e) — eur-lex.europa.eu/eli/dir/2022/2555/oj
  • Durchführungsverordnung (EU) 2024/2690 (CIR), Anhang §6.7 und §6.8 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
  • BSI-Gesetz (BSIG), §30(2) Nr. 5 in der Fassung des NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetzes
  • BSI IT-Grundschutz, Bausteine NET.1 (Netze und Kommunikation) und NET.3.2 (Firewall) — bsi.bund.de/grundschutz
  • ENISA Technical Implementation Guidance zur CIR (EU) 2024/2690 (Stand Mai 2026)
Netzsicherheits-Evidenz ohne Excel-Stapel
Netzarchitektur, Segmentierungsregeln und Administrationsnetz-Register auf einer Plattform, gekoppelt an die Risikobewertung. Kostenlos, Open Source, kein Lock-in.