taa22 - stock.adobe.com
Ein Einstieg in das Security Chaos Engineering
Chaostests schleusen absichtlich neue Fehler in eine Umgebung ein. Dadurch wird geprüft, wie gut oder schlecht die IT darauf reagiert. So lassen sich Lücken finden und beheben.
Ein neuer Begriff macht derzeit die Runde: Security Chaos Engineering. Hierzulande ist er noch nicht sehr bekannt, aber das dürfte sich bald ändern. Auf den ersten Blick erinnert Security Chaos Engineering an das Durchführen von Penetrationstests, aber die Ähnlichkeiten sind geringer als gedacht. Beide Konzepte werden genutzt, um Schwächen oder Sicherheitslücken in einem System aufzuspüren, bevor ein Schaden durch eine echte Attacke entstehen kann. Während Penetrationstests aber echte Angriffe simulieren, werden bei sogenannten Chaostests absichtlich Fehler, Ausfälle und anderes zufälliges Verhalten ausprobiert. Auf diese Weise kann dann geprüft werden, ob und wie das System sie bemerkt und wie es damit umgeht.
Ein Sicherheitsteam, das die Erlaubnis haben möchte, eine produktiv genutzte Anwendung absichtlich zu sabotieren, wird in den meisten Fällen auf Ablehnung stoßen. Es handelt sich bei Security Chaos Engineering aber um kontrolliert durchgeführte Experimente, die – bei sorgfältiger Planung – zu einer deutlich sichereren und widerstandsfähigeren IT-Umgebung führen können. Außerdem stärken sie das Vertrauen in die eigenen Systeme und die Überzeugung, dass diese auch wirklich so funktionieren wie gewünscht.
Wie sich Security Chaos Engineering für Sicherheitstests nutzen lässt
Die ersten Versuche, die ein Unternehmen im Bereich Security Chaos Engineering durchführt, sollten allerdings nur in einer Test- oder Staging-Umgebung erfolgen. Auf diese Weise können sich die Mitglieder des Teams in Ruhe mit den erforderlichen Werkzeugen und Prozessen vertraut machen. Ein Punkt sollte dabei aber nie übersehen werden: Mehr als ein einziges Experiment, zum Beispiel eine absichtlich fehlerhafte Konfiguration eines Ports, sollte nie in einem gegebenen Zeitraum durchgeführt werden. Auf diese Weise ist anschließend klar, welcher Grund, also das was, wie und warum, tatsächlich für die ausgelösten Veränderungen verantwortlich ist.
Das Ziel beim Security Chaos Engineering ist nicht, einen komplexen Angriff gegen eine größere Infrastruktur zu starten. Dadurch würde ein ganz anderes Bild entstehen, das es erheblich schwieriger macht, genau zu verstehen, wo der Vorfall tatsächlich seinen Ursprung hat und wie die Zusammenhänge aussehen. Die Beteiligten sind während solcher Tests auch nicht unter dem hohen Druck, der während eines echten Angriffs schnell entsteht. Trotzdem lernen sie durch die Experimente viel. Vermeiden Sie es, zu viele Variablen und Parameter auf einmal zu ändern oder einzuführen. Ansonsten entstehen möglicherweise sich gegenseitig aufschaukelnde Effekte, die den Blick auf das versperren, was ursprünglich geplant war.
Jeder, der durch das Experiment in welcher Form auch immer betroffen ist und der benötigt wird, das System wieder ordnungsgemäß zum Laufen zu bringen, sollte von Anfang an in die Tests mit einbezogen werden. Damit sind etwa Software- und Netzwerkingenieure gemeint, aber auch die Incident-Response- und Sicherheitsteams. Hilfreich ist es, wenn jeder Beteiligte zumindest in Grundzügen versteht, wie man programmiert. So können sie leichter verstehen, wie Software aufgebaut ist und wie komplex sie sein kann. Das trifft besonders auf Umgebungen zu, die auf Infrastructure as Code (IaC) setzen oder dies für die nähere Zukunft planen.
Auch eine genaue Planung des Tests im Vorfeld ist unabdingbar. Definieren Sie vorher, welche Bestandteile der Test umfassen wird und legen Sie fest, was geschehen soll, wenn die Systeme und Kontrollen genau so arbeiten wie erwartet. Ebenso sollte bestimmt werden, an welchem Punkt und unter welchen Umständen der Test beendet wird. Um beim Beispiel des absichtlich fehlerhaft konfigurierten Ports zu bleiben: Sie sollten festlegen, welche Firewall-Regeln den nicht autorisierten Datenverkehr über den fraglichen Port erkennen sollen, welche Ereignisse dadurch ausgelöst werden, wo sie registriert und verarbeitet werden und wer die Alerts erhalten soll. Das ist in sich bereits ein interessanter Test, da die betroffenen Software-, Netzwerk- und Lösungsspezialisten in der Regel divergierende Ansichten darüber haben, wie das gesamte System funktionieren soll.
Sobald ein Test gestartet wurde, zeichnen Sie jedes erwartete und unerwartete Ereignis auf. Prüfen Sie zudem, wie schnell das zuständige Team das Problem nur auf Basis der Informationen beheben kann, die von den Sicherheitskontrollen generiert werden. Führt der Test jedoch zu unvorhergesehenen Problemen oder Instabilitäten, dann sollte er beendet und die absichtlich eingeschleusten Fehler wieder entfernt werden.
Nach dem Abschluss des Tests sollten die Ergebnisse dann genau geprüft werden. Anschließend kann etwa festgelegt werden, welche Maßnahmen nötig sind, damit das System den Test beim nächsten Durchlauf besteht. Kommt es zum Beispiel zu Abweichungen der Konfiguration zwischen mehreren Instanzen? Müssen die Log-Einträge ausführlicher gestaltet werden? Alerts sind gut. Das gilt aber nicht, wenn aus ihnen nicht klar wird, von welcher Instanz sie stammen. Andere Ergebnisse zeigen möglicherweise, dass bestimmte Firewall-Regeln nicht mehr relevant oder effektiv sind. Haben die vorhandenen Sicherheitsmaßnahmen erreicht, was sie eigentlich erledigen sollen und wofür sie ursprünglich konfiguriert wurden? Eventuell hat auch ein Mangel an Personal oder Kenntnissen dafür gesorgt, dass ein Fehler länger existiert, als nötig. Auf jeden Fall kann das Incident Response Team aus dem Test viel über seine Stärken und Schwächen lernen.
Nachdem die unterschiedlichen Sicherheitskontrollen in der Testumgebung geprüft wurden, kann der Test in die produktiven Bereiche verlagert werden. Dieser Schritt ist wichtig, da es in verteilten Umgebungen meist zumindest graduelle Unterschiede in den Konfigurationen verschiedener Systeme gibt. Aufgrund der Geschwindigkeit, dem Umfang und den zahlreichen Änderungen dieser Dienste und Ressourcen sind solche Diskrepanzen nahezu unvermeidlich.
Verfügbare Tools für Security Chaos Engineering
Auch wenn Security Chaos Engineering noch eine vergleichsweise junge Disziplin ist, gibt es bereits eine stetig wachsende Zahl von Werkzeugen, mit denen Unternehmen eigene Chaos-Tests aufsetzen und durchführen können. Im Folgenden finden Sie eine kleine Auswahl:
- ChaoSlingr ist hauptsächlich auf AWS-Umgebungen ausgerichtet. Das Tool schleust Fehler ein, die sicherheitsrelevante Probleme identifizieren sollen.
- Gremlin verfügt über eine Bibliothek mit verschiedenen Angriffsvarianten. Sie können für unterschiedliche Szenarien und für Tests in Container-Umgebungen verwendet werden.
- Die Chaos Automation Platform wurde vom Streaming-Dienst Netflix entwickelt. Sie hilft, die Deployment-Pipeline eines ausgewählten Services zu testen. Das Tool startet dazu experimentelle Cluster des ins Visier genommenen Dienstes und führt verschiedene fehlerbehaftete Szenarien durch. Die Ergebnisse der Tests lassen sich durch den Betreiber des Dienstes in einem Report auswerten.
- Verica ist eine Plattform für automatisierte Experimente in Umgebungen, die Kubernetes oder Apache Kafka einsetzen und kann relativ leicht genutzt werden. Die Lösung stammt von früheren Entwicklern der Chaos Automation Platform.
- Chaos Toolkit ist ein Open-Source-Projekt, das es Programmierern ermöglicht, eigene Experimente für spezifische Anwendungsfälle zu entwickeln.
Auf mögliche Fehler testen, statt abzuwarten
In Anbetracht der kontinuierlich hohen Zahl von sicherheitsrelevanten Vorfällen im Internet, müssen die Schutzmaßnahmen weiterentwickelt werden, um besser mit verteilten, kurzlebigen oder unveränderlichen Systemen umgehen zu können. Noch mehr Geld für die bisher genutzten Lösungen auszugeben, ist aber ganz klar nicht mehr der richtige Weg. Das liegt unter anderem daran, dass es für Menschen zunehmend schwieriger wird, moderne Anwendungen und die für sie benötigte Infrastruktur im Kopf zu modellieren. Zudem ist es unmöglich geworden, solche Applikationen in jedem denkbaren Status mit Pentests unter die Lupe zu nehmen. Security Chaos Engineering kann die Antwort auf die Frage sein, wie Unternehmen den allgemeinen Schutz und das Vertrauen in ihre geschäftskritischen Anwendungen wieder erhöhen können.
