Het is de hoogste tijd dat persoonsgegevens in it beter beschermd gaan worden en dat vereist actie. Een administratie van risico’s helpt, maar lost het probleem nog niet op. In mijn dagelijkse praktijk van software-onderzoek zie ik steeds weer dezelfde security- en privacyfouten. Het zijn de oorzaken van de datalekken waar we dagelijks over lezen en de wet eist nu dat ze worden verholpen. In dit artikel laat ik graag zien hoe dat kan worden aangepakt.
Met wat voor soort problemen hebben wij te maken? Denk bijvoorbeeld aan sport-apps die je locatie doorgeven aan adverteerders – ook als je niet aan het sporten bent. Of denk aan Ashley Madison: de Amerikaanse website voor buitenechtelijke relaties. Zij hadden hun security niet op orde waardoor alle gegevens op straat kwamen, ondanks hun diverse keurmerken, waaronder ‘100 persent secure’. Hun grootste zonde was niet zozeer de slechte beveiliging, maar het bewaren van adresgegevens terwijl die niet meer nodig waren en het onnodig registreren van ip-adressen. Zo kon de hele wereld zien wie precies overspel pleegde en wie dat bijvoorbeeld vanaf zijn werk deed. Pijnlijk, en met consequenties.
GDPR maakt privacy urgent
Een lichtpunt voor de bescherming van onze persoonsgegevens is de vernieuwde aandacht voor privacy met de Europese GDPR wetgeving, die organisaties aansprakelijk stelt voor goede omgang met persoonsgegevens. Bijvoorbeeld: verzamel niet meer persoonlijke informatie dan noodzakelijk, regel toestemming voor datagebruik, verwijder data wanneer dat kan, stuur het niet zomaar naar anderen, versleutel waar nodig, en zorg dat systemen niet gehackt kunnen worden of anderszins data lekken.
Hoe gaat u nu vaststellen of deze privacyprincipes zijn ingebouwd in de it en hoe bepaalt u waar extra maatregelen noodzakelijk zijn? U bent immers ervoor verantwoordelijk dat de juiste organisatorische en technische maatregelen zijn genomen.
Wat er precies gebeurt met persoonsgegevens is helaas niet eenvoudig aan de buitenkant van de techniek of in documentatie te zien. Systemen zijn vaak complex, dynamisch of gedateerd en in het ergste geval een combinatie daarvan. Bovendien zit het privacy-venijn in de details. De kleinste beslissing van een programmeur kan leiden tot het grootste privacyprobleem: even die gegevens ook opslaan, even de gps lokatie opvragen of adressen op een kaartje zetten, et cetera.
Als u wilt weten wat er echt gebeurt met gegevens in it dan is het nodig de broncode te bekijken. Die bevat alle beslissingen van de programmeurs en op die manier kunnen overtredingen van de privacyprincipes worden ontdekt en verholpen, om zo compliant te zijn aan de wet. Bovendien, als software geen black box meer is dan kan tijd en geld worden bespaard omdat bepaalde organisatorische en technische maatregelen (zoals encryptie) niet overal nodig zijn.
Nu beginnen
Organisaties zijn nu druk met het zorgen voor een GDPR-administratie, vaak nog gebaseerd op aannames van wat er in de it gebeurt. Men kijkt op tegen verdieping in de techniek, omdat er veel techniek is. Waar moet men beginnen? Daarvoor is goed nieuws: met een risicogebaseerde aanpak kunt u meteen aan de slag. Start met onderzoek van het meest riskante softwaresysteem. Welk systeem dat is, hangt af van type applicatie, de gebruikte technologie, welke persoonsgegevens worden verwerkt, et cetera. Die eerste blik levert veel inzicht op in de eigen problematiek en of er meer systemen of onderdelen zijn die nader onderzoek behoeven, totdat het risiconiveau acceptabel is.
De GDPR omschrijft een ‘data protection impact assessment’ als middel om in te schatten of een gegevensverwerking risico’s heeft. Let op: dat is dus geen compliance-check, maar een risico-inschatting, die helpt om te bepalen welke systemen nader onderzoek verdienen.
Privacy by design
De GDPR eist dat privacyprincipes zijn gehanteerd in bestaande systemen en worden ingebouwd in nieuwe systemen. Maar wat blijkt: de correcte manier van omgang met persoonsgegevens is heel nieuw voor softwarebouwers. Ze zijn gewend om data te zien als het nieuwe goud, en moeten nu afscheid gaan nemen van aangeleerde principes. zoals het zo lang mogelijk bewaren van zoveel mogelijk data, ‘want dat is handig voor bijvoorbeeld marketing’.
Op bijeenkomsten van software engineers staan we vaak met een stand en dan vragen we aan de hand van een codevoorbeeld of men de securityproblemen kan vinden. ‘Find the flaw’ noemen we dat. Vaak vindt men tussen de 20 procent en 80 procent, maar we hebben ook een voorbeeld met privacy-problemen en daar wordt maar 0 procent tot 40 procent gescoord. Ontwikkelaars blijken een blinde vlek te hebben voor verantwoorde omgang met persoonsgegevens. Deze problematiek doen ze typisch af als ‘Dat is toch voor juristen?’ en het klopt dat juristen soms de knoop moeten doorhakken, maar de ontwikkelaar heeft wel degelijk een belangrijke rol, namelijk herkennen wanneer ze zich moeten afvragen: ‘mag dat?’
Door broncode en ontwerp te onderzoeken op privacyproblemen kan aan de ontwikkelaars worden teruggegeven waar ze op moeten letten, om zo het bewustzijn en inzicht te vergroten.
Radioactief goud
Ontwikkelaars zouden persoonsgegevens moeten gaan zien als radioactief goud: het is van waarde, maar ga er voorzichtig mee om, kijk uit waar je het laat en beperk het tot een minimum.
We merken in eerste instantie veel weerstand tegen het privacy-idee omdat men denkt dat het in de weg staat van data-gestuurd werken. Maar men wordt enthousiaster als we dan laten zien welke technieken er bestaan om zowel voordeel te halen uit data als privacy in acht te nemen. Denk daarbij aan slim aggregeren, pseudonimisering/anonimisering, gescheiden opslag et cetera. Met de juiste kennis van zaken is het vaak mogelijk om de concessies te minimaliseren.
GDPR biedt een nieuwe kans
Om onaangename privacyverrassingen uit it te halen en te houden is het nodig te onderzoeken wat er precies gebeurt in de broncode en daarop actie te nemen. Hierdoor gaan risico’s op boetes, aansprakelijkheid, klantverlies en imagoschade drastisch omlaag. Bovendien helpt het verbeterde inzicht bij het goed instruereren van ontwikkelaars en bij gericht investeren in passende maatregelen. Het wordt zelfs mogelijk om te concurreren op privacy. Wat je niet verzamelt en wat je goed beschermt kun je niet lekken. Privacy is gegroeid van wens naar eis en professionele organisaties kunnen hier het goede voorbeeld geven. Al was het maar om te voorkomen dat ze gebruikt worden als voorbeeld hoe het niet moet.
Rob van der Veer, principal consultant, Software Improvement Group (SIG)
