Wat kunnen we leren van het datalek bij de GGD?

  • Giel Oerlemans
  • woensdag 3 februari 2021 om 14:23
Op dit moment is het groot in het nieuws: de privégegevens van miljoenen Nederlanders die aanwezig zijn in de coronasystemen van de GGD worden illegaal verhandeld. RTL Nieuws deed onderzoek naar de beveiliging van de systemen die gebruikt worden voor het registreren en organiseren van coronatesten, alsook voor het vastleggen van de uitslag en het doen van bron- en contactonderzoek. Daaruit bleek dat er een levendige handel gaande is in privégegevens, waarbij gegevens van specifieke personen op aanvraag worden verkocht, maar ook in grote hoeveelheden in bulk worden aangeboden.

Naast de omvang maakt ook het soort gelekte gegevens dit een zeer ernstig incident. Behalve algemene persoonlijke informatie behoren ook BSN nummers en medische gegevens tot de gelekte data. Daarmee wordt het risico op bijvoorbeeld identiteitsdiefstal zeer groot. 

illustratie data diefstal

De gegevens worden door malafide medewerkers met toegang tot het systeem doorverkocht aan criminelen tegen een vergoeding per persoon. Ze blijken afkomstig te zijn uit een tweetal systemen waartoe heel veel medewerkers en ingehuurde krachten toegang hebben. De praktijken zijn al maanden aan de gang en hoewel de GGD besloten heeft bepaalde functionaliteiten uit te schakelen, lijkt het einde nog niet in zicht. 

Het is dan ook van belang om lering te trekken uit het voorval bij de GGD, ook al weten we nog lang niet alles en is de onderste steen ongetwijfeld nog niet boven. Hoewel we bij StackSecure de nadruk leggen op de mens als belangrijke (of misschien wel de belangrijkste) schakel in de digitale security keten, is het datalek bij de GGD niet te voorkomen door enkel medewerkers bewust te maken van digitale dreigingen. De dreiging komt namelijk van binnenuit. Het lijkt lastig om jezelf als organisatie daartegen te wapenen. Er zijn echter legio mogelijkheden om jezelf te beschermen tegen een dergelijke inside job, op technisch gebied door middel van bijvoorbeeld data loss prevention oplossingen, maar ook op beleidsniveau.

Toegangsrechten beperken

De problemen ontstaan doordat er niet goed nagedacht is over de verschillende functies binnen een bedrijf en de rechten en functionaliteiten die in een systeem nodig zijn om de functies uit te kunnen voeren. In welke gegevens dient een callcenter medewerker inzage te hebben? Als het goed is, zijn dat enkel gegevens die relevant zijn voor het inplannen en vastleggen van een afspraak. Hetzelfde geldt uiteraard voor de personen die testen afnemen, of die bron- en contactonderzoek doen. Wat kunnen zij, per functie, inzien, aanpassen en uit het systeem exporteren. Dergelijke afwegingen zijn in ieder bedrijf, ongeacht de branche waarin zij opereren, te maken. In informatiebeveiliging is het van belang dat toegangsrechten zo strikt mogelijk worden belegd, volgens het principe van least-privilege.

Bijhouden en controleren van acties

Daarnaast is het, zeker als het gaat om gevoelige informatie, erg belangrijk bij te houden welke medewerker wat doet in een systeem. Er zou dan, al dan niet steekproefsgewijs, kunnen worden gecontroleerd of er geen onrechtmatige acties plaatsvinden. Ook kunnen eventuele (onopzettelijke) fouten worden gevonden en gecorrigeerd. Wanneer een medewerker gegevens opvraagt, die hij of zij helemaal niet hoort op te vragen, dan gaat er bij voorkeur een alarmbel af. Bijvoorbeeld wanneer eerder genoemde callcenter medewerker, verantwoordelijk voor het inplannen van afspraken, gegevens opvraagt van personen van wie de afspraak al heeft plaatsgevonden.

Werk systematisch en neem weloverwogen besluiten

Dergelijke maatregelen brengen uiteraard extra tijd, moeite en kosten met zich mee. Overigens zijn er veel verschillende gradaties van maatregelen. Ook van af en toe een steekproef kan voldoende preventieve werking uitgaan. Het is daarom zeer belangrijk kritisch te kijken naar de kosten van alle verschillende maatregelen, en deze af te wegen tegen nut, noodzaak en het risico dat wordt gelopen wanneer besloten wordt een maatregel niet door te voeren. 
Het gevaar om verzeild te raken in een eindeloze spiraal van maatregel op maatregel ligt op de loer wanneer de vraag “wanneer is het goed genoeg” niet kan worden beantwoord. Iedere organisatie zal hier zelf een antwoord op moeten proberen te vinden. Daarbij kan gebruik worden gemaakt van bekende systematiek en bestaande frameworks, mogelijk ondersteund door ervaren deskundigen.

Naast de vraag wanneer het “goed genoeg” is, is ook de vraag “zijn we compleet” erg relevant. Helemaal blind staren op het slot op de voordeur, terwijl de achterdeur al die tijd op een kier staat, zal uiteindelijk ook tot problemen leiden. Ook hiervoor kunnen frameworks, guidelines en best-practices uitkomst bieden. Een systematische aanpak leidt ertoe dat alle facetten worden belicht. Dat wil zeker niet zeggen dat ook op alle vlakken maatregelen nodig zijn. Wederom moeten kosten en baten worden afgewogen.

Evalueren en bijstellen

Tot slot geeft het voorbeeld van de GGD ook aan dat het belangrijk is om het informatiebeveiligingsbeleid, en de informatiebeveiliging zelf, regelmatig te evalueren en bij te stellen. De opkomst van de coronapandemie is natuurlijk vrij uitzonderlijk geweest, laten we hopen dat dit zich niet snel zal herhalen. De omstandigheden zijn daarmee dermate veranderd, dat een systeem dat, hoewel bekend was dat het kwetsbaarheden bevatte, op kleine schaal voldeed (of tenminste de risicoafweging doorstond), veel te kwetsbaar bleek voor gebruik op de schaal van de pandemie door nieuwe medewerkers die wellicht niet allemaal even goed gescreend konden worden. 

Staat u te popelen om het beveiligingsbeleid (nieuw) leven in te blazen en bent u benieuwd hoe StackSecure u daarbij kan ondersteunen? Neem dan zeker contact op. Met onze kennis van standaarden, frameworks en ondersteunende tooling kunt u een vliegende start maken en kunnen we uw bedrijf in verregaande mate ondersteunen.


StackSecure maakt gebruik van cookies.

Voor het correct functioneren, optimaliseren van deze website en t.b.v. commerciële doeleinden maakt StackSecure gebruik van cookies. Meer hierover kunt u lezen in ons privacy statement