Dat development en operations bij de productie en uitgave van applicaties en/of software beter moeten samenwerken, is inmiddels algemeen bekend. En dat er behoefte aan DevOps is ook. Maar hoe zit het met de beveiliging? Een ondergesneeuwd kindje zo blijkt. Tijd voor verandering.
DevOps is langzamerhand gemeengoed voor veel bedrijven. Het is een methode die de samenwerking stimuleert tussen teams die applicaties maken en testen (development) en teams die de toepassingen onderhouden in productieomgevingen (operations). Dat is ook precies wat de DevOps-beweging wil: samenwerking verbeteren tussen de twee afdelingen om applicaties nog efficiënter te produceren en een snellere time-to-market te realiseren.
Verschillende belangen
Het traditionele beeld van development is dat deze afdeling graag zoveel mogelijk functionaliteiten binnen korte tijd in productie neemt. Dit in tegenstelling tot operations. Voor deze afdeling is stabiliteit belangrijker dan verandering. Veranderingen moeten beheersbaar en gecontroleerd doorgevoerd worden. Maar in een 24-uurs economie verandert alles voortdurend.
Wil een bedrijf onderscheidend kunnen blijven ten opzichte van de concurrentie, dan moet software snel aan te passen zijn. Ze moeten nieuwe functionaliteiten sneller produceren, zonder in te leveren op stabiliteit en beschikbaarheid. Een wekelijkse – of zelfs dagelijkse – oplevering van software is nu niet snel genoeg meer. Maar dat betekent dat de overdracht van software van development naar operations en naar de uiteindelijke productie, beter moet. En dat niet alleen. Ook op het gebied van beveiliging moeten bedrijven flinke stappen zetten.
Security
Voor development en operations is beveiliging echter een struikelblok; iets wat het proces onnodig vertraagt. Voorheen gebeurde de controle nadat een applicatie gebouwd werd en voordat het in productie ging. Maar bedrijven moeten beveiliging continu op meerdere plekken inzetten. Dat is van groot belang voor het succes van een onderneming, zeker nu het aantal cyberaanvallen toeneemt. Het is daarom essentieel om eerder in te grijpen en een mogelijk lek te ontdekken, in plaats van hier aan het einde van een proces op te controleren. Dan is het vaak te laat.
Het zou een misvatting zijn om te zeggen dat de afdeling Security niet in DevOps past. Het is juist een zegen voor security-specialisten, die met de juiste automatisering en operationele tools beveiliging eerder aan het ontwikkelproces kunnen toevoegen. Door betere monitoring, het delen van informatie en het uitvoeren van tests, kunnen zij immers problemen sneller opsporen en herstellen. Samenwerking tussen de verschillende afdelingen is hierbij cruciaal.
Samenwerking
Nog beter is het om afdelingen samen te voegen en iedereen vanaf het begin bij het proces te betrekken. Op die manier leren ze elkaars werk begrijpen en waarderen en kennen ze elkaars ergernissen. Een organisatie kan daardoor juist flexibiliteit garanderen en ervoor zorgen dat processen efficiënter verlopen. Bovendien biedt het mogelijkheden om samen andere strategieën te onderzoeken, wat de organisatie ten goede komt.
Zorg er als organisatie dus voor dat ontwikkeltrajecten een geheel vormen, waarbij ontwikkeling, uitvoering en beveiliging tegelijkertijd worden opgepakt. Dit bevordert niet alleen het teamwork, maar het creëert ook een gezamenlijk verantwoordelijkheidsgevoel. Bovendien helpt het om het proces rondom het uitgeven van nieuwe software of applicaties te verbeteren. Tot slot is het bevorderlijk voor het aantonen van compliance, het handhaven van de veiligheid en voor de operationele efficiëntie.
Marco,
In principe zit security ook in het concept van DevOps waar snelheid trouwens niet het doel is maar het resultaat van optimalisatie.
Marco,
Ik ben het eens met Ewout, security is onderdeel van de non-functional requirements en zit in het concept van DevOps. Als het al een ondergesneeuwd kindje is, dan vooral doordat de uitvoering niet goed is, niet door het concept.
Hulde! Ik ben het 100% eens met de inhoud van dit artikel. Ik wil graag nog iets toevoegen. Het bouwen van veilige software dient in onze optiek al te beginnen bij de opleiding van programmeurs. Vraag aan programmeurs hoeveel tijd er tijdens hun opleiding is besteed aan secure development en je krijgt niet meer te horen dan dat er een keer een gastcollege is geweest over “hacken”. We komen nog steeds software developers tegen die nog nooit van OWASP en/of SANS gehoord hebben. Secure development gaat echter een belangrijke rol spelen in de nabije toekomst. Er komt nieuwe wetgeving aan waarbij concrete maatregelen worden gevraagd om de security en privacy van data te waarborgen. Systemen zullen straks gebouwd moeten worden volgens het “Privacy by Design” principe, wat wil zeggen dat de privacy wet als het ware ingebouwd dient te zijn in de systemen. Datalekken zullen binnen 72 uur gerapporteerd moeten worden aan het CBP. Het “Secure by Design” ontwikkelen van software en het (regelmatig) laten scannen van de software op kwetsbaarheden is daarom van belang om boetes te voorkomen die van materiële aard zijn. Security testing dient zo vroeg mogelijk in het ontwikkelproces opgenomen te worden. Daar is trouwens ook een goede business case voor: Het repareren van security kwetsbaarheden in software die al in gebruik is kost 100x meer dan het oplossen van die problemen tijdens de ontwikkeling van de software!
Oeps.
“Voor development en operations is beveiliging echter een struikelblok; iets wat het proces onnodig vertraagt.”
Dat zinnetje illustreert precies wat er nog breed in ons vakgebied aan de hand is: IT’ers kijken vooral naar zichzelf, naar de IT, naar de technologie. Als ze eens wat meer begrepen van de klant dan zouden het wel uit hun hoofd halen om security als een struikelblok te betitelen.
DevOps is natuurlijk niets nieuws en het *proces* wordt er geenszins anders van, hooguit op werkinstructie-niveau verandert er iets omdat de technische uitwerking van werkzaamheden verandert. De samenwerking tussen ontwikkelaars en productie-mensen is van alle tijden: het huidige DevOps is niet meer of minder dan een hogere frequentie van die samenwerking, in kleinere stapjes. In die zin prima te vergelijken met Scrum.
De “afdeling” Security heeft nog steeds dezelfde taak als bij een organisatie waar de opeenvolging tussen ontwikkeling en productie een lagere frequentie heeft. Daar verandert in essentie niets. Het lijkt me voor Security zelfs moeilijker om die hogere frequentie te ondersteunen dan de lagere…
Het slotakkoord in het artikel slaat de spijker weer op de kop: samenwerking kan heel veel verbeteren. Processen blijven processen, maar de organisaties waarin je die processen uitvoert kunnen sterk variëren. De praktijk illustreert steeds vaker dat een organisatie die een teamverband structureert over verschillende taakgebieden heen grote voordelen biedt: juist door het gebrek aan communicatie ging er immers altijd veel mis: iedereen kent de problemen die volgen uit het “over de schutting gooien”. Of zoals Bart Stofberg het zo mooi weet te verwoorden: “touwmanagement is vaak veel beter dan ketenmanagement”.
Conclusie: dat security niet mag worden vergeten bij DevOps is een waarheid als een koe, maar het lijkt er toch een beetje op dat het een koe op leeftijd is die hier uit de sloot wordt gehaald. Wat in de IT voor veel oude koeien geldt, dat geldt echter ook hier: je kan het niet vaak genoeg zeggen. Goeie actie Marco!