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
