Het zal de meeste mensen niet ontkomen zijn: op 12 februari heeft er een grote cyberaanval plaatsgevonden op Telecomprovider Odido, waarbij er persoonsgegevens van ongeveer 6,5 miljoen personen verloren zijn gegaan (naar onderzoek van de NOS).
Hoe vervelend ook, datalekken zijn tegenwoordig steeds vaker de orde van de dag. Het is dan ook goed om stil te staan bij de mogelijke implicaties van zulke datalekken en welke risico’s dit oplevert. Er is al veel geschreven over mogelijke nepberichten (phishing) waar gedupeerden alert op moeten zijn. Daarnaast is er aandacht nodig voor de veiligheid van bepaalde betrokkenen, nu ook afgeschermde adressen zijn gepubliceerd.
Een onderwerp dat niet veel besproken is, zijn de risico’s ten aanzien van verificatietechnieken. Veel organisaties gebruiken “verificatievragen” om te weten of ze met de juiste persoon te maken hebben. Zoals “Wat is uw geboortedatum”, of “Wat is uw BSN?”. Daargelaten of het BSN hier geschikt voor is (daar zijn strenge regels voor), is het zaak om alert te zijn als organisatie of je verificatietechniek gecompromitteerd is.
In dit blog ga ik dieper in op de vraag welke risico’s zulke datalekken met zich meebrengen ten aanzien van verificatie, welke rol de Algemene verordening gegevensbescherming (AVG) heeft en welke alternatieve verificatiemethodes er zijn voor jouw organisatie om je goed te beschermen tegen mogelijke inbreuken.
Let wel: dit blog gaat over verificatiemethoden die plaatsvinden buiten digitale klantomgevingen.
Afkadering van het begrip verificatie
Om goed te begrijpen waar de risico’s liggen rondom verificatie, is het belangrijk om op de hoogte te zijn van het onderscheid tussen enkele begrippen die vaak in de praktijk door elkaar worden gebruikt. Het gaat in dit blog om de volgende begrippen:
-
Identificatie: de claim van identiteit ("Hallo, ik ben gebruiker X").
-
Authenticatie (bewijzen): het bewijzen van de identiteit met middelen (wachtwoord, 2FA-code, vingerafdruk).
-
Verificatie (controleren): het proces waarbij het systeem controleert of de verstrekte bewijzen overeenkomen met de opgeslagen gegevens, vaak om zekerheid te krijgen dat de gebruiker is wie hij zegt te zijn.
-
Autorisatie (toestemming): bepaalt tot welke data of functionaliteiten de geverifieerde gebruiker toegang heeft.
Risico’s
Bij sommige datalekken worden gegevens op een gegeven moment publiek beschikbaar. Gegevens zijn bij hackers erg waardevol, onder meer omdat gegevens ze mogelijk toegang kunnen bieden tot omgevingen waartoe zij niet gerechtigd zijn. Dat kan bijvoorbeeld als volgt gaan: een hacker die de naam, adres, woonplaats of BSN heeft verzameld, doet zich via de telefoon of een chatbox voor als iemand anders. Medewerkers van een organisatie waartoe de hacker toegang probeert te krijgen, vragen dan bij wijze van verificatie naar de geboortedatum, adres, woonplaats en/of de laatste vier cijfers van iemands BSN. Wanneer de hacker deze gegevens keurig voorleest, is het moeilijk voor de medewerker om onderscheid te maken tussen de hacker of de daadwerkelijke persoon waar het om draait.
Een dergelijk verificatiesysteem heet ‘Knowledge based authentication’ (hierna: KBA). Alhoewel KBA voorheen een handig systeem kon zijn, vormt deze verificatiemethode met de komst van het internet een groot risico. Het is namelijk niet de bedoeling dat je voor je verificatiemethode gebruik maakt van publiek beschikbare informatie. Ook niet van niet-openbare gegevens die na een groot incident, zoals een datalek, opeens gemakkelijk publiekelijk beschikbaar worden.
Het is daarom verstandig om, mocht je nog gebruik maken van KBA, een beter alternatief te hanteren.
AVG – juridisch kader
Het is belangrijk om stil te staan bij de verplichtingen die voortvloeien uit de AVG met betrekking tot de beveiliging van persoonsgegevens. Op grond van artikel 5 lid 1 sub f AVG, moeten persoonsgegevens worden verwerkt op dusdanige manier dat een passende beveiliging is gewaarborgd. Dit moet gebeuren door het nemen van passende technische of organisatorische maatregelen (artikel 32 AVG).
Buiten het feit dat een datalek grote gevolgen kan hebben voor betrokken personen, kan het ook een boete tot gevolg hebben, als niet is voldaan aan de vereisten voor beveiliging. Dit onderstreept het belang dat jouw organisatie passende verificatiemethoden hanteert.
Alternatief: Multi-factor authentication (MFA)
Het feit dat veel informatie publiek beschikbaar is, onder meer via regelmatige incidenten, betekent dat we goed moeten nadenken over de manier waarop organisaties omgaan met verificatie. In een tijdperk van grootschalige datalekken is kennis eigenlijk geen geheim meer. Wij raden organisaties aan om altijd te werken met MFA.
MFA houdt in principe in dat een gebruiker zich identificeert met minimaal twee verschillende factoren. Factoren die we gebruiken als bewijslast kunnen we onderscheiden in drie verschillende dimensies, te weten:
-
Iets wat je weet (kennisfactor)
-
Iets wat je hebt (bezitsfactor)
-
Iets wat je bent (inherente factor)
Hieronder volgt een gedetailleerde toelichting van de gevraagde dimensies.
Kennisfactor
Wanneer je binnen het verificatieproces iets moet aangeven, om te bewijzen dat jij de persoon bent op basis van iets wat alleen jíj hoort te weten, spreken we over een kennisfactor. Dit kan bijvoorbeeld een wachtwoord of BSN zijn. Binnen deze dimensie gebruiken organisaties verficatievragen, waarin een onderscheid is tussen twee soorten: statisch en dynamisch.
Statische verificatievragen zijn gebaseerd op gegevens die vast staan en niet veranderen: geboortedatum of -plaats, wachtwoord, of paspoortnummer. Het probleem met deze methode is dat gevraagde informatie publiek bekend kan zijn of bij datalekken publiek kunnen worden.
Dynamische verificatievragen zijn, in tegenstelling tot statische verificatievragen, vragen die context- of tijdgebonden zijn en dus niet vastliggen. Een voorbeeld hiervan is te vragen naar het betalingskenmerk van een recente transactie. Dynamische verificatievragen zijn, in tegenstelling tot statische verificatievragen, ideaal wanneer personen telefonisch toegang willen tot gegevens en geen toegang hebben tot een digitale omgeving of app.
Bezitsfactor
Omvat het verificatieproces het bewijzen van een identiteit door middel van iets wat iemand bezit? Dan spreken we over een bezitsfactor. Denk bijvoorbeeld aan SIM-kaart of telefoon, die de mogelijkheid bieden om de eigenaar een SMS of notificatie te sturen via een authenticator-app, die een eenmalig wachtwoord weergeeft.
Inherente factor
Er is sprake van een inherente factor, wanneer iemand zijn of haar identiteit bewijst aan de hand van unieke biologische karakteristieken, zoals een vingerafdruk of iris-scan. Het gebruik van dergelijke gegevens voor beveiliging kan in Nederland onder strenge voorwaarden. Dat is alleen toegestaan als de situatie een dergelijk zware beveiliging nodig heeft, dat het niet anders kan dan de beveiliging op deze manier in te richten. Denk hierbij aan de toegang voor een kerncentrale.
Je verificatietechniek in de PDCA-cyclus
Goed beleid is constant onderhevig aan een Plan-Do-Check-Act-Cylus. Dat komt neer op dat het constant wordt herzien. Dit geldt ook voor verificatietechnieken. Zorg ervoor dat je deze herziet, zeker als het afhankelijk is van gegevens die mogelijk publiek beschikbaar zijn, of zijn geworden door een incident.
Neem het volgende mee bij het instellen of herzien van je verificatietechniek:
-
Ontwerp verificatie alsof persoonsgegevens openbaar zijn. Ga er altijd vanuit dat gegevens zoals naam, adres en geboortedatum al bekend kunnen zijn bij een aanvaller. Berust niet enkel op persoonsgegevens bij het verifiëren van de identiteit van personen, en hanteer altijd meerdere verificatielagen.
-
Wees bewust dat een zwakke verificatie kan leiden tot een incident/datalek. Een zwakke verificatiemethode kan bijdragen aan incidenten of datalekken. Wanneer achteraf blijkt dat de gehanteerde verificatiemethode niet passend was gelet op de mogelijke risico’s, kan dit leiden tot risico’s voor betrokkenen, je organisatie en onder de AVG tot handhaving of aansprakelijkheid.
-
Evalueer je verificatieproces periodiek. Door een kritisch verificatieproces periodiek te evalueren, verklein je het risico op eventuele datalekken en voldoe je sneller aan de eisen in de AVG.
-
Pas risicogebaseerde verificatie toe. Hoe groter de potentiële gevolgen en gevoeliger de data, hoe zwaarder de verificatiemethode.
Heb je nog vragen na het lezen van dit blog? Neem dan contact met ons op!
