Schwach­stellen­meldungen: Höher, schneller, weiter, wo führt die Straße hin

Der Eindruck vieler IT-Experten und Anwender ist, dass immer häufiger Schwachstellen mit teils gravierenden Auswirkungen bekannt werden. Es muss schneller gepatcht werden, weil sich Informationen über diese Schwachstellen rasant verbreiten. Das zeitnahe Schwachstellenmanagement wird für die IT-Administratoren aber nicht nur aufgrund der höheren Frequenz und Dringlichkeit erschwert, sondern auch dadurch, wie Informationen über Schwachstellen und deren zusammenfassende Advisories aufbereitet sind. Die Installation von Updates als Schutz vor Schwachstellen ist außerdem nicht frei von Risiken, weshalb eine vorherige Einschätzung der Folgen in Betracht gezogen werden muss. Für solch eine Einschätzung ist es wichtig, dass aktuelle Informationen in einer geeigneten Form zur Verfügung gestellt werden, damit rechtzeitig reagiert werden kann. Die Darstellung der Information über Schwachstellen und Advisories sowie deren Kritikalität in Form einheitlicher Datenformate und Metriken gewinnt daher zunehmend an Bedeutung.

Die Charakterisierung von Schwachstellen mit Hilfe des Common Vulnerability Scoring System (CVSS) vereinfacht das Verständnis und damit die Reaktionsgeschwindigkeit der IT-Administratoren. Die Version 4 von CVSS bezieht im Vergleich zu den vorhergehenden Versionen noch mehr Kontext in die Schwachstellenbewertung ein. Im Sinne einer höheren Präzision ist das hilfreich, wenngleich die Komplexität dadurch wieder steigt. Insbesondere werden Anwender-spezifische Kontexte, die (zu Recht) in die Bewertung einfließen, IT-Administratoren möglicherweise dadurch mehr eigene gedankliche Arbeit abverlangen.

Um der Situation der steigenden Anzahl von Advisories Herr zu werden, bedarf es einer Möglichkeit, deren Verarbeitung zu automatisieren. Derzeit haben wir als DFN-CERT bereits eine JSON-Struktur, die eine solche automatisierte Verarbeitung ermöglicht. Das BSI arbeitet ebenfalls an einer Lösung, Anwendern das Auffinden sowie die Bewertung und Umsetzung von Security Advisories zu erleichtern. Hierzu wird auf das maschinen­verarbeitbare Format für Security Advisories, das sogenannte Common Security Advisory Framework (CSAF) 2.0 zurückgegriffen. Dieses ermöglicht das automatisierte Abrufen von Security Advisories von Herstellern und das Abgleichen mit der eigenen Inventar­datenbank. Das Tool zum Erstellen von CSAF-Dokumenten (namens Secvisogram) hat das BSI auf seiner GitHub-Seite veröffentlicht.

Eine andere Möglichkeit, um mit der wachsenden Anzahl an Schwachstellen umzugehen, sind sogenannte „Negativ"-Advisories, die mit Hilfe von VEX verarbeitet werden. Im Gegensatz zu den klassischen Security Adisories wird hier nicht beschrieben, welches Produkt in welcher Version verwundbar ist und wie die konkreten Handlungsempfehlungen aussehen, sondern welche nicht betroffen sind.

In diesem Beitrag werden die Neuerungen der CVSS Version 4, die Themen CSAF und VEX näher beschrieben sowie Tools zur Automatisierung der Behandlung von Advisories vorgestellt.

https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Empfehlungen-nach-Angriffszielen/Industrielle-Steuerungs-und-Automatisierungssysteme/CSAF/CSAF_node.html

https://www.heise.de/news/Black-Hat-USA-2021-Security-Advisories-mehr-Durchblick-dank-Automatisierung-6155594.html

Bewertung von Schwachstellen mit CVSS

Gegenwärtig wird die CVSS-Metrik weiterentwickelt und die Version 4 soll im Herbst finalisiert werden. Im Folgenden wird beschrieben, welche Neuerungen die CVSS Version 4 enthält.

Attack Complexity (AC) wird ergänzt durch Attack Requirements (AR)

Die Basismetrik „Attack Complexity (AC)“ wird ergänzt durch die Basismetrik „Attack Requirements (AR)“.

Attack Complexity (AC): beschreibt die technische Komplexität eines Angriffs, die erforderlich ist, um defensive oder sicherheitsverbessernde Technologien zu umgehen.

Attack Requirements (AR): wiederum sind die vorausgesetzten Bedingungen der verwundbaren Komponente, die den Angriff möglich machen.

Grund für die Ergänzung ist, dass die „niedrigen“ und „hohen“ AC-Werte nicht die signifikanten Unterschiede zwischen den Bedingungen widerspiegeln, die derzeit in der Definition von „hoher“ Komplexität zusammengefasst sind. Das Umgehen von Sicherheitsmaßnahmen wie beispielsweise von Kryptographie stellen objektiv eine wesentlich höhere Komplexität dar, als die Iteration eines Angriffs, um eine Race Condition zu gewinnen. Dennoch führen beide Bedingungen derzeit zu demselben CVSS Score in Version 3.1.

User Interaction (UI): None, Active und Passive

Darüber hinaus wird die Basismetrik „User Interaction (UI)“ verfeinert in None, Passive und Active, um auch hier eine genauere Einordnung der Schwachstelle zu ermöglichen.

• None: Für das anfällige System ist keine Interaktion eines menschlichen Benutzers außer dem Angreifer notwendig, um die Schwachstelle auszunutzen.
• Passive: Die verwundbare Komponente erfordert begrenzte Interaktionen des anvisierten Benutzers. Das bedeutet, dass diese Interaktionen unfreiwillig sind und nicht erfordern, dass Benutzer aktiv eingebaute Schutzmaßnahmen einer Komponente umgehen.
• Active: Bei der aktiven Interaktion wiederum wird vorausgesetzt, dass ein anvisierter Benutzer bestimmte, bewusste Interaktionen mit der verwundbaren Komponente durchführt oder die Interaktionen aktiv Schutzmaßnahmen umgehen, was zur Ausnutzung der Schwachstelle führt.
   

Impact wird aufgeteilt in Vulnerable System und Subsequent System(s)

Des Weiteren entfällt in Version 4 die Basismetrik „Scope“, da diese in der Vergangenheit uneinheitliche Bewertungen zwischen den Herstellern untereinander verursachte. Stattdessen wird die Metrik „Impact“ in zwei Gruppen aufgeteilt, um in Zukunft differenzierter betrachten zu können, ob Schwachstellen nur das angegebene System oder noch weitere betreffen:

• Vulnerable System: Confidentiality (VC), Integrity (VI), Availability (VA)
• Subsequent System(s): Confidentiality (SC), Integrity (SI), Availability (SA)

Weiterhin entfallen die Metriken „Remediation Level (RL)“ und „Report Confidence (RC)“ und die Metrik „Exploit Code Maturity (E)“ wird geändert in „Exploit Maturity (E)“.

Supplemental Metrics Group

Viele Schwachstellen können nicht nur Auswirkungen auf ein betroffenes bzw. verwundbares System haben, sondern auch auf Menschen. Insbesondere in den Bereichen Internet of Things (IoT), Industrial Control Systems (ICS) und im Gesundheitswesen ist es von großer Bedeutung, dass diese Art von Auswirkungen als Teil der CVSS-Spezifikation identifiziert werden. Deshalb gibt es in CVSS Version 4 sogenannte „Umweltmetriken“, jeweils für Verbraucher (Operational Technology (OT): Consumer Supplied Environmental Safety) als auch für Anbieter (Operational Technology (OT): Provider Supplied Supplemental Safety).

Operational Technology (OT): Consumer Supplied Environmental Safety

Für Verbraucher wird hier unterschieden zwischen:

• Modified Integrity of Subsequent System: Safety (MSI:S): Dies beschreibt die erfolgreiche Ausnutzung einer Schwachstelle, welche die Integrität eines anfälligen Systems beeinträchtigt (z.B. Änderung der Dosierung einer Medikamenteninfusionspumpe), was zu einer Beeinträchtigung der menschlichen Gesundheit und Sicherheit führt.
• Modified Availability of Subsequent System: Safety (MSA: S): Dies beschreibt die erfolgreiche Ausnutzung einer Schwachstelle, welche die Verfügbarkeit eines anfälligen Systems beeinträchtigt (z. B. Ausfall eines Bremssystems in einem Auto), was ebenfalls zu einer Beeinträchtigung der menschlichen Gesundheit und Sicherheit führt.
   

Operational Technology (OT): Provider Supplied Supplemental Safety

Für Anbieter wird unterschieden zwischen:

• Present (P): kann hierbei die Werte „marginal“, „critical“ oder „catastrophic“ als Folge einer Schwachstelle haben.
• Negligible (N): entspricht hierbei der Definition der IEC 61508 Folgekategorie „vernachlässigbar“.
• Not Defined (X): bedeutet, dass kein Wert für diese Metrik für die Schwachstelle definiert wurde.

Diese Metriken sind für Anbieter optional anzugeben.

Supplemental Metrics

Außerdem werden die bestehenden Metriken um ergänzende erweitert. Diese bieten die Möglichkeit, neue Metriken zu definieren, die zusätzliche extrinsische Attribute einer Schwachstelle beschreiben und messen. Keine der Metriken hat einen numerischen Einfluss auf den endgültigen CVSS-Score. Organisationen können dann die Wichtigkeit und/oder die effektive Auswirkung der einzelnen Metriken oder einer Reihe/Kombination von Metriken zuordnen, indem diese mehr, weniger oder überhaupt keinen Einfluss auf die endgültige Risikoanalyse haben. Diese zusätzlichen Metriken sind optional für Hersteller anzugeben.

Supplemental Metric: Automatable

Die Metrik „Automatable“ erfasst die Antwort auf die Frage: „Kann ein Angreifer die Ausnutzung dieser Schwachstelle für mehrere Ziele automatisieren?“, basierend auf den Schritten 1-4 der Angriffskette: Reconnaissance, Weaponization, Delivery und Exploitation. Die Metrik kann zwei Werte haben: Nein und Ja.

Nein impliziert hierbei, dass Angreifer nicht alle Schritte der Angriffskette für diese Schwachstelle ausnutzen können, weil mindestens einer der folgenden Schritte zutrifft:

1. Reconnaissance: Die verwundbare Komponente ist nicht durchsuchbar oder aufzählbar.
2. Weaponization: Die Vorbereitung des Angriffs erfordert für jedes Ziel die Anweisung eines Menschen.
3. Delivery: Die Zustellung erfolgt über Kanäle, die von der Netzwerksicherheitskonfiguration blockiert werden.
4. Exploitation: Die Ausnutzung ist nicht zuverlässig aufgrund von Techniken zur Verhinderung von Angriffen.

Ja impliziert hingegen, dass alle Schritte der Angriffskette zuverlässig ausgenutzt werden können und die Schwachstelle eine unautorisierte Remote-Code-Ausführung oder Befehlseinschleusung ermöglicht. Zudem muss ein „Proof of Concept“ vorliegen, welches zeigt, dass alle vier Schritte automatisiert werden können.

Supplemental Metric: Recovery

Die Metrik „Recovery“ beschreibt die Widerstandsfähigkeit einer Komponente/eines Systems zur Wiederherstellung in Bezug auf Leistung und Verfügbarkeit, nachdem ein Angriff durchgeführt wurde. Diese kann folgende Werte haben:

• Automatic (A): Die Komponente/das System stellt sich nach einem Angriff automatisch wieder her.
• User (U): Die Komponente/das System erfordert ein manuelles Eingreifen des Benutzers zur Wiederherstellung nach einem Angriff.
• Irrecoverable (I): Die Komponente/das System kann nach einem Angriff vom Benutzer nicht wiederhergestellt werden.
   

Supplemental Metric: Value Density

Die Metrik „Value Density“ beschreibt die Ressourcen, die ein Angreifer mit einem einzigen Ausnutzungsereignis erlangt. Diese kann zwei mögliche Werte haben:

• Diffuse: Das System, das die verwundbare Komponente enthält, verfügt über begrenzte Ressourcen.
• Concentrated: Das System, das die verwundbare Komponente enthält, ist reich an Ressourcen. Heuristisch gesehen, sind solche Systeme oft in der direkten Verantwortung von „Systembetreibern“ und nicht von Benutzern.
   

Supplemental Metric: Vulnerability Response Effort

Die Metrik „Vulnerability Response Effort“ liefert ergänzende Informationen darüber, wie schwierig es für Anwender ist auf die Auswirkungen von Sicherheitslücken bei Produkten und Diensten in ihrer Infrastruktur zu reagieren. Anwender können diese zusätzlichen Informationen zum erforderlichen Aufwand bei der Anwendung und/oder der Planung von Abhilfemaßnahmen berücksichtigen. Die Metrik kann folgende Werte haben:

• Low (L): Der Aufwand für die Reaktion auf eine Schwachstelle ist gering.
• Moderate (M): Die Maßnahmen, die zur Behebung einer Schwachstelle nötig sind, erfordern einen gewissen Aufwand auf Seiten der Anwender und könnten minimale Auswirkungen auf den Dienst haben.
• High (H): Die zur Behebung einer Schwachstelle erforderlichen Maßnahmen sind erheblich und/oder schwierig und können möglicherweise zu einer längeren, geplanten Beeinträchtigung des Dienstes führen. Alternativ dazu ist eine Reaktion auf die Schwachstelle vor Ort nicht aus der Ferne möglich. Die einzige Lösung zur Behebung der Schwachstelle beinhaltet einen physischen Austausch.
   

Supplemental Metric: Provider Urgency

Zur Erleichterung einer standardisierten Methode zur Einbeziehung zusätzlicher, vom Anbieter bereitgestellter Bewertungen wurde eine optionale ergänzende Metrik mit der Bezeichnung „Provider Urgency“ definiert. Diese kann die folgenden Werte haben:

• Rot: Der Provider hat die Auswirkungen dieser Schwachstelle mit der höchsten Dringlichkeit bewertet.
• Gelb: Der Provider hat die Auswirkungen dieser Schwachstelle als mäßig dringlich eingestuft.
• Grün: Der Provider hat die Auswirkungen dieser Schwachstelle als weniger dringlich eingestuft
• Weiß: Der Provider hat die Auswirkungen dieser Schwachstelle als wenig oder gar nicht dringlich eingestuft. (Informativ)

https://www.first.org/cvss/v4-0/cvss-v40-presentation.pdf

CSAF aus unterschiedlichen Perspektiven

Im Folgenden wird beschrieben, wie die Arbeit mit CSAF aus unterschiedlichen Perspektiven aussehen kann.

Benutzer-Perspektive

Aus Benutzer-Perspektive kann die Arbeit mit CSAF so aussehen, dass ein Benutzer ein Advisory von einem „CSAF provider“, „CSAF trusted provider“ oder „CSAF aggregator“ abruft, mit einer Bestandsdatenbank vergleicht, entscheidet, wie mit dem Advisory zu verfahren ist und abschließend sein Handeln dokumentiert. (Siehe Abbildung 1)

Hersteller-Perspektive

Aus Hersteller-Perspektive kann die Arbeit mit CSAF so aussehen, dass ein Hersteller auf eine Schwachstelle aufmerksam wird, diese analysiert, einen Patch vorbereitet, einen Hinweis schreibt und abschließend den Patch sowie den Hinweis an einen „CSAF trusted provider“ veröffentlicht. (Siehe Abbildung 2)

Koordinator & Multiplier (Behördliche CERTs)

Aus Koordinator Perspektive kann die Arbeit mit CSAF so aussehen, dass ein Koordinator auf eine Sicherheitslücke aufmerksam wird, anschließend einen Hersteller kontaktiert, einen Coordinated Vulnerability Disclosure (CVD)-Fall durchführt, eine Handlungsempfehlung schreibt und abschließend ein Advisory mit der Sicherheitslücke veröffentlicht. (Siehe Abbildung 3)

Aus Multiplikator-Perspektive kann die Arbeit mit CSAF so aussehen, dass ein Multiplikator von einem Hersteller über ein Advisory in Kenntnis gesetzt wird, entscheidet, wie zu verfahren ist, eine Handlungsempfehlung schreibt und abschließend das Advisory veröffentlicht. (Siehe Abbildung 4)

https://www.bsi.bund.de/SharedDocs/Termine/DE/2022/CSAF_IHK.html

Behandlung von Advisories (CSAF)

Wie am Anfang des Artikels erwähnt, ist CSAF 2.0 ein maschinenverarbeitbares Format für Security Advisories, welches das automatisierte Abrufen von Security Advisories von Herstellern und das Abgleichen mit der eigenen Inventardatenbank ermöglicht. CSAF 2.0 ist der Nachfolger von CSAF CVRF 1.2 und wird entwickelt unter anderem von Cisco, Red Hat, Oracle, Siemens, BSI uvm. Diese bieten derzeit auch bereits Security Advisories im CSAF-Format an.

Frühere Arbeiten zu Advisory-Formaten werden an dieser Stelle nicht systematisch betrachtet, beispielhaft wäre das CAIF Project (2004-2005) unter Beteiligung von UKERNIA, TU Delft, CERT-VW, SAP, SAP-CERT, CISCO-PSIRT, ComCERT, GNSec, Kurt Seifried, Helmut Springer (delta) und RUS-CERT zu nennen.

https://caif.cert.uni-stuttgart.de/

https://caif.cert.uni-stuttgart.de/draft-goebel-caif-format.html

CSAF 2.0 definiert verschiedene Rollen für CSAF-Dokumente, welche sich bezüglich der Anforderungen unterscheiden und im folgenden aufgeführt werden. Detailliertere Informationen hierzu gibt es auf https://github.com/oasis-tcs/csaf/blob/master/csaf_2.0/prose/csaf-v2-editor-draft.md#7-distributing-csaf-documents

Rolle: CSAF Herausgeber (CSAF publisher)

Eine verteilende Partei erfüllt die Rolle „CSAF-Herausgeber“, wenn die Partei nur CSAF-Dokumente im eigenen Namen vertreibt und die Anforderungen 1 bis 4 erfüllt.

• Anforderung 1 (Gültiges CSAF-Dokument): vgl. Konformitätsklausel 1
• Anforderung 2 (Dateiname): Das CSAF-Dokument hat einen Dateinamen, der den Regeln in Abschnitt 5.1 entspricht.
• Anforderung 3 (TLS): Das CSAF-Dokument ist standardmäßig von einer Webseite abrufbar, die TLS für die Verschlüsselung und Serverauthentizität verwendet.
• Anforderung 4 (TLP:WHITE): Wenn das CSAF-Dokument mit TLP:WHITE gekennzeichnet ist, muss es frei zugänglich sein.
   

Rolle: CSAF Anbieter (CSAF provider)

Rolle: CSAF Vertrauenswürdiger Anbieter (CSAF trusted provider)

Eine verteilende Partei erfüllt die Rolle „CSAF Vertrauenswürdiger Anbieter“, wenn die Partei das Rollenprofil „CSAF-Anbieter“ erfüllt und zusätzlich die Anforderungen 18 bis 20.

• Anforderung 18 (Integrität): Alle CSAF-Dokumente müssen mindestens eine Hash-Datei haben, die mit einem sicheren kryptografischen Hash-Algorithmus (z. B. SHA-512 oder SHA-3) berechnet wurde, um ihre Integrität zu gewährleisten. Der Dateiname wird durch Anhängen der Dateierweiterung gebildet, die durch den Algorithmus vorgegeben wird.
  • MD5 und SHA1 sollten nicht verwendet werden.
  • Der Inhalt der Datei muss mit dem ersten Byte des hexadezimalen Hashwerts beginnen. Alle nachfolgenden Daten (wie ein Dateiname), die optional sind, müssen durch mindestens ein Leerzeichen getrennt sein.
  • Wenn ein ROLIE-Feed vorhanden ist, muss jede Hash-Datei darin aufgeführt werden, wie in Anforderung 15 beschrieben.
• Anforderung 19 (Signaturen): Alle CSAF-Dokumente müssen mindestens eine OpenPGP-Signaturdatei haben, die unter demselben Dateinamen bereitgestellt wird, der um die entsprechende Erweiterung ergänzt ist. Siehe RFC 4880 für weitere Details.
  • Wenn ein ROLIE-Feed vorhanden ist, muss jede Signaturdatei darin aufgeführt werden, wie in Anforderung 15 beschrieben.)
• Anforderung 20 (Öffentlicher OpenPGP-Schlüssel): Der öffentliche Teil des OpenPGP-Schlüssels, der zum Signieren der CSAF-Dokumente verwendet wird, muss verfügbar sein. Er sollte auch auf einem öffentlichen Schlüsselserver verfügbar sein.
  • Der OpenPGP-Schlüssel sollte eine Stärke haben, die als sicher angesehen wird.
     

Rolle: CSAF-Lister

Eine verteilende Partei erfüllt die Rolle des „CSAF-Listers“, wenn die Partei den Wert „lister“ für „/aggregator/category“ verwendet, keinen Mirror auflistet, der auf eine Domain unter seiner eigenen Kontrolle zeigt und die Anforderungen 6, 21 und 22 erfüllt.

• Anforderung 6 (Keine Umleitungen): siehe oben.
• Anforderung 21 (Liste der CSAF-Anbieter): Die Datei „aggregator.json“ muss vorhanden und gemäß dem JSON-Schema „CSAF aggregator“ gültig sein. Sie muss nicht neben einer „provider-metadata.json“ gespeichert werden. Die Datei „aggregator.json“ sollte nur die neueste Version der Metadaten eines „CSAF-Anbieters“ auflisten.
• Anforderung 22 (Zwei disjunkte Ausgabestellen): Die Datei „aggregator.json“ (Anforderung 21) listet mindestens zwei disjunkte „CSAF-Provider“ (einschließlich CSAF Trusted Provider) oder einen „CSAF-Publisher“ und einen „CSAF-Provider“ (einschließlich CSAF Trusted Provider) auf.
• Anforderung 23 (Mirror): Die CSAF-Dokumente für jede ausstellende Behörde, die gespiegelt werden, müssen sich in einem anderen Ordner befinden. Der Ordnername sollte aus dem Namen der ausstellenden Behörde abgeleitet werden. Dieser Ordner muss sich neben der „aggregator.json“ befinden (Anforderung 21). Jeder dieser Ordner muss mindestens:
  • eine „provider-metadata.json“ für die aktuelle ausstellende Stelle enthalten.
  • das ROLIE-Feed-Dokument gemäß Anforderung 15 bereitstellen, das auf die lokale Kopie des CSAF-Dokuments verweist.

Der Zweck dieser Rolle ist es, eine Liste von URLs zur Verfügung zu stellen, unter denen CSAF-Dokumente zu finden sind. Es wird nicht angenommen, dass die Liste vollständig ist.

Rolle: CSAF-Aggregator

Eine vertreibende Partei erfüllt die Rolle des „CSAF-Aggregators“, wenn die Partei

• die Anforderungen 1 bis 6 und 21 bis 23 erfüllt.
• den Wert „aggregator“ für „/aggregator/category“ verwendet.
• einen Mirror für mindestens zwei disjunkte Issuing Parties aufführt, der auf eine Domain unter eigener Kontrolle zeigt.
• den öffentlichen Teil des OpenPGP-Schlüssels verlinkt, der zum Signieren von CSAF-Dokumenten verwendet wird, für jede gespiegelte ausstellende Partei in der entsprechenden „provider-metadata.json“.
• für jedes gespiegelte CSAF-Dokument eine Signatur (Anforderung 19) und einen Hash (Anforderung 18) bereitstellt. Beide müssen im ROLIE-Feed aufgeführt sein.

Wenn die ausstellende Partei diese Dateien für ein CSAF-Dokument bereitstellt, müssen diese ebenfalls kopiert werden. Wenn die ausstellende Partei diese Dateien nicht bereitstellt, müssen sie vom CSAF-Aggregator erstellt werden. Eine solche Signatur impliziert keine Haftung des CSAF-Aggregators für den Inhalt des entsprechenden CSAF-Dokuments. Sie bestätigt lediglich, dass das bereitgestellte CSAF-Dokument nach dem Herunterladen von der ausstellenden Partei nicht verändert wurde. Ein CSAF-Aggregator kann zusätzliche Signaturen und Hashes für ein CSAF-Dokument hinzufügen.

Außerdem kann ein CSAF-Aggregator eine oder mehrere ausstellende Parteien auflisten, die er nicht spiegelt.

Der Zweck dieser Funktion ist es, eine zentrale Stelle zu schaffen, an der CSAF-Dokumente abgerufen werden können. Es ist zu erwarten, dass es weltweit mehrere CSAF-Aggregatoren gibt. Keiner von ihnen ist verpflichtet, alle CSAF-Dokumente aller ausstellenden Parteien zu spiegeln. CSAF-Aggregatoren können kostenlos oder als kostenpflichtige Dienstleistung angeboten werden.

Um die Automatisierung zu unterstützen, können CSAF-Aggregatoren CSAF-Dokumente von CSAF-Herausgebern spiegeln. Hinsichtlich der Nutzungsbedingungen sollten sie sich mit der ausstellenden Partei beraten. Der Zweck dieser Option ist, dass ein Verbraucher CSAF-Dokumente von einem CSAF-Herausgeber so abrufen kann, als ob dieser Herausgeber ein vertrauenswürdiger CSAF-Anbieter wäre. Um dieses Ziel zu erreichen, sammelt ein CSAF-Aggregator die CSAF-Dokumente vom CSAF-Herausgeber und spiegelt sie. Der Sammelprozess kann automatisiert oder manuell erfolgen. CSAF-Aggregatoren geben das Abholintervall über das Feld „update_interval“ im entsprechenden Element der CSAF-Verlegerliste (csaf_publishers) in ihrer „aggregator.json„ bekannt.

Um den Implementierungsaufwand und den Prozess-Overhead zu minimieren, kann ein CSAF-Aggregator die CSAF-Dokumente eines CSAF-Verlags in eine interne Instanz einer CSAF-Provider-Software hochladen. Ein solches Konstrukt wird als „CSAF-Proxy-Provider“ bezeichnet, da es von der CSAF-Aggregator-Software gespiegelt werden kann. Ein solcher CSAF-Proxy-Provider muss jedoch nicht von einer anderen Stelle als dem CSAF-Aggregator selbst zugänglich sein. Andernfalls würde dies gegen die zweite Regel in Abschnitt 7.2.1 verstoßen. Daher wird empfohlen, den CSAF-Proxy-Provider nur auf localhost bereitzustellen und den Zugriff nur von der CSAF-Aggregator-Software aus zu erlauben.

https://www.bsi.bund.de/SharedDocs/Termine/DE/2022/CSAF_IHK.html

Tools zur Automatisierung

Im Folgenden werden einige Tools kurz vorgestellt, welche die Arbeit mit CSAF erleichtern.

BSI Secvisogram CSAF 2.0 Web Editor

Secvisogram ist ein Webtool zur Erstellung und Bearbeitung von Sicherheitshinweisen im CSAF-2.0-Format.

https://github.com/secvisogram/secvisogram

BSI Secvisogram CSAF Backend

Ist das Backend des Secvisogram vom BSI.

https://github.com/secvisogram/csaf-cms-backend

csaf_provider

Ist eine Implementierung der Rolle CSAF Trusted Provider, die auch einen einfachen HTTPS-basierten Verwaltungsdienst bietet.

https://github.com/csaf-poc/csaf_distribution/blob/main/docs/csaf_provider.md

csaf_uploader

Ist ein Kommandozeilenwerkzeug, das CSAF-Dokumente zum csaf_provider hochlädt.

https://github.com/csaf-poc/csaf_distribution/blob/main/docs/csaf_uploader.md

csaf_aggregator

Ist eine Implementierung der Rolle CSAF-Aggregator.

https://github.com/csaf-poc/csaf_distribution/blob/main/docs/csaf_aggregator.md

csaf_checker

Ist ein Werkzeug zum Testen eines CSAF Trusted Providers gemäß Abschnitt 7 des CSAF-Standards. Prüft Anforderungen, ohne die angegebene Rolle zu berücksichtigen.

https://github.com/csaf-poc/csaf_distribution/blob/main/docs/csaf_checker.md

csaf_downloader

Ist ein Werkzeug zum Herunterladen von Advisories von einem Provider.

https://github.com/csaf-poc/csaf_distribution/blob/main/docs/csaf_downloader.md

https://www.bsi.bund.de/SharedDocs/Termine/DE/2022/CSAF_IHK.html

Alternativer Ansatz

Während sich herkömmliche Security Advisories dafür eignen, betroffene Versionen und Abhilfemaßnahmen für Schwachstellen zu kommunizieren, eignen sich VEX, sogenannte „Negative"-Advisories, für das Gegenteil. Also, um zu bestätigen, dass ein Produkt nicht von einer Schwachstelle betroffen ist und keine Abhilfemaßnahmen erforderlich sind. Dies kann bspw. daran liegen, dass der Code, auf den sich die Schwachstelle bezieht, nicht vorhanden ist, nicht offengelegt wird, kompensierende Kontrollen existieren oder an anderen Faktoren.

Um VEX nutzen zu können, werden aktuelle Daten der Software, der Schwachstellen-Status sowie einige verpflichtende Felder bzgl. des Produktes bzw. der Schwachstelle benötigt, siehe Abbildung 6 und 7.

Im Folgenden sind die Voraussetzungen und verpflichtenden Felder von VEX beschrieben.

VEX: Voraussetzungen

„Descriptive Data of SW“ enthält das verpflichtende Feld „Product id“

„Vulnerability Status“ enthält die verpflichtenden Felder:

• „Vulnerability ID“ (CVE-Nummer)
• „Vuln details“ (Schwachstellenbeschreibung)
• „Product status“ gibt bspw. an, ob das Produkt noch gepflegt wird oder bereits den End-of-Life-Status erreicht hat.
• „Action statement / Impact statement“ beschreibt den Workaround bzw. die Auswirkung der Schwachstelle.

Weiteres verpflichtendes Feld: Metadata (author, id, timestamp)

Zudem kann ein Profil von VEX in CSAF integriert werden, sodass dieses ebenfalls maschinenlesbar und automatisiert genutzt werden kann, da es dieselbe Infrastruktur und dieselben Systeme verwendet.

https://i.blackhat.com/USA21/Wednesday-Handouts/US-21-Friedman-Your-Software-is-not-Vulnerable.pdf

Fazit

Da Security Advisories in den meisten Fällen nicht einheitlich aufgebaut sind, verbringen IT-Sicherheitsverantwortliche viel Zeit damit, diese zu sichten, zu analysieren und zu bewerten. In diesem Artikel wurden einige Möglichkeiten vorgestellt, um diesen Prozess zu optimieren.

CVSS Version 4 bringt zum einen viele Vorteile mit sich, wie bspw. detaillierte Informationen zu Schwachstellen, durch die eine genauere Risikoabschätzung und klarere Handlungsempfehlungen möglich sind. Andererseits bedeutet dies natürlich mehr Arbeit, weil mehr Informationen verarbeitet werden müssen, wobei gleichzeitig die Anzahl an Schwachstellen und Security Advisories zunimmt.

CSAF soll hier Abhilfe schaffen, da es die Behandlung von Security Advisories größtenteils automatisiert und durch das einheitliche Format weniger manuelle Arbeit in das Analysieren und Bewerten von Schwachstellen investiert werden muss. Voraussetzung hierfür ist jedoch, dass sowohl auf der Seite der verteilenden Parteien, als auch seitens der „Leser“ von Security Advisories CSAF verwendet wird.

VEX ist eine weitere Möglichkeit, um mit der steigenden Anzahl an Schwachstellen umzugehen, da durch sogenannte „Negative“-Advisories festgestellt werden kann, ob ein unterstütztes Produkt von einer Schwachstelle tatsächlich betroffen ist. Besonders in Zeiten, wo „Supply Chain Attacks“ sich häufen (siehe Log4Shell), leicht auszunutzen und gleichzeitig zahlreiche Produkte dadurch betroffen sind, ist dies von besonderem Mehrwert.

Trotz der eben beschriebenen Möglichkeiten, die den Umgang mit Security Advisories erleichtern sollen, scheitert es derzeit in der Praxis häufig daran, dass Hersteller und verantwortliche Institutionen nicht ausreichend Informationen bezüglich der Schwachstellen und der davon betroffenen Produkte bereitstellen. Dadurch ist es für Sicherheitsverantwortliche nicht trivial, das passende Advisory für das jeweilige Produkt zu finden, zumal sich die Common Platform Enumerations (CPEs) der National Vulnerability Database (NVD) oft von denen der Hersteller unterscheiden. Zum Teil kommt es vor, dass Hersteller überhaupt keine CPEs angeben oder Produkte umbenannt werden und infolgedessen unklar ist, ob ein veröffentlichtes Advisory auch für ältere Produkte gilt.

All diese Probleme können letztendlich nur durch eine (noch) bessere Zusammenarbeit zwischen Herstellern, internationalen Standardisierungsgremien, Sicherheitsforschern und den Institutionen, welche Standard-basiert Schwachstelleninformationen sammeln, pflegen und bereitstellen, angegangen werden. Oberstes Ziel dabei sollte es sein, IT-Sicherheitsverantwortlichen eindeutige und transparente Informationen an die Hand zu geben, die als praktikable Entscheidungshilfe dienen können.

Peter Sokolov, DFN-CERT