Succesfactoren voor DevSecOps in agile software development

Wat zijn succesfactoren om DevSecOps te regelen in een agile omgeving? Deze vraag stond centraal in een gesprek tussen ISACA-leden Mirna Bognar en Nico Kaag.

Zeggen dat DevSecOps zijn passie is gaat Nico Kaag te ver. Maar hij zou wel graag zien dat security een vast onderdeel wordt bij (agile) softwareontwikkeling. In de praktijk ziet Nico namelijk nog vaak dat softwareontwikkelaars uitstekend software kunnen ontwikkelen, maar onvoldoende aandacht hebben voor security. En dat terwijl de nadelen toch vaak in het nieuws zijn. ‘Je leest vrijwel dagelijks in de krant dat er vulnerabilities in software zijn, dat er spullenboel ontvreemd is’, zegt Nico. Waarom die aandacht voor security er niet is, durft Nico niet te zeggen. ‘Misschien ontbreekt de kennis. Of is het niet sexy genoeg voor de ontwikkelaars. Security blijft toch een beetje eng, denk ik.’

‘Is dit anders dan vroeger?’ wil Mirna weten. Ze schetst de situatie voorheen: ‘Vroeger verliep de ontwikkeling van software vaak projectmatig. Er waren grote ontwikkelprojecten, met uitvoerige risk assessments. Vervolgens was er het implementatieproces. Daar zaten nadelen aan die agile werken moest ondervangen. Wat heb je zien veranderen met agile werken? Waren we vroeger misschien beter in security?’

Nico schudt direct zijn hoofd. ‘We waren vroeger zeker niet beter als het gaat om security. Security was toen juist nog een beetje een onontgonnen gebied. We hadden nooit gedacht dat mensen, bewust of onbewust, via software dingen zouden gaan doen die we niet willen dat ze doen. Ik denk dat security toch op de één of andere manier niet in de genen zit van de ontwikkelaar.’

‘Security moet een onderdeel zijn van de deliverable’

Nico vergelijkt het gebrek aan aandacht voor security bij softwareontwikkeling met roken. ‘Waarom blijven mensen roken, terwijl ze weten dat het slecht voor ze is? Zo zie ik dat ook een beetje met softwareontwikkeling. Security lijkt voor ontwikkelaars nog een ver-van-mijn-bed show. Ze denken dat het een add-on is van hun werk. Ik denk dat het juist een vast onderdeel van hun werk zou moeten zijn. Je kunt tegenwoordig ook geen auto meer kopen zonder antiblokkeersysteem (dat zorgt dat de auto bestuurbaar blijft bij een noodstop, red.). Datzelfde zou ik ook bij de oplevering van software willen verwachten. Dat er geen Cross-Site Scripting in zit. Dat er geen bekende vulnerabilities in zitten als het wordt geleverd. Security zou een onderdeel moeten zijn van de deliverable en dat is het nog niet.’

Nico wijst op de ‘shift left’ die in de markt gaande is. ‘Als securityteam gaan we steeds meer naar de voorkant, het begin van het ontwikkelproces. Security requirements worden onderdeel van de business/non functional requirements. Teams zullen zich hierdoor meer bewust worden dat de business security belangrijk vindt en misschien zelfs als USP (Unique Selling Point) kan worden gebruikt. Daardoor zullen ze security een onlosmakelijk onderdeel moeten maken van het product.’

‘Maak de Product Owner accountable’

Nico’s streven om security te verankeren in agile software development komt niet zomaar uit de lucht vallen. In 2021 rondde hij een onderzoek af aan The Hague Graduate School naar security in agile werkende softwareteams. Doel van het onderzoek was om te bepalen wat de impact is van AgileSecDevOps op de bedrijfsrisico’s en hoe deze risico’s kunnen worden beïnvloed. Naast een literatuurstudie naar AgileSecDevOps deed Nico met een information securityteam van zes personen drie maanden lang onderzoek bij een (anoniem beschreven) organisatie met zeventien agile scrumteams.

‘Je noemde net dat security requirements onderdeel moeten worden van de business requirements. Hoe zorg je dat security requirements vanaf het begin worden meegenomen? Gaat dat vanzelf?’ vraagt Mirna.

Nico: ‘Dat gaat zeker niet vanzelf. In de teams van het onderzoek benoemden we allereerst een Security Champion. We kozen iemand met interesse in security en diegene probeerden wij dan te motiveren om security op de radar te krijgen bij de DevSecOps teams. Vanuit het information securityteam boden we uiteraard wel ondersteuning bij vragen enzovoort. En we hielpen de champion als we merkten dat security niet genoeg aandacht en prioriteit kreeg. Daarnaast maakten we de Product Owner accountable. Als software niet veilig bleek, werd de Product Owner erop aangesproken. Oplevering van software is immers de verantwoordelijkheid van de Product Owner, niet van security. We belegden het eigenaarschap met andere woorden beter en eenduidig. Als de Product Owner niet meewerkte, werd het moeilijk. Maar begrijp wel, we eisten niet direct een tien. We namen eerst genoegen met een vijf of zes. Zo bouwden we het samen op.’

‘Wijs capaciteit toe voor security maintenance in de sprintplanning’

Mirna: ‘Je maakte de Product Owner verantwoordelijk. Welke uitdaging volgde dan?’

‘Als een product wordt gereleased in productie, kunnen er initieel al kwetsbaarheden in zitten. Of er komen kwetsbaarheden bij als er iets nieuws wordt toegevoegd. Ik zag dat er in de daaropvolgende sprints vaak geen ruimte was voor maintenance, oftewel onderhoud. De sprints waren veelal volgepland met nieuwe functionaliteiten. Er werden dan dus alleen nieuwe functionaliteiten ontwikkeld of functionaliteiten werden verbeterd. Maar er was geen ruimte om security flaws aan te passen.’

‘Security was belegd bij de Product Owner, maar kreeg een lagere prioriteit?’ vraagt Mirna.

Nico: ‘Ja, en daarom adviseerden we ook om in de sprintplanning op te nemen dat 20-25% van de capaciteit wordt gealloceerd en mogelijk besteed aan onderhoud’, legt Nico uit. ‘Toen zagen we dat er meer aandacht kwam voor security.’

‘Was dat voldoende?’ wil Mirna weten.

Nico: ‘Soms wel, soms niet. We zagen wel dat hoe beter de teams werkten ‘aan de voorkant’, hoe minder tijd het team uiteindelijk nodig had voor security issues. Met die 20-25% tijd bleken teams uiteindelijk wel uit te komen.’

‘Je bent zo sterk als de zwakste schakel’

‘Wat gebeurde er vervolgens in de teams?’ vraagt Mirna door.

Nico: ‘We zagen enorme verschillen in volwassenheid van de teams. De deliverables worden door de teams geleverd, maar functioneren vaak in één ecosysteem. Hierdoor ben je zo sterk als je zwakste schakel, zagen we.’

Mirna: ‘Hoe zorg je als organisatie dat die zwakste schakel gezien wordt? En hoe pak je dit vervolgens aan?’

Nico: ‘Als information securityteam zagen we in penetratietesten en vulnerabilityscans waar security flaws zaten. Daarna gingen we met de zwak presterende teams in gesprek. We vroegen naar de oorzaken. Ontbreekt het aan middelen en/of kennis? Hebben jullie onvoldoende tijd? Was dit laatst het geval, dan lieten we het team aanhaken bij een goed presterend team. Die kon het zwakkere team dan overtuigen dat security ‘erbij hoort’. Dat het mogelijk is om goed te plannen en prioriteren en dat het dan overall veelal geen extra tijd kost. We stelden ook de vraag: ‘Als je geen tijd hebt om het in een keer goed te doen, waar haal je dan de tijd vandaan om de fout(en) te herstellen?’ Zagen we verschillen in de CI/CD-pipeline, dan adviseerden we bijvoorbeeld om de tooling en kennis beter in te zetten. Uiteindelijk gingen de teams elkaar helpen, door ervaringen en kennis te delen. Ook plaatsten we mensen uit goed presterende teams in de zwakkere teams. Dat werkte heel goed. Die mensen vonden het ook leuk om te helpen.’

‘Neem security op in beoordeling’

Mirna: ‘Hoe zou je de rol en verantwoordelijkheid van het information securityteam omschrijven in dit proces? Hoe zorgden jullie met andere woorden dat de teams jullie volgden?’

Nico legt uit: ‘De Chief Information Security Officer in de organisatie was de linking pin naar de directie. Het directieteam vond het ook belangrijk dat er veilige software werd gebouwd. Daarnaast werd het borgen van security een beoordelingscriterium van de mensen. De Product Owner werd bijvoorbeeld beoordeeld op het aantal security incidenten en bevindingen uit penetratietesten. Later maakten we de CI/CD-pipeline ook strakker. We deden automatische vulnerability scans. Als de scans uitwezen dat er fouten inzaten, kon je nieuwe code niet inchecken als developer. Je kon het product daardoor niet naar productie brengen. En dat vinden mensen natuurlijk niet leuk.’

Mirna: ‘Hoe waren de beoordelingscriteria vormgegeven? Ging dat bijvoorbeeld via kpi’s of via het Dreyfus Maturity model?’

‘We gebruikten het ASAMM-model (Agile Software Assurance Maturity Model, een methode om de Software Development Life Cycle te analyseren en te verbeteren, red.). We hebben een grote vragenlijst gemaakt op basis van het SAMM-model van OWASP. SAMM is nog erg ‘waterval’. Daar hebben we dus Agile aan toegevoegd. Verder kwam één en ander terug in de persoonlijke beoordeling van de werknemers. Dan zie je het gedrag veranderen. Maar we gaven mensen ook wel een kans om kpi’s waar te kunnen maken, hè. We ondersteunden ze met tijd, met tooling, opleiding en dat soort zaken.’

‘De grootste uitdaging was om te laten zien dat security geen business disabler is, maar een business enabler.’

Mirna: ‘Wat vond je in het onderzoek het moeilijkste om te implementeren of laten uitvoeren?’

Nico: ‘Om de business owners te overtuigen. Die vonden het bijvoorbeeld duur en te lang duren, terwijl er haast was om te voldoen aan nieuwe richtlijnen van de toezichthouders of wetgeving. Daar ‘verscholen’ zij zich naar mijn mening wel achter’, zegt Nico. ‘De grootste uitdaging was om te laten zien dat security geen business disabler is, maar een business enabler. Met veilige producten heb je minder onderhoud, minder ellende. De tijd die je er aan de voorkant insteekt, krijg je er aan de achterkant weer voor terug. Om dat te laten zien, vond ik wel een uitdaging. We lieten overigens ook zien wat de gevolgen kunnen zijn als je een onveilig product levert. Het kost het bedrijf geld, je krijgt ontevreden klanten en soms veroorzaakt het zelfs een faillissement. Dat hielp wel.’

‘Hoe hebben jullie dat concreet gemaakt?’ wil Mirna weten. ‘Wat voor metrieken hebben jullie gebruikt op de verschillende niveaus?’

Nico: ‘We gebruikten het aantal findings uit de penetratietesten. En het aantal meldingen door middel van responsible disclosure.’

Mirna: ‘Hebben jullie de uitkomst van het onderzoek ook getoetst bij andere bedrijven?’

Nico schudt zijn hoofd: ‘Wel hebben we eerst een nulmeting gedaan. En na een jaar hebben we nog een meting gedaan. We zagen gek genoeg niet dat het veel veiliger was geworden. Dat kwam vooral omdat er zoveel verschil was tussen de teams. Het ene team leverde wel een veilig product, maar het andere niet. Je ecosysteem blijft hierdoor dan onveilig. Je moet de teams echt zien als communicerende vaten, anders heb je een probleem.’

Mirna: ‘Maar hoe wist je dan dat je onderzoek succesvol was?’

‘We denken dat we de teams te positief hebben ingeschat bij de nulmeting. Positiever dan ze bleken bij de individuele begeleiding van de teams.’

Mirna: ‘En effecten van dit soort trajecten zie je vaak ook veel later.’

Nico knikt. ‘We zagen wel een verandering, namelijk dat het securityteam meer werd gezien als een kritische vriend in plaats van de afdeling business preventie. We hebben ook heel duidelijk het ‘comply and explain’ principe gehanteerd. Want misschien zijn er goede redenen om op een stukje een minder veilig product te leveren. Maar laten we dit dan uitleggen en beschrijven wat we eraan gaan doen om het risico te laten accepteren. Met andere woorden: maak het transparant.’

‘Als je nu terugkijkt op het onderzoek, wat waren de key succesfactoren met het oog op het ontwikkelen van veiligere software?’ vraagt Mirna.

‘Allereerst wezen we de Security Champion niet aan, maar kozen we iemand die zijn vinger opstak en het leuk vond om te doen. Daarnaast hebben we diegene ook goed geïnstrueerd, begeleid en regelmatig overlegd met die persoon. Ook hebben we de Champion er niet op afgerekend als het nog niet goed ging. We beloonden juist als het wel goed ging. Het leuke was, je zag dat andere mensen langzaamaan ook wel Security Champion wilden worden. Zo gingen mensen hetzelfde gedrag vertonen en ging de aanpak als een olievlek door de organisatie.’

Het hielp ook dat het onderzoeksteam dedicated was toegewezen om de ontwikkelteams te begeleiden, legt Nico uit. ‘We hoefden ons niet bezig te houden met andere securityzaken. We focusten ons op de development teams.’

Nico benadrukt ook dat de teams meededen aan het onderzoek op basis van vrijwilligheid. ‘We hebben de Product Owners gevraagd om mee te doen aan ons onderzoek. We lieten de doelen zien en vertelden ook wat we met de resultaten zouden doen. We benadrukten ook dat we de resultaten zouden anonimiseren. Teams konden zodoende niet zien en zeggen dat een bepaald team het slecht deed. Teams waren ook niet verplicht om mee te doen. We waren bang dat teams anders politiek correcte antwoorden zouden geven. Alleen de onderzoekers en de Product Owners konden de resultaten inzien. De CISO en board kregen alleen de anonieme gegevens. Hierdoor voelden mensen zich veilig en durfden ze fouten te maken. Of een minder positieve, meer realistische score te geven, denk ik. En ook al deed niet iedereen mee, we hebben door het onderzoek wel alle teams kunnen meenemen in de verbetering.’

Mirna vat samen: ‘Om veiligere software te bereiken is het dus -kort gezegd- van belang dat security onderkend wordt in de organisatie. Dat de CISO aanwezig is in de board en dat de risico’s van onveilige software duidelijk zijn. Verder moet de accountability belegd wordt bij de Product Owner. Ook is vrijwilligheid belangrijk bij het benoemen van de Security Champion en de samenwerking met en tussen de DevSecOps teams. Daarnaast heb je een aantal mechanismen benoemd, zoals het opnemen van security in de targets en beoordeling van mensen, in de CI/CD-pipeline en in de sprintplanning.’

Nico: ‘En maak het onderdeel van je kpi’s. Laat het team dat soort dingen rapporteren aan het managementteam.’

‘Security moet gezien worden als onderdeel van het product’

Nico benadrukt een belangrijke succesfactor: ‘Wat vooral belangrijk is en waar we naartoe wilden, is dat security niet meer apart wordt gezien van het product, maar als onderdeel van het product. Veiligheid moet gewoon in de software zitten, is hier een onlosmakelijk deel van.’

Mirna: ‘En de rol van de Product Owner is in de agile manier van werken ook van belang.’

Nico knikt: ‘We hebben vooraf het product heel gedetailleerd gedefinieerd. Zo werd duidelijk waar de Product Owner end-to-end verantwoordelijk voor is. We hebben het echt DevSecOps gemaakt. ‘What you build is what you run and own, zeg maar. Er is altijd een generieke laag waar de security centraal geregeld is. Maar je moet als Product Owner bijvoorbeeld wel nagaan of de server waar je spullenboel op draait gepatcht is, je moet downtime inplannen enzovoort.’

‘Hoe hebben jullie de architecten in de loop gehouden?’ vraagt Mirna. ‘Zij werken vaak overkoepelend en voelen zich vaak los staan van het ontwikkelproces.’

‘Het was inderdaad een uitdaging om uniformiteit te krijgen in de CI/CD pipeline vanuit een architectuurvisie, anders gaan de teams zelf een pipeline bouwen. Architectuur werd meer op de business functies geënt. Het was ook een uitdaging om goede coding guidelines te krijgen voor alle teams en een uniforme foutafhandeling. Hoe doe je input validatie op een veld, als een gebruiker iets verkeerd invoert. Welke informatie wil je teruggeven, zodat de gebruiker en developer weet wat niet goed gaat, zonder dat je informatie geeft waar een hacker misbruik van kan maken? Dat blijft een uitdaging.’

‘Zorg voor een open, lerende cultuur’

Mirna: ‘Hoe is het onderzoek ontvangen binnen de organisatie waar het onderzoek plaatsvond?’

Nico: ‘Positief. De CISO stond erachter, dat hielp. Maar het onderzoek maakte de mate van veiligheid van het product transparant en tastbaar. Daardoor zagen de teams dat ze moesten verbeteren. Het hielp ook dat de teams geholpen werden om problemen op te lossen door het securityteam, vanuit het People-Process-Technology Framework. We keken: is er opleiding nodig? Moeten de processen verbeterd worden. Is er de juiste tooling? Of is er iets anders aan de hand?’

‘Als je agile echt goed doet, is het risico mitigerend’, zegt Mirna. ‘Klopt’, zegt Nico. ‘Als je agile goed én consequent toepast,’ benadrukt Nico. ‘De kwaliteit van software gaat heel snel omhoog bij agile werken. Als er bij een release onveilige dingen uitkomen, kun je de Plan, Do, Check, Act Cycle echt goed doen. Als je iets snel ziet, kun je het snel oplossen. Fail fast, learn fast. Een open, lerende cultuur is belangrijk. Dat hebben we geprobeerd te creëren door met anonieme gegevens te werken. Fouten maken mag, leren van fouten moet. Het was leuk om te zien dat de Product Owners onderling ook veel meer met elkaar gingen samenwerken.’

Meer weten over het onderzoek ‘Agile Secure Development & Operations’ of het ASAMM-model? Neem contact op met Nico Kaag of Barry Derksen.