Zero-Day-Angriffe nehmen zu. Es ist an der Zeit, eine Verteidigungsstrategie zu entwickeln.

Eine Version dieses Artikels erschien im SC Magazine. Er wurde hierfür angepasst und syndiziert.


Wer schon einmal Opfer eines Einbruchs war, kennt dieses beklemmende Gefühl, dass etwas nicht stimmt, gefolgt von der Erkenntnis, dass man tatsächlich bestohlen und in seiner Privatsphäre verletzt wurde. Meist bleibt ein dauerhaftes Unbehagen zurück, ganz zu schweigen von der Umstellung auf Sicherheitsmaßnahmen, die es mit Fort Knox aufnehmen könnten.

Stellen Sie sich nun vor, in Ihr Haus wird eingebrochen, weil die Diebe sich einen Schlüssel angefertigt haben. Sie schleichen herum, kommen und gehen, wie es ihnen gefällt, achten aber darauf, unentdeckt zu bleiben. Eines Tages bemerken Sie viel zu spät, dass der Schmuck aus dem Gefrierfach verschwunden ist, der Safe geleert wurde und Ihre persönlichen Gegenstände durchwühlt sind. Genau das ist die Realität für ein Unternehmen, das Opfer eines Zero-Day-Cyberangriffs wird. Eine Studie des Ponemon Institute aus dem Jahr 2020 ergab, dass 80 % der erfolgreichen Datendiebstähle das Ergebnis von Zero-Day-Exploits waren – und leider sind die meisten Unternehmen nach wie vor schlecht gerüstet, um diese Statistik signifikant zu verbessern.

Zero-Day-Angriffe lassen Entwicklern per Definition keine Zeit, bestehende Schwachstellen zu finden und zu schließen, bevor sie ausgenutzt werden, da die Angreifer schneller sind. Der Schaden ist bereits entstanden, und es folgt ein hektischer Wettlauf, um sowohl die Software als auch den Ruf des Unternehmens zu retten. Angreifer haben immer einen Vorsprung, und es ist entscheidend, diesen so weit wie möglich zu verringern.

Das Weihnachtsgeschenk, das niemand wollte – Log4Shell – erschüttert derzeit das Internet; über eine Milliarde Geräte sollen von dieser katastrophalen Java-Schwachstelle betroffen sein. Es entwickelt sich zum schlimmsten Zero-Day-Angriff aller Zeiten, und wir stehen erst am Anfang. Obwohl einige Berichte darauf hindeuten, dass die Exploits bereits einige Tage vor der öffentlichen Bekanntgabe begannen, legt eine Präsentation auf der Black Hat Conference 2016 nahe, dass dieses Problem schon länger bekannt war. Autsch. Erschwerend kommt hinzu, dass die Schwachstelle erschreckend einfach auszunutzen ist und sich jeder Script-Kiddie und Cyberkriminelle auf der Welt damit bereichern will.

Was ist also der beste Weg, um sich gegen eine so schwer fassbare, heimtückische Bedrohung zu verteidigen – ganz zu schweigen von Schwachstellen, die im Softwareentwicklungsprozess ü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 erzielen oft stolze Preise. Ein Beispiel in diesem Artikel wurde zum Zeitpunkt der Veröffentlichung für 2,5 Millionen Dollar gelistet. Da es sich angeblich um einen Exploit für Apple iOS handelt, überrascht der hohe Preis des Sicherheitsforschers nicht; schließlich könnte dies das Einfallstor sein, um Millionen von Geräten zu kompromittieren, Milliarden von sensiblen Datensätzen zu ernten und dies so lange wie möglich zu tun, bevor die Lücke entdeckt und geschlossen wird.

Aber wer hat überhaupt so viel Geld? In der Regel bringen organisierte Cyberkriminalitäts-Syndikate das nötige Kapital auf, wenn es sich lohnt, insbesondere für die allseits beliebten Ransomware-Angriffe. Aber auch Regierungen und Verteidigungsministerien weltweit gehören zu den Kunden für Exploits, die sie für ihre Bedrohungsanalysen nutzen können. In positiveren Szenarien kaufen Unternehmen ihre eigenen potenziellen Zero-Day-Exploits sogar selbst auf, um Katastrophen abzuwenden.

2021 wurden Rekorde bei der Entdeckung aktiver Zero-Day-Exploits gebrochen. Besonders große Unternehmen, Regierungsbehörden und Infrastruktureinrichtungen sind gefährdet, auf Schwachstellen hin untersucht zu werden. Es gibt keinen hundertprozentigen Schutz vor Zero-Day-Angriffen, aber man kann das „Spiel“ mitspielen, indem man ein großzügiges und gut strukturiertes Bug-Bounty-Programm anbietet. Anstatt darauf zu warten, dass jemand die Schlüssel zu Ihrer Software-Festung auf einem Dark-Web-Marktplatz anbietet, sollten Sie sich Sicherheitsexperten ins Boot holen und ihnen faire Belohnungen für die ethische Offenlegung und mögliche Lösungen bieten.

Und falls es sich tatsächlich um eine haarsträubende Zero-Day-Bedrohung handelt, können Sie davon ausgehen, dass Sie mehr als nur einen Amazon-Gutschein springen lassen müssen (und es wird sich für Sie lohnen).

Ihre Tools könnten für Ihr Sicherheitspersonal zur Belastung werden

Umständliche Sicherheitstools sind schon lange ein Problem. Ein durchschnittlicher CISO verwaltet zwischen 55 und 75 Tools in seinem Sicherheitsarsenal. Abgesehen davon, dass es sich um das wohl verwirrendste (metaphorische) Schweizer Taschenmesser der Welt handelt, sind laut einer Studie des Ponemon Institute 53 % der Unternehmen nicht einmal davon überzeugt, dass sie effektiv arbeiten. Eine weitere Studie ergab, dass nur 17 % der CISOs ihren Sicherheits-Stack für „vollständig effektiv“ hielten.

In einem Bereich, der für Burnout, Fachkräftemangel und den Bedarf an Agilität bekannt ist, ist es eine enorme Belastung, Sicherheitsexperten mit einer Informationsflut aus Daten, Berichten und der Überwachung riesiger Tool-Landschaften zu konfrontieren. Genau das ist das Szenario, in dem kritische Warnmeldungen übersehen werden können – was möglicherweise auch bei der korrekten Bewertung der Schwachstellen von Log4j der Fall war.

Präventive Sicherheit sollte entwicklergesteuerte Bedrohungsmodellierung beinhalten

Schwachstellen auf Code-Ebene werden oft von Entwicklern eingeführt; sie benötigen präzise Anleitungen und regelmäßige Lernpfade, um Fähigkeiten für sicheres Programmieren aufzubauen. Fortgeschrittene Entwickler sollten jedoch die Möglichkeit erhalten, Bedrohungsmodellierung als Teil ihres Softwareentwicklungsprozesses zu erlernen und anzuwenden.
‍
Es sollte niemanden überraschen, dass diejenigen, die ihre Software am besten kennen, die Entwickler sind, die sie selbst erstellt haben. Sie verfügen über wertvolles Wissen darüber, wie Benutzer mit der Software interagieren, wo Funktionen eingesetzt werden und – bei entsprechendem Sicherheitsbewusstsein – in welchen Szenarien sie versagen oder ausgenutzt werden könnte.

Wenn wir auf den Log4Shell-Exploit zurückkommen, sehen wir leider ein Szenario, in dem eine katastrophale Schwachstelle von Experten und komplexen Tools unentdeckt blieb. Hätte man die Bibliothek so konfiguriert, dass Benutzereingaben bereinigt werden, wäre es vielleicht gar nicht erst dazu gekommen. Die Entscheidung dagegen schien ein obskures Feature für mehr Komfort zu sein, machte die Software aber erschreckend leicht angreifbar (denken Sie an SQL-Injection-Niveau, sicher keine Glanzleistung). Wäre eine Bedrohungsmodellierung durch ein engagiertes, sicherheitsbewusstes Entwicklerteam erfolgt, ist es sehr wahrscheinlich, dass dieses Szenario theoretisch durchgespielt und berücksichtigt worden wäre.

Ein großartiges Sicherheitsprogramm hat eine emotionale Komponente; menschliches Eingreifen und Fingerspitzengefühl stehen im Mittelpunkt bei der Lösung von Problemen, die von Menschen geschaffen wurden. Bedrohungsmodellierung erfordert Empathie und Erfahrung, ebenso wie sicheres Programmieren und Konfigurieren auf der architektonischen Ebene von Software und Anwendungen. Entwickler sollten nicht über Nacht damit allein gelassen werden, aber ein klarer Pfad zur Weiterbildung, damit sie das Sicherheitsteam bei dieser wichtigen Aufgabe entlasten können, ist ideal (und eine großartige Möglichkeit, das Verhältnis zwischen beiden Teams zu verbessern).

Aus Zero-Days werden N-Days

Der nächste Schritt bei der Bewältigung einer Zero-Day-Lücke besteht darin, Patches so schnell wie möglich bereitzustellen – in der Hoffnung, dass jeder Nutzer der betroffenen Software diese umgehend installiert, bevor Angreifer zuschlagen. Im Fall von Log4Shell könnte das Ausmaß Heartbleed sogar noch übertreffen, da die Schwachstelle in Millionen von Geräten eingebettet ist und komplexe Abhängigkeiten innerhalb der Softwarearchitektur 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 für die Entwicklung hochwertiger, sicherer Software zu nutzen und die Entwicklung mit derselben Sorgfalt wie bei kritischer Infrastruktur anzugehen, haben wir alle eine echte Chance.