Offenlegung von Sicherheitslücken

Nehmen wir an, es wurde eine Schwachstelle in einem Penetrationstest oder einfach aufgrund von Neugier identifiziert. Dann könnten wir diesen einfachen Prozess Schritt für Schritt abarbeiten.

Die Abfolge wäre dann also 1. Identifizieren, 2. Weiterleiten, 3. Beheben und 4. Veröffentlichen.

Natürlich ist es in der Realität aber meist leider nicht ganz so einfach. Warum es vielleicht doch nicht so ganz trivial ist, welche verschiedenen Perspektiven und Interessen berücksichtigt werden sollten und welche Abläufe es gibt, dem wollen wir etwas genauer auf den Grund gehen.

Warum sollten Hersteller Sicherheitslücken offenlegen?

Bei der Entwicklung von Hardware und Software auf dem heutigen Komplexitätslevel ist es unrealistisch, dass sich nicht hier und dort einmal ein Fehler einschleicht. Trotz intensiven Testens von diesen komplexen IT-Systemen werden nicht alle Fehler durch interne Experten identifiziert und behoben. Viele Fehler werden erst von Anwendern bemerkt oder von Sicherheitsforschern aufgedeckt.

Die Offenlegung von Sicherheitslücken kann eine kontroverse Angelegenheit sein und es gibt verschiedene Perspektiven dazu.

Schaffung von Transparenz und Vertrauen

Die Offenlegung von Sicherheitslücken schafft Transparenz für Anwender, Betreiber und Administratoren, die für die Sicherheit der von Ihnen eingesetzten Software und Systeme verantwortlich sind.

Erhöhung der Sicherheit

Die Offenlegung von Schwachstellen kann Sicherheitsforschern und Entwicklern helfen. Durch eine detaillierte Beschreibung von Schwachstellen können eventuell ähnliche Sicherheitslücken in anderen Systemen von Sicherheitsforschern identifiziert werden. Das Wissen über neue Angriffstechniken oder Fehler kann Entwicklern helfen, diese im eigenen Secure Software Development Life Cycle (SSDLC) zu berücksichtigen. Folglich wird die Sicherheit von Software und Systemen für alle verbessert.

Einfordern von Verantwortung aus Anwendersicht

Durch die Veröffentlichung von Schwachstellen werden Hersteller und Entwickler in die Verantwortung genommen und aufgefordert, die Sicherheit ihrer Produkte zu verbessern.

Schutz der Nutzer

Indem Schwachstellen veröffentlicht werden, können Benutzer informiert werden und Maßnahmen ergreifen und aktiv werden, um sich selbst zu schützen. Dies kann beispielsweise das Aktualisieren von Software durch das Einspielen von Patches oder das Implementieren zusätzlicher Sicherheitsmaßnahmen umfassen.

Offenlegung in Abstimmung

Es ist wichtig, dass Schwachstellen verantwortungsbewusst offengelegt werden, um potenzielle Risiken zu minimieren und die Sicherheit der Benutzer nicht zu gefährden. Hierzu wird ein Prozess der verantwortungsvollen Offenlegungangewendet, bei dem Schwachstellen den Herstellern zunächst vertraulich gemeldet werden, um ihnen die Möglichkeit zu geben, Patches zu entwickeln, bevor die Schwachstellen öffentlich bekannt gemacht werden.

Was sind die Vorteile und Nachteile für Hersteller durch die Veröffentlichung von Sicherheitslücken?

In der Tat kann es einige Nachteile oder Fallstricke, jedoch auch einige Vorteile für Hersteller und Entwickler geben, wenn Schwachstellen veröffentlicht werden. Wichtig ist hier die Kommunikation. Wird die Offenlegung der Schwachstellen koordiniert und transparent durchgeführt, können aus Nachteilen ganz schnell Vorteile werden.

Reputationsschaden, Wettbewerbsnachteile oder Vertrauensbildung

Die Offenlegung von Schwachstellen kann das Vertrauen der Kunden in die Sicherheit von Produkten beeinträchtigen und zu einem Reputationsschaden und Wettbewerbsnachteilen führen, wenn diese nicht optimal kommuniziert wird. Um aktuelle Kunden nicht an Mitbewerber zu verlieren, ist eine schnelle Reaktion und klare Kommunikation an Kunden notwendig.

Wenn ein Hersteller Schwachstellen offenlegt und schnell Maßnahmen ergreift, um sie zu beheben, kann dies den Ruf des Unternehmens als verantwortungsbewusster Akteur im Bereich der Cybersicherheit stärken. Werden Schwachstellen mit Unterstützung von Herstellern und Entwicklern veröffentlicht, schafft dies Vertrauen bei Kunden und Sicherheitsforschern. Dies kann langfristig das Vertrauen der Kunden stärken und die Markenreputation verbessern, was sich positiv auf die Wahrnehmung des Unternehmens durch Kunden, Partner und die breitere Sicherheitsgemeinschaft auswirkt.

Richtig umgesetzt kann ein Sicherheitsvorfall sogar zu einer höheren Wertschätzung führen und statt eines Reputationsschadens ein positives Signal auch für den Umgang in Zukunft senden und eventuell sogar einen Wettbewerbsvorteil darstellen.

Druck zur schnellen Reaktion und Einhaltung von Regularien

Sobald eine Schwachstelle öffentlich bekannt ist, kann der Druck auf Hersteller und Entwickler zunehmen, schnell einen Patch oder eine Lösung bereitzustellen. Desto länger eine Schwachstelle öffentlich bekannt und nicht behoben ist, desto höher ist die Wahrscheinlichkeit, dass sie von Angreifern ausgenutzt wird.

Werden Nutzer angegriffen, erleiden nicht nur diese einen Schaden, sondern auch der verantwortliche Hersteller. Die schnelle und saubere Behebung dieser Schwachstelle kann je nach Umstand erhebliche zeitliche und finanzielle Ressourcen in Anspruch nehmen. Es wird dann nicht nur vom Hersteller erwartet, dass dieser schnell reagiert, sondern auch, dass der Patch effektiv ist und keine neuen Probleme verursacht.

In einigen Fällen können Hersteller rechtlichen Anforderungen unterliegen, Schwachstellen offenzulegen. Durch die Einhaltung dieser Anforderungen können Hersteller potenzielle rechtliche Probleme vermeiden und das Risiko von Bußgeldern oder anderen Sanktionen verringern.

Aus diesem Grund muss die Offenlegung koordiniert erfolgen und erst, wenn ein Patch oder eine andere Gegenmaßnahme vorhanden ist. Dies erfordert die Zusammenarbeit mit Sicherheitsforschern und Behörden, um Schäden vom Unternehmen und Nutzern fernzuhalten.

Proaktiv oder Passiv? Kosten für Sicherheitsmaßnahmen

Die Behebung von Schwachstellen und die Implementierung zusätzlicher Sicherheitsmaßnahmen können erhebliche Kosten verursachen, sowohl in Bezug auf die Entwicklung von Patches als auch auf die Sicherheitsüberprüfungen und -verbesserungen. Insbesondere, da solche Lücken oft ungeplant identifiziert werden. Wird eine Lücke jedoch aufgedeckt, veröffentlicht und nicht oder erst spät auf externen Druck behoben, können die Kosten erheblich höher sein und zusätzlich mit Reputationsschäden und rechtlichen Problemen einhergehen.

Aus diesem Grund ist es wichtig, dass Hersteller und Entwickler proaktiv auf solche Szenarien reagieren. Nicht nur sollten regelmäßige Tests der Software und Systeme durchgeführt werden, auch sollte ein Ablaufplan für die Kommunikation und Behebung von extern gemeldeten Schwachstellen existieren.

Kundenzufriedenheit

Schwachstellen sind allgegenwärtig und werden auch in den Medien thematisiert. Kunden und Anwender können sich über verschiedene Kanäle ein Bild von einem Hersteller machen. Werden Schwachstellen verheimlicht und gehen dann Daten von Kunden verloren, kann dies, durch die schnelle Verbreitung in der heutigen Medienlandschaft, zu einem Verlust der Kunden führen.

Durch die Offenlegung von Schwachstellen und die Bereitstellung von Patches oder Lösungen zeigen Hersteller, dass sie die Sicherheit von Kunden ernst nehmen und bereit sind, die notwendigen Schritte zu unternehmen, um sie zu schützen. Transparenz und proaktive Sicherheitsmaßnahmen werden von Kunden wertgeschätzt und schaffen eine höhere Kundenzufriedenheit.

Sicherheitsforschung und -entwicklung

Zeigt ein Unternehmen ein geringes Interesse an Zusammenarbeit mit Sicherheitsforschern oder verklagt diese womöglich aufgrund einer Mitteilung einer Sicherheitslücke, kann dies negative Folgen für den zukünftigen Umgang mit Schwachstellen seitens der Sicherheitsforscher haben.

Daher sollte die Offenlegung von Schwachstellen in Betracht gezogen werden. Dies kann dazu beitragen, dass Sicherheitsforscher und Entwickler auf potenzielle Probleme aufmerksam werden und dazu beitragen, sicherere Produkte zu entwickeln.

Folglich kann dies ein Beitrag sein, das Sicherheitsniveau von Produkten langfristig zu verbessern und potenzielle weitere Schwachstellen proaktiv anzugehen. Des Weiteren sind Beispiele für koordiniert veröffentlichte Sicherheitslücken ein Anreiz für Sicherheitsforscher Produkte zu analysieren und neue Sicherheitslücken direkt an den Hersteller zu melden, anstatt diese einfach zu veröffentlichen.

Wie stehen wir als NSIDE zu dem Thema?

Trotz eventueller Fallstricke ist ein transparenter Umgang mit Sicherheitslücken unumgänglich. Es ist nicht unüblich, dass Schwachstellen aus den bereitgestellten Patches zurückgerechnet werden und somit über Umwege unkontrolliert veröffentlicht werden. Generell sehen wir die Offenlegung von Schwachstellen als einen entscheidenden Schritt im Kampf gegen Cyberkriminalität und die Aufrechterhaltung und Verbesserung der Sicherheit von Software und Systemen unserer Kunden.

Was ist Responsible Vulnerability Disclosure und Coordinated Vulnerability Disclosure?

Die Veröffentlichung von Schwachstellen oder Sicherheitslücken sollte immer verantwortungsvoll und koordiniert erfolgen. Aus diesem Grund haben sich Responsible Vulnerability Disclosure (RVD) und nachfolgend Coordinated Vulnerability Disclosure (CVD) entwickelt.

Während RVD aus dem Bereich der Mitteilung von Sicherheitslücken an Hersteller durch externe Sicherheitsforscher kommt, wurde CVD als Modell für interne Prozesse entwickelt.

Das Modell des Responsible Vulnerability Disclosure erlaubte keine Veröffentlichung von Schwachstellen, bis diese vom Hersteller behoben waren. Dieser Umstand wurde von einigen wenigen genutzt, um Sicherheitslücken über lange Zeiträume nicht zu beheben. Inzwischen ist der de facto Standard Coordinated Vulnerability Disclosure. Sollten Hersteller und Entwickler auf Meldungen nicht reagieren und z. B. Sicherheitslücken bereits aktiv ausgenutzt werden, erfolgt eine Veröffentlichung z. B. in Zusammenarbeit mit einem Computer Emergency Response Team (CERT).

Es gibt verschiedene Coordinated Vulnerability Disclosure Policies. Das Google Project Zero hat z. B. eine Veröffentlichungsfrist von 90-Tagen nach Meldung an den Hersteller und die ZeroDayInitiave (ZDI) von 120 Tagen nach der ersten Rückmeldung seitens des Herstellers auf die gemeldete Schwachstelle.

Die Coordinated Vulnerability Disclosure Policy der NSIDE ATTACK LOGIC GmbH beträgt 60 Tage nach Meldung an den Hersteller, jedoch betrifft dies nur die Veröffentlichung, wenn sich ein Hersteller nicht meldet oder die Schwachstelle nicht als solche anerkennt. In der Regel wird eine Schwachstelle in Zusammenarbeit mit dem Hersteller veröffentlicht. Hier gehts zum Download der NSIDE Vulnerability Disclosure Policy.

Sicherheitslücken in Software, welche ausschließlich bei Kunden intern entwickelt und verwendet wird, werden grundsätzlich nicht veröffentlicht, da hier kein öffentliches Interesse bzw. kein Mehrwert für die Öffentlichkeit besteht.

Es gibt verschiedene Schwachstellen-IDs von verschiedenen Herstellern. Der bekannteste Standard zur Veröffentlichung von Schwachstellen ist Common Vulnerabilities and Exposures (CVE) und die Zuordnung von CVE IDs zu einer eindeutigen Schwachstelle mit dem Schema CVE-YYY-ID. Dieser Standard wird auch oft zusätzlich von Herstellern zu der eigenen Schwachstellen-ID verwendet. Ein Beispiel für eine CVE-ID ist CVE-2022-1337.

Fazit

Ob und wie Schwachstellen veröffentlicht werden, kommt immer auf den Einzelfall an.

Schwachstellen ohne öffentliches Interesse bzw. ohne einen Mehrwert für die Öffentlichkeit sollten nicht veröffentlicht werden. Des Weiteren würden hier betriebsinterne Informationen eines einzelnen Anwenders/Entwicklers nach außen getragen.

Anders sieht es aus, wenn die Schwachstelle externe Dritte betrifft, z. B. ein unautorisierter Datenzugriff. In diesem Fall könnte sogar die Pflicht der Veröffentlichung bestehen. Dies sollte mit der zuständigen Datenschutzstelle abgestimmt werden.

Handelt es sich um eine Schwachstelle in Software, die von verschiedenen Parteien verwendet wird (öffentliches Interesse), sollte eine Veröffentlichung in Erwägung gezogen werden. Hier liegt dann jedoch die Krux im Detail. Wann an wen welche Informationen herausgegeben werden, kann den Unterschied machen zwischen einer Erfolgsgeschichte oder Schaden für die Reputation.

Die NSIDE rät generell zu einem transparenten Umgang mit Sicherheitslücken und der entsprechenden Veröffentlichung unter Einhaltung von Best Practices und Standards wie Common Vulnerabilities and Exposures (CVE). Decken wir als NSIDE Sicherheitslücken oder Schwachstellen in Systemen auf, unterstützen wir gerne bei der koordinierten Veröffentlichung der Schwachstellen mittels Beantragung einer CVE ID – Mehr zum Thema CVE dann in einem späteren Blogpost.