この記事のバージョンが掲載されました SC Magazine。ここで修正およびシンジケートされています。
泥棒に家に侵入されたことがあれば、最初は何かがおかしいという気持ちが沈み、その後、自分が実際に盗まれて侵害されたことに気づくのがわかるでしょう。フォートノックスに匹敵するセキュリティ対策への転換は言うまでもなく、通常は不快感が長続きします。
Stellen Sie sich vor, Ihr Haus wurde zerstört, weil Diebe selbst Schlüssel angefertigt haben. Sie schleichen sich heran und kommen und gehen, wie es ihnen gefällt, wobei sie darauf achten, nicht bemerkt zu werden. Und eines Tages bemerken Sie zu spät, dass der im Gefrierschrank versteckte Schmuck verschwunden ist, der Safe leergeräumt wurde und Ihre persönlichen Gegenstände geplündert wurden.Dies entspricht genau der Realität, mit der Unternehmen konfrontiert sind, wenn sie Opfer eines Zero-Day-Cyberangriffs werden. Eine Studie des Ponemon Institute aus dem Jahr 2020 ergab Folgendes: 80 % der erfolgreichen Datenlecks sind das Ergebnis von Zero-Day-Exploits, und leider sind die meisten Unternehmen nicht darauf vorbereitet, diese Statistik deutlich zu verbessern.
Bei Zero-Day-Angriffen hat der Angreifer natürlich als Erster Zugriff, sodass Entwickler keine Zeit haben, potenzielle Schwachstellen zu entdecken und zu beheben. Wenn Schäden auftreten, kommt es zu einem hektischen Wettlauf, um sowohl die Software als auch den Ruf des Unternehmens wiederherzustellen. Angreifer sind immer im Vorteil, daher ist es wichtig, diesen Vorsprung so weit wie möglich zu verringern.
Log4Shell, ein unerwünschtes Weihnachtsgeschenk, erobert derzeit das Internet und soll mehr als eine Milliarde Geräte betreffen, die von dieser verheerenden Java-Sicherheitslücke betroffen sind. Dies könnte der schlimmste Zero-Day-Angriff aller Zeiten werden, und er hat gerade erst begonnen. Dennoch berichten einige Berichte, dass der Exploit bereits einige Tage vor seiner Veröffentlichung gestartet wurde. Präsentation auf der Black Hat-Konferenz 2016 lässt vermuten, dass das Problem schon seit einiger Zeit bekannt war. Das tut weh. Erschwerend kommt hinzu, dass diese Schwachstelle sehr leicht auszunutzen ist und alle Skriptkrampf-Hacker und Bedrohungsakteure weltweit darauf abzielen.
Was ist nun der beste Weg, um sich vor bösartigen Bedrohungen zu schützen, ganz zu schweigen von den Schwachstellen, die im Softwareentwicklungsprozess übersehen wurden? Schauen wir uns das einmal an.
Zero-Day-Angriffe auf große Ziele sind selten (und teuer).
Im Dark Web gibt es einen riesigen Markt für Exploits, und Zero-Day-Exploits erzielen beispielsweise tendenziell beträchtliche Summen. Zum Zeitpunkt der Erstellung dieses Artikels sind sie mit 2,5 Millionen Dollar gelistet.Es handelt sich zwar um einen gemeldeten Missbrauch von Apple iOS, aber es ist nicht verwunderlich, dass die von Sicherheitsforschern angebotenen Preise in die Höhe schnellen. Schließlich könnte dies tatsächlich ein Tor sein, um Millionen von Geräten zu kompromittieren, Milliarden vertraulicher Datensätze zu sammeln und dies so lange wie möglich zu tun, bevor es entdeckt und gepatcht wird.
Aber wer verfügt überhaupt über solche Geldmittel? In der Regel beschaffen sich organisierte Cyberkriminelle Geldmittel für besonders beliebte Ransomware-Angriffe, wenn sie diese für lohnenswert halten. Allerdings sind Regierungen und Verteidigungsbehörden weltweit Kunden für Exploits, die für Bedrohungsinformationen genutzt werden können. In einem positiveren Szenario könnten Unternehmen selbst zu Käufern potenzieller Zero-Day-Exploits werden, um Katastrophen abzuwenden.
2021 wurde der Rekord gebrochen. Am stärksten von Zero-Day-Exploits betroffen und dem Risiko einer Untersuchung ihrer Schwachstellen ausgesetzt sind große Organisationen, Regierungsbehörden und Infrastrukturen. Es gibt keine Möglichkeit, sich vollständig vor Zero-Day-Angriffen zu schützen, aberaber mit einem großzügigen und gut strukturierten Bug-Bounty-Programm kann man das Risiko ein wenig „mildern“. Anstatt darauf zu warten, dass jemand auf dem Dark-Web-Marktplatz den Schlüssel zum Software-Schloss anbietet, sollten Sie sich legitime Sicherheitsfanatiker zu Verbündeten machen und angemessene Belohnungen für ethische Offenlegungen und potenzielle Korrekturen anbieten.
そして、それがたまたま身の毛もよだつようなゼロデイ脅威である場合は、Amazonギフトカード以上のものを支払う必要があると考えて間違いありません（そうする価値はあります）。
Die Verwendung von Tools kann eine Belastung für Sicherheitsbeauftragte darstellen.
Komplexe Sicherheitstools sind seit langem ein Problem, und der durchschnittliche CISO verwaltet zwischen 55 und 75 Tools in seinem Sicherheitsarsenal. Abgesehen davon, dass sie die unübersichtlichsten (im übertragenen Sinne) Schweizer Taschenmesser der Welt sind, geben 53 % der Unternehmen an, dass sie nicht einmal sicher sind, ob sie effektiv arbeiten. Eine Studie des Ponemon Institute ergab, dass nur 17 % der CISOs ihre Sicherheitsmaßnahmen als „vollständig effektiv” betrachten.
Burnout-Syndrom, Mangel an Fachkräften mit den erforderlichen Sicherheitskenntnissen, Notwendigkeit von Agilität – in diesem Bereich, der für diese Probleme bekannt ist, stellt die Verarbeitung einer enormen Datenmenge in Form von Toolsets, Berichten und Überwachungsdaten eine große Belastung für Sicherheitsexperten dar. Dies ist genau das Szenario, das dazu führen kann, dass kritische Warnmeldungen übersehen werden, was auch bei der angemessenen Bewertung der Log4j-Schwachstelle der Fall sein könnte.
Präventive Sicherheit muss eine entwicklergesteuerte Bedrohungsmodellierung umfassen.
Code-Level-Schwachstellen werden häufig von Entwicklern eingeführt. Um sichere Codierungsfähigkeiten zu erwerben, sind genaue Anleitungen und regelmäßige Lernpfade erforderlich. Entwicklern der nächsten Stufe wird jedoch die Möglichkeit geboten, im Rahmen des Softwareentwicklungsprozesses Threat Modeling zu erlernen und anzuwenden.
Es ist nicht überraschend, dass diejenigen, die die Software eines Unternehmens am besten kennen, die Entwickler sind, die sie erstellt haben. Wenn sie sich bewusst sind, wie Benutzer die Software bedienen, wo sie Funktionen nutzen und wie die Sicherheit funktioniert, verfügen sie über fundierte Kenntnisse über Szenarien, in denen die Software beschädigt oder missbraucht werden könnte.
Wenn wir uns wieder dem Log4Shell-Exploit zuwenden, sehen wir leider ein Szenario, in dem selbst Experten und komplexe Toolsets diese kritische Schwachstelle nicht erkennen können. Allerdingswäre dies möglicherweise gar nicht aufgetreten, wenn die Bibliothek so konfiguriert gewesen wäre, dass sie Benutzereingaben saniert. Die Entscheidung, dies nicht zu tun, war offenbar eine vage Funktion, um die Benutzerfreundlichkeit zu erhöhen, machte es jedochsehr einfach, sie zu missbrauchen (denken Sie an das Niveau einer SQL-Injection. Das ist sicherlich kein Geniestreich). Hätte eine Gruppe von sicherheitsbewussten, engagierten Entwicklern eine Bedrohungsmodellierung durchgeführt, wäre dieses Szenario wahrscheinlich theoretisiert und untersucht worden.
Ein hervorragendes Sicherheitsprogramm beinhaltet emotionale Elemente, und im Mittelpunkt der Lösung von Problemen, die von Menschen verursacht wurden, stehen menschliches Eingreifen und feine Unterschiede. Um eine effektive Bedrohungsmodellierung durchzuführen, sind Empathie und Erfahrung erforderlich, ebenso wie sicheres Codieren und Konfigurieren auf der Ebene der Software- und Anwendungsarchitektur. Dies ist keine Aufgabe, die Entwickler über Nacht bewältigen können, aber es ist ideal, einen klaren Weg vorzugeben, um die Fähigkeiten der Entwickler so weit zu verbessern, dass der Druck auf das Sicherheitsteam in Bezug auf diese wichtige Aufgabe verringert wird. (Dies ist auch eine hervorragende Möglichkeit, um Vertrauen zwischen beiden Teams aufzubauen).
Zero Day führt zu n Tagen.
Die nächste Stufe der Zero-Day-Abwehr besteht darin, Patches so schnell wie möglich zu verteilen. Wir möchten, dass alle Nutzer der anfälligen Software die Patches so schnell und zuverlässig wie möglich installieren, noch bevor Angreifer sie zum ersten Mal ausnutzen können. Die Stärke von Log4Shell liegt in seiner Robustheit und Wirksamkeit, obwohl es in Millionen von Geräten eingebaut ist, die möglicherweise von Heartbleed betroffen sind, und komplexe Abhängigkeiten in der gesamten Software-Entwicklung verursacht.
Realistisch gesehen gibt es keine Möglichkeit, solche hinterhältigen Angriffe vollständig zu verhindern. Wenn wir jedoch alle Mittel einsetzen, um hochwertige und sichere Software zu entwickeln, und uns verpflichten, bei der Entwicklung denselben Ansatz wie bei kritischen Infrastrukturen zu verfolgen, haben wir alle eine Chance, uns zu wehren.
