DevOps en security: het recept voor een monogame relatie

Marco Rottigni, Chief Technical Security Officer EMEA, Qualys

Het is bijna twintig jaar geleden dat het originele manifest voor agile software-ontwikkeling werd gepubliceerd. Softwareontwikkelings- en IT-teams streven allemaal naar betere software om te voldoen aan de vraag en behoeften van klanten, wat ruwweg overeenkomt met de agile-principes. Toch doen zich nog steeds een hoop problemen voor rondom de processen en politiek van software. 

DevOps - waarbij teams samenwerken aan het sneller en efficiënter op de markt brengen van software - kan hier uitkomst bieden. Maar DevOps heeft IT-beveiligingsteams ook veel kopzorgen bezorgd als het gaat om het beheren van security en de verbonden risico’s. Hoe kunnen DevOps- en securityteams die hun aanpak willen verbeteren voorkomen dat ze vastlopen en zich in plaats daarvan voortaan aan juiste processen houden? 

Betere processen creëren binnen teams

Een van de grootste uitdagingen voor IT-beveiligingsteams is om vroeg genoeg in het ontwikkelingsproces betrokken te worden. Voor velen is security iets wat pas wordt toegepast wanneer de applicaties al gebouwd zijn en in productie gaan. Dit is een ouderwetse aanpak die overblijft uit de tijd van de Waterfallmethode en software achter sterke perimeterbeveiliging werd gehouden. 

Vandaag de dag bevat bijna elke software wel een vorm van cloud, API-integratie of code van derden. Het is nu makkelijk om softwarecomponenten te combineren om zo nieuwe diensten te creëren, in plaats van ze from scratch te ontwikkelen. Elk team dat probeert om zijn eigen cryptografie of security te implementeren in plaats van gebruik te maken van kant-en-klare producten zal namelijk in de loop van de tijd enorme problemen voor zichzelf creëren. Door best-in-class-diensten, opensource-componenten en interne code te combineren, worden sneller betere resultaten behaald. 

Toch doet zich een aantal kwesties voor met betrekking tot deze aanpak. De eerste is zichtbaarheid: met zo veel onderdelen die bij elke toepassing betrokken zijn, is het up-to-date en veilig houden van elke toepassing een oneindige Sisyfus-taak. Dat wordt nog lastiger wanneer bedrijven containers gebruiken om microservicetoepassingen uit te voeren. Containers kunnen bijvoorbeeld zo ontworpen worden dat ze bestaan zolang er vraag is naar de dienst - en uitgeschakeld en vernietigd zodra die vraag afneemt. Zolang de applicatie draait, zullen de componenten bestaan. Dat is precies het punt waarop ze kwetsbaar zijn. 

Containers worden opgehaald uit repositories die de images opslaan totdat ze nodig zijn. Deze images kunnen intern worden ontwikkeld of vanuit openbare bibliotheken worden gebruikt. Hoe dan ook, ze moeten worden bijgewerkt en up-to-date worden gehouden. Als dit niet regelmatig gebeurt, dan zal er een zogenaamde ‘nieuwe’ container gemaakt worden waarin zich al fouten bevinden.

Voor elke cloudtoepassing zou het verkrijgen van nauwkeurige informatie over wat er op elk moment draait een noodzakelijke stap moeten zijn. Deze data moet IT-securityteams inzicht geven in wat de risico’s van elke dienst zijn. Developers kunnen deze informatie gebruiken om grip te krijgen op hun applicatie-instances voor prestatiebesprekingen.

Het tweede gebied waar deze informatie van essentieel belang kan zijn, is bij het bepalen wie op welk moment voor welke assets verantwoordelijk is. Wanneer applicaties in de cloud draaien, bevinden ze zich op de infrastructuur van een ander bedrijf. Die organisatie kan alle voorzieningen bieden om de dienst te laten draaien of laat developers hun eigen instances opzetten en draaien bovenop de basis cloud-infrastructuur. 

Wanneer security betrokken raakt bij DevOps-teams - of dat nu is door middel van ad-hoc-samenwerking of meer formele DevSecOps-processen - is het van essentieel belang dat het niet wordt gezien als een verstoring van het softwareontwikkelingsproces. In plaats daarvan moet het worden ingebouwd in het bestaande codebouwproces door middel van directe plug-ins en integratie in de tools die developers dagelijks gebruiken voor hun Pipeline. Op die manier zien developers security als een positief effect op de efficiëntie van hun code, in plaats van dat het proces onderbreekt of blokkeert. 

Tegelijkertijd betekent het cloud shared responsibility-model dat developers en beveiligingsteams moeten samenwerken om te bepalen wie de assets up-to-date houdt. Het is niet belangrijk wie dit doet - het belangrijkste is dat het gebeurt. 

Vooruitplannen rondom samenwerking

In de toekomst zullen developers steeds meer verantwoordelijkheid dragen voor het gehele proces van het bouwen en draaien van software. Voor beveiligingsteams zou het eerder betrokken raken bij het proces moeten helpen bij de integratie van beveiligingstools zoals het scannen van softwarekwetsbaarheid of containerbeheer. Dit betekent niet dat je softwareteams precies moet vertellen wat ze moeten doen - maar het zou ze wel moeten helpen om hun prioriteiten te bepalen en om eventuele problemen op te sporen voordat de software in productie gaat. 

Het bieden van meer inzicht in potentiële beveiligingsproblemen in een vroeg stadium kan onder meer bestaan uit het scannen naar veelvoorkomende fouten en verouderde software in images tot en met het afdwingen van best practices in webapplicaties. Door eerder in het ontwikkelingsproces meer begeleiding te bieden bij het oplossen van problemen, kunnen deze worden opgelost voordat ze verderop in het proces terechtkomen. Op die manier draait het proces van fouten ontdekken ook meer om samenwerking en prioritering dan om discussies tussen verschillende teams met verschillende doelen. 

Voor beveiligingsteams die meer betrokken willen raken bij DevOps, kan het juist het tegenovergesteld effect hebben wanneer zij zich focussen op security an sich. Door developers meer inzicht te geven in hun eigen applicaties, kunnen ze er juist voor zorgen dat iedereen dezelfde doelen nastreeft. 

Door de focus te leggen op zichtbaarheid rond applicatiecomponenten, kan iedereen zien waar werk nodig is. Terwijl overlappend inzicht in verantwoordelijkheden en prioriteiten ervoor zorgt dat middelen op het juiste moment op de juiste locaties zijn. Dit advies over wat het belangrijkst is - wat voor elk bedrijf anders is, gebaseerd op zijn unieke IT-geschiedenis en technologische keuzes - betekent dat iedereen het juiste pad kan blijven volgen, in plaats van vast te lopen op de verkeerde projecten.