Ich kann den Optimismus zum Cyber Resilience Act nicht uneingeschränkt teilen und sehe jedenfalls keine klare win win Situation.
Software wird nie unabhängig entwickelt, sondern ist eigentlich immer von Bestandteilen (Bibliotheken) Dritter abhängig. Man konzentriert sich auf seine Geschäftslogik und erfindet eben nicht das Rad neu, wenn es bereits etablierte Bibliotheken gibt.
Bzgl. des CRA ist das plötzlich ein rechtliches Risiko, denn oft hat man Sicherheitslücken gar nicht selbst verbrochen, sondern durch das Nutzen einer Bibliothek geerbt.
Ich fürchte, dass sich Entwickler und Kunden daher zukünftig, aus Gründen der rechtlichen Absicherung (und nicht der Sicherheit), für kommerzielle Programme anstelle von Open Source entscheiden könnten. Ich sehe hier noch viele offene Fragen bei der Haftung und umso mehr Bewertungsspielraum. Wenn Entwickler aufgrund der Unsicherheit zusätzlich Versicherungen abschließen, gewinnt am Ende nicht die Sicherheit, sondern die Versicherung.
Ich teile nicht alle Einschätzungen, fände aber auch eine Einordnung wie der CRA mit Open Source umgeht gut - würde für mich auch als ausführliches thema für Cyber Nation passen
Wir beschäftigen uns gerade mit diesem Thema in der Firma, da grundsätzlich alle Geräte, die eine Firmware enthalten, davon betroffen sind.
Der CRA soll dafür sorgen, dass digitale Produkte in der EU von Anfang an und über den Lebenszyklus hinweg sicher sind.
Dazu gehört z.B. eine SBOM (Software Bill of Materials), in der alle genutzten Bestandteile der Firmware aufgelistet und wiederholt geprüft werden. Z.B. Bibliotheken, die der Entwickler genutzt hat, ob diese Updatefähig sind etc.
Aber auch eine Risikobewertung, welche möglichen Gefahren von einem Gerät ausgehen und wie diese abgesichert sind.
Ziel ist ein höherer Fokus auf derartigen potentiellen Gefahren.
Denn: Softwaresicherheit bezahlt der Endkunde nicht.
In unserem Fall bedeutet es: Wir erstellen die Risikobeurteilung und SBOM selbst und treffen Maßnahmen bei erkannten Gefahren. Stellt sich z.B. während des Lebenszyklus heraus, dass eine vom Entwickler verwendete Bibliothek eine Sicherheitslücke enthält, können wir Maßnahmen einleiten und ein Update zur Verfügung stellen.
Es geht dabei nicht darum, keine etablierten Bibliotheken zu verwenden. Ich muss dies aber dokumentieren und eine Möglichkeit schaffen, bei auftretenden Sicherheitslücken für Abhilfe zu sorgen.
Ein wesentliches Problem sind dabei die Kosten die auftreten, um ein Produkt für den Lebenszyklus sicher zu m achten uns zu halten.
Wie schon geschrieben fängt das damit an, dass man eine saubere und vollständige SBOM (Software Bill of Material) erstellt.
Während der Produktentwicklung gehören dann je nach Produkt auch Penetration Test dazu, bei denen man das Gerät bzw. die Firmware auf Schwachstellen prüft oder prüfen lässt.
Bei „Funkanlagen“ und das ist alles was funkt z.B. BT, WLAN, Mobilfunk, … greift dann in der EU noch die RED (Radio Equipment Direktive) welche auch in Artikel 3.3d,e,f.
Danach folgt dass man in regelmäßigen Abständen diese SBOM mit einem Vulnerability Management System auf bekannte Sicherheitslücken CVEs prüft.
Die gefundenen Schwachstellen müssen dann im Produktkontext auf ihre Kriminalität bewertet werden und gegebenenfalls behoben und per SW Update ausgerollt werden.
All das macht vor allem eine Preiskalkulation unmöglich in der mit dem Anschaffungspreis die Maintainence inklusive Security über die Produktlebenszeit festgelegt werden soll.
Das würde dazu führen, dass man in Zukunft mehr Mietmodelle sieht oder zu seinem Router, Smartphone, IoT device, … einen Securitywartungsvertrag abschließen muss mit laufenden Kosten.
Gerade für Startups und kleine Unternehmen gelten viele Vereinfachungen um genau das zu verhindern. Größere Unternehmen haben meist sowieso schon die Strukturen und Prozesse die nötig sind. Die Mehrkosten pro Stück/Lizenz dürften sich da sehr im Rahmen halten.
Ein Securitywartungsvertrag wird ja komplett obsolet durch den CRA. Da der Hersteller genau dadurch gesetzlich verpflichtet ist. D.h. er darf sein Produkt garnicht verkaufen ohne die Leistungen so eines Vertrages. Aber dann macht es ja keinen Sinn dafür Geld zu verlangen.
Ich beschäftige mich seit einiger Zeit mit dem CRA und teile die Sorge nicht.
Auch glaube ich, missverstehst du den CRA an der ein oder anderen Stelle.
Der CRA verpflichtet, keine Software mit bekannten Schwachstellen auszuliefern. Das lässt sich leicht nachprüfen, auch für open-source Bibliotheken. CVE’s gelten hier als ausreichend. Wobei auch viele Ausnahmen möglich sind, die man dann aber begründen muss. Das gilt für proprietäre Software, wie für open-source.
Und dann ist es so wie von Tikka beschrieben. Man ist normalerweise verplichtet 5 Jahre Softwareupdates (also mindestens Sicherheitspatches zu liefern). Die werden in genügen großen open-source Projekten meißt deutlich schneller und nachhaltiger behoben als bei vielen Branchenriesen (ich schau dich an Microsoft). Die Patches müssen dann einfach ins eigene Produkt integriert werden und an die eigenen Kunden ausgeliefert.
Das erklärt jedoch noch nicht wie ein Unternehmen die Kosten, welche definitiv durch die Anforderung Sicherheitsupdates über den Productlifecycle zu liefern, entstehen berechnen sollen.
Bitte verstehe mich nicht falsch, ich bin zu 100% bei dir, dass es notwendig ist die Sicherheitslücken zu Monitoren und ggf. zu beheben damit das Produkt weiter sicher betrieben werden kann. Es ist jedoch schwer zu kalkulieren was das kostet. Niemand ist in der Lage heute zu sagen wie viele Vulnerabilities z.B. im Linux Kernel x.y in den nächsten 10, 20 oder 30 Jahren gefunden werden (Anthropic lässt grüßen) und wie aufwendig das Patchen sein wird, bzw. Ob es wirklich möglich ist die Schwachstelle zu patchen.
Ein Beispiel aus der Realität. In jedem modernen Fahrzeug sind Mobilfunkmodems für eCall und Telematik verbaut. Diese Modems sind im Prinzip oft ganz ähnlich wie Smartphones. Es läuft ein stark vom Chipsatzhersteller z.B. Qualcomm oder Mediatek veränderter Linnux Kernel. Die Kette der Verantwortung reicht vom Chipsatzhersteller über den Modemhersteller über den Automobilzulieferer der die Telematik oder eCallbox herstellt bis zum OEM der das Fahrzeug verkauft.
Heute ist es so, dass Qualcomm dir den nackten Arsch zeigt wenn es um Sicherheitsupdates des Kernels geht der teilweise steinalt ist. Geschweige, dass man für Geld und gute Worte ein Kernelupdate bekommen könnte. Hier sehe ich, dass der CRA eine positive Wirkung haben könnte, jedoch auch die Kosten stark treiben wird und zu früherer Obsolenz führt, da es nicht nur um SW sondern auch um HW gehen kann. Nicht jeder Bug wird durch SW behebbar sein bzw. Können Systemgrenzen erreicht werden an denen z.B. nicht mehr genügen Speicher auf dem embedded Gerät vorhanden ist um neue SW Einzuspielen.
Gerade bei Fahrzeugen und Maschinen werden Produktlebenszyklen von 20 bis 30 Jahren erwartet. Es gibt aktuell noch keinen Fahrzeughersteller, der z.B. das ersetzen der entsprechenden ECU durch eine aktualisierte HW. Ein Beispiel, dass bald Realität wird sind eCall Systeme die noch auf 2G Modems setzten die werden bald funktionsunfähig wenn die Netze abgeschaltet werden… damit kommt das Fahrzeug nicht mehr durch den TÜV wenn das eCall System Homologationsrelevant war (ab 31.3.2018 homologierte PKWs).
Ich weiß ich bin jetzt tief in ein spezielles Gebiet eingetaucht aber ähnlich kannst du das auf viele Embedded und IoT Geräte übertragen.
Ich verstehe deine Bedenken, aber v.a. bei B2B Verträgen existieren ja bereits Software Wartungsverträge, die genau das abdecken.
Schwierig wird es nur, wenn die Bahn bspw ihren Navigator neu entwickeln lässt und im rechtlichen Sinne selbst Hersteller wird, es aber bisher nicht ausreichend geregelt ist, wie die Verantwortlichkeiten an den tatsächlichen Hersteller abgetreten werden können (bspw. Meldung von Sicherheitsverstößen innerhalb von 24 Stunden).
Zunächst vielen Dank für die kenntnisreiche und detaillierte Darstellung.
Mir käme es naheliegend vor, dass jeder Gerät, soweit nicht seine Hauptfunktion dem entgegensteht (z.B. Internetrouter), auch offline funktionieren muss (ggf mit gewissen Einschränkungen, insbesondere im Komfort und Umfang der Bedienmöglichkeiten) und vom Anwender konfiguriert werden kann (sei es durch einen Schalter oder eine Menüoption usw.), offline zu arbeiten.
Das wäre eine robuste Rückfallebene, sei es dass der Hersteller nicht mehr existiert, der Support ausgelaufen ist, ich ihm aufgrund der politischen Lage an seinem Firmensitz nicht mehr vertrauen will usw., dass ich weiterhin ein funktionierendes Produkt in der Hand habe.
Bei den Autos und der Notruffunktion: man hat ja auch durch Setzung des Stichtags 2018 akzeptiert, dass Autos weiterhin in Betrieb sein dürfen, die nicht online sind und diese Funktion nicht haben. Ich fände es nur folgerichtig, dass wenn sich das technische Umfeld so ändert, dass die damals korrekt eingebaute Funktion unwirksam wird (weil selbst bei Einführung von 4G m.W. noch nicht klar war, ob als Legacy-System zusätzlich 2G oder 3G länger weiterhin betrieben werden würde), und sich dadurch keine schlechtere Situation ergibt als für bestimmte andere Fahrzeuge, die wir auf den Straßen weiterhin erlauben, dies kein Kriterium sein darf, das Auto aus dem Verkehr zu ziehen. (Mir ist schon klar, dass man sich erhofft hat, diese Ausnahmen altern ganz natürlich aus dem Bestand raus und irgendwann ist alles supi, ja mei. Aber wenn zwei zusammenstoßen, dann müssten ja beide Legacy sein, dass kein Notruf abgesetzt wird, und wenn einer gegen den Baum fährt, der hat ja gewusst dass kein Notruf erfolgt.)
Ich sehe das als ganz klassisches BWL Problem und auch als unternehmerisches Risiko. Man weiß ja auch nie, wie viele Produkte man am Ende verkauft und wie viel Budget man dementsprechend für die Entwicklung hat. Oder ob ein neues Feature mehr Geld kostet als es „einspielt“. Das hat wenig mit der Sicherheit selbst zu tun.
Bisher war es ein Wettbewerbsnachteil mehr Geld in Sicherheit zu investieren, da man das Produkt teurer gemacht hat. Mit dem Nebeneffekt, dass man das Risiko verallgemeinert hat. Darum ja das Gesetz. Klar werden sich Teile der Kosten im Preis widerspiegeln. Aber das ist gewollt. Die Schäden für Unternehmen und Gesellschaft durch IT-Sichereitsvorfälle sind ja auch enorm hoch.
5 Jahre wird vom CRA verlangt. Alles darüber hinaus ist freiwillig und kann gerne mit einem „erweiterem Security-Wartungsvertrag“ abgedeckt werden. 5 Jahre ist ein einigermaßen überschauber Zeitraum würde ich sagen.
Ich glaube aber, der Knackpunkt ist, dass man nicht gezwungen ist den Kernel selbst zu patchen. Man ist aber gezwungen die Schwachstelle an den Hersteller (oder im Falle von OS, dem Maintainer) mitzuteilen, sowie .
Danach geht es wahrscheinlich in die Einzelfallbewertung. Kann man mit etwas Code die Kernel Schwachstelle umgehen oder den Teil des Kernels deaktivieren? Falls eine Umgehung (mitigation) der Schwachstelle aber nicht möglich ist, könnte man wohl argumentiren, dass es ausreicht die Nutzer zu warnen (je nach Schweregrad) und es bei den Kernel Entwicklern zu eskalieren. Notfalls müsste man wohl extern wen beauftragen um es zu fixen. Aber sich „ohne Verzögerung darum zu kümmern“ interpretiere ich nicht als „alles stehen und liegen lassen bis es behoben ist, koste es was es wollte“. Ich bin aber kein Jurist. Aber als jemand aus der IT-Sicherheit, würde ich jedem raten die Finger von sowas wie Kernels zu lassen. Wenn man nicht Teil des Kernel Teams ist, macht man zu 100% mehr kaputt als man repariert.
Autos („motorized vehicles“) sind nicht Scope des CRA. Und für Produktionsmaschinen werden Hersteller sowieso spezielle Verträge brauchen. Für Support, Wartung und ggf. Gewährleistung. Dafür ist der CRA nicht gedacht.
Naja, alles über 5 Jahre Laufzeit wird einfach nicht abgedeckt vom CRA. Der CRA definiert laut Eigenbeschreibung „horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen“. Es wird also eine „Bottom Line“ von IT-Sicherheit definiert.
Langlebige Produkte werden damit wohl kein Problem haben. Ich kann mir eher vorstellen, dass so billig Schrott damit Schwierigkeiten bekommt. Da wird Security einfach komplett ausenvor gelassen und Updates kann man auch vergessen. Die bekommen dann aber kein CE Label mehr. Bzw setzen sich sehr hohen Strafen aus, wenn sie fälschlich behaupten sie wären konform.