Die Cybersicherheitsprobleme, die wir 2022 nicht ignorieren können

Eine Version dieses Artikels wurde veröffentlicht in Infosecurity Magazin. Es wurde hier aktualisiert und syndiziert.

‍

Die letzten zwei Jahre waren für, nun ja, alle eine Feuertaufe, aber der Cybersicherheits-Blueprint für die meisten Unternehmen wurde auf die Probe gestellt, da viele von uns praktisch über Nacht in ein Modell der Telearbeit versetzt wurden. Wir mussten wirklich noch einen drauf legen und uns als Branche anpassen, vor allem angesichts der verzweifelten Bedrohungsakteure was zu einem Anstieg der gemeldeten Cyberkriminalität um 300% führte seit Beginn der Pandemie.

Wir haben alle einige Lektionen gelernt, und es tröstet mich, dass nicht nur die allgemeine Cybersicherheit ernster genommen wird, sondern auch die Sicherheit und Qualität von Software auf Codeebene. Bidens Exekutivverordnung Bei der Sicherung der Softwarelieferkette kamen kritische Probleme ans Licht, insbesondere im Zuge der Massenverletzung von SolarWinds. Die Idee, dass wir uns alle mehr um Sicherheit kümmern müssen, und Die Arbeit an der Reduzierung von Sicherheitslücken mit messbarem Sicherheitsbewusstsein ist definitiv ein größerer Teil der Diskussion.

Allerdings müssen wir im Kampf gegen Cyberkriminelle so nah wie möglich mit ihnen Schritt halten und ihnen mit einer präventiven Denkweise zuvorkommen.

Ich denke, hier könnten sie im kommenden Jahr Wellen schlagen:

Das Metaversum ist eine neue Angriffsfläche

Das Metaversum mag die nächste Entwicklung des Internets sein, aber eine ähnliche Transformation steht noch aus, was die Art und Weise angeht, wie die meisten Branchen an die Sicherung von Software und digitalen Umgebungen herangehen.

Allgemeine Fallstricke im Bereich Cybersicherheit wie Phishing-Betrug werden zwar unvermeidlich sein (und wahrscheinlich zahlreich, während sich alle mit dem Metaversum zurechtfinden), aber die eigentliche Infrastruktur und die Geräte, die diese immersive virtuelle Welt ermöglichen, müssen sicher sein. Ähnlich wie Smartphones uns geholfen haben, online zu leben, sind Peripheriegeräte wie VR-Headsets das neue Tor zu Bergen von Benutzerdaten. Die Sicherheit eingebetteter Systeme wird immer komplexer, um IoT-Geräte sicher zu machen, und die schöne neue Welt der Mainstream-VR/AR ist da keine Ausnahme. Wie wir beim Log4Shell-Exploit gesehen haben, können einfache Fehler auf Codeebene zu einem Backstage-Pass für Bedrohungsakteure werden, und in einer simulierten Realität erzeugt jede Bewegung Daten, die gestohlen werden können.

Obwohl ein erfolgreiches Metaversum noch in den Kinderschuhen steckt, erfordert es die praktische Einführung von Kryptowährungen (nicht nur das zufällige Horten der neuesten Meme-Coins) und Wertgegenstände wie NFTs, was bedeutet, dass unser reales Vermögen, unsere Identität, unsere Daten und unser Lebensunterhalt potenziell für einen neuen „Wilden Westen“ geöffnet werden, der Menschen gefährden kann. Bevor wir Entwickler anfangen, mit epischen Funktionen und Verbesserungen verrückt zu werden, sollte die Minimierung dieser neuen, riesigen Angriffsfläche von Grund auf eine Priorität sein.

Gesetzgebung im Zuge von Log4Shell

Für die zahlreichen Entwickler, die ins Chaos gestürzt wurden und sich bemühten, herauszufinden, ob es irgendwelche Instanzen oder Abhängigkeiten gibt, die mit einer ausnutzbaren Version des weit verbreiteten Log4j-Logging-Tools verbunden sind, glaube ich nicht, dass die Weihnachtszeit eine schöne Zeit gewesen wäre.

Dieser Zero-Day-Angriff ist gehört zu den schlechtesten aller Zeiten, mit Vergleichen zwischen Log4Shell und der verheerenden Heartbleed OpenSSL-Sicherheitslücke, die wird über sechs Jahre später immer noch ausgebeutet. Wenn man sich an diesen Zeitplan halten kann, werden wir es noch lange mit einem Log4Shell-Kater zu tun haben. Es ist klar, dass viele Unternehmen trotz der Lehren aus Heartbleed — zumindest in Bezug auf die Notwendigkeit, Patches so schnell wie möglich einzuführen und zu implementieren — einfach nicht schnell genug handeln, um sich selbst zu schützen. Je nach Größe des Unternehmens kann das Patchen unglaublich schwierig und bürokratisch sein und erfordert eine abteilungsübergreifende Dokumentation und Implementierung. Sehr oft verfügen IT-Abteilungen und Entwickler nicht über ein enzyklopädisches Wissen über alle verwendeten Bibliotheken, Komponenten und Tools und werden durch strenge Bereitstellungspläne behindert, um Unterbrechungen und Anwendungsausfälle zu minimieren. Es gibt triftige Gründe für diese Arbeitsweise (sprich: niemand will einen Strich durch die Rechnung machen und etwas kaputt machen), aber zu langsam zu patchen, ist eine leichte Beute.

So wie der SolarWinds-Angriff hat das Spiel für die Software-Lieferkette verändert. Ich gehe davon aus, dass im Zuge von Log4Shell Ähnliches passieren wird. Zwar gibt es bereits Mandate und Empfehlungen zum Patch-Management in einige kritische Branchen, eine weit verbreitete Gesetzgebung ist eine andere Geschichte. Präventive Softwaresicherheit wird immer die beste Chance sein, dringende Sicherheits-Patches gänzlich zu vermeiden. Bewährte Sicherheitsverfahren schreiben jedoch vor, dass das Patchen eine nicht verhandelbare vorrangige Maßnahme ist. Ich denke, dies wird ein aktuelles Thema sein und zu weniger subtilen Empfehlungen führen, schnell und häufig zu patchen.

Mehr Wert auf architektonische Sicherheit (und Entwickler sind noch nicht bereit)

Das neue OWASP Top 10 2021 hatte einige bedeutende Neuzugänge sowie eine Überraschung, als Injection-Schwachstellen vom Spitzenplatz auf einen niedrigen dritten Platz fielen. Diese Neuzugänge sprechen quasi für eine „zweite Phase“ auf dem Weg eines Entwicklers in Sachen sichere Codierung und bewährte Sicherheitsmethoden, und leider sind die meisten schlecht gerüstet, um hier einen positiven Beitrag zur Risikominderung zu leisten, sofern sie nicht entsprechend geschult sind.

Wir wissen seit einiger Zeit, dass Entwickler über Sicherheitskenntnisse verfügen müssen, wenn wir häufig auftretende Sicherheitslücken im Code bekämpfen wollen, und Unternehmen reagieren besser auf die Prämisse der entwicklerorientierten Prävention. Allerdings mit Unsicheres Design Da es sich um einen Platz in den OWASP Top 10 handelt und da es sich um eine Kategorie architektonischer Sicherheitsprobleme und nicht um eine einzelne Art von Sicherheitslücken handelt, müssen Entwickler über die Grundlagen hinaus gedrängt werden, wenn sie sie erst einmal gemeistert haben. Lernumgebungen, die sich mit Bedrohungsmodellierung befassen — idealerweise mit Unterstützung des Sicherheitsteams — nehmen den Druck ab, sobald die Entwickler erfolgreich weitergebildet sind. Aber so wie es aussieht, ist das für die meisten Softwareingenieure eine erhebliche Wissenslücke.

Um dem entgegenzuwirken, „braucht es ein ganzes Dorf“, und das Unternehmen kann dazu beitragen, eine positive Sicherheitskultur für Entwickler zu schaffen, die ihre Neugier weckt, ohne ihren Arbeitsablauf wesentlich zu stören.