Der Wettlauf zum Patch für OpenSSL hat wieder begonnen
Die geänderte Art und Weise, wie neu entdeckte Schwachstellen offengelegt werden, verdient großes Lob. So kündigten die Betreuer des OpenSSL-Projekts vergangene Woche an, dass am 1. November ein Update für das Projekt herausgegeben wird, das unter anderem eine unbekannte kritische Schwachstelle beheben soll.
Im weiteren Verlauf dieser Woche werden alle, auch Cyberkriminelle, wissen, worin diese Schwachstelle besteht. Die Cybersicherheits-Teams sind jetzt jedoch vorgewarnt und müssen sicherstellen, dass ihre Unternehmen auf die sofortige Installation eines OpenSSL-Updates vorbereitet sind.
Die OpenSSL-Community überwacht die Entwicklung eines Kryptografie-Toolkits zur Sicherung der Kommunikation über das Transport Layer Security (TLS)-Protokoll, auf das sich Websites und Anwendungen weitgehend verlassen. Am bekanntesten ist ein Heartbleed-Bug in OpenSSL, der 2014 entdeckt wurde und es Cyberkriminellen ermöglichte, eine missgestaltete Heartbeat-Anfrage mit einer kleinen Malware-Payload und einem großen Längenfeld an jede anfällige Website oder Anwendung zu senden.
Die Entdeckung dieser Schwachstelle hat zu erheblichen Störungen geführt. In einigen Fällen gab es bis zu drei Jahre nach der Entdeckung des Heartbleed-Bugs immer noch Berichte über Verstöße, die diesen Bug ausnutzten. Der diese Woche veröffentlichte Patch wird die Incident Response vieler Unternehmen auf Sicherheitsvorfälle erneut auf die Probe stellen, da ein erneuter Wettlauf mit der Zeit beginnt. Cyberkriminelle werden den Details der in dieser Woche stattfindenden OpenSSL-Offenlegung zweifellos große Aufmerksamkeit schenken.
Wie genau Schwachstellen offengelegt werden, ist natürlich ein heikles Thema unter vielen Cybersicherheits-Experten. Insbesondere die Open-Source-Gemeinschaft bevorzugt Offenlegungen für die Allgemeinheit, da dies mit dem allgemeinen Ethos eines gemeinschaftlich gepflegten Projekts in Einklang steht. Im Laufe der Jahre ist dies zu einer besonderen Herausforderung geworden, da die Menge des in viele Anwendungen eingebetteten Open-Source-Codes exponentiell gestiegen ist. Viele IT-Organisationen suchen immer noch nach allen Instanzen einer Schwachstelle in der weit verbreiteten Open-Source-Software Log 4J, die zum Sammeln von Protokolldaten von Java-Anwendungen verwendet wird.
Ein Plus ist zumindest, dass eine gute Open-Source-Sicherheitskrise zumindest nicht umsonst war. Die Betreuer von Open-Source-Software-Projekten setzen jetzt auf alles, von der kryptografischen Signierung des Codes bis zur automatischen Erstellung von Software-Stücklisten (SBOMs), mit denen sich leichter herausfinden lässt, wo Instanzen eines beliebigen Codes ausgeführt werden.
Die Frage ist nun, inwieweit die Prozesse zur Incident Response verbessert werden, um auf die zugänglich gemachten Informationen zu reagieren. IT-Teams müssen zunächst in der Lage sein, den Schweregrad einer Schwachstelle zu bestimmen und dann sicherzustellen, dass die besten DevSecOps-Praktiken angewendet werden, um die kritischsten Schwachstellen so schnell wie möglich zu beheben.
In den kommenden Monaten wird es zweifellos Sicherheitsverletzungen geben, die auf anfällige Instanzen von OpenSSL zurückgeführt werden, die nicht gepatcht wurden. Es ist jedoch auch klar, wo die Schuld zunehmend liegen wird, wenn die notwendigen Updates zur Verhinderung dieser Verstöße nicht installiert werden.
