Illustration: Absmeier Geralt
In den letzten Tagen ließ sich beides finden, gespannte Erwartung wie auch Besorgnis hinsichtlich der neuen OpenSSL-Sicherheitslücke. Einige Details wurden bereits am 28. Oktober bekannt, und in Fachkreisen wurde erwartet, dass diese Sicherheitslücke als »kritisch« eingestuft werden würde. Zeitgleich wurde auch ein Patch mit Verfügbarkeitsdatum 1. November angekündigt. Nach dem 1. November wissen wir nun um zwei Dinge: der Schweregrad der Sicherheitslücke wurde mit »hoch« statt mit »kritisch« bewertet und der Patch betrifft zwei Sicherheitslücken.
Was ist passiert?
Es mag kaum überraschen, dass eine OpenSSL-Sicherheitslücke die Aufmerksamkeit der Branche und der Medien auf sich zieht. Mit der anfänglichen Einstufung als »kritisch« war das Medieninteresse stark gestiegen. Dieses Medieninteresse dient realistischerweise zwei unterschiedlichen Zwecken. Erstens wurde die Aufmerksamkeit sowohl in den technischen als auch in den eher nicht-technischen Reihen der Unternehmen, die OpenSSL potenziell verwenden, geweckt. Zweitens wurde das Interesse von Cyberangreifern geweckt. Denn da draußen gibt es etwas, auf das sie ihre R&D-Anstrengungen konzentrieren sollten, angesichts der großen Zielgruppe für mögliche Angriffe.
Ein nicht unwesentlicher Teil des Chaos und des nicht unbeträchtlichen Risikos für die Softwarelieferkette, gehen darauf zurück, dass die Sicherheitslücke veröffentlicht wurde, bevor Patches zur Verfügung standen. Das zog Spekulationen nach sich. Und es führte höchstwahrscheinlich zu Fehlentscheidungen bei denjenigen, die versuchten, ihre Systeme vor einem unbekannten Angriff zu schützen, um auf einen vermeintlich größeren Vorfall zu reagieren.
Was hätte passieren sollen?
Es ist immens wichtig, die Bemühungen im Bereich des Schwachstellenmanagements nicht klein zu reden. Aber was man zwingend braucht sind eine Perspektive und vordefinierte Prozesse – das sind Schlüsselelemente beim Incident Response Management. In der Anfangsphase der Medien- und Community-Reaktion auf die Sicherheitslücke CVE-2022-3602 hatte ich Unternehmen einen proaktiven Scan ihrer gesamten Software mit einem Software Composition Analysis (SCA)-Tool empfohlen. SCA-Tools scannen den Quellcode einer Anwendung und erstellen eine Stückliste (Bill of Materials) für diese Anwendung. Wenn Sie keinen Zugriff auf den Quellcode haben, bieten alle großen SCA-Anbieter eine Option zum Scannen von Binärdateien an, um eine solche Stückliste zu erstellen.
Im Hinblick auf die Incident Response sollte man sämtliche, in einem Unternehmen verwendete Software scannen, unabhängig von ihrer Quelle oder der jeweiligen Rolle. Dazu zählen kommerzielle Software, frei heruntergeladene Software, mobile Anwendungen und Software wie Firmware, die im Lieferumfang einer Hardware enthalten ist. Eine aktuelle, genaue und vollständige Stückliste für die komplette Software ist der Schlüssel zu einer schnellen Vorfallsreaktion – einem Vorfall wie er aufgrund von CVE-2022-3602 zu erwarten ist.
Welchen Nutzen bietet eine Stückliste bei der Incident Response?
Angenommen, Sie verfügen über eine Stückliste für die gesamte Software. Dann können Sie jede Stückliste abfragen und herausfinden, ob die anfällige Version der Software von einer Anwendung referenziert wird oder mit ihr verknüpft ist. Ist das nicht der Fall, gibt es nichts weiter zu tun. Ist es hingegen der Fall, sollten Sie sich für eine Triage entscheiden. Der Einfachheit halber könnten Sie für die bereits veröffentlichte OpenSSL-Schwachstelle einfach alle Anwendungen in die Liste der zu prüfenden Anwendungen aufnehmen, die auf eine Version von OpenSSL verweisen. Wir wissen jetzt, dass die von CVE-2022-3602 betroffenen Versionen 3.0.0 bis 3.0.6 sind. So lässt sich die Triage-Liste weiter filtern und auf genau diese Versionen von OpenSSL beschränken.
Mit einer Liste der zu triagierenden Anwendungen besteht der nächste Schritt darin, herauszufinden, woher der Patch für CVE-2022-3602 kommen soll. SCA-Tools lösen dieses Problem zwar bis zu einem gewissen Grad. Allerdings ist es weitaus zielführender zu wissen, was genau geprüft werden soll. Wenn Sie beispielsweise wissen, dass Sie eine Webanwendung überprüfen, die auf einer Linux-VM läuft, dann sollte der OpenSSL-Patch von der Distribution stammen, die diese Linux-Version erstellt hat. Dieses Paradigma gilt unabhängig davon, ob Sie es mit VMs, Containern, Firmware, mobilen Anwendungen, serverlosen Funktionen oder einem anderen Bereitstellungskontext zu tun haben.
Den Zeitraum bis zur Identifizierung und Beseitigung verkürzen
Natürlich werden nicht alle in Frage kommenden Anbieter ihre Patches zur gleichen Zeit veröffentlichen. Aber wenn die Veröffentlichung einer Schwachstelle unter Verschluss gehalten wird, bis Patches von einer Mehrheit der Patch-Quellen bereitstehen, haben alle die gleichen Ausgangsbedingungen. SCA-Tools etwa verkürzen die Zeit für die Identifizierung betroffener Anwendungen und Implementierungen erheblich. Wenn Sie mit dem Konzept der SBOM vertraut sind, dann bietet es genau denselben Mehrwert wie die BOM eines SCA-Tools. Aber ähnlich wie bei SCA-Tools müssen Sie wissen, wie genau man sie am besten einsetzt, um die potenziellen Auswirkungen zu identifizieren.
Die Zeit bis zur Behebung bemisst sich danach, wie lange es dauert, die Patches zu validieren und zu verteilen. Aber wenn Sie die Zeit bis zur Identifizierung verkürzen können, indem Sie sich auf die Systeme und Anwendungen konzentrieren, die direkt von einer Schwachstelle betroffen sind, passiert das deutlich effizienter und schneller.
Durch den Einsatz von SCA-Tools schicken Sie an Ihre Lieferanten keine E-Mails mehr mit der Frage: »Ist Ihr Unternehmen für OpenSSL anfällig?«, sondern Sie sind proaktiver Teil der Lösung und fragen: »Wir sehen, dass die Awesome Acme Software möglicherweise für CVE-2022-3602 anfällig ist. Können Sie uns einen Zeitplan für die Bereitstellung eines Patches und für vorläufige Abhilfemaßnahmen vorlegen? »
Tim Mackey, Open Source Technology Evangelist bei Synopsys