Die Probleme der Cybersicherheit, die wir 2022 nicht ignorieren können

Veröffentlicht Mar 28, 2022
von Matias Madou, Ph.D.
FALLSTUDIE

Die Probleme der Cybersicherheit, die wir 2022 nicht ignorieren können

Veröffentlicht Mar 28, 2022
von Matias Madou, Ph.D.
Ressource anzeigen
Ressource anzeigen

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

Die letzten zwei Jahre waren eine Art Feuertaufe für alle, aber das Konzept der Cybersicherheit für die meisten Unternehmen wurde auf die Probe gestellt, da viele von uns praktisch über Nacht auf ein Modell der Telearbeit umgestellt wurden. Wir mussten wirklich den Einsatz erhöhen und uns als Branche anpassen, vor allem als Folge der verzweifelten Bedrohungsakteure, die seit Beginn der Pandemie einen 300-prozentigen Anstieg der gemeldeten Cyberkriminalität verursachten.

Wir haben alle ein paar Lektionen gelernt, und mich tröstet die Tatsache, dass nicht nur die allgemeine Cybersicherheit ernster genommen wird, sondern auch die Software-Sicherheit und -Qualität auf Code-Ebene. Bidens Durchführungsverordnung zur Sicherung der Software-Lieferkette hat kritische Fragen ans Licht gebracht, insbesondere nach dem Masseneinbruch bei SolarWinds. Der Gedanke, dass wir uns alle mehr um die Sicherheit kümmern und daran arbeiten müssen, Schwachstellen durch ein messbares Sicherheitsbewusstsein zu verringern, ist definitiv ein größerer Teil der Diskussion.

Wenn es um den Kampf gegen Cyberkriminelle geht, müssen wir ihnen jedoch so weit wie möglich folgen und ihre Spielplätze mit einer präventiven Denkweise verhindern. 

Ich denke, dass sie im kommenden Jahr Wellen schlagen werden:

Das Metaversum ist eine neue Angriffsfläche

Das Metaverse mag die nächste Evolution des Internets sein, aber ein ähnlicher Wandel in der Art und Weise, wie die meisten Branchen die Sicherung von Software und digitalen Umgebungen angehen, steht noch aus. 

Während allgemeine Cybersecurity-Fallen wie Phishing-Betrügereien unvermeidlich sind (und wahrscheinlich zahlreich auftreten werden, während jeder mit dem Metaversum zurechtkommt), müssen die eigentliche Infrastruktur und die Geräte, die diese immersive virtuelle Welt ermöglichen, sicher sein. Ähnlich wie die Smartphones uns geholfen haben, online zu leben, sind Peripheriegeräte wie VR-Headsets das neue Tor zu Bergen von Benutzerdaten. Immer komplexere eingebettete Systeme sind erforderlich, um IoT-Gadgets sicher zu machen, und die schöne neue Welt von VR/AR ist da keine Ausnahme. Wie wir mit dem Log4Shell-Exploit gesehen haben, können sich einfache Fehler auf der Code-Ebene zu einem Backstage-Pass für Bedrohungsakteure entwickeln, und in einer simulierten Realität erzeugt jede Bewegung Daten, die gestohlen werden können.  

Ein erfolgreiches Metaverse, das noch in den Kinderschuhen steckt, erfordert die praktische Anwendung von Kryptowährungen (und nicht nur das willkürliche Horten des neuesten Meme-Coins) und Wertgegenständen wie NFTs, was bedeutet, dass unser reales Vermögen, unsere Identität, unsere Daten und unser Lebensunterhalt potenziell einem neuen "Wilden Westen" ausgesetzt sind, der die Menschen gefährden kann. Bevor wir Ingenieure uns mit epischen Funktionen und Erweiterungen überschlagen, sollte die Minimierung dieser neuen, riesigen Angriffsfläche von Grund auf Priorität haben.

Gesetzgebung im Gefolge von Log4Shell

Für die zahlreichen Entwickler, die im Chaos versinken mussten, um herauszufinden, ob es eine ausnutzbare Version des weit verbreiteten Log4j-Protokollierungswerkzeugs gibt oder ob Abhängigkeiten bestehen, waren die Feiertage sicher keine schöne Zeit. 

Dieser Zero-Day-Angriff gehört zu den schlimmsten in der Geschichte. Es wurden Vergleiche zwischen Log4Shell und der verheerenden Heartbleed-OpenSSL-Schwachstelle gezogen, die auch über sechs Jahre später noch ausgenutzt wird. Wenn es nach dieser Zeitachse geht, werden wir noch lange mit einem Log4Shell-Kater zu kämpfen haben. Es ist klar, dass trotz der Lehren, die aus Heartbleed gezogen wurden - zumindest in Bezug auf die Notwendigkeit, Patches so schnell wie möglich bereitzustellen und zu implementieren - viele Unternehmen einfach nicht schnell genug handeln, um sich zu schützen. Je nach Größe des Unternehmens kann das Patchen unglaublich schwierig und bürokratisch sein und eine abteilungsübergreifende Dokumentation und Implementierung erfordern. Häufig verfügen IT-Abteilungen und Entwickler nicht über ein enzyklopädisches Wissen über alle verwendeten Bibliotheken, Komponenten und Tools und werden durch strenge Zeitpläne für die Bereitstellung behindert, um Störungen und Ausfallzeiten von Anwendungen zu minimieren. Es gibt triftige Gründe für diese Arbeitsweise (niemand will einen Fehler machen und etwas kaputt machen), aber wer zu langsam patcht, ist eine leichte Beute.

So wie der SolarWinds-Angriff die Software-Lieferkette verändert hat, sage ich voraus, dass Ähnliches im Gefolge von Log4Shell passieren wird. Während es in einigen kritischen Branchen bereits Patch-Management-Mandate und -Empfehlungen gibt, ist eine weit verbreitete Gesetzgebung eine andere Geschichte. Vorbeugende Softwaresicherheit wird immer die beste Möglichkeit sein, dringende Sicherheits-Patches ganz zu vermeiden, aber bewährte Sicherheitsverfahren schreiben vor, dass Patches eine nicht verhandelbare Prioritätsmaßnahme sind. Ich denke, dies wird ein heißes Thema sein und zu nicht ganz so subtilen Empfehlungen führen, schnell und oft zu patchen. 

Mehr Gewicht auf architektonische Sicherheit (und die Entwickler sind nicht bereit)

Die neue OWASP Top 10 2021 enthielt einige wichtige Neuzugänge sowie eine Überraschung: Injection-Schwachstellen fielen von der Spitzenposition auf einen bescheidenen dritten Platz. Diese Neuzugänge deuten auf eine Art "zweite Stufe" der Reise eines Entwicklers in Bezug auf sichere Kodierung und bewährte Sicherheitspraktiken hin, und leider sind die meisten nicht in der Lage, hier einen positiven Einfluss auf die Risikominderung zu nehmen, wenn sie nicht entsprechend geschult sind.

Wir wissen schon seit einiger Zeit, dass Entwickler über Sicherheitskenntnisse verfügen müssen, wenn wir häufige Sicherheitsfehler im Code bekämpfen wollen, und die Unternehmen reagieren immer besser auf die Prämisse der entwicklergesteuerten Prävention. Da Insecure Design jedoch einen Platz in den OWASP Top 10 beansprucht und eher eine Kategorie von architektonischen Sicherheitsproblemen als eine einzelne Art von Sicherheitsfehlern ist, müssen Entwickler über die Grundlagen hinaus gefördert werden, sobald sie diese beherrschen. Lernumgebungen, die die Modellierung von Bedrohungen abdecken - idealerweise mit Unterstützung des Sicherheitsteams - nehmen den Druck von den Entwicklern, sobald sie sich erfolgreich fortgebildet haben, aber so wie es aussieht, ist es für die meisten Softwareingenieure eine erhebliche Wissenslücke.

Um dem entgegenzuwirken, braucht es ein Dorf", und das Unternehmen kann eine Rolle bei der Schaffung einer positiven Sicherheitskultur für Entwickler spielen, indem es ihre Neugierde weckt, ohne ihre Arbeitsabläufe wesentlich zu stören.

Ressource anzeigen
Ressource anzeigen

Autor

Matias Madou, Ph.D.

Matias ist ein Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung im Bereich der Softwaresicherheit. Er hat Lösungen für Unternehmen wie Fortify Software und sein eigenes Unternehmen Sensei Security entwickelt. Im Laufe seiner Karriere hat Matias mehrere Forschungsprojekte zur Anwendungssicherheit geleitet, die zu kommerziellen Produkten geführt haben, und kann auf über 10 Patente verweisen. Wenn er nicht am Schreibtisch sitzt, ist Matias als Ausbilder für fortgeschrittene Anwendungssicherheitstrainings courses tätig und hält regelmäßig Vorträge auf globalen Konferenzen wie RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec und BruCon.

Matias hat einen Doktortitel in Computertechnik von der Universität Gent, wo er die Sicherheit von Anwendungen durch Programmverschleierung untersuchte, um die innere Funktionsweise einer Anwendung zu verbergen.

Sie wollen mehr?

Tauchen Sie ein in unsere neuesten Erkenntnisse über sichere Kodierung im Blog.

Unsere umfangreiche Ressourcenbibliothek zielt darauf ab, die menschliche Herangehensweise an eine sichere Weiterbildung im Bereich der Programmierung zu stärken.

Blog ansehen
Sie wollen mehr?

Holen Sie sich die neuesten Forschungsergebnisse zur entwicklergesteuerten Sicherheit

Unsere umfangreiche Ressourcenbibliothek ist voll von hilfreichen Ressourcen, von Whitepapers bis hin zu Webinaren, die Ihnen den Einstieg in die entwicklungsorientierte sichere Programmierung erleichtern. Erforschen Sie sie jetzt.

Ressourcendrehscheibe

Die Probleme der Cybersicherheit, die wir 2022 nicht ignorieren können

Veröffentlicht Mar 28, 2022
Von Matias Madou, Ph.D.

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

Die letzten zwei Jahre waren eine Art Feuertaufe für alle, aber das Konzept der Cybersicherheit für die meisten Unternehmen wurde auf die Probe gestellt, da viele von uns praktisch über Nacht auf ein Modell der Telearbeit umgestellt wurden. Wir mussten wirklich den Einsatz erhöhen und uns als Branche anpassen, vor allem als Folge der verzweifelten Bedrohungsakteure, die seit Beginn der Pandemie einen 300-prozentigen Anstieg der gemeldeten Cyberkriminalität verursachten.

Wir haben alle ein paar Lektionen gelernt, und mich tröstet die Tatsache, dass nicht nur die allgemeine Cybersicherheit ernster genommen wird, sondern auch die Software-Sicherheit und -Qualität auf Code-Ebene. Bidens Durchführungsverordnung zur Sicherung der Software-Lieferkette hat kritische Fragen ans Licht gebracht, insbesondere nach dem Masseneinbruch bei SolarWinds. Der Gedanke, dass wir uns alle mehr um die Sicherheit kümmern und daran arbeiten müssen, Schwachstellen durch ein messbares Sicherheitsbewusstsein zu verringern, ist definitiv ein größerer Teil der Diskussion.

Wenn es um den Kampf gegen Cyberkriminelle geht, müssen wir ihnen jedoch so weit wie möglich folgen und ihre Spielplätze mit einer präventiven Denkweise verhindern. 

Ich denke, dass sie im kommenden Jahr Wellen schlagen werden:

Das Metaversum ist eine neue Angriffsfläche

Das Metaverse mag die nächste Evolution des Internets sein, aber ein ähnlicher Wandel in der Art und Weise, wie die meisten Branchen die Sicherung von Software und digitalen Umgebungen angehen, steht noch aus. 

Während allgemeine Cybersecurity-Fallen wie Phishing-Betrügereien unvermeidlich sind (und wahrscheinlich zahlreich auftreten werden, während jeder mit dem Metaversum zurechtkommt), müssen die eigentliche Infrastruktur und die Geräte, die diese immersive virtuelle Welt ermöglichen, sicher sein. Ähnlich wie die Smartphones uns geholfen haben, online zu leben, sind Peripheriegeräte wie VR-Headsets das neue Tor zu Bergen von Benutzerdaten. Immer komplexere eingebettete Systeme sind erforderlich, um IoT-Gadgets sicher zu machen, und die schöne neue Welt von VR/AR ist da keine Ausnahme. Wie wir mit dem Log4Shell-Exploit gesehen haben, können sich einfache Fehler auf der Code-Ebene zu einem Backstage-Pass für Bedrohungsakteure entwickeln, und in einer simulierten Realität erzeugt jede Bewegung Daten, die gestohlen werden können.  

Ein erfolgreiches Metaverse, das noch in den Kinderschuhen steckt, erfordert die praktische Anwendung von Kryptowährungen (und nicht nur das willkürliche Horten des neuesten Meme-Coins) und Wertgegenständen wie NFTs, was bedeutet, dass unser reales Vermögen, unsere Identität, unsere Daten und unser Lebensunterhalt potenziell einem neuen "Wilden Westen" ausgesetzt sind, der die Menschen gefährden kann. Bevor wir Ingenieure uns mit epischen Funktionen und Erweiterungen überschlagen, sollte die Minimierung dieser neuen, riesigen Angriffsfläche von Grund auf Priorität haben.

Gesetzgebung im Gefolge von Log4Shell

Für die zahlreichen Entwickler, die im Chaos versinken mussten, um herauszufinden, ob es eine ausnutzbare Version des weit verbreiteten Log4j-Protokollierungswerkzeugs gibt oder ob Abhängigkeiten bestehen, waren die Feiertage sicher keine schöne Zeit. 

Dieser Zero-Day-Angriff gehört zu den schlimmsten in der Geschichte. Es wurden Vergleiche zwischen Log4Shell und der verheerenden Heartbleed-OpenSSL-Schwachstelle gezogen, die auch über sechs Jahre später noch ausgenutzt wird. Wenn es nach dieser Zeitachse geht, werden wir noch lange mit einem Log4Shell-Kater zu kämpfen haben. Es ist klar, dass trotz der Lehren, die aus Heartbleed gezogen wurden - zumindest in Bezug auf die Notwendigkeit, Patches so schnell wie möglich bereitzustellen und zu implementieren - viele Unternehmen einfach nicht schnell genug handeln, um sich zu schützen. Je nach Größe des Unternehmens kann das Patchen unglaublich schwierig und bürokratisch sein und eine abteilungsübergreifende Dokumentation und Implementierung erfordern. Häufig verfügen IT-Abteilungen und Entwickler nicht über ein enzyklopädisches Wissen über alle verwendeten Bibliotheken, Komponenten und Tools und werden durch strenge Zeitpläne für die Bereitstellung behindert, um Störungen und Ausfallzeiten von Anwendungen zu minimieren. Es gibt triftige Gründe für diese Arbeitsweise (niemand will einen Fehler machen und etwas kaputt machen), aber wer zu langsam patcht, ist eine leichte Beute.

So wie der SolarWinds-Angriff die Software-Lieferkette verändert hat, sage ich voraus, dass Ähnliches im Gefolge von Log4Shell passieren wird. Während es in einigen kritischen Branchen bereits Patch-Management-Mandate und -Empfehlungen gibt, ist eine weit verbreitete Gesetzgebung eine andere Geschichte. Vorbeugende Softwaresicherheit wird immer die beste Möglichkeit sein, dringende Sicherheits-Patches ganz zu vermeiden, aber bewährte Sicherheitsverfahren schreiben vor, dass Patches eine nicht verhandelbare Prioritätsmaßnahme sind. Ich denke, dies wird ein heißes Thema sein und zu nicht ganz so subtilen Empfehlungen führen, schnell und oft zu patchen. 

Mehr Gewicht auf architektonische Sicherheit (und die Entwickler sind nicht bereit)

Die neue OWASP Top 10 2021 enthielt einige wichtige Neuzugänge sowie eine Überraschung: Injection-Schwachstellen fielen von der Spitzenposition auf einen bescheidenen dritten Platz. Diese Neuzugänge deuten auf eine Art "zweite Stufe" der Reise eines Entwicklers in Bezug auf sichere Kodierung und bewährte Sicherheitspraktiken hin, und leider sind die meisten nicht in der Lage, hier einen positiven Einfluss auf die Risikominderung zu nehmen, wenn sie nicht entsprechend geschult sind.

Wir wissen schon seit einiger Zeit, dass Entwickler über Sicherheitskenntnisse verfügen müssen, wenn wir häufige Sicherheitsfehler im Code bekämpfen wollen, und die Unternehmen reagieren immer besser auf die Prämisse der entwicklergesteuerten Prävention. Da Insecure Design jedoch einen Platz in den OWASP Top 10 beansprucht und eher eine Kategorie von architektonischen Sicherheitsproblemen als eine einzelne Art von Sicherheitsfehlern ist, müssen Entwickler über die Grundlagen hinaus gefördert werden, sobald sie diese beherrschen. Lernumgebungen, die die Modellierung von Bedrohungen abdecken - idealerweise mit Unterstützung des Sicherheitsteams - nehmen den Druck von den Entwicklern, sobald sie sich erfolgreich fortgebildet haben, aber so wie es aussieht, ist es für die meisten Softwareingenieure eine erhebliche Wissenslücke.

Um dem entgegenzuwirken, braucht es ein Dorf", und das Unternehmen kann eine Rolle bei der Schaffung einer positiven Sicherheitskultur für Entwickler spielen, indem es ihre Neugierde weckt, ohne ihre Arbeitsabläufe wesentlich zu stören.

Wir bitten Sie um Ihre Erlaubnis, Ihnen Informationen über unsere Produkte und/oder verwandte Themen der sicheren Codierung zuzusenden. Wir werden Ihre persönlichen Daten immer mit äußerster Sorgfalt behandeln und sie niemals zu Marketingzwecken an andere Unternehmen verkaufen.

Senden
Um das Formular abzuschicken, aktivieren Sie bitte "Analytics"-Cookies. Sie können die Cookies wieder deaktivieren, sobald Sie fertig sind.