Epic Failures in DevSecOps, Volume 1
10 juni, 2021
Boekbespreking
Eerder bespraken we het boek ‘Agile secure software lifecycle management, secure by agile design’. Het hier besproken boek sluit daar mooi op aan met een achttal verhalen over mislukkingen van epische allure bij het security aspect in aglie ontwikkelingsprojecten.
In vervolg op mijn vorige boekreview over Agile heb ik doorgepakt en een verdiepingsslag gemaakt met Epic Failures. Hier bespreek ik volume 1 van deze tweedelige publicatie. Epic Failures heeft een opmerkelijke insteek, namelijk schrijven over je mislukte acties, interventies of andere activiteiten – in dit geval in de DevSecOps-wereld. Dat zie je niet vaak. De meeste ‘goeroes’ schrijven over hun succesverhalen, omdat veel lezers die liever horen en zich graag vereenzelvigen met kennelijk succesvolle personen. In het beste geval krijgen mislukkingen in die publicaties indirect enige aandacht in de vorm van geleerde lessen en handvatten voor de lezer om niet in dezelfde valkuilen te stappen. De nadruk op mislukkingen maakt dit setje boeken dus zo bijzonder. Daarbij valt wel op te merken dat het falen in veel gevallen gaat over hoe ‘security’ onderdeel te maken van DevSecOps… of juist hoe het dus mis liep. En minder over ‘Dev’ of ‘Ops’.
Volume 1, de inhoud – acht losstaande verhalen
In acht losstaande verhalen schrijven negen in het ‘wereldje’ van DevSecOps bekende auteurs over hun ervaringen. Die variëren van het breed introduceren van security-gerelateerde activiteiten binnen de Software Development Life Cycle (SDLC) en het introduceren van een Red Team-cultuur tot het opzetten van een securitystrategie. Redelijk breed dus, en daardoor ook makkelijk leesbaar en afwisselende materie.
Ik geef per verhaal kort een paar highlights.
Verhaal 1: We are ALL special snowflakes
We worden meegenomen in de algemene ontwikkeling van security in het IT-domein en krijgen ook een beetje een vooruitblik hoe het terrein verder zal veranderen als AI echt van de grond gaat komen. De auteur geeft ook nog een paar basics mee als leerpunten om zijn punt te maken waarom security in al die voorbije jaren niet echt overtuigend zijn plek heeft gekregen binnen het domein van de IT.
Verhaal 2: The security Person who is not invited into the room
De titel spreekt boekdelen. De reputatie van ‘het team dat altijd nee zegt’ als uitgangspunt nemend, schetst de schrijver, op basis van haar eigen faalverhaal, waar je op moet letten om als InfoSec-specialist toch partner van de business te kunnen zijn.
Verhaal 3, The problem with succes
Dit verhaal geeft inzicht hoe je in een DevOps-aanpak succesvol geautomatiseerde securitymethodieken in de development-pipeline kunt introduceren… en hoe juist het succes van het introduceren en integreren van de tools de oorzaak werd dat het initiatief bijna ten onder ging. SAST, DAST, OSSM, CVA … alles komt voorbij. Even lezen, om op te frissen waar je het als auditor over moet hebben met je opdrachtgever en/of auditee
Verhaal 4, The table of the burning programme
De schijfster laat zien hoe snel alles uit de hand kan lopen als jij zelf pas laat in het traject – mid program, dus als het systeemontwikkelingsprogramma al vol op stoom is - verantwoordelijk wordt voor het borgen van security in de SDLC. De opdrachtgever hoopte aanvankelijk dat partners en system integrators de mogelijke problemen uiteindelijk wel zouden ondervangen. Zij waren tenslotte de deskundigen, nietwaar? En hoe beperkte transparantie, gebrek aan ontwikkelstandaarden, een weinig security-minded agile-cultuur en slechte contractering je het leven zuur kunnen maken bij je uiteindelijke streven naar een veilig eindproduct.
Verhaal 5, Threat Modelling – A disaster
Dit is een van mijn favorieten. Voor een auditor is de risicoanalyse altijd een belangrijk thema als je iets moet vinden van een DevOps-traject. Maar de praktijk is een stuk weerbarstiger, want documenteren (van risicoanalyses) is in deze aanpak vaak een vies woord. En omdat dit verhaal over een bancaire toepassing gaat, was dit wel een cruciale voorwaarde om zichtbaar te maken dat er ook een veilig fundament was gelegd. Hoe doe je dit documenteren dan toch slim, en houd je de ontwikkelaars aan boord? Tips en tricks volop, en ook de nodige valkuilen voor de auditor. In het begin gingen de development teams helemaal de mist in – leerzaam studiemateriaal.
Verhaal 6, Red Team the culture
Dit is vervolgens weer down to earth een traditioneel voorbeeld waarin vertrouwen te paard gaat. Het bedrijf in kwestie wilde een Red Teaming-activiteit opzetten om het volwassenheidsniveau van hun beveiliging na te gaan. Nou, dat hebben ze geweten. Oorspronkelijk was iedereen into the idea. Maar toen de uitkomsten en gehanteerde werkwijzen zichtbaar werden, begon men uit een ander vaatje te tappen. Zo wilden de lijnmanagers bijvoorbeeld alle rapporten herschrijven voordat het hoger management hier kennis van kon nemen. Een niet onbekend fenomeen.
Verhaal 7, Unicorn Rodeo
Dit verhaal gaat over de ervaringen van een securityspecialist bij een tech-startup die in de bancaire sector wil doorbreken. Omdat in die sector de security van een applicatie van doorslaggevend belang is, wil men binnen het DevOps kader de security strikt centraal managen vanuit een security squad. Het team gaat zo op in alle details dat het grotere plaatje, en daarmee hun promotors en stakeholders, helemaal uit het oog raakt. Ook was er niet in een toekomst vaste security-bewuste ontwikkelcultuur geïnvesteerd; de techniek en het integreren van de optimale security-tooling had de waan van de dag gedicteerd.
Verhaal 8, Strategic asymmetry – leveling the Playing Field between Defenders and Adversaries
Dit laatste verhaal schildert het opzetten van een succesvol DevSecOps-programma. Het laat zien waar, ondanks uiteindelijk succes, onderweg toch noch van alles is misgegaan. Met ‘lessons learned’ natuurlijk.
Helaas moeten we een boekbespreking kort houden, maar ik hoop dat de highlights de lezers voldoende zullen aanspreken om eens kennis te nemen van de besproken publicatie. We horen al té vaak succesverhalen… en in de regel is dat dan één triomf tussen een hele rits blunders – terwijl je juist van die blunders het meeste kunt leren.
Conclusie: leerzame fouten – ook voor de auditor, om zijn of haar onderzoek goed vorm te geven!
Het boekje is niet alleen voor informatiebeveiligers, managers, Scrum masters of Product Owners. Ook een IT-auditor die werkzaam is kan er lessen uit halen bij audits in een DevOps-omgeving. Bijvoorbeeld om zijn of haar onderzoek richting te geven bij het nagegaan waar het ondanks alle mooie verhalen fout kan zitten. Of als hulp om eventueel advies of verbeterpunten te formuleren.
Afsluitend volgen hierna enkele ‘lessons learned’ die zich bij mij opdrongen.
- Laat je niet in de luren leggen door wat ‘de boekjes’ zeggen over goede security-praktijken. De praktijk is vaak een stuk weerbarstiger dan de theorie.
- Blijf erop hameren dat de borging van security niet slechts in de methodieken wordt benoemd maar ook in de dagelijkse praktijk daadwerkelijk gebeurt.
- Die borging is in de SDLC van een DevOps organisatie geen sinecure. Tooling is daarbij onmisbaar. Het allemaal handmatig willen doen is namelijk vaak een recept voor ellende en weg-prioriteren of uiteindelijk zelfs achterwege laten van security.
Ir. J.E. (Jean-Jacques) Bistervels RE CIA/CFSA/CCSA CRISC/CDPSE CCP | Senior Audit Manager bij Obvion
Jean-Jacques Bistervels is werkzaam als auditmanager bij Obvion. Hij richt zich daar op IT en operational audits. Na zijn studie Technische Bedrijfskunde aan de TUE is hij zijn carrière bij Ernst & Young gestart als IT-auditor. Hij heeft daarna ruim zeven jaar gewerkt binnen de farmaceutische sector, daarna ruim tien jaar in de financiële sector en kort nog even in de wereld van gemeenten en media & educatieve bedrijven vertoefd. Binnen NOREA is hij actief voor de kennisgroep Software Development en als redacteur voor de IT-auditor.
