Gezien de vermeende spanning tussen developers en security klinkt het te fantasierijk om de twee partijen samen te laten werken. Maar ‘shift-left’ kan een verschil maken, namelijk door de beveiliging van het einde van de levenscyclus van softwareontwikkeling te verplaatsen naar een eerder punt in het proces.
Door security-hulpmiddelen in te zetten als onderdeel van de developers-pijplijn, kunnen developers een einde maken aan hun nachtmerrie waarin ze proberen om security-issues pas aan het einde van een ontwikkelingsproces op te lossen.
Het potentieel voor verbeterd security-bewustzijn en -processen in devops is duidelijk als je bedenkt hoe fundamentele, maar ernstige tekortkomingen in cloudsecurity een probleem blijven. Het meest recente ‘Cloud Threat Report’ van Unit 42 onthulde slechte cybersecurity in cloudgebaseerde software en infrastructuur. Bijna driekwart van de cloudinstallaties die ze onderzochten, draaiden productietaken in Google Cloud met beheerdersrechten die niet veilig genoeg waren.
Devsecops is de term die de culturele verandering samenvat die moet plaatsvinden om een einde te maken aan deze en andere tekortkomingen. Met devsecops moeten teams die applicaties maken niet alleen weten hoe code wordt ontwikkeld en geïmplementeerd in de cloud en elders, maar ook hoe deze wordt beveiligd. Devsecops betekent security in alles integreren, zodat alle contactpunten gedurende de levenscyclus van softwareontwikkeling een beveiligingselement bevatten.
Het doel van devsecops is om zowel devops als security-processen veel efficiënter te maken en mogelijke problemen veel eerder op te sporen.
Communicatielijnen openen
Dus met dit in gedachten, wat zijn de noodzakelijke elementen voor succes? Een voor de hand liggende is hoe de barrières tussen developers en security-teams op een positieve manier zijn weg te nemen. Er zijn verschillende benaderingen, zoals het inbedden van een security-medewerker in een developers-team of het trainen van developers in best practices op het gebied van security.
Welke aanpak ook wordt gekozen, een cruciale stap is het overwinnen van communicatiebarrières. Een veel voorkomende misvatting is dat security alleen gaat over nee zeggen – op elk verzoek – om de risico’s zoveel mogelijk in te perken. Vanuit een security-perspectief is er nog een misvatting dat developers alleen waarde hechten aan het leveren van code, en dat security voor hen minder betekent. Geen van beide standpunten is fundamenteel waar.
Net als iedereen willen beveiligingsmensen het bedrijf zien slagen en coole dingen zien gebeuren. Developers geven daarnaast ook om meer dan alleen code; bovendien weten ze dat als er iets ergs gebeurt, er aanzienlijke implicaties zijn die ze willen vermijden.
Hoewel open communicatielijnen en wederzijds begrip essentieel zijn, is het net zo belangrijk dat devsecops-teams een toolset hebben die op dezelfde manier geïntegreerd is en in staat is om de veranderingen die in jouw organisatie plaatsvinden te volgen en aan te pakken. Of we het nu hebben over veranderingen in cloudproviders, de implementatiestack of iets anders, er is duidelijk behoefte aan een platform dat werkt waar je je ook bevindt: in de cloud of op locatie.
Het helpt dan dat benaderingen van cloud-native-ontwikkeling nieuwe manieren ontketenen om security te bieden. De technologie bestaat nu om op security-problemen te scannen vanaf het codescherm van de developer tot en met het automatisch scannen en beschermen van productieomgevingen. Bovendien is een basis van een goed beveiligingsbewustzijn en -zichtbaarheid de gebruikersentiteit en gedragsanalyses. Deze kunnen helpen om risico’s verder te minimaliseren.
Andere uitdagingen
Hoewel tools een essentieel element zijn om devsecops mogelijk te maken, zijn er nog andere uitdagingen die moeten worden opgelost. Deze omvatten de ‘onbekende onbekenden’ die organisaties tegenkomen wanneer ze hun digitale transformatie versnellen.
Misschien is de grootste moeilijkheid die organisaties tegenkomen wanneer ze proberen security in devops te betrekken, maar al te vaak dat iedereen het gemakkelijke antwoord wil. Met andere woorden: ‘voldoende beveiliging’, maar dat is nooit een goed idee.
Er moet hiervoor wat zwaar worden getild aan de manier waarop de security-mentaliteit van een organisatie duidelijk maakt dat iedereen werk zal moeten verzetten. Hier is geen makkelijke tussenweg.
Shift-left en devsecops cultiveren kost tijd. Investeren in tools waarmee developers en security-teams kunnen samenwerken, heeft een dubbele taak; en echt moeite doen om communicatiebarrières weg te nemen, de juiste cultuur te ontwikkelen en processen op te zetten die developers en security-professionals in staat stellen samen te werken voor een gemeenschappelijk doel.
Auteur: Ashley Ward, technical director, office of the cto bij Palo Alto Networks
Shiftleft, wat wordt daar nu mee bedoeld ?
Volgens mij staat de shift naar links voor een visuele horizontale tijdslijn dus eerder in de tijd.
Als dino heb ik daar wel oren naar.
Naar wat dan ? dat mag je zelf kiezen, wat goed uitkomt, testen ?
In dit geval security. Dus security al vroeg in het ontwikkelingsproces meenemen. Verschuif security van eind naar begin in het ontwikkelingsproces.
Merkwaardig om dit mee te laten nemen door een groep die steeds blijk geeft niet met security om te kunnen gaan, de ontwikkelaars.
Voor d’evers is sec en ops voor sufferds voor wie het creatieve ontwikkelaarsvak niet is weggelegd.
Culturele verandering aldus het artikel, want security blijkt toch essentieel. Wie had dat gedacht ?
En nu begint het nog maller te worden.
Waar in het ITIL tijdperk, de verantwoordelijkheden tijdens hele lifecycle van een product bij zoveel mogelijk verschillende groepen werd gelegd, die dan zo goedkoop mogelijk werden uitbesteed. Krijg je nu de zelfsturende teams met alle verantwoordelijkheden vanaf ontwikkeling tot het beheer in productie.
Ineens is wederzijds begrip een issue.
Door de business opgelegde paradigma’s die veranderen..
Het moet weer allemaal anders.
Wat blijft is het geklaag dat de uitvoerders, de devers, opsers, devopsers, devsecopsers niet te vinden zijn.
Dino,
Eén stapje naar links en twee stappen naar rechts want uiteindelijk gaat het niet om de security maar de compliance, meneer Palo Alto gaat volledig voorbij aan Europese wetgeving waar Security-by-design zo’n dingetje is waarbij je dus niet alleen nadenkt over de code maar vooral over de scheiding van informatie. Functiescheiding en SecDevOps lijkt me organisatorisch lastig in te vullen als je alles door één team laat doen zonder toezicht op de daadwerkelijke uitvoer.