5 mythes over GDPR en encryptie ontkracht

Iedereen weet nu wel dat op 25 mei de nieuwe GDPR-wetgeving van kracht wordt. Er wordt dus druk bekeken wat er allemaal nodig is om in orde te zijn met de nieuwe regels. Wij krijgen daar dan ook heel wat vragen over. De meest gestelde vragen gaan over GDPR en encryptie en dan vooral deze: “Verplicht GDPR je om al je data te encrypteren?” In deze blogpost geven we een antwoord en ontkrachten we tegelijk andere mythes over GDPR en encryptie.

1. Verplicht de GDPR encryptie?

Een simpele vraag, want we kunnen het antwoord gewoon opzoeken in de GDPR-wetgeving zelf. Het woord encryptie (of versleuteling) komt slechts vier keer voor in de 88 pagina’s tellende tekst van de GDPR:

• Teneinde de veiligheid te waarborgen en te voorkomen dat de verwerking inbreuk maakt op deze verordening, dient de verwerkingsverantwoordelijke of de verwerker de aan de verwerking inherente risico’s te beoordelen en maatregelen, zoals versleuteling, te treffen om die risico’s te beperken. (pagina 16)
• het bestaan van passende waarborgen, waaronder eventueel versleuteling of pseudonimisering. (pagina 37)
• maatregelen om een op het risico afgestemd beveiligingsniveau te waarborgen, die, waar passend, onder meer het volgende omvatten: a) de pseudonimisering en versleuteling van persoonsgegevens;
• de persoonsgegevens onbegrijpelijk maken voor onbevoegden, zoals versleuteling (pagina 53)

De woorden “zoals”, “waaronder” en “waar passend” laten duidelijk zien dat de GDPR-wetgeving nergens versleuteling verplicht, maar het louter als mogelijkheid ziet. Het geeft wél aan dat encryptie een goede optie is en dus de moeite om over na te denken.

Dàt is wat de GDPR-wet verplicht: dat je nadenkt over hoe je met data omgaat. Je mag/moet elke oplossing aftoetsen aan de technische en economische haalbaarheid.

Draai de situatie om: stel je voor dat je een datalek krijgt en iemand stelt de vraag: “Waarom heb je geen encryptie toegepast?”. Als je dan een aanvaardbaar antwoord hebt, is er niets aan de hand volgens de wetgeving.

2. Zorgt encryptie ervoor dat ik datalekken niet moet melden?

Deze vraag is al meer genuanceerd. Het staat nergens in de wetgeving letterlijk zo vermeld. Wat er wel staat is dat je het data subject, de persoon over wiens data het gaat, zelf moet inlichten als er een reëel gevaar bestaat dat zijn data gelekt is en er kans is dat de data aan hem te linken is. Als de data versleuteld of gepseudonimiseerd is, is dat dus niet nodig.

Voor je begint te juichen, moet je wel realiseren dat dit je niét ontslaat van je eventuele plicht om het lek te melden bij de Gegevenbeschermingsautoriteit (GBA, nu nog even de privacycommissie). Komt bij dat je best toch eens nadenkt over eventuele reputatieschade als het datalek toch nog bekend raakt en blijkt dat jij het niet gemeld hebt.

Encryptie maakt dat je sterker staat: “Ja, er was een datalek maar de gegevens zijn onbruikbaar” is de beste verklaring die je kan geven op zulk moment.

3. Welke encryptietechnieken moet ik gebruiken van de GDPR?

Opnieuw geen vermeldingen in de GDPR-wetgeving zelf. Nergens vind je begrippen zoals encryption in rest, encryption in transit, Triple-DES, AES, enz. De GDPR-wet verplicht je enkel om “security by design” en “privacy by default” te voorzien.

Het is niet voldoende om security enkel op het einde van een project als extra sausje over het geheel te gieten. Je moet al rekening houden met security van op de tekentafel. Dit is voor ons als security-experts niks nieuw. Wij raden al jaren aan om meerdere beschermingslagen te voorzien. Om een simpele vergelijking te maken: is een slotgracht rond je burcht voldoende of voorzie je toch ook best dikke muren, stevige poorten, ijzeren hekken en wachten die 24/7 op post zijn?

Het hangt ook allemaal af van de gegevens waar je mee werkt. Dat je zoveel mogelijk bescherming voorziet voor gevoelige data is een evidentie. Dat het iets minder is voor minder gevoelige data, is toegelaten.

Hou er dan wel rekening mee dat de gevoeligheid van data soms kan toenemen. Niet door de aard van de data zelf, maar door de hoeveelheid data die je verzamelt. Weten dat iemand naar een concert van Iron Maiden is geweest, is geen gevoelige data. Weten naar welke optredens die persoon nog allemaal is geweest, maakt profiling mogelijk. En dan wordt diezelfde data plots wél gevoelig.

4. Is het voldoende om encryptie over te laten aan systeembeheerders?

Neen. Net zoals bij vraag 3 verwijzen we hier naar de verplichtingen “security by design” en “privacy by default”. Je moet op alle niveau’s nadenken over de beveiliging van de gegevens die je verwerkt.

Daar kan DevOps een belangrijk voordeel bieden. Ontwikkelaars en systeembeheerders moeten van in het begin met elkaar communiceren en samen beslissen wat haalbaar en nodig is, onder leiding van iemand met een C-level. CIO’s en CEO’s moeten dus voldoende betrokken zijn. Data security is te belangrijk om het enkel over te laten aan IT.

5. Lost diskencryptie niet alle problemen op?

Diskencryptie is een typisch voorbeeld van een eenvoudige oplossing die vaak een onvoldoende scoort. Diskencryptie is “encryption in rest”: het is een oplossing wanneer de schijf verloren raakt of gestolen wordt. Een goede oplossing dus voor laptops of externe harde schijven.

Het is echter geen oplossing voor servers, want die draaien quasi 100% van de tijd. En wanneer de server actief is, is de schijf toegankelijk. Een hacker die een server binnendringt, kan dus nog altijd de gegevens van een versleutelde schijf lezen.

Je zal dus ook naar andere technieken moeten kijken die programmatorische wijzigingen vereisen, zoals database-encryptie of pseudonimisering van de gegevens. Of nog simpeler: je de vraag stellen of je die gegevens eigenlijk echt wel moet/wil bijhouden.

Wat kan Combell doen om je te helpen?

Bij Combell hebben we pakken ervaring met DevOps en zijn we dus ideaal geplaatst om samen met jou te kijken welke stappen wenselijk/nodig zijn om je data beter te beveiligen. Daarbij gaan we altijd gefaseerd te werk: we kijken welke maatregelen snel en eenvoudig te implementeren vallen en vervolgens identificeren we maatregelen die meer tijd en energie vragen en dus in een volgende fase aan bod kunnen komen.

Heb je nog vragen, opmerkingen of wil je meer weten? Stuur ons een berichtje via het contactformulier.

Maak het je gemakkelijk met iubenda

Iubenda is een tool die ontwikkeld is om ervoor te zorgen dat jouw website altijd in orde is met de GDPR. Zo schrijft iubenda een privacy en cookie policy voor jouw website én maak je er een cookiebanner mee in jouw huisstijl.