Valkuilen in DevSecOps
‘Security is een van de grootste uitdagingen in software development’, stelt Davide Cioccia, senior application security architect bij Veralto. Hij geeft enkele best practices mee. ‘Leer beveiliging aan ontwikkelaars en ontwikkeling aan beveiliging.’
Voor IT-vereniging SAI, een van de partners van Cybersec Europe, deelde Davide Cioccia onlangs zijn visie rond de aanpak van DevSecOps, wat staat voor development, security & operations. DevSecOps is een approach van cultuur, automatisering en platformontwerp die beveiliging integreert als gedeelde verantwoordelijkheid gedurende de gehele IT-levenscyclus, met development als belangrijk aspect. ‘Een van de meest vooraanstaande pitfalls daarbij is dat security geen deel uitmaakt van development’, stelt Davide Cioccia.
Bij veel organisaties heerst ook een slechte beveiligingscultuur. ‘Een uiting daarvan is bijvoorbeeld dat het management niet is betrokken bij discussies over security’, stelt Cioccia. ‘Ook het feit dat bijvoorbeeld het security department owner is van de security van het product is een teken aan de wand. Net als de verdeling van de workforce. Als er bijvoorbeeld 1 security persoon of expert is tegenover 1.000 developers. Dan zit die verhouding niet goed.’
Beveiliging is geen bijzaak
Een sterke security cultuur brengt om te beginnen al security experts binnen met een development background en laat ze samenwerken met het ontwikkelingsteam, stelt Cioccia, en hij wijst op ieders rol en focus. ‘De security mensen moeten de product tech en de business goed begrijpen. De ontwikkelteams zijn op hun beurt eigenaar van de beveiliging van hun producten. En het management spreekt regelmatig over security.’
Een andere valkuil is dat security iets is wat achteraf gebeurt, als soort van nasleep. ‘Implementeer beveiliging in verschillende fasen van de ontwikkelingscyclus’, raadt hij aan. ‘En leer beveiliging aan ontwikkelaars en ontwikkeling aan beveiliging.’
Sommige tools zoals SAST en SCA, of een combinatie van beide, kunnen teams zeker helpen. SAST (= static application security testing) analyseert voornamelijk bedrijfseigen code op potentiële veiligheidsrisico’s. SCA (= software composition analysis), aan de andere kant is het ontworpen om kwetsbaarheden in open-sourcecomponenten te identificeren, zodat organisaties deze kunnen herstellen vóór implementatie of levering. ‘Maar weet dat tools op zich niet de oplossing zijn. Die zit in jouw proces. Richt je daar zeker op.’
Betere beveiliging tijdens de ontwikkeling: 10 concrete adviezen
• Begin met een of twee tools (SAST en SCA) voor het scannen van uw pipelines op beveiligingsproblemen.
• Hanteer één volwassenheidsmodel en houd je daaraan.
• Integreer kwetsbaarheden in de tools van de ontwikkelaars (zoals Jira).
• Ontwikkelaars zijn verantwoordelijk voor het definiëren van hun pijplijnen.
• Forceer niet één beveiligingspijplijn voor iedereen.
• Betrek de beveiliging alleen bij veranderingen met een hoog risico.
• Voeg het beveiligingsteam niet toe als goedkeurder voor alle Pull Request en Merge Request.
• Gebruik een dreigingsmodel waarmee u een reeks dreigingen kunt categoriseren en identificeren.
• Identificeer mensen die geïnteresseerd zijn in beveiliging binnen uw (ontwikkel)team.
• Creëer een ‘Security Champions’-programma en curriculum voor training en continue verbetering.
Dit artikel verscheen eerder in het Engels in het Cybersec e-Magazine #4 (april 2024):
security is inderdaad “een van de grootste uitdagingen in software development”.
Saai, ingewikkeld, duur. Al eens een inthousiaste management presentatie gezien over beveiliging ?
Liever nog groen. Scoren met groen productie en DCs. De marketing afdeling knutselt wel wat in elkaar,
want is maar voor de buhne.
Mis een beetje de kosten van die mooi bedoelde 10 concrete adviezen.
Ook leuk dat alleen “mensen die geïnteresseerd zijn in beveiliging binnen uw (ontwikkel)team” geidentificeerd hoeven te worden.
Das trouwens nu ook al het geval : Niemand 😉
Dat scheelt ook weer een boel benodigde approvals bij die software wijziging requests wat time to market kan verkorten.
En zo hoort het.
Leer eerst informatiebeveiliging aan bestuurders want zowel SAST als SCA vergeten dat de meeste datalekken nog altijd buiten de applicatie plaats vinden en een ‘better practice’ is dan ook een classificatie van de data omdat de verantwoordelijkheden hierin niet bij de ontwikkelaars liggen. Natuurlijk zullen de kwetsbaarheden in de software zorgen voor een ongeautoriseerde toegang tot de processen want het is met de data als het overtypen van Engelse artikelen. De lezer is nog niet de schrijver als we kijken naar het rollenspel van autorisaties.
Een software architectuur die meerdere afzonderlijke gebruikersgroepen kan bedienen zorgt ervoor dat ik al een heleboel enthousiaste presentaties gezien heb over hoe het concept van RBAC in de code is verweven. Het ei van Columbus wat betreft de complexiteit van end-to-end scheiding van de tenants met zoiets als gedeelde resources begint tenslotte met het creëren van vertikale silo’s door de horizontale lagen van het OSI-model. Niet één pijplijn voor een ieder maar een pijplijn voor één ieder wat begint met de ‘praatplaat’ van een architectuur.
Het gemis van Dino over de kosten van de 10 adviezen gaat tenslotte om het risicomanagement want naast RBAC hebben we nog RASCI. Nog saaier dan beveiliging is de naleving van regels, ook bekend als compliance. Want een gedeelde verantwoordelijkheid in de cloud met exoneratieclausules in de gebruiksvoorwaarden gaat om het temmen van alle papieren tijgers. Want wat betreft het dreigingsmodel en de zwakste schakel hierin begint informatiebeveiliging bij zoiets als de stakeholders hierin met het MoSCoW principe om alle beveiligingsmaatregelen te categoriseren naar het moeten en willen.