De nieuwe 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 7 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 eventuele 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 o.a. 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 filesystem level 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 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 accountability 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 AutoriteitPersoonsgegevens 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. Verwerker voert immers uit in opdracht van 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 (max. 4% van de wereldwijde omzet of 20M 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 DPO, de Data Protection Officer – voor veel organisaties vanaf 25 mei een verplichte functie – mogelijk een brugfunctie hierin kan vervullen.
