Creating ethical software, Part 1

Have you read the previous blog yet?: Building Quality Software, Part 2

De projectmanager van het Public API-team wrijft over zijn slapen. Alex kan zijn spanning bijna proeven terwijl hij zich voorbereidt om het team toe te spreken. Naast hem zit de afdelingsmanager van de E-train-afdeling voor softwareontwikkeling en -operaties. Het feit dat hij er ook bij is, maakt Alex ongemakkelijk. Dat betekent waarschijnlijk dat deze audit serieuze business is.

“Iedereen, ik heb jullie hier bij elkaar geroepen om een plan van aanpak te bespreken. Drie auditors zullen niet alleen onze hele applicatie doornemen, maar ook onze communicatiekanalen en onze processen. Als blijkt dat we tekortschieten, kunnen we onze afdelingsfinanciering verliezen of zelfs worden opgedoekt. We moeten ervoor zorgen dat dat niet gebeurt. De auditors mogen geen grote fouten vinden. Wat kunnen jullie me vertellen over onze status wat betreft beveiliging, privacy en compliance?”

Het team kijkt elkaar wat beschaamd aan. “Waarschijnlijk niet best,” zegt uiteindelijk een van de ontwikkelaars. “Het management heeft ons nooit tijd gegeven om die aspecten van de API’s te onderzoeken. Nieuwe functies en inkomsten waren belangrijker.”

“Ik bedoel, we hebben de basis wel gedaan,” vult een andere ontwikkelaar aan. “Maar je moet begrijpen dat beveiliging, privacy en ál die verschillende compliance-standaarden… dat is een compleet ander vakgebied. Je kunt niet van ons als softwareontwikkelaars verwachten dat we dat allemaal weten.”

“We worden geaudit door ons eigen bedrijf,” zegt de projectmanager. “Dus kennelijk verwachten ze wél dat we dat allemaal weten.”

“Ook al begrijpen zij het zelf niet,” zegt Alex met een frons.

“De auditors komen morgen,” vervolgt de projectmanager. “Alex, ik wil dat jij ze voorziet van alles waar ze om vragen.”

“En als ze onvermijdelijk iets vinden?” vraagt Alex.

De afdelingsmanager kucht en neemt dan eindelijk het woord. “Maak je geen zorgen, allemaal. Ik sta achter jullie. Laat de auditors gewoon hun werk doen en hun bevindingen publiceren. Ik regel het wel met het hogere management. Wat ze ook in hun rapport zetten, ik weet zeker dat ik wel iemand kan overtuigen dat het vooral betekenisloos gezeur is.”

De reikwijdte vergroten

In deel 2 en 3 van deze serie richtten we ons op het onderwerp code schrijven. Vervolgens breidden we in deel 4 en 5 de reikwijdte uit naar softwarekwaliteit. Nu vergroten we die reikwijdte opnieuw. Testbare code en kwalitatieve software zijn belangrijk, maar het feit dat iets gemakkelijk te ontwikkelen is en een hoge kwaliteit heeft, betekent nog niet dat het goed is. En met ‘goed’ bedoel ik hier het filosofische Goede. Producten van hoge kwaliteit kunnen illegaal, immoreel of zelfs nutteloos zijn. Met andere woorden: ze zijn niet per se ethisch. Het is ethische software die we zouden moeten creëren. En mijn stelling is dat als de software engineer niet verantwoordelijk is voor ethiek, niemand dat is.

Je vraagt je misschien af waarom niet iemand anders. Je zou kunnen denken dat de ethische kant van software niet de specialisatie is van de product owner of het midden- of hoger management. In deze blog bespreek ik drie onderwerpen die binnen het domein van ethiek vallen: beveiliging, privacy en compliance. Dat zijn complexe thema’s. Zou het niet beter zijn als iemand anders daar verantwoordelijk voor is? Zijn ze niet veel te tijdrovend of te verschillend van het “echte” ontwikkelwerk om door een software engineer goed te worden beheerst?

Als software engineer heb je twee opties: of je bent zelf verantwoordelijk voor beveiliging, privacy en compliance, of je delegeert die verantwoordelijkheid aan anderen. Die tweede optie klinkt aantrekkelijk, maar in de praktijk betekent het dat jij en je team tijdens elke fase van het ontwikkelproces afhankelijk worden van de input van die anderen. Naar mijn mening is het beter om beveiliging, privacy en compliance op te nemen in je eigen vaardigheidspakket.

Software engineers behoren doorgaans tot de mensen die het beste begrijpen wat hun software daadwerkelijk doet. Bovendien zijn zij vaak het meest thuis in softwareprincipes. Dat betekent dat jij, als software engineer, de meest logische persoon bent om complexe softwarevragen te beantwoorden, zoals hoe een hacker toegang zou kunnen krijgen tot data, welke persoonlijke gegevens worden opgeslagen, waar en hoe lang, of hoeveel werk het zou zijn om aan ISO 9001 te voldoen. Het veel te vaak gehoorde antwoord “Ik weet het niet en ik weet niet wie het wel weet” ondermijnt je eigen deskundigheid.

Het is dus veel werk en het brengt extra complexiteit met zich mee. Maar dat brengt ons bij de laatste vraag: waarom zouden we ons überhaupt druk maken om ethiek? Waarom het niet gewoon negeren en zien hoe het loopt? Naast het morele en juridische argument is er ook een financieel argument. Onethische software ontwikkelen brengt risico’s met zich mee. Als wangedrag wordt ontdekt, verliezen de eigenaren van de software geld, populariteit en vertrouwen. Wanneer ik hieronder beveiliging, privacy en compliance beschrijf, zie dat dan als een startpunt. Als mijn beschrijvingen niet ver genoeg gaan, verdiep je dan verder. Het is letterlijk jouw verantwoordelijkheid om dat te doen.

Houd het geheim, houd het veilig

Beveiliging is een cruciaal onderdeel van ethische softwareontwikkeling. Softwarebeveiliging draait om het beschermen van de software en haar gebruikers tegen kwaadwillige aanvallen. Maar hoe maak je software veilig? Security by design is hier het kernbegrip. Het is essentieel om vanaf het begin software te ontwerpen met beveiliging in gedachten, in plaats van dit pas achteraf toe te voegen.

Zelfs als je beveiliging al meeneemt in de ontwerpfase, zal dat niet genoeg zijn als je kennis op dit gebied beperkt is. Een veelgebruikte bron binnen softwarebeveiliging is het Open Web Application Security Project (OWASP), een non-profitorganisatie die hulpmiddelen, kennis en best practices biedt voor webapplicatiebeveiliging. OWASP stelt een enorme hoeveelheid informatie beschikbaar, waaronder lijsten van de belangrijkste beveiligingsrisico’s, gangbare mitigatiestrategieën en actuele updates. De link naar hun website (en enkele andere) zal ik delen in de laatste paragraaf van deze blog.

Concreet betekent dit dat je bij het inschatten van stories of het schrijven van een planning rekening moet houden met extra inspanning op beveiligingsvlak. Denk aan het gebruik van encryptie om gevoelige gegevens zoals wachtwoorden, creditcardinformatie en persoonlijke gegevens te beveiligen. Zorg voor validering van invoerdata om injectieaanvallen te voorkomen, waarbij aanvallers kwetsbaarheden misbruiken om schadelijke code in de software te plaatsen. Beperk toegangsrechten om ongeautoriseerde toegang tot gevoelige delen van de software te vermijden. En denk aan het inrichten van (virtuele) netwerken, firewalls en private endpoints. Al deze zaken moeten worden overwogen, gebouwd, getest en voortdurend gemonitord.

Daarnaast: hack jezelf. Of nog beter, laat anderen jou hacken. Of dat nu gebeurt via een penetratietest of via initiatieven zoals hackerone.com, het is jouw verantwoordelijkheid om je blinde vlekken te ontdekken door je applicatie doelbewust te laten aanvallen. En tot slot: blijf up-to-date. Dat geldt niet alleen voor het bijwerken van softwarepakketten en afhankelijkheden, maar ook voor het volgen van beveiligingsnieuws en recente datalekken. Je kunt niet verwachten dat je op de hoogte blijft als je daar geen tijd in investeert.

Wat je niet ziet

Privacy is een ander belangrijk onderdeel van ethische softwareontwikkeling. Privacy is het vermogen van een individu of groep om persoonlijke informatie, activiteiten en communicatie vertrouwelijk te houden en te beschermen tegen ongeautoriseerde toegang of toezicht. Het omvat het recht om te bepalen welke informatie over iemand wordt verzameld, hoe die informatie wordt gebruikt en wie er toegang toe heeft.

Privacy kan worden beschouwd als een fundamenteel mensenrecht, omdat het mensen in staat stelt autonomie te behouden, hun persoonlijke leven te beschermen en hun waardigheid te bewaren. Het stelt mensen in staat keuzes te maken zonder angst voor oordeel of inmenging, en het bevordert een gevoel van veiligheid en vertrouwen in persoonlijke relaties, instellingen en de samenleving als geheel.

Software engineers moeten ervoor zorgen dat hun software de privacy van gebruikers respecteert en voldoet aan relevante wet en regelgeving. Een belangrijke wet die betrekking heeft op privacy is de Algemene Verordening Gegevensbescherming (AVG), die de privacy van individuen binnen de Europese Unie beschermt. Software kan privacyvriendelijk worden ontworpen door de hoeveelheid verzamelde gegevens te beperken, gebruikers vooraf toestemming te laten geven voordat persoonlijke gegevens worden verzameld, en door ervoor te zorgen dat deze gegevens veilig worden opgeslagen.

Om de privacy van gebruikers te beschermen, zijn er enkele fundamentele principes die je kunt volgen. Net als bij beveiliging is het belangrijk om privacy by design toe te passen, waarbij privacyoverwegingen worden geïntegreerd in elke fase van het ontwikkelproces. Persoonsgegevens moeten bijvoorbeeld na verloop van tijd uit databases worden verwijderd zodra ze hun doel hebben gediend. Bedenk hoe je dat gaat beheren.

Daarnaast moeten er transparante en begrijpelijke privacyverklaringen worden opgesteld, waarin gebruikers worden geïnformeerd over welke gegevens worden verzameld, hoe deze worden gebruikt en welke maatregelen zijn genomen om ze te beschermen. Als er iets verandert aan deze gegevens of de verwerking ervan, houd dan versies bij zodat je altijd weet welke versie op welk moment van toepassing was.

Verder is het belangrijk om de verzameling en opslag van persoonlijke informatie te minimaliseren en alleen te bewaren wat strikt noodzakelijk is. Een goede aanpak is om data te labelen met het beoogde gebruik en de versie van de privacyverklaring die erop van toepassing is. Op die manier kunnen updates of verwijderingen van gegevens op een gecontroleerde en privacyvriendelijke manier worden geautomatiseerd.

Tot slot moeten er sterke gegevensbeschermingsmaatregelen worden toegepast, zoals encryptie en anonimisering, om ongeautoriseerde toegang of onbedoelde openbaarmaking te voorkomen. Hier komen beveiliging en privacy samen. Een applicatie kan geen privacy garanderen als ze niet veilig is.

Het staat allemaal in de handleiding

Compliance betekent in deze context twee dingen: voldoen aan wettelijke en regelgevende vereisten en het naleven van branchegerichte standaarden. Naast technische overwegingen moeten software engineers zich ook kunnen bewegen binnen het juridische landschap van softwareontwikkeling. Naleving van de geldende wetten en voorschriften is essentieel om ethische normen te handhaven. Net als bij tekortkomingen op het gebied van beveiliging en privacy kan het niet voldoen aan complianceverplichtingen leiden tot juridische gevolgen, boetes en reputatieschade.

Veel compliance-standaarden vertonen sterke overlap met beveiliging en privacy. Toch is naleving zeer brancheafhankelijk. Er bestaan specifieke normen voor de gezondheidszorg, de financiële sector, de overheid, het onderwijs, het leger en meer. Daarnaast zijn er ook normen die specifiek gelden voor softwareontwikkeling zelf. De eerste stap om compliant te worden én te blijven, is weten welke standaarden op jouw software van toepassing zijn. Maak jezelf vertrouwd met de relevante wetgeving en regelgeving die gelden binnen jouw domein, zoals privacywetgeving (bijvoorbeeld de AVG) of branchespecifieke regels (zoals HIPAA voor software in de zorgsector).

Het is absoluut noodzakelijk om samen te werken met juridische professionals of consultants die gespecialiseerd zijn in technologie en ICT-recht. Zij kunnen helpen om de juridische vereisten die op jouw software van toepassing zijn te begrijpen en juist te interpreteren. En dat is geen eenmalige actie. Software moet regelmatig worden geëvalueerd en geüpdatet om veranderingen in de wetgeving bij te houden, zodat naleving met de zich steeds ontwikkelende standaarden wordt gewaarborgd.

Vaak hoor ik software engineers op dit punt zeggen: “Hoe is dit mijn taak?” Waarop ik herhaal wat ik eerder zei: als jij niet verantwoordelijk bent, wie dan wel? Verantwoordelijk zijn betekent overigens niet dat je alles zelf moet weten of doen. Je hebt hulp nodig. Ten eerste is het belangrijk dat je het management informeert over de huidige staat van de software, welke veranderingen nodig zijn en waarom. Ten tweede is het jouw verantwoordelijkheid ervoor te zorgen dat iemand binnen de organisatie toeziet op software compliance, en dat die persoon weet op welke manier jij daarbij kunt helpen. Deze samenwerking zorgt voor de juiste middelen, kennis en bewustwording om compliant te worden en te blijven.

Tijdwinst voor jou

Om je wat motivatie en tijd te besparen, vind je hieronder een aantal nuttige links om mee te beginnen.

https://owasp.org: is de grootste non-profitorganisatie die zich richt op softwarebeveiliging.
https://www.wired.com: is een van de meest centrale beveiligingsplatforms op het internet.
https://thehackernews.com: biedt nieuws en updates over de wereld van informatiebeveiliging.
https://www.troyhunt.com: is de blog van Microsoft’s MVP-beveiligingsexpert Troy Hunt.
https://iapp.org: is de International Association of Privacy Professionals, vergelijkbaar met OWASP maar dan gericht op privacy in plaats van beveiliging.

Daarnaast geef ik je een aantal afkortingen en standaarden die relevant kunnen zijn. Als je er één of meer niet kent, zoek ze dan op en informeer binnen je organisatie of er specifieke normen gelden voor jouw software.

ISO/IEC 27001: richt zich op informatieveiligheidsmanagementsystemen en biedt richtlijnen voor het beschermen van gevoelige informatie.
Payment Card Industry Data Security Standard (PCI DSS): is een set beveiligingsnormen die ervoor zorgen dat bedrijven die creditcardgegevens verwerken, opslaan of verzenden dit doen in een veilige omgeving.
General Data Protection Regulation (GDPR / AVG): is een EU-verordening die de bescherming van persoonsgegevens en privacy van EU-burgers regelt. Deze geldt voor alle organisaties die persoonlijke data van EU-ingezetenen verwerken.
Health Insurance Portability and Accountability Act (HIPAA): stelt normen voor de bescherming van gevoelige patiëntgegevens in de zorg. Zorginstellingen moeten beveiligingsmaatregelen nemen om vertrouwelijkheid, integriteit en beschikbaarheid te waarborgen.
ISO/IEC 20000: is een standaard voor IT-servicemanagement die richtlijnen biedt voor het opzetten en onderhouden van een effectief servicemanagementsysteem.
System and Organization Controls (SOC) 2: is een auditstandaard die zich richt op beveiliging, beschikbaarheid, verwerkingsintegriteit, vertrouwelijkheid en privacy van systemen van dienstverleners. Deze wordt veel gebruikt voor cloudproviders en organisaties die gevoelige data verwerken.
ISO 9001: is een kwaliteitsmanagementsysteemstandaard met criteria voor het implementeren en onderhouden van effectieve kwaliteitsbeheerprocessen.
Web Content Accessibility Guidelines (WCAG): bieden richtlijnen voor het creëren van toegankelijke webinhoud, zodat websites en digitale diensten bruikbaar zijn voor mensen met een beperking.

Tot slot, als je iets nieuws leert, houd het dan niet voor jezelf. Deel je kennis en moedig anderen aan om samen met jou te streven naar meer kennis en ethiek in softwareontwikkeling.

Een cultuur van leren

Een van de auditors gaat naast Alex zitten. “We gaan zo de NIST-checklist doornemen, gevolgd door de standaard ISO 9001, een pentest en een aantal controles met betrekking tot PCI DDS. Heb je wat API-documentatie beschikbaar, of misschien zelfs een Postman-collectie voor ons?”

Alex aarzelt en voelt zich een beetje overweldigd. Na een diepe ademhaling besluit hij eerlijk te zijn. “Luister, ik wil helpen en ik weet het een en ander, maar ik ben bang dat ik de helft van wat jullie controleren niet zal begrijpen. Ik wilde dat eigenlijk niet zeggen, omdat ik bang ben dat jullie denken dat ik geen idee heb wat ik doe als software engineer als ik niet eens begrijp waar jullie het over hebben. Maar ik vind het belangrijk om het wel te begrijpen, dus ik wil vragen of jullie het iets rustiger aan kunnen doen.”

De tweede auditor kijkt op van zijn formulieren. “Maak je geen zorgen. We zijn hier om je te ondersteunen. Laten we beginnen met de basis en daarna de details ingaan. We begeleiden je stap voor stap. Mijn naam is trouwens Riley.”

Gesterkt door hun aanmoediging begint Alex steeds meer vragen te stellen. Het blijkt niet verrassend dat hij behoorlijke kennisgaten heeft op het gebied van beveiliging, privacy en vooral compliance voor de publieke API’s. Wat wel verrassend is, is dat het Public API-team intuïtief al veel dingen goed heeft gedaan en dat de meeste tekortkomingen in de nabije toekomst eenvoudig kunnen worden opgelost. Met elke dag groeit Alex’ enthousiasme en hij voelt zich bevoorrecht om van de auditors te mogen leren. Vooral Riley heeft een talent om complexe concepten helder uit te leggen.

Naarmate de audits vorderen, beseft Alex dat ze een kans hebben om een blijvende impact te maken op de bedrijfscultuur van E-train. “Voordat we begonnen, zag het Public API-team jullie als tegenstanders. Ik weet zeker dat ze daar niet uniek in zijn. Ik denk dat het waardevol zou zijn als het hele bedrijf het belang van beveiliging, privacy en compliance beter zou begrijpen. Zouden we een workshop kunnen organiseren om iedereen hierover te informeren?”

Riley denkt even na en glimlacht dan. “Zeker. Laten we samen een workshop ontwerpen waarin we de basis behandelen. Jouw enthousiasme en inzet zullen anderen inspireren om deze aspecten ook prioriteit te geven in hun werk.”

Enkele weken later wordt het auditrapport gepubliceerd. Er staan behoorlijk wat bevindingen in, en de termijn om ze op te lossen is kort voordat de financiering mogelijk wordt stopgezet. Toch vraagt Alex de afdelingsmanager om het belang van de bevindingen niet te bagatelliseren tegenover het hogere management. Hij overhandigt een begeleidend document waarin hij beschrijft hoe de problemen kunnen worden opgelost, inclusief globale schattingen. “Het is duidelijk wat er moet gebeuren,” zegt Alex. “En nog belangrijker, het is onze verantwoordelijkheid om het te doen. We hadden dit vanaf het begin al zo moeten aanpakken.”

De afdelingsmanager zucht. “Weet je het zeker? Hoe denkt de rest van het team hierover?”

“Ik weet het nog niet. We bespreken het in de volgende Sprint Retrospective.”

De afdelingsmanager kijkt Alex even zwijgend aan, schudt zijn hoofd en stopt het rapport in zijn aktetas. Daarna geeft hij het begeleidende document terug aan Alex. “Het enige wat ik kan zeggen is: veel succes. Ik denk niet dat dit je erg populair zal maken binnen het team.”

Alex knikt. “Waarschijnlijk niet, nee.”