Security Chaos Engineering 101: Grundlagen

In diesem Artikel wird die Positionierung von Security Chaos Engineering (SCE) als Aspekt der Sicherheitstechnik erörtert. Die Hauptmotivation besteht darin, Sicherheitsingenieuren und anderen Cybersicherheitsexperten zu ermöglichen, SCE als Teil der Sicherheitstechnik zu betrachten; es handelt sich nicht um ein esoterisches Handwerk. Die Übernahme dieser Denkweise ist von entscheidender Bedeutung für SCE entmystifizieren; was eine Voraussetzung ist, um die inhärenten Vorteile nutzen zu können. Darüber hinaus werden in diesem Artikel zwei Missverständnisse über SCE behandelt, um objektive Informationen und Klarheit des Wissens zu vermitteln.

Hinweis: Dies ist der erste Teil einer zweiteiligen Serie, und einige der Inhalte wurden in unserem letzten Webinar behandelt - Erste Schritte mit Security Chaos Engineering (Link zur Aufzeichnung).

Security Chaos Engineering als Aspekt der Sicherheitstechnik

Security Chaos Engineering (SCE) ist ein neuartiger Ansatz für Cybersicherheit; seine Kerngrundlagen basieren auf Prinzipien des Chaos Engineering, obwohl das Ziel darin besteht, Cyber-Resilienz zu ermöglichen. Chaos Engineering ermöglicht es Unternehmen beispielsweise, Ausfälle zu überstehen, die durch Verfügbarkeits- und Leistungsstörungen verursacht werden. Umgekehrt können Unternehmen durch die Einführung von SCE werden Sie widerstandsfähig gegen Cyberangriffe, z. B. Ransomware-Angriffe.

Sicherheitstechnik

Die Sicherheitstechnik konzentriert sich auf das Entwerfen und Bauen von Systemen und Anwendungen unter Berücksichtigung der Sicherheit. Es beinhaltet die Anwendung von Sicherheitsprinzipien und bewährten Verfahren auf den gesamten Entwicklungszyklus, von der Anforderungsanalyse und dem Entwurf bis hin zur Implementierung und zum Testen. Die Sicherheitstechnik zielt darauf ab, Systeme zu entwickeln, die von Natur aus sicher sind und verschiedenen Arten von Angriffen und Bedrohungen widerstehen können.

In seinem Buch “Sicherheitstechnik“, renommierter Cybersicherheitsexperte und Professor für Sicherheitstechnik, Ross Anderson behauptet“Bei der Sicherheitstechnik geht es darum, Systeme so zu bauen, dass sie angesichts von Böswilligkeit, Irrtümern oder Missgeschicken zuverlässig bleiben.“. Ross gibt außerdem Einblicke in die Bedeutung der Durchführung von Sicherheitstests im Rahmen der Sicherheitstechnik. Im Idealfall zielen Sicherheitstests darauf ab, sicherzustellen, dass Systeme wie geplant implementiert werden, und zwar in späteren Phasen, um Sicherheitslücken im System zu identifizieren. Daher ist eine Möglichkeit, SCE unter diesem Gesichtspunkt zu betrachten, insbesondere wenn SCE auf die Anwendungssicherheit angewendet wird.

SCE kann auf den gesamten Entwicklungslebenszyklus angewendet werden, insbesondere im gesamten 4 Cs der cloudnativen Sicherheit. Dieser Artikel konzentriert sich auf seine Anwendung auf der Cloud-Infrastrukturebene. Angesichts der Tatsache, dass diese Dimension der Sicherheitstechnik unter die Cloud-Infrastruktur fällt, ist es sinnvoll, sie als Cloud-Sicherheitstechnik. Cloud-Sicherheitsingenieure sind für mehrere Cybersicherheitsaufgaben verantwortlich, die die Sicherheit der Cloud-Infrastruktur gewährleisten. Diese Aufgaben können unter dem Oberbegriff zusammengefasst werden Cloud-Sicherheitstechnik. In der Regel werden Cloud-Sicherheitsingenieure damit beauftragt oder erwartet, SCE-Experimente durchzuführen. SCE kann jedoch von verschiedenen Cybersicherheitsexperten genutzt werden. In der Cloud-Sicherheitstechnik gibt es zwei Anwendungen von SCE: Überprüfung der Cloud-Sicherheit und Überprüfung der Cloud-Cyber-Resilienz.

Cloud-Sicherheit Überprüfung

SCE kann genutzt werden, um Cloud-Sicherheitskontrollen zu verifizieren. Aufgrund der damit verbundenen Komplexität ist die Überprüfung von Cybersicherheitskontrollen kein häufig diskutiertes Thema. In herkömmlichen, lokalen Systemen werden die Ergebnisse der Sicherheitskontrollen größtenteils wie folgt verwendet Wahrheit. Diese Haltung ist jedoch in Bezug auf Cloud-Infrastrukturen ziemlich riskant. Cloud-Sicherheitskontrollen werden zusammen mit der Infrastruktur eingesetzt (z. B. Infrastructure-as-Code), wodurch das Risiko erhöht wird Sicherheitslücken, die auf Fehlkonfigurationen beruhen. Es kommen mir mehrere andere Herausforderungen in den Sinn, die die Cloud-Sicherheit erschweren: potenzielle Beeinträchtigung der Cloud-Sicherheitskontrollen, schnell wachsende Cloud-Angriffsflächen und eine zunehmend komplexe Infrastruktur. Daher ist die kontinuierliche Überprüfung der Cloud-Sicherheitskontrollen für eine gesunde Cloud-Sicherheitslage unerlässlich. Cloud-Sicherheitsteams können SCE nutzen, um zu überprüfen, ob die Sicherheitskontrollen erwartungsgemäß funktionieren, d. h. um Verstöße gegen Sicherheitsattribute (Vertraulichkeit, Integrität und Verfügbarkeit) zu verhindern. Die Abbildung unten zeigt beispielsweise ein Experiment zur Cloud-Sicherheitsüberprüfung, bei dem überprüft werden soll, ob AWS GuardDuty eine Benachrichtigung an einen Slack-Channel sendet, wenn ein S3-Bucket veröffentlicht wird.

Überprüfung der Cloud-Cyber-Resilienz

Das wichtigste und disruptivste Ziel von SCE ist es, Cyber-Resilienz zu ermöglichen. Dieser Aspekt wird am wenigsten verstanden, da die Definition und Praxis von Cyber-Resilienz oft missverstanden, missbraucht und ziemlich abstrakt ist. Die Disziplinen Software- und Plattformtechnik haben bereits ein ausgereiftes Verständnis von Resilience Engineering entwickelt, einschließlich Frameworks, die die praktische Umsetzung beschleunigen. Zum Beispiel haben die meisten Cloud-Dienstanbieter bereits eine Resilienz-Säule als Teil ihrer Gut durchdachtes Framework. In den meisten Fällen werden Aspekte der Cyber-Resilienz unter Resilienz/Zuverlässigkeit zusammengefasst. Dies hilft Cybersicherheitsexperten nicht wirklich, da die Definitionen und Anforderungen oft verschwommen sind. Diese Unterschiede können durch die Einführung von Tools und Ansätzen zur Implementierung und Überprüfung der Cyberresistenz geklärt werden. Hier kommt SCE ins Spiel.

Es ist wichtig, die Cyberresistenz von Cloud-Infrastrukturen kontinuierlich zu überprüfen. Dies kann durch eine Vielzahl von Ansätzen erreicht werden. Ein Ansatz besteht darin, tatsächliche Angriffe einzuschleusen (die meisten Menschen bevorzugen den Begriff Angriffssimulation), um zu beobachten, wie die Infrastruktur reagiert. Diese Angriffe testen die Reaktion der Cyber-Resilienzmechanismen. Wenn beispielsweise ein Ransomware-Angriff ausgeführt wird, wird deutlich, ob die Gegenmaßnahmen gegen Ransomware wirksam sind. Die Ausgabe ist nicht binär; sie hat viele Seiten. Es könnte interessant sein, Kennzahlen zu messen, z. B. die Mean Time to Respond (MTTR), Recovery Time Objective (RTO) und Recovery Point Objective (RPO). Die beiden letzten Metriken sind wichtige Aspekte der Zuverlässigkeitssäule des AWS Well-Architected Framework.

Irrtümer über Security Chaos Engineering

In Bezug auf SCE gibt es zwei größte Missverständnisse: Bei SCE geht es um groß angelegte, komplexe Angriffe, und Experimente sollten groß angelegt werden, und SCE beginnt in Produktionsumgebungen. Lassen Sie uns diese Missverständnisse erörtern.

Irrtum 01: Bei SCE geht es um groß angelegte, komplexe Angriffe

Interessanterweise besteht der falsche Eindruck, dass SCE nur durch groß angelegte, komplexe Angriffe erreicht wird. Ich vermute, dass diese Denkweise stark von der Wahrnehmung beeinflusst wird, die durch die Simian Army von Netflix hervorgerufen wurde, z. B. durch den Chaosgorilla, der ganze AWS-Verfügbarkeitszonen zerstört hat. Es ist aufschlussreich zu wissen, dass Chaos Monkey das erste und ursprüngliche Mitglied der Simian-Armee war, und es hat eine Sache getan — eine oder mehrere AWS-Instanzen offline nehmen. Die übrigen Mitglieder der Simian-Armee, z. B. Chaos Kong und Chaos Gorilla, wurden eingeführt, um auf dem anfänglichen Erfolg von Chaos Monkey aufzubauen. Diese schrittweise Einführung von Chaos Engineering verdeutlicht die Notwendigkeit organisatorischer Reife.

Es ist daher unerlässlich, SCE mit grundlegenden Tests zu beginnen, z. B. mit der Veröffentlichung von AWS S3-Buckets, um zu beobachten, ob Sicherheitsüberwachungsmechanismen Warnmeldungen auslösen und, noch besser, wie schnell die Warnungen eintreffen. Dieses grundlegende Beispiel (auf das wir im nächsten Blogbeitrag näher eingehen werden) bietet bereits wichtige Lernmöglichkeiten für Maßnahmen in den Bereichen Sicherheit und Cyberresistenz und sollte ernst genommen werden.

Irrtum 02: SCE startet in Produktionsumgebungen

Wie das vorherige Missverständnis beziehen sich die meisten Leute, die auf Chaos Engineering stoßen, auf Netflix und die Definition von Chaos Engineering auf der Prinzipien des Chaos Engineering Webseite. Es ist jedoch wichtig zu verstehen, dass die Ingenieure, die das Chaos Engineering populär machten, geschickt und sehr erfahren waren. Außerdem arbeiteten sie in einer Organisation, die mit enormen Verfügbarkeitsproblemen (Risikoprofil) konfrontiert war und die auch über die Ressourcen verfügte, um diese Herausforderungen mit einem Chaos-Engineering-Ansatz (Budget) zu bewältigen. Dementsprechend konnten sie es sich leisten, Chaos Engineering-Experimente schnell in die Produktion zu verlagern.

Die meisten technischen Verfahren beginnen in der lokalen Umgebung eines Entwicklers und gehen schrittweise in eine Entwicklungsumgebung über, bevor sie schließlich in der Produktion ankommen. Dieser Ansatz ermöglicht einen schrittweisen und gezielten Aufbau von kontextuellem und praktischem Wissen. Die Einführung von SCE sollte einem ähnlichen Prozess folgen. Beginnen Sie mit dem Schreiben Ihrer Skripte in der Umgebung, in der Sie sich am wohlsten fühlen, verbessern und darauf abzielen, irgendwann in die Produktion zu gelangen, denn dort möchten Sie schützen. Die Häufigkeit des Wechsels von einer Umgebung in eine andere wird von vielen Faktoren bestimmt: Fähigkeiten, Bedrohungsprofil des Unternehmens, Geschäftsanforderungen usw.

Als Maßstab sollten daher die folgenden Faktoren berücksichtigt werden, wenn erwogen wird, Sicherheitschosstests in die Produktion zu überführen: Fähigkeiten des Sicherheitstechnikteams, Unternehmensrisikoprofil, Geschäftsanforderungen und Sicherheitsbudget. Unter dem Strich sind diese Faktoren kein Hindernis für die Einführung von SCE. Sie können immer von Ihrer lokalen Umgebung oder Ihrer Entwicklungsumgebung ausgehen.

Nutzung der Mitigant SCE-Plattform zur nahtlosen Einführung von Security Chaos Engineering

Die Kosten für die Entwicklung einer Security-Chaos-Engineering-Strategie sind für die meisten Unternehmen entmutigend. Darüber hinaus ist das technische Know-how relativ nicht verfügbar. Mitigant löst diese Herausforderungen durch die Bereitstellung einer SaaS-Plattform.

Die Mitigant SCE-Plattform besteht aus mehreren Cloud-Angriffen, die als Bausteine für die Erstellung komplexer Angriffsszenarien gegen die AWS-Infrastruktur genutzt werden können. Die Plattform ermöglicht sichere und kontrollierte SCE-Experimente, Angriffe können mit Tastenklicks gestartet und gestoppt werden, und alle an der Cloud-Infrastruktur vorgenommenen Änderungen werden rückgängig gemacht und nahtlos wiederhergestellt. Darüber hinaus werden alle Angriffe dem zugeordnet MITRA BEI T&CK Bibliothek, die die Implementierung von Angriffen in der realen Welt in freier Wildbahn ermöglicht.

Die Plattform von Mitigant SCE zielt darauf ab, als erstklassiger Bürger in einer Cloud-nativen Infrastruktur die Cyber-Resilienz zu fördern. Sie eignet sich für Unternehmen aller Größen und ermöglicht eine schnelle und sichere Einführung von SCE, ohne den bereits oben genannten Kosten- und Ressourcenaufwand in Kauf nehmen zu müssen. Bitte zögern Sie nicht, uns zu kontaktieren, wenn Sie Security Chaos Engineering einführen möchten.