CRA-PSIRT aufbauen: Rollen, Prozesse und Eskalation für Produktsicherheit

Ein Product Security Incident Response Team (PSIRT) bündelt die Verantwortung für Schwachstellen, Security Advisories, Meldepflichten und Produkt-Sicherheitsvorfälle. Der CRA schreibt nicht vor, dass jedes Unternehmen eine Abteilung mit dem Namen „PSIRT“ gründen muss. Er verlangt aber Prozesse, Zuständigkeiten und Nachweise, die sich mit einer klaren PSIRT-Funktion sehr gut organisieren lassen.

Einordnung im CRA-Wissen: Dieser Fachartikel gehört zum Themenbereich Schwachstellen & Meldeprozesse. Dort finden Sie die angrenzenden Anforderungen und eine praktische Reihenfolge für die Umsetzung.

Was ist ein PSIRT?

Ein PSIRT ist die zentrale organisatorische Funktion für Produktsicherheit nach der Auslieferung. Es nimmt Schwachstellenmeldungen entgegen, koordiniert technische Bewertung und Behebung, bereitet Security Advisories vor und steuert bei Bedarf gesetzliche Meldungen.

Anders als ein klassisches IT-Security-Team konzentriert sich ein PSIRT auf die Produkte, die ein Unternehmen entwickelt und auf den Markt bringt. Das interne SOC schützt die eigene Infrastruktur; das PSIRT kümmert sich um Sicherheitsprobleme in den ausgelieferten Produkten.

Verlangt der CRA ausdrücklich ein PSIRT?

Nein, der Begriff PSIRT ist keine formale Pflichtbezeichnung im CRA. Die Verordnung verlangt jedoch wirksame Prozesse zur Behandlung von Schwachstellen, koordinierte Offenlegung, sichere Updates und gesetzliche Meldungen. Diese Aufgaben brauchen verantwortliche Personen und klare Entscheidungswege.

Ein Hersteller kann die Funktion deshalb anders benennen. Entscheidend ist, dass die Verantwortlichkeiten praktisch funktionieren und nicht zwischen Support, Entwicklung, Compliance und Management verloren gehen.

Welche Aufgaben sollte die PSIRT-Funktion übernehmen?

Die PSIRT-Funktion verbindet externe Signale mit internen Teams. Typische Aufgaben reichen vom Eingang einer Meldung bis zum Abschluss eines Security Releases.

Wer sollte im PSIRT vertreten sein?

Die Kernfunktion braucht technisches Verständnis und Entscheidungsfähigkeit. Typisch sind Product Security, Entwicklung, Produktmanagement, Support und Compliance. Bei kritischen Fällen kommen Management, Legal und Kommunikation hinzu.

In kleinen Unternehmen kann eine Person mehrere Rollen übernehmen. Wichtig ist dann eine Vertretungsregel. Ein gesetzlich relevanter Fall darf nicht liegen bleiben, weil die einzige zuständige Person im Urlaub ist.

Welche Entscheidungskompetenz braucht das PSIRT?

Das PSIRT sollte nicht nur Informationen sammeln, sondern definierte Entscheidungen auslösen können. Dazu gehören Priorisierung, Eskalation, Sperrung eines Releases, Einleitung eines Security Updates und Start des CRA-Meldeprozesses.

Für besonders weitreichende Entscheidungen kann eine Management-Freigabe erforderlich sein. Diese Schwelle sollte vorher definiert sein. Unter Zeitdruck ist es zu spät, erst herauszufinden, wer einen dringenden Patch freigeben darf.

Wie nimmt das PSIRT externe Meldungen entgegen?

Ein öffentlicher Security-Kontakt und eine klare CVD-Struktur helfen externen Forschern und Kunden, Schwachstellen an die richtige Stelle zu melden. Der Eingang sollte automatisch oder manuell bestätigt und in ein nachvollziehbares Fallsystem überführt werden.

Die Meldung braucht mindestens Produkt, Version, Beschreibung, Reproduktionsinformationen und Kontaktdaten des Meldenden, soweit verfügbar. Danach beginnt die interne Triage.

Wie arbeitet das PSIRT mit der Entwicklung zusammen?

Die Entwicklung liefert technische Analyse und Fix. Das PSIRT sorgt dafür, dass das Problem nicht nur als normales Bugticket behandelt wird. Es setzt Priorität, koordiniert Vertraulichkeit und hält den Bezug zu Nutzern, Meldepflichten und Supportzeitraum.

Eine gute Arbeitsweise trennt die Security-Fallakte vom normalen Entwicklungsbacklog, verbindet beide aber über Referenzen. So bleiben technische Details für Entwickler zugänglich, während regulatorische Nachweise vollständig bleiben.

Wie bindet man SBOM und Komponentenmanagement ein?

Bei Schwachstellen in Drittkomponenten muss das PSIRT schnell wissen, welche Produktversionen betroffen sind. Eine gepflegte SBOM ist deshalb eines der wichtigsten Arbeitsmittel.

Im Idealfall kann das Team von einer Komponentenmeldung direkt zu betroffenen Builds, Produkten und Supportversionen springen. Ohne diese Verbindung wird jede neue CVE zu einer manuellen Recherche.

Wann löst das PSIRT eine CRA-Meldung aus?

Wenn eine aktiv ausgenutzte Schwachstelle oder ein schwerer Sicherheitsvorfall die Voraussetzungen des CRA erfüllt, muss der gesetzliche Reporting-Prozess gestartet werden. Die zentrale Frage ist deshalb nicht nur „wie kritisch ist der Bug?“, sondern auch „liegt aktive Ausnutzung oder ein meldepflichtiger Vorfall vor?“

Der PSIRT-Prozess sollte einen festen Übergabepunkt zu den 24h-/72h-Meldepflichten enthalten. So wird vermieden, dass technische Teams einen Patch entwickeln, während die gesetzliche Frist unbemerkt läuft.

Welche Werkzeuge braucht ein PSIRT?

Es gibt kein vorgeschriebenes Tool. Für den Start reichen ein geschütztes Ticketsystem, Produktinventar, SBOM, Kontaktlisten und Vorlagen für Bewertung, Advisory und Meldung. Entscheidend sind Zugriffsrechte und Nachvollziehbarkeit.

Sensible Schwachstellendetails sollten nicht in allgemein zugänglichen Projektboards landen. Der Zugriff muss auf die Personen beschränkt sein, die ihn tatsächlich benötigen.

Wie sollte ein Security Advisory aufgebaut sein?

Ein Advisory beschreibt verständlich, welches Produkt und welche Version betroffen sind, welche Auswirkungen bestehen und welche Maßnahme Nutzer ergreifen sollen. Es sollte zwischen bestätigten Fakten und noch unsicheren Annahmen unterscheiden.

Technische Tiefe hängt von Zielgruppe und Risiko ab. Wichtig ist, dass Nutzer nicht nur „Update verfügbar“ lesen, sondern erkennen, warum das Update relevant ist und ob temporäre Schutzmaßnahmen notwendig sind.

Wie misst man die Leistungsfähigkeit des PSIRT?

Hilfreiche Kennzahlen sind Zeit bis zur Eingangsbestätigung, Zeit bis zur Betroffenheitsanalyse, offene kritische Fälle, Zeit bis zum Patch, Anteil fristgerecht behandelter Fälle und Zahl verspäteter Nutzerinformationen.

Auch qualitative Reviews sind wichtig. Nach kritischen Fällen sollte das Team prüfen, welche Informationen gefehlt haben und ob Rollen oder Systeme angepasst werden müssen.

Wie sieht eine Minimalbesetzung für ein KMU aus?

Ein kleines Unternehmen kann mit drei benannten Funktionen starten: PSIRT-Owner, technischer Ansprechpartner und Management-/Compliance-Eskalation. Dazu kommen Vertretungen. Der PSIRT-Owner überwacht den Security-Kontakt und steuert den Prozess.

Die technische Person bewertet Betroffenheit und koordiniert Fixes. Management oder Compliance entscheidet bei gesetzlichen Meldungen und weitreichenden Kommunikationsmaßnahmen. Diese Struktur kann in bestehenden Rollen verankert werden.

Welche Fehler machen Unternehmen beim PSIRT-Aufbau?

• PSIRT wird als neue Bezeichnung eingeführt, ohne Entscheidungsbefugnisse zu ändern.
• Nur Security kennt den Prozess; Support und Entwicklung nicht.
• Es gibt keine Vertretung.
• Produktversionen und SBOM sind nicht verfügbar.
• CRA-Meldepflichten sind vom technischen Incident-Prozess getrennt.
• Advisories werden erst nach Veröffentlichung des Patches geplant.

Wie testet man das PSIRT vor einem echten Vorfall?

Ein Tabletop-Test sollte einen realistischen Produktfall simulieren: externe Meldung, betroffene Bibliothek, mehrere Releases, möglicher Exploit und Zeitdruck. Das Team bearbeitet den Fall wie einen echten Incident.

Danach wird geprüft, ob Ansprechpartner, Entscheidungen, Informationen und Kommunikationswege funktioniert haben. Das CRA Incident & Reporting Paket kann als strukturierte Arbeitsgrundlage für einen solchen Test dienen.

Wo liegen die rechtlichen Anknüpfungspunkte?

Die PSIRT-Funktion unterstützt vor allem die Herstellerpflichten aus Artikel 13, die Meldepflichten aus Artikel 14 und die Vulnerability-Handling-Anforderungen in Anhang I Teil II der Verordnung (EU) 2024/2847. Der CRA schreibt die Organisationsbezeichnung nicht vor, wohl aber funktionierende Prozesse.

Wie unterscheidet sich PSIRT von CERT und CSIRT?

Ein CERT oder CSIRT bearbeitet typischerweise Sicherheitsvorfälle in einer Organisation oder einem definierten Zuständigkeitsbereich. Ein PSIRT fokussiert dagegen auf die Sicherheit der eigenen Produkte und ihrer Nutzer. In kleinen Unternehmen können dieselben Personen beide Funktionen wahrnehmen, die Aufgaben sollten aber getrennt gedacht werden.

Diese Trennung ist für den CRA hilfreich: Ein Angriff auf den internen Mailserver ist nicht automatisch ein CRA-Produktvorfall. Eine aktiv ausgenutzte Schwachstelle in einer ausgelieferten Firmware kann dagegen CRA-relevant sein, auch wenn das eigene Unternehmensnetz nicht betroffen ist.

Welche Informationen braucht das PSIRT aus dem Produktmanagement?

Das PSIRT muss wissen, welche Produktversionen im Markt sind, welche Kunden oder Vertriebskanäle betroffen sein können, wie lange Support zugesagt ist und welche Funktionen sicherheitskritisch sind. Ohne diese Informationen bleibt die technische Analyse abstrakt.

Produktmanagement sollte deshalb Produktinventar, Releasekalender und Supportstatus mit dem PSIRT teilen. Bei einer kritischen Schwachstelle muss nicht erst recherchiert werden, ob Version 3.2 noch verkauft oder unterstützt wird.

Wie organisiert man Bereitschaft ohne 24/7-Security-Team?

Der CRA verlangt nicht pauschal eine rund um die Uhr besetzte Hotline. Unternehmen brauchen aber einen Prozess, der kritische Meldungen rechtzeitig erkennt – besonders mit Blick auf kurze gesetzliche Meldefristen ab Kenntnis.

KMU können dafür technische Alarmierung, Rufbereitschaft für wenige definierte Rollen oder einen externen Dienstleister nutzen. Entscheidend ist eine realistische Lösung, die zu Risiko und Produktportfolio passt und im Ernstfall tatsächlich funktioniert.

Was gehört in eine PSIRT-Rollenmatrix?

Für jede Kernaufgabe sollte feststehen, wer ausführend, entscheidend, beratend und zu informieren ist. Besonders wichtig sind Triage, Einstufung aktiver Ausnutzung, Freigabe eines Security Updates, Veröffentlichung eines Advisories und behördliche Meldung.

Die CRA Rollen- & Verantwortlichkeitsmatrix kann dafür als Ausgangspunkt dienen. Entscheidend ist, dass die Matrix mit echten Namen oder Funktionen gefüllt und bei Personalwechsel aktualisiert wird.

Wie geht das PSIRT mit vertraulichen Informationen um?

Unveröffentlichte Schwachstellendetails, Exploit-Code und Kundendaten gehören nicht in allgemein zugängliche Systeme. Das PSIRT braucht abgestufte Zugriffsrechte und klare Regeln für Weitergabe an Entwicklung, Zulieferer und externe Partner.

Vertraulichkeit darf den Prozess aber nicht blockieren. Wenn nur eine Person Zugriff hat, entstehen Abhängigkeiten. Besser sind definierte Rollen, Vertretungen und sichere Kommunikationskanäle.

Wie werden Lieferanten und Open-Source-Maintainer eingebunden?

Liegt die Ursache in einer Drittkomponente, koordiniert das PSIRT die Kommunikation mit Lieferant oder Maintainer. Es prüft, ob bereits ein Fix existiert, welche Versionen betroffen sind und welche Informationen zurückgegeben werden müssen.

Der eigene Hersteller bleibt für das integrierte Produkt verantwortlich. Deshalb verfolgt das PSIRT die Behebung weiter, auch wenn ein externer Maintainer beteiligt ist. Der geplante Artikel zu Drittkomponenten vertieft diese Lieferkettenpflicht.

Was gehört in ein PSIRT-Handbuch?

Ein kompaktes Handbuch sollte Kontaktwege, Rollen, Prioritätsregeln, Triage-Fragen, Reporting-Trigger, Freigaben, Advisory-Vorlage, Update-Prozess und Abschlusskriterien enthalten. Es muss keine hundert Seiten lang sein.

Wichtiger ist, dass neue Teammitglieder einen Fall damit bearbeiten können. Ein gutes Handbuch wird nach Übungen und echten Vorfällen aktualisiert und verweist auf die tatsächlichen Werkzeuge und Ansprechpartner.

Wie sollte die Übergabe zwischen PSIRT und Management funktionieren?

Nicht jeder Fall braucht die Geschäftsführung. Für kritische Sicherheitsprobleme muss aber definiert sein, ab welcher Schwelle Management einbezogen wird – etwa bei aktiver Ausnutzung, erheblicher Kundenwirkung, Rückrufrisiko oder gesetzlicher Meldung.

Die Eskalation sollte eine kurze Entscheidungsvorlage liefern: betroffene Produkte, technisches Risiko, Nutzerwirkung, geplante Maßnahme, Fristen und offene Entscheidungen. So kann Management schnell handeln, ohne erst Rohdaten aus mehreren Systemen zusammenzutragen.

Wie arbeitet PSIRT mit Kommunikation und Vertrieb zusammen?

Vertrieb und Kommunikation brauchen bei größeren Fällen klare, freigegebene Aussagen. Sie sollten weder technische Details erfinden noch die Bedeutung einer Schwachstelle verharmlosen. Das PSIRT liefert deshalb einen abgestimmten Kerntext und definiert, welche Fragen an Security zurückgehen.

Besonders bei Geschäftskunden können Account Manager wichtige Rückmeldungen zum Rollout liefern. Diese Rückmeldungen gehören in die Fallakte, damit sichtbar bleibt, ob Kunden das Update tatsächlich umsetzen können.

Wie verhindert man, dass PSIRT nur reaktiv arbeitet?

Eine reife PSIRT-Funktion analysiert wiederkehrende Ursachen und gibt Erkenntnisse zurück an Entwicklung und Produktmanagement. Häufen sich beispielsweise Fehler in Authentisierung, Update-Signierung oder Drittkomponenten, sollte daraus eine präventive Engineering-Maßnahme entstehen.

Damit wird PSIRT Teil eines geschlossenen Produkt-Sicherheitskreislaufs: Vorfälle liefern Erkenntnisse, diese verändern Anforderungen und Tests, und neue Produktversionen werden robuster. Genau dieser Rückkopplungseffekt passt zum risikobasierten Ansatz des CRA.

Wie oft sollte die PSIRT-Struktur überprüft werden?

Mindestens jährlich sowie nach größeren Produkt-, Personal- oder Prozessänderungen sollte geprüft werden, ob Kontakte, Vertretungen, Eskalationsschwellen und Vorlagen noch stimmen. Auch ein realer Security-Fall ist ein guter Anlass für ein Review.

Die Aktualisierung sollte dokumentiert werden. So kann der Hersteller später zeigen, dass die PSIRT-Funktion nicht nur einmal entworfen, sondern laufend gepflegt wurde.