Erklärung zur koordinierten Offenlegung von Sicherheitslücken

Zweck

Diese Richtlinie legt die grundlegenden Prinzipien und Handhabungsverpflichtungen des Unternehmens für den Empfang, die Validierung, die Kommunikation, die Behebung und die öffentliche Offenlegung von Produktsicherheitslücken fest. Das Unternehmen ermutigt Sicherheitsforscher, Kunden, Partner, Lieferanten und andere relevante Parteien, potenzielle Schwachstellen gemäß dieser Richtlinie zu melden und gemeinsam Risiken für Endnutzer und das Ökosystem durch eine koordinierte Offenlegung zu mindern.

Diese Richtlinie ist in Verbindung mit dem Schwachstellenmanagement-Verfahren des Unternehmens und dem umfassenden Betriebshandbuch zum Umgang mit Schwachstellen anzuwenden. Kontaktinformationen, Bestätigungsfristen, Kommunikationshäufigkeit, sichere Kommunikation, Offenlegungsvereinbarungen und Anerkennungsverpflichtungen, die in der externen Richtlinie genannt werden, müssen durch interne Prozesse, Verantwortlichkeiten des Personals und Aufzeichnungsmechanismen unterstützt werden.

Anwendungsbereich

Diese Richtlinie gilt für digital vernetzte Produkte und zugehörige Dienstleistungen, die unter dem Namen Minifire hergestellt, verkauft, gewartet oder unterstützt werden, einschließlich, aber nicht beschränkt auf Software, Firmware, Hardware, mobile Anwendungen, APIs, Aktualisierungsmechanismen, Standardkonfigurationen und die zugehörigen Cloud-Dienste. Der genaue Umfang der geltenden Produkte richtet sich nach den auf der offiziellen Website, dem Kundenportal oder der Produktsicherheitsseite des Unternehmens veröffentlichten Informationen.

Diese Richtlinie gilt nicht für allgemeine Funktionsfehler, Spam, Social-Engineering-Tests, physische Angriffe, Denial-of-Service-Stresstests, unbefugten Datenzugriff, Tests gegen Systeme Dritter oder Aktivitäten, die gegen geltendes Recht, Kundenverträge oder Nutzungsbedingungen verstoßen. Wenn Meldende unsicher sind, ob ein Problem in den Geltungsbereich dieser Richtlinie fällt, können sie über die in diesem Dokument angegebenen Kanäle zunächst Kontakt aufnehmen.

Meldekanäle

Das Unternehmen unterhält einen oder mehrere Kanäle zur Meldung von Schwachstellen. Wenn ein Meldender einen ersten Hinweis über den allgemeinen Kundensupport oder andere nicht sicherheitsbezogene Kanäle einreicht, muss das Unternehmen die Meldung annehmen und den Meldenden an den offiziellen Sicherheitskanal weiterleiten. Meldungen dürfen nicht allein deshalb abgelehnt werden, weil der ursprüngliche Übermittlungskanal falsch war. Unter den öffentlichen Meldekanälen muss mindestens ein offizieller, nicht personengebundener Zugang bereitgestellt werden, der von außen zugänglich bleibt.

1. Sicherheits-E-Mail: security@expressluck.com
2. Offizielles Website-Portal: https://minifire.com/en/pages/cybersecurity-policy
3. Weitere Kontaktpunkte, z. B. Vertriebsplattformen

Von Meldenden Bereitzustellende Informationen

Um eine schnelle Validierung und Behebung von Schwachstellen zu erleichtern, werden Meldende ermutigt, so viele der folgenden Informationen wie möglich bereitzustellen. Fehlende Teilinformationen führen nicht automatisch zur Ablehnung der Meldung; das Unternehmen kann in nachfolgenden Mitteilungen zusätzliche Informationen anfordern.

• Betroffene Produkte, Modelle, Hardware-Revisionen, Software-/Firmware-Versionen, Komponenten, Konfigurationen, Einsatzumgebungen oder Kundenszenarien.
• Beschreibung der Schwachstelle, Angriffsvoraussetzungen, Auslösebedingungen, Schritte zur Reproduktion, minimaler PoC, Screenshots, Protokolle oder sonstiges Belegmaterial.
• Einschätzung des Meldenden zu den potenziellen Auswirkungen, z. B. ob die Schwachstelle aus der Ferne ausnutzbar ist, ob eine Authentifizierung erforderlich ist, und die Auswirkungen auf Vertraulichkeit / Integrität / Verfügbarkeit.
• Ob die Schwachstelle bereits öffentlich bekannt gemacht wurde, ob eine Ausnutzung vermutet oder bestätigt ist, und ob Lieferanten, Kunden, Koordinierungsorganisationen oder andere Parteien informiert wurden.
• Kontaktdaten des Meldenden, Zeitzone, organisatorische Zugehörigkeit, geplantes Datum der öffentlichen Offenlegung, vorgeschlagener Vertraulichkeitszeitraum, und Präferenz für Namensnennung oder Anonymität.

Meldende sollten davon absehen, Geschäftsgeheimnisse von Kunden, Zugangsdaten, geheime Schlüssel oder andere Informationen zu übermitteln, die über das für die Validierung der Schwachstelle Notwendige hinausgehen. Sollten solche Informationen während der Tests versehentlich abgerufen werden, muss der weitere Zugriff sofort eingestellt und der Umstand in der Meldung vermerkt werden.

Verpflichtungen zu Annahme, Bestätigung und Kommunikation

Nach Eingang einer Schwachstellenmeldung erfasst und priorisiert das Produktsicherheitsteam die Meldung gemäß den internen Verfahren. Unter allgemeinen Umständen wird Minifire den folgenden Kommunikationsrhythmus einhalten:

1. Eine Empfangsbestätigung wird innerhalb von 1 Geschäftstag nach Eingang einer gültigen Meldung zusammen mit einer zugewiesenen Vorgangsnummer (VMR-JJJJ-NNNN) versendet. Diese Vorgangsnummer ist während des gesamten Vorgangs von Priorisierung, Validierung, Behebung, Kommunikation, Offenlegung und Fallabschluss zu referenzieren. Wird dieselbe Schwachstelle wiederholt über mehrere Kanäle gemeldet, werden die Meldungen mit der Originalmeldung verknüpft und erreichbare Meldende erhalten Statusaktualisierungen.
2. Die vorläufige Validierung wird innerhalb von 3 Geschäftstagen abgeschlossen, wobei mitgeteilt wird, ob eine Untersuchung eingeleitet wird, ob zusätzliche Informationen erforderlich sind, oder ob die Angelegenheit außerhalb des Geltungsbereichs dieser Richtlinie liegt.
3. Während der Validierung und Behebung werden dem Meldenden mindestens alle 15 Kalendertage Statusaktualisierungen bereitgestellt; bei wesentlichen Änderungen erfolgt eine zeitnahe Kommunikation.
4. Sobald eine Schwachstelle bestätigt ist, teilt das Unternehmen den geplanten Behebungsansatz, temporäre Abhilfemaßnahmen, Vereinbarungen zur koordinierten Offenlegung und den voraussichtlichen Zeitpunkt der öffentlichen Veröffentlichung mit.
5. Nach Abschluss der Behebung, Abhilfemaßnahme oder Fallabschluss informiert das Unternehmen den Meldenden über die Abschlussergebnisse, Links zu Sicherheitshinweisen, Anerkennungsvereinbarungen und weiterführende Unterstützungsmöglichkeiten.

Sichere Kommunikation und Informationsschutz

Schwachstellenmeldungen und Koordinierungsabläufe können Details zur Ausnutzung, PoC-Dateien, Protokolle, Zugangsdaten, geheime Schlüssel, Kundendaten oder nicht öffentliche Informationen zur Behebung enthalten. Das Unternehmen beschränkt den Zugriff nach dem Need-to-know-Prinzip und übermittelt sowie speichert sensible Informationen über geschützte Kanäle.

• Erstmeldungen können per normaler E-Mail oder über die Support-Kanäle der offiziellen Minifire-Website eingereicht werden; sensible Details und Anhänge müssen zeitnah auf geschützte Kanäle wie sichere Formulare oder verschlüsselte E-Mails migriert werden. Sichere Kommunikationsmethoden müssen sowohl die Vertraulichkeit als auch die Integrität der Nachricht wahren, z. B. HTTPS-gesicherte Formulare, PGP/S-MIME-verschlüsselte oder signierte E-Mails, kontrollierte Kundenportale.
• Nicht öffentliche Schwachstelleninformationen dürfen nicht an unbefugtes Personal weitergeleitet, in frei zugängliche Repositorys hochgeladen oder in öffentlichen Chatgruppen oder unkontrollierten Plattformen besprochen werden.
• Für Tickets, Code-Repositorys, gemeinsame Laufwerke, Mailinglisten und Besprechungsprotokolle müssen angemessene Zugriffsberechtigungen gelten; wichtige Zugriffs- und Kommunikationsaufzeichnungen müssen aufbewahrt werden.
• Müssen Schwachstelleninformationen mit Lieferanten, Betreuern von Open-Source-Projekten, CERT/CSIRT-Stellen, Kunden oder Aufsichtsbehörden geteilt werden, wird nur das für Koordination, Behebung oder Nutzerschutz unbedingt erforderliche Mindestmaß an Informationen offengelegt.

Koordinierte Offenlegung und Vertraulichkeitszeitraum

Das Unternehmen und die Meldenden können einen angemessenen Vertraulichkeitszeitraum und ein Datum für die öffentliche Offenlegung verhandeln. Der Vertraulichkeitszeitraum wird unter Berücksichtigung des Schweregrads der Schwachstelle, der Komplexität der Behebung, der Komplexität der Koordination zwischen vor- und nachgelagerten Beteiligten, der Kritikalität des Produkts, des Status einer aktiven Ausnutzung, bereits vorhandener öffentlicher Offenlegungen, der von Nutzern benötigten Zeit zur Implementierung von Updates sowie anwendbarer rechtlicher oder vertraglicher Anforderungen festgelegt.

Bis Behebungs- oder Abhilfemaßnahmen verfügbar sind, müssen sowohl die Meldenden als auch das Unternehmen davon absehen, technische Details öffentlich zu machen, die das Ausnutzungsrisiko erhöhen könnten. Wenn Schwachstelleninformationen vorzeitig offengelegt werden, eine aktive Ausnutzung erfolgt, der Meldende eine vorzeitige Veröffentlichung beabsichtigt oder Nutzerrisiken eine frühere Benachrichtigung erfordern, muss das Unternehmen unverzüglich an den Produktsicherheitsverantwortlichen sowie an die Rechts- / Compliance-Verantwortlichen eskalieren, um die Offenlegungsvereinbarungen neu zu bewerten und zu prüfen, ob externe Verpflichtungen zu Sicherheitshinweisen ausgelöst werden.

Behebung, Sicherheitshinweise und Nutzerbenachrichtigungen

Nach Bestätigung der Schwachstelle steuert das Unternehmen die Behebung, temporäre Abhilfemaßnahmen, Validierungstests und die Release-Vorbereitung entsprechend der Risikoeinstufung und den Produktsupport-Richtlinien. Sind Komponenten Dritter, Open-Source-Projekte, Hardware-Lieferanten, Cloud-Dienste oder Vertriebspartner betroffen, koordiniert das Produktsicherheitsteam vor- und nachgelagerte Beteiligte, um die Auswirkungsanalyse und Behebungsplanung abzuschließen.

Sicherheitshinweise werden in der Regel veröffentlicht, nachdem behobene Versionen, Patches, Konfigurations-Abhilfemaßnahmen oder andere risikomindernde Maßnahmen verfügbar sind. Die Hinweise müssen ausreichende Informationen enthalten, damit Zielnutzer die Relevanz einschätzen und Maßnahmen ergreifen können; dies umfasst typischerweise: Beschreibung der Schwachstelle, Schwachstellenkennungen, betroffene Produkte und Versionen, potenzielle Auswirkungen, Schweregradbewertung, Behebungs- / Abhilfemaßnahmen, Veröffentlichungsdatum, Überarbeitungsdatum, Kontaktdaten für den Support sowie Anerkennung der Meldenden, sofern eine Zustimmung erteilt wurde.

Würde die vollständige öffentliche Veröffentlichung technischer Details ein größeres Angriffsrisiko als Sicherheitsvorteil schaffen, kann das Unternehmen betroffenen Nutzern zunächst risikomindernde Informationen und Behebungsmaßnahmen zusammen mit einem geplanten Datum für die vollständige Offenlegung bereitstellen. Eine verzögerte vollständige Offenlegung muss vom Produktsicherheitsverantwortlichen, dem zuständigen Produktverantwortlichen und dem Rechts- / Compliance-Verantwortlichen genehmigt und dokumentiert werden.

Zu Stellungnahmen

Das Unternehmen schätzt die Beiträge der Sicherheitsforschungs-Community zur Produktsicherheit. Nach Behebung und Offenlegung der Schwachstelle kann das Unternehmen mit Zustimmung des Meldenden diesen in Sicherheitshinweisen, Danksagungsseiten oder internen Aufzeichnungen anerkennen.

Soweit gesetzlich zulässig, wird das Unternehmen keine nachteiligen rechtlichen Schritte gegen in gutem Glauben durchgeführte Sicherheitsforschung einleiten, die im Einklang mit dieser Richtlinie steht und zeitnah gemeldet wurde. Diese Verpflichtung gilt nicht für Aktivitäten, die gegen Gesetze verstoßen, auf Systeme Dritter zugreifen, Dienste stören, Daten exfiltrieren, Erpressung begehen, Drohungen aussprechen oder sonstiges Verhalten außerhalb des Geltungsbereichs dieser Richtlinie darstellen.

Anerkennung, Haftungsfreistellung (Safe-Harbour) und Haftungsbeschränkung

Das Unternehmen schätzt die Beiträge der Sicherheits-Community zur Produktsicherheit. Nach Behebung und Offenlegung der Schwachstelle kann das Unternehmen mit Zustimmung des Meldenden dessen Beitrag öffentlich in Sicherheitshinweisen, Danksagungsseiten oder internen Aufzeichnungen anerkennen. Meldende können anonym bleiben oder eine festgelegte Namensnennung verwenden.

Soweit gesetzlich zulässig, wird das Unternehmen keine nachteiligen rechtlichen Schritte gegen in gutem Glauben durchgeführte Sicherheitsforschung einleiten, die im Einklang mit dieser Richtlinie in gutem Glauben durchgeführt und zeitnah gemeldet wurde. Diese Verpflichtung gilt nicht für Verhalten, das gegen Gesetze verstößt, auf Systeme Dritter zugreift, Dienste stört, Daten exfiltriert, Erpressung begeht, Drohungen ausspricht oder sonstige Aktivitäten außerhalb der Grenzen dieser Richtlinie darstellt.

Aufzeichnungen, Überprüfung und Kontinuierliche Verbesserung

Das Unternehmen bewahrt Richtlinienversionen, Links zu öffentlichen Seiten, Aufzeichnungen zur Kanalvalidierung, Schwachstellenmeldungen, Kommunikationsprotokolle, Nachweise sicherer Kommunikation, Offenlegungsentscheidungen, Überarbeitungen von Sicherheitshinweisen, Anerkennungsbestätigungen, Validierungsaufzeichnungen zur Behebung und Aufzeichnungen zum Fallabschluss auf. Die Aufbewahrungsfristen müssen den Produktsupport-Lebenszyklus abdecken und die geltenden regulatorischen, vertraglichen und kundenseitigen Anforderungen erfüllen (Schwachstellenregister müssen mindestens 10 Jahre oder für die Dauer des Produktsupport-Lebenszyklus aufbewahrt werden, je nachdem, was länger ist).

Der Produktsicherheitsverantwortliche organisiert mindestens jährlich / halbjährlich eine Überprüfung der Richtlinie, um die Funktionsfähigkeit der Meldekanäle, die Zugänglichkeit der öffentlichen Seiten, die Einhaltbarkeit der Kommunikationsfristen, die Wirksamkeit der sicheren Kommunikation, die Vollständigkeit der Sicherheitshinweise sowie den Umgang mit Nutzer- und Meldenden-Feedback zu überprüfen. Festgestellte Lücken werden in Verbesserungsmaßnahmen umgewandelt und bis zum Abschluss nachverfolgt.