Disclosure-Vorlagen

Lernziel

Nach dieser Seite weißt du, wie du BLE-Schwachstellen verantwortungsvoll offenlegst, welche rechtlichen Rahmenbedingungen gelten, und hast fertige Vorlagen für die Kommunikation mit Herstellern.

Was ist Responsible Disclosure?

Responsible Disclosure (zu deutsch: verantwortungsvolle Offenlegung) ist ein Prozess, bei dem ein Sicherheitsforscher eine Schwachstelle zuerst privat an den betroffenen Hersteller meldet — und ihm eine angemessene Frist gibt, das Problem zu beheben — bevor die Details öffentlich gemacht werden.

Stell dir vor, du findest einen offenen Safe in einem Geschäft. Du gibst dem Besitzer Bescheid und ein paar Tage Zeit, ihn zu schließen — anstatt sofort alle Passanten darüber zu informieren. Das ist Responsible Disclosure.

Rechtliche Grundlagen (Deutschland)

Bevor du eine Analyse durchführst, solltest du die rechtlichen Rahmenbedingungen kennen:

StGB §202a – Ausspähen von Daten: Das Analysieren von BLE-Kommunikation eigener Geräte (die du gekauft hast) ist legal. Du greifst auf Daten zu, für die du "berechtigt" bist, da du das Gerät besitzt.

StGB §202b – Abfangen von Daten: Unverschlüsselte oder offen zugängliche BLE-Kommunikation fremder Geräte abzuhören kann problematisch sein. Bei eigenen Geräten: kein Problem.

StGB §202c – Vorbereitung: Das Besitzen und Entwickeln von Tools wie dem Python-PoC ist nicht per se illegal, wenn der Zweck die Sicherheitsforschung ist.

Kernregel:

• Eigene, legal erworbene Geräte: Analyse ist legal
• Fremde Geräte ohne Erlaubnis: Nicht erlaubt
• Mit schriftlicher Genehmigung: Legal (Bug-Bounty-Programme, Pentesting-Aufträge)

Der ISO/IEC 29147-Prozess

ISO/IEC 29147:2018 ist der internationale Standard für Vulnerability Disclosure. Er definiert den idealen Ablauf:

Phase 1: Entdeckung
├── Schwachstelle gefunden und dokumentiert
├── Proof-of-Concept entwickelt
└── CVSS-Score berechnet

Phase 2: Erstmeldung (Tag 0)
├── Sicherheitskontakt des Herstellers suchen
├── Verschlüsselte Erstmeldung senden (PGP wenn verfügbar)
└── Erwartungen an Frist kommunizieren

Phase 3: Koordination (Tag 0–90)
├── Hersteller bestätigt Empfang (Ziel: innerhalb 7 Tage)
├── Regelmäßige Updates vom Hersteller
└── Frist bei konstruktiver Zusammenarbeit ggf. verlängern

Phase 4: Patch/Offenlegung (Tag 90+)
├── Hersteller veröffentlicht Patch → Koordinierte Offenlegung
├── Kein Patch → Öffentliche Offenlegung nach Deadline
└── CVE via MITRE beantragen

Fristen

Wenn der Hersteller sich konstruktiv verhält, können Fristen einvernehmlich verlängert werden. Wenn der Hersteller nicht reagiert oder abblockt: Offenlegung nach Deadline ist gerechtfertigt.

Interaktive Disclosure-Vorlagen

Die folgenden Vorlagen kannst du direkt kopieren und anpassen:

Betreff: Sicherheitslücke — [Product Name]

Sehr geehrtes [Vendor] Security-Team,

hiermit melde ich eine Sicherheitslücke, die ich in [Product Name] entdeckt habe.

Schwachstellentyp: Unbefugter Zugriff
Entdeckungsdatum: [Date]

[Kurzbeschreibung — bitte selbst ausfüllen]

Ich melde diese Schwachstelle im Rahmen einer verantwortungsvollen Offenlegung. Ich bitte um:
1. Bestätigung dieses Berichts innerhalb von 5 Werktagen
2. Einen Zeitplan für die Behebung
3. Benachrichtigung, sobald das Problem behoben ist

Gerne stehe ich für weitere Details oder Unterstützung bei der Behebung zur Verfügung.

Mit freundlichen Grüßen,
[Researcher Name]

Wenn kein Sicherheitskontakt vorhanden ist

Viele kleine IoT-Hersteller haben keine dedizierte Sicherheits-E-Mail. Alternativen:

1. security@hersteller.com — Standard-Convention
2. info@hersteller.com — Allgemeine Kontaktadresse
3. LinkedIn-Profil des CTO oder Head of Engineering
4. Bug-Bounty-Plattformen: HackerOne, Bugcrowd (wenn der Hersteller dort registriert ist)
5. CERT-Bund als Koordinationsstelle: cert@bsi.bund.de

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) betreibt das CERT-Bund und kann bei der Koordination zwischen Forscher und Hersteller helfen.

CVE-Antrag bei MITRE

Nach erfolgreicher Koordination oder nach öffentlicher Offenlegung kannst du eine CVE-Nummer beantragen:

1. CVE-Antragsformular: cve.mitre.org/cve/researcher_reservation_guidelines.html
2. Benötigte Informationen:
   • Betroffene Software/Hardware und Version
   • Schwachstellenbeschreibung (CWE-Typ)
   • Proof-of-Concept (optional aber empfohlen)
   • Patch/Advisory-Link (wenn vorhanden)
3. MITRE weist eine CVE-ID zu (z. B. CVE-2024-12345)
4. CVE wird nach öffentlicher Offenlegung veröffentlicht

Ethik in der Forschung

Neben dem rechtlichen Rahmen gibt es ethische Leitlinien:

• Minimaler Schaden: Führe nur Tests durch, die zur Analyse notwendig sind. Kein absichtliches Ausfallen-Lassen von Produktionssystemen.
• Datenschutz: Wenn du im Rahmen einer Analyse Nutzerdaten abfängst, lösche sie nach Abschluss der Dokumentation.
• Transparenz: Melde nicht nur die Schwachstellen, sondern auch, wie du sie gefunden hast. Das hilft dem Hersteller beim Patching.
• Proportionalität: Der Disclosure-Prozess sollte der Schwere der Schwachstelle angemessen sein.

Zusammenfassung

• Eigene Geräte analysieren ist in Deutschland legal (StGB §202a)
• Der ISO/IEC-29147-Prozess: Erstmeldung → 90 Tage → koordinierte Offenlegung
• CERT-Bund (cert@bsi.bund.de) als Koordinationsstelle bei fehlendem Herstellerkontakt
• CVE bei MITRE beantragen für Schwachstellen mit CVSS 7.0+
• Ethik: minimaler Schaden, Datenschutz, Transparenz, Proportionalität