De Europese GDPR, General Data Protection Regulation, bij ons ook wel de AVG geheten, spreekt in artikel 25 over security by design en security by default. Klinkt goed maar wat is eigenlijk het verschil? En hoeveel impact gaan deze eisen hebben op bedrijven en directies als ze op 25 mei aanstaande samen met de GDPR van kracht worden? Hieronder lees je meer over de zeven ins en outs van security by design en security by Default.
1. Security by design: tijdens het ontwerp al rekening houden met security. Security by design betekent dat je tijdens het ontwerp van een nieuwe applicatie of ict-omgeving rekening houdt met de beveiliging van persoonsgegevens. En dus niet zoals nu het geval is, dat er weinig aandacht aan wordt besteed en achteraf patches toegepast moeten worden. Beiden zijn wettelijke verplichtingen waaraan in het GDPR voldaan moet worden. Bedrijven moeten security by design en security by default aan kunnen tonen. Die plicht is onderdeel van het accountability en compliancy beginsel waar het GDPR op gestoeld is.
In Artikel 25(3) staat: ‘Een overeenkomstig artikel 42 goedgekeurd certificeringsmechanisme kan worden gebruikt als element om aan te tonen dat aan de voorschriften van de leden 1 en 2 van dit artikel is voldaan.’ Let op de formulering en het woord ‘kan’: het is (nog) geen harde eis. Bedrijven zijn op dit moment nog vrij om dit op eigen wijze aan te tonen via bijvoorbeeld hun documentatie.
2. Security by default: standaard instelling, de default moet op veilig ingesteld staan. Dat betekent dus bijvoorbeeld geen vinkje die standaard aangevinkt is voor het ontvangen van een nieuwsbrief. Zowel security by design als security by default zijn de basis van het groter geheel van de GDPR dat bescherming van persoonsgegevens als een fundamenteel recht regelt. En dat gaat behoorlijk ver. Niet alleen mag je niet een default opt-in doen met een aangevinkt checkbox, ook moet je vastleggen en kunnen aantonen voor welk deel van je applicatie of website je toestemming hebt gegeven.
Het alleen vastleggen van de toestemming zelf, zoals nu standaardpraktijk is, is niet meer voldoende. Dus als je bijvoorbeeld vijf inschrijf formulieren op je website hebt die elk naar dezelfde opt-in leiden zul je toch per opt-in betrokkene (de ‘data subject’) vast moeten leggen voor welk formulier dat was en wat er in dat formulier stond, zodat voor betrokkene ook later duidelijk kan worden waar hij precies toestemming voor heeft gegeven.
3. Encryptie als wondermiddel…of toch niet. De GDPR stelt dat het belangrijk is om persoonsgegevens zo goed als mogelijk te beschermen. Bij een eventueel datalek moet de security er aan bijdragen dat de schade voor de data subject zo minimaal mogelijk blijft. Art. 32 over security, heeft het over onder andere encryptie als mogelijk maatregel.
Encryptie op alle systemen maar implementeren dus? Dat zou logisch zijn, maar de dagelijkse praktijk is weerbarstiger. Recht-toe-recht-aan encryptie op filesysteem niveau gaat het lastig en omslachtig maken om bestanden bijvoorbeeld via de mail uit te wisselen. Ook kan encryptie een performance hit geven en maakt het vaak het beheer van omgevingen complexer voor de beheerders. Bitlocker is een optie voor Microsoft omgevingen omdat de hele disk transparant versleuteld wordt. Maar biedt het voldoende beveiliging om de data van personen te beschermen? Wel als de disk wordt gestolen maar in de dagelijkse praktijk dus onvoldoende.
Dit vraagstuk is een typisch voorbeeld van leemtes in de AVG. Concreet wordt het zelden en technische details staan er per definitie niet in. Het is momenteel aan eenieder om op zijn eigen manier te (proberen) te voldoen aan de complexe en lang niet altijd duidelijke compliancy regels.
4. Pseudonimisering? In artikel 25 wordt uitdrukkelijk de term pseudonimisering genoemd. Artikel 25(1) luidt voluit: Rekening houdend met de stand van de techniek, de uitvoeringskosten, en de aard, de omvang, de context en het doel van de verwerking alsook met de qua waarschijnlijkheid en ernst uiteenlopende risico’s voor de rechten en vrijheden van natuurlijke personen welke aan de verwerking zijn verbonden, treft de verwerkingsverantwoordelijke, zowel bij de bepaling van de verwerkingsmiddelen als bij de verwerking zelf, passende technische en organisatorische maatregelen, zoals pseudonimisering, die zijn opgesteld met als doel de gegevensbeschermingsbeginselen, zoals minimale gegevensverwerking, op een doeltreffende manier uit te voeren en de nodige waarborgen in de verwerking in te bouwen ter naleving van de voorschriften van deze verordening en ter bescherming van de rechten van de betrokkenen.
Ook voor mij was dat een nieuwe term. WTF is pseudonimisering? Pseudonimisering is een techniek waarbij de persoonsgegevens uit een bestand of database worden gehaald en onleesbaar worden gemaakt, bijvoorbeeld via encryptie. Vervolgens worden de persoonsgegevens in een ander bestand opgeslagen. Het proces moet omkeerbaar zijn. Groot voordeel van pseudonimisering is dat het een data minimalisatie techniek is, wat een essentieel hoeksteen is van de GDPR. Het lijkt in eerste instantie een interessante techniek. Azure Marketplace heeft pseudonimisering al toegepast door de implementatie van dynamic data masking op kolommen die persoonlijke data bevatten.
5. Relevantie van security by design en security by default voor ict-professionals en voor het management. Security by design en security by default zijn zeer relevant voor zowel ict’ers als voor het management. GDPR vereist immers compliance met alle 99 artikelen en dus ook met artikel 25. De relevantie van compliance kan niet genoeg worden benadrukt. Want de compliance en accountabilit- eisen moeten niet alleen worden nageleefd, organisaties moeten ook kunnen aantonen (accountability) dat ze de eisen uit de GDPR en dus ook artikel 25 in de praktijk naleven. De bewijslast ligt dus niet bij de Autoriteit Persoonsgegevens (AP) maar bij het bedrijf zelf.
Interessant is dat artikel 25 alleen spreekt van compliance door de controller. De processor, ofwel de verwerkingsverantwoordelijke volgt hier inherent uit. De verwerker voert immers uit in opdracht van de controller. Dat kan in de praktijk tot pittige meningsverschillen leiden. Gaat de controller bepalen hoe de processor zijn systemen moet inrichten? Lijkt me niet handig, dit is niet iets waar je je als controller mee bezig wilt houden. Er is bovendien momenteel geen AP goedgekeurde certificatie waar partijen op terug kunnen vallen, weinig houvast dus.
6. Wat is de relatie met DevSecOps? DevSecOps is de integratie van secure code in het DevOps proces vanaf de aanvang van de coding. Een goede zaak dus en in mijn optiek een fundering onder ‘GDPR compliant coding’.
7. Welk beleid moeten bedrijven voeren om aan de GDPR te voldoen? Voldoen aan de GDPR betekent de kernwaarden ‘verantwoording afleggen’ en ‘nakomingsverplichting’ (accountability en compliance) doorvoeren in de hele organisatie. Zonder steun van het hoger management, directie en raad van bestuur, is invoering van het GDPR in mijn ogen zeker gedoemd te mislukken. GDPR is veel meer dan een ict-security vraagstuk. Het gaat immers om zowel technische als organisatorische maatregelen.
Per definitie zal een dergelijk ingrijpend traject ongemakken en frustraties opleveren bij de gebruikers. Denk bijvoorbeeld aan het doorvoeren van de Spectre en Meltdown-patches. Een no-brainer onder GDPR. Maar impact van deze patches kunnen aanzienlijk tragere systemen zijn. Wie dekt de it-manager/cio als gebruikers steen en been klagen en het management de ict-manager dwingt de patches ongedaan te maken? Geloof me of niet, het gebeurt. In het verleden haalde men zijn schouders weer op en ging weer over tot de orde van de dag. Maar met de boetes van het GDPR (maximaal 4 procent van de wereldwijde omzet of twintig miljoen euro, whichever is higher) zal de directie zich ineens voor een duivels dilemma geplaatst zien.
In een volgend artikel ga ik nader in op hoe de pata protection officer (dpo) – voor veel organisaties vanaf 25 mei een verplichte functie – mogelijk een brugfunctie hierin kan vervullen.
Leuk artikel die er toch weer op een andere manier naar kijkt als veel artikelen.
Uit Punt 4: “Het proces moet omkeerbaar zijn”
Ik denk dat hier onomkeerbaar bedoeld wordt.
Stel een bedrijf meet gemiddelde snelheden op een bepaald traject en de politie wil dat gebruiken voor analyse om te kijken waar je vaak te hard wordt gereden. Dan pseudonimiseer je dat bestand door de kentekens te husselen. Als het omkeerbaar is dan kan de politie alsnog individuen ontrafelen.
Aan de andere kant. Als je een berg diagnoses hebt en je wilt een gespecialiseerde partij voorspellingen laten doen welke patienten een verhoogde kans op een bepaalde aandoening hebben. Dat wil je van die partij een lijst van patienten hebben zonder dat die partij weet om wie het gaat. Die pseudoniemen wil je dan weer kunnen matchen op echte patienten en deze aanschrijven.
Waar het in ieder geval op neerkomt is dat het voor de verwerkende partij geen toegevoegde waarde heeft om individiuen te kunnen herkennen je een set wilt aanleveren zonder persoonsgegevens. Dit is echter lastiger dan verwacht. Als je woon-werk verkeer analyseert (reist van punt a naar punt b) dan is daaruit heel snel een individu uit te halen zonder dat je persoonsgegevens had. Zo is het pseudonimiseren van een CV lastig.
https://bauhaus.nl/gdpr-pseudonimiseren-en-anonimiseren/
https://bauhaus.nl/gdpr-pseudonimiseren-en-anonimiseren-2/
De wilde wereld van de GDPR
https://nl.wikipedia.org/wiki/Pseudonimiseren maakt het nog wat gecompliceerder : “Pseudonimiseren kan omkeerbaar of onomkeerbaar worden gedaan”. Lijkt erop dat in anonimiseren dan als speciaal geval van pseudonimeseren wordt gezien, namelijk onomkeerbaar.
Dank Dino en Henri voor jullie reacties. Specifiek over pseudonimiseren bedoelde ik omkeerbaar. Anonimiseren zou idd zijn onomkeerbaar. Omkeerbaar omdat je de data weer terug wil kunnen lezen. Simpel voorbeeld is een Excel sheet met bijvoorbeeld namen. Stel dat je die namen onherkenbaar wilt maken via pseudonomisering. Dat is al het geval als je een simpele bewerking er op loslaat wat de eerste en laatste letters vervangt door een ander teken. Als je de data weer leesbaar wilt hebben zul je het proces weer moeten omdraaien.
Henri,
Iedereen wordt geacht de wet te kennen maar niemand houdt zich hieraan, de tegenstrijdigheid in wetten zorgt ervoor dat de belofte over privacy als het terugkrijgen van ons geld van de Grieken is. Je voorbeeld over de zorg zou tot zorgen moeten leiden als je even kijkt naar je redenering hierin, het commerciële belang van veel Amerikaanse bedrijven maakt Europa tot een proeftuin als we accepteren dat er sprake is van een omkeerbare anonimisering in de gegevensverstrekking en kijk dus vooral eens bij:
https://www.rijksoverheid.nl/onderwerpen/privacy-en-persoonsgegevens/vraag-en-antwoord/wie-krijgen-mijn-persoonsgegevens-uit-brp
Sorry Henri, maar ik denk dat je opportunistisch bent door een tegenstrijdigheid in je standpunt betreffende privacy als je weging van gegevens op de persoonlijke levenssfeer buiten je overweging laat. Laat ik zeggen dat een conclusie over geestelijke en lichamelijke gezondheid maatschappelijk meer impact heeft dan één kilometer te hard rijden op een dagelijkse traject om dus je boterham te verdienen.
In het stuk: “Interessant is dat artikel 25 alleen spreekt van compliance door de controller. De processor, ofwel de verwerkingsverantwoordelijke volgt hier inherent uit. ” staat een fout, de processor is de verwerker, niet de verwerkingsverantwoordelijke. In de rest van het artikel staat het wel goed.