IT-Sicherheitslücken: Transparenz muss sein

In meiner Jugend hörte ich von einem Administrator häufig den Spruch „Never change a running system“ – sehr frei übersetzt: „Finger weg von Systemen, die laufen.“ Dass dies so nicht mehr gilt, ist heute allen Administrator*innen bewusst. Täglich werden Meldungen über neue IT-Schwachstellen veröffentlicht, die eine Reaktion erfordern, in einigen Fällen sogar direktes Handeln.

Veröffentlichung von Sicherheitslücken – ein Blick hinter die Kulissen

In meinem Blogbeitrag möchte ich diese Meldungen zu neuen Sicherheitslücken einmal genauer beleuchten. Wie werden IT-Schwachstellen überhaupt entdeckt – und wie lassen sie sich beheben? Hier sei direkt darauf hingewiesen, dass es nicht nur den einen Weg gibt, sondern eine Vielzahl von unterschiedlichen Möglichkeiten. Der in diesem Artikel skizzierte Weg kann also nur als Beispiel verstanden werden.

Der klassische Weg: Vor einem Update oder der Markteinführung seines Produkts – dabei kann es sich um eine beliebige Applikation, eine mobile Smartphone-App oder ein Smart TV handeln – beauftragt der Hersteller ein Dienstleistungsunternehmen, einen Penetrationstest durchzuführen. Dabei wird durch Expert*innen geprüft, ob es in dem Testobjekt Fehler gibt, die es Hackern leicht machen könnten, vertrauliche Daten einzusehen, in das System einzudringen oder das Produkt in seiner Funktion zu beinträchtigen. Wird ein solcher Fehler gefunden, spricht man von einer Sicherheitslücke oder auch Vulnerability. Nach einer Bewertung der Ergebnisse werden Maßnahmen ergriffen, um die Sicherheitslücke zu schließen. Ist das Produkt bereits im Einsatz, so ist es mittlerweile üblich, dies im Rahmen der Versionshistorie aufzuzeigen und nach Möglichkeit eindeutig mit einer CVE-ID zu kennzeichnen. CVE steht für Common Vulnerabilities and Exposures und ist ein Industriestandard zur Benennung öffentlich bekannter Sicherheitslücken. Ein Beispiel wäre etwa „CVE-2020-0001“. Die ID besteht aus der Bezeichnung „CVE“, gefolgt von der Jahreszahl und einer fortlaufenden Nummer.

Aufgedeckte Sicherheitslücken – ein Reputationsschaden?

Häufig höre ich die Frage, warum ein Hersteller freiwillig bekannt geben sollte, dass sein Produkt von einer Sicherheitslücke betroffen ist? Ist das nicht kontraproduktiv? Die Antwort ist komplex. Natürlich ist das Eingestehen von Fehlern der Reputation eines Unternehmens auf den ersten Blick nicht zuträglich.

Schwachstellen verheimlichen – ein gefährlicher Fehler

Dies verdeutlicht auch, dass eine reine Fehlervermeidungsstrategie nicht die Lösung sein kann. Vielmehr ist ein ganzheitlicher Ansatz notwendig, der auch den koordinierten und verantwortungsvollen Umgang mit vorhandenen Sicherheitslücken einschließt – insbesondere auch das Bekanntmachen von Schwachstellen in eigenen Produkten über die Unternehmenswebseite. Vor allem, wenn das Produkt weltweit millionen- oder milliardenfach eingesetzt wird, kann eine transparente Kommunikation von Schwachstellen der Unternehmensreputation langfristig nur dienlich sein.

Wechseln wir die Perspektive vom Hersteller des Produkts, bei dem eine Sicherheitslücke erkannt wurde, zu dem Unternehmen, das dieses Produkt einsetzt. In Unternehmen wird heute eine Vielzahl von Softwareanwendungen betrieben, die eine regelmäßige Wartung erfordern. Dazu gehört auch die Aktualisierung der Software. Wer in seinem Leben schon einmal ein Update durchgeführt hat, weiß, dass es dabei zu Problemen kommen kann. Daher werden Aktualisierungen im Vorfeld häufig auf einem Testsystem durchgeführt. Korrekturversionen bzw. Patches werden somit selten sofort eingespielt, sondern es vergeht Zeit. Auch werden nicht immer alle Patches eingespielt. Wird beispielsweise mit einem Update lediglich die Farbe eines Symbols geändert, so kann der Patch auch verschoben werden.

Nehmen wir nun an, dass ein Software-Hersteller versucht zu verheimlichen, dass es in seiner Software eine schwerwiegende Sicherheitslücke gab. Um das Problem still und heimlich beheben zu können, gibt er einen Patch heraus, der eine von den Anwendern gewünschte Funktion hinzufügt – beispielsweise eine neue Farbe für die Symbolleiste. Gleichzeitig wird auch die Sicherheitslücke geschlossen, aber ohne dies explizit zu erwähnen. In letzter Konsequenz könnte dies bedeuten, dass die IT-Abteilung des betroffenen Unternehmens sich dazu entschließt, das Update erst in einem halben Jahr einzuspielen – oder gar nicht. Hat jetzt ein Hacker mit seinem Angriff Erfolg, weil die Sicherheitslücke verheimlicht wurde, dürfte der Reputationsschaden bedeutend größer sein als der Schaden, der entsteht, wenn offen über eine Schwachstelle gesprochen wird.

To be continued…