Ein Product Security Incident Response Team von Grund auf aufbauen

Jahrelang waren dedizierte Product Security Incident Response Teams (PSIRTs) ausschließlich die Domäne multinationaler Tech-Giganten, der Microsofts, Apples und Ciscos dieser Welt. Wenn Sie ein kleines oder mittleres Unternehmen (KMU) waren, das IoT-Geräte, B2B-Software oder Unterhaltungselektronik baute, war die Schwachstellenbehandlung wahrscheinlich eine Ad-hoc-Aufgabe, die jenem Senior-Entwickler zugewiesen wurde, der gerade online war, als ein verärgerter Sicherheitsforscher den CEO anschrieb.

Der EU Cyber Resilience Act (CRA) beendet diese Ära endgültig.

Bis September 2026 muss jeder Hersteller, der Produkte mit digitalen Elementen (PDEs) auf den EU-Markt bringt, formalisierte Prozesse haben, um Schwachstellen entgegenzunehmen, sie innerhalb von 48 Stunden zu bestätigen, sie umgehend zu beheben und sie gegebenenfalls innerhalb von 24 Stunden den Behörden zu melden.

Diese gesetzlichen Pflichten können Sie nicht auf Ad-hoc-Basis erfüllen. Sie brauchen ein PSIRT.

Doch wenn Sie eine Entwicklungsorganisation mit 50 Personen sind, können Sie sich kein dediziertes Team von 10 Sicherheitsanalysten leisten, das in einem Lagezentrum sitzt. Sie brauchen ein minimal tragfähiges PSIRT. Hier ist ein praktischer Bauplan, um von Grund auf eine konforme, wirksame Produktsicherheitsfähigkeit aufzubauen, zugeschnitten auf KMU.

Das PSIRT entmystifizieren

Unterscheiden wir zunächst ein PSIRT von einem CSIRT (Computer Security Incident Response Team) oder einem SOC (Security Operations Center).

• CSIRT/SOC: Verteidigt die interne Infrastruktur des Unternehmens (das Firmennetzwerk, die Laptops der Mitarbeiter, die Cloud-Hosting-Umgebung).
• PSIRT: Verteidigt die Kunden, die die Produkte des Unternehmens nutzen. Es behandelt Schwachstellen, die in dem Code oder der Hardware, die Sie verkaufen, gefunden werden.

Während ein Großunternehmen diese Funktionen trennt, besteht das MV-PSIRT eines KMU oft aus Personen, die mehrere Rollen übernehmen und sich aus Entwicklung, interner IT und Rechtsabteilung bedienen.

Schritt 1: Die „Eingangstür“ einrichten (Werkzeuge)

Bevor Sie die menschlichen Rollen festlegen, brauchen Sie die Infrastruktur, um Meldungen entgegenzunehmen. Sie brauchen einen Prozess zur koordinierten Offenlegung von Schwachstellen (CVD).

Die Anforderungen:

1. Sichtbarkeit: Eine security.txt-Datei im Stammverzeichnis Ihrer Hauptdomains, die auf Ihre Richtlinie verweist.
2. Der Eingangsmechanismus: Ein dediziertes Portal (wie CVD Portal) oder ein security@-E-Mail-Alias. Verwenden Sie keine allgemeinen Support-Ticketsysteme; Sicherheitsmeldungen müssen abgetrennt werden, um eine versehentliche Offenlegung von Zero-Day-Exploits gegenüber dem First-Level-Support zu verhindern.
3. Sichere Kommunikation: Der Eingangskanal muss Verschlüsselung unterstützen (z. B. PGP-Schlüssel für E-Mail oder erzwungenes HTTPS/TLS für Portale), um die Schwachstellendetails während der Übertragung zu schützen.

Schritt 2: Die Rollen definieren (Die Menschen)

In einem MV-PSIRT sind das Rollen, nicht notwendigerweise bestimmte Vollzeitstellen. Ein einzelner Senior-Entwickler kann mehrere Rollen innehaben.

1. Der Triage-Koordinator

Dies ist die kritischste Rolle für den täglichen Betrieb.

• Verantwortung: Überwacht den Eingangskanal. Bestätigt den Eingang innerhalb von 48 Stunden (eine strikte CRA-Anforderung). Führt die erste Filterung durch, um Spam und Beg-Bounties auszusortieren.
• Profil: Ein Entwickler auf Junior- bis Mid-Level oder ein hochtechnischer Support-Spezialist. Er muss den Fehler nicht beheben, aber die Terminologie von Schwachstellen verstehen (XSS, Buffer Overflow, RCE), um glaubwürdige Meldungen zu erkennen.

2. Der Schwachstellenanalyst / Produktverantwortliche

• Verantwortung: Reproduziert die gemeldete Schwachstelle in einer sicheren Umgebung. Vergibt einen CVSS-Schweregradwert. Bestimmt den Wirkungsradius (betrifft das andere Produkte?).
• Profil: Senior-Entwickler, Technical Leads oder QA-Ingenieure, die mit der spezifischen Produktarchitektur vertraut sind. In einem KMU haben Sie wahrscheinlich keine dedizierten Sicherheitsanalysten; Sie verlassen sich darauf, dass Ihre Senior-Entwickler als Fachexperten für den von ihnen geschriebenen Code agieren.

3. Der Behebungsverantwortliche

• Verantwortung: Treibt die Korrektur in der Entwicklung voran. Stellt sicher, dass der Patch keine Regressionen einführt. Koordiniert den Veröffentlichungsplan.
• Profil: Ein Engineering Manager oder Team Lead. Er verantwortet das Entwicklungs-Backlog und hat die Befugnis, Entwickler von der Feature-Arbeit abzuziehen, um einen Sicherheitspatch hoher Priorität zu erzwingen.

4. Der Incident Commander (der „Artikel-14“-Verantwortliche)

• Verantwortung: Trifft die folgenschweren Entscheidungen. Hat die Befugnis, einen „schwerwiegenden Vorfall“ zu erklären oder eine „aktive Ausnutzung“ zu bestätigen und damit die 24-Stunden-Meldekaskade des CRA auszulösen. Koordiniert die öffentliche Kommunikation und die rechtliche Prüfung.
• Profil: Der CTO, VP of Engineering oder CISO. Diese Person muss die organisatorische Befugnis haben, normale Verfahren während einer Krise zu umgehen.

Schritt 3: Das Playbook formalisieren (Der Prozess)

Ein MV-PSIRT ist nur so gut wie seine Dokumentation. Sie brauchen ein schriftliches Playbook, das genau vorgibt, was passiert, wenn eine gültige Meldung eintrifft.

Die Service Level Agreements (SLAs)

Legen Sie interne Reaktionsgrenzen auf Basis des CVSS-Schweregrads fest. (Dies sind Beispiele; passen Sie sie an Ihre Kapazität an, aber behalten Sie die CRA-Erwartungen im Blick.)

• Kritisch (CVSS 9,0 bis 10,0): Triage in 4 Stunden. Behebungsplan in 24 Stunden. Patch veröffentlicht in {"<"} 7 Tagen.
• Hoch (CVSS 7,0 bis 8,9): Triage in 24 Stunden. Patch im nächsten geplanten Sprint ({"<"} 30 Tage).
• Mittel/Niedrig (CVSS 0,0 bis 6,9): Triage in 48 Stunden. Patch innerhalb von 90 Tagen.

Das Protokoll für „aktive Ausnutzung“

Erstellen Sie in Ihrem Playbook einen großen, fett gedruckten Abschnitt für die 24-Stunden-CRA-Meldung.

Weist eine Meldung auf aktive Ausnutzung hin (z. B. „Ich sehe gerade, wie diese Ransomware-Payload in meinem Netzwerk abgelegt wird und dabei diesen Fehler in Ihrem Produkt nutzt“), entfallen die normalen SLAs. Der Incident Commander wird sofort alarmiert, um mit dem Entwurf der Frühwarnmeldung an das nationale CSIRT zu beginnen.

Offenlegung und Sicherheitsmeldungen

Legen Sie das Format Ihrer öffentlichen Sicherheitsmeldungen fest, sobald der Patch live ist. Sie müssen den Forscher würdigen (falls gewünscht), die CVE-ID auflisten, die Auswirkungen erklären und klare Update-Anweisungen geben. Gehen Sie zu maschinenlesbaren Formaten (CSAF 2.0) über, um die Compliance-Meldung zu erleichtern.

Schritt 4: Eine Tabletop-Übung durchführen

Testen Sie Ihr PSIRT-Playbook nicht zum ersten Mal während einer echten Krise.

Planen Sie eine zweistündige „Tabletop-Übung“ mit Ihren benannten MV-PSIRT-Mitgliedern. Stellen Sie ein simuliertes Szenario vor:

• Szenario: „Es ist 16:00 Uhr an einem Freitag. Ein Forscher schreibt an den security@-Alias und erklärt, er habe einen nicht authentifizierten Zero-Day für Remote Code Execution (RCE) in unserem Vorzeige-IoT-Controller gefunden. Er hat ein Python-Skript geliefert, das die Firmware perfekt ausnutzt. Was tun Sie?“

Gehen Sie das Playbook Schritt für Schritt durch. Wer bestätigt die E-Mail? Wer richtet die Testumgebung ein? Wer bewertet sie? Wenn der Forscher angibt, dass er die Details am Montag veröffentlichen will, wie sieht Ihre Krisenkommunikationsstrategie aus?

Identifizieren Sie die Lücken in Ihrem Prozess und verbessern Sie das Playbook iterativ.

Fazit

Ein PSIRT von Grund auf aufzubauen ist einschüchternd, erfordert aber kein Millionenbudget und keine dedizierte Sicherheitsarmee. Es erfordert Absicht, Organisation und ein klares Verständnis Ihrer gesetzlichen Pflichten unter dem CRA. Indem sie eine formalisierte Eingangstür einrichten, vorhandenen Entwicklungstalenten klare Rollen zuweisen und ihre Reaktions-SLAs konsequent definieren, können KMU ein hochkompetentes minimal tragfähiges PSIRT aufbauen, das für alles gewappnet ist, was in ihrem Postfach landet.