Diese Cybersicherheitsprobleme können wir 2022 nicht ignorieren

Eine Version dieses Artikels wurde im Infosecurity Magazine veröffentlicht. Er wurde hier aktualisiert und erneut publiziert.

‍

Die letzten zwei Jahre waren für so ziemlich jeden eine Art Feuertaufe. Die Cybersicherheitsstrategien der meisten Unternehmen wurden auf eine harte Probe gestellt, als viele von uns quasi über Nacht auf ein Modell für Remote-Arbeit umstellen mussten. Wir mussten als Branche wirklich nachlegen und uns anpassen, insbesondere angesichts skrupelloser Akteure, die einen Anstieg der gemeldeten Cyberkriminalität um 300 % seit Beginn der Pandemie verursacht haben.

Wir alle haben unsere Lektionen gelernt, und es beruhigt mich, dass nicht nur die allgemeine Cybersicherheit ernster genommen wird, sondern auch die Sicherheit und Qualität von Software auf Code-Ebene. Bidens Executive Order zur Sicherung der Software-Lieferkette hat kritische Probleme aufgezeigt, insbesondere nach dem massiven SolarWinds-Angriff. Die Erkenntnis, dass wir uns alle stärker um Sicherheit kümmern und daran arbeiten müssen, Schwachstellen durch messbares Sicherheitsbewusstsein zu reduzieren, ist definitiv ein zentraler Bestandteil der aktuellen Diskussion.

Um Cyberkriminellen wirksam entgegenzutreten, müssen wir ihnen immer einen Schritt voraus sein und ihre Spielwiesen mit einer präventiven Denkweise besetzen.

Hier sind die Bereiche, in denen sie meiner Einschätzung nach im kommenden Jahr für Unruhe sorgen könnten:

Das Metaverse als neue Angriffsfläche

Das Metaverse mag die nächste Evolutionsstufe des Internets sein, doch eine vergleichbare Transformation steht in der Art und Weise, wie die meisten Branchen die Sicherheit von Software und digitalen Umgebungen angehen, noch aus.

Während allgemeine Cybersicherheitsrisiken wie Phishing-Betrug unvermeidlich (und wahrscheinlich zahlreich sein werden, während sich alle im Metaverse zurechtfinden), müssen die tatsächliche Infrastruktur und die Geräte, die diese immersive virtuelle Welt ermöglichen, abgesichert werden. Ähnlich wie Smartphones uns geholfen haben, online zu leben, sind Peripheriegeräte wie VR-Headsets die neuen Tore zu riesigen Mengen an Nutzerdaten. Für die Sicherheit von IoT-Geräten sind zunehmend komplexe eingebettete Systeme erforderlich, und die schöne neue Welt des Mainstream-VR/AR bildet da keine Ausnahme. Wie wir beim Log4Shell-Exploit gesehen haben, können einfache Fehler auf Code-Ebene für Angreifer zum Generalschlüssel werden – und in einer simulierten Realität erzeugt jede Bewegung Daten, die gestohlen werden können.

Obwohl es noch in den Kinderschuhen steckt, wird ein erfolgreiches Metaverse die praktische Nutzung von Kryptowährungen (nicht nur das willkürliche Horten des neuesten Meme-Coins) sowie von wertvollen Objekten wie NFTs erfordern. Das bedeutet, dass unser reales Vermögen, unsere Identität, unsere Daten und unsere Lebensgrundlage potenziell einem neuen „Wilden Westen“ ausgesetzt sind, der Menschen gefährden kann. Bevor wir Ingenieure uns in epischen Funktionen und Erweiterungen verlieren, sollte die Minimierung dieser neuen, riesigen Angriffsfläche von Grund auf Priorität haben.

Gesetzgebung nach Log4Shell

Für die zahlreichen Entwickler, die ins Chaos gestürzt wurden und fieberhaft nach Instanzen oder Abhängigkeiten der ausnutzbaren Version des weit verbreiteten Log4j-Logging-Tools suchen mussten, war die Weihnachtszeit sicher keine besinnliche Zeit.

Dieser Zero-Day-Angriff gehört zu den schlimmsten, die je verzeichnet wurden, und wird mit der verheerenden Heartbleed-OpenSSL-Schwachstelle verglichen, die selbst nach über sechs Jahren noch ausgenutzt wird. Wenn dieser Zeitrahmen ein Indikator ist, werden wir noch lange mit den Nachwirkungen von Log4Shell zu kämpfen haben. Es ist offensichtlich, dass viele Unternehmen – selbst nach den Lektionen von Heartbleed, zumindest was die Notwendigkeit betrifft, Patches so schnell wie möglich bereitzustellen und zu implementieren – einfach nicht schnell genug handeln, um sich zu schützen. Je nach Unternehmensgröße kann das Patchen unglaublich schwierig und bürokratisch sein, da es abteilungsübergreifende Dokumentation und Implementierung erfordert. 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 ausgebremst, um Störungen und Ausfallzeiten der Anwendungen zu minimieren. Es gibt gute Gründe für diese Arbeitsweise (niemand möchte den Betrieb stören und etwas kaputt machen), aber zu langsam zu patchen bedeutet, ein leichtes Ziel zu sein.

So wie der SolarWinds-Angriff die Spielregeln für die Software-Lieferkette verändert hat, sage ich voraus, dass Ähnliches nach Log4Shell geschehen wird. Während es in einigen kritischen Branchen bereits Vorgaben und Empfehlungen für das Patch-Management gibt, ist eine flächendeckende Gesetzgebung eine andere Sache. Präventive Softwaresicherheit wird immer unsere beste Chance sein, dringende Sicherheits-Patches ganz zu vermeiden, aber bewährte Sicherheitspraktiken schreiben vor, dass das Patchen eine unverzichtbare Prioritätsmaßnahme ist. Ich denke, dies wird ein heißes Thema werden und zu deutlichen Empfehlungen führen, schnell und häufig zu patchen.

Mehr Fokus auf architektonische Sicherheit (und Entwickler sind nicht bereit)

Die neuen OWASP Top 10 2021 enthielten einige bedeutende Neuerungen sowie eine Überraschung: Injection-Schwachstellen fielen vom Spitzenplatz auf einen bescheidenen dritten Platz. Diese neuen Ergänzungen deuten auf eine Art „Stufe zwei“ für die Reise eines Entwicklers in Richtung sicherer Programmierung und bewährter Sicherheitspraktiken hin. Leider sind die meisten ohne entsprechende Schulung kaum in der Lage, hier einen positiven Beitrag zur Risikoreduzierung zu leisten.

Wir wissen schon seit Längerem, dass Entwickler über Sicherheitskompetenzen verfügen müssen, wenn wir häufige Sicherheitslücken im Code bekämpfen wollen, und Unternehmen reagieren zunehmend positiv auf das Konzept der entwicklergesteuerten Prävention. Da jedoch Insecure Design nun einen Platz in den OWASP Top 10 einnimmt und eher eine Kategorie architektonischer Sicherheitsprobleme als eine einzelne Art von Sicherheitslücke darstellt, müssen Entwickler über die Grundlagen hinaus gefordert werden, sobald sie diese beherrschen. Lernumgebungen, die Threat Modeling abdecken – idealerweise mit Unterstützung des Sicherheitsteams –, nehmen den Druck erheblich, sobald Entwickler erfolgreich weitergebildet wurden. Doch nach aktuellem Stand klafft hier bei den meisten Softwareentwicklern eine große Wissenslücke.

Dem entgegenzuwirken ist eine Gemeinschaftsaufgabe. Das Unternehmen kann eine wichtige Rolle dabei spielen, eine positive Sicherheitskultur für Entwickler zu schaffen, die deren Neugier weckt, ohne den Arbeitsablauf massiv zu stören.