Koordinierte Schwachstellenoffenlegung nach CRA: Richtlinien-Vorlage und Umsetzung

Der CRA verlangt von Herstellern die Implementierung einer koordinierten Schwachstellenoffenlegung. Dies ist keine Option, sondern eine gesetzliche Pflicht. Dennoch haben viele Organisationen keine CVD-Richtlinie oder eine, die die regulatorischen Erwartungen nicht erfüllt.

Dieser Leitfaden bietet alles, was Sie brauchen: Richtlinienvorlagen, Frameworks für die Forscherkommunikation und Zeitplanhinweise.

Was der CRA verlangt

Anhang I, Teil II des CRA verlangt von Herstellern:

"eine Richtlinie zur koordinierten Schwachstellenoffenlegung einzuführen und durchzusetzen"

Das bedeutet:

• Eine Richtlinie haben: Geschrieben, veröffentlicht, zugänglich
• Sie umsetzen: Die Richtlinie tatsächlich befolgen, wenn Meldungen eingehen
• Sie durchsetzen: Konsistente Anwendung für alle Produkte

Der CRA spezifiziert keine genauen Richtlinieninhalte, aber Industriestandards und regulatorische Erwartungen sind klar.

Wesentliche Richtlinienkomponenten

Ihre CVD-Richtlinie muss diese Elemente behandeln:

1. Geltungsbereich

Welche Produkte und Dienste sind abgedeckt?

BEISPIEL GELTUNGSBEREICH:
Diese Richtlinie gilt für:
- Alle [Firmenname] Produkte mit digitalen Elementen
- Zugehörige Firmware und Software
- Web-Applikationen unter *.firma.de
- Mobile Anwendungen, veröffentlicht von [Firmenname]

Diese Richtlinie gilt NICHT für:
- Drittprodukte, die verkauft, aber nicht von uns hergestellt werden
- Dienste von Partnern unter deren eigenen Richtlinien

2. Kontaktmethoden

Wie können Forscher Sie erreichen?

Erforderliche Kanäle:

• E-Mail-Adresse (security@firma.de)
• Webformular (bevorzugt, strukturierte Erfassung)
• security.txt-Datei mit Verweis auf Kontaktmethoden

Optionale Erweiterungen:

• PGP-Schlüssel für verschlüsselte Meldungen
• Bug-Bounty-Plattform-Integration
• Dediziertes Forscher-Portal

3. Antwortverpflichtungen

Was können Forscher erwarten?

4. Offenlegungszeitplan

Wann können Forscher veröffentlichen?

Industriestandard: 90 Tage von Meldung bis öffentliche Offenlegung

Ihre Richtlinie sollte spezifizieren:

• Standard-Offenlegungsfenster (z.B. 90 Tage)
• Verlängerungsbedingungen (komplexe Fixes, koordinierte Multi-Vendor-Fälle)
• Vorzeitige Offenlegungsbedingungen (aktive Ausnutzung, Hersteller reagiert nicht)
• Recht des Forschers zur Offenlegung bei ausbleibender Antwort

5. Rechtlicher Schutzraum (Safe Harbor)

Schutz gutgläubiger Forscher vor rechtlichen Schritten.

BEISPIEL SCHUTZRAUM:
[Firmenname] wird keine rechtlichen Schritte gegen Forscher einleiten, die:
- Gutgläubig versuchen, diese Richtlinie einzuhalten
- Datenschutzverletzungen, Datenzerstörung und Dienstunterbrechungen vermeiden
- Schwachstellen nicht über die notwendige Demonstration hinaus ausnutzen
- Erkenntnisse zeitnah melden und angemessene Behebungszeit gewähren
- Nicht vor dem koordinierten Zeitplan öffentlich offenlegen

Dieser Schutzraum deckt Aktivitäten ab, die andernfalls verletzen könnten:
- Computermissbrauchsgesetze
- Datenschutzvorschriften
- Nutzungsbedingungen

6. Anerkennung und Belohnungen

Wie Sie Forscher würdigen.

Optionen:

• Öffentliche Anerkennung (Hall of Fame)
• Privater Dank
• Bug-Bounty-Zahlungen
• Werbeartikel/Merchandise
• Referenzschreiben

7. Nicht-Geltungsbereich

Was Sie nicht gemeldet haben möchten (oder anders behandeln).

NICHT IM GELTUNGSBEREICH:
- Social-Engineering-Angriffe gegen Mitarbeiter
- Physische Sicherheitsprobleme
- Denial-of-Service-Tests
- Spam- oder Phishing-Meldungen
- Probleme in Drittdiensten, die wir nicht kontrollieren
- Bereits gemeldete Schwachstellen

Vollständige CVD-Richtlinienvorlage

Verwenden Sie diese Vorlage als Ausgangspunkt. Passen Sie sie an Ihre Organisation an.

# [Firmenname] Richtlinie zur Schwachstellenoffenlegung

## Einleitung

[Firmenname] ist der Sicherheit unserer Produkte und der Sicherheit
unserer Kunden verpflichtet. Wir schätzen die Security-Research-Community
und begrüßen verantwortungsvolle Offenlegung von Schwachstellen.

## Geltungsbereich

Diese Richtlinie gilt für:
- Alle von [Firmenname] hergestellten Produkte
- Software und Firmware in unseren Produkten
- Web-Eigenschaften unter *.firma.de
- Mobile Anwendungen, veröffentlicht von [Firmenname]

## Wie Sie melden

**Bevorzugte Methode:** Einreichen über unser sicheres Formular unter:
https://firma.de/security/melden

**Alternative:** E-Mail an security@firma.de
- PGP-Schlüssel: [Schlüssel-ID oder Link zum Schlüssel]

**Referenz:** Unsere security.txt-Datei finden Sie unter:
https://firma.de/.well-known/security.txt

## Was Sie einschließen sollten

Bitte geben Sie an:
- Betroffene(s) Produkt(e) und Version(en)
- Beschreibung der Schwachstelle
- Schritte zur Reproduktion
- Potenzielle Auswirkungsbewertung
- Ihre vorgeschlagene Behebung (optional)
- Ihre Kontaktdaten für Rückfragen

## Unsere Verpflichtungen

| Zeitrahmen | Aktion |
|------------|--------|
| 3 Werktage | Bestätigung Ihrer Meldung |
| 10 Werktage | Erste Bewertung und Schweregrad |
| Alle 14 Tage | Statusupdate bis zur Lösung |
| 90 Tage | Ziellösung für die meisten Schwachstellen |

Wir können bei komplexen Schwachstellen, die koordinierte Fixes über
mehrere Produkte oder Anbieter erfordern, um Verlängerungen bitten.

## Koordinierte Offenlegung

Wir folgen einem 90-Tage-Offenlegungszeitplan:
- Tag 0: Sie melden die Schwachstelle
- Tage 1-90: Wir arbeiten an der Behebung
- Tag 90: Koordinierte öffentliche Offenlegung

**Verlängerungen:** Wir können bis zu 30 zusätzliche Tage beantragen für:
- Komplexe Multi-Komponenten-Fixes
- Hardware-Schwachstellen, die Lieferketten-Koordination erfordern
- Multi-Vendor-Koordination

**Vorzeitige Offenlegung:** Sie können früher offenlegen, wenn:
- Wir nicht innerhalb von 14 Tagen antworten
- Wir keine Absicht zur Behebung signalisieren
- Die Schwachstelle aktiv ausgenutzt wird

## Schutzraum

Wir werden keine rechtlichen Schritte gegen Forscher einleiten, die:
- Gutgläubig handeln und diese Richtlinie einhalten
- Den Zugriff auf, die Änderung oder Löschung von Nutzerdaten vermeiden
- Unsere Dienste nicht stören oder unseren Kunden schaden
- Schwachstellen zeitnah melden
- Angemessene Zeit zur Behebung vor Offenlegung gewähren

Dieser Schutzraum gilt für potenzielle Verstöße gegen:
- Computermissbrauchsgesetze
- Unsere Nutzungsbedingungen
- Datenschutzanforderungen (für zufälligen Zugriff während der Forschung)

## Anerkennung

Wir pflegen eine Security Hall of Fame unter firma.de/security/danke,
die Forscher würdigt, die zur Verbesserung unserer Sicherheit beigetragen haben.

Wir betreiben derzeit kein bezahltes Bug-Bounty-Programm.
[ODER: Wir bieten Bounties über [Plattform] an. Details siehe [Link].]

## Nicht im Geltungsbereich

Folgendes fällt nicht unter diese Richtlinie:
- Social Engineering von Mitarbeitern oder Kunden
- Physische Angriffe auf unsere Einrichtungen
- Denial-of-Service-Angriffe
- Erkenntnisse automatisierter Scanner ohne nachgewiesene Auswirkung
- Probleme in Drittdiensten
- Bereits gemeldete Schwachstellen

## Kontakt

Security Team: security@firma.de
Fragen zur Richtlinie: security-policy@firma.de
PGP-Schlüssel: [Link]

Zuletzt aktualisiert: [Datum]

Implementierungs-Checkliste

Infrastruktur-Setup

CVD-INFRASTRUKTUR-CHECKLISTE

KONTAKTKANÄLE:
[ ] security@firma.de konfiguriert und überwacht
[ ] Webformular mit erforderlichen Feldern erstellt
[ ] PGP-Schlüssel generiert und veröffentlicht
[ ] security.txt-Datei bereitgestellt (siehe separaten Leitfaden)
[ ] /security oder /security/melden Seite erstellt

INTERNER PROZESS:
[ ] Triage-Team identifiziert
[ ] Eskalationspfad definiert
[ ] SLA-Tracking-System vorhanden
[ ] Vorlagen-Antworten vorbereitet
[ ] Offenlegungs-Koordinationsprozess dokumentiert

DOKUMENTATION:
[ ] CVD-Richtlinie geschrieben und genehmigt
[ ] Richtlinie auf Website veröffentlicht
[ ] Interne Bearbeitungsverfahren dokumentiert
[ ] Forscher-Kommunikationsvorlagen bereit
[ ] Hall-of-Fame-Seite erstellt (optional)

TESTS:
[ ] Testmeldung intern eingereicht
[ ] Antwortzeitverfolgung verifiziert
[ ] Eskalationsprozess getestet
[ ] Offenlegungskoordination getestet

Vorlagen für Forscherkommunikation

Bestätigung (Tag 0-3):

Betreff: [Ticket #] - Schwachstellenmeldung erhalten

Sehr geehrte(r) [Forscher],

vielen Dank für die Meldung einer potenziellen Sicherheitsschwachstelle
in [Produktname]. Wir haben Ihre Meldung erhalten und ihr die
Tracking-Nummer [Ticket #] zugewiesen.

Unser Sicherheitsteam wird Ihre Einreichung prüfen und innerhalb von
10 Werktagen eine erste Bewertung abgeben.

Bitte referenzieren Sie [Ticket #] in zukünftiger Korrespondenz.

Fragen? Antworten Sie auf diese E-Mail oder kontaktieren Sie security@firma.de.

Mit freundlichen Grüßen,
[Firmenname] Security Team

Erste Bewertung (Tag 10):

Betreff: [Ticket #] - Erste Bewertung abgeschlossen

Sehr geehrte(r) [Forscher],

wir haben unsere erste Bewertung Ihrer gemeldeten Schwachstelle
in [Produktname] abgeschlossen.

Bewertungszusammenfassung:
- Schweregrad: [Kritisch/Hoch/Mittel/Niedrig]
- Status: [Bestätigt/In Untersuchung/Nicht reproduzierbar]
- Betroffene Versionen: [Liste]
- Ziellösung: [Datum, typischerweise innerhalb von 90 Tagen]

Nächste Schritte:
[Beschreibung des geplanten Behebungsansatzes]

Wir werden alle 14 Tage Statusupdates geben. Aktuelles
Offenlegungsziel: [Datum].

Vielen Dank für Ihren Beitrag zur Verbesserung unserer Sicherheit.

Mit freundlichen Grüßen,
[Firmenname] Security Team

Lösungsbenachrichtigung:

Betreff: [Ticket #] - Schwachstelle behoben

Sehr geehrte(r) [Forscher],

wir haben die von Ihnen gemeldete Schwachstelle in [Produktname] behoben.

Lösungsdetails:
- Fix-Version: [Versionsnummer]
- Veröffentlichungsdatum: [Datum]
- CVE-ID: [Falls zugewiesen]

Koordinierte Offenlegung:
Wir planen, am [Datum] ein Security Advisory zu veröffentlichen.

Möchten Sie in unserem Advisory genannt werden?
[ ] Ja, nennen Sie mich als: [Name/Handle]
[ ] Ja, nennen Sie mich anonym
[ ] Keine Nennung erforderlich

Vielen Dank für Ihre verantwortungsvolle Offenlegung. Ihr Beitrag
wurde unserer Security Hall of Fame unter [URL] hinzugefügt.

Mit freundlichen Grüßen,
[Firmenname] Security Team

Umgang mit häufigen Szenarien

Szenario 1: Forscher verlangt sofortige Offenlegung

Situation: Forscher besteht auf 30-Tage-Zeitplan statt 90 Tagen.

Reaktion:

1. Erklären Sie Ihren Standard-Zeitplan und den Grund (gründlicher Fix, Tests)
2. Bieten Sie Kompromiss an, wenn möglich (60 Tage mit Statusupdates)
3. Wenn Forscher besteht, intern eskalieren
4. Dokumentieren Sie die Meinungsverschiedenheit und Ihre gutgläubigen Bemühungen
5. Priorisieren Sie den Fix, denn Sie müssen möglicherweise beschleunigen

Szenario 2: Doppelte Meldung

Situation: Schwachstelle bereits bekannt oder zuvor gemeldet.

Reaktion:

Betreff: [Ticket #] - Doppelte Meldung

Sehr geehrte(r) [Forscher],

vielen Dank für Ihre Meldung bezüglich [Schwachstellentyp] in
[Produktname].

Dieses Problem wurde bereits gemeldet und wird derzeit bearbeitet.
Original-Ticket: [Referenz].

Erwartete Lösung: [Datum]

Obwohl wir für doppelte Meldungen keine Anerkennung anbieten können,
schätzen wir Ihre Aufmerksamkeit für unsere Sicherheit.

Mit freundlichen Grüßen,
[Firmenname] Security Team

Szenario 3: Meldung außerhalb des Geltungsbereichs

Situation: Meldung betrifft etwas außerhalb Ihres CVD-Geltungsbereichs.

Reaktion:

Betreff: [Ticket #] - Außerhalb des Geltungsbereichs

Sehr geehrte(r) [Forscher],

vielen Dank für Ihre Meldung. Nach Prüfung haben wir festgestellt,
dass dieses Problem außerhalb unserer Schwachstellenoffenlegungs-Richtlinie
liegt.

Grund: [z.B. "Drittdienst, der nicht von uns kontrolliert wird"]

Wenn Sie diese Einschätzung für falsch halten, antworten Sie bitte
mit zusätzlichem Kontext.

Für Probleme mit [Drittanbieter] kontaktieren Sie bitte [Kontakt].

Mit freundlichen Grüßen,
[Firmenname] Security Team

Szenario 4: Aktive Ausnutzung entdeckt

Situation: Während der Untersuchung entdecken Sie, dass die Schwachstelle ausgenutzt wird.

Reaktion:

1. ENISA-Meldung auslösen (24-Stunden-Anforderung)
2. Forscher über Situationsänderung informieren
3. Behebung beschleunigen
4. Vorzeitige koordinierte Offenlegung in Betracht ziehen
5. Kundenbenachrichtigung vorbereiten

Betreff: [Ticket #] - Dringendes Update

Sehr geehrte(r) [Forscher],

wir haben aktive Ausnutzung der von Ihnen gemeldeten Schwachstelle
entdeckt. Wir:

1. Beschleunigen unseren Behebungszeitplan
2. Benachrichtigen die zuständigen Behörden wie erforderlich
3. Bereiten Kundenkommunikation vor

Wir müssen die Offenlegung dringend koordinieren. Bitte kontaktieren
Sie uns unter [Telefon/sicherer Kanal], um den Zeitplan zu besprechen.

Bitte veröffentlichen Sie zu diesem Zeitpunkt NICHT öffentlich.
Dies könnte Schaden für Nutzer erhöhen, bevor Patches verfügbar sind.

Dringender Kontakt: [Telefon/Signal]

[Firmenname] Security Team

Integration von CVD mit ENISA-Meldung

Ihr CVD-Prozess muss mit Ihrer ENISA-Meldepflicht verbunden sein:

FORSCHERMELDUNG TRIFFT EIN
         │
         ▼
    TRIAGE & BEWERTEN
         │
         ├── Keine aktive Ausnutzung ──→ Standard-CVD-Prozess
         │                              (90-Tage-Zeitplan)
         │
         └── Aktive Ausnutzung ──→ ENISA-MELDUNG AUSLÖSEN
              erkannt                    │
                                        ▼
                                   24h Frühwarnung
                                        │
                                        ▼
                                   72h Detaillierte Meldung
                                        │
                                        ▼
                                   Beschleunigtes CVD
                                   (mit ENISA koordinieren)

Häufige Fehler

Keine veröffentlichte Richtlinie

Problem: Richtlinie existiert intern, ist aber nicht öffentlich.

Lösung: An auffindbarer URL veröffentlichen. Forscher können einer Richtlinie nicht folgen, die sie nicht finden können.

Unrealistische Zeitpläne

Problem: 7-Tage-Antwort versprechen, wenn Sie das nicht liefern können.

Lösung: Erreichbare Verpflichtungen setzen. Weniger versprechen, mehr liefern.

Fehlender Schutzraum

Problem: Kein rechtlicher Schutz für Forscher.

Lösung: Explizite Safe-Harbor-Formulierung hinzufügen. Ohne diese melden Forscher möglicherweise nicht an Sie.

Forscher als Bedrohungen behandeln

Problem: Rechtliche Drohungen, aggressive Antworten, Meldungen ignorieren.

Lösung: Forscher helfen Ihnen. Behandeln Sie sie als Partner.

Kein interner Prozess

Problem: Richtlinie veröffentlicht, aber niemand weiß, wie Meldungen zu bearbeiten sind.

Lösung: Interne Verfahren dokumentieren. Team schulen. Mit Simulationen testen.

CVD-Richtlinien-Checkliste

CVD-RICHTLINIEN-VOLLSTÄNDIGKEITS-CHECKLISTE

GELTUNGSBEREICH:
[ ] Abgedeckte Produkte aufgelistet
[ ] Nicht-Geltungsbereich definiert
[ ] Geografischer Geltungsbereich klar (falls relevant)

KONTAKT:
[ ] E-Mail-Adresse angegeben
[ ] Webformular verfügbar
[ ] PGP-Schlüssel veröffentlicht
[ ] security.txt bereitgestellt
[ ] Antwortkanäle überwacht

ZEITPLAN:
[ ] Bestätigungszeitplan angegeben
[ ] Bewertungszeitplan angegeben
[ ] Lösungsziel angegeben
[ ] Offenlegungszeitplan angegeben
[ ] Verlängerungsbedingungen definiert

RECHTLICH:
[ ] Safe-Harbor-Erklärung enthalten
[ ] Abgedeckte Aktivitäten definiert
[ ] Gutgläubigkeitsanforderungen genannt

ANERKENNUNG:
[ ] Credit-Prozess erklärt
[ ] Hall of Fame (falls zutreffend)
[ ] Bounty-Programm (falls zutreffend)

PROZESS:
[ ] Interne Triage dokumentiert
[ ] Eskalationspfad definiert
[ ] Vorlagen-Antworten bereit
[ ] ENISA-Integration geplant

Verwandte Leitfäden

• security.txt für CRA-Compliance einrichten
• ENISA-Schwachstellenmeldung: Die 24-Stunden-Anforderung
• CRA-Strafen und Durchsetzungsleitfaden

Wie CRA Evidence hilft

CRA Evidence umfasst CVD-Workflow-Unterstützung:

• Meldungs-Tracking: Protokollieren und verfolgen Sie Forschermeldungen
• Zeitplan-Management: Automatisches SLA-Tracking
• ENISA-Integration: Meldung auslösen bei erkannter Ausnutzung
• Dokumentation: Audit-Trail für regulatorische Compliance

Etablieren Sie Ihren CVD-Prozess mit app.craevidence.com.

Dieser Artikel dient nur zu Informationszwecken und stellt keine Rechtsberatung dar. Für spezifische Compliance-Beratung konsultieren Sie qualifizierte Rechtsberater.