Cyberveiligheid (5): Schuif als security specialist vaker aan bij softwareontwikkelaars

Op deze pagina staat ook informatie speciaal voor leden. Log in voor toegang of vraag een account aan.

De ontwikkeling van webapplicaties gaat steeds sneller en is een continu proces van bouwen, lanceren en verbeteren. Volgens Jeroen Prinse, Security Architect bij Aegon, wordt security vaak te laat betrokken bij het ontwikkelingsproces, met frustratie en veiligheidsrisico’s tot gevolg. In dit interview deelt hij zijn ervaring met shift security left voor een betere samenwerking en betere bescherming van klantdata.

In een serie interviews over cyberveiligheid gaat het Verbond van Verzekeraars in gesprek met experts uit de (financiële) sector. Welke vormen van cyberaanvallen vormen de grootste risico’s en hoe wapenen verzekeraars zich hier tegen? In dit laatste interview van deze serie deelt Jeroen Prinse zijn ervaring met shift security left. Samen met zijn collega’s bouwt hij security-gereedschap die de softwareontwikkelaars van Aegon gebruiken voor veilige applicaties en portals voor de klant en het intermediair.

Wat is shift security left?

“Laat ik beginnen bij de zes fases van de Software Development Life Cycle. Dat zijn: analysis, design, development, testing, deployment en maintenance. Bij veel bedrijven wordt laat in het ontwikkelingsproces aandacht besteed aan security. Bijvoorbeeld in de test- of deployment-fase, oftewel vlak voor lancering. Grote kans dat security specialisten dan nog veel op- en aanmerkingen hebben over de veiligheid, wat vaak leidt tot tijdnood en wrijving tussen verschillende afdelingen. Het is dan ook niet gek dat security puts the no in innovation een veelgebruikte uitspraak is in ons werk. Shift security left is een aanpak waarbij security eerder in het ontwikkelingsproces aan bod komt met als doel om efficiënter te werken én veiligere applicaties te bouwen.”

“Ook bij ons ontplofte er soms een bommetje vlak voor de lancering van een applicatie”

En sinds wanneer wordt deze aanpak toegepast bij Aegon?

“We zijn er zo’n 2,5 jaar geleden mee gestart. Want ja, ook bij ons ontplofte er soms een bommetje als vlak voor de lancering bleek dat een nieuwe applicatie niet veilig genoeg was. We moesten dan compromissen sluiten over welke problemen direct opgelost moesten worden. Dat waren meestal problemen in de categorie ‘high’. ‘Medium’ en ‘low’ belandden op de to-do-list na lancering, maar daardoor bleven we achter de feiten aanlopen. Te laat aanhaken van security specialisten is trouwens niet alleen vervelend voor security- en development-teams, maar ook voor andere afdelingen zoals marketing. Zij communiceren over nieuwe of verbeterde applicaties. Kortom; het moest anders.”

Dat lijkt me heel vervelend. Hoe hebben jullie het aangepakt?

“Dat was zeker vervelend, maar ik denk dat dit nog steeds aan de orde van de dag is bij veel security-afdelingen. Als je er als security specialist van uitgaat dat softwareontwikkelaars uit de voeten kunnen met 120 pagina’s security-beleid, heb je het mis. Je moet weten hoe software development werkt en je collega’s kant-en-klare oplossingen aanreiken. Mijn collega’s en ik hebben in de afgelopen tijd tools voor testen geïmplementeerd die ontwikkelaars zelfstandig kunnen gebruiken in hun werk. Worden er foutjes opgespoord? Dan kunnen ze bij ons terecht voor hulp, waarna ze snel verder kunnen bouwen.”

Wat voor tools zijn dat?

“Wij hebben bijvoorbeeld tools geïmplementeerd die broncodes controleren op fouten. Dit wordt ook wel static application security testing genoemd. Ook bieden wij een tool aan om nieuwe versies van websites te testen op kwetsbaarheden. Dat is een vorm van dynamic application security testing.”

Aan welke kwetsbaarheden moet ik dan denken?

“Dat zijn er heel veel, maar de belangrijkste zijn Remote Code Execution (RCE) en SQL Injection. RCE is een aanval waarbij criminelen misbruik maken van een kwetsbaarheid in een webapplicatie en hierdoor in staat zijn om via een netwerk zoals het internet kwaadaardige codes uit te voeren op een server. Hierdoor kunnen ze vaak volledige toegang krijgen tot een server. Wannacry en NotPetya, twee wormen die bij veel bedrijven bestanden gijzelde met ransomware, maakten onder andere gebruik van RCE. De andere belangrijke kwetsbaarheid is SQL Injection, een aanval waarbij criminelen webformulieren bestoken met input zoals gekke tekens. Net zolang totdat ze een opening vinden waarmee ze data, zoals klantgegevens of gebruikersnamen en wachtwoorden kunnen stelen. Om dit te voorkomen moeten alle invulvelden gevalideerd worden. Bij het invulveld ‘naam’ verwachten wij dus alleen letters en geen cijfers. En bij de optie ‘uploaden foto’ verwachten wij een jpg- of png-bestand. Als je dit niet goed dichttimmert, krijgen hackers mogelijk toegang tot data en servers.”

“Zichtbaar zijn is belangrijk om 'shift security left' te laten slagen”

En hoe weet je welke tools ontwikkelaars nodig hebben?

“De security officers van Aegon, waaronder ik zelf, sluiten zich zo vaak als het kan aan bij diegenen die software ontwikkelen. We zijn aanwezig bij hun rituelen zoals stand ups en kwartaalplanningen en luisteren naar hun plannen, stellen vragen en geven advies. Zichtbaar zijn en meedoen is belangrijk om shift security left te laten slagen.”

Hoe heeft dat jouw werk veranderd?

“Mijn collega’s en ik zijn nu niet meer de boemannen die op het laatste moment zeggen: sorry, maar deze applicatie is niet veilig genoeg. Een bijkomend voordeel is dat we zo ook kosten besparen op de inzet van externe partijen voor uitgebreide testen vlak voor de lancering, want veel fouten zijn al eerder in het ontwikkelingsproces opgelost. Door mee te denken in alle fases van de Software Development Life Cycle heb ik het gevoel dat ik meer waarde toevoeg en bijdraag aan veiligere applicaties voor onze klanten.”


Was dit artikel nuttig?