Er was een tijd dat de wetgever optimistisch was over technologie. Inmiddels sijpelt in regelgeving door dat er ook risico’s zijn. Maar hoe maak je iets dat zo ingewikkeld is als een risico-inschatting nu weer eenvoudig? Door te kijken hoe falen eigenlijk werkt.
Nog niet eens zo lang geleden zagen bestuurders technologie als oplossing voor ieder probleem ongeacht de vraag. Misdaad op straat? Camerabewaking. Overlast veroorzakende hangjongeren? Een etnisch ingegeven database. Lastige kinderen? Een elektronisch kinddossier. Witwassen? Een database met transacties. Laat thuis na verkiezingen? Een stemcomputer. Verkiezingen? Een stemcomputer. Volle kantoorgebouwen? Flexwerken met mobiele verbindingen. Terrorisme? Vingerafdrukken in een paspoort, databases met reisgegevens, tappen internetverbindingen en ga zo maar door.
De werking van sommige technieken is hoopvol. Alleen wordt langzaam maar zeker ook steeds duidelijker dat technologie niet altijd zo mooi werkt als voorgespiegeld. Er ontstaan nieuwe beveiligingsproblemen. Rechters maken technologie soms ondergeschikt aan mensenrechten. Persoonsgegevens kunnen in verkeerde handen komen. De afhankelijkheid brengt kwetsbaarheden met zich mee. Projecten mislukken vaak of eindigen (ver) boven budget. En soms treden er simpelweg onverwachte neveneffecten op die we bij nader inzien niet wenselijk vinden.
Denk aan risico’s
Ook de politiek ziet inmiddels dat ‘vrijheid-blijheid’ soms ongewenste effecten heeft en dat technologie verantwoord en met beleid moet worden ingezet. En zo komt er meer en meer regelgeving die vraagt om niet alleen naar de lusten te kijken, maar ook oog te krijgen voor de lasten, lees: gevaren. Over technologie an sich kun je zelden zeggen dat iets goed of fout is. Het hangt van de situatie af. Een ‘dit mag wel of dat mag niet’ kunnen we dan ook nagenoeg nooit in wetgeving zetten zonder onverwachte gevolgen. Dat besef komt dan ook langzaam terug in de wetgeving die vooral in de EU wordt opgesteld. In de Algemene Verordening Gegevensbescherming (AVG) komt daarom in wettekst en preambule maar liefst 70 keer de term ‘risico’ voor. Van organisaties verwacht de wetgever een inventarisatie: welke risico’s zijn er; waar horen ze thuis; zijn ze acceptabel; hoe kunnen ze worden verkleind en hoe worden ze bewaakt? Kortom, de afvinklijstjes gaan in de ban en de situatie bepaalt of iets wel of niet mag. Dat sluit beter aan bij ICT en de realiteit van alle dag. Het gevolg is wel dat er van ons een actieve houding wordt verwacht om elke dag met compliance bezig te zijn.
Als in november 2018 de nieuwe Wet beveiliging netwerk en informatiesystemen (Wbni) in werking treedt, komen er nog meer redenen bij om te kijken naar risico’s. Want waar het eerst ging om het verwerken van persoonsgegevens, staan nu opeens alle computersystemen ter discussie. Niet iedereen is zich hiervan bewust, maar veel organisaties vallen onder de werking van de wet. Soms zal de overheid bedrijven op de hoogte stellen met een brief, maar in veel gevallen moeten organisaties op eigen kracht weten wat hun plichten zijn. Ook wetgeving die de komende jaren van kracht zal worden, hebben allemaal dezelfde focus: kijk naar het risico.
Concreet worden
Met de opdracht om risico-inschattingen te maken, doemen meteen twee problemen op. Het is bepaald niet handig om te werken met de gouden regel die stelt: een risico is het product van de kans dat een gevaar optreedt, maal het mogelijke effect (eventueel vermenigvuldigd met de gevoeligheid). Dit maakt het voor mensen heel lastig om te denken in risico’s, deze goed te zien en zowel juist als volledig te benoemen. Het is nu eenmaal iets waar we niet sterk in zijn. Daarnaast is het principe van ‘kans’ enorm ingewikkeld. De theorie zegt wel dat we een kwantitatieve (op getallen gebaseerde) analyse moeten uitvoeren, maar in de praktijk komen we in de ICT niet veel verder dan een goede gok. Ook is het lastig aan te geven welk effect een maatregel heeft op het geïdentificeerde risico. Het blijft nattevingerwerk. Om op deze manier compliant te zijn is een ware nachtmerrie, waarbij vaak de vraag zal opkomen of dit allemaal echt gaat helpen.
Risico’s weer simpel maken
Het kijken naar risico’s betekent niet dat de traditionele aanpak de enige is. Het Europees beveiligingsbureau ENISA heeft een nieuwe standaard voor het maken van risico-inschattingen omhelsd. De Failure Mode Effect Analyses, kortweg FMEA, benadert de problematiek door niet te kijken naar een risico, maar naar realistische manieren waarop iets mis kan gaan (‘Hoe zou dit allemaal kunnen falen?’). Deze zogenaamde foutmodus is eenvoudiger in te vullen dan een vaag containerbegrip als risico. Bovendien kunnen mensen in het werkveld zelf actief betrokken zijn bij de inschatting, waardoor ze bewust worden en onderdeel van de oplossing zijn. Zie het kader ‘FMEA en de koffiepot’ voor nadere toelichting van de methode.
Geen papieren tijger
De aanpak maakt risico-inschattingen eenvoudiger, sneller uit te voeren en levert veel concretere handelswijzen op. Bijkomend voordeel is dat per maatregel goed kan worden aangegeven welke invloed deze heeft op een foutmodus. Zo zijn zinvolle en minder zinvolle stappen snel te zien en hebben we meteen deugdelijke documentatie. We kleuren wetgeving als de AVG en Wbni handig in, zonder dat het een papieren tijger wordt maar juist iets waar we mee aan de slag kunnen. Het mooie is dat de ENISA de methodiek heeft omhelsd en daarmee is het een internationale standaard van een Europees erkend bureau. De Wbni zegt dat we die moeten adopteren (als we niets anders doen). Dat maakt de overweging om complexe methodieken te vervangen of aan te vullen door iets simpelers – al was het maar als second opinion – een zinvolle exercitie die echt help gevaren goed in beeld te krijgen.
FMEA en de koffiepot
Failure Modes and Effects Analysis (FMEA) vindt zijn oorsprong bij The National Aeronautics and Space Administration, een omgeving waar het voorkomen van fouten extreem belangrijk is. Het is een systeem voor het analyseren van het ontwerp van een product- of servicesysteem om potentiële fouten te identificeren, en vervolgens stappen te ondernemen om deze tegen te gaan, of op zijn minst de risico’s hierop te minimaliseren. Het FMEA proces begint bij het identificeren van ‘failure modes’, de manier waarop een product, service of proces zou kunnen falen. Bij elke stap van een service – beginnend bij de input tot en met de aan de klant geleverde output – vraagt een projectteam zich af: “Wat zou er hier fout kunnen gaan?”
Als voorbeeld nemen het proces van de levering van koffie bij een stopplaats voor vrachtwagens. Een input is ‘schone koffiepot’. Hier kan al veel misgaan waardoor de koffiepot niet schoon is. Bij het vullen van het koffiezetapparaat met water, en de koffie in het filter, kunnen bijvoorbeeld verkeerde hoeveelheden worden gebruikt. De gewenste uitkomst van het proces, een hete kop goede koffie, kan vervolgens nog door allerlei andere elementen worden verstoord. Natuurlijk is geen enkele fout hetzelfde. Een extreem slappe bak geserveerd krijgen, is erger dan wanneer de koffie niet helemaal heet meer is.
Een belangrijk element van FMEA is het analyseren van de drie karakteristieken van fouten:
- Hoe ernstig ze zijn (Severity)
- Hoe vaak ze voorkomen (Frequency of occurrance)
- Hoe waarschijnlijk het is dat ze worden opgemerkt (Likelyhood of detection)
Normaliter waardeert elk projectteam de ‘failure modes’ in elk van deze drie gebieden op een vastgestelde schaal (van 1 tot 10 of van 1 tot 5) en volgens eigen vaste en vooraf gedefinieerde criteria. Op die manier is de meetlat geobjectiveerd. Vervolgens berekenen zij het Risk Priority Number (RPN): RPN = (Severity) x (Frequency of occurrence) x (Likelihood of detection). De hoogst gewaardeerde failure modes zijn de fouten die zich vaakst voor doen (van zeer zelden tot zeer regelmatig), ernstig zijn (van niet ernstig tot catastrofaal). Tot slot wordt bepaald hoe goed kan worden gedetecteerd dat een foutmodus aan het optreden is. Hierbij scoren fouten die waarschijnlijk niet worden herkend het hoogst. Bij het compleet maken van de analyses wordt gekeken naar de potentiële oorzaken van de fout; het identificeren van manieren om het probleem te vinden; aanbevelingsacties ontwikkelen; verantwoordelijkheden toekennen om het proces te monitoren en actie ondernemen als er klachten zijn. Het is meteen duidelijk waar we wat mee moeten doen en wat wel even mag blijven liggen. Daarnaast is duidelijk welke risico’s door een organisatie erkend worden en welke niet.