Zero-Day-Angriffe sind auf dem Vormarsch. Es ist an der Zeit, einen Verteidigungsvorsprung zu planen.

Eine Version dieses Artikels erschien in SC-Magazin. Er wurde hier geändert und syndiziert.
Wenn

Sie schon einmal einen Einbruch erlebt haben, kennen Sie das Gefühl, dass etwas nicht stimmt, gefolgt von der Erkenntnis, dass Sie tatsächlich bestohlen wurden. Das führt in der Regel zu dauerhaftem Unbehagen, ganz zu schweigen davon, dass man Sicherheitsmaßnahmen ergreift, die es mit Fort Knox aufnehmen könnten.

Stellen Sie sich nun vor, dass in Ihr Haus eingebrochen wird, weil die Diebe sich einen Schlüssel gemacht haben. Sie schleichen herum, kommen und gehen, wie es ihnen gefällt, aber sie achten darauf, unentdeckt zu bleiben. Eines Tages bemerken Sie zu spät, dass der Schmuck, den Sie in der Gefriertruhe versteckt haben, verschwunden ist, dass Ihr Tresor geleert wurde und dass Ihre persönlichen Gegenstände durchwühlt worden sind. Dies ist die gleiche Realität, mit der ein Unternehmen konfrontiert wird, wenn es Opfer eines Zero-Day-Cyberangriffs wird. Im Jahr 2020 ergab eine Studie des Ponemon Institute, dass 80 % der erfolgreichen Datenschutzverletzungen das Ergebnis von Zero-Day-Angriffen waren, und leider sind die meisten Unternehmen nach wie vor nicht in der Lage, diese Statistik deutlich zu verbessern.

Bei Zero-Day-Angriffen bleibt den Entwicklern definitionsgemäß keine Zeit, vorhandene Schwachstellen zu finden und zu beheben, da der Bedrohungsakteur zuerst eingedrungen ist. Der Schaden ist angerichtet, und dann ist es ein verrücktes Gedränge, um sowohl die Software als auch den Imageschaden für das Unternehmen zu beheben. Angreifer sind immer im Vorteil, und es ist von entscheidender Bedeutung, diese Lücke so weit wie möglich zu schließen. 

Das Weihnachtsgeschenk, das sich niemand gewünscht hat - Log4Shell - macht derzeit das Internet unsicher, da über eine Milliarde Geräte von dieser katastrophalen Java-Schwachstelle betroffen sein sollen. Es zeichnet sich ab, dass dies der schlimmste 0day-Angriff aller Zeiten sein wird, und wir stehen erst am Anfang. Obwohl in einigen Berichten behauptet wird, dass die Angriffe bereits einige Tage vor der Veröffentlichung begonnen haben, deutet eine Präsentation auf der Black Hat Conference 2016 darauf hin, dass dieses Problem schon seit einiger Zeit bekannt ist. Autsch. Noch schlimmer ist, dass es schmerzhaft einfach auszunutzen ist und jeder Skript-Kiddie und Bedrohungsakteur auf dem Planeten hinter dieser Sicherheitslücke her ist.

Was ist also der beste Weg, um sich gegen eine schlüpfrige, unheimliche Bedrohung zu verteidigen, ganz zu schweigen von Schwachstellen, die bei der Softwareentwicklung übersehen wurden? Werfen wir einen Blick darauf. 

Zero-Day-Angriffe auf große Ziele sind selten (und teuer)

Es gibt einen riesigen Markt für Exploits im Dark Web, und Zero-Days werden oft für viel Geld verkauft. Ein Beispiel in diesem Artikel wird zum Zeitpunkt der Erstellung dieses Artikels für 2,5 Millionen Dollar angeboten. Berichten zufolge handelt es sich um ein Exploit für Apple iOS. Es überrascht daher nicht, dass der Preis für den Sicherheitsforscher so hoch ist, schließlich könnte dies das Tor sein, um Millionen von Geräten zu kompromittieren und Milliarden von sensiblen Datensätzen abzugreifen, und das so lange wie möglich, bevor es entdeckt und gepatcht wird.

Aber wer hat schon so viel Geld? Normalerweise bringen organisierte Cyberkriminelle das Geld auf, wenn sie es für lohnenswert halten, insbesondere bei den beliebten Ransomware-Angriffen. Aber auch Regierungen und Verteidigungsministerien weltweit gehören zu den Abnehmern von Exploits, die sie für Bedrohungsanalysen nutzen können, und in positiveren Szenarien können die Unternehmen selbst Käufer ihrer eigenen potenziellen Zero-Day-Exploits sein, um eine Katastrophe zu verhindern. 

ImJahr 2021 wurden Rekorde bei der Entdeckung von Zero-Day-Exploitsgebrochen, und es sind große Organisationen, Regierungsstellen und Infrastrukturen, die am meisten gefährdet sind, auf Schwachstellen untersucht zu werden. Es gibt keine Möglichkeit, sich völlig vor der Möglichkeit eines Zero-Day-Angriffs zu schützen, aber Sie können das Spiel ein wenig "mitspielen", indem Sie ein großzügiges und gut strukturiertes Bug-Bounty-Programm anbieten. Anstatt zu warten, bis jemand die Schlüssel zu Ihrem Software-Schloss auf einem Dark-Web-Marktplatz anbietet, sollten Sie legitime Sicherheitsexperten auf Ihre Seite ziehen und ihnen eine anständige Belohnung für die ethische Offenlegung und mögliche Fehlerbehebung anbieten.

Und wenn es sich zufällig um eine haarsträubende Zero-Day-Bedrohung handelt, können Sie davon ausgehen, dass Sie mehr als einen Amazon-Gutschein ausgeben müssen (und es wird sich lohnen).

Ihre Werkzeuge könnten eine Belastung für Ihr Sicherheitspersonal darstellen

Schwerfällige Sicherheitstools sind schon seit langem ein Problem. Der durchschnittliche CISO verwaltet zwischen 55 und 75 Tools in seinem Sicherheitsarsenal. Abgesehen davon, dass es sich dabei um das verwirrendste (metaphorische) Schweizer Taschenmesser der Welt handelt, sind 53 % der Unternehmen laut einer Studie des Ponemon Institute nicht einmal davon überzeugt, dass sie effektiv arbeiten. Eine andere Studie ergab, dass nur 17 % der CISOs der Meinung sind, dass ihr Sicherheits-Paket "vollkommen effektiv" ist.

In einem Bereich, der für sein Burnout, den Mangel an Sicherheitsfachkräften und den Bedarf an Flexibilität bekannt ist, ist es sehr belastend, wenn Sicherheitsexperten gezwungen sind, mit einer Informationsflut in Form von Daten, Berichten und der Überwachung riesiger Toolsets zu arbeiten. Dies ist genau die Art von Szenario, die dazu führen kann, dass sie einen kritischen Alarm übersehen, was durchaus der Fall gewesen sein kann, als es darum ging, die Schwachstellen von Log4j richtig zu bewerten. 

Vorbeugende Sicherheit sollte eine entwicklergesteuerte Bedrohungsmodellierung beinhalten

Schwachstellen auf Code-Ebene werden häufig von Entwicklern eingebracht, und sie benötigen eine genaue Anleitung und regelmäßige Lernwege, um sichere Programmierfähigkeiten aufzubauen. Sichere Entwickler der nächsten Stufe haben jedoch die Möglichkeit, die Modellierung von Bedrohungen als Teil ihres Softwareentwicklungsprozesses zu erlernen und zu üben.

Es sollte nicht überraschen, dass die Leute, die ihre Software am besten kennen, die Entwickler sind, die sie selbst entwickelt haben. Sie verfügen über ein umfassendes Wissen darüber, wie die Benutzer mit der Software interagieren, wo die Funktionen verwendet werden und - bei ausreichendem Sicherheitsbewusstsein - über mögliche Szenarien, in denen die Software versagen oder ausgenutzt werden könnte.

Wenn wir dies auf den Log4Shell-Exploit zurückführen, sehen wir leider ein Szenario, in dem eine katastrophale Schwachstelle der Erkennung durch Experten und komplexe Tools entgangen ist, die jedoch möglicherweise gar nicht aufgetreten wäre, wenn die Bibliothek so konfiguriert gewesen wäre, dass Benutzereingaben sanitized wurden. Die Entscheidung, dies nicht zu tun, scheint eine obskure Funktion gewesen zu sein, die der Bequemlichkeit diente, es aber schmerzhaft einfach machte, die Schwachstelle auszunutzen (man denke an SQL-Injection-Level, sicherlich keine geniale Sache). Wenn die Bedrohungsmodellierung von einer Gruppe scharfsinniger, sicherheitsbewusster Entwickler durchgeführt worden wäre, hätte man dieses Szenario höchstwahrscheinlich durchdacht und berücksichtigt.

Ein großartiges Sicherheitsprogramm hat eine emotionale Komponente, wobei menschliches Eingreifen und Nuancen im Mittelpunkt der Lösung von Problemen stehen, die von Menschen geschaffen wurden. Die Modellierung von Bedrohungen erfordert Einfühlungsvermögen und Erfahrung, um effektiv zu sein, ebenso wie die sichere Kodierung und Konfiguration auf der Architekturebene von Software und Anwendungen. Entwickler sollten nicht von heute auf morgen in diese Aufgabe hineingeworfen werden, aber ein klarer Weg, sie auf ein Niveau zu bringen, auf dem sie das Sicherheitsteam bei dieser wichtigen Aufgabe entlasten können, ist ideal (und es ist eine großartige Möglichkeit, eine Beziehung zwischen beiden Teams aufzubauen). 

Null-Tage führen zu n-Tagen

Der nächste Teil des Umgangs mit einem Zero-Day besteht darin, Patches so schnell wie möglich zu veröffentlichen und zu hoffen, dass jeder Benutzer der verwundbaren Software sie so schnell wie möglich anwendet, und zwar bevor ein Angreifer sie als erster findet. Log4Shell könnte Heartbleed in puncto Ausdauer und Wirksamkeit in den Schatten stellen, da es in Millionen von Geräten eingebettet ist und komplexe Abhängigkeiten innerhalb eines Software-Builds schafft.

Realistisch betrachtet gibt es keine Möglichkeit, diese Art von heimtückischen Angriffen vollständig zu verhindern. Wenn wir uns jedoch dazu verpflichten, alle Möglichkeiten zu nutzen, um qualitativ hochwertige und sichere Software zu entwickeln, und die Entwicklung mit der gleichen Einstellung angehen wie kritische Infrastrukturen, können wir alle eine Chance haben.