Maschinensicherheit im Kontext von KI und Security

GIT SICHERHEIT: Herr Niehaus, der CRA ist neben NIS 2 eine der wesentlichen Regularien, um die Cybersicherheit innerhalb der EU zu erhöhen. Worum genau handelt es sich bei dieser Verordnung und warum wurde sie erlassen? 

Michael Niehaus: Jeder dürfte mindestens ein Unternehmen kennen, das Ziel von Cyberangriffen geworden ist und erhebliche Probleme hatte, den normalen Geschäftsbetrieb wieder aufzunehmen. Wenn es nicht sogar in seiner Existenz bedroht ist. Betroffen von Angriffen sind häufig die Office-Software, aber auch die Anlagen und Maschinen in der Produktion. Dies liegt an der immer stärkeren Vernetzung von Produktionsanlagen mit der Office-Software in Unternehmen.
Die  SPS einer Produktionsanlage ist beispielsweise an das LAN des Unternehmens angeschlossen, um schnell Störungsmeldungen zu erhalten. Die SPS selbst basiert in Teilen auf bestehender, weitverbreiteter Software, zum Beispiel ein Standardbetriebssystem, um die Vernetzung so einfach und flexibel wie möglich zu machen. Dadurch wird die SPS „attraktiv“ für Angriffe. Schließlich ist ein Standardbetriebssystem weit verbreitet, was die Chance erhöht, dass Angriffspunkte gefunden werden. Ist der Befall in der Produktion erst einmal vorhanden, verursacht die Beseitigung einen erheblichen zusätzlichen Aufwand. Natürlich sind nicht nur Unternehmen, sondern auch Privatpersonen betroffen. Sei es das Babyphone mit Kamera oder die Hausautomatisierung, die aus dem Internet erreichbar ist.
Diese Problematik greift der CRA auf. Er betont in Erwägungsgrund 1, dass Cyberangriffe ein Thema von öffentlichem Interesse sind. Denn sie wirken sich nicht nur auf die Wirtschaft, sondern auch auf die Demokratie sowie die Sicherheit und Gesundheit der Verbraucher kritisch aus.       

Wen genau betrifft der CRA und wie sieht die Zeitschiene aus?

Michael Niehaus: Das ist in Artikel 2 Absatz 1 des CRA beschrieben. Betroffen sind Hersteller von Produkten mit digitalen Elementen, also Hardware oder Software inklusive Datenfernverarbeitungslösungen, sofern die Datenfernverarbeitung eine Funktion des Produktes ist. Weiterhin muss der „bestimmungsgemäße Zweck“ oder die „vernünftigerweise vorhersehbare Verwendung“ des Produktes eine direkte oder indirekte logische oder physische Datenverbindung mit einem Gerät oder Netz einschließen. Also vereinfacht gesagt: wenn das Produkt mit einem anderen Gerät oder Netz kommunizieren kann bzw. sinnvollerweise könnte. Die Produkte müssen getrennt in Verkehr gebracht werden, also einem Abnehmer einzeln zur Verfügung gestellt werden.
Die Zeitschiene des CRA umfasst für die Hersteller zwei Meilensteine: Ab dem 11. Dezember 2027 müssen sie die Anforderungen des CRA für die betroffenen Produkte erfüllen. Schon früher allerdings, ab dem 11. September 2026, gelten für die Hersteller die Meldepflichten für aktiv ausgenutzte Schwachstellen.        

Direkt im Anschluss daran stellt sich natürlich die Frage, was der CRA verlangt – insbesondere mit Blick auf den Maschinenbau?

Michael Niehaus: Eine Maschine mit einer Schnittstelle dürfte in den Anwendungsbereich des CRA fallen. Sie besteht in der Regel aus selbst entwickelten und zugekauften Komponenten, wovon einige selbst unter den CRA fallen, zum Beispiel die SPS. Ebenso wie der Hersteller der Komponente muss der Maschinenbauer die grundlegenden Cybersecurity-Anforderungen aus Anhang I des CRA erfüllen. Er muss die Cybersicherheitsrisiken bewerten und Maßnahmen in der Maschine umsetzen und dies durch seine Konformitätserklärung bestätigen. Der Umfang der Maßnahmen muss sorgfältig abgewogen werden, denn ein Zuviel kann die Bedienbarkeit der Maschine nachteilig beeinflussen, ein Zuwenig die Angriffsmöglichkeiten inakzeptabel erhöhen.
Weiterhin muss der Hersteller einen Unterstützungszeitraum angeben, in dem er Schwachstellen der Maschine wirksam und im Einklang mit dem CRA behandelt. Dazu muss er erkennen, ob es Schwachstellen gibt. Er muss für seine Eigenentwicklungen, aber auch für zugekaufte Komponenten eine Schwachstellenüberwachung installieren. Details dazu finden sich ebenfalls im Anhang I des CRA.

Der CRA steht natürlich nicht allein. Obendrein gibt es auch die neue EU-Maschinenverordnung, die die bestehende Maschinenrichtlinie ab dem 20. Januar 2027 ablösen wird. Auch diese nimmt Bezug auf die Cybersicherheit von Maschinen und Anlagen. Was kommt auf die Anwender der Maschinenverordnung zu?

Michael Niehaus: Einer der Gründe für die Überarbeitung der Maschinenrichtlinie zur Maschinenverordnung waren neue Technologien und damit neue Gefährdungen. Gemeint waren unter anderem KI und natürlich Cybersicherheit. Da die Maschinenverordnung vor dem CRA veröffentlicht wurde, konnte sie keinen Bezug zum CRA herstellen. Der CRA hingegen erwähnt im Erwägungsgrund (53) die Maschinenverordnung und deren Anforderungen im Anhang III Abschnitte 1.1.9 und 1.2.1. Dabei wird deutlich gemacht, dass bei Erfüllung des CRA diese Anforderungen erfüllt sein könnten.
Der Abschnitt 1.1.9 in Anhang III der Maschinenverordnung verlangt von den Herstellern unter der Überschrift Korrumpierung einen Schutz gegen die Verfälschung von Informationen. Abschnitt 1.2.1. definiert die zu protokollierenden Daten und Anforderungen zum Einsatz von sich teilweise selbst entwickelnden Systemen, sprich KI. Informationen zur Umsetzung dieser Anforderungen sind im neuen Guide zur Maschinenverordnung beziehungsweise den in der Entwicklung befindlichen harmonisierten Normen zu finden – und auch im folgenden Artikel dieser GIT-Serie.  

Besondere Bedeutung kommt ja auch dem Thema „Sicherheits-Update“ zu. Wie lange müssen Cybersecurity-Updates bereitgestellt werden und wie sollten diese organisiert werden?

Michael Niehaus: Leider muss man sagen: Es kommt auf die Maschine an. Artikel 13 Abschnitt 8 des CRA spricht davon, dass der Unterstützungszeitraum, das heißt die Zeit, in der Schwachstellen vom Hersteller behandelt werden müssen, die voraussichtliche Nutzung widerspiegelt. Daraus ergeben sich zahlreiche Fragen. Industriemaschinen werden in der Regel eine längere Nutzungsdauer als die erwähnten fünf Jahre haben. Spannend wird es, wenn der Hersteller einen Unterstützungszeitraum angibt, die Komponenten, die er zukauft, aber kürzere Unterstützungszeiträume angeben.
Die Organisation von Updates kann leider ebenfalls nicht pauschal beantwortet werden. Bei Maschinen wird man vermutlich keine automatischen Updates machen wollen, sondern diese nur gesteuert einspielen, zum Beispiel während eines Wartungsintervalls. Das bedeutet aber auch, das Betreiber in der Zwischenzeit eine Cybersecurity-Analyse durchführen und andere Maßnahmen ergreifen müssen.

Wie behalten Unternehmen den Überblick über die Vielzahl an Informationen zu Schwachstellen?

Michael Niehaus: Das Wichtigste dürfte das Verständnis der Cybersecurity-Architektur der Maschine sein, sodass schnell bewertet werden kann, welche Schwachstellen für die Maschine relevant sind und welche nicht. Die Identifikation von Schwachstellen aller zugekauften und eingesetzten Komponenten wird nur automatisiert funktionieren. Es gibt schon erste Ansätze, die Schwachstellen in einem einheitlichen maschinenlesbaren Format zu kommunizieren. Diese Automatismen können hoffentlich einen Großteil der Arbeit durchführen und nicht relevante Schwachstellen wegfiltern. Es wird am Ende dennoch darauf hinauslaufen, dass der Maschinenhersteller die „verbleibenden“ Schwachstellen bewertet und über die Maßnahmen entscheidet.

Welche Herausforderungen sehen Sie bei der Umsetzung des CRA in der Praxis?

Michael Niehaus: Sicherlich ist es erst einmal eine Einstiegshürde, sich mit den Anforderungen des CRA auseinander zu setzen und sie auf die Maschine abzubilden. Hierbei ist der Umfang der Maßnahmen ein Balanceakt zwischen Kosten, Bedienbarkeit und Einhaltung der gesetzlichen Vorgaben.
Wenn klar ist, welche Maßnahmen zu ergreifen sind, müssen diese in der Maschine umgesetzt werden. Dies kann konzeptionelle Herausforderungen bedeuten, wenn Updates nie vorgesehen waren oder Komponenten nicht in einer CRA-konformen Form vorliegen. Die Beobachtung von Schwachstellen über den Unterstützungszeitraum, deren Bewertung und – falls erforderlich –  das Management von Updates dürfte ebenfalls herausfordernd werden.