Chaos Engineering ist die Disziplin des geplanten Experimentierens an verteilten Systemen, um Schwachstellen aufzudecken und Vertrauen aufzubauen. Der Prozess umfasst das Einrichten der Umgebung, das Entwerfen und Durchführen von Experimenten sowie die Integration von Chaos Testing in die Organisation und Penetration Testing für Sicherheitsaspekte. Die Werkzeuge und Methoden im Chaos Engineering entwickeln sich kontinuierlich weiter, wobei die Durchführung regelmäßiger Gamedays für Teams empfohlen wird.

1. Der Status Quo des
Chaos Engineerings
ContainerConf 2020/21 - Cloud Native Day
Benjamin Tokgöz Josef Fuchshuber

2. Benjamin Tokgöz
Cloud Solution Architect
Herz schlägt für …
• Open Source
• Quantum Computing
• Wissenschaft
• Tiere
@benn0rs

3. Josef Fuchshuber
Director of Quality, Productivity +
Innovation
Herz schlägt für …
• Software Engineering und Handwerkstolz
• Everything as Code

4. Source: https://principlesofchaos.org
"Chaos Engineering ist die Disziplin des
durchdachten und geplanten
Experimentierens an einem verteilten
System, um Schwachstellen aufzudecken
und Vertrauen aufzubauen."

5. Warum?

6. Microservice Architekturen &
hochgradig verteilte Anwendungen
img source: "Resiliency through Failure" (A. Tseitlin, QCon NY, 2013)

7. Chaos Engineering & Chaos Testing
schließt Testabdeckungslücken

8. Wie neu sind die
Chaos Engineering
Ideen?
img source: https://www.gettyimages.de/detail/foto/woman-screaming-with-joy-opens-carton-parcel-box-lizenzfreies-bild

9. Wobei hilft uns Chaos Engineering?
§Battle Test für neue Infrastruktur und Services
§Quality Review: Kontinuierlich die Robustheit von Anwendungen verbessern
§Post Mortem: Reproduktion von Ausfällen
§On-Call Training

10. Die Chaos Engineering Levels

11. Was ist Chaos Engineering nicht?
img source: https://www.gettyimages.de/detail/foto/burning-car-lizenzfreies-bild/168266695

12. Step 0:
Observability

13. "Chaos Engineeringwithout observability … is just chaos"
@mipsytipsy, CEO of honeycomb
img source: https://www.gettyimages.de/detail/foto/burning-car-lizenzfreies-bild/168266695

14. Step 1:
Environment
Setup

15. Produktionsnah starten und nicht gleich in PROD
§ Die ersten Experimente sollte man eine Umgebung wählen, die identisch mit der in
Produktion ist. Nur dann kommt man zu aussagekräftigen Erkenntnissen.
§ Infrastruktur und integrierte Services wie in PROD (keine Mocks)
§ Applikationskonfigurationen analog zu PROD
§ Sobald die ersten Schritte getan sind und es zu Verbesserungen kam, kann der Weg
weiter in Richtung Produktion gehen.
§ Ziel sollte es aber sein, Tests in PROD zu machen:
§ Echte Kundenlast ist nie wie die von Lastgeneratoren oder Akzeptanztests.
§ Sie interagieren oftmals anders mit den Services als erwartet.

16. Step 2:
Experiment
&Hypothesen

17. Die Phasen des Chaos Testings
Steady State
Hypothese
Experiment
ausführen
Verifikation
Analysieren
und
Verbessern

18. Design und Ausführung von Experimenten
§ Stelle eine Hypothese auf
§ Beispiel: Wenn die Datenbank von meinem Webshop ausfällt, erscheint vor Kunde eine Fehlerseite
mit einer Kontaktmöglichkeit zum Support-Team
§ Designe den Umfang Ihres Experiments
§ Beispiel: Wie kann der Ausfall simuliert werden: Datenbank-Server herunterfahren, fehlerhafte
DNS-Routen eintragen, Netzwerkprobleme simulieren
§ Lege die für das Experiment relevanten Metriken fest
§ Beispiel: Health Check der Datenbank, HTTP Response Status Code 200
§ Informieren vor der Durchführung dein Team
§ Beispiel: Wenn ihr auf Shared-Environments experimentiert, Informiert immer das komplette Team
über eure Experimente.

19. Sei dir über den „Blast-Radius“ bewusst!

20. Man startet bei den Experimenten klein.
§Erst wenn ein Experiment erfolgreich war, wird der Blast-Radius vergrößert:
§ Weitere Komponenten oder Services werden hinzugenommen
§ Last, Fehlerquoten und Latenzen werden erhöht
§ ...
Blast-Radius

21. Die Eigenschaften der Chaos
Engineering Tools sind vielfältig
§ Kommerziell oder Open Source
§ API oder Operator basierend
§ Support des Chaos Engineering Levels
§ Zufallsbasiert oder experimentbasiert
Es gibt momentan nicht den "One-Stop-Shop", der alle Teams glücklich macht.

22. Chaos Engineering hat in der CNCF-
Landkarte eine eigene Kategorie
https://landscape.cncf.io/card-mode?category=chaos-engineering&grouping=category (Stand 01. Feb. 2021)

23. Step 3:
Etablieren in der
Organisation

24. Etablierung von Chaos Testing im Projekt
und in der Organisation.

25. Penetration
Testing + Chaos
Engineering

26. Penetration Testing + Chaos Engineering
Wissen aus dem Penetration Testing nutzen um mehr
Erkenntnisse über die eigene Infrastruktur zu gewinnen
Gezieltes einsetzen gängiger Tools um Schwachstellen zu
erkennen
Direkte Anbindung an Monitoring-Tools – wenn möglich

27. Use Cases für
Security Chaos
Engineering
Erkennung von Vulnerabilities in
der Software
Dediziert für jeden
Microservice
Kompetenzaufbau bei eigenen
Mitarbeiter zum Thema Exploits
Architektur und
Netzwerkentscheidungen
reviewen

28. Penetration Testing Phasen
Reconnaissance
Scanning
Gaining Access
Maintaining Access
Covering Tracks
Interessant für
Chaos Engineering!

29. Security Chaos Engineering
• Ein Event (oder auch Game day) um direkte und verwertbare Ergebnisse zu erhalten
• Angriffe auf das System beziehen sich hierbei klar auf Exploits und Vulnerabilities
• Reportings werden in Echtzeit von Penetration Testern, Security Engineers, Software
engineers, Business Stakeholdern und Mitgliedern der IT generiert und ausgewertet.

30. Besonderheiten beim Security CE.
Genau wie beim klassischen Chaos Engineering werden verschiedene bekannte Schritte durchlaufen
Aktuelle Bestandsaufnahme des Systems
Entwickeln einer Hypothese
Angriffsgrenzen festlegen
Fallback Pläne erstellen
In Kenntnis setzen der Organisation
Durchführung des Game days
Monitoring, Validation und Fazit
Reconfiguration des vorgesehenen Systems
Automatisiere das Experiment

31. Tools für SCE

32. Nmap
Automatisierung über bash scripts
Klassiker
https://github.com/nmap/nmap
Automatisierung über CI Plattformen wie GitHub

33. OWASP ZAP
Automatisierung über (z.B.) python scripts
Klassiker
https://github.com/zaproxy
Automatisierung über CI Plattformen wie GitHub

34. Metasploit Framework
Metasploit interaktiv nutzen während eines Game day
Metasploit automatisieren über resource scripts
Metasploit automatisieren über ruby scripts
Automatisierung über CI Plattformen wie GitHub
Klassiker
https://github.com/rapid7/metasploit-framework

35. Security Automatisierung
durch GitHub Actions

36. Empfehlungen
und
best practices
Ändert nie mehr als eine Variable zu
einer bestimmten Zeit
Kenne den Blast radius des Game
days!
Integriert die Ergebnisse in euer SIEM
Quelle: Securing chaos: How Security
Chaos Engineering tools can improve
design and response (rsa.com)

37. Buchempfehlung
für Secure Engineering
Author:
Ross Anderson
Title:
A guide to building dependable distributed systems
https://www.wiley.com/en-
us/Security+Engineering%3A+A+Guide+to+Building+Dependable+Di
stributed+Systems%2C+3rd+Edition-p-9781119642817

38. Demo

39. Chaos Toolkit Live-View: http://20-73-198-159.nip.io

40. Summary

41. Zusammenfassung
§ Das wichtigste am Chaos Engineering ist, dass man es macht:
§ Gamedays im gesamten Team sollten in jedem Team ein festes Ritual sein.
§ Startet in einer produktionsnahen Umgebung und prüft ob euer Monitoring ausreichend ist.
§ Werkzeuge kommen und gehen:
§ Die Chaos Engineering Werkzeuge im Cloud Native Ökosystem entwickeln sich weiter.
§ Der Kontext eurer Chaos Engineering Experimente wird sich erweitern.

42. Infos & Anmeldung unter: https://www.containerconf.de/lecture_workshop.php?id=12764