CSAF Docs mit Secvisogram

Das Common Security Advisory Framework (CSAF) ist ein maschinenlesbares Format und ein internationaler Standard für den Informationsaustausch über Cyber-Sicherheitslücken. Es informiert Nutzer Ihres Produkts über die richtige Reaktion: Müssen sie auf eine neuere Version aktualisieren? Müssen sie eine Konfiguration ändern? Ist Ihr Produkt überhaupt betroffen oder ruft es den betroffenen Teil der anfälligen Bibliothek möglicherweise nie auf?

Der CSAF-Standard von OASIS Open deckt ein sehr breites Spektrum an Szenarien ab. Aus diesem Grunde kann er zunächst sehr überwältigend sein. Diese Seite zeigt die wichtigsten Komponenten eines CSAF-Dokuments und bietet einen praktischen Leitfaden für den sofortigen Einstieg.

Secvisogram

CSAF-Dokumente sind Dateien im JSON-Format, die einem bestimmten Schema folgen. Daher können sie grundsätzlich mit jedem Texteditor erstellt werden. CSAF-Dokumente müssen jedoch eine Vielzahl von Regeln einhalten, die jeder CSAF-Anbieter (und das schließt BOMnipotent mit ein) überprüfen muss.

Stattdessen wird die Verwendung von Secvisogram empfohlen. Es handelt sich um eine Open-Source-Serveranwendung mit grafischer Benutzeroberfläche, die ursprünglich vom Bundesamt für Sicherheit in der Informationstechnik (BSI) entwickelt wurde.

Lokaler Editor

Der wohl bequemste Einstieg in das Schreiben von CSAF-Dokumenten ist das Forken des Repositorys local_csaf_editor der AUNOVIS GmbH . Es enthält ein kleines Bash-Skript zum lokalen Klonen und Ausführen von Secvisogram. Es ermunter Sie weiterhin dazu, versionierte CSAF-Vorlagen zu speichern, da einige Eigenschaften von Advisory zu Advisory immer gleich bleiben.

Wichtige Einträge

Die Erstellung eines validen CSAF-Dokuments ist eine Reise, die Sie von sich selbst über Ihre Produkte bis hin zu den Sicherheitslücken führt, die sie plagen. Diese Seite ist Ihre Karte und Ihr Reisebegleiter.

Wichtige Dokument Einträge

Dokumenteigenschaften liefern Informationen über das CSAF-Dokument selbst. Sie geben unter anderem Aufschluss darüber, wie es identifiziert werden kann, wer es wann erstellt hat, und mit wem es geteilt werden darf.

Titel

Der Titel des Dokuments soll dem menschlichen Leser den Inhalt des Dokuments verdeutlichen. Es ist sinnvoll, den Produktnamen und die Art der Sicherheitslücke im Titel anzugeben, es gibt jedoch keine formalen Einschränkungen.

In Secvisogram finden Sie den Titel unter “Metadaten auf Dokumentebene”.

Publisher

Der Abschnitt Publisher dient Ihrer eindeutigen Identifizierung als Herausgeber des Dokuments.

Er enthält die Pflichtfelder “Name”, “Namespace” und “Category” sowie die optionalen Felder “Issuing Authority” und “Contact Details”. Die hier angegebenen Werte sollten mit den Werten in Ihrer Provider-Metadaten -Konfiguration übereinstimmen, die für das Hosten von CSAF-Dokumenten erforderlich ist. Die Dokumentationsseite enthält weitere Informationen zu den hier anzugebenden Werten.

Tracking

Der Abschnitt Tracking enthält wichtige Metadaten zum Dokument. Er soll in erster Linie maschinenlesbar sein. Der erforderlichen Felder gibt es viele:

• ID: Die ID dient zusammen mit Ihrem Herausgeber-Namespace zur Identifizierung eines Dokuments. Sie muss daher innerhalb Ihrer Organisation eindeutig sein. Darüber hinaus verlangt der Standard lediglich, dass die ID nicht mit einem Leerzeichen beginnt oder endet. Es wird jedoch empfohlen, nur Kleinbuchstaben, Ziffern sowie die Symbole “+”, “-” und “_” zu verwenden, denn der Standard empfiehlt, dass Dateinamen für CSAF-Dokumente diesem Muster folgen. Abweichungen davon können zu Verwirrung und sogar Konflikten führen. Es gibt keinen triftigen Grund dafür, dass eine ID nicht mit ihrem Dateinamen identisch sein sollte.
• Initial Release Date (Erstveröffentlichungsdatum) und Current Release Date (Aktuelles Veröffentlichungsdatum) sind wunderbar selbsterklärende Felder.
• Status: Dieser Status muss “draft” (“Entwurf”), “interim” (“Zwischenstand”) oder “final” (“Endstand”) sein. Der Status informiert Ihre Nutzer über die voraussichtliche Änderungsrate des Dokuments. Vor dem ursprünglichen Veröffentlichungsdatum muss der Status “draft” sein.
• Version: Sie können entweder die semantische Versionierung oder eine natürliche Zahl als Dokumentversion verwenden. Es wird empfohlen, mit 1 als (semantische) Major Version oder als natürliche Zahl zu beginnen. Bei jeder Änderung Ihres Dokuments müssen Sie die Version erhöhen. Bei semantischen Versionen bedeutet dies, dass mindestens die Patch-Version erhöht werden muss, während bei natürlichen Zahlenversionen die Zahl mindestens um 1 erhöht werden muss.
• Revisionsverlauf: Dieser muss für jede veröffentlichte Version einen Eintrag mit Zeitstempel, Version und Zusammenfassung enthalten.

Distribution - TLP

Obwohl Sie das CSAF-Dokument nicht klassifizieren müssen, möchten Sie dies wahrscheinlich. Dies geschieht mithilfe des Traffic Light Protocol (TLP) , mit dem Sie die Informationen auf eine einzelne Person, eine Organisation und ihre Kunden, eine ganze Community oder gar nicht beschränken können.

Diese Klassifizierung hat programmatische Konsequenzen: Ein als TLP:WHITE oder TLP:CLEAR klassifiziertes Dokument wird von BOMnipotent öffentlich freigegeben, während Dokumente mit einer anderen Klassifizierung eine explizite Authentifizierung und Zugriff erfordern, um angezeigt zu werden.

Wenn Sie im Dokument keine Klassifizierung angeben, verwendet der BOMnipotent-Server ein konfigurierbares Standard-TLP . Dies bedeutet jedoch, dass die TLP-Informationen verloren gehen, sobald das Dokument vom Server heruntergeladen wird. Daher wird eine Klassifizierung im Dokument empfohlen.

Bitte beachten Sie, dass der CSAF-Standard nur die Klassifizierung mit den veralteten TLP v1.0 Labels vorsieht. Sofern Sie sich strikt daran halten, sollte die URL im Dokument https://www.first.org/tlp/v1/ lauten (dies entspricht nicht der von Secvisogram angebotenen URL).

Viele CSAF-Herausgeber bevorzugen jedoch die Klassifizierung ihrer Dokumente mit dem TLP v2.0 Label TLP:AMBER+STRICT, welches nur die Verteilung innerhalb einer Organisation erlaubt. Sie können BOMnipotent so konfigurieren , dass auch CSAF-Dokumente akzeptiert werden, die mit TLP v2.0-Labels klassifiziert sind.

Wichtige Product Tree Einträge

Der Produktbaum enthält Informationen darüber, welche Produkte von dem Advisory abgedeckt sind. Diese sind in Zweige gruppiert, die, ähnlich wie Namespaces, zur Strukturierung Ihres Produktkatalogs dienen.

Erstellen Sie am besten eine Vorlage mit allen Ihren Produkten (oder Produktfamilien, falls dies Ihren Anforderungen besser entspricht). Das Löschen irrelevanter Produkte aus einem Dokument ist in Sekundenschnelle erledigt, das Hinzufügen fehlender Produkte birgt hingegen das Risiko, einige zu vergessen.

Branches

Branches (Zweige) bestehen immer aus genau drei Feldern: einem Namen , einer Kategorie und anschließend entweder einem Produkt oder weiterer Zweige.

Diese rekursive Definition sollte mit einem allgemeinen Überblick beginnen und dann bis zu den einzelnen Releases heruntergehen. Eine sehr plausible Struktur ist die folgende:

• Ein oberster Zweig mit der Kategorie “vendor” (“Anbieter”). Der Name entspricht dem Namen Ihrer Organisation.
• Der Zweig “vendor” enthält für jedes Ihrer Produkte einen Zweig mit der Kategorie “product_name” (“Produktname”). Sollten die Produkte zu zahlreich werden, können Sie sie zusätzlich in Zweigen mit der Kategorie “product_family” (“Produktfamilie”) gruppieren.
• Jeder Zweig “product_name” enthält einen Zweig für jede “product_version” (“Produktversion”). Wichtig ist, dass der Name des Zweigs tatsächlich eine Version und nicht einen Versionsbereich darstellt. Dafür gibt es eine separate Kategorie. Wenn Sie für verschiedene Architekturen entwickeln, empfiehlt sich die Einrichtung eines Unterzweigs mit der Kategorie “architecture”.

Für welche Zweigstruktur Sie sich auch entscheiden, die untersten Zweige müssen ein Produktfeld enthalten. Dieses muss die folgenden Felder enthalten:

• Name: Ein idealerweise eindeutiger Name, der menschlichen Lesern die Identifizierung des Produkts erleichtert. Dies kann auch die Verkettung aller Zweignamen sein, die zu diesem Punkt führen.
• Produkt-ID: Die Produkt-ID dient zur Referenzierung dieses Produkts im aktuellen Dokument. Es gelten keine besonderen Anforderungen, außer dass sie im Dokument eindeutig sein muss.

Das Produkt kann einen Produktidentifizierungshelfer enthalten. Dieser ist in erster Linie relevant, um anderen Personen die Identifizierung Ihres Produkts von außerhalb des aktuellen Dokuments zu erleichtern.

Wichtige Vulnerabilities Einträge

Vulnerabilities sind Einträge, die Ihren Nutzern mitteilen, welche Produkte (nicht) von einer Sicherheitslücke betroffen sind und welche Maßnahmen ergriffen werden müssen.

Titel

Der Titel dient dazu, menschlichen Lesern zu zeigen, welche Sicherheitslücke in diesem CSAF-Dokument behandelt wird.

CVE und IDs

Diese wichtigen Felder werden von Maschinen zur Identifizierung einer Sicherheitslücke verwendet. Es gibt verschiedene Systeme zur Identifizierung von Sicherheitslücken. Das bekannteste ist die Common Vulnerabilities and Exposures (CVE) Trackingnummer. Wenn für die Sicherheitslücke eine CVE-Nummer vorhanden ist, können Sie diese in das entsprechende Feld eingeben.

Wird die Sicherheitslücke über ein anderes System verfolgt, können Sie deren ID im Feld IDs angeben. Jeder Eintrag enthält zwei Felder:

• Systemname: Dient zur Identifizierung des Tracking-Systems. Dies kann beispielsweise “GitHub Security Advisories” oder “GitHub Issue” sein. Nur “CVE” ist nicht zulässig, da CVEs über das dedizierte Feld angegeben werden.
• Text: Der tatsächliche Wert der ID, z. B. “GHSA-abcd-efgh-ijkl” oder “Weichwerke-Heidrich-Software/bomnipotent_doc#37”.

Hinweis: In Secvisogram müssen Sie die “Aktive Relevanzstufe” auf 4 setzen, um IDs eingeben zu können, die keine CVEs sind.

Notes

Jede Sicherheitslücke muss mindestens eine Notiz enthalten. Eine Notiz hat eine Kategorie und einen Inhalt. In den meisten Fällen reicht es aus, einen Hinweis mit der Kategorie “description” (“Beschreibung”) hinzuzufügen und die Beschreibung der Sicherheitslücke aus der offiziellen Quelle zu übernehmen.

Anders verhält es sich natürlich, falls die Sicherheitslücke keine offizielle Beschreibung hat, weil sie direkt aus Ihrem Produkt stammt. In diesem Fall sollten Sie eine weitere Notiz mit der Kategorie “details” hinzufügen.

Produktstatus

Die Listen mit den Produktstati können als das Herzstück des Advisorys verstanden werden. Sie sind maschinenlesbare Listen, die Informationen darüber enthalten, ob ein Produkt von einer Sicherheitslücke betroffen ist oder nicht. Es wird empfohlen, alle Ihre Product IDs (also alle Versionen aller Produkte) mindestens in die folgenden Kategorien zu sortieren:

• Known affected: Diese Versionen sind von der Sicherheitslücke betroffen.
• Fixed: Diese Versionen enthalten einen Fix und sind daher nicht von der Sicherheitslücke betroffen.
• Recommended: Dies ist die Version, die Sie zur Verwendung empfehlen. Sie sollte idealerweise auch in Ihrer Liste der behobenen Probleme aufgeführt sein.

Es kommt nicht selten vor, dass eine Sicherheitslücke in Ihrer Lieferkette Ihr Produkt nicht tatsächlich betrifft. Dies kann daran liegen, dass Ihr Produkt die anfälligen Pfade nie nutzt. In diesem Fall sollten Sie auch Einträge zu “known not affected” hinzufügen. Andernfalls werden Nutzer Ihres Produkts mit Zugriff auf Ihre SBOM möglicherweise über die Sicherheitslücke benachrichtigt und fragen nach, ob sie Maßnahmen ergreifen müssen.

Hinweis: Im Secvisogram müssen Sie die “Aktive Relevanzstufe” auf 4 setzen, um alle verfügbaren Stati anzuzeigen.

Remediations

Für jedes betroffene (oder aktuell untersuchte) Produkt müssen Sie mindestens einen Eintrag erstellen, der eine remediation (Abhilfemaßnahme) beschreibt. Der Eintrag muss Folgendes enthalten:

• eine Kategorie, zum Beispiel “mitigation”, “workaround” oder “no_fix_planned” (Risikoakzeptanz ist eine valide Strategie).
• Einzelheiten zur Anwendung der Abhilfemaßnahme oder warum keine Fehlerbehebung geplant ist.
• Ein Verweis auf mindestens eine Produkt-ID.