Koordinierte Offenlegung von Schwachstellen
Dokumentenklassifizierung: Öffentlich
1. Zweck
Catalogic Software („Catalogic“, „wir“, „unser“) schätzt den Beitrag unabhängiger Sicherheitsforscher und anderer Personen, die uns helfen, Sicherheitslücken in unseren Produkten zu finden und zu beheben. Diese Richtlinie erläutert, wie Sie eine vermutete Schwachstelle in Catalogic DPX oder Catalogic CloudCasa melden, welche Reaktion Sie von uns erwarten können und unter welchen Bedingungen wir gutgläubige Sicherheitsforschung gestatten.
Diese Richtlinie berücksichtigt außerdem die Verpflichtung von Catalogic als Hersteller von „Produkten mit digitalen Elementen“ gemäß der EU-Cyberresilienz-Verordnung (Verordnung (EU) 2024/2847, „CRA“), ein Verfahren zur koordinierten Offenlegung von Schwachstellen zu unterhalten und durchzusetzen (CRA Anhang I, Teil II Nummer 5) sowie eine zentrale Kontaktstelle für Schwachstellenmeldungen zu veröffentlichen (CRA Anhang II Nummer 2).
2. Geltungsbereich
2.1. Im Geltungsbereich
- Catalogic DPX und vStor in allen aktuell unterstützten Versionen (siehe den DPX-Support-Lebenszyklus und den Zeitplan zum Support-Ende).
- Catalogic CloudCasa, einschließlich der CloudCasa-SaaS-Plattform und aller aktuell unterstützten selbst gehosteten Komponenten und Konnektoren.
- Schwachstellen in von Catalogic entwickeltem Code, in Konfigurationen und in von Catalogic betriebener Infrastruktur, die diese Produkte unmittelbar unterstützt.
2.2. Außerhalb des Geltungsbereichs
- Denial-of-Service, Spam, Social Engineering oder physische Angriffe gegen Mitarbeitende, Büros oder Rechenzentren von Catalogic.
- Automatisierte Schwachstellenscans, die ohne vorherige Abstimmung eine erhebliche Last auf von Catalogic gehosteten Diensten verursachen.
- Dienste, Abhängigkeiten oder Infrastruktur Dritter, die nicht von Catalogic kontrolliert werden (Hinweise zur Meldung finden Sie in Abschnitt 8).
- Produkte, deren Support beendet ist, sofern die jeweilige Mitteilung zum Support-Ende nichts anderes vorsieht.
3. Begriffe
- Schwachstelle: Eine Schwäche, Anfälligkeit oder ein Fehler in einem Produkt mit digitalen Elementen, die durch eine Cyberbedrohung ausgenutzt werden können.
- Aktiv ausgenutzte Schwachstelle: Eine Schwachstelle, für die zuverlässige Hinweise vorliegen, dass ein böswilliger Akteur sie ohne Erlaubnis des Systemeigentümers in einem System ausgenutzt hat (CRA Artikel 3 Nummer 42). Dies löst die eigenen gesetzlichen Meldepflichten von Catalogic gemäß CRA Artikel 14 aus; siehe Abschnitt 7.
- Koordinierte Offenlegung von Schwachstellen (CVD): Ein Verfahren, bei dem ein Meldender eine Schwachstelle vertraulich einem Anbieter mitteilt und diesem vor einer öffentlichen Offenlegung Zeit zur Bewertung und Behebung einräumt.
- Gutgläubige Sicherheitsforschung: Der Zugriff auf ein Produkt ausschließlich zum Testen, Untersuchen und/oder Beheben eines Sicherheitsproblems in einer Weise, die Schäden vermeidet, verbunden mit einer unverzüglichen Meldung an Catalogic.
4. Eine Schwachstelle melden
Bitte melden Sie vermutete Schwachstellen an unsere zentrale Kontaktstelle:
- E-Mail: security@catalogicsoftware.com
- Dieser Kontakt wird auch in maschinenlesbarer Form unter https://www.catalogicsoftware.com/.well-known/security.txt und https://cloudcasa.io/.well-known/security.txt veröffentlicht.
Wenn Sie vermuten, dass eine Schwachstelle bereits aktiv ausgenutzt wird oder eine unmittelbare Gefahr für Kundendaten darstellt, weisen Sie bitte ausdrücklich in der Betreffzeile darauf hin, beispielsweise mit „ACTIVE EXPLOITATION“. So kann die Meldung unverzüglich priorisiert werden; siehe Abschnitt 7.
5. Angaben in Ihrer Meldung
- Betroffenes Produkt und betroffene Versionen, beispielsweise DPX x.x oder die CloudCasa-Komponente mit Datum.
- Beschreibung der Schwachstelle und ihrer möglichen Auswirkungen.
- Wenn möglich, schrittweise Anweisungen zur Reproduktion, Proof-of-Concept-Code oder eine Aufzeichnung von Anfrage und Antwort.
- Ihre Einschätzung, ob die Schwachstelle bereits außerhalb einer Testumgebung ausgenutzt wird, sowie entsprechende Hinweise.
- Bevorzugter Kontaktweg und, falls Sie öffentlich genannt werden möchten, der dafür zu verwendende Name oder Benutzername.
Bitte übermitteln Sie keine tatsächlichen Kundendaten, Zugangsdaten oder anderen sensiblen Informationen. Beschreiben Sie den Zugriff, statt Daten zu exfiltrieren.
6. Unsere Zusagen an Sie
Wenn wir über den oben genannten Kanal eine gültige Meldung erhalten, sagen wir Folgendes zu:
- Den Eingang zu bestätigen und eine Referenznummer zur Nachverfolgung zu vergeben.
- Die Meldung zu untersuchen und zu validieren und Sie über wesentliche Fortschritte zu informieren.
- Bestätigte Schwachstellen innerhalb der nachstehend beschriebenen Zeitvorgaben nach Schweregrad priorisiert zu beheben.
- Keine rechtlichen Schritte gegen Forschende einzuleiten, die diese Richtlinie einhalten (siehe Abschnitt 9).
- Meldende auf Wunsch zu nennen, sobald eine Behebung verfügbar ist. Derzeit besteht kein Programm für finanzielle Prämien.
| Schweregrad der Meldung (CVSS-v3.1-/4.0-Basiswert) | Ziel für die Eingangsbestätigung | Ziel für die erste Bewertung / das Ergebnis der Priorisierung | Ziel für die Verfügbarkeit einer abgestimmten Behebung oder Abhilfemaßnahme |
|---|---|---|---|
| Kritisch (9,0–10,0) | 1 Arbeitstag | 3 Arbeitstage | So schnell wie vernünftigerweise möglich; keine feste Höchstfrist, jedoch Vorrang vor allen anderen Entwicklungsarbeiten |
| Hoch (7,0–8,9) | 2 Arbeitstage | 5 Arbeitstage | Gemäß dem internen Patch-SLA für hohen Schweregrad |
| Mittel (4,0–6,9) | 3 Arbeitstage | 10 Arbeitstage | Gemäß dem internen Patch-SLA für mittleren Schweregrad |
| Niedrig (0,1–3,9) | 5 Arbeitstage | 15 Arbeitstage | Behebung in einem regulären Wartungs- oder Nebenrelease |
Die vorstehenden Reaktionszeiten sind vorgeschlagene interne Serviceziele, die sich an gängiger Branchenpraxis orientieren, beispielsweise an den Grundsätzen von ISO/IEC 29147 und 30111. Sie werden nicht durch den CRA vorgeschrieben. Der CRA legt keine zahlenmäßigen Reaktions-SLAs für CVD-Programme fest.
7. Zeitplan für die koordinierte Offenlegung und aktive Ausnutzung
Wir bitten Meldende, eine Schwachstelle erst dann öffentlich offenzulegen, wenn eine Behebung oder Abhilfemaßnahme verfügbar ist oder seit der Bestätigung der Meldung als gültig 90 Kalendertage vergangen sind, je nachdem, welcher Zeitpunkt früher eintritt. Gemeinsam können wir einen anderen Zeitplan vereinbaren.
Wenn Catalogic zu irgendeinem Zeitpunkt feststellt, dass eine gemeldete Schwachstelle der CRA-Definition einer „aktiv ausgenutzten Schwachstelle“ entspricht (Artikel 3 Nummer 42), oder wenn ein schwerwiegender Sicherheitsvorfall die Sicherheit von DPX oder CloudCasa beeinträchtigt, ist Catalogic gesetzlich verpflichtet, das zuständige, als Koordinator benannte CSIRT und die ENISA gemäß CRA Artikel 14 zu benachrichtigen. Die Benachrichtigung erfolgt innerhalb von 24 Stunden nach Kenntniserlangung als Frühwarnung, innerhalb von 72 Stunden als Meldung und anschließend mit einem Abschlussbericht. Diese gesetzliche Verpflichtung läuft parallel zur Abstimmung mit dem Meldenden und ersetzt diese nicht.
8. Komponenten Dritter und Open-Source-Komponenten
Wenn eine gemeldete Schwachstelle aus einer Komponente eines Dritten oder einer Open-Source-Komponente stammt, die in DPX, vStor oder CloudCasa verwendet wird, stimmen wir uns, soweit praktikabel, mit dem zuständigen Maintainer oder Verwalter ab. Dessen Offenlegungszeitplan berücksichtigen wir gemäß CRA Anhang I, Teil II Nummer 6 in unserem eigenen Zeitplan.
9. Schutz gutgläubiger Sicherheitsforschung (Safe Harbor)
Catalogic wird weder rechtliche Schritte gegen Forschende einleiten noch sie Strafverfolgungsbehörden melden, wenn sie: (a) sich nach bestem Wissen und Gewissen bemühen, diese Richtlinie einzuhalten; (b) Verletzungen der Privatsphäre, die Zerstörung von Daten und die Unterbrechung oder Beeinträchtigung unserer Dienste vermeiden; (c) auf Daten nur zugreifen, sie verändern oder exfiltrieren, soweit dies zum Nachweis der Schwachstelle unbedingt erforderlich ist; und (d) den Fund unverzüglich melden und ihn nicht über das für die Überprüfung erforderliche Maß hinaus ausnutzen.
10. Öffentliche Sicherheitshinweise
Sobald eine Behebung verfügbar ist, veröffentlicht Catalogic gemäß CRA Anhang I, Teil II Nummer 4 Sicherheitshinweise zur Schwachstelle, zu betroffenen Produkten und Versionen, zum Schweregrad und zu Maßnahmen zur Behebung. Die Hinweise werden auf catalogicsoftware.com und cloudcasa.io veröffentlicht.
11. Verwaltung dieser Richtlinie
- Verantwortlich: Security-Team
- Überprüfung: mindestens jährlich sowie bei wesentlichen Änderungen der regulatorischen Vorgaben, beispielsweise neuen CRA-Leitlinien der Kommission oder der ENISA, oder bei Änderungen des Produktumfangs.
- Diese Richtlinie gilt gemeinsam für DPX und CloudCasa. Produktspezifische Seiten mit Sicherheitshinweisen können sie ergänzen.