Thought Leadership
Mit der TR-03183 will das Bundesamt für Sicherheit in der Informationstechnik Herstellern den Einstieg in den Cyber Resilience Act (CRA) erleichtern. Verbindlich ist das Dokument nicht, helfen soll es trotzdem.
Der CRA bringt für Hersteller vernetzter Produkte einiges an neuen Hausaufgaben mit sich: Sicherheitsanforderungen über den gesamten Produktlebenszyklus, Schwachstellenmanagement, Meldepflichten und die lästige, aber wichtige Dokumentation aller verbauten Softwarebestandteile. Bis die Verordnung am 11. Dezember 2027 komplett greift, ist zwar noch etwas Zeit, wer aber erst kurz vor Toresschluss anfängt, sich damit zu beschäftigen, wird es vermutlich schwer haben. Das BSI hat deshalb mit der Technischen Richtlinie TR-03183 eine Art Starthilfe veröffentlicht, die zeigen soll, wo man am besten ansetzt.
Wichtig dabei: Die TR-03183 ist keine verpflichtende Norm und lässt sich auch nicht nutzen, um gegenüber dem CRA Konformität zu behaupten. Sie versteht sich eher als Sammlung von Infos, praktisch als Einstiegshilfe, besonders gedacht für Hersteller, die bislang noch keine ausgereiften IT-Sicherheitsprozesse in Entwicklung und Schwachstellenbehandlung haben. Mit der Zeit soll das Dokument dann Stück für Stück durch die entsprechenden harmonisierten europäischen Normen abgelöst werden, sobald die fertig sind.
Vier Teile für unterschiedliche Aspekte
Die Richtlinie gliedert sich in mehrere Teile. Teil 1, „General Requirements“, bündelt die allgemeinen Anforderungen an Hersteller und Produkte, angelehnt an die Artikel und Anhänge des CRA. Aktuell liegt er in Version 1.0.0 vor.
Teil 2 dreht sich um die Software Bill of Materials (SBOM), also die Stückliste aller Softwarekomponenten in einem Produkt. In Version 2.1.0 hat das BSI hier unter anderem eine Zuordnungsempfehlung zwischen den geforderten Datenfeldern und den gängigen SBOM-Formaten SPDX und CycloneDX ergänzt, den Lizenzabschnitt überarbeitet und virtuelle sowie referenzierte Komponenten neu eingeführt.
Teil 3, Version 1.0.0, beschreibt, wie Hersteller mit eingehenden Schwachstellenmeldungen umgehen sollen, also einem der Kernstücke der CRA-Meldepflichten.
Und dann gibt es noch Teil H, der sich um die Konformitätsbewertung auf Basis einer umfassenden Qualitätssicherung nach Modul H dreht. Hersteller können darüber ihre CRA-Konformität über ein ISO/IEC-27001-konformes Informationssicherheits-Managementsystem nachweisen, etwa über den guten alten IT-Grundschutz. Wer also schon ein funktionierendes ISMS hat, kann bestehende Prozesse und Fähigkeiten einfach auf Produktentwicklung und Schwachstellenbehandlung ausweiten, statt bei null anzufangen. Dieser Teil liegt aktuell in Version 1.1.0 vor.
Sicherheitsmaßnahmen zum Nachlesen und Nachbauen
Nach einer Kommentierungsphase hat das BSI Teil 1 zudem in einer Zwischenversion 0.10.0 überarbeitet. Neu mit dabei: ein risikobasierter Ansatz zur Auswahl von IT-Sicherheitsmaßnahmen sowie eine erste Sammlung generischer Maßnahmen im maschinenlesbaren Format OSCAL. Diese Inhalte gibt es ergänzend auf Github, den Zugang dazu kann man sich über das Funktionspostfach [email protected] besorgen.
Eigener CycloneDX-Namensraum
Damit Hersteller leichter SBOM erstellen können, die zu Teil 2 passen, hat das BSI außerdem einen eigenen Namensraum für das SBOM-Format CycloneDX angelegt und offiziell registrieren lassen. Die dazugehörige Taxonomie liegt öffentlich einsehbar auf dem Github-Account des BSI.
Ob die TR-03183 am Ende wirklich die Brücke schlägt, die sie schlagen soll, wird sich wohl erst in den nächsten Jahren zeigen. Fest steht aber schon jetzt: Wer bei SBOM, Schwachstellenmanagement und Sicherheitsmaßnahmen bisher eher planlos unterwegs war, bekommt mit dem Dokument zumindest eine Checkliste an die Hand, an der er sich entlanghangeln kann.
(red)
