Der Cyber Resilience Act beginnt im Produkt

Vernetzte Maschinen, digitale Dienste und softwarebasierte Sicherheitskomponenten haben die Produktion flexibler gemacht. Sie haben aber auch eine neue Form der Verwundbarkeit geschaffen. Wo früher eine trennende Schutzeinrichtung, ein Sicherheitsschalter oder eine Steuerung weitgehend für sich stand, entstehen heute Verbindungen: zu Netzwerken, Wartungssystemen, Cloud-Anwendungen oder anderen Maschinen.

Der Cyber Resilience Act, kurz CRA, trägt dieser Entwicklung Rechnung. Er macht Cybersicherheit bei Produkten mit digitalen Elementen zu einer Anforderung, die nicht nur bei der Markteinführung erfüllt sein muss. Hersteller sollen ihre Produkte über den gesamten Lebenszyklus hinweg beobachten, Schwachstellen bewerten und angemessen darauf reagieren.

Was zunächst nach einer weiteren Aufgabe für die IT klingt, greift tief in Produktentwicklung, Konstruktion, Dokumentation und Service ein. Im Gespräch mit PRODUKTION erläutern Marc Wiederoder und Xabier Antolin von Euchner, was daraus für Hersteller, Zulieferer und Betreiber folgt.

PRODUKTION: Herr Antolin, Herr Wiederoder, der Cyber Resilience Act wird häufig als neues IT-Sicherheitsgesetz wahrgenommen. Ist das die entscheidende Fehleinschätzung?

Xabier Antolin: Ja. Wer den CRA ausschließlich bei der IT-Abteilung verortet, unterschätzt seine Tragweite. Die Verordnung betrifft Produkte mit digitalen Elementen und damit deren Entwicklung, Herstellung und Pflege. Im Maschinenbau sind deshalb nicht nur die IT-Verantwortlichen gefordert, sondern ebenso Konstruktion, Produktmanagement, Einkauf, Qualitätsmanagement, Dokumentation und Service.

Das ist ein wichtiger Perspektivwechsel. Cybersecurity wird zu einer Produkteigenschaft. Unternehmen müssen nicht nur ihre eigenen Netzwerke schützen, sondern auch beurteilen, welche Risiken von einem Produkt ausgehen können, wie es eingesetzt werden soll und welche Grenzen für den sicheren Betrieb gelten.

Was bedeutet das für Safety-Komponenten, die zunehmend vernetzt oder softwarebasiert sind?

Marc Wiederoder: Zunächst müssen Hersteller den Anwendungskontext sehr genau beschreiben. Sie legen fest, für welche Einsatzgebiete ein Produkt vorgesehen ist, unter welchen Bedingungen es sicher betrieben werden kann und welche Anwendungen ausgeschlossen werden müssen.

Das klingt zunächst nach Dokumentation. Tatsächlich beginnt die Arbeit aber wesentlich früher. Kommunikationsschnittstellen, Firmware, Update-Mechanismen oder eingesetzte Softwarebibliotheken müssen bereits während der Entwicklung unter Cybersecurity-Gesichtspunkten betrachtet werden. Bei sicherheitsrelevanten Komponenten kommt hinzu, dass eine Manipulation nicht nur Daten oder Verfügbarkeit beeinträchtigen kann. Sie kann im ungünstigsten Fall eine Safety-Funktion beeinflussen.

Aus einem Security-Problem kann also unmittelbar ein Risiko für Menschen oder Anlagen entstehen?

Marc Wiederoder: Genau. Funktionale Sicherheit und Cybersecurity haben unterschiedliche Ausgangspunkte. Safety soll gefährliche Maschinenzustände verhindern. Security soll Systeme unter anderem vor unbefugtem Zugriff, Manipulation und missbräuchlicher Nutzung schützen.

In einer vernetzten Produktion lassen sich beide Bereiche jedoch nicht mehr sauber voneinander trennen. Wird eine sicherheitsrelevante Funktion digital beeinflusst, kann aus einem Cyberangriff eine gefährliche Situation entstehen. Deshalb sollten Unternehmen bei ihren Cybersecurity-Bewertungen besonders auf Funktionen achten, die für die Sicherheit von Menschen, Maschinen und Produktionsgütern entscheidend sind.

Betrifft der CRA vor allem die Hersteller kompletter Maschinen?

Xabier Antolin: Nein, die gesamte Lieferkette ist betroffen. Ein Komponentenhersteller muss beurteilen, welche Cybersecurity-Eigenschaften sein Produkt benötigt und welche Informationen der Maschinenbauer für die Integration braucht. Der Maschinenbauer wiederum muss die einzelnen Komponenten im Zusammenhang des Gesamtsystems bewerten. Und der Betreiber ist dafür verantwortlich, Produkte im vorgesehenen Anwendungskontext einzusetzen und die Hinweise des Herstellers zu beachten.

Das Zusammenspiel ist entscheidend. Cybersecurity lässt sich nicht an einen einzelnen Teilnehmer der Lieferkette delegieren. Anforderungen müssen weitergegeben, Einsatzbedingungen verstanden und Änderungen transparent gemacht werden.

Werden dabei alle digitalen Komponenten nach denselben Maßstäben beurteilt?

Xabier Antolin: Nein. Die Funktion und das Risikoprofil eines Produkts spielen eine wesentliche Rolle. Ein Gerät, das den Zugang zwischen unterschiedlichen Security-Zonen kontrolliert, übernimmt eine andere Schutzfunktion als ein einfacher Sensor. Entsprechend unterscheiden sich auch die Anforderungen und Bewertungsgrundlagen.

Hersteller müssen deshalb analysieren, wo ein Produkt eingesetzt wird, wie stark es vernetzt ist und welche Folgen ein erfolgreicher Angriff haben könnte. Daraus ergibt sich eine Abwägung: Einschränkungen können die Angriffsfläche reduzieren, dürfen die industrielle Nutzung aber nicht unnötig erschweren. Sicherheit und Bedienbarkeit müssen gemeinsam gedacht werden.

Können Hersteller viele Anforderungen nicht einfach über zusätzliche Hinweise in der Betriebsanleitung erfüllen?

Marc Wiederoder: In manchen Fällen wird nur die Dokumentation angepasst werden müssen. Sie allein reicht aber häufig nicht aus. Je nach Produkt können Veränderungen an Hardware, Firmware, Schnittstellen oder Update-Mechanismen erforderlich sein. Cybersecurity lässt sich nachträglich nicht oder nur mit viel Aufwand auf ein fertiges Produkt aufsetzen. Werden grundlegende Anforderungen erst kurz vor der Markteinführung betrachtet, können Änderungen sehr aufwendig werden. Deshalb ist Security-by-Design so wichtig: Bedrohungen, mögliche Angriffspfade und Schutzmaßnahmen müssen bereits in der Konzept- und Entwicklungsphase berücksichtigt werden.

Wie früh sollten OEMs damit beginnen?

Marc Wiederoder: So früh wie möglich. Je früher Cybersecurity-Anforderungen in den Entwicklungsprozess einfließen, desto leichter kann ein Produkt später an neue Erkenntnisse oder veränderte Bedrohungslagen angepasst werden. Das spart nicht nur Ressourcen. Es verhindert auch, dass grundlegende Architekturentscheidungen nachträglich korrigiert werden müssen.

Ein sicherer Entwicklungsprozess nach IEC 62443-4-1 kann hierfür einen belastbaren Rahmen schaffen. Er ergänzt bestehende Prozesse der funktionalen Sicherheit um systematische Cybersecurity-Aktivitäten – von der Anforderungsanalyse über die Implementierung bis zum Umgang mit entdeckten Schwachstellen.

In der klassischen Produktentwicklung gilt ein Produkt mit der Serienfreigabe als fertig. Gilt das unter dem CRA noch?

Marc Wiederoder: Aus Sicht der Cybersecurity ist die Markteinführung nicht das Ende der Entwicklung, sondern der Beginn einer weiteren Phase. Neue Angriffsmethoden, Schwachstellen in verwendeten Softwarekomponenten oder veränderte Nutzungsszenarien können eine frühere Risikobewertung infrage stellen. Solange sich ein Produkt in seinem aktiven Lebenszyklus befindet, müssen relevante Entwicklungen beobachtet und bewertet werden. Cybersecurity endet nicht mit der Produktfreigabe. Unternehmen brauchen deshalb Verfahren, mit denen sie ihre Produkte regelmäßig prüfen und auf neue Schwachstellen oder Anforderungen reagieren können.

Was gehört zu einem belastbaren Schwachstellenmanagement?

Xabier Antolin: Zunächst braucht es klare Meldewege. Kunden, Sicherheitsforscher oder Partner müssen wissen, an wen sie sich wenden können, wenn sie eine mögliche Schwachstelle entdecken. Intern muss geregelt sein, wie eine Meldung geprüft, bewertet und an die zuständigen Bereiche weitergeleitet wird. Eine zentrale Funktion kann dabei ein Product Security Incident Response Team, kurz PSIRT, übernehmen. Ein solches Team bündelt Informationen, koordiniert die technische Bewertung und steuert die Kommunikation. Das ist vor allem eine organisatorische Aufgabe. Ohne definierte Verantwortlichkeiten helfen auch gute technische Werkzeuge nur begrenzt.

Welche Bedeutung erhält die technische Dokumentation über den Produktlebenszyklus hinweg?

Xabier Antolin: Sie wird dynamischer. Bei neuen Software- oder Firmwareständen müssen Betreiber prüfen können, welche Änderungen vorgenommen wurden, welche Voraussetzungen gelten und ob sich der vorgesehene Anwendungskontext verändert hat. Ein Update kann eine Schwachstelle schließen, zugleich aber neue Anforderungen an Konfiguration oder Kompatibilität mit sich bringen. Deshalb darf die Dokumentation nicht als einmaliges Begleitpapier verstanden werden. Sie ist ein Bestandteil des sicheren Betriebs und muss bei neuen Versionen konsequent berücksichtigt werden.

Müssen nun auch sämtliche Bestandsanlagen neu bewertet werden?

Marc Wiederoder: Nicht automatisch. Bestehende Anlagen sind nicht allein deshalb betroffen, weil der CRA in Kraft tritt. Relevant kann eine Neubewertung jedoch werden, wenn eine wesentliche Änderung vorgenommen wird.

Unternehmen sollten daher genau betrachten, was bei einer Modernisierung geschieht. Eine neue Vernetzung, der Austausch zentraler Komponenten oder eine veränderte Softwarearchitektur können den ursprünglichen Anwendungskontext deutlich verändern. Entscheidend ist nicht allein das Alter einer Maschine, sondern die Frage, ob sich ihr Risikoprofil grundlegend verschiebt.

Viele Unternehmen haben bereits Strukturen für NIS2 aufgebaut. Ist damit auch der CRA weitgehend abgedeckt?

Xabier Antolin: NIS2-Strukturen können eine gute organisatorische Grundlage sein. Unternehmen haben dann häufig bereits Verantwortlichkeiten definiert, Meldewege eingerichtet und Informationssicherheit als Managementthema etabliert. Der CRA verlangt jedoch zusätzlich einen konsequenten Blick auf das Produkt. Allgemeine Informationssicherheit ersetzt kein Security-by-Design, keine Bewertung von Produktkomponenten und kein Schwachstellenmanagement über den Produktlebenszyklus. Beide Regelwerke berühren sich, setzen aber unterschiedliche Schwerpunkte.

Wie lässt sich verhindern, dass die zusätzliche Komplexität vollständig beim Maschinenbetreiber landet?

Marc Wiederoder: Hersteller müssen Anforderungen so übersetzen, dass sie in der industriellen Praxis verständlich und umsetzbar sind. Dazu gehören eindeutige Konfigurationsvorgaben, nachvollziehbare Einsatzgrenzen und konkrete Anwendungsbeispiele.

Das Thema bleibt komplex. Es hilft aber wenig, wenn Unternehmen ausschließlich abstrakte Normen oder regulatorische Texte weiterreichen. Veröffentlichungen, Workshops und praxisnahe Applikationen können dazu beitragen, die Folgen für konkrete Maschinen und Anlagen sichtbar zu machen. Ebenso wichtig sind Ansprechpartner, die Betreiber bei Security-Bewertungen unterstützen können.

Was sollten Maschinenbauer und produzierende Unternehmen jetzt als Erstes tun?

Xabier Antolin: Der CRA muss zunächst im Unternehmen sichtbar werden. Geschäftsführung, Entwicklung, Produktmanagement, IT, Einkauf, Service und Qualitätsmanagement brauchen ein gemeinsames Verständnis davon, was sich verändert.

Anschließend sollten Verantwortliche benannt werden, die regulatorische Entwicklungen verfolgen und interne Fragen koordinieren. Ebenso notwendig ist eine Bestandsaufnahme: Welche Produkte enthalten digitale Elemente? Welche Bibliotheken, Schnittstellen und Kommunikationsprotokolle werden verwendet? Welche Komponenten erfüllen sicherheitsrelevante Funktionen? Und wie werden Schwachstellen heute erkannt, bewertet und kommuniziert?

Marc Wiederoder: Unternehmen sollten außerdem frühzeitig mit Lieferanten und Kunden sprechen. Welche Informationen werden künftig benötigt? Welche Update- und Supportzeiträume werden zugesagt? Wie lassen sich Schwachstellenmeldungen entlang der Lieferkette weitergeben? Solche Prozesse entstehen nicht innerhalb weniger Wochen. Wer erst beginnt, wenn Kunden konkrete Nachweise verlangen, gerät schnell unter erheblichen Zeitdruck.

Welche Maßnahmen hat Euchner nach der Vorbereitung auf diese Anforderungen umgesetzt? Wie profitiert der Kunde?

Marc Wiederoder: Wir haben frühzeitig einen internen Prozess für das Cybersecurity-Risikomanagement aufgebaut und einen Secure Development Lifecycle etabliert. Dazu gehört ein zertifizierter Entwicklungsprozess nach IEC 62443-4-1.

Darüber hinaus wurde ein PSIRT eingerichtet. Das Produktportfolio wird kontinuierlich auf mögliche Schwachstellen und CRA-relevante Anforderungen untersucht. Ein automatisierter Prozess unterstützt dabei, verwendete Komponenten und neu bekannt gewordene Schwachstellen systematisch zu beobachten.

Xabier Antolin: Ebenso wichtig ist der Austausch über Unternehmensgrenzen hinweg. Die Beteiligung an Sicherheitsinitiativen, CERT-Strukturen und Schwachstellendatenbanken hilft dabei, neue Erkenntnisse frühzeitig zu berücksichtigen. Kein Hersteller kann industrielle Cybersecurity isoliert lösen. Entscheidend ist, dass Informationen verlässlich ausgetauscht und in konkrete Maßnahmen übersetzt werden. Der CRA macht diese Zusammenarbeit verbindlicher – und zwingt Unternehmen, Sicherheit nicht nur für den Zeitpunkt der Auslieferung zu versprechen, sondern über Jahre hinweg zu organisieren.
Künftig bietet Euchner auch Beratungsleistungen zu Cybersecurity-Anforderungen in der Industrie an. Dazu gehören Bedrohungs- und Risikoanalysen, die Identifikation von Security-Schwachstellen sowie die Unterstützung bei Security-by-Design, Konformitätsfragen, Schwachstellenmanagement und Security-Updates – mit dem Ziel, Anforderungen frühzeitig einzuordnen und notwendige Maßnahmen planbar in Entwicklungs- und Betriebsprozesse zu integrieren.

Dieser Beitrag wird präsentiert von:

https://www.euchner.com/de-de/