Info Support: security en privacy in alle haarvaten van het ontwikkelproces

Security en privacy zijn typisch van die onderwerpen die vaak te laat aan bod komen bij softwareontwikkeling. Teams hebben maanden gewerkt aan een nieuwe functionaliteit en vlak voor de live-gang daalt plots het besef in: hebben we eigenlijk wel goed genoeg nagedacht over de veiligheid van data?

Het is natuurlijk beter om vanaf het allereerste moment in het ontwikkelproces rekening te houden met de beveiliging en bescherming van data. In de praktijk zijn ontwikkeltrajecten echter zelden ‘secure by design’. Wie wel op deze manier wil werken, moet aandacht besteden aan zowel de techniek als aan het ontwikkelproces. Niet voor niets heeft Info Support specialisten op beide fronten, waaronder Principal Architect Raimond Brookman en Senior Adviseur Privacy & Ethiek Nico Nijenhuis.

De vraag aan deze experts is dan ook: hoe zorg je er nu voor dat security en privacy worden geïntegreerd in het volledige ontwikkelproces? Wanneer ben je nu écht ‘secure by design’? Raimond Brookman: “Waar het in de praktijk vaak misgaat is dat DevOps-teams in sprints werken aan een functionaliteit. Pas op het moment dat de penetratietest wordt uitgevoerd, gaat iemand in het team vragen stellen zoals Hebben we de security & privacy eigenlijk wel op orde?”

“Teams hebben vaak een hele sterke focus op het doel van het ontwikkeltraject”, aldus Nico Nijenhuis. “En door die focus verliezen ze andere zaken uit het oog, waaronder privacy en ethiek. Je ziet het nu bijvoorbeeld gebeuren met Smart City-initiatieven, waarin mensen op straat in kaart worden gebracht aan de hand van hun mobiele telefoon, met behulp van WiFi en Bluetooth-tracking. Als voetganger heb je hier vaak geen idee van, laat staan dat je je er redelijkerwijs aan kunt onttrekken. Dit soort technologieën wordt ook lang niet altijd om veiligheidsredenen ingezet, maar om relevante informatie aan te leveren voor winkeliers. Dat schiet voorbij aan maatschappelijke waarden als privacy en openbare ruimten die vrij toegankelijk moeten blijven.

En wat kun je daar als ontwikkelteam aan doen?
“Het is vooral belangrijk dat er meer aandacht komt voor duurzaam succes in plaats van kleine succesjes op korte termijn. Is de oplossing die we ontwikkelen veilig genoeg en maatschappelijk aanvaardbaar? Dat zijn heel andere discussies dan de gesprekken die ontwikkelaars gewend zijn om te voeren over de techniek. Als je daar niet mee begint, dan loop je het risico dat je een werkende oplossing alsnog van de muur moet schroeven, zoals nu in enkele steden wel het geval is.”

Raimond Brookman: “Over het algemeen zie je nog te vaak voorkomen dat IT-bedrijven en afdelingen een houding aannemen van ‘u vraagt, wij draaien’. Een opdrachtgever of Product Owner stelt requirements op, het ontwikkelteam gaat daarmee aan de slag. En als het dan achteraf mis gaat omdat er niet goed genoeg is nagedacht over privacy en security, dan wordt de opdrachtgever daarop aangesproken. De opdrachtgever is formeel eindverantwoordelijk, maar bij Info Support vinden we dat we daarbij wel moeten helpen, door vanaf het eerste moment met onze klanten na te denken over deze aspecten. Dat betekent ook dat je kritische vragen moet durven te stellen.”

Kun je daar wat voorbeelden van geven?
“Onze opdrachtgevers zijn inmiddels verplicht om een eigen register bij te houden van de persoonsgegevens die ze verwerken en ook waarom, voor hoe lang en ga zo maar door. Je kunt als ontwikkelteam de opdrachtgever helpen te blijven voldoen aan de AVG door deze registergegevens mee te leveren bij een oplevering. En dit betekent automatisch dat er tijdens de ontwikkeling aspecten op tafel komen zoals bewaartermijnen en doelbinding”, aldus Nico Nijenhuis. “Maar de keuzes die een ontwikkelteam maakt kunnen ook verplichtingen met zich meebrengen voor opdrachtgevers. Het kan betekenen dat er juist daardoor een formele beoordeling opgesteld moet worden van de privacyrisico’s die de goedkeuring vereisen van een interne privacy officer. Soms blijkt zelfs dat het nodig is om goedkeuring te vragen bij de Autoriteit Persoonsgegevens. Dat kan nogal wat gevolgen hebben voor de doorlooptijd en business case. In gesprek met de klant kom je er zo achter wat wenselijk en wijsheid is.” Kortom: een ontwikkelteam moet niet alleen verstand hebben van techniek, maar ook van wet- en regelgeving.

Wat kunnen opdrachtgevers er zelf aan doen om ‘secure by design’ te zijn?
Raimond Brookman: “Je ziet het helaas nog wel eens gebeuren dat IT-teams en privacy-experts volledig los van elkaar opereren, in silo’s. Als je een vraag stelt aan IT’ers over de beschikbaarheid, integriteit en vertrouwelijkheid van data, dan zeggen ze: ‘Goede vraag, ik weet eigenlijk niet zo goed wat onze organisatie daarmee doet.’ De beste manier om dit probleem te tackelen is om te beginnen met het doel voor ogen: stel jezelf eerst de vraag wat een nieuwe oplossing of feature bijdraagt aan de business. Met name in de agile-wereld is er helaas nog te vaak een focus op het ontwikkelen van nieuwe features. Begin daarom met het stellen van strategische vragen. Breng in een vroeg stadium in kaart brengen wat het risico is op een security-breach is en wat daarvan de financiële gevolgen kunnen zijn. Op die manier kun je daar al bij het ontwerp van functionaliteiten rekening mee houden door passende maatregelen te nemen. Het klinkt misschien logisch, maar in de praktijk komt het heel vaak voor dat dit soort vragen niet wordt gesteld.”

Training
Om ontwikkelteams te helpen met dit vraagstuk, heeft Info Support een Bootcamp Security en Privacy ontwikkeld. Deelnemers leren hier onder meer welke vragen op verschillende momenten in een project gesteld zouden moeten worden om security & privacy by design toe te kunnen passen.