Bij het ontstaan van devops – we spreken meer dan tien jaar geleden – was het verbeteren van de samenwerking tussen development- en operations-teams het belangrijkste doel. Het automatiseren van processen bij het bouwen, testen en implementeren van applicaties speelden hierbij een belangrijke rol. Wat begon als een verzameling standaardprocedures, veranderde in een nieuwe engineeringcultuur en -proces: devops. Security had op dat moment zeker aandacht, maar niet altijd de prioriteit.
De opkomst van devops viel samen met twee andere grote verschuivingen: de overstap naar de cloud en de groeiende afhankelijkheid van opensource. Samen zorgen deze veranderingen voor de digitale transformatie, waardoor bedrijven sneller waarde kunnen leveren.
Deze veranderingen brengen ook uitdagingen met zich mee, waardoor het steeds moeilijker wordt om digitale assets te beveiligen. Omdat ontwikkelingsteams sneller en vaker resultaten leveren, is het voor security-teams moeilijker om bij te blijven. Security is in het ontwikkelproces vaak een vertragende factor. Dat is dan ook een belangrijke reden om security als een integraal onderdeel van het ontwikkelingsproces te zien. Devops verandert meer in een devsecops-cultuur.
Evolutie, geen revolutie
Devsecops is geen losstaand concept, maar een natuurlijke voortzetting van devops. Zie het eerder als een evolutionaire dan een revolutionaire stap. Dankzij een devsecops-cultuur kunnen ontwikkelingsteams beveiligen wat ze ontwikkelen terwijl ze aan het bouwen zijn. Tegelijkertijd werkt dit meer samenwerking tussen ontwikkelings- en security-teams in de hand. Security-teams hebben een belangrijke ondersteunende rol. Met hun expertise vergroten ze de autonomie van de ontwikkelaar en houden tegelijkertijd toezicht op de zakelijke behoeftes.
Praktische aspecten van implementatie
Een devsecops-cultuur realiseer je niet binnen een dag, maar een eerste stap in de goede richting is het signaleren van de behoefte in je organisatie. Een paar van de voordelen zijn:
- Snellere ontwikkeling door beveiliging te integreren in de ci/cd-pijplijn. Dit komt onder meer door geautomatiseerde standaardchecks die ook door ontwikkelaars kunnen worden uitgevoerd.
- Verbeterde beveiliging door een gedeelde verantwoordelijkheid en betrokkenheid vanaf de ontwerpfase. Security is geïntegreerd in het hele proces door het shared responsibility-model: van het bouwen en implementeren van code tot het beveiligen van productieworkloads. Teams werken samen om security-kennis te delen en tooling geeft snellere feedback.
- Kosten- en tijdsbesparing door kwetsbaarheden en bugs te identificeren voor en tijdens implementatie. Naast een vermindering van risico’s en operationele kosten, kost het minder tijd om software veilig te leveren, omdat het niet nodig is om achteraf beveiligingsmaatregelen te wijzigen.
- Betrouwbare oplevering door meer vertrouwen in de beveiliging van ontwikkelde software en het omarmen van nieuwe technologieën. Dit leidt tot meer omzet en een groter aanbod.
Gating
Bedrijven die het belang van de devsecops-cultuur in zien, moeten rekening houden met de volgende drie factoren: bedrijfscultuur, het proces en de technologie. Door deze factoren op de juiste manier te benaderen, worden silo’s afgebroken en een collectieve kracht gerealiseerd.
- Bevorder teamsamenwerking
Een moderne security-cultuur werkt vóór je team in plaats van tegen hen om succesvol te kunnen zijn. De overstap naar devsecops begint met het beter integreren van security-teams in de hele organisatie. Een sterkere samenwerking tussen dev-, ops- en sec-teams zorgt voor snellere feedback vanuit een security-perspectief over de kwaliteit van de code, software of applicatie. Daarnaast verlaagt het de kosten voor het implementeren van fouten die achteraf worden ontdekt.
Van oudsher was het ontwikkelingsteam verantwoordelijk voor snelle levering, security was verantwoordelijk voor applicatiebeveiliging en operationele teams waren verantwoordelijk voor stabiliteit. Devsecops verwijdert deze silo’s en verenigt alle drie de rollen in het gemeenschappelijke doel om snel veilige en stabiele software te leveren.
- Ondersteun de nieuwe devsecops-cultuur procesmatig
Het omarmen van een devsecops-cultuur vereist bedrijfsprocessen die een snelle adoptie realiseren. Dat betekent dat beleidsbarrières en -workflows die altijd in de weg zaten, moeten worden doorbroken. Moedig juist een gedeelde verantwoordelijkheid aan. Daarnaast is het van belang om de juiste balans te vinden tussen geautomatiseerde en handmatige gating.
Binnen traditionele security-strategieën worden belangrijke mijlpalen vastgesteld waarop security-activiteiten plaatsvinden. Het proces kon niet verder dan een mijlpaal tot een acceptabel resultaat was bereikt. In sommige organisaties implementeerden operationele teams vergelijkbare gates. Hierdoor ontstaan langdurige feedbackloops die de oplevering vertragen en silogericht denken versterken. Binnen devsecops is het creëren van snellere feedbackloops juist heel belangrijk.
Een gedeelde verantwoordelijkheid vervangt gating en moet worden ondersteund door procesveranderingen. Devsecops-teams moeten samenwerken om alle bedrijfsdoelstellingen te bereiken door middel van het creëren van snelle, veilige en stabiele software. Het in kaart brengen van bedreigingen, zwakke punten in de security en de maatregelen die bedreigingen kunnen verminderen is voor hen een belangrijke eerste stap. Processen waarmee security- en operationele best practices worden geïmplementeerd in het hele opleveringsproces zijn cruciaal bij het tot stand brengen van deze samenwerking en gedeelde verantwoordelijkheid.
- Gebruik de juiste technologie
Terwijl mensen en processen samenwerken om de acceptatie van de nieuwe devsecops-cultuur te waarborgen, kan deze uit elkaar vallen als de onderliggende technologie de veranderingen niet ondersteunt. Als mensen denken aan devsecops-technologieën, raken ze vaak verstrikt in de automatisering van leveringsprocessen zoals builds, promoties en implementaties. Maar automatisering is niet altijd het juiste antwoord. Bedrijven moeten eerst hun bestaande technologie onderzoeken en automatiseren waar dat nodig is, mogelijk is, en aansluit op de manier waarop er momenteel gewerkt wordt. Daarnaast is het belangrijk om technologie te elimineren waar het onpraktisch of overbodig is.
Holistisch
Bij het kiezen van een technologieplatform is het belangrijk om er een te kiezen waarbij de behoeften en vereisten van ontwikkelaars centraal staan in de oplossingen. Platforms met een developer-first-benadering zijn in staat om security in de hele pijplijn te integreren, waardoor meerdere verschillende belanghebbenden, zoals dev-, sec- en ops-teams, een holistisch beeld kunnen krijgen om samen te komen en een wederzijdse devsecops-mentaliteit te creëren.
Developer-first-benadering, “een holistisch beeld kunnen krijgen om samen te komen en een wederzijdse devsecops-mentaliteit te creëren.”
gaat het nog ergens over en zoja zouden ze het zelf geloven ? Ik werk zelf ook veel met developers. Ze moeten altijd meteen geholpen, anders halen ze hun sprint niet. Security kennen ze niet en boeit ook niet niet, daar is die cisosufkop voor, je weetwel die alles tegenhoudt. Hoeveel storage ? eeeh, kweenie, doe maar alles. Beheer is nooit in scope, is ook geen bal aan. Ja, lever nog maar een account, geef maar alle rechten anders doetie het misschien niet. “Wat is keybased login ? We willen juist veel dezelfde wachtwoorden die we makkelijk kunnen onthouden”. Waar die service accounts voor dienen die door hun hippe dev club was aangevraagd ? “Geen idee, die gasten zijn al lang vertrokken naar volgende klus en documentatie stond op backlog maar budget was ook op.”
“Ja sprint is af, alleen bugs eruit en iets met beveiliginggezeik, niet teveel testen anders levert dat nog meer werk, en eerst even die sexy features erin die tenminste zichtbaar zijn”. gaan ze allemaal klappen na de demo 😛
Ik zal niet proberen Dino te overtroeven maar de traditionele beheerteams zijn niet alleen verantwoordelijk voor de continuïteit van de IT dienstverlening maar ook voor de integriteit ervan. En het fundament van vertrouwen hierin gaat om de onafhankelijke controle want behoeften en vereisten van ontwikkelaars staan uiteindelijk niet centraal in de oplossingen. Het dualisme van een scheiding der machten heeft een functie want beveiliginggezeik gaat uiteindelijk om meer dan de code. En dat security (en privacy) in het ontwikkelproces hierdoor vaak een vertragende factor is lijkt me geen nieuws want het sorry achteraf staat dagelijks in de krant omdat een holistisch beeld aangaande de data nog altijd ontbreekt. Want je kunt geloven in klein beginnen en van daaruit werken tot iets werkt maar iedereen met kennis en kunde weet dat je daarmee een breiwerk aan complexiteit verkrijgt.