Effizientes Schwachstellenmanagement durch Automatisierung: Das Common Security Advisory Framework (CSAF) 2.0: Das CSAFversum 27 Monate nach dem Big Bang

Hinweis: Dieser Artikel stammt aus der Ausgabe 1/2025 der Zeitschrift IT-SICHERHEIT. Das komplette Heft können Sie hier herunterladen. (Registrierung erforderlich)

Die Anzahl veröffentlichter sicherheitsrelevanter Schwachstellen [1], stieg in den vergangenen  Jahren so erheblich an (siehe Abbildung 1), dass aktuell die Handhabung und Evaluierung dieser Informationen bereits nahezu unmöglich oder nur mit sehr viel personellem Aufwand manuell bearbeitbar ist. [2] Die EU hat daher am 10. Dezember 2024 durch das Inkrafttreten des Cyber Resilience Act (CRA) [3], einer Marktzugangsregelung, die Cybersicherheitsanforderungen an Produkte mit digitalen Elementen über den gesamten Lebenszyklus hinweg stellt, ein Zeichen für mehr IT-Sicherheit in Europa gesetzt.

Fakt ist, dass im Zuge einer immer stärker vernetzten, automatisierten und dadurch auch komplexeren Welt die Menge an Schwachstellen perspektivisch nicht geringer werden wird. Es ist zu erwarten, dass die schiere Anzahl, nicht nur durch die mit dem CRA verbundenen Meldepflichten, sondern allein durch die Tatsache, dass sich statistisch gesehen in mehr als 75 Prozent aller Applikationen mindestens eine Sicherheitslücke befindet,[4, 5] erheblich anwachsen wird.

Jede Soft- und Hardware ist ab einem gewissen Komplexitätsgrad als fehlerbehaftet anzusehen, und IT-Sicherheitslücken sind omnipräsent. Langfristig wird es nicht mehr darum gehen, ob ein System oder eine Komponente von sicherheitsrelevanten Schwachstellen betroffen ist, sondern wie schnell bekannte Sicherheitslücken geschlossen werden. Ein zeitgemäßes Schwachstellen- und Risikomanagement über alle Unternehmensgrößen und -bereiche sowie über den gesamten Produktlebenszyklus, wie es der CRA für Produkte mit digitalen Elementen fordert, ist daher unverzichtbar.

Um Informationen zu Schwachstellen in Produkten oder in einer Infrastruktur und deren Behebungsmaßnahmen zu kommunizieren, werden Sicherheitsinformationen (Security Advisories), veröffentlicht. Von Unternehmen zu Unternehmen und von Advisory zu Advisory können sich die Struktur, der Inhalt, die Qualität und das Format (z. B. HTML, PDF, TXT etc.) zur Kommunikation von Schwachstellen und den zugehörigen Behebungsmaßnahmen erheblich unterscheiden.

Ebenso ist nicht abzusehen, wie sich die Gefährdungslage entwickelt, wann es neu entdeckte Schwachstellen oder weitergehende Informationen zu bereits bekannten Sicherheitslücken gibt und auf welchen Wegen (E-Mail, Download von einer Webseite, Feed etc.) und in welchem Zeitraum die Kunden diese erhalten. Aufgrund der unterschiedlichen Strukturen sind die Advisories oft nur menschenlesbar. Eine automatisierte Verarbeitung der Informationen ist nur mit Vorarbeit möglich und fehleranfällig bei Veränderungen an Struktur oder Format.

Zusammengefasst ist es schlichtweg nicht möglich die Flut an Informationen zu beherrschen und wenn, dann nur mit einem enormen personellen Aufwand. IT-Sicherheitsfachkräfte, an denen es weltweit mangelt, werden durch die Suche nach Advisories und deren Evaluation gebunden. Sie stehen damit nicht für die eigentliche Risikobewertung von Informationen über Schwachstellen, deren Behebung und andere Fachaufgaben zur Verfügung.

Ein Standard bringt Ordnung ins System

Um diese Vielzahl von neu entdeckten Schwachstellen, den dazugehörigen Informationen, den Security-Advisory-Formaten, den unterschiedlichen Informationswegen und der Bewertung überhaupt bewältigen zu können, braucht es dringend eine Lösung. Ein Teil dieser Lösung besteht darin, dass die Prozesse zur Kommunikation und zum Erhalt von Sicherheitsinformationen strukturiert erfolgen und automatisierbar werden. IT-Sicherheitsfachkräfte aus Wirtschaft, Verwaltung und Gesellschaft haben daher ihre Expertise auf internationaler Ebene vereint und gemeinsam das Common Security Advisory Framework (CSAF) 2.0 entwickelt. Am 18. November 2022 wurde CSAF als OASIS Open Standard veröffentlicht [6] und ist damit weltweit kostenfrei zugänglich. Das Framework spezifiziert einerseits das Format für maschinenverarbeitbare Sicherheitsinformationen und andererseits deren automatisierte Verteilung in Form von Bereitstellung, Auffindung und Abruf.

Standardkonforme CSAF-Dokumente werden im JSON-Format erstellt und sind immer gleich aufgebaut. Sie enthalten Metadaten, einen Produktbaum und Informationen über Schwachstellen, bezogen auf die einzelnen Produkte, und sind bis auf den Versionslevel aufgeschlüsselt. Die Verwendung von Dateien im JSON-Format erlaubt die gewünschte Maschinenlesbarkeit und die daraus resultierende Skalierbarkeit für die Verarbeitung von CSAF-Dokumenten. Dadurch kann schnell und effizient bewertet, priorisiert und auf bekannt gewordene Gefährdungen reagiert werden.

Ferner werden nur die Security Advisories automatisiert abgerufen, die für den Anwender relevant sind, zum Beispiel weil das betroffene Produkt in einer Infrastruktur eingesetzt wird. Das setzt ein umfassendes Asset-Management voraus, das alle in einem Unternehmen eingesetzten Produkte und Komponenten auflistet.

Der CSAF-Standard 2.0 spezifiziert insgesamt drei Rollen für die Bereitstellung, die Suche und den Abruf von CSAF-Dokumenten: CSAF publisher, CSAF provider und CSAF trusted provider. Nur der CSAF provider und der CSAF trusted provider, der die Sicherheitsinformationen mit einer Signatur, einem OpenPGP-Schlüssel zur Überprüfung der Integrität und einem HashWert versieht, erlauben ein automatisierbares Auffinden und den automatisierbaren Abruf von Sicherheitsinformationen gemäß CSAF-Standard 2.0. Um den Bezug von Sicherheitsinformationen weiter zu vereinfachen, gibt es sogenannte CSAF Lister beziehungsweise Aggregatoren, die wie ein Telefonbuch agieren und die Quellen aufführen, die CSAF-Dokumente bereitstellen. Die Security Advisories von CSAF-Publishern können von einer Stelle gesammelt werden, um so ihren automatisierbaren Abruf für andere konsumierende Stellen zu gewährleisten (Abbildung 2).

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) betreibt einen solchen kostenfreien Aggregator [7]. Unternehmen, die Advisories im CSAF-Format bereitstellen, egal, ob sie bereits Trusted Provider sind oder nicht, können sich zum einen selbst beim BSI melden oder von Dritten vorgeschlagen werden. Das BSI führt dann eine Plausibilitätsprüfung der veröffentlichenden Stelle hinsichtlich der Bereitstellung standardkonformer Sicherheitsinformationen durch. Die Verwendung des CSAF-Standards reduziert somit sowohl den manuellen Aufwand als auch die Anzahl der relevanten Advisory-Informationen erheblich und ermöglicht einen automatisierten Abruf von Sicherheitsinformationen.

Das CSAFversum wurde geboren

Um die Vorteile der Automatisierung von strukturierten Informationen zu nutzen, muss der CSAF-Standard eine gewisse Verbreitung finden. Nur mittels Expansion kann überhaupt der Makrokosmos, das sogenannte CSAFversum, entstehen. Ein wichtiger Faktor dafür ist zum einen die Kenntnis darüber, dass es den CSAF-Standard gibt und welche Vorteile er bietet. Zum anderen
sind die Kosten und der Aufwand, die hinter der Weiterentwicklung des CSAFversum stecken und von Organisationen aufgewendet werden müssen, ein wichtiges Kriterium für die Nutzung und Verbreitung von CSAF-Dokumenten.

Um die Akzeptanz zu erhöhen und Kosten sparen zu können, werden seitens des BSI alle Entwicklungen und zukünftigen Entwicklungsvorhaben konsequent als kostenlose Open-Source-Software mit entsprechenden Implementierungsanleitungen zur Verfügung gestellt. Die einzelnen Werkzeuge können von Organisationen genutzt und weiterentwickelt werden. Ebenso ermöglichen Rückmeldungen und Verbesserungsvorschläge aus der Community die stetige Weiterentwicklung des CSAFversums.

Das führt dazu, dass bereits heute Advisories, welche die Anforderungen dieses Standards erfüllen, von vielen, auch großen Unternehmen, angeboten werden und deren Anzahl kontinuierlich steigt. Um das CSAFversum weiter expandieren zu lassen, müssen künftig mehr und mehr Organisationen ihre Advisories im CSAF-Format veröffentlichen und bereitstellen. Anreize für die Bereitstellung von Sicherheitsinformationen bieten insbesondere Betreiber, Integratoren, Behörden und Hersteller, die innerhalb von Lieferketten CSAF-Advisories einfordern und dies sogar vertraglich festlegen, beispielsweise bei Ausschreibungen. Darüber hinaus sind gesetzliche Vorgaben, so auch der CRA, eine Möglichkeit, damit sich bestehende Standards etablieren, weil sie helfen, die Anforderungen zu erfüllen.

Bisher gibt es diverse Open-Source-Tools, um die Nutzung des CSAF-Standards weiter zu fördern und Organisationen bei der Erstellung, Verteilung, Darstellung und Bewertung von Advisories zu unterstützen [8, 9, 10, 11, 12]. Weitere werden in den kommenden Monaten und Jahren folgen. Die Basisinfrastruktur des CSAFversums war bereits nach weniger als 1,5 Jahren geschaffen [13] und wird bis heute weiter ausgebaut. Die nächsten Meilensteine werden voraussichtlich in diesem Jahr zum einen die Veröffentlichung des CSAF-Standards 2.0 als ISO-Standard [14] und zum anderen die Veröffentlichung des CSAF-Standards 2.1 sein, der Anpassungen und Verbesserungswünsche aus der Community wie die Nutzung des Common Vulnerability Scoring System (CVSS) 4.0 [15] enthalten wird.

Wo die Reise im CSAFversum nach der Veröffentlichung von CSAF 2.1 noch hingehen kann, wird sich aus aktuellen und kommenden Erfordernissen und Regulierungen ergeben. Diese Anforderungen können sehr agil abgebildet werden, denn sie ermöglichen die kontinuierliche Erweiterung, Verbesserung sowie die Individualisierung der bestehenden Werkzeuge. Die Zusammenarbeit durch wertvolle Community-Beiträge ist mit einem Teleskop vergleichbar, das neue und bisher unbekannte Bereiche des CSAFversums beleuchten und deren Erschließung erlauben wird.

Hinzu kam die Regulierung

Das Entstehen neuer Himmelskörper oder Tier- und Pflanzenarten wird durch besondere Rahmenbedingungen ermöglicht. Ebenso verhält es sich im Kontext der internationalen, europäischen und nationalen Regulierung. Durch einen vorgegebenen Rechtsrahmen müssen Dinge oder Prozesse entsprechend verändert oder angepasst werden oder überhaupt erst Einzug in die Regulierung erhalten, wie im Fall der IT-Sicherheit. Durch aktuelle Gesetze auf nationaler und europäischer Ebene, wie den CRA [3], das IT-Sicherheitsgesetz 2.0 [16] oder die NIS-2-Richtlinie [17] und deren Umsetzung, wird IT-Sicherheit inzwischen mitgedacht und mehr IT-Sicherheitsbewusstsein von Organisationen eingefordert, beispielsweise mittels eines Warn und Meldewesens zur Kommunikation von IT-Sicherheitsproblemen.

Der CRA wurde am 20. November 2024 im EU-Amtsblatt veröffentlicht und ist am 11. Dezember 2024 in Kraft getreten. Der CRA verfolgt das Ziel, resiliente Infrastrukturen zu schaffen und sichere Produkte in der EU einzusetzen. Er stellt weitreichende Anforderungen an die IT-Sicherheit von Produkten und die Prozesse innerhalb und außerhalb von Organisationen:

• Der CRA ist eine Marktzugangsregelung für Produkte mit digitalen Elementen, die im Europäischen Wirtschaftsraum (EWR) vertrieben werden.
• Er fordert, dass es transparente Schwachstellenmanagementprozesse und eine Software Bill of Materials (SBOM) seitens der Organisationen gibt.
• Organisationen müssen einen IT-Sicherheitskontakt haben, der beispielsweise durch die Implementierung der security.txt (RFC 9116) [19, 20] realisiert werden kann.
• Die EU-Mitgliedstaaten haben Marktaufsichtsbehörden, deren Aufgabe die Marktüberwachung ist und sie ermächtigt, Produkte mit IT-Sicherheitsbedenken zu untersuchen und sie gegebenenfalls vom Markt nehmen zu dürfen.
• Ab dem 11. Juni 2026 können Konformitätsbewertungsstellen die Erfüllung der Anforderungen an den CRA von Produkten und Komponenten bewerten.
• Für Hersteller, die ihre Produkte im EWR vertreiben und folglich durch den CRA reguliert werden, besteht ab dem 11. September 2026 eine Meldepflicht für Schwachstellen und Sicherheitsvorfälle.
• Es wird eine europäische Schwachstellendatenbank geben. Hier werden alle nationalen Computer-Security-and-Incident-Response-Teams (CIRTs) angeschlossen sein.
• Ab dem 11. Dezember 2027 müssen alle CRA-Anforderungen bei neuen Produkten eingehalten werden.

Das BSI hat die Technische Richtlinie TR-03183 [21] zu Cyberresilienz-Anforderungen, die aus drei Teilen besteht, als Begleitpublikation zum CRA veröffentlicht. In Teil 1 (General Requirements) werden Anforderungen an Hersteller und Produkte in Anlehnung an die Anforderungen aus den Artikeln und Anhängen des CRA zusammengestellt. Im zweiten Teil werden formelle und fachliche Vorgaben für Software Bill of Materials gemacht und Teil 3 (Vulnerability Reports and Notifcations) beschreibt den Umgang mit eingehenden Schwachstellenmeldungen.

Ebenso wie es die NIS-2-Regulierung fordert, muss es im Zuge des CRA auch strukturierte Schwachstellenmanagementprozesse sowie eine Sammelstelle für Schwachstelleninformationen geben. Das ist notwendig, um resilienter zu werden und sich beispielsweise vor Angriffen oder unsicheren Produkten zu schützen und entsprechende Schutzmaßnahmen länderübergreifend kommunizieren zu können. Das wird dazu führen, dass letztlich mehr über Schwachstellen gesprochen wird und als logische Konsequenz mehr Advisories publiziert werden müssen, um Organisationen und auch die Marktaufsicht zu informieren. Hier könnte sich die Nutzung des CSAF-Standards als unabdingbar erweisen, sodass das CSAFversum in unsere Welt, mit all ihren aktuellen und zukünftigen Prozessen und Regulierungen, vollständig integriert würde.

Deswegen hat das BSI zudem die Technische Richtlinie TR-03191 [22] veröffentlicht. Die Adaption von CSAF erleichtert die Erfüllung der regulatorischen Anforderungen. Hersteller erfüllen ihre
Pflichten zur Bereitstellung von Advisories. Anwender erhalten eine Möglichkeit, mit geringem Aufwand über Schwachstellen in ihren Systemen informiert zu werden und können schneller handeln. Durch die maschinenverarbeitbaren Sicherheitsinformationen, den standardisierten Abruf und die Verteilung ermöglicht das Framework nicht nur die gewünschte Skalierbarkeit und Delegation von Aufgaben, sondern auch die Einhaltung der aktuellen und kommenden gesetzlichen Vorgaben (Compliance).

Das CSAFversum expandiert

Nach lediglich 27 Monaten ist klar, dass das CSAFversum keine Einbildung ist, sondern tatsächlich existiert. Es ist nicht nur gewachsen, sondern expandiert stetig weiter – und das zu Recht. Behördliche Ausschreibungen, die Kenntnisse des CSAF-Standards erfordern, sind mittlerweile auf der Tagesordnung. Es wird gefordert, dass sämtliche Schwachstellen und ihre Behebungsmaßnahmen in Form von CSAF-Advisories kommuniziert werden. Auch die amerikanische Cybersecurity and Infrastructure Security Agency (CISA) publiziert mittlerweile standardkonforme CSAF-Advisories für den Bereich der Operational Technology (OT). [23]

Es ist ein Trend erkennbar, dass mehr und mehr Organisationen sich für den CSAF-Standard interessieren und um Unterstützung bei der Implementierung bitten. Die Notwendigkeit der Automatisierung, aber auch die aktuellen und künftigen Anforderungen durch neue Gesetzgebungen, sind den meisten bewusst. Denn gerade bei kritischen Schwachstellen ist es enorm wichtig, zeitnah eine Aussage hinsichtlich der Betroffenheit oder eben Nicht-Betroffenheit zu treffen. Auch dies lässt sich mit dem CSAF-Standard, in Form eines Vulnerability-ExploitabilityeXchange-(VEX)-Advisories [24], abbilden, da VEX ein Profil in CSAF ist.

Weiterhin zeugt die Anzahl der verschiedenen CSAF-Tools, die auf unterschiedlichen Github-Repositories [8, 9, 10, 11, 12] zur Verfügung stehen und von der Community genutzt und ständig weiterentwickelt werden, von der Expansion des CSAFversums. Ein weiterer Bedarf zeigt sich in der gestiegenen Nachfrage für praxisnahe Workshops, die sowohl das Veröffentlichen und Erstellen von CSAF-Advisories als auch die Verteilung von Sicherheitsinformationen und deren Abruf trainieren. Durch das „Train-the-Trainer“-Prinzip werden CSAF-Kenntnisse in die Fläche gebracht. Jede Person und Organisation kann also einen aktiven Beitrag leisten, egal ob durch die Veröffentlichung von Security Advisories, durch die Forderung nach solchen, durch das Erstellen neuer Werkzeuge oder durch die Weitergabe von Wissen. Aufgrund dieser Art der vertrauensvollen Zusammenarbeit und der aktuellen und zukünftigen gesetzlichen Anforderungen erreicht CSAF eine große Reichweite, und das CSAFversum ist bereit für die nächste Dimension.

Um das CSAFversum zu sehen, braucht man 2025 weder eine Lupe noch ein Teleskop. Der CSAF-Standard ist weltweit angekommen und hat gute Chancen zu bleiben, um sich weiterzuentwickeln und nicht als Supernova oder aussterbende Art zu enden.

Literatur

[1]Common Vulnerabilities and Exposures (CVE). https://cve.org/
[2]Open Source Security. „It’s time to fix CVE“. 30.03.2021. https://opensourcesecurity.io/2021/03/30/its-time-to-fix-cve/
[3]European Cyber Resilience Act. www.european-cyber-resilience-act.com/
[4]Veracode. „State of Software Security Report“. www.veracode.com/state-of-software-security-report
[5]Comparitech. „Cybersecurity Vulnerability Statistics“. www.comparitech.com/blog/information-security/cybersecurity-vulnerability-statistics/
[6]OASIS. „CSAF Documentation“. https://oasis-open.github.io/csaf-documentation/
[7]CERT-Bund. „CSAF Aggregator“. wid.cert-bund.de/.well-known/csaf-aggregator/aggregator.json
[8]GitHub Repository: CSAF Webview. https://github.com/csaf-poc/csaf_webview
[9]GitHub Repository: GOCSAF. https://github.com/gocsaf/csaf
[10]GitHub Repository: CSAF Backend. https://github.com/csaf-poc/csaf_backend
[11]GitHub Repository: ISDuBA. https://github.com/ISDuBA/ISDuBA/
[12]GitHub Repository: Secvisogram. https://github.com/secvisogram
[13]Truxius, Dr. Dina C. „Die Entwicklung des CSAFversums: 17½ Monate nach dem Big Bang“. 20. Deutscher IT-Sicherheitskongress des BSI, 2024
[14]ISO. „ISO/IEC 29147:2024“. www.iso.org/standard/89986.html
[15]FIRST. „Common Vulnerability Scoring System (CVSS) v4.0“. www.first.org/cvss/v4-0/
[16]Bundesgesetzblatt. „BSIG (2009)“. www.gesetze-im-internet.de/bsig_2009/
[17]EUR-Lex. „Richtlinie (EU) 2022/2555“. https://eur-lex.europa.eu/eli/dir/2022/2555/oj
[18]Bundesamt für Sicherheit in der Informationstechnik (BSI). „Lagebericht 2024“. www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Lageberichte/Lagebericht2024.html
[19]Allianz für Cybersicherheit. „BSI-CS 149“. www.allianz-fuer-cybersicherheit.de/SharedDocs/Downloads/Webs/ACS/DE/BSI-CS/BSI-CS_149.html
[20]RFC Editor. „RFC 9116“. www.rfc-editor.org/info/rfc9116
[21]Bundesamt für Sicherheit in der Informationstechnik (BSI). „Technische Richtlinie TR-03183“. www.bsi.bund.de/dok/TR-03183
[22]Bundesamt für Sicherheit in der Informationstechnik (BSI). „Technische Richtlinie TR-03191“. www.bsi.bund.de/dok/TR-03191
[23]Cybersecurity and Infrastructure Security Agency (CISA). „Transforming Vulnerability Management: CISA adds OASIS CSAF 2.0 Standard to ICS Advisories“. Transforming Vulnerability Management: CISA Adds OASIS CSAF 2.0 Standard to ICS Advisories | CISA
[24]Cybersecurity and Infrastructure Security Agency (CISA). „Minimum Requirements for VEX“. https://www.cisa.gov/sites/default/files/2023-04/minimum-requirements-for-vex-508c.pdf

Weitere Artikel zum Thema: 

BSI begrüßt CRA-Verabschiedung als wichtige Stütze der Cybersicherheit

Sicherheit für Produkte: Cyber Resilience Act der EU

Cyber Resilience Act: Drei Maßnahmen, die Unternehmen sofort ergreifen sollten