Der European Cyber Resilience Act als Expedition – Ein Gespräch mit Michael Brunner, CERTAINITY

Business Circle: Sehr geehrter Herr Brunner, Sie leiten als Partner seit Juni 2022 bei CERTAINITY den Bereich Security Engineering. Können Sie kurz darstellen, wie Sie Ihr Weg dorthin geführt hat und warum Cybersicherheit zu Ihrer Berufung wurde?

Michael Brunner: Ursprünglich habe ich mich dem Bereich Security aus der Softwareentwicklung heraus genähert. Als Softwareentwickler in unterschiedlichen Branchen und insbesondere für Finanzdienstleister habe ich den stark an aktuellen Bedrohungslagen ausgerichteten als auch den Compliance-getriebenen Umgang mit Sicherheitsanforderungen aus erster Hand miterlebt. Das war dann schließlich auch der Grund mich mit dem Thema Informationssicherheits- und Risikomanagmentsystemen in meiner Dissertation intensiv zu beschäftigen. Bei CERTAINITY leite ich unsere Practice für Security Engineering und kann meinen beiden Leidenschaften - der für Softwareentwicklung und der für Security Management - nachgehen und unsere Kunden sowohl bei der Konzeption als auch der Etablierung von Sicherheitspraktiken unterstützen.

BC: Etwas, das bei der Ankündigung Ihres Vortrages gleich auffällt: warum haben Sie die Analogie aus dem Bergsport gewählt?

Brunner: Auch wenn ich das gerne für mich reklamieren würde - die Idee kam von Christoph Ranalter (FELDER KG), den ich nun schon mehrere Jahre im Bereich sichere Software- und Produktentwicklung berate. Aber ich denke, dass sich jedem die Analogie sehr schnell erschließt. Wir erleben es oft, dass sich insbesondere neue regulatorische Anforderungen für viele Unternehmen zunächst wie ein hohes, schroffes Bergmassiv darstellen. Da gilt es mit entsprechender Planung die richtigen Routen zu wählen und auch die erforderliche Ausrüstung mitzubringen. Und ähnlich auch wie beim Bergsport, ist es oft unerlässlich auf externe Expertise zurückzugreifen: Den Bergführer im alpinen Raum - den Berater bei der Umsetzung des European Cyber Resilience Acts.

BC: Könnten Sie uns einen Überblick über die wichtigsten Anforderungen des CRA geben, insbesondere was die ersten Schritte in der Umsetzungspraxis angeht?

Brunner: Zunächst einmal ist es mir wichtig darauf hinzuweisen, dass der CRA allgemein gültige Mindeststandards für die Sicherheit vernetzter Produkte in der EU vorgibt: Das betrifft damit sowohl Hardware – vom bluetooth-fähigen Kinderspielzeug bis hin zu industriellen Firewalls – inkl. deren Softwarekomponenten als auch reine Software-Produkte. Damit werden also beispielsweise auch mobile Apps oder klassische Desktopapplikationen adressiert. Die Anforderungen, die der CRA vorgibt, betreffen zum einen die Produkte selbst. Dies sind zwingend zu berücksichtigende essenzielle Sicherheitsanforderungen, die betroffene Produkte erfüllen müssen. Weiters werden eine Reihe von Vorgaben zum Entwicklungsprozess selbst gegeben – allen Voran die Forderung ein sogenanntes Cyber Risk Assessment durchzuführen und die Ergebnisse im Rahmen des gesamten Entwicklungsprozesses zu berücksichtigen und auch zu aktualisieren. Darunter fällt natürlich auch die Berücksichtigung der Cyberrisken der Software Supply Chain. Für die Zeit nach der Produktentwicklung werden Hersteller verpflichtet, die Fähigkeiten und Kapazitäten für einen effizienten Umgang mit Schwachstellen in Ihren Produkten zu gewährleisten. Und all diese Aspekte sind natürlich entsprechend zu dokumentieren, um den Konformitätsvorgaben zu entsprechen und diese auch gegenüber Marktüberwachungsbehörden nachweisen zu können.

Abhängig vom aktuellen Reifegrad der Produkt- und Software-Entwicklungsprozesse sind für damit eine recht breite Palette an Umsetzungmaßnahmen in der Praxis zu berücksichtigen. Daher sollte der erste Schritt immer darin bestehen, zunächst zu prüfen welche eigenen Produkte vom CRA betroffen sind und dann die eigene CRA-Fitness zu bewerten.

BC: Welche Kennzahlen und Messgrößen kann ein Unternehmen verwenden, um seine eigene CRA-Fitness zu bewerten?

Brunner: Bei der Bewertung der eigenen CRA-Fitness gilt es nach meiner Erfahrung zunächst darum, den aktuellen Umsetzungsgrad der einzelnen Anforderungen sowohl auf Ebene der Produkte als auch der etablierten Prozesse zu prüfen. Die Anforderungen im CRA sind recht kurz und auch tendenziell etwas abstrakt gehalten, lassen sich aber qualitativ entlang eines CMMI-basierten Reifegradmodells sehr effizient bestimmen. Auf diese sehr spannende Fragestellung werden wir auch in unserem Stream eingehen und freuen uns auf einen offenen Austausch mit den Teilnehmer:innen. Heute möchte ich dazu ungern mehr „spoilern“.

BC: Auch bei einer Bergtour braucht man Teilziele und Basiscamps. Was wären typische Milestones auf der Roadmap zu einer effizienten CRA-Compliance?

Brunner: Erster wichtiger Schritt, wäre wie schon erläutert, zu klären, welche der eigenen Produkte betroffen sind. Die Anzahl betroffener Produkte und insbesondere die Heterogenität des eigenen Produktprotfolios haben mitunter multiplikative Effekte für die Umsetzungsaufwände und müssen von Beginn an in der Ressourcenplanung berücksichtigt werden. Als zweiter Meilenstein steht die Analyse des aktuellen Umsetzungsgrades – der eigenen CRA-Fitness – an und damit auch die Detailplanung erforderlicher Umsetzungsmaßnahmen. In weiterer Folge gilt es dann Policies und Vorgaben zu etablieren, erforderliche Methoden und Tools einzuführen und gegebenenfalls auch neue Prozesse oder Prozessschritte im Unternehmen zu etablieren. Welche konkreten Schritte zu setzen sind, ist meist sehr stark vom Reifegrad der einzelnen Unternehmen und Entwicklungsteams abhängig. Sehr häufig sehen wir dass beispielsweise das vom CRA eingeforderte Cyber Risk Assessment nicht ausreichend im Entwicklungsprozess Berücksichtigung findet. Weitere typische „Baustellen" sind der Dokumentationsreifegrad (sowohl was die Prozesse als auch die Security Aspekte der Produkte betrifft), die Sicherheit der Software Supply Chain und letztendlich auch die Fähigkeiten zur effizienten Behandlung von Security-Schwachstellen. Abschließend ist natürlich zu beachten, dass nach der Herstellung der CRA-Compliance diese auch aufrechtzuerhalten ist. Der CRA fordert unter anderem eine effizienten Behandlung neu entdeckter Security-Schwachstellen von Produkten über mehrere Jahre hinweg ein - inkl. der kostenfreien Bereitstellung von Security Updates.

Größte Herausforderung wird voraussichtlich die Rekrutierung sein

BC: Welche Ratschläge hätten Sie für einen Security Manager in einem Unternehmen, der jetzt einen Projektplan für ein CRA-Projekt aufsetzen soll? Welche Vorbereitungen soll man angehen, was sind typische Fehler, die man vermeiden kann?

Brunner: Zu Beginn gilt es, die Unterstützung des Top-Managements sicherzustellen. Sofern ein Unternehmen die eigenen Produkte nicht bereits jetzt schon für hochregulierte Bereiche (kritische Infrastruktur, Automotive, medical Devices, …) entwickelt und damit schon restriktive Sicherheitsvorgaben umgesetzt hat, ist davon auszugehen, dass sowohl Anpassungen am Entwicklungsprozess selbst als auch an Support-Prozessen erforderlich sein werden – und das ist mit einem entsprechenden Aufwänden und Kosten verbunden. Der CRA wird im September 2024 in Kraft gesetzt und sieht aus meiner Sicht recht unternehmerfreundliche Umsetzungsfristen bis September 2027 vor. Allerdings wird die Verpflichtung zur Meldung aktiv ausgenutzter Schwachstellen und schwerer Sicherheitsvorfälle an die ENISA und das CSIRT des jeweiligen EU-Mitgliedsstaats bereits am 1. Juni 2026 in Kraft treten. Für Unternehmen bedeutet das konkret, dass ab diesem Zeitpunkt die geforderten Berichtspflichten umzusetzen sind. Und auch wenn das noch in recht weiter Ferne erscheinen mag, sollte diese Anforderung nicht unterschätzt werden. Schließlich werden Produkthersteller damit de facto verpflichtet ein Product Security Incident Response Team (PSIRT) aufzubauen. Größte Herausforderung dabei wird voraussichtlich die Rekrutierung von geeigneten Mitarbeiter:innen sein – und das ist üblicherweise mit längeren Vorlaufzeiten verbunden. Meine Empfehlung an Unternehmen ist daher, sich bereits jetzt mit dem CRA zu befassen und damit auch ausreichend Zeit für die Umsetzung der künftigen regulatorischen Anforderungen zu schaffen. Der häufigsten „Fehler“ wenn man so will, den wir in der Praxis sehen, ist die allgemein oft recht späte Beschäftigung mit regulatorischen Anforderungen. Insbesondere der CRA greift in unterschiedliche Aspekte von den Entwicklungs- und Supportprozessen ein – und hier benötigen ggf. erforderliche Anpassungen oder Erweiterungen mit unter längere Umsetzungszeiten.

BC: Abschließend: Sie werden zum ersten Mal bei uns vortragen - Glückwunsch dazu! Warum ist es für Sie wichtig und sinnvoll, sich im Bereich Datenschutz und Datensicherheit zu vernetzen?

Brunner: Konferenzen wie die PriSec schaffen den so dringend erforderlichen Raum, sich Abseits des täglichen Arbeitsumfeldes konzentriert zu aktuellen Herausforderungen und innovativen Lösungsansätzen auszutauschen. Ich freue mich auf zwei spannende Tage im Kreise Gleichgesinnter!

BC: Sehr geehrter Herr Brunner, vielen Dank für dieses Gespräch und die wertvollen Einblicke! Wir freuen uns schon auf Ihren Auftritt bei der PriSec!

Michael Brunner, PhD leitet als Partner bei CERTAINITY seit Juni 2022 den Bereich Security Engineering. Er ist seit über 20 Jahren als Security Architekt, Unternehmensberater und Software-Engineer tätig. Im Rahmen der PriSec ist er Gastgeber einen Workshops zum Thema „Expedition European Cyber Resilience Act“.

‍