Anno 2020 is DevOps, de nieuwe manier van informatiesystemen ontwikkelen, niet meer weg te denken uit de ICT wereld. De mentaliteit van “You build it, you run it” is een vloek en een zegen tegelijk. Waar we eerst een scheiding konden aanbrengen tussen de ontwikkelaars en de operations afdelingen, wordt er tegenwoordig steeds meer gewerkt met teams bestaande uit minimaal deze beide disciplines. Om dit goed voor elkaar te krijgen dienen alle teamleden dezelfde “taal” te spreken, zodat een voorheen operations engineer ook weet waar een developer over praat, en dat een developer omgekeerd ook weet hoe je de software moet publiceren en vooral up-and-running kan houden. Maar waar blijft security in dit hele verhaal?
SLIM AUTOMATISEREN
Om deze taken te vereenvoudigen wordt er veelal gebruik gemaakt van tooling zoals een zogenaamde delivery / deployment pipeline, welke in de volksmond ook wel CI/CD straat wordt genoemd. Deze tooling begeleid het proces van broncode naar draaiende applicatie.
Zo’n delivery / deployment pipeline zal er schematisch ongeveer zo uit zien:
Zoals weergegeven worden er verschillende stappen ondernomen om van broncode in een versiebeheersysteem naar een werkende applicatie te komen. Vaak wordt de deployment stap nog verdeeld over meerdere stappen (eerst naar acceptatie omgeving, daarna naar productie).
En dan staat de applicatie buiten in het wild en wordt deze gebruikt door misschien wel miljoenen gebruikers. Hoera. Succes! Totdat de eerste meldingen (al dan niet geautomatiseerd) binnen komen dat de applicatie niet meer of niet stabiel werkt.
OEPS… KAPOT…
Na intensief onderzoek blijkt er een zogenaamde weakness of vulnerability in je applicatie te zitten welke misbruikt kan worden en daardoor de applicatie onstabiel maakt of laat crashen. Dus moet dit gerepareerd worden en gaat de nieuwe broncode weer heel de cyclus door. Gelukkig heeft de pipeline alle stappen geautomatiseerd en gaat dit relatief snel.
Maar… hoe kun je zeker weten dat deze weakness of vulnerability niet nog eens gaat voorkomen na een code aanpassing? Welkom in de wereld van DevSecOps, of eigenlijk SecDevSecOpsSec maar daar later meer over.
Door testcases op te nemen die misbruik van de weakness of vulnerability proberen te maken, kun je actief testen of deze niet per ongeluk terug komt door aanpassingen. Deze testcases worden actief afgespeeld op de software in de test stap van de pipeline, en als de test faalt dan gaat deze build niet verder naar buiten.
Dit is een stap in de goede richting, maar je kan nog meer doen. Zo kun je bijvoorbeeld OWASP ZAP (Z Attack Proxy) opnemen in je test stap om actief penetratie testen (bijv. SQL injection testen) uit te voeren op je software om proactief “onbekende” zwakheden te vinden.
Wat vervelender is, de vulnerability hoeft niet eens in je eigen code te zitten. Bijna alle software maakt gebruik van bibliotheken van derden. Hier kan onverhoopt ook een vulnerability of weakness in zitten, waardoor je mogelijk je eigen software in gevaar brengt. Kunnen we dit op voorhand weten? Nooit 100% zeker, maar gelukkig zijn er de zogenaamde CVE en CWE databases waarin deze weaknesses en vulnerabilities in populaire bibliotheken zijn opgenomen. En laat er nu tooling zijn die je software kan controleren of de gebruikte bibliotheken in deze databases voorkomen. Door deze tooling op te nemen in de pipeline ben je weer een stapje dichter bij veiligere software.
De delivery / deployment pipeline kan door een paar relatief kleine aanpassingen er als volgt uit gaan zien:
SECDEVSECOPSSEC?
Vandaar dat ik de mening ben toegedaan dat security eigenlijk door het hele proces moet zijn verweven dus vandaar dat ik i.p.v. DevSecOps liever zou zien dat er gedacht wordt aan SecDevSecOpsSec. Dat dit voor geen meter klinkt, snap ik, dus laten we het DevSecOps noemen, zolang de gedachte maar is dat security alleen effectief is als het cross-the-board wordt meegenomen.
