PSIRT: Was ein Product Security Incident Response Team tut

Was ist ein PSIRT?

Ein Product Security Incident Response Team (PSIRT) ist die Funktion, die Sicherheitslücken in den Produkten behandelt, die ein Unternehmen herstellt und verkauft. FIRST definiert es als eine Einheit, die sich darauf konzentriert, die mit Sicherheitslücken in den Produkten verbundenen Risiken zu identifizieren, zu bewerten und zu bearbeiten, einschließlich Angeboten, Lösungen, Komponenten und Diensten.

In der Praxis erledigt ein PSIRT Folgendes:

Es betreibt den Kanal, über den Forschende, Kunden und Partner Schwachstellen melden.
Es beobachtet Schwachstellen in den Komponenten von Drittanbietern und aus Open Source, die in seinen Produkten stecken.
Es sichtet jede Meldung: Ist sie echt, welche Produkte und Versionen sind betroffen, wie schwer wiegt sie?
Es sorgt dafür, dass das zuständige Entwicklungsteam sie behebt, nach einem Zeitplan, der zum Risiko passt.
Es veröffentlicht Advisories und koordiniert die Offenlegung mit Findern und nachgelagerten Anbietern.
Es berichtet Metriken an die Führungsebene und schult die Menschen, die die Produkte bauen.

Der größte Teil der Arbeit fällt nach dem Release an. FIRST merkt an, dass die meisten Produktschwachstellen als Qualitätsmängel gemeldet werden, sobald ein Produkt auf dem Markt ist. Ein PSIRT bringt aber auch früher Nutzen, bei Design-Reviews und im Threat Modeling.

Wo ein PSIRT in der Organisation angesiedelt ist

Der Unterschied zu anderen Sicherheitsteams ist der Fokus auf Produkte. Ein Enterprise-CSIRT schützt die eigenen Systeme und Netzwerke des Unternehmens; ein PSIRT schützt die Kunden, die die Produkte des Unternehmens betreiben. Beide teilen Fähigkeiten und oft eine Berichtslinie, und sie treffen aufeinander, wenn ein Vorfall in der eigenen Infrastruktur, etwa ein kompromittiertes Build-System, ein Produkt erreicht. Der vollständige Vergleich steht unter PSIRT vs. CSIRT.

FIRST beschreibt drei Betriebsmodelle:

Verteilt: Ein kleines Kern-PSIRT legt die Richtlinien fest und koordiniert, und Sicherheitsverantwortliche in jedem Produktteam übernehmen Triage und Fixes. Das skaliert über ein großes, vielfältiges Portfolio, aber die Menschen, die die Arbeit machen, berichten nicht an das PSIRT.
Zentralisiert: Ein größeres PSIRT mit eigenem Programmmanagement, eigenen Leuten für Triage und Behebung, das an eine Führungskraft für Produktsicherheit berichtet. Es passt zu kleineren Unternehmen oder einem einheitlichen Portfolio und wird teurer, wenn das Portfolio wächst.
Hybrid: Eine Mischung aus beidem, gewählt nach Unternehmensgröße, Portfolio und Entwicklungsstrategie.

Unabhängig vom Modell betont FIRST die Unabhängigkeit: Das PSIRT sollte an eine Führungskraft berichten, die seine Befugnisse bestätigt, damit es zu Schwachstellen in den eigenen Produkten des Unternehmens objektiv Stellung nehmen kann.

Das FIRST PSIRT Services Framework

Das PSIRT Services Framework, von FIRST kostenlos veröffentlicht und inzwischen in Version 1.1, ist die Referenz, auf der die meisten PSIRTs ihren Servicekatalog aufbauen. Es legt operative Grundlagen fest (Mandat, Stakeholder, Budget, Richtlinien) und danach sechs Servicebereiche:

Servicebereich	Was er abdeckt
1. Management des Stakeholder-Ökosystems	Interne Stakeholder, die Finder-Community, nachgelagerte Anbieter und Kunden, Vorfallskommunikation, Anerkennung von Findern, Stakeholder-Metriken
2. Entdeckung von Schwachstellen	Annahme von Schwachstellenmeldungen, Auffinden nicht gemeldeter Schwachstellen, Überwachung von Produktkomponenten auf Schwachstellen, Identifizierung neuer Schwachstellen, Entdeckungsmetriken
3. Triage und Analyse von Schwachstellen	Qualifizierung von Meldungen, Zusammenarbeit mit bekannten Findern, Reproduktion von Schwachstellen
4. Behebung	Release-Plan für die Abhilfe, Behebung, Vorfallsbehandlung, Release-Metriken
5. Offenlegung von Schwachstellen	Benachrichtigung, Koordination, Offenlegung über Advisories, Offenlegungsmetriken
6. Schulung und Ausbildung	Schulung des PSIRT, der Entwicklungs- und Validierungsteams und weiterer Stakeholder; Feedback-Mechanismen

Ein Service verdient besondere Beachtung, weil er einen großen Teil der Arbeit ausmacht: die Überwachung von Schwachstellen in Produktkomponenten. Seine erste Funktion ist ein Inventar der Produktkomponenten, eine Liste der Anbieter, Produkte und Versionen in jedem Produkt. Laut FIRST ist es unverzichtbar, um bei geerbten Schwachstellen die betroffenen Produkte schnell zu identifizieren. In moderner Software ist dieses Inventar eine Software-Stückliste (SBOM).

Der PSIRT-Prozess im Überblick

Zwei ISO/IEC-Normen beschreiben den Prozess. ISO/IEC 30111:2019 behandelt, wie ein Anbieter Schwachstellen intern bearbeitet. ISO/IEC 29147:2018 behandelt, wie er Meldungen von außen entgegennimmt und Informationen zur Behebung veröffentlicht. 30111 ist für die Verwendung zusammen mit 29147 gedacht, und die beschriebenen Phasen ergeben eine nützliche Gliederung:

Vorbereitung. Richtlinie, Rollen, ein veröffentlichter Weg zum Melden von Schwachstellen, eine Bewertungsmethode, ein Inventar dessen, was ausgeliefert wird.
Eingang. Nehmen Sie Meldungen von Forschenden, Kunden, Partnern und aus Ihren eigenen Tests entgegen, ebenso aus Advisories für Komponenten, die Sie nutzen. Bestätigen Sie dem Finder den Eingang.
Verifizierung. Bestätigen Sie die Schwachstelle, reproduzieren und bewerten Sie sie und ermitteln Sie jedes betroffene Produkt und jede Version. Halten Sie auch nicht betroffene Produkte fest und warum.
Entwicklung der Behebung. Das zuständige Team baut und testet einen Fix oder eine Abhilfe. Das PSIRT verfolgt den Fortschritt gegen den vereinbarten Zeitplan.
Release. Liefern Sie den Fix aus und veröffentlichen Sie das Advisory, abgestimmt mit dem Finder und mit nachgelagerten Anbietern, die Ihr Produkt einbetten.
Nach dem Release. Achten Sie auf Probleme mit dem Fix, beantworten Sie Kundenfragen und melden Sie Ursachen an die Entwicklung zurück.

Jede Phase, mit dem, was festzuhalten ist und wer zuständig ist, behandelt der Lebenszyklus des Schwachstellenmanagements. Welche Befunde zuerst kommen, klärt die Schwachstellenpriorisierung, mit Ausnutzungssignalen aus EPSS und dem CISA-KEV-Katalog. Eine Schwachstelle, die ausgenutzt wird, bevor es einen Fix gibt, ist ein Zero-Day, und das PSIRT behandelt sie als Vorfall. Den Weg vom Advisory zum behobenen, ausgelieferten Build beschreibt CVE-Behebung.

Offenlegung und Advisories

Die Offenlegung ist der Teil des PSIRT, den Kunden sehen. Üblich ist die koordinierte Offenlegung von Schwachstellen: Der Finder meldet privat, der Anbieter behebt, und beide veröffentlichen an einem vereinbarten Datum, wobei der Finder genannt wird. Am Anfang steht eine öffentliche Richtlinie zur Offenlegung von Schwachstellen, die sagt, wie man meldet, was Finder erwarten können und wie lange Produkte unterstützt werden. Siehe koordinierte Offenlegung von Schwachstellen.

Ein gutes Advisory sagt einem Kunden ohne Telefonat:

welche Produkte und Versionen betroffen sind und welche nicht;
die CVE-ID und einen Schweregrad;
die behobene Version oder eine Abhilfe, falls es noch keinen Fix gibt;
wer sie gefunden hat.

Große Kunden wollen Advisories immer häufiger in maschinenlesbarer Form, die sie automatisch mit ihrem eigenen Asset-Inventar abgleichen können. CSAF ist das OASIS-Standardformat für Advisories, und mit VEX lässt sich angeben, dass ein Produkt von einer Schwachstelle in einer seiner Komponenten nicht betroffen ist, was beiden Seiten ein Ticket erspart.

PSIRT-Metriken und Reifegrad

Das Framework sieht in jedem Servicebereich Metriken vor. Gängige Metriken:

Zeit bis zur Bestätigung einer Meldung, bis zur Triage und bis zum Release eines Fixes, nach Schweregrad;
offene Schwachstellen nach Produkt, Schweregrad und Alter;
Anteil der Fixes, die innerhalb der veröffentlichten Behebungsziele geliefert wurden;
intern gefundene gegenüber von außen gemeldeten Schwachstellen;
veröffentlichte Advisories und Korrekturen an Advisories.

Das begleitende PSIRT Maturity Document von FIRST ordnet die Services in drei Stufen:

Stufe 1, Basis: Unterstützung durch die Führungsebene, Stakeholder, Budget und Richtlinien; ein Weg zum Empfang von Meldungen; ein Triage-Workflow; dokumentierte Fixes; Advisories, die CVE und CVSS nutzen und den Finder nennen.
Stufe 2, Mittel: eine Charta und ein Organisationsmodell, Basismetriken, ein Produktregister mit Abhängigkeitszuordnung, ein formaler Abhilfeplan, ein System zur Benachrichtigung von Stakeholdern und Schulungen für das Team.
Stufe 3, Fortgeschritten: direkter Austausch mit der Finder-Community, Überwachung von Produktkomponenten auf Schwachstellen, Entdeckungs- und Release-Metriken, fortgeschrittene Vorfallsbehandlung und Playbooks für die Koordination in der Branche.

Die Entwicklung zwischen den Stufen führt von reaktiv zu proaktiv.

Wie Sie ein PSIRT aufbauen: klein anfangen

Holen Sie sich ein schriftliches Mandat von einer Führungskraft, mit der Befugnis, Produktteams um Fixes zu bitten.
Veröffentlichen Sie, wie man eine Schwachstelle meldet: eine Sicherheitskontaktadresse, ein Webformular oder eine security.txt-Datei sowie eine kurze Offenlegungsrichtlinie.
Legen Sie Triage und Bewertung fest: wer entscheidet, ob eine Meldung gültig ist, wie der Schweregrad bewertet wird und welche Behebungsziele pro Schweregrad gelten.
Wissen Sie, was Sie ausliefern. Für jede Produktversion die enthaltenen Komponenten und Versionen. Ohne das wird jede neue CVE in einer beliebten Bibliothek zu tagelangem Nachfragen bei den Entwicklungsteams.
Benennen Sie pro Produkt einen Verantwortlichen, der Befunde erhält und Fixes einplant.
Schreiben Sie eine Advisory-Vorlage und veröffentlichen Sie das erste Advisory, auch für ein kleines Problem.
Messen Sie von Anfang an einige Durchlaufzeiten, damit Sie Verbesserungen zeigen können.

Die Seite für PSIRT-Teams betrachtet die Rolle aus Sicht der Leitung für Produktsicherheit, und Anbieter im Industriebereich können diese Schritte auf IEC 62443-4-1 abbilden, dessen Anforderungen an den sicheren Entwicklungslebenszyklus auch Fehler- und Patch-Management umfassen.

Regulierung, die ein PSIRT erwartet

Ein PSIRT galt früher als Kennzeichen eines reifen Anbieters. Heute verlangen mehrere Regelwerke seine Ergebnisse. NIS2 Artikel 21 Absatz 2 Buchstabe e nennt den Umgang mit Schwachstellen und ihre Offenlegung unter den Maßnahmen, die wesentliche und wichtige Einrichtungen ergreifen müssen. In den USA verlangt Section 524B von Medizinprodukteherstellern einen Plan, um Schwachstellen nach dem Inverkehrbringen zu überwachen, zu identifizieren und zu beheben, einschließlich koordinierter Offenlegung, zusammen mit einer SBOM. Und der EU Cyber Resilience Act verpflichtet Hersteller, aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle den Behörden zu melden, beginnend mit einer Frühwarnung innerhalb von 24 Stunden; siehe Was ist der CRA.

Die Tools, die ein PSIRT braucht

Bedarf	Warum
Meldungsannahme und Fallverfolgung	Jede Meldung erhält einen Verantwortlichen, einen Status und einen Zeitplan
Inventar dessen, was ausgeliefert wird	Eine genaue SBOM pro Produktversion, einschließlich transitiver Abhängigkeiten
Kontinuierliche Überwachung	Neue CVEs werden mit den Komponenten jeder veröffentlichten Version abgeglichen, nicht nur der nächsten
Triage und Weiterleitung	Befunde gehen an das Team, das für den Fix zuständig ist, mit dem Kontext zum Handeln
Aussagen zu betroffen und nicht betroffen	VEX hält fest, welche Produkte eine Schwachstelle betrifft und warum die anderen nicht betroffen sind
Veröffentlichung von Advisories	Für Menschen lesbare Advisories und maschinenlesbares CSAF für große Kunden

Wenige Produkte decken jede Zeile ab; PSIRT-Tools im Vergleich zeigt, welches Tool was leistet. Mit dem Inventar tun sich die meisten PSIRTs schwer. Ein Scanner, der Lockfiles nachträglich liest, listet Entwicklungsabhängigkeiten auf, die nie ausgeliefert werden, und übersieht Pakete, die der Build außerhalb des Paketmanagers heruntergeladen hat. Die Antwort auf „Sind wir betroffen?“ beginnt also mit Zweifeln.

CRACI bezieht dieses Inventar aus dem Build selbst. Es führt GitHub-Actions-Builds auf eigenen Runnern aus und zeichnet die Pakete auf, die jeder Job tatsächlich geladen hat, einschließlich transitiver Abhängigkeiten, aus CI-Caches wiederhergestellter Pakete und Abhängigkeiten, die in keinem Lockfile stehen. Jede SBOM trägt einen Vollständigkeitsstatus und lässt sich als CycloneDX oder SPDX exportieren. Überwachte SBOMs werden laufend neu bewertet, sobald neue Schwachstellen veröffentlicht werden, die Build-Historie zeigt, welche früheren Builds eine verwundbare Abhängigkeit enthielten, und die Inventaransicht zeigt, welche Softwareversionen in welchen Produkten im Einsatz sind. Sicherheitsteams sichten Befunde und leiten sie an die Teams weiter, die für den Fix zuständig sind, und CRACI unterstützt VEX. Siehe Schwachstellenverfolgung und CRACI für PSIRT-Teams.

PSIRT: häufig gestellte Fragen

Wofür steht PSIRT?

PSIRT steht für Product Security Incident Response Team. FIRST definiert es als eine Einheit innerhalb einer Organisation, die sich darauf konzentriert, die Risiken zu identifizieren, zu bewerten und zu bearbeiten, die mit Sicherheitslücken in den Produkten, Angeboten, Lösungen, Komponenten und Diensten verbunden sind, die die Organisation herstellt oder verkauft.

Was ist der Unterschied zwischen einem PSIRT und einem CSIRT?

Ein PSIRT behandelt Schwachstellen in den Produkten, die ein Unternehmen an Kunden ausliefert. Ein Enterprise-CSIRT behandelt Sicherheitsvorfälle in den eigenen Systemen und Netzwerken des Unternehmens. Beide arbeiten zusammen, etwa wenn ein Einbruch in die Build-Infrastruktur ein Produkt betrifft. Siehe PSIRT vs. CSIRT.

Was ist das FIRST PSIRT Services Framework?

Ein kostenloser Leitfaden von FIRST, dem Forum of Incident Response and Security Teams, der die Services auflistet, die ein PSIRT erbringen kann. Version 1.1 gliedert sie in sechs Servicebereiche: Management des Stakeholder-Ökosystems, Entdeckung von Schwachstellen, Triage und Analyse von Schwachstellen, Behebung, Offenlegung von Schwachstellen sowie Schulung und Ausbildung. Ein begleitendes Dokument zum Reifegrad ordnet die Services in drei Stufen.

Welche Normen beschreiben den PSIRT-Prozess?

ISO/IEC 30111:2019 behandelt, wie ein Anbieter Schwachstellenmeldungen intern bearbeitet, von Vorbereitung und Eingang über Verifizierung, Entwicklung der Behebung und Release bis zur Phase nach dem Release. ISO/IEC 29147:2018 behandelt die Schnittstelle nach außen: das Entgegennehmen von Meldungen und das Veröffentlichen von Informationen zur Behebung. 30111 ist für die Verwendung zusammen mit 29147 gedacht. IEC 62443-4-1 legt Anforderungen an den sicheren Entwicklungslebenszyklus fest, einschließlich Fehler- und Patch-Management, für Produkte der industriellen Automatisierung.

Braucht ein kleines Unternehmen ein PSIRT?

Es braucht die Funktion, nicht unbedingt eine Abteilung. Das Reifegraddokument von FIRST beginnt mit Unterstützung durch die Führungsebene, benannten Stakeholdern, einem Budget, einigen Richtlinien, einem veröffentlichten Weg zum Melden von Schwachstellen, einem Triage-Workflow, dokumentierten Fixes und Advisories, die den Finder nennen. Das können ein oder zwei Personen mit schriftlichem Mandat leisten.

Welche Tools braucht ein PSIRT?

Mindestens: einen Weg zum Empfang von Meldungen, einen Fall-Tracker, eine Methode zur Bewertung von Schwachstellen, ein Inventar darüber, welche Komponenten in welchen Produktversionen ausgeliefert werden, eine Überwachung dieser Komponenten auf neue Schwachstellen, einen Weg, um für jedes Produkt festzuhalten, ob es betroffen ist (oft als VEX), und einen Weg zur Veröffentlichung von Advisories, zunehmend in CSAF.

PSIRT: was ein Product Security Incident Response Team tut