Cyber Resilience Act und private Mobilfunknetze 5G-Campusnetze: Wer trägt hier eigentlich die Verantwortung?

Anbieter zum Thema

CLOUDYRION GmbH

Vitel GmbH

Ein privates 5G-Netz vereint Technik verschiedener Anbieter. Der Cyber Resilience Act verschärft die Anforderungen an die Produktsicherheit. Betreiber müssen klären, wer im laufenden Betrieb welche Sicherheitsaufgaben übernimmt.

Private 5G-Campusnetze erlauben Produktions- und Logistikunternehmen, ihre Mobilfunkinfrastruktur auf die eigenen Anforderungen zuzuschneiden. Technisch besteht ein solches Netz jedoch aus weit mehr als Funkzellen und einem 5G-Core. Hinzu kommen Managementsysteme, Edge-Infrastruktur, Endgeräte sowie die Anbindung an IT und OT.

Die Komponenten stammen häufig von verschiedenen Herstellern. Ein Integrator führt sie zusammen, während das Unternehmen oder ein damit beauftragter Dienstleister den Betrieb übernimmt. Damit stellt sich eine praktische Sicherheitsfrage: Wer handelt, wenn in einer Komponente eine Schwachstelle bekannt wird?

Der CRA setzt beim Produkt an

Einen Teil der Antwort hierauf liefert der Cyber Resilience Act (CRA) und die dazugehörigen Meldepflichten, die seit dem 11. September 2026 greifen. Hersteller von Produkten mit digitalen Elementen müssen Cybersicherheit bereits bei Planung, Entwicklung und Produktion berücksichtigen. Außerdem müssen sie während des Unterstützungszeitraums Schwachstellen beheben und Sicherheitsupdates bereitstellen. Erfährt ein Hersteller von einer aktiv ausgenutzten Schwachstelle in seinem Produkt, muss er innerhalb von 24 Stunden eine Frühwarnung abgeben. Innerhalb von 72 Stunden folgt eine ausführlichere Meldung inklusive weiterführender Informationen und möglicher Gegenmaßnahmen. Spätestens 14 Tage, nachdem eine Korrektur- oder Risikominderungsmaßnahme verfügbar ist, muss der Hersteller dann noch einen Abschlussbericht erstellen.

Für Campusnetze ist jedoch eine Unterscheidung wichtig: Der CRA definiert Pflichten für Produkte und die beteiligten Wirtschaftsakteure. Ein heterogenes Campusnetz wird dadurch nicht zu einem Produkt mit einem einzigen Verantwortlichen. Der jeweilige Hersteller trägt die im CRA vorgesehene Verantwortung für sein Produkt. Wie die einzelnen Komponenten im Campusnetz zusammenspielen und wer dabei welche Sicherheitsaufgaben übernimmt, muss jedoch separat geregelt werden.

Hersteller, Integrator und Betreiber haben eigene Aufgaben

Dabei unterscheiden sich die Aufgaben je nach Rolle. Hersteller entwickeln ihre Produkte sicher, beheben Schwachstellen, stellen Updates bereit und liefern Informationen für einen sicheren Einsatz. Integratoren führen die Komponenten zusammen und berücksichtigen dabei Schnittstellen, Segmentierung, Managementzugänge und Konfigurationen. Betreiber kennen den konkreten Einsatzkontext und organisieren unter anderem Asset Management, Zugriffsrechte, Monitoring, Patch-Prozesse und die Reaktion auf Sicherheitsvorfälle.

Diese Zuständigkeiten sollten vor der Inbetriebnahme feststehen. Eine Verantwortungsmatrix kann regeln, wer Security Advisories überwacht, Schwachstellen bewertet, Updates testet und Änderungen freigibt. Bei extern betriebenen Campusnetzen sollte zudem klar sein, welche Security-Aufgaben der Dienstleister übernimmt und welche beim Unternehmen verbleiben.

Die Schnittstellen entscheiden mit

Bei der Sicherheitsbewertung komplexer Infrastrukturen reicht der Blick auf einzelne Komponenten nicht aus. Ein 5G-Core kann sauber gehärtet sein. Ist sein Managementzugang – etwa über SSH oder NETCONF – jedoch aus einem unnötig großen Netzsegment erreichbar oder verfügt ein Service Account über mehr Rechte als für seine Funktion nötig, entsteht das Risiko bei der Integration. Besonders relevant ist die Verbindung zur Produktionsumgebung: Über das Campusnetz kommunizieren Maschinen, Steuerungen, Sensoren und Logistiksysteme. Fehlt die Trennung zwischen Management- und Produktionssegment, kann ein Angreifer vom kompromittierten Managementzugang des Cores aus direkt auf die Anlagensteuerung zugreifen. Ein kompromittiertes System kann sich deshalb auch auf Bereiche außerhalb der eigentlichen 5G-Infrastruktur auswirken.

Administratoren müssen klar festlegen, welche Kommunikationsbeziehungen erforderlich sind und daraus Segmentierungsregeln und Berechtigungen ableiten, z.B. orientiert am Zonen- und Conduit-Modell der IEC 62443. Managementschnittstellen sollten nur von definierten Systemen aus erreichbar sein und Service Accounts nur die benötigten Rechte besitzen. Änderungen an diesen Beziehungen gehören in das Change Management und sollten sicherheitstechnisch bewertet werden. Secure-by-Design betrifft damit neben dem Produkt auch Architektur und Integration.

Patchen im Produktionsnetz braucht Vorbereitung

Wie wichtig die Abstimmung der Beteiligten ist, zeigt das Patch Management. Veröffentlicht der Hersteller einer Core-Komponente ein Update für eine kritische Schwachstelle, muss der Betreiber zunächst prüfen, ob die betroffene Version eingesetzt wird und wie groß das konkrete Risiko ist, etwa anhand des CVSS-Scores. Ist die verwundbare Funktion aktiv und erreichbar? Gibt es Hinweise auf eine Ausnutzung? Welche Maßnahmen können das Risiko bis zum Update reduzieren?

Danach müssen Teams die betrieblichen Folgen des Patches prüfen. Ein Neustart kann Maschinenkommunikation oder fahrerlose Transportsysteme beeinträchtigen. Administratoren brauchen deshalb Testverfahren, Wartungsfenster, Freigaben und Rückfalloptionen. Diese Abläufe müssen bereits vor dem Ernstfall fest definiert sein. Der Hersteller liefert Sicherheitsinformationen und Updates, der Integrator kennt technische Abhängigkeiten und der Betreiber entscheidet anhand des Einsatzes über Priorität und Rollout.

SBOM und Asset Management zusammenführen

Vulnerability Management setzt einen aktuellen Überblick der eingesetzten Technik voraus. Betreiber sollten für relevante Komponenten mindestens Hersteller, Produkt, Version, Einsatzort, Verantwortlichen und technische Abhängigkeiten dokumentieren. Der CRA verpflichtet Hersteller zugleich, Komponenten ihrer Produkte zu identifizieren und zu dokumentieren. Dazu gehört eine Software Bill of Materials (SBOM), die mindestens die Top-Level-Abhängigkeiten erfasst (z.B. im SPDX- oder CycloneDX-Format).

Nützlich wird die SBOM für den Betreiber in Verbindung mit dem eigenen Asset Management. Bei einer Schwachstelle muss der Betreiber schnell feststellen können, welche Systeme und Versionen betroffen sind, welche Funktion sie erfüllen und wie exponiert sie sind. Damit kann der Betreiber das konkrete Risiko für das eigene Netz bewerten und Maßnahmen priorisieren.

Fünf Punkte für den sicheren Betrieb

Für den sicheren Betrieb eines 5G-Campusnetzes müssen technische Maßnahmen und organisatorische Abläufe ineinandergreifen. Daraus lassen sich fünf zentrale Punkte für die Praxis ableiten:

• Komponenten und Abhängigkeiten erfassen: RAN, Core, Edge-Systeme, Managementsoftware, Endgeräte und IT-/OT-Verbindungen müssen samt Versionen und Zuständigkeiten im Inventar stehen.

• Verantwortlichkeiten festlegen: Für Schwachstellen, Updates und Sicherheitsvorfälle braucht es benannte Ansprechpartner. Aufgaben und Reaktionszeiten sollten auch mit Integratoren und Dienstleistern geregelt sein.

• Security in die Beschaffung aufnehmen: Update-Zeiträume, der Umgang mit Schwachstellen und Informationen zu Softwareabhängigkeiten sollten vor der Auswahl einer Komponente geklärt sein.

• Patch- und Incident-Prozesse testen: Ansprechpartner, Testmöglichkeiten und Freigabewege müssen auch unter Zeitdruck funktionieren.

• Änderungen neu bewerten: Neue Geräte, Netzsegmente, Softwarestände und Schnittstellen gehören in die laufende Sicherheitsbewertung.

Sicherheit entsteht über den gesamten Lebenszyklus

Der CRA stärkt die Produktsicherheit, löst aber nicht die Sicherheitsfragen des gesamten Campusnetzes. Betreiber müssen dafür sorgen, dass sicherheitsrelevante Informationen zwischen Herstellern, Integratoren und dem eigenen Team zuverlässig fließen können. Zudem sollten sie Updates kontrolliert in den Betrieb einbringen und Änderungen an der Architektur neu bewerten.

Wer diese Abläufe bereits bei Planung und Aufbau festlegt, schafft die Grundlage für einen sicheren Betrieb über den gesamten Lebenszyklus. Secure-by-Design beginnt damit schon lange vor dem ersten Patch.

Über den Autor

Okay Güler ist Gründer und CEO von Cloudyrion. Nachdem er im Banking und Automotive-Bereich Erfahrung als Ethical Hacker sammeln konnte, gründete Güler 2020 Cloudyrion. Seine Motivation: Unternehmen zu helfen, die neuen Herausforderungen im Cyberspace zu bewältigen und Awareness für Secure-by-Design zu schaffen.

(ID:51002993)