Developers zijn zich tegenwoordig bewuster van dataprivacy en -security

Digitale bureaus, verenigd in Dutch Digital Agencies, lossen voor opdrachtgevers in verschillende sectoren de meest uiteenlopende digitale uitdagingen op. Een no-nonsense-benadering van security is daarbij essentieel om de juiste dingen te blijven doen op dit gebied. Hoe zit het bijvoorbeeld met vulnerabilities in third party libraries? En lopen Nederlandse bedrijven echt meer gevaar door mogelijke cyberaanvallen uit Rusland?

IT’ers die werken bij een digital agency werken samen in teams die specialistische kennis combineren in uitdagende projecten voor klanten. Valentijn Scholten, Security Architect bij iO Campus Eindhoven, merkt hier dagelijks het effect van. “Wij hebben campussen in heel Europa, maar met name in Nederland en België. In Eindhoven zijn we goed in het integreren van security in de backend en api's.” Als het gaat om security is er nog veel missiewerk te verrichten, ziet Valentijn. “Ik zie op het gebied van awareness eigenlijk twee ontwikkelingen. In het verleden werd het gezien als sluitstuk; het is iets waar men eigenlijk liever niet in wil investeren. Zelfs al komen datalekken dagelijks in het nieuws, wordt de noodzaak om er zelf mee aan de slag te gaan niet gezien. Het is een uitdaging om deze mensen mee te krijgen.”

Valentijn ziet een nieuwe generatie developers die ook veel belang hechten aan security. “Vergelijk het met de aandacht die er is voor maatschappijbrede uitdagingen zoals klimaatverandering en dierenwelzijn. Security is een hot topic waar ze iets mee willen doen. Jongeren zijn kritisch over wat er met hun data gebeurt en ze zijn zich bewust van dataprivacy en databescherming. Ze willen werken bij een bedrijf dat dit goed op order heeft. Onder developers zie je dat bijvoorbeeld terug in de shift-left-beweging die al enkele jaren zichtbaar is en waar wij zelf ook vol op inzetten. Waar vroeger pas aan het einde van een ontwikkeltraject naar security en testen werd gekeken, definiëren we security-eisen tegenwoordig zo vroeg mogelijk. Het liefst maak je al van tevoren afspraken en test je tijdens het traject doorlopend de maatregelen.”

Log4J, Spring en Okta

Het bewustzijn rond security gaat bovendien verder dan alleen het product zelf. Veel dreigingen ontstaan door de afhankelijkheden van code elders in de keten, zoals in third party libraries. “Bij veel hacks en datalekken lijkt het inmiddels te draaien om supply chain-achtige zaken”, zegt Valentijn. “In de devops-wereld maken we veelvuldig gebruik van opensource-libraries en -frameworks waar veel vulnerabilities in zitten. Afgelopen maand zagen we dat nog bij het Spring-framework en in december bij Log4J.” Behalve infiltreren via vulnerabilities proberen hackers ook op andere manieren binnen te komen. “Neem bijvoorbeeld de recente hack op Okta, een grote single sign-on-provider waarbij aanvallers via social engineering accounts probeerden over te nemen. Dit zie je steeds vaker gebeuren en ook hier is de vraag: hoe wapen je jezelf ertegen?”

“Je kunt alles wel scannen, maar het risico bestaat dat je op een gegeven moment door de bomen het bos niet meer ziet”

Het is cruciaal om als bureau inzicht te creëren in de mogelijke kwetsbaarheden. “Daarom brengen we precies in kaart welke projecten we hebben en welke dependencies daarin zitten. Als er vervolgens een melding binnenkomt van een lek in een framework, weet je precies welke projecten je moet patchen. Daarbij kun je tevens gebruikmaken van tooling die helpt bij het bijhouden van library-lijsten en vulnerabilities.” Dat laatste is overigens iets dat weer andere problemen met zich mee kan brengen. “Zo kun je van alles scannen en checken: je framework, je webserver, libraries, AWS infrastructure as code-files en of je niet ergens secrets hebt gelekt. Het risico is dat je op een gegeven moment zo ontzettend veel scans hebt draaien en zo ontzettend veel rapporten en alerts krijgt, dat je door de bomen het bos niet meer ziet. Er zitten dan ook nog een hoop false positives tussen, iets dat sowieso een thema is binnen de wereld van security. Zeker momenteel, tegen de achtergrond van de aanval van Rusland op Oekraïne, proberen vendors je zoveel mogelijk security-producten te verkopen en vliegen de waarschuwingen je links en rechts om de oren. Een deel daarvan is bangmakerij en je moet de onzin er wel uit weten te filteren.”

JavaScript-injection en credential stuffing

Het is een belangrijke taak voor Valentijn om het kaf van het koren te scheiden en bezig te zijn met de juiste zaken. “Gelukkig heb ik mensen met een technische achtergrond in mijn team, die de juiste afwegingen kunnen maken. Het is leuk als je een beleidsstuk kunt schrijven of weet hoe een ISO-certificering werkt, maar uiteindelijk gaat het bij security ook gewoon om de basics. Denk daarbij aan zaken zoals JavaScript-injection, iets wat aanvallers toepassen als je voor je website kwetsbare plug-ins gebruikt, of credential stuffing, waarbij scriptkiddies met lijsten vol buitgemaakte wachtwoorden en gebruikersnamen proberen accounts over te nemen. Het zijn bekende dreigingen die je voor het grootste deel kunt voorkomen door je systemen up-to-date te houden. Daarnaast zien we bij het ontwikkelen van oplossingen dat training en codereviews goed werken. Dit zijn dan ook belangrijke onderdelen van onze sdlc (secure development life cycle, red). Codereviews kosten misschien tijd, maar leveren je veel op aan kwaliteit en security. Bij deze reviews kijken bovendien altijd minimaal twee developers naar een code. Dat levert veel kennisdeling op waarmee je elkaar helpt om beter te worden.”

Op het gebied van training doet iO Campus Eindhoven veel met het materiaal van Owasp, het Open Web Applications Security Project. “Dat is een community van security-specialisten die opensource en vendor-neutraal kennis promoten onder developers. Van hen gebruiken we onder meer trainingsmaterialen en checklists. Sowieso kan ik aanraden om Owasp’s top-10 van proactieve controles toe te passen bij softwaredevelopment; hiermee voorkom je veel kwetsbaarheden.” Valentijn is zelf ook moderator van de vulnerability-managementtool Owasp Defect Dojo. “Het is een soort JIRA voor vulnerabilities, waarmee je scanresultaten kunt analyseren, ontdubbelen en prioriteren, en taken toe kunt wijzen. Ik vind het geweldig om te doen, vooral omdat het vroeger een soort droom van mij was om zelf aan een bugtracker mee te kunnen schrijven.”

Enthousiast over security?

“Alles wat we doen, is maatwerk. Dat levert uitdagingen op waar je ontzettend veel van leert”

“Alles wat we doen, is maatwerk. Dat levert uitdagingen op waar je ontzettend veel van leert”, stelt Valentijn. Als bureau is iO aangesloten bij Dutch Digital Agencies, de organisatie die de beste digitale bureaus van Nederland bij elkaar brengt en verenigt. Wat het werken voor een bureau extra leuk maakt, is volgens Valentijn de variatie in opdrachten. “Omdat we zelf geen standaard producten verkopen, is alles wat we voor een klant doen maatwerk. Daarnaast werk je altijd aan vraagstukken waar je opdrachtgever zelf geen antwoord kan geven. Het levert uitdagingen op waar je veel van leert en waarbij er vaak ruimte is om te experimenteren.” Voor developers die ‘meer met security willen doen’ heeft Valentijn een advies. “Veel mensen deinzen terug omdat ze denken dat security ontzettend complex is. Het belangrijkste is dat je het werk en de uitdagingen leuk vindt. Daarnaast hoef je niet alles alleen te doen. We werken bij iO met ‘security champions’ binnen de verschillende teams en campussen. Dat zijn mensen in uiteenlopende functies die enthousiast zijn over security en elkaar met van alles helpen: van het actief uitdragen van het onderwerp tot het signaleren van issues en het invoeren van nieuwe maatregelen. Die eigenschap, dat enthousiasme, heb je echt nodig om security op een zorgvuldige manier op de kaart te zetten en er te houden. Daar begint en eindigt alles mee.”

Benieuwd geworden naar werken bij een digitaal bureau en wil je graag weten of er vacatures openstaan die passen bij jouw profiel? Check het hier.

Edit 03-05-2022: titel aangepast, en tweede en derde alinea.

Dit artikel is geen redactioneel artikel, maar een advertorial en tot stand gekomen dankzij Dutch Digital Agencies en Tweakers Partners. Dit is de afdeling binnen Tweakers die verantwoordelijk is voor commerciële samenwerkingen, winacties en Tweakers-events zoals Meet-ups, Developers Summit, Testfest en meer. Kijk hier voor een overzicht van alle acties en events. Mocht je ideeën met ons willen delen over deze vorm van adverteren, dan horen wij dat graag. Hierover kun je met ons in gesprek via [Discussie] Reclame algemeen].

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Reacties (18)

Mijn hemel, voor zo'n club wil je toch niet werken?
Vooringenomen over 'oudere' developers.....
Onze oudste devs (gaan helaas binnenkort met pensioen) weten heel goed hoe security werkt, of Fortran, of Pascal.....en zijn dus in staat om zo'n oude lib ff te recoden in iets moderns.

'Jonge' devs (whatever that may be) hebben nogal eens de neiging om gewoon een random library te pakken voor een kleine functionaliteit, met alle bijkomende vulnerabilities, i.p.v. gewoon even een algorithme te implementeren op basis van een publicatie, maar dan zonder alle toeters en bellen er omheen die je óók weer moet doorgronden.
Kijk eens naar de dependencies van een willekeurig JS, Python of c# project?

Is dependency gebruik ook niet gewoon het resultaat van hoe gemakkelijk dit is gemaakt? Los van de bezwaren gezien.

Ben zelf een frontend developer, en de node_modules map is soms wel enkele honderden mb’s groot ja. Maargoed, tradeoff is alles zelf schrijven, wat weer de kosten van het project laat oplopen omdat je langer bezig bent met schrijven, testen én documenteren.

Volgens mij is het een kwestie van de juiste balans er in vinden en bewust zijn van de nadelen. En de juiste vulnerability check tools gebruiken.

[Reactie gewijzigd door JorzoR op 3 mei 2022 09:46]

Er zit een verschil tussen een library gebruiken omdat het functionaliteit is die je niet zomaar kan namaken (bijv. Moment.js, die enorm veel logica heeft voor afwijkende tijdzones e.d.) en gewoon voor alles een library binnen trekken.

Het probleem begint wanneer de jongere developers (waar dit artikel over gaat) niet meer de logica die in die libraries zit herkent, maar alleen weet welke library ze nodig hebben. Ze hebben gewoon niet de kennis om het zelf te schrijven, zelfs al hadden ze de tijd ervoor.

Als er dan dus een library een flinke fout bevat dan kunnen ze die ook zelf niet afvangen. Kost uiteindelijk veel meer geld als je een mooie boete van de AP krijgt omdat je allemaal gegevens lekt dan als je zelf wat meer code schrijft.

Er is niet echt een balans meer. Er is maar 1 manier om te developen in een geld-gedreven omgeving en dat is door gebruik van libraries en frameworks. Deadlines, verwachtingen en onderhoud zijn er compleet op ingesteld dat dit het gekozen pad is.

Dus het is niet "gaan we een web framework gebruiken" maar "WELK web framework gaan we gebruiken". Ondanks dat je simpelweg met enkel Typescript ook gewoon prima en comfortabel een webapp kunt bouwen als je niet bang bent voor boilerplate. Niemand zal er een seconde bij stil staan, Angular, Vue, React, Svelte, etc. etc. bestaan dus ga je die gebruiken. .NET framework bestaat dus dat ga je gebruiken. Spring Boot bestaat dus je gaat dat gebruiken.

Dus het is niet "gaan we een web framework gebruiken" maar "WELK web framework gaan we gebruiken".

Ik heb zelf 0 ervaring met een werkomgeving waar er maar vanuit wordt gegaan dat er een framework gebruikt wordt. Uiteindelijk is dat gewoon sterk afhankelijk voor het soort website dat gemaakt moet worden. Dus ik herken dat niet echt.

Ondanks dat je simpelweg met enkel Typescript ook gewoon prima en comfortabel een webapp kunt bouwen als je niet bang bent voor boilerplate. Niemand zal er een seconde bij stil staan, Angular, Vue, React, Svelte, etc. etc. bestaan dus ga je die gebruiken. .NET framework bestaat dus dat ga je gebruiken. Spring Boot bestaat dus je gaat dat gebruiken.

Dat ligt er maar net aan wát er gebouwd moet worden, toch? Niet iedere website heeft inderdaad een framework nodig. Net zoals voor complexe websites/apps een framework toch écht wel handig is als je de features ook echt gaat inzetten.

[Reactie gewijzigd door JorzoR op 3 mei 2022 16:42]

wtf... dus oude developers klooien maar wat aan wat betreft de security?

Ik ben al wat ouder in developers termen, maar juist ik ben degene die continu met security bezig is, de jonkies intereresseert het totaal niet, ze hebben er op school niets van meegekregen en door mijn jarenlange ervaring zie ik juist eerder dat er iets mis is, en ook veel vlotter hoe het op te lossen is.

Dat 'oude developer shaming' moet maar eens afgelopen zijn. De echte oudjes doen nog Cobol, maar de iets minder ouden doen het juist beter dan de broekies. Dat is niet alleen mijn ervaring maar ook die van mijn collega's. Door dit soort berichten komen oudere developers steeds lastiger aan het werk.

Data verdienen ze meer aan, dus dit is een onzinnig advertentie, wat is het doel?

[Reactie gewijzigd door AntiSpam op 3 mei 2022 09:02]

Ik als semi broekie kan jouw verhaal beamen. De bewustwoording van hoe belangrijk security is komt bij mij vooral van ervaren developers uit het bedrijfsleven.

Ervaring is belangrijk maar uiteindelijk wil je als developer, los van hoeveel ervaring je hebt, iets goeds neerzetten waarbij data van het bedrijf en de gebruikers veilig zijn. Als je daar niks om geeft of er is geen budget voor dan heeft dat weinig met ervaring en leeftijd te maken.

Maar oude developers hebben allemaal dingen op hun CV staan die de recruiter niet kent, in plaats van alleen Laravel en Vue/Angular/React (ben helaas niet zo bekend met de equivalenten daarvan buiten web development), en daarvan raakt de recruiter in de war

Ik vind het ook raar dat er gedaan wordt alsof iemand die nu vers van school komt relevant zou zijn voor een positie waar security belangrijk is, want menig junior die net een (zelfs universitaire) opleiding af heeft heb je op dat vlak nog helemaal niks aan

Zulke recruiters laat je toch gewoon links liggen? Als een recruiter mijn CV niet snapt, dan heb ik niets aan die recruiter. Net zo min als van die HR bobo's die allemaal eisen stellen die nergens op slaan.

Komt ook door de perceptie, denk ik.
Als ervaren developer hou je meestal al bij het initieel programmeren er rekening mee, zonder dit expliciet te benoemen (en naast security ook performance en leesbaarheid, etc). Anderen zien een "oude developer" meer tijd nemen om een feature te implementeren en denken "die is oud en langzaam".

De titel vind ik toch wel een beetje beledigend.

Het zijn (zoals @elhopo al aangeeft) vooral de seniors die zich bewust zijn van security. Ik vind het zelfs verontrustend hoe weinig 'de nieuwe generatie' van security weet omdat ze er vanuit gaan dat hun hippe framework het allemaal op orde heeft. Wij hebben 'vroeger' nog geleerd hoe je zelf mogelijke security issues afhandelt. Die kennis wordt steeds meer verschoven naar de generatie die nu aan de top zit, en echt niet de jongeren die nu de markt op komen.

[Reactie gewijzigd door Oon op 3 mei 2022 09:47]

Als bureau is iO aangesloten bij Dutch Digital Agencies, de organisatie die de beste digitale bureaus van Nederland bij elkaar brengt en verenigt.

DDA is een leuke inclusieve club. Je moet omzet van minstens 1 miljoen hebben. En de andere leden mogen bepalen of je bij de club mag. Verder niets over de kwaliteit...

Heb eerder het idee, dat dit gewoon een bedrijven promoot platform is

[Reactie gewijzigd door wica op 3 mei 2022 15:13]

Wanneer je niet meer jong bent, ben je volgens Dutch Digital Agencies dus ongeschikt om met security kwesties te kunnen werken.

Okay, weer wat geleerd zo.

[Reactie gewijzigd door Hatsieflatsie op 3 mei 2022 09:25]

Gelukkig zitten de 'oudere' devs vaak in de beslis boom als het gaat om het aantrekken van extra handjes. Weet je gelijk welke club zich nu in de voet geschoten heeft.

Ik mag hopen dat de banner boven dit artikel niet is geleverd door de sponsor

-

[Reactie gewijzigd door CodeCaster op 3 mei 2022 23:37]

Issue zit toch voornamelijk in JavaScript libaries. Iedereen installeert maar random npm packages, geschreven door (Java)script kiddies. Ook wordt de regel om de cliënt nooit te vertrouwen veel te vaak genegeerd.