Schlagwortarchiv für: NIST NVD

Das Common Security Advisory Framework (CSAF) reguliert die Bereitstellung von maschinenlesbaren Sicherheitshinweisen nach einem standardisierten Prozess, damit sie automatisiert ausgetauscht werden können. Greenbone arbeitet kontinuierlich an der Integration von Technologien, die den CSAF 2.0-Standard für die automatisierte Bereitstellung von Cybersecurity-Informationen nutzen. Eine Einführung in CSAF 2.0 und wie es das Schwachstellenmanagement der nächsten Generation unterstützt, finden Sie in einem früheren Blogbeitrag.

Zu Beginn des Jahres 2024 hat der Ausfall der NIST National Vulnerabilities Database (NVD) den Fluss kritischer Cybersicherheitsinformationen an nachgeschaltete Verbraucher unterbrochen. Dies macht das dezentralisierte CSAF 2.0-Modell zunehmend wichtiger für Cybersicherheitsinformationen, um die Widerstandsfähigkeit gegenüber einem einzelnen Ausfallpunkt zu erhöhen. Wer CSAF 2.0 einführt, kommt einem zuverlässigeren Ökosystem für Cybersicherheitsinformationen einen Schritt näher.


Inhaltsverzeichnis

1. Zusammenfassung
2. Wer sind die CSAF-Stakeholder?
2.1. Rollen im CSAF 2.0-Prozess
2.1.1. CSAF 2.0 Ausstellende Parteien
2.1.1.1. Die Rolle des CSAF-Publishers
2.1.1.2. Die Rolle des CSAF-Providers
2.1.1.3. Die Rolle des Trusted Providers in CSAF
2.1.2. CSAF 2.0 Datenaggregatoren
2.1.2.1. Die Rolle des CSAF-Listers
2.1.2.2. Die Rolle des CSAF-Aggregators
3. Fazit


1. Zusammenfassung

Dieser Artikel stellt die verschiedenen Akteure und Rollen dar, die in der CSAF-2.0-Spezifikation definiert sind. Die Rollen regeln die Mechanismen zur Erstellung, Verbreitung und Nutzung von Sicherheitshinweisen innerhalb des CSAF-2.0-Ökosystems. Das Verständnis, wer die Stakeholder von CSAF sind und welche standardisierten Rollen das CSAF 2.0-Framework definiert, hilft Security-Verantwortlichen klarer zu sehen, wie CSAF funktioniert, ob es für ihre Organisation von Nutzen sein kann und wie CSAF 2.0 zu implementieren ist.

2. Wer sind die CSAF-Stakeholder?

Auf höchster Ebene hat der CSAF-Prozess zwei primäre Stakeholder-Gruppen: vorgelagerte Produzenten, die Cybersicherheitshinweise im CSAF-2.0-Dokumentenformat erstellen und bereitstellen, und nachgelagerte Konsumenten (Endnutzer), die die Hinweise konsumieren und die darin enthaltenen Sicherheitsinformationen anwenden.

Bei den vorgelagerten Herstellern handelt es sich in der Regel um Anbieter von Softwareprodukten (wie Cisco, Red Hat und Oracle), die für die Aufrechterhaltung der Sicherheit ihrer digitalen Produkte und die Bereitstellung öffentlich zugänglicher Informationen über Schwachstellen verantwortlich sind. Zu den vorgelagerten Akteuren gehören auch unabhängige Sicherheitsforscher und öffentliche Einrichtungen, die als Quelle für Cybersicherheitsinformationen dienen, wie die US Cybersecurity Intelligence and Security Agency (CISA) und das deutsche Bundesamt für Sicherheit in der Informationstechnik (BSI).

Zu den nachgelagerten Verbrauchern gehören private Instanzen, die ihre eigene Cybersicherheit verwalten, staatliche CERT-Agenturen, die mit dem Schutz der nationalen IT-Infrastruktur betraut sind, und Managed Security Service Provider (MSSP), die die Cybersicherheit von Kunden überwachen und managen. Die in den CSAF 2.0-Dokumenten enthaltenen Informationen werden von IT-Sicherheitsteams genutzt, um Schwachstellen in ihrer Infrastruktur zu identifizieren und Abhilfemaßnahmen zu planen, und von Führungskräften, um zu beurteilen, wie IT-Risiken den Betrieb beeinträchtigen.

Schaubild zu den CSAF 2.0 Stakeholdern: Links die Upstream Producers wie Softwareanbieter, Behörden und Forscher, rechts die Downstream Consumers wie CERTs, SOC-Teams und Sicherheitsplattformen – verbunden durch das CSAF 2.0 Advisory Format.

Der CSAF-2.0-Standard definiert spezifische Rollen für vorgelagerte Hersteller, die ihre Beteiligung an der Erstellung und Verbreitung von Hinweis-Dokumenten beschreiben. Diese offiziell definierten Rollen sehen wie folgt aus:

2.1. Rollen im CSAF 2.0-Prozess

CSAF 2.0-Rollen werden in Abschnitt 7.2 definiert. Sie werden in zwei verschiedene Gruppen unterteilt: Ausstellende Parteien („Issuer“) und Datenaggregatoren („Aggregatoren“). Erstere sind direkt an der Erstellung von Beratungsdokumenten beteiligt. Letztere sammeln diese Dokumente und verteilen sie an die Endnutzer, um die Automatisierung für die Verbraucher zu unterstützen. Eine einzelne Organisation kann sowohl die Rolle des Ausstellers als auch die des Aggregators übernehmen, diese Funktionen sollten jedoch als separate Einheiten betrieben werden. Selbstverständlich müssen Organisationen, die als vorgelagerte Produzenten agieren, auch ihre eigene Cybersicherheit gewährleisten. Daher können sie auch nachgelagerte Verbraucher sein, die CSAF-2.0-Dokumente aufnehmen, um ihre eigenen Aktivitäten im Bereich des Schwachstellenmanagements zu unterstützen.

Diagramm der CSAF 2.0 Upstream-Rollen mit den Gruppen Issuing Parties (Producer, Provider, Trusted Provider) und Data Aggregators (Lister, Aggregator), die Cybersicherheitshinweise an Downstream Consumers weiterleiten.

Die spezifischen Verantwortlichkeiten der CSAF-2.0-Issuer und Datenaggregatoren stellen sich wie folgt dar:

2.1.1. CSAF 2.0 Ausstellende Parteien

Issuers sind die Quelle der CSAF-2.0-Cybersecurity-Hinweise. Sie sind jedoch nicht für die Übermittlung der Dokumente an die Endnutzer verantwortlich. Sie müssen angeben, wenn sie nicht wollen, dass ihre Hinweise von Datenaggregatoren aufgelistet oder gespiegelt werden. Außerdem können CSAF 2.0-Aussteller auch als Datenaggregatoren fungieren.

Hier sind die einzelnen Unterrollen innerhalb der Gruppe der ausstellenden Parteien:

2.1.1.1. Die Rolle des CSAF-Publishers

Publisher sind in der Regel Organisationen, die Hinweise nur im Namen ihrer eigenen digitalen Produkte entdecken und weitergeben. Sie müssen die Anforderungen 1 bis 4 in Abschnitt 7.1 der CSAF 2.0-Spezifikation erfüllen. Dies bedeutet, dass sie strukturierte Dateien mit gültiger Syntax und Inhalten herausgeben, die den in Abschnitt 5.1 beschriebenen CSAF 2.0-Dateinamenskonventionen entsprechen, und sicherstellen, dass die Dateien nur über verschlüsselte TLS-Verbindungen verfügbar sind. Außerdem müssen sie alle als TLP:WHITE klassifizierten Hinweise öffentlich zugänglich machen.

Alle Publisher müssen über ein öffentlich zugängliches provider-metadata.json-Dokument verfügen, das grundlegende Informationen über die Organisation, ihren CSAF-2.0-Rollenstatus und Links zu einem öffentlichen OpenPGP-Schlüssel enthält, mit dem das provider-metadata.json-Dokument digital signiert wird, um seine Integrität zu verifizieren. Diese Informationen werden von Softwareanwendungen verwendet, die die Hinweise der Publisher für Endbenutzer anzeigen.

2.1.1.2. Die Rolle des CSAF-Providers

Provider stellen CSAF-2.0-Dokumente für die breitere Gemeinschaft zur Verfügung. Zusätzlich zur Erfüllung der gleichen Anforderungen wie ein Publisher muss ein Provider seine provider-metadata.json.-Datei nach einer standardisierten Methode bereitstellen (mindestens eine der Anforderungen 8 bis 10 aus Abschnitt 7.1), eine standardisierte Verteilung für seine Hinweise verwenden und technische Kontrollen implementieren, um den Zugang zu allen Hinweisdokumenten mit dem Status TLP:AMBER oder TLP:RED zu beschränken.

Provider müssen außerdem wählen, ob sie die Dokumente auf der Grundlage eines Verzeichnisses oder auf der Grundlage von ROLIE verteilen wollen. Einfach ausgedrückt, stellt die verzeichnisbasierte Verteilung Hinweisdokumente in einer normalen Verzeichnispfadstruktur zur Verfügung, während ROLIE (Resource-Oriented Lightweight Information Exchange) [RFC-8322] ein RESTful-API-Protokoll ist, das speziell für die Automatisierung der Sicherheit, die Veröffentlichung, das Auffinden und die gemeinsame Nutzung von Informationen entwickelt wurde.

Verwendet ein Provider die ROLIE-basierte Verteilung, muss er auch die Anforderungen 15 bis 17 aus Abschnitt 7.1 erfüllen. Verwendet ein Provider die verzeichnisbasierte Verteilung, so muss er alternativ die Anforderungen 11 bis 14 aus Abschnitt 7.1 erfüllen.

2.1.1.3. Die Rolle des Trusted Providers in CSAF

Trusted Provider sind eine besondere Klasse von CSAF-Providern, die sich ein hohes Maß an Vertrauen und Zuverlässigkeit erworben haben. Sie müssen sich an strenge Sicherheits- und Qualitätsstandards halten, um die Integrität der von ihnen ausgestellten CSAF-Dokumente zu gewährleisten.

Zusätzlich zur Erfüllung aller Anforderungen an einen CSAF-Provider müssen Trusted Provider auch die Anforderungen 18 bis 20 aus Abschnitt 7.1 der CSAF 2.0-Spezifikation erfüllen. Diese beinhalten die Bereitstellung eines sicheren kryptographischen Hashs und einer OpenPGP-Signaturdatei für jedes ausgegebene CSAF-Dokument und sie stellen sicher, dass der öffentliche Teil des OpenPGP-Signierschlüssels öffentlich zugänglich gemacht wird.

2.1.2. CSAF 2.0 Datenaggregatoren

Datenaggregatoren konzentrieren sich auf die Sammlung und Weiterverteilung von CSAF-Dokumenten. Sie fungieren als Verzeichnis für CSAF-2.0-Issuers und deren Hinweis-Dokumente sowie als Vermittler zwischen Issuers und Endanwendern. Eine einzelne Instanz kann sowohl als CSAF-Lister als auch als Aggregator fungieren. Datenaggregatoren können je nach den Bedürfnissen ihrer Kunden wählen, welche Hinweis-Dokumente von vorgelagerten Publishern sie auflisten oder sammeln und weiterverteilen.

Hier sind einzelne Unterrollen in der Gruppe der Datenaggregatoren:

2.1.2.1. Die Rolle des CSAF-Listers

Sogenannte „Lister“ sammeln CSAF-Dokumente von mehreren CSAF-Herausgebern und listen sie an einem zentralen Ort auf, um das Auffinden zu erleichtern. Der Zweck eines Listers ist es, als eine Art Verzeichnis für CSAF 2.0-Hinweise zu fungieren, indem URLs konsolidiert werden, unter denen CSAF-Dokumente abgerufen werden können. Es wird nicht davon ausgegangen, dass ein Lister einen vollständigen Satz aller CSAF-Dokumente enthält.

Lister müssen eine gültige aggregator.json-Datei veröffentlichen, die mindestens zwei separate CSAF-Anbieter auflistet. Während ein Lister auch als Issuer fungieren kann, darf er keine gespiegelten Dateien auflisten, die auf eine Domain unter seiner eigenen Kontrolle zeigen.

2.1.2.2. Die Rolle des CSAF-Aggregators

Die Rolle des CSAF-Aggregators stellt den letzten Wegpunkt zwischen den veröffentlichten CSAF-2.0-Hinweis-Dokumenten und dem Endanwender dar. Aggregatoren bieten einen Ort, an dem CSAF-Dokumente durch ein automatisiertes Tool abgerufen werden können. Obwohl Aggregatoren als konsolidierte Quelle für Cybersicherheitshinweise fungieren, vergleichbar mit NIST NVD oder CVE.org der MITRE Corporation, handelt es sich bei CSAF 2.0 um ein dezentralisiertes Modell, im Gegensatz zu einem zentralisierten Modell. Aggregatoren sind nicht verpflichtet, eine umfassende Liste von CSAF-Dokumenten von allen Herausgebern anzubieten. Außerdem können die Herausgeber ihren CSAF-Beratungsfeed kostenlos zur Verfügung stellen oder als kostenpflichtigen Dienst betreiben.

Ähnlich wie Lister müssen Aggregatoren eine aggregator.json-Datei öffentlich zugänglich machen, und CSAF-Dokumente von jedem gespiegelten Issuer müssen in einem separaten Ordner zusammen mit der provider-metadata.json des Issuers abgelegt werden. Im Wesentlichen müssen Aggregatoren die Anforderungen 1 bis 6 und 21 bis 23 aus Abschnitt 7.1 der CSAF-2.0-Spezifikation erfüllen.

CSAF-Aggregatoren sind auch dafür verantwortlich, sicherzustellen, dass jedes gespiegelte CSAF-Dokument eine gültige Signatur (Anforderung 19) und einen sicheren kryptografischen Hash (Anforderung 18) besitzt. Wenn die ausstellende Partei diese Dateien nicht zur Verfügung stellt, muss der Aggregator sie erzeugen.

3. Fazit

Das Verständnis der CSAF 2.0-Stakeholder und -Rollen ist entscheidend für die ordnungsgemäße Umsetzung von CSAF 2.0 und die Nutzung der automatisierten Erfassung und Nutzung wichtiger Cybersicherheitsinformationen. Die CSAF 2.0-Spezifikation definiert zwei Hauptinteressengruppen: vorgelagerte Produzenten, die für die Erstellung von Cybersicherheitshinweisen verantwortlich sind, und nachgelagerte Verbraucher, die diese Informationen zur Verbesserung der Sicherheit nutzen. Zu den Rollen innerhalb von CSAF 2.0 gehören Issuer (Herausgeber, Anbieter und vertrauenswürdige Anbieter), die Hinweise erstellen und verteilen, und Datenaggregatoren wie Lister und Aggregatoren, die diese Hinweise sammeln und an die Endnutzer weitergeben.

Die Mitglieder jeder Rolle müssen sich an bestimmte Sicherheitskontrollen halten, die die sichere Übertragung von CSAF 2.0-Dokumenten unterstützen. Das Traffic Light Protocol (TLP) regelt, wie Dokumente freigegeben werden dürfen und welche Zugriffskontrollen erforderlich sind.

IT-Sicherheitsteams müssen nicht unbedingt wissen, was CSAF ist, aber andererseits kann die Kenntnis dessen, was „unter der Haube“ einer Schwachstellenmanagement-Plattform passiert, einen Kontext dafür liefern, wie sich das Schwachstellenmanagement der nächsten Generation entwickelt und welche Vorteile ein automatisiertes Schwachstellenmanagement hat. In diesem Artikel geben wir eine Einführung in CSAF 2.0, was es ist und wie es das Schwachstellenmanagement in Unternehmen verbessern soll.

Die Greenbone AG ist offizieller Partner des Bundesamtes für Sicherheit in der Informationstechnik (BSI) bei der Integration von Technologien, die den CSAF 2.0 Standard für automatisierte Cybersecurity Advisories nutzen.

Was ist CSAF?

Das Common Security Advisory Framework (CSAF) 2.0 ist ein standardisiertes, maschinenlesbares Format für Hinweise auf Sicherheitslücken. CSAF 2.0 ermöglicht es der vorgelagerten Cybersecurity Intelligence Community, einschließlich Software- und Hardware-Anbietern, Regierungen und unabhängigen Forschern, Informationen über Schwachstellen bereitzustellen. Nachgelagert ermöglicht CSAF den Nutzern von Schwachstelleninformationen, Sicherheitshinweise von einer dezentralen Gruppe von Anbietern zu sammeln und die Risikobewertung mit zuverlässigeren Informationen und weniger Ressourcenaufwand zu automatisieren.

Durch die Bereitstellung eines standardisierten, maschinenlesbaren Formats stellt CSAF eine Entwicklung hin zu einem automatisierten Schwachstellenmanagement der nächsten Generation dar, das die Belastung der IT-Sicherheitsteams, die mit einer ständig wachsenden Zahl von CVE-Enthüllungen konfrontiert sind, verringern und die risikobasierte Entscheidungsfindung angesichts eines Ad-hoc-Ansatzes beim Austausch von Schwachstelleninformationen verbessern kann.

CSAF 2.0 ist der Nachfolger des Common Vulnerability Reporting Framework (CVRF) v1.2 und erweitert die Möglichkeiten seines Vorgängers, um mehr Flexibilität zu bieten.

Hier sind die wichtigsten Erkenntnisse:

  • CSAF ist ein internationaler offener Standard für maschinenlesbare Dokumente mit Hinweisen auf Schwachstellen, der die Markup-Sprache JSON verwendet.
  • Die CSAF-Aggregation ist ein dezentralisiertes Modell zur Verteilung von Schwachstelleninformationen.
  • CSAF 2.0 wurde entwickelt, um ein automatisiertes Schwachstellenmanagement der nächsten Generation in Unternehmen zu ermöglichen.

Der traditionelle Prozess des Schwachstellenmanagements

Der traditionelle Prozess der Schwachstellenverwaltung ist für große Unternehmen mit komplexen IT-Umgebungen ein schwieriger Prozess. Die Anzahl der CVEs, die in jedem Patch-Zyklus veröffentlicht werden, steigt in einem unkontrollierbaren Tempo [1][2]. Bei einem herkömmlichen Schwachstellenmanagementprozess sammeln IT-Sicherheitsteams Schwachstelleninformationen manuell über Internetrecherchen. Auf diese Weise ist der Prozess mit einem hohen manuellen Aufwand für das Sammeln, Analysieren und Organisieren von Informationen aus einer Vielzahl von Quellen und Ad-hoc-Dokumenten Formaten verbunden.

Zu diesen Quellen gehören in der Regel:

  • Datenbanken zur Verfolgung von Schwachstellen wie NIST NVD
  • Sicherheitshinweise der Produktanbieter
  • Nationale und internationale CERT-Beratungen
  • Bewertungen der CVE-Nummerierungsbehörde (CNA)
  • Unabhängige Sicherheitsforschung
  • Plattformen für Sicherheitsinformationen
  • Code-Datenbanken ausnutzen

Das letztendliche Ziel, eine fundierte Risikobewertung durchzuführen, kann während dieses Prozesses auf verschiedene Weise vereitelt werden. Empfehlungen, selbst die des Produktanbieters, sind oft unvollständig und werden in einer Vielzahl nicht standardisierter Formate geliefert. Dieser Mangel an Kohärenz erschwert eine datengestützte Entscheidungsfindung und erhöht die Fehlerwahrscheinlichkeit.

Lassen Sie uns kurz die bestehende Informationspipeline für Schwachstellen sowohl aus der Sicht der Ersteller als auch der Verbraucher betrachten:

Der Prozess der Offenlegung von Schwachstellen

Die in der National Vulnerability Database (NVD) des NIST (National Institute of Standards and Technology) veröffentlichten CVE-Datensätze (Common Vulnerability and Exposure) stellen das weltweit zentralste globale Repository für Schwachstelleninformationen dar. Im Folgenden finden Sie einen Überblick darüber, wie der Prozess der Offenlegung von Schwachstellen funktioniert:

  1. Produktanbieter werden durch ihre eigenen Sicherheitstests oder durch unabhängige Sicherheitsforscher auf eine Sicherheitslücke aufmerksam und setzen damit eine interne Richtlinie zur Offenlegung von Sicherheitslücken in Gang. In anderen Fällen können unabhängige Sicherheitsforscher direkt mit einer CVE Numbering Authority (CNA) zusammenarbeiten, um die Schwachstelle ohne vorherige Rücksprache mit dem Produktanbieter zu veröffentlichen.
  2. Schwachstellen-Aggregatoren wie NIST NVD und nationale CERTs erstellen eindeutige Tracking-IDs (z. B. eine CVE-ID) und fügen die gemeldete Schwachstelle einer zentralen Datenbank hinzu, in der Produktanwender und Schwachstellenmanagement-Plattformen wie Greenbone die Fortschritte verfolgen können.
  3. Verschiedene Interessengruppen wie der Produkthersteller, NIST NVD und unabhängige Forscher veröffentlichen Hinweise, die Informationen zu Abhilfemaßnahmen, voraussichtliche Termine für offizielle Patches, eine Liste der betroffenen Produkte, CVSS-Auswirkungsbewertungen und Schweregrade, Common Platform Enumeration (CPE) oder Common Weakness Enumeration (CWE) enthalten können, aber nicht müssen.
  4. Andere Anbieter von Informationen über Cyber-Bedrohungen, wie z. B. Known Exploited Vulnerabilities (KEV) von CISA und Exploit Prediction Scoring System (EPSS) von First.org, liefern zusätzlichen Risikokontext.

Der Prozess des Schwachstellenmanagements

Die Produktanwender sind für die Aufnahme von Schwachstelleninformationen und deren Anwendung verantwortlich, um das Risiko einer Ausnutzung zu mindern. Hier ein Überblick über den traditionellen Prozess des Schwachstellenmanagements in Unternehmen:

  1. Produktanwender müssen CVE-Datenbanken manuell durchsuchen und die Sicherheitshinweise überwachen, die ihre Software- und Hardware-Assets betreffen, oder eine Schwachstellenmanagement-Plattform wie Greenbone nutzen, die automatisch die verfügbaren Ad-hoc-Bedrohungshinweise zusammenfasst.
  2. Die Produktnutzer müssen die verfügbaren Informationen mit ihrem IT-Bestand abgleichen. Dies beinhaltet in der Regel die Pflege eines Bestandsverzeichnisses und die Durchführung eines manuellen Abgleichs oder die Verwendung eines Produkts zum Scannen von Schwachstellen, um den Prozess der Erstellung eines Bestandsverzeichnisses und der Durchführung von Schwachstellentests zu automatisieren.
  3. Die IT-Sicherheitsteams ordnen die entdeckten Schwachstellen nach dem kontextbezogenen Risiko für kritische IT-Systeme, Geschäftsabläufe und in einigen Fällen für die öffentliche Sicherheit.
  4. Die Ausbesserungen werden entsprechend der endgültigen Risikobewertung und den verfügbaren Ressourcen zugewiesen.

Was ist falsch am traditionellen Schwachstellenmanagement?

Herkömmliche oder manuelle Verfahren zur Verwaltung von Schwachstellen sind in der Praxis komplex und nicht effizient. Abgesehen von den operativen Schwierigkeiten bei der Implementierung von Software-Patches behindert der Mangel an zugänglichen und zuverlässigen Informationen die Bemühungen um eine wirksame Sichtung und Behebung von Schwachstellen. Die alleinige Verwendung von CVSS zur Risikobewertung wurde ebenfalls kritisiert [1][2], da es an ausreichendem Kontext für eine solide risikobasierte Entscheidungsfindung mangelt. Obwohl Plattformen zur Verwaltung von Schwachstellen wie z. B. Greenbone die Belastung der IT-Sicherheitsteams erheblich verringern, ist der Gesamtprozess immer noch häufig von geplagt von einer zeitaufwändigen manuellen Zusammenstellung von Ad-hoc-Hinweisen auf Schwachstellen, die unvollständige Informationen zur Folge haben kann.

Vor allem angesichts der ständig wachsenden Zahl von Schwachstellen besteht die Gefahr, dass die Zusammenstellung von Ad-hoc-Sicherheitsinformationen zu langsam ist und zu mehr menschlichen Fehlern führt, wodurch die Zeit für die Aufdeckung von Schwachstellen verlängert und die risikobasierte Priorisierung von Schwachstellen erschwert wird.

Fehlende Standardisierung führt zu Ad-hoc-Intelligenz

Dem derzeitigen Verfahren zur Offenlegung von Schwachstellen fehlt eine formale Methode zur Unterscheidung zwischen zuverlässigen Informationen von Anbietern und Informationen, die von beliebigen unabhängigen Sicherheitsforschern wie den Partner-CNAs bereitgestellt werden. Tatsächlich wirbt die offizielle CVE-Website selbst für die niedrigen Anforderungen, die für eine CNA-Mitgliedschaft gelten. Dies führt dazu, dass eine große Anzahl von CVEs ohne detaillierten Kontext herausgegeben wird, was eine umfangreiche manuelle Anreicherung im nachgelagerten Bereich erzwingt.

Welche Informationen aufgenommen werden, liegt im Ermessen des CNA, und es gibt keine Möglichkeit, die Zuverlässigkeit der Informationen zu klassifizieren. Ein einfaches Beispiel für dieses Problem ist, dass die betroffenen Produkte in einem Ad-hoc-Hinweis oft mit einer Vielzahl von Deskriptoren angegeben werden, die manuell interpretiert werden müssen. Zum Beispiel:

  • Version 8.0.0 – 8.0.1
  • Version 8.1.5 und höher
  • Version <= 8.1.5
  • Versionen vor 8.1.5
  • Alle Versionen < V8.1.5
  • 0, V8.1, V8.1.1, V8.1.2, V8.1.3, V8.1.4, V8.1.5

Skalierbarkeit

Da Anbieter, Prüfer (CNAs) und Aggregatoren verschiedene Verteilungsmethoden und Formate für ihre Hinweise verwenden, wird die Herausforderung der effizienten Verfolgung und Verwaltung von Schwachstellen operativ komplex und schwer zu skalieren. Darüber hinaus verschlimmert die zunehmende Offenlegung von Schwachstellen die manuellen Prozesse, überfordert die Sicherheitsteams und erhöht das Risiko von Fehlern oder Verzögerungen bei den Abhilfemaßnahmen.

Schwierige Bewertung des Risikokontextes

NIST SP 800-40r4 „Guide to Enterprise Patch Management Planning“ Abschnitt 3 empfiehlt die Anwendung von Schwachstellen-Metriken auf Unternehmensebene. Da das Risiko letztlich vom Kontext jeder Schwachstelle abhängt – Faktoren wie betroffene Systeme, potenzielle Auswirkungen und Ausnutzbarkeit -, stellt die derzeitige Umgebung mit Ad-hoc-Sicherheitsinformationen ein erhebliches Hindernis für ein solides risikobasiertes Schwachstellenmanagement dar.

Wie löst CSAF 2.0 diese Probleme?

Bei den CSAF-Dokumenten handelt es sich um wichtige Hinweise zu Cyber-Bedrohungen, mit denen die Lieferkette für Schwachstelleninformationen optimiert werden kann. Anstatt Ad-hoc-Schwachstellendaten manuell zu sammeln, können Produktanwender maschinenlesbare CSAF-Hinweise aus vertrauenswürdigen Quellen automatisch in einem Advisory Management System zusammenführen, das die Kernfunktionen des Schwachstellenmanagements wie Asset-Matching und Risikobewertung kombiniert. Auf diese Weise zielt die Automatisierung von Sicherheitsinhalten mit CSAF darauf ab, die Herausforderungen des traditionellen Schwachstellenmanagements durch die Bereitstellung zuverlässigerer und effizienterer Sicherheitsinformationen zu bewältigen und das Potenzial für das Schwachstellenmanagement der nächsten Generation zu schaffen.

CSAF 2.0 löst die Probleme des traditionellen Schwachstellenmanagements auf folgende Weise:

Zuverlässigere Sicherheitsinformationen

CSAF 2.0 behebt das Problem der Ad-hoc-Sicherheitsinformationen, indem es mehrere Aspekte der Offenlegung von Sicherheitslücken standardisiert. So erlauben die Felder zur Angabe der betroffenen Version standardisierte Daten wie Version Range Specifier (vers), Common Platform Enumeration (CPE), Paket-URL-Spezifikation, CycloneDX SBOM sowie den allgemeinen Produktnamen, die Seriennummer, die Modellnummer, die SKU oder den File-Hash zur Identifizierung betroffener Produktversionen.

Neben der Standardisierung von Produktversionen unterstützt CSAF 2.0 auch den Austausch von Schwachstellen (Vulnerability Exploitability eXchange, VEX), mit dem Produkthersteller, vertrauenswürdige CSAF-Anbieter oder unabhängige Sicherheitsforscher explizit den Status der Produktbehebung angeben können. VEX liefert Produktanwendern Empfehlungen für Abhilfemaßnahmen.

Die expliziten VEX-Status-Deklarationen sind:

  • Nicht betroffen: Es sind keine Abhilfemaßnahmen bezüglich einer Schwachstelle erforderlich.
  • Betroffen: Es werden Maßnahmen empfohlen, um eine Schwachstelle zu beheben oder zu beseitigen.
  • Behoben: Bedeutet, dass diese Produktversionen einen Fix für eine Sicherheitslücke enthalten.
  • Wird untersucht: Es ist noch nicht bekannt, ob diese Produktversionen von einer Sicherheitslücke betroffen sind. Ein Update wird in einer späteren Version zur Verfügung gestellt.

Effektivere Nutzung von Ressourcen

CSAF ermöglicht mehrere vor- und nachgelagerte Optimierungen des traditionellen Schwachstellenmanagement-Prozesses. Die OASIS CSAF 2.0-Dokumentation enthält Beschreibungen mehrerer Konformitätsziele, die es Cybersecurity-Administratoren ermöglichen, ihre Sicherheitsabläufe zu automatisieren und so ihre Ressourcen effizienter zu nutzen.

Hier sind einige Zielvorgaben für die Einhaltung der Vorschriften, auf die im CSAF 2.0 die eine effektivere Nutzung von Ressourcen über den traditionellen Prozess des Schwachstellenmanagements hinaus unterstützen:

  • Advisory Management System: Ein Softwaresystem, das Daten verarbeitet und CSAF-2.0-konforme Beratungsdokumente erstellt. Es ermöglicht den CSAF-Produktionsteams, die Qualität der zu einem bestimmten Zeitpunkt eingehenden Daten zu bewerten, sie zu überprüfen, zu konvertieren und als gültige CSAF-2.0-Sicherheitshinweise zu veröffentlichen. Auf diese Weise können CSAF-Produzenten die Effizienz ihrer Informationspipeline optimieren und gleichzeitig sicherstellen, dass korrekte Hinweise veröffentlicht werden.
  • CSAF Management System: Ein Programm, das CSAF-Dokumente verwalten kann und in der Lage ist, deren Details gemäß den Anforderungen des CSAF-Viewers anzuzeigen. Auf der grundlegendsten Ebene ermöglicht dies sowohl den vorgelagerten Produzenten als auch den nachgelagerten Konsumenten von Sicherheitshinweisen, deren Inhalt in einem für Menschen lesbaren Format zu betrachten.
  • CSAF Asset Matching System / SBOM Matching System: Ein Programm, das mit einer Datenbank von IT-Assets, einschließlich Software Bill of Materials (SBOM), integriert wird und Assets mit allen CSAF-Hinweisen abgleichen kann. Ein Asset-Matching-System dient dazu, einem Unternehmen, das CSAF nutzt, Einblick in seine IT-Infrastruktur zu verschaffen, festzustellen, wo anfällige Produkte vorhanden sind, und optimale Informationen zur automatischen Risikobewertung und -behebung zu liefern.
  • Technisches System: Eine Softwareanalyse-Umgebung, in der Analysewerkzeuge ausgeführt werden. Ein Engineering-System kann ein Build-System, ein Versionskontrollsystem, ein Ergebnisverwaltungssystem, ein Fehlerverfolgungssystem, ein Testausführungssystem usw. umfassen.

Dezentralisierte Cybersicherheitsinformationen

Der kürzlich verkündete Ausfall des CVE-Anreicherungsprozesses der NIST National Vulnerability Database (NVD) zeigt, wie riskant es sein kann, sich auf eine einzige Quelle für Schwachstelleninformationen zu verlassen. CSAF ist dezentralisiert und ermöglicht es nachgelagerten Nutzern von Schwachstellen, Informationen aus einer Vielzahl von Quellen zu beziehen und zu integrieren. Dieses dezentralisierte Modell des Informationsaustauschs ist widerstandsfähiger gegen den Ausfall eines Informationsanbieters, während die Last der Anreicherung von Schwachstellen effektiver auf eine größere Anzahl von Beteiligten verteilt wird.

Anbieter von IT-Produkten für Unternehmen wie RedHat und Cisco haben bereits ihre eigenen CSAF- und VEX-Feeds erstellt, während staatliche Cybersicherheitsbehörden und nationale CERT-Programme wie das deutsche Bundesamt für Sicherheit in der Informationstechnik (BSI) und die US-amerikanische Cybersecurity & Infrastructure Security Agency (CISA) ebenfalls CSAF-2.0-Austauschfunktionen entwickelt haben. 

Das dezentralisierte Modell ermöglicht es auch, dass sich mehrere Interessengruppen zu einer bestimmten Schwachstelle äußern, so dass die nachgeschalteten Verbraucher mehr Informationen über eine Schwachstelle erhalten. Mit anderen Worten: Eine Informationslücke in einem Gutachten kann von einem alternativen Hersteller geschlossen werden, der die genaueste Bewertung oder spezialisierte Analyse liefert.

Verbesserte Risikobewertung und Priorisierung von Schwachstellen

Insgesamt tragen die Vorteile des CSAF 2.0 zu einer genaueren und effizienteren Risikobewertung, Priorisierung und Abhilfemaßnahmen bei. Produktanbieter können direkt verlässliche VEX-Hinweise veröffentlichen, die Entscheidungsträgern im Bereich Cybersicherheit zeitnahe und vertrauenswürdige Informationen zu Abhilfemaßnahmen liefern. Außerdem dient das aggregierte Schweregradobjekt (aggregate_severity) in CSAF 2.0 als Vehikel, um verlässliche Dringlichkeits- und Kritikalitätsinformationen für eine Gruppe von Schwachstellen zu übermitteln, was eine einheitlichere Risikoanalyse und eine datengesteuerte Priorisierung von Abhilfemaßnahmen ermöglicht und die Expositionszeit kritischer Schwachstellen verkürzt.

Zusammenfassung

Herkömmliche Verfahren zum Management von Schwachstellen leiden unter mangelnder Standardisierung, was zu Problemen bei der Zuverlässigkeit und Skalierbarkeit führt und die Bewertung des Risikokontexts sowie die Fehlerwahrscheinlichkeit erschwert.

Das Common Security Advisory Framework (CSAF) 2.0 zielt darauf ab, den bestehenden Prozess des Schwachstellenmanagements zu revolutionieren, indem es eine zuverlässigere, automatisierte Sammlung von Schwachstelleninformationen ermöglicht. Durch die Bereitstellung eines standardisierten, maschinenlesbaren Formats für den Austausch von Schwachstelleninformationen im Bereich der Cybersicherheit und die Dezentralisierung ihrer Quelle versetzt CSAF 2.0 Organisationen in die Lage, zuverlässigere Sicherheitsinformationen zu nutzen, um ein genaueres, effizienteres und konsistenteres Schwachstellenmanagement zu erreichen.

Die Greenbone AG ist offizieller Partner des Bundesamtes für Sicherheit in der Informationstechnik (BSI) bei der Integration von Technologien, die den CSAF 2.0 Standard für automatisierte Cybersecurity Advisories nutzen.

Kontakt Kostenlos testen Hier kaufen Zurück zur Übersicht