C5-Themengebiet COS: Netze segmentieren und Datenflüsse dokumentieren

Diese Seite behandelt das Themengebiet COS (Kommunikationssicherheit) des C5:2026, Abschnitt 5.9 des Katalogs. Wie Kriterien und Unterkriterien grundsätzlich aufgebaut sind, erklärt die Seite C5-Kriterienkatalog.

Worum geht es im Themengebiet COS?

COS schützt Informationen in Netzen. Der Katalog nennt als Ziel, den Schutz von Informationen in Netzen und den entsprechenden informationsverarbeitenden Systemen sicherzustellen (Abschnitt 5.9). Die Kriterien verlangen technische Schutzmaßnahmen gegen netzbasierte Angriffe auf mehreren Ebenen (COS-01), festgelegte Sicherheitsanforderungen an Verbindungen (COS-02), Sicherheitszonen mit überwachten Übergängen (COS-03), Sicherheitsgateways an jedem Netzperimeter (COS-04), eigene Netze für die Administration (COS-05), die Trennung des Datenverkehrs der Kunden in gemeinsam genutzten Netzen (COS-06), eine aktuelle Dokumentation der Netztopologie (COS-07) und Richtlinien für die Datenübertragung (COS-08).

Das Gebiet umfasst acht Kriterien mit 20 Basis-Unterkriterien, einem verschärfenden und drei erweiternden Zusatz-Unterkriterien. Für einen SaaS-Anbieter auf einer Hyperscaler-Plattform betrifft COS vor allem die virtuellen Netze, die er selbst konfiguriert. Welche Verschlüsselungsverfahren für die Übertragung gelten, regelt das Gebiet CRY; wie die Daten der Schutzsysteme im SIEM ausgewertet werden, das Gebiet OPS.

Ausgangssituation: ein gewachsenes, flaches Netz

Fiktives Beispiel, kein Kunde. Ein Anbieter betreibt eine Telemonitoring-Plattform für Herzpatienten. Messgeräte in den Wohnungen senden Werte über kleine Mobilfunk-Gateways, die der Anbieter bereitstellt; Kliniken und kardiologische Praxen sehen die Werte in einem Webportal und erhalten Alarme. Der Dienst läuft als SaaS auf der Infrastruktur eines großen Cloud-Anbieters, in einem verwalteten Kubernetes-Cluster mit verwalteter Datenbank.

So sieht es vor dem Projekt aus:

• Alle Dienste liegen in einem virtuellen Netz mit einem Subnetz; die Datenbank ist von jedem Pod aus erreichbar.
• Administratoren verbinden sich per SSH direkt aus dem Büronetz, freigegeben über dessen IP-Adresse.
• Die Regeln der Sicherheitsgruppen sind über Jahre gewachsen. Wofür einzelne offene Ports gebraucht werden, weiß niemand mehr genau.
• Die Web Application Firewall schützt das Portal, nicht aber die Schnittstelle für die Messwerte.
• Das Netzdiagramm im Wiki zeigt den Stand vor zwei Jahren.
• Die Protokolle der Firewall und der Web Application Firewall liegen bei der Plattform, das SIEM des Anbieters bekommt sie nicht.

Wer ist wofür verantwortlich: Anbieter, Plattform, Kunde?

Die Grenze verläuft zwischen dem physischen Netz der Plattform und den virtuellen Netzen, die der Anbieter konfiguriert. Fünf der acht Kriterien enthalten korrespondierende Kriterien für Kunden; sie richten sich vor allem an Kunden, die selbst Teile des Dienstes verantworten, etwa virtuelle Maschinen in einer IaaS-Lösung. Unsere Einordnung für das Beispiel:

Welche Kundenkontrollen Sie voraussetzen, gehört als korrespondierende Kundenkontrollen (CUEC) in die Systembeschreibung. Betreiben Kunden in einem SaaS-Dienst keine eigenen virtuellen Netze, können die korrespondierenden Kriterien zu COS-01, COS-03, COS-04 und COS-06 ins Leere laufen; das sollte die Systembeschreibung dann ausdrücklich sagen.

Wie sieht ein prüffähiges Zonenmodell aus?

COS-03.01B verlangt, zwischen vertrauenswürdigen und nicht vertrauenswürdigen Netzen zu unterscheiden und sie auf Grundlage einer Risikobeurteilung in Sicherheitszonen für interne und externe Bereiche und gegebenenfalls eine DMZ zu trennen. COS-04.01B verlangt Sicherheitsgateways an jedem Netzperimeter, COS-05.01B getrennte Netze für die Administration. Die Trennung darf logisch sein, etwa über VLAN, SDN oder VRF. Unser Zonenmodell für das Beispiel:

Netze, über die der Anbieter Compute-Workloads erstellt, migriert oder orchestriert, trennt er nach COS-05.02B von den Netzen der Kunden. Bei einem verwalteten Kubernetes-Cluster betreibt die Plattform die Steuerungsebene; der Anbieter beschreibt, wie er den Zugriff darauf auf das Administrationsnetz beschränkt. Wie Sie eine solche Container-Plattform insgesamt prüffähig betreiben, zeigt die Seite Container und Kubernetes. Für das Büronetz legt COS-02.01B fest, dass die Sicherheitsanforderungen auch Firewalls, sichere WLAN-Konfigurationen und VPN für den Fernzugriff regeln.

Wie dokumentieren Sie Datenflüsse nach COS-07?

COS-07.01B verlangt eine nachvollziehbare und aktuelle Dokumentation, die zeigt, wie Subnetze zugewiesen sind, wie das Netz zoniert und segmentiert ist, wie es mit Netzen Dritter und öffentlichen Netzen verbunden ist und wie Daten zwischen Subnetzen und Systemkomponenten fließen. COS-02.01B verlangt festzulegen, welche Kommunikationsbeziehungen und Protokolle zugelassen sind. Beides lässt sich in einer Datenflussmatrix verbinden, die zugleich die Grundlage für das Regelwerk der Gateways ist. Ein Auszug für das Beispiel:

Zur Dokumentation gehört nach COS-07.02B außerdem, in welchen Partitionen, Regionen, Zonen oder an welchem Standort die Kundendaten gespeichert werden, und nach COS-07.03B eine Darstellung der Systeme, die aus Netztopologie und Asset-Inventar abgeleitet ist. Jede Zeile der Matrix sollte einer Regel im Gateway entsprechen und umgekehrt; das macht die Überprüfung nach COS-03 erst handhabbar.

Beispiel-Kontrollbeschreibung zu COS-03

COS-03.03B verlangt, mindestens jährlich und bei wesentlichen Änderungen am Dienst Entwurf und Umsetzung der Verbindungen gegen die Sicherheitsanforderungen zu prüfen, COS-03.05B, in festgelegten Abständen die geschäftliche Begründung für alle Dienste, Protokolle und Ports zu überprüfen, einschließlich kompensierender Maßnahmen für als unsicher geltende Protokolle. Unsere Beispiel-Kontrolle für den Anbieter oben (eigene Formulierung, kein Katalogtext):

Die halbjährliche Frequenz für Ports und Protokolle ist unsere Empfehlung; der Katalog verlangt „festgelegte Abstände“, die Sie in Ihrer Richtlinie bestimmen. Bei einem Typ-2-Bericht prüft der Prüfer, ob jeder festgelegte Durchlauf im Zeitraum stattgefunden hat.

Welche Nachweise der Prüfer sehen will

Für COS entstehen Nachweise aus Konfigurationsexporten, Netzdokumentation und Überprüfungsprotokollen. Beispiele aus unserem Szenario:

Ein Nachweisregister ordnet jedem Unterkriterium seinen Nachweis zu; wie Sie es führen, zeigt die Seite Nachweise und Dokumentation.

Mögliche Lücken: Ursache, Wirkung, Abhilfe

Die folgenden Lücken ergeben sich aus dem Wortlaut der Kriterien und dem Szenario oben. Ist ein einziges Unterkriterium nicht erfüllt, gilt das Kriterium als nicht erfüllt, und der Prüfer berichtet die Abweichung (Abschnitte 3.4.12 und 3.4.13).

Alle Kriterien des Themengebiets COS

Titel nach der deutschen Fassung 1.1.0, Zählung der Unterkriterien nach Abschnitt 5 (B = Basis, AS = verschärfend, AC = erweiternd). Die Spalte „Worum es geht“ ist unsere eigene Kurzbeschreibung, kein Katalogtext; verbindlich ist der Wortlaut der Kriterien im Katalog.

Die Zusatzkriterien: COS-01.01AC (keine unbekannten Geräte im Netz), COS-04.01AS (redundante, hochverfügbare Sicherheitsgateways), COS-05.01AC (Verschlüsselung des Administrationsverkehrs bei nicht physischer Trennung) und COS-06.01AC (für IaaS und PaaS physische Trennung oder Verschlüsselung in Kombination mit logischer Trennung). Ob COS-06 für einen SaaS-Dienst greift, hängt davon ab, ob Kunden eine Netzumgebung gemeinsam nutzen; die Trennung gespeicherter und verarbeiteter Daten ist nach den ergänzenden Informationen Gegenstand von OPS-30 und OPS-31 (Mandantentrennung).

Bezug zu ISO/IEC 27001:2022 Anhang A

Die folgende Zuordnung ist unsere eigene, nicht amtliche Einordnung nach Thema. Das BSI hat für C5:2026 noch keine Kreuzreferenz veröffentlicht, und auch eine amtliche Tabelle zeigt nach dem Katalog nur thematische Nähe, keine Erfüllung (Abschnitt 3.3). Die Kurzbezeichnungen sind unsere, keine Titel aus der Norm. Was Sie aus einem zertifizierten ISMS insgesamt wiederverwenden können, steht auf der Seite C5 und ISO 27001.