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

In diesem Artikel wird die Einführung von SCE als sicherheitstechnische Praxis vorgestellt, die nicht esoterisch, sondern realisierbar ist. Die Hauptmotivation besteht darin, Sicherheitstechnikern und Fachleuten im Allgemeinen zu ermöglichen, SCE als jede andere sicherheitstechnische Maßnahme zu betrachten und den Aufwand und die Auswirkungen ihrer Einführung zu entmystifizieren. Darüber hinaus werden in diesem Artikel mehrere Missverständnisse über SCE behandelt, um objektive Informationen und Klarheit des Wissens zu vermitteln.

Dieser Artikel ist eine Fortsetzung eines früherer Artikel in dem mehrere grundlegende Aspekte von Security Chaos Engineering erörtert wurden, einschließlich einiger weit verbreiteter Missverständnisse. In diesem Artikel werden praktische Beispiele für die Durchführung von SCE-Experimenten vorgestellt.

Hallo World SCE

Die meisten von uns praktizieren bereits unwissentlich irgendeine Form von SCE. Das Erstellen, Ändern oder Löschen von Cloud-Ressourcen bildet die Grundlage für SCE-Experimente, und dies sind die grundlegenden Techniken. Warum also nicht direkt SCE nennen, zwei wichtige Punkte: Denkweise und Absicht.

Die richtige Denkweise annehmen

Die für SCE gewählte Denkweise ist entscheidend für die Erstellung der richtigen Hypothese und die Durchführung erfolgreicher Experimente. Die Denkweise bezieht sich im Allgemeinen auf eine Denkweise, eine Einstellung, eine Meinung, insbesondere auf eine gewohnheitsmäßige. Es ist wichtig, eine Denkweise zu haben, bei der man von einem Verstoß ausgeht. Andernfalls könnte eine widersprüchliche Hypothese aufgestellt werden, die keine effektiven Experimente unterstützt. Eine Denkweise, die in der Lage ist, bestehende Überzeugungen und Kulturen in Frage zu stellen, ist erforderlich. Wenn wir von einer Denkweise sprechen, bei der von einem Sicherheitsverstoß ausgegangen wird, muss davon ausgegangen werden, dass ein Angreifer Zugriff auf eine Cloud-Umgebung erhalten kann. Dies ist die erste Hürde, auf die eine widersprüchliche Denkweise stoßen wird, nämlich die Notwendigkeit, davon überzeugt zu sein, dass Angreifer eine „eiserne“ präventive Abwehr umgehen können. Beispiele für diese Art von Kompromissen gibt es zuhauf, z. B. Datenpannen bei LastPass.

Die richtige Absicht verfolgen

Die Absicht, ein SCE-Experiment durchzuführen, besteht darin, aus Fehlern zu lernen und proaktiv zu sein. Sie möchten Beweise für bestimmte Annahmen erhalten, bevor Sie Schlussfolgerungen ziehen. Idealerweise sollten Sicherheitsentscheidungen nicht auf Bauchgefühl oder Herstellerversprechen beruhen, sondern auf Experimenten, Fakten und Daten. Es gibt Raum für Wissen, das aus Erfahrung stammt; dies muss jedoch mit empirischen Analysen abgewogen werden. Außerdem wird, wie in der letzter Blogartikel Was SCE-Irrtümer angeht, so besteht die Absicht nicht darin, die Umwelt mit balistischen Angriffen zu überwältigen. Versuche, dies zu tun, werden zu Burnout, Stress und Unmut des Managements und anderer Sicherheitsmitarbeiter führen. Das Wichtigste ist, klein anzufangen, Ihre Strategien schrittweise zu lernen und zu verbessern.

SCE-Experiment — Öffentlicher S3-Bucket

Das Experiment, das wir verwenden werden, basiert auf einem öffentlichen S3-Bucket. Ziel ist es, zu experimentieren und Beweise für die Ereignisse und Reaktionen zu sammeln, die eintreten würden, wenn ein S3-Bucket absichtlich, versehentlich oder aufgrund gegnerischer Aktionen veröffentlicht würde. Für dieses Experiment werden wir einen vorhandenen Bucket verwenden. Sie können jedoch gerne einen neuen Bucket erstellen. Ziel ist es zu beobachten, was passiert, wenn der S3-Bucket bereits existiert; ob eine Sicherheitskontrolle effektiv funktioniert.

Schritt 1: Stellen Sie den Steady State her

Sobald der Ziel-Bucket ausgewählt wurde, muss der Steady-State hergestellt werden. In diesem Beispiel kann der Steady-State so einfach sein wie die Konfiguration des Ziel-S3-Buckets. Infrastructure-as-Code kann für die Markierung des Steady-State genutzt werden.

Schritt 2: Machen Sie den S3-Bucket öffentlich

Es gibt mehrere Möglichkeiten, einen AWS-Bucket öffentlich zu machen. Zwei dieser Methoden werden im Folgenden mithilfe der AWS-CLI dargestellt. Mit dem ersten Befehl kann jeder im Internet auf den Bucket und seinen Inhalt (Objekte) zugreifen.

aws s3api put-bucket-acl --bucket sce-experiment --acl öffentlich lesen-schreiben

Der zweite Befehl deaktiviert die `public-access-block-configuration` vollständig.

aws s3api delete-public-access-block --bucket sce-experiment

Schritte 3 und 4: Beobachten

Wenn der Bucket veröffentlicht wird, werden einige Ereignisse für ein gut gesichertes AWS-Konto erwartet. In der Regel werden Sicherheitskontrollen eingesetzt, um Sicherheitsereignisse zu verhindern, zu erkennen oder sich von ihnen zu erholen. Diese Sicherheitskontrollen sind kontextabhängig von der Umgebung und basieren auf der Sicherheitsarchitektur. Nehmen wir an, GuardDuty wird als detektivische Sicherheitskontrolle eingesetzt; daher wird erwartet, dass es auf der Grundlage einer früheren Konfiguration eine Warnung auslöst. Hinweis: Es wird davon ausgegangen, dass GuardDuty so konfiguriert wurde, dass Warnmeldungen, die auf bestimmten Regeln basieren, an einen Slack-Channel gesendet werden. Einzelheiten zur Konfiguration von GuardDuty-Benachrichtigungen mit Slack-Benachrichtigungen finden Sie auf der folgende Dokumentation. Wenn Sie dies in Ihrer Umgebung versuchen, erhalten Sie je nach Konfiguration die Warnungen möglicherweise als GuardDuty-Ergebnisse. Einige wichtige Fragen, die es zu berücksichtigen gilt

• Können Sie den genauen GuardDuty-Befund identifizieren?
• Macht der GuardDuty-Befund für Sie Sinn, d.h. können Sie ihn interpretieren?
• Ist die GuardDuty-Feststellung umsetzbar?
• Wie lange hat es gedauert, bis der GuardDuty-Fund eintraf, als der Bucket veröffentlicht wurde?

Weitere Fragen können kreativ geklärt werden, aber lassen Sie uns die Sache einfach halten.

Schritt 5: Wiederherstellen

Schließlich möchten wir den Eimer wieder in seinen stabilen Zustand versetzen. Dies kann über die AWS-CLI oder über Terraform erfolgen. Es könnte möglich sein, andere Strategien anzuwenden, die die Persistenz von Cloud-Ressourcen ermöglichen, z. B. kann ein agiles Cloud-Inventar- und Asset-Management-System genutzt werden, um die früheren Änderungen rückgängig zu machen.

aws s3api put-public-access-block --public-access-block-configuration blockpublicACLS=true, ignorepublicACLS=true, blockpublicPolicy=true, restrictPublicBuckets=true --bucket sce-experiment

Schritt 6: Analyse und Planung

Die Beobachtungen und Ergebnisse des Experiments sind entscheidend und nützlich, um faktenbasierte Entscheidungen zu treffen, die die Sicherheit und Cyberresistenz verbessern. Es können mehrere Ansätze verfolgt werden. In unserem S3-Experiment haben wir beispielsweise Benachrichtigungen von GuardDuty über die Slack-Integration erwartet. Rechtzeitige Benachrichtigungen sind jedoch nützlicher, da sie die Lücke zwischen einem erfolgreichen und einem gestoppten Angriff schließen könnten. Eine daraus abzuleitende Lehre besteht darin, praktisch zu ermitteln, wie lange es dauert, bis die GuardDuty-Benachrichtigung eingeht, und zu entscheiden, ob die Lieferzeit akzeptabel ist. Eine Verbesserung in dieser Hinsicht wird die Implementierung von S3-Bucket-Ereignissen und den dazugehörigen Lambda-Funktionen sein. Dadurch können die Ereignisse fast sofort ausgelöst und gemeldet werden. Einzelheiten zur Implementierung von S3-Bucket-Ereignissen finden Sie in der AWS-Dokumentation. Nach dieser Verbesserung könnte ein Folgeexperiment durchgeführt werden, um die Wirksamkeit und andere notwendige Verbesserungen zu überprüfen. Beachten Sie, dass dies nur eine Dimension der Verbesserung ist. Die Antworten auf die gestellten Fragen sind kontextabhängig, und ihre Beantwortung bietet eine angemessene Anleitung für die richtigen Verbesserungsansätze. Das Wichtigste ist, Ihre Sicherheitskontrollen und Investitionen schnell zu bewerten und fundierte, faktengestützte Entscheidungen zu treffen.

Die Mitigant SCE-Plattform

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 dass Kosten und Ressourcenaufwand auf sich genommen werden müssen. Die Kosten der Umsetzung einer SCE-Strategie könnten für die meisten Unternehmen entmutigend sein. 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.

Melden Sie sich noch heute für eine kostenlose Testversion der Mitigant SCE-Plattform an, um die Cyber-Resilienz für Cloud-Infrastrukturen unter https://mitigant.io/sign-up aufzubauen.

‍