Eine Version dieses Artikels wurde veröffentlicht in Revue SCveröffentlicht. Er wurde überarbeitet und hier veröffentlicht.
Wenn Sie schon einmal Opfer eines Einbruchs geworden sind, kennen Sie dieses Gefühl, dass etwas nicht stimmt, gefolgt von der Erkenntnis, dass Sie tatsächlich bestohlen und verletzt worden sind. Dies führt in der Regel zu einem anhaltenden Unbehagen, ganz zu schweigen von der Notwendigkeit, Sicherheitsmaßnahmen zu ergreifen, die denen von Fort Knox vergleichbar sind.
Stellen Sie sich nun vor, dass in Ihr Haus eingebrochen wird, weil sich die Diebe einen Schlüssel angefertigt haben. Sie schleichen sich herein, kommen und gehen, wie es ihnen gefällt, achten jedoch darauf, nicht entdeckt zu werden. Eines Tages stellen Sie dann zu spät fest, dass der Schmuck, den Sie im Gefrierschrank versteckt hatten, verschwunden ist, Ihr Safe ausgeräumt und Ihre persönlichen Gegenstände durchwühlt wurden. Genau damit sieht sich eine Organisation konfrontiert, wenn sie Opfer eines Cyberangriffs vom Typ „Zero Day“ wird. Im Jahr 2020 ergab eine Studie des Ponemon Institute, dass 80 % der erfolgreichen Datenverletzungen das Ergebnis von Zero-Day-Exploits waren, und leider sind die meisten Unternehmen immer noch nicht in der Lage, diese Statistik wesentlich zu verbessern.
Zero-Day-Angriffe lassen den Entwicklern per Definition keine Zeit, bestehende Schwachstellen, die ausgenutzt werden könnten, zu erkennen und zu beheben, da der Urheber der Bedrohung zuerst zugeschlagen hat. Der Schaden ist bereits angerichtet, und es beginnt ein Wettlauf gegen die Zeit, um sowohl die Software als auch den Ruf des Unternehmens wiederherzustellen. Die Angreifer sind immer im Vorteil, und es ist entscheidend, diesen Vorteil so weit wie möglich zu verringern.
Das Weihnachtsgeschenk, das niemand wollte, Log4Shell, lässt derzeit das Internet explodieren, da mehr als eine Milliarde Geräte von dieser katastrophalen Java-Sicherheitslücke betroffen sein sollen. Es kündigt sich als der schlimmste Zero-Day-Angriff aller Zeiten an, und wir stehen erst am Anfang. Obwohl einige Berichte darauf hindeuten, dass die Exploits bereits einige Tage vor ihrer öffentlichen Bekanntgabe begonnen hatten, deut et eine Präsentation auf der Black Hat Conference 2016 darauf hin, dass dieses Problem schon seit einiger Zeit bekannt ist. Autsch. Schlimmer noch, es ist extrem einfach auszunutzen, und alle Skriptersteller und Akteure von Bedrohungen auf der ganzen Welt sind auf der Suche nach einem lukrativen Geschäft dank dieser Sicherheitslücke.
Was ist also der beste Weg, um sich gegen eine finstere und schwer fassbare Bedrohung zu verteidigen, ganz zu schweigen von den Schwachstellen, die während des Softwareentwicklungsprozesses nicht entdeckt wurden? Schauen wir uns das einmal an.
Angriffe vom Typ „Zero Day“ auf große Ziele sind selten (und kostspielig).
Es gibt einen riesigen Markt für Exploits im Dark Web, und Zero-Day-Exploits sind in der Regel sehr teuer, um nur ein Beispiel aus diesem Artikel zu nennen, das zum Zeitpunkt der Erstellung mit 2,5 Millionen Dollar bewertet wurde. Da es sich um einen Exploit für Apple iOS handelt, ist es nicht verwunderlich, dass der vom Sicherheitsforscher geforderte Preis exorbitant hoch ist. Schließlich könnte es sich um eine Schnittstelle handeln, über die Millionen von Geräten kompromittiert und Milliarden von sensiblen Daten gesammelt werden können, und zwar so lange wie möglich, bevor sie entdeckt und behoben werden.
Aber wer hat überhaupt so viel Geld? Im Allgemeinen finden organisierte Cyberkriminelle Geld, wenn sie es für sinnvoll halten, insbesondere für die immer beliebter werdenden Ransomware-Angriffe. Allerdings gehören auch Regierungen und Verteidigungsministerien weltweit zu den Kunden für Exploits, die sie für die Bedrohungsaufklärung nutzen können, und in positiveren Szenarien können Unternehmen selbst potenzielle Zero-Day-Exploits kaufen, um Katastrophen abzuwenden.
2021 wurden Rekorde bei der Entdeckung von Zero-Day-Exploits in Echtzeit gebrochen, und es sind große Organisationen, Regierungsbehörden und Infrastrukturen, die am ehesten Gefahr laufen, auf mögliche Schwachstellen untersucht zu werden. Es gibt keine Möglichkeit, sich vollständig vor einem Zero-Day-Angriff zu schützen, aber Sie können ein wenig „mitspielen“, indem Sie ein großzügiges und gut strukturiertes Bug-Bounty-Programm anbieten. Anstatt darauf zu warten, dass Ihnen jemand auf einem Dark-Web-Marktplatz die Schlüssel zu Ihrem Software-Schloss anbietet, sollten Sie sich an seriöse Sicherheitsexperten wenden und ihnen angemessene Belohnungen für ethische Offenlegungen und potenzielle Korrekturen anbieten.
Und wenn sich herausstellt, dass es sich um eine atemberaubende Zero-Day-Bedrohung handelt, können Sie davon ausgehen, dass Sie mehr als eine Amazon-Geschenkkarte benötigen (und das wird sich lohnen).
Ihre Ausrüstung könnte für Ihr Sicherheitspersonal ein Hindernis darstellen.
Die Schwerfälligkeit von Sicherheits-Tools ist seit langem ein Problem, da der durchschnittliche CISO zwischen 55 und 75 Tools in seinem Sicherheitsarsenal verwaltet. Abgesehen davon, dass es sich um das verwirrendste (metaphorische) Schweizer Taschenmesser der Welt handelt, sind laut einer Studie des Ponemon Institute 53 % der Unternehmen nicht einmal davon überzeugt, dass sie effizient arbeiten. Eine andere Studie ergab, dass nur 17 % der RSSI der Meinung waren, dass ihre Sicherheitslösung „vollständig effektiv” sei.
In einem Bereich, der für seine Überlastung, seinen Mangel an qualifiziertem Sicherheitspersonal zur Deckung des Bedarfs und seinen Bedarf an Flexibilität bekannt ist, erweist es sich als mühsam, Sicherheitsfachleute zu verpflichten, mit einer Überflutung an Informationen in Form von Daten, Berichten und der Überwachung riesiger Tool-Sets zu arbeiten. Genau diese Art von Szenario kann dazu führen, dass sie eine kritische Warnung übersehen, was möglicherweise der Fall war, als es darum ging, die Schwachstellen von Log4j richtig einzuschätzen.
Präventive Sicherheit muss eine von Entwicklern gesteuerte Bedrohungsmodellierung umfassen.
Les vulnérabilités au niveau du code sont souvent introduites par les développeurs, qui ont besoin de conseils précis et de parcours d'apprentissage réguliers pour développer des compétences de codage sécurisés. Cependant, les développeurs sécurisés de niveau supérieur ont eu l'opportunité d'apprendre et de pratiquer la modélisation des menaces dans le cadre de leur processus de création de logiciels.
Es überrascht nicht, dass diejenigen, die ihre Software am besten kennen, die Entwickler sind, die sie erstellt haben. Sie verfügen über fundierte Kenntnisse darüber, wie Benutzer mit ihr interagieren, wo Funktionen verwendet werden und, wenn sie sich der Sicherheit ausreichend bewusst sind, über mögliche Szenarien, in denen sie geknackt oder ausgenutzt werden könnte.
Wenn wir dies auf die Log4Shell-Sicherheitslücke zurückführen, sehen wir leider ein Szenario, in dem eine katastrophale Schwachstelle von Experten und komplexen Tool-Sets übersehen wurde, die jedoch möglicherweise gar nicht aufgetreten wäre, wenn die Bibliothek so konfiguriert worden wäre, dass sie Benutzereingaben bereinigt. Die Entscheidung, dies nicht zu tun, scheint eine obskure Funktion gewesen zu sein, die der Bequemlichkeit diente, aber die Ausnutzung extrem einfach machte (denken Sie an das Niveau der SQL-Injektion, das sicherlich nicht toll ist). Wäre die Bedrohungsmodellierung von einer Gruppe begeisterter und sicherheitsbewusster Entwickler durchgeführt worden, wäre dieses Szenario höchstwahrscheinlich theoretisiert und in Betracht gezogen worden.
Ein gutes Sicherheitsprogramm beinhaltet eine emotionale Komponente, da menschliches Eingreifen und Nuancen im Mittelpunkt der Lösung von durch Menschen verursachten Problemen stehen. Die Modellierung von Bedrohungen erfordert Empathie und Erfahrung, um effektiv zu sein, ebenso wie die sichere Codierung und Konfiguration auf der Ebene der Software- und Anwendungsarchitektur. Entwickler sollten nicht von heute auf morgen mit dieser Aufgabe konfrontiert werden, aber idealerweise sollte ein klarer Weg gefunden werden, um sie so weit zu verbessern, dass sie das Sicherheitsteam bei dieser wichtigen Aufgabe entlasten können (und dies ist eine hervorragende Möglichkeit, Beziehungen zwischen den beiden Teams aufzubauen).
Ein Tag Null führt zu n Tagen
Der nächste Schritt, um einem Zero-Day-Angriff zu begegnen, besteht darin, die Patches so schnell wie möglich zu veröffentlichen, in der Hoffnung, dass jeder Nutzer der anfälligen Software diese so schnell wie möglich installiert, und zwar auf jeden Fall bevor ein Angreifer zuerst zugreift. Mit Log4Shell könnte dies Heartbleed in seiner Ausdauer und Leistungsfähigkeit in den Schatten stellen, da es in Millionen von Geräten integriert ist und komplexe Abhängigkeiten innerhalb eines Software-Designs schafft.
In Wirklichkeit gibt es keine Möglichkeit, diese Art von heimtückischen Angriffen vollständig zu verhindern. Wenn wir uns jedoch dazu verpflichten, alle Mittel einzusetzen, um sichere und hochwertige Software zu entwickeln, und die Entwicklung mit derselben Einstellung anzugehen, als handele es sich um eine kritische Infrastruktur, haben wir alle eine Chance auf Erfolg.
