In deze blog focust Bram van de Kerkhof op Chaos Engineering en hoe wij de initiële stap hebben gemaakt voor een klant. Als purist zul je kunnen zeggen dat wat we hebben gedaan nog ver weg is van Chaos engineering. Maar toch wilde Bram het graag delen omdat vaak kleine stappen kunnen leiden tot meer. Lopen alvorens te gaan rennen als het ware.
Chaos engineering
Vaak hebben recovery testen een beperkte scope waar bijvoorbeeld enkel de data van een database wordt teruggezet. Maar wat nu als iemand toegang krijgt tot het systeem? Of onderdelen niet meer werken door bijvoorbeeld configuratiefouten? We zien dat hier een stuk minder op wordt getest. Hierdoor kan het voorkomen dat als deze situatie zich in het echt voordoet teams hier niet op zijn voorbereid. Een methodiek hiervoor is Chaos Engineering. Bij deze techniek leer je teams alert te blijven door structureel en willekeurig systemen binnen een applicatielandschap offline te brengen. Het probleem, als je dit bij een bedrijf voorstelt dit naar verwachting niet met al te veel positiviteit zal worden ontvangen. Ook moeten teams hierop voorbereid zijn omdat herstel ook via automatisering moet lopen. Iets wat past bij de DevOps principes maar vaak de volwassenheid of prioriteit nog niet op dat niveau zit.
De initiële stap
Om deze reden hebben we gekozen om te focussen op weerbaarheid en hier een activiteit van te maken die uitgevoerd moet worden door alle teams. Om de impact te minimaliseren scopen we de opdracht zodat cruciale systemen of productiesystemen niet geraakt worden tenzij de betrokken partijen zijn ingelicht, in de praktijk betekende dit vaak dat we op acceptatie de hersteltest uitvoerde. Het is niet perfect maar wel een initiële stap naar Chaos Engineering.
Binnen de afgesproken scope waren we vrij om te doen wat we wilden. Hierbij hebben we geprobeerd om op verschillende lagen chaos te creëren, vaak inclusief persistence aspect zodat simpel herstel alleen niet voldoende zou zijn. Zo hebben we logica binnen infrastructuur aangepast wat ervoor zorgde dat belangrijke databases bijvoorbeeld iedere 10 minuten leeggegooid werden. Voor andere team hebben we een ransomware aanval gesimuleerd door een database te encrypten of de gehele DNS records weg te gooien. Dit in combinatie met het weggooien van de source code in git om het herstel extra lastig te maken. Door dit in de praktijk uit te voeren en de resources echt te verwijderen of ontoegankelijk te maken, in plaats van een theoretisch of beperkt herstel uitvoer, e.g. data in database herstellen zag je dat de resultaten toepasbaarder waren.
Security in DevOps teams
Veel ging goed, maar waar verbetering zat, zagen we veel uitdaging van security in DevOps teams terugkomen. Kennisdeling tussen teamleden ontbrak soms, door bijvoorbeeld de senior ontwikkelaar of engineer buiten spel te zetten moesten minder ervaren teamleden opeens zelf een herstel uitvoeren. Ook zorgde de persistance dat teams meerdere herstelpogingen moesten doen en echt moesten onderzoeken wat de oorzaak was in plaats van alleen symptoombestrijding. Er was veel tijd besteed aan het schrijven van recovery scripts. Echter ontbrak in veel gevallen de kennis om te achterhalen hoe het probleem zich exact voldaan had waardoor een aanvaller langer aanwezig kon zijn dan nodig was. Toch hebben we gezien dat teams actief aan de slag gingen, plezier hadden en aan het einde van de activiteit vervolg stappen konden definiëren waardoor ze in de toekomst beter voorbereid zijn op een dergelijke situatie.
Opkomst van Chaos Engineering
Met de opkomst van DevOps binnen teams, de focus op korte loops, en veel automatisering zul je zien dat Chaos Engineering binnen security een steeds belangrijkere rol gaat krijgen. Door niet sporadisch te kijken of systemen weerbaar zijn, maar dit in te bouwen binnen processen, kun je met grotere zekerheid zeggen dat een bedrijf bestand is tegen incidenten die impact hebben op beschikbaarheid. Omdat dit voor veel bedrijven nog ver weg is adviseer ik: “begin klein zoals wij hebben gedaan en zie hoeveel daar al uit kan komen”.
Zekerheid inbouwen tijdens het ontwikkelproces?
Security issues al in het ontwikkelproces kunt minimaliseren. Wil je eens van gedachten wisselen? Neem contact op of bekijk onze dienstverlening.
