Was ist ein PSIRT?

Am 7. Juni 2024 veröffentlichte der CERT-Bund eine Warnung vor der Schwachstelle WID-SEC-2024-131 in Microsoft Azure. Die Ursache war ein fehlerhaft konfigurierter SAS-Token (Shared Access Signatures), mit dem Angreifer Zugriff auf eigentlich geschützte Ressourcen erhalten konnten, und das ohne Authentifizierung. Diese Schwachstelle wurde mit einem CVSS-Score von 10.0 bewertet, der höchstmöglichen Risikostufe. Betroffen waren nicht nur Azure-Dienste selbst, sondern auch Produkte und Plattformen, die darauf aufbauen.

Solche Fälle sind kein Einzelfall und der Trend zeigt, es wird zukünftig eher mehr als weniger Securityvorfälle geben. Sicherheitslücken in Produktkomponenten egal ob selbst entwickelt oder von Dritten eingebunden, werden heute nicht nur schneller gefunden, sondern auch aggressiver und gezielter ausgenutzt. Die betroffenen Unternehmen stehen unter enormem Druck. Die Kunden erwarten sofortige Informationen, Behörden fordern Meldungen innerhalb definierter Fristen, und ein Reputationsverlust droht mit jedem Tag Verzögerung.

Wer in so einer Situation schnell, strukturiert und transparent reagieren kann, hat ein funktionierendes Product Security Incident Response Team (PSIRT). Dieses Team ist dafür da, Schwachstellen in Produkten systematisch zu behandeln. Gleichzeitig kann damit das Schadensausmaß reduziert und die Zeit zur Wiederherstellung der Prozesse und IT-Systeme beschleunigt werden.

Was ist ein PSIRT?

Ein PSIRT ist das Sicherheitsreaktionsteam speziell für deine Produkt- und Systemlandschaft, dazu gehören in der Regel angebotene Produkte wie Embedded-Geräte, SaaS-Plattformen oder mobile Apps, aber auch unternehmenseigene OT-Systeme, wenn diese produktähnlich betrieben werden.

Gerade in der Industrie spielt Produktsicherheit nicht nur in Richtung Kunde eine Rolle, sondern auch im eigenen Betrieb, z. B. bei Steuerungsanlagen, Maschinensteuerungen oder Produktionsnetzwerken. Ein PSIRT ist deshalb auch dann zuständig, wenn interne Komponenten Schwachstellen aufweisen, die sich wie ein Produkt verhalten, weil sie beispielsweise zentral betrieben, gewartet und über Lifecycle-Prozesse gepflegt werden.

Während ein CSIRT IT-Vorfälle wie Ransomware oder Phishing bearbeitet, konzentriert sich das PSIRT auf Schwachstellen in Code, Systemarchitektur oder Komponenten, die du selbst entwickelst oder integrierst.

Ein PSIRT ist also keine rein technische Einheit, sondern eine organisationsübergreifende Funktion. Es bringt Security, Entwicklung, Qualitätssicherung, Recht und Kommunikation an einen Tisch, um in sicherheitsrelevanten Vorfällen gemeinsam zu handeln und das unter Zeitdruck und unter vielen wachsamen Augen.

PSIRT, CSIRT oder SOC?

Du hast schon ein CSIRT oder ein Security Operations Center (SOC) und fragst dich, ob das reicht? Die Rollen unterscheiden sich deutlicher, als es auf den ersten Blick wirkt.

Ein SOC ist dein Frühwarnsystem. Es überwacht kontinuierlich Logs und Ereignisse, erkennt Muster, schlägt bei Anomalien Alarm und reagiert operativ auf Angriffe in Echtzeit. Ein SOC nutzt dafür auch externe Medien und verfolgt das Weltgeschehen. Typische Beispiele, welche innerhalb eines SOCs bearbeitet werden: Auffällige Login-Versuche, verdächtiger Netzwerkverkehr oder Angriffe auf das Active Directory.

Ein CSIRT reagiert auf konkrete Vorfälle in deiner IT, beispielsweise auf einen erfolgreichen Phishing-Angriff, Datenabfluss oder kompromittierte Endgeräte. Es dokumentiert den Vorfall, analysiert den Ablauf, koordiniert Sofortmaßnahmen und sichert Spuren.

Ein PSIRT hingegen wird aktiv, wenn die Sicherheit deiner Produkte oder produktähnlichen Systeme gefährdet ist – egal ob sie an Kunden ausgeliefert oder im eigenen Betrieb genutzt werden. Das kann eine Schwachstelle in eurer Firmware sein, ein Exploit gegen das Web-Frontend einer Edge-Appliance oder eine kritische Sicherheitslücke in einer Drittanbieter-Bibliothek wie log4j oder zlib, die in einer OT-Komponente eingesetzt wird.

Auch Systeme wie selbst entwickelte Steuerungssoftware, konfigurierte SPS-Komponenten oder interne Plattformen zur Maschinensteuerung fallen in den Zuständigkeitsbereich des PSIRTs, sofern sie sicherheitskritisch sind und wie ein Produkt betrieben werden.

Die Zusammenarbeit dieser Teams ist wichtig, ihre Aufgaben und Perspektiven, aber grundverschieden. Das PSIRT denkt vom Produkt und vom Kunden her und nicht von der Infrastruktur.

Was macht ein PSIRT konkret?

Ein PSIRT begleitet den gesamten Lebenszyklus eines Sicherheitsvorfalls und das heißt: von der Entdeckung bis zur Nachbereitung. Dabei geht es um deutlich mehr als nur das “Fixen” von Schwachstellen.

Meldungen entgegennehmen und erfassen

Der erste Schritt ist die saubere Erfassung von neuen Schwachstellen aus unterschiedlichen Quellen. Schwachstellenmeldungen können extern über security.txt, Vulnerability-Disclosure-Formulare, E-Mail oder Bug-Bounty-Plattformen gemeldet werden. Häufiger gelangen jedoch interne Meldungen von Entwicklern oder durch automatisierte Scans zum PSIRT.

Ein PSIRT stellt sicher, dass eingehende Schwachstellenmeldungen zentral erfasst, eindeutig dokumentiert – also mit Angaben wie Datum, betroffenem Produkt, Version und Beschreibung versehen und anschließend zeitnah bewertet werden.

Priorisierung und Klassifizierung

Nicht jede Meldung ist kritisch, viele entpuppen sich als Duplikate, Missverständnisse oder betreffen nur Konfigurationen. Hier entscheidet das PSIRT, welche Funde weiterverfolgt werden und mit welcher Priorität.

Ein PSIRT kann die folgenden Kriterien nutzen, um Sicherheitsmeldungen zu priorisieren und klassifizieren:

• Exploitability: Lässt sich die Schwachstelle remote ausnutzen? Ist ein Exploit verfügbar?
• Verbreitung: Welche Produkte und Kundenversionen sind betroffen?
• Schweregrad: Einschätzung durch CVSS oder eigene Risikomodelle.
• Kontext: Wie sensibel ist das betroffene System? Gibt es regulatorische Auflagen?

Ein erfahrener PSIRT-Prozess kann mit Priorisierungs-Workflows viel Zeit und Aufwand sparen.

Koordination der Gegenmaßnahmen

Sobald die Priorisierung abgeschlossen ist, beginnt die technische Arbeit. Entwicklerteams analysieren die Ursache, reproduzieren das Problem und entwickeln einen Patch oder eine andere Maßnahme zur Absicherung.

Das PSIRT spielt hier eine moderierende Rolle:

• Es sorgt für Transparenz und Priorisierung in der Entwicklung.
• Es stellt sicher, dass alle betroffenen Versionen berücksichtigt werden.
• Es koordiniert Testing, Qualitätssicherung und Regressionstests.
• Es plant die Auslieferung – via Firmware-Update, App-Release oder SaaS-Deployment.

Je nach Unternehmen können Teile dieser Aufgaben auch nicht vom PSIRT, sondern von den Entwicklungsteams durchgeführt werden.

Kommunikation und Stakeholdermanagement

Sobald ein Fix bereitsteht oder klar ist, dass die Schwachstelle keine Auswirkungen hat (z. B. durch Konfiguration oder Architektur), muss kommuniziert werden. Die Kommunikation sollte transparent, verantwortungsvoll und auf Zielgruppen zugeschnitten sein.

Dazu erstellt das PSIRT Security Advisories mit technischen Details und klaren Handlungsanweisungen, verfasst VEX-Dokumente, die darüber informieren, ob und welche Produkte tatsächlich von einer Schwachstelle betroffen sind, reicht gegebenenfalls CVE-Anträge ein, um die Lücke öffentlich zu dokumentieren, und koordiniert darüber hinaus auch Pressemeldungen, Kundeninformationen sowie Inhalte für den Support.

Nachbereitung und Verbesserung

Nach jedem sicherheitsrelevanten Vorfall stellt sich die Frage, ob die Bearbeitung gut lief und was noch weiter verbessert werden kann.

Ein gutes PSIRT führt strukturierte Post-Mortem-Analysen durch. Es dokumentiert Ursachen, Reaktionen, Zeitverlauf und Verbesserungspotenziale und nutzt die Erkenntnisse, um Prozesse zu optimieren, Schulungen zu entwickeln oder technische Schulden abzubauen.

Welche Skills braucht ein PSIRT-Team?

Ein PSIRT ist kein reines Tech-Team. Es braucht Menschen mit unterschiedlichen Perspektiven und Fähigkeiten.

Technische Expertise

Du brauchst Leute, die verstehen, wie Exploits funktionieren, wie Code-Änderungen auf komplexe Systeme wirken und wie Sicherheit in Embedded-, Web- und Cloud-Systemen umgesetzt wird.

Dazu gehören die folgenden Kenntnisse:

• Sicherheitsarchitektur
• Schwachstellenklassifikation (CVSS, CWE)
• Binary Analysis und Debugging
• SBOMs und VEX

Produktkenntnis

Die beste Analyse hilft nichts, wenn man nicht weiß, wie das Produkt funktioniert, wo es eingesetzt wird und wie Konfigurationen typischerweise aussehen. Gute PSIRT-Mitglieder verstehen das Produkt und können in seinem Kontext bewerten, was “kritisch” wirklich heißt.

Kommunikationsfähigkeit

Ob CVE-Antrag, Kundenhinweis oder Boardroom-Briefing, Sicherheitsvorfälle sind hochpolitisch. Klare, zielgruppengerechte Kommunikation und Stakeholdermanagement ist entscheidend.

Prozess- und Governance-Kompetenz

Von ISO 30111 über den Cyber Resilience Act bis hin zu branchenspezifischen Vorgaben: Ein PSIRT muss mit regulatorischen Anforderungen umgehen können, Audits begleiten und dokumentieren, dass Vorfälle angemessen behandelt wurden.

Wie organisierst du ein PSIRT?

Jedes Unternehmen tickt anders. Deshalb gibt es nicht das eine PSIRT-Modell, sondern drei gängige Strukturen:

Zentrales PSIRT

Ein dediziertes, kleines Kernteam kümmert sich um alle Produkte.

Vorteil: Klare Zuständigkeiten, standardisierte Prozesse, zentrale Sichtbarkeit. Nachteil: Geringe Nähe zu den Produktteams, limitierte Skalierbarkeit.

Dezentrales PSIRT

Jedes Produktteam stellt eigene PSIRT-Ressourcen. Entscheidungen und Kommunikation laufen lokal.

Vorteil: Direkter Draht zur Produktentwicklung, hohe Geschwindigkeit. Nachteil: Inkonsistenzen, Doppelarbeit, fehlende Standards.

Hybrides Modell

Ein zentrales PSIRT-Team verantwortet Methodik, Tools, Koordination. In den Produktbereichen arbeiten Security Champions, die operativ unterstützen.

Vorteil: Skalierbar, verbindlich, produktnah. Nachteil: Bedarf klarer Rollen, Governance und Kommunikation.

Viele Unternehmen starten zentral und entwickeln sich mit wachsendem Reifegrad in Richtung hybrider Struktur.

Fazit

Ein PSIRT ist kein “nice to have” mehr, sondern essenziell für jedes Unternehmen, das Produkte mit Softwarekomponenten vertreibt. Ob gesetzliche Vorgaben wie der Cyber Resilience Act, Kundenerwartungen oder schlicht betriebliche Resilienz.

Sicherheitsvorfälle sind keine Frage des ob etwas passiert, sondern nur wann es passiert.

Wenn du ein PSIRT aufbauen oder weiterentwickeln möchtest, solltest du dir zunächst die richtigen Fragen stellen, wie beispielsweise: Wie empfangen und bewerten wir Schwachstellenmeldungen? Wer ist verantwortlich für die technische Umsetzung und die kommunikative Koordination im Ernstfall? Wie dokumentieren wir unsere Maßnahmen nachvollziehbar, auch im Hinblick auf Audits? Und wer stellt sicher, dass Lessons Learned nicht nur erkannt, sondern auch tatsächlich in Verbesserungen überführt werden?