Met de naderende ingangsdatum van GDPR/AVG op 25 mei schuift menig leverancier zijn oplossing naar voren als de heilige graal voor de bescherming van data. Deze opinie werpt een ontnuchterende blik op geboden oplossingen die vaker helemaal geen volledige oplossing zijn. De doelstellingen van het beschermen van data en faciliteren van gegevensuitwisseling staan vaak haaks op elkaar. Dit probleem kan niet opgelost worden als de bescherming van data niet fundamenteel anders aangepakt wordt.
Wat GDPR vereist is dat je, kort samengevat, netjes met data omgaat. Je mag geen data van mensen opslaan als dat niet nodig is. Ook moet je mensen in de gelegenheid stellen hun data, die jij opgeslagen hebt, aan te passen of eventueel te verwijderen. Dat zijn zaken die een functioneel karakter hebben. Dit uitvoeren kan lastig zijn maar gelukkig is het wel erg concreet. GDPR vereist ook dat je redelijke maatregelen neemt om een datalek te voorkomen en ook dat je het meldt als er toch een datalek geweest is. In dit stukje zit het probleem. Data kan op zo veel verschillende manieren kwijt raken. Bedrijven hebben vaak geen volledig overzicht waar hun data is en waar het naar toe stroomt. Als duidelijk is dat data gelekt is, dan is nog lang niet duidelijk waar dat lek precies zit.
Achterhaalde oplossingen
Een beetje vereenvoudigd zijn er drie gebieden waar een datalek kan plaatsvinden:
1. een hack op een specifiek onderdeel
2. datalek in de omgang met data
3. administratieve toegang
Iedereen die over een datalek hoort denkt onmiddellijk aan de eerste categorie. Dit is het gebied waar iets wordt gebroken of omzeilt. Een hack kun je niet voorkomen omdat het afhangt van de creativiteit van de hacker, van de totale hackbare oppervlakte van een applicatie en hoe goed die beschermd is. In dit gebied worden de meeste kosten gemaakt om de kans te verkleinen dat waardevolle informatie kan worden buitgemaakt. Systemen worden hiertoe periodiek gepatched. Daarnaast bestaat een hele rits aan dure secundaire systemen die moeten detecteren dat men gehacked wordt of beter nog dit te voorkomen.
De tweede categorie bestaat uit het omgaan met de data door klanten en intern personeel. Dit wordt gedaan door op een normale manier met het systeem om te gaan. Deze categorie wordt bijna nagenoeg alleen beveiligd door authenticatie en autorisatie. Authenticatie is eenvoudig gezegd gebruikersnaam en wachtwoord. Autorisatie is de exacte bevoegdheid van wat iemand precies mag zien. Het idee hier achter is dat je accounts van medewerkers die niet meer bij het bedrijf werken afsluit en dat je mensen niet meer autorisatie geeft dan nodig is.
In theorie zou dit een goede beveiliging moeten zijn. De praktijk wijst echter anders uit. Een enkel geraden wachtwoord kan betekenen dat data toegankelijk voor anderen wordt. Gek genoeg accepteren we eigenlijk heel erg makkelijk dat dit niet helemaal perfect is. Voor externe klant accounts maakt een gelekt wachtwoord niet uit. Veel bedrijven zijn van mening dat bescherming van het wachtwoord toch de verantwoordelijkheid van de klant zelf is en bovendien zijn de bevoegdheden van de klant ingeperkt met autorisatie.
Binnen het bedrijf gaan we nog slordiger met data om. Een voorbeeld is data te verplaatsen naar gebieden waar beperkte regels voor authenticatie en autorisatie gelden zoals test-omgevingen. We staan dit toe omdat het ’toch maar binnen het bedrijf” is. Om bij de data te komen moet men toch eerst binnen het bedrijf zijn. Dit is de gedachte die er sinds er computers zijn heerst en er erg diep in zit. Met de komst van botnetten is dit echter voor goed veranderd. We zijn nog niet volledig aan deze veranderde wereld gewend. De komst van het botnet zorgde er voor dat de bescherming van authenticatie en autorisatie kwam te vervallen. Een botnet neemt bezit van je computer en leest mee wat jij aan het doen bent. Het botnet heeft toegang waar jij ook toegang hebt. Dat betekent dat alle Excel lijsten met gedownloade gegevens op jouw pc door het botnet gekopieerd kunnen worden. De bescherming die authenticatie en autorisatie had moeten bieden is daarmee volledig omzeild.
Tegenmaatregelen zoals virusscanners die botnetten moeten detecteren zijn maar deels effectief. Dit is een kantelpunt in de manier van omgaan met data en er is geen weg meer terug. We hebben te accepteren dat toegang ook automatisch betekent dat data door anderen benaderd kan worden. Het grootste lek van gegevens zit dus bij de mensen die beroepshalve met de data omgaan.
Een voorbeeld van hoe data onder je neus weg kan lekken is het Broedkamer incident bij de Belastingdienst (Computable 3-7-2017). Data raakte hier kwijt in de omgang met waarschijnlijk alle goede bedoelingen tijdens de analyse van de data. We kunnen dit incident veroordelen maar het is wel exact de wijze van hoe we nu met data omgaan: We halen het uit het systeem om het door te kijken, te analyseren en met anderen te delen.
De derde categorie is administratieve toegang. We zijn bijna vergeten dan niet altijd een hack nodig is. Beheerders kunnen overal bij. Het zijn er echter maar een paar, ze werken al jaren bij het bedrijf en ze hebben een NDA getekend. Waarom dus zorgen maken? Er is ook heel weinig aan te doen. Het heeft geen zin beheerders uit te sluiten. Toen de site Ashley Madison ‘gehacked’ werd rezen er ook vragen over hoe het mogelijk was dat er zo veel data (40 GB) in een keer gestolen kon worden. Het duurde even voordat iemand durfde te beweren dat dit alleen van binnen uit gedaan kon zijn.
Samengevat: iedereen denkt direct aan een hack maar de huidige manier van omgang met data maakt dat deze makkelijk weg lekt. Het lijkt een beetje op het verplaatsen van fijn zand.
Zoeken naar een oplossing
De totale geleden schade in Nederland is voor 26 procent afkomstig uit gelekte gegevens in 2015 en voor 32 procent in 2016 (AIVD). Dat is 6 procent toename binnen een jaar. Men is dus ook wel echt op zoek naar een oplossing. Het algemene idee achter het ‘beter binnen houden’ van data is dat we het beter moeten verstoppen. Deze gedachtegang volgt een aantal partijen die Bitlocker als de oplossing voor GDPR gerelateerde problemen aanraden. Bitlocker past sterke AES-versleuteling toe op de data zoals die is opgeslagen op de harde schijf van je computer. De data wordt ontsleuteld zodra deze door het besturingssysteem wordt gelezen. Dat werkt op zich heel goed.
Een verloren laptop in de trein met Bitlocker is voor een vinder onbruikbaar. Dit is een goede maatregel tegen het risico van verlies van een laptop. Tegen alle andere dreigingen van het verlies van data doet het echter niets. We hebben net gezien dat verlies in de omgang het grootste risico is. Sterke AES-versleuteling wordt bijvoorbeeld ook toegepast bij SAP Hana bij data volume encryption. Dit is inderdaad een goede oplossing om ongeoorloofde toegang tot de database te beveiligen. Dit komt bijvoorbeeld tot zijn recht als de backup van de database op een plek staat die je minder vertrouwt dan je eigen server.
Data is echter niet meer versleuteld als deze in gebruik is. SAP haalt zijn snelheid vooral uit zijn in-memory-computing techniek. Encryptie op dat level zou enorme gevolgen voor de performance kunnen hebben. Dit is dus niet gedaan. Volume encryptie is dus van toegevoegde waarde voor de bescherming van de data, maar is zeker geen volledige oplossing. Je kunt je dus ook oprecht de vraag stellen dat als bescherming van data in de omgang al niet geregeld is, welke waarde dataprotectie op opslag dan heeft. Vaak wordt encryptie gebracht als een totaal oplossing wat het dus niet is (GDPR-oplossing en de toepassing van drive encryptie).
Kernprobleem
Het kernprobleem is dat data in de omgang moeilijk te beschermen is. Er wordt gebruikt gemaakt van authenticatie en autorisatie maar verder dan dat gaat het vaak niet. Mensen hebben toegang tot data nodig om er mee te kunnen werken. Je kunt dit niet beperken omdat het nodig is.
Om data in de toekomst beter te kunnen beschermen moeten we drie dogma’s loslaten:
• Met authenticatie en autorisatie is alles geregeld;
Het gedrag van het opvragen van informatie is ook van belang. Wie vraagt wat in welke omstandigheid op. Bij sommige hacks werd langzaam een gehele database gelezen zonder dat het opviel. Authenticatie en autorisatie is belangrijk maar afdoende.
• Versleuteling van data op disk is voldoende;
Versleuteling is heel goed om te hebben maar als het alleen op disk is en je werkt verder met onversleutelde data dan mis je als nog de boot.
• Voor analyse is het nodig om data op te halen, te bewerken en terug te zetten
Dit is zoals we nu werken: Data download naar Excel, bewerken en weer een upload.
Het is min of meer ook de manier zoals we vroeger met papier werkten. Voor het uitvoeren van de optelling 1 + 2 = 3 heb je de afzonderlijke waarden nodig anders kan je de berekening niet uitvoeren. Tenminste, dat is de gedachte. Bij het controleren van een specifieke postcode moet je zelf de waarde kunnen zien. Bij veel bewerkingen is het echter niet nodig dat je de waarden zelf ziet. Je kunt de optelling uitbesteden zonder de waarden zelf te kennen: a+b=c.
Hoe oplossen?
Als dat erg voor de hand liggend en erg makkelijk was dan was het jaren geleden al opgelost. Ik hoop dat dit artikel duidelijk heeft gemaakt dat er geen ‘one-button-solution’ is en dat gemaakte kosten niet altijd evenredig zijn met het nut wat ze hebben. De oplossing zit in de hele manier van werken en omgaan met data en dat betekent hele fundamentele veranderingen.
De eerste verandering is dat data permanent versleuteld moet zijn. Dat betekent dat een beheerder in ieder geval niet zomaar toegang tot data heeft. Een hack heeft in dat geval geen zin meer want zowel uit de applicatie als uit de database is geen “plain tekst” data meer te halen. Dit stelt echter totaal nieuwe eisen aan cryptografische algoritmen. Ook zoeken in versleutelde data is een serieus probleem. De manier van opvragen van data aan de client kant zal ook moeten veranderen. Vaak weten we niet wat we zoeken en vragen dan te veel data op om die visueel te filteren. Betere zoek- en filter technieken moeten zorgen dat we niet alles met directe data hoeven te doen maar dat we voor analyse ook kunnen rusten op metadata.
Tot slot zal gevolgd moeten worden wie, welke data waarom opvraagt. Deze beweging is een aantal jaar geleden ingezet met de intrede van security information and event management (Siem)-applicaties, alleen nog niet op dit niveau. Hieraan kan men het opvragen van data onder een botnet herkennen en gepaste maatregelen nemen. Verder wil ik waarschuwen dat het een illusie is hackers helemaal te stoppen. Hackers zoeken met ongekende creativiteit en niet aflatende geestdrift tot ze gevonden hebben wat ze zoeken. Daarom gaat actieve misleiding verder waar bescherming van data stopt.
Om je te helpen betere keuzes te maken de volgende hulpjes:
• Beschermen dat data van een pc lekt is goed maar zorgen dat data niet op een pc komt is beter;
• Encryptie van ‘data at rest’ heeft alleen nut voor de bescherming van de backup;
• Siem is een goede investering omdat deze in de komende jaren belangrijker wordt;
• Encryptie is in het algemeen een goed idee maar moet op de toepassing worden afgestem;d
• Je beheerders hebben toegang tot het systeem nodig en niet noodzakelijker wijze tot de data. Beperk hun rechten;
• Gebruik geen productiedata op test systemen maar maskeer deze;
• Kunnen alle interfaces alle data lezen? Rechten zijn vaak standaard te veel;
• Voorkom dure oplossingen die niet het probleem oplossen.
Mark Deiss, security consultant bij Newitera
Een Excel met persoonsgegevens versturen naar een verkeerd email adres is een datalek.
Een goed versleutelde laptop met daarop persoonsgegevens die kwijt raakt moet gemeld worden bij autoriteit persoonsgegevens. Zij doen dan de inschatting of er een datalek is ontstaan.
In de basis is het simpel. Weet wat je vastlegt en waarom, vraag hier expliciet toestemming voor, en geef aan met wie je deze data deelt en ga zorgvuldig met de data om en controleer of je verwerkers dit ook doen. Daarnaast moet je rekening houden met minderjarigen e.d. en moet je op kunnen lepelene bij een verzoek wat je daadwerkelijk vast hebt gelegd. Dit is het in een notendop.
Vooral het netjes proberen doen en dit aantoonbaar maken is wellicht de belangrijkste manier om boetes te voorkomen.
En ook niet onbelangrijk vergeet niet om toestemming te vragen en bij te houden voor het verzamelen van data die niet strikt noodzakelijk is voor het doel waarvoor de klant, klant is geworden. Geef diezelfde klant ook de mogelijkheid om de toestemming in te trekken (deze functie moet net zo makkelijk te vinden zijn als de functie voor toestemming geven), en als die klant de toestemming intrekt moet ook de data waarop de toestemming betrekking heeft worden verwijderd.
Tot slot zou het voor de klant ook mogelijk moeten zijn om zijn data mee te krijgen als hij niet meer klant wenst te zijn (inclusief het recht om vergeten te worden). Dit moet zodanig gebeuren dat deze data automatisch is te verwerken door een concurrent om te gebruiken voor de dienstverlening aan die klant.
Al met al een wet met behoorlijke impact op bedrijven, maar zeker ook veel kansen om de klantervaring sterk te verbeteren!
@Mark,
Goed stuk. Dank je wel.
Ik meen dat je gelijk hebt dat er geen one-button oplossingen zijn. Het gaat veel meer om het omarmen van een ander paradigma. Namelijk dat ieder, in welke rol dan ook, niet meer kan zien dan vereist is voor die rol. Ik meen dat daarmee een belangrijk deel van de gebruikersfouten voorkomen kunnen worden.
Dat betekent dat alle informatie open is (anders kan je de afdelingsinformatie van de collega niet meer zien;-), tenzij er een heel-goede-reden is de informatie af te schermen. klinkt paradoxaal, maar denk er even over na. Voor je het weet schieten de fundamentalisten door.
De AVG geeft daar dus aanleiding voor beperken van inzage/gebruik. Net zoals de export wetgeving, de wet politiegegevens, de wet op de inlichtingen en veiligheid, de wet geneeskundige behandelingsovereenkomsten, etc, etc.
Je geeft een aantal bruikbare technieken. En die zijn allemaal nodig. Als extra’s wil ik graag Attribute Based Access Controls noemen. Dit is bruikbaar voor elke combinatie van compliance op diverse wetgevingen. Dit is ook schaalbaar naar interne en externe gebruikers. Hoe dat werkt: Op basis van jouw rol, wordt de informatie wel/niet naar jou toegestuurd. Dit draagt er zorg voor dat informatie alleen maar naar de werkplek komt als jij daarvoor de bijbehorende attributen hebt. De data moet dan overeenkomstige attributen hebben. Je hebt hiervoor ook een policy-manager en een policy enforcer nodig om de persoonsattributen en data-attributen te kunnen koppelen.
Hiervoor is al veel commerciële software beschikbaar. Boldon James, NextLabs, Titus Labs, etc. Dat werkt altijd goed samen met de gebruikte de-facto standaarden. NextLabs gaat aanzienlijk verder met haar portfolio. Maar ook in de Open Source wereld zijn hier ontwikkelingen. Ik herinner de naam Classify-IT als tool. En in Libre Office is het gebruik van data-attributen al ingeregeld op document niveau. Op dit moment werkt men aan implementatie op paragraaf niveau. De hardening van de data en de attributen gebeurt in Libre Office met sha256.
@Henri
Volgens mij hoef je het verlies van (goed gehardende) encrypte laptop (met persoonlijke gegevens) niet te melden. Dat zou hetzelfde zijn als het melden van een bewust encrypte email die persoonlijke gegevens bevat. Als dat moet gebeuren, dan moeten we terug naar briefpapier.
De zwakheid in mijn betoog is het feit dat de laptop de geheime sleutel bevat die door een goede inlog gebruikt wordt. Dat betekent nmm dat het inloggen in die laptop ook op een sterke manier moet plaatsvinden. Als je ook dit hebt geregeld, dan is melden nmm zeker niet nodig.
Oa toelichting 88 geeft hiervoor handvatten.
En Art 33 lid 1 stelt nadrukkelijk een meldplicht, tenzij het niet waarschijnlijk is dat de inbreuk risico inhoudt voor de rechten en vrijheden van natuurlijke personen.
@henri
“Vraag hier expliciet toestemming voor, en geef aan met wie je deze data deelt en ga zorgvuldig met de data om en controleer of je verwerkers dit ook doen”
Daar heb ik laatst eens iets over gevraagd toen jij je foto-dumpen-op-de-aws-cloud-is-zo-handig oplossing beschreef. Hoe staat het daar mee?
Fekke; “En Art 33 lid 1 stelt nadrukkelijk een meldplicht, tenzij het niet waarschijnlijk is dat de inbreuk risico inhoudt voor de rechten en vrijheden van natuurlijke personen.”
Het gaat erom dat zij dit bepalen ivm kwijtraken versleutelde laptop. Het betekent overigens niet dat je de wet of iets dergelijks overtreedt, maar dat zij “goed versleuteld” niet als waarheid aannemen.
Maar zoals je zegt, niemand wordt er beter van als we het fundamentalistisch benaderen. Maar de gedachte achter GDPR vind ik op zich goed. Kunnen aantonen dat je in control bent als het gaat om data over anderen.
Swa, ik heb vorige keer al aangegeven dat het qua compliance gewoon geregeld is en dat AWS cloud prima gebruikt kan worden. Ik ga daar niet verder op in.
@Henri
Tja. Ik kan me voorstellen dat de AP de afdoende versleuteling zou willen bepalen. Maar in de wet staat dat niet. Er staat echt dat de verantwoordelijke dit moet vaststellen. En als de versleuteling in zichzelf heel goed is, maar het is een laptop zonder wachtwoord, tja, dan heb je alsnog een probleem. Dan moet je (als het uitkomt) vast ook gaan uitleggen hoe het komt dat je een verkeerde inschatting hebt gemaakt.
Gelukkig (voor de verantwoordelijken) is in de AVG ook ruimte voor certificeringen. Dat zou (in principe) ook van toepassing kunnen zijn op implementatie van maatregelen in technologie. Bij de AIVD kan je zelfs een lijstje inkijken van goedgekeurde spullen (https://www.aivd.nl/onderwerpen/informatiebeveiliging/beveiligingsproducten). Waarschijnlijk te zwaar spul voor commercieel gebruik, maar toch. AIVD heeft zelfs een proces waarbij gecertificeerde Nederlandse beveiligingslabs namens hen het onderzoek naar veiligheid uitvoeren. Dat initiatief zou uitgebreid kunnen worden. Daar zouden veel verantwoordelijken bij geholpen kunnen zijn.
Ik denk in ieder geval dat het op een of andere manier hier heen moet gaan. Een Trusted Third Beveiligingslab die de veiligheid en de assurance daarop kan vaststellen. Inclusief de mogelijke configuratie van de afhankelijke parameters.
Maar wie gaat er controleren op GDPR? En de gene die controleert, heeft die wel genoeg tijd om alle officiele data lekken te checken en eventuele boetes uit te gaan schrijven?