Security by Design in low-code applicaties wat jij kunt leren van het GGD-fiasco

Softwareontwikkelaars hebben een belangrijke rol bij het veilig bouwen, opleveren en onderhouden van applicaties. Af en toe komt er een voorbeeld langs dat dat weer even pijnlijk duidelijk maakt. Ik doel natuurlijk op de ‘exportfunctie’ van de applicatie die bij de GGD het proces rond de coronatests ondersteunde. Hoe kon het zo misgaan? En hoe voorkom je dit soort datalekken in jouw low-code applicaties? 

Bijna alle medewerkers die het GGD-systeem gebruikten hadden toegang tot een functie die alle data uit het hele systeem exporteerde naar een bestand. Twee medewerkers gebruikten deze functie om de data door te verkopen aan criminelen, die daar ondertussen al fraude mee gepleegd hebben. 

Deel van je product 

Dit geval laat zien hoe groot de schade kan zijn. Er is natuurlijk directe financiële schade, maar de deuk in het vertrouwen is veel schadelijker en kan bijvoorbeeld zorgen dat minder mensen zich op corona laten testen en zo de kernmissie van de GGD schaden. Ook voor het vaccinatieprogramma kan dit gevolgen hebben. Ben je een commercieel bedrijf, dan is het nog duidelijker: minder vertrouwen betekent minder business. Een datalek kost je direct klanten en maakt het werven van nieuwe klanten moeilijker. Privacy en security zijn, kortom, al lang geen bijzaak meer. Ze zijn een essentieel onderdeel van je product geworden. 

Wat is Security by Design? 

Dit betekent dus ook dat je veiligheid en privacy vanaf het begin moet meenemen bij het bouwen van applicaties. Dat noemen we Security by Design en Privacy by Design. Het zijn manieren van denken en processen inrichten die zorgen dat je bij alles wat je doet de juiste vragen stelt. Security by Design heeft drie belangrijke onderdelen: prevent, detect en correct. 

Prevent 

Security begint al bij het productidee. Het GGD-voorbeeld illustreert perfect dat meer features altijd meer exposure opleveren en daarmee per definitie meer risico. Bij het uitdenken van een applicatie is het dus belangrijk om bij iedere feature te vragen: 

• Hebben we het echt nodig? 

• Wie heeft het nodig? Kunnen we gebruik beperken? 
• Moeten we bijhouden of, hoe vaak en door wie een feature gebruikt wordt? 

Door het verzamelen van data over het gebruik van features vind je functionaliteiten die weinig gebruikt worden en dus misschien uitgezet kunnen worden. Of misschien blijkt een feature in de praktijk alleen van belang voor bepaalde rollen of op bepaalde momenten. Zo kun je de risico’s beperken, zonder de gebruiker te hinderen. 

AVG-beslisboom 

De AVG-wetgeving geeft houvast bij het bepalen of we bepaalde data wel moeten of zelfs mogen opslaan. Je kunt van een developer niet verwachten dat hij de regelgeving van voor naar achter kent, maar je kunt wel vragen dat hij op het juiste moment contact opneemt met de Information Security Officer (ISO) en om advies vraagt. Security by Design zorgt dat dit standaard deel uitmaakt van het proces. We gebruiken intern bijvoorbeeld een AVG-beslisboom die vragen stelt als ‘waarom leg je dit vast?’ en ‘wie heeft er toegang?’ Maar je kunt ook op ‘boerenlogica’ vertrouwen en steeds de vraag stellen of je bepaalde data wel écht nodig hebt. 

Wel of geen BSN? 

Een praktijkvoorbeeld is het BSN. Dit is een heel handig stukje data om te hebben, omdat je zeker weet dat je hiermee een persoon kunt identificeren. Dat maakt het tegelijk ook voor criminelen heel waardevol. We willen dit dus alleen verwerken als het écht niet anders kan. En alle andere gevallen gaan we, ook al is het meer werk, op zoek naar een andere oplossing. Want wat je niet hebt, kun je ook niet kwijtraken. 

Detect 

Je kunt niet iedere security-issue vooraf voorzien en voorkomen. Het detecteren van bestaande problemen is dus net zo belangrijk als het voorkomen van nieuwe. Als we een applicatie bouwen of aanpassen, checken we die dus altijd nog een keer op potentiële problemen. Maar dit geldt ook in het gebruik van een applicatie. Je kunt het allemaal nog zo strak ontwerpen en bouwen, als beheerders te veel rechten openzetten is het nog steeds onveilig. Detectie betekent dus ook dat je geregeld kijkt wie welke rechten heeft en of dat wel nodig is. 

Correct 

De laatste stap is dat je ook echt optreedt als je een probleem vindt. Dat lijkt een open deur, maar het gebeurt veel te vaak dat bekende security- en privacy-issues lang blijven liggen. Ook bij de GGD was het lek al maanden bekend. Er werd pas actie ondernomen toen het al op het journaal geweest was. Hier moeten processen voor ingericht zijn en er moeten mensen klaarstaan om het te doen. 

Wachten tot er brand uitbreekt... 

En dat brengt ons automatisch bij de kwestie van de kosten. Want het inrichten van dit soort processen kost tijd en geld. Maar ieder probleem dat je niet veroorzaakt door vooraf goed over dataveiligheid na te denken, hoef je later niet op te lossen. Vergelijk het eens met een huis. Natuurlijk komt de brandweer, als je huis in brand staat. En natuurlijk doen die hun uiterste best om zo veel mogelijk van je bezittingen te redden. Maar het is altijd beter dat de brandweer helemaal nooit komt. Gek genoeg wordt bij security en privacy nog steeds vaak gewacht tot er brand uitbreekt. 

Duizenden inbrekers per dag 

Of kijk eens naar je applicatie als een professionele inbreker naar een huis kijkt. Die vraagt zich bij het verkennen van een mogelijk doelwit drie dingen af: wat is de buit, hoeveel moeite kost het om binnen te komen en wat is de kans dat ik gepakt word? Omdat de pakkans voor cybercriminelen nihil is, kun je alleen maar zorgen dat er zo min mogelijk te halen is en dat het zo moeilijk mogelijk is om binnen te komen. Een belangrijk verschil tussen inbraak en cybercrime is dat je digitaal niet aan een rustige, goedverlichte straat kunt gaan wonen. Je ‘voordeur’ is per definitie zichtbaar voor alle slechte mensen op de hele wereld. Er komen dus dagelijks letterlijk duizenden potentiële inbrekers langs, die allemaal eventjes aan je deurknop voelen om te kijken of ze misschien makkelijk binnen kunnen komen. We voeren dit gesprek altijd met onze opdrachtgevers en we merken gelukkig dat het steeds makkelijker wordt om ze ervan te overtuigen dat Security by Design een goede investering is. 

Security by Design in low-code 

Deze overwegingen spelen natuurlijk bij alle softwareprojecten, maar bij low-code moet je hier wat extra aandacht voor hebben. Low-code projecten worden vaak gebouwd door niet-technische citizen developers. Dit zijn vaak businessconsultants of businessanalisten, die heel goed op de hoogte zijn van de functionele kant van hun project. Het zijn ook mensen die optimaal profiteren van het gemak en de snelheid van low-code. Zij kunnen, zonder tussenkomst van IT of developmentteams, functionaliteit maken en aanpassen voor de eindgebruikers. Het risico is dat daarbij security niet altijd voldoende aandacht krijgt. 

Securityprocessen automatiseren 

Ik heb ooit meegemaakt dat een gebruiker functionaliteit had gebouwd om gebruikers hun eigen mailadres te laten wijzigen. Toen wij voor deze klant onze gebruikelijke pre-release security check deden, bleek dat daarbij iedere gebruiker ieder mailadres kon wijzigen. En als je een mailadres kunt wijzigen, kun je ook een nieuw wachtwoord aanvragen en met dat nieuwe wachtwoord kun je, als je kwaad wilt, veel schade doen. Doordat we altijd ook voor het wijzigen van een applicatie processen zijn vrij goed automatiseren en we hebben hier al voor verschillende klanten tooling voor gebouwd. Ben je ISO-gecertificeerd? Dan heb je sowieso maandelijks een overzicht nodig van wie waar bij kan. Dat kun je met een low-code app heel goed automatisch inrichten. Zo helpt low-code je om snel en flexibel te werken aan veilige software.