De kracht van de ja-nou-en-vraag

Het doen van een risicoanalyse is geen rocket science, maar je moet het wel een paar keer gedaan hebben om het geheel goed te snappen. Een van de belangrijkste uitdagingen daarbij is het goed beschrijven van een risico. Het inzichtelijk maken van risico's is immers het doel van een risicoanalyse. Dat dat nog niet zo eenvoudig is, blijkt uit de vele risicoanalyserapporten en risicolijsten die ik heb mogen inzien.

Een goede manier om een risico te beschrijven is bowtie. Het belangrijkste daarin is de risicogebeurtenis. Dat is hetgeen we willen voorkomen. Een risicogebeurtenis kent een of meerdere oorzaken en kan leiden tot een of meerdere gevolgen. De oorzaken (het kans-element van een risico) ga je tegen door middel van preventieve maatregelen. De risicogebeurtenis laat je niet onopgemerkt voorbij gaan door middel van detectieve maatregelen. De gevolgen (het impact-element van een risico) ga je tegen met behulp van repressieve maatregelen. Dit is grafisch weergegeven in onderstaand schema. Een oorzaak kan daarnaast een andere oorzaak hebben en een gevolg kan weer leiden tot een ander gevolg. Echter, deze mogelijke verdere vertakkingen zijn in het onderstaande schema niet weergegeven.

Wat ik vaak mis zie gaan, is dat niet een risicogebeurtenis zelf, maar een mogelijke oorzaak als risicogebeurtenis wordt opgeschreven. Het probleem daarbij is dat je daardoor mogelijk minder goed zicht hebt op het feitelijke risico. Daarnaast maakt dat het toepassen van het breed-geaccepteerde bowtie lastig, wat tot onduidelijkheden kan leiden bij de risicobeheersing in bijvoorbeeld een ketensamenwerking.

Neem bijvoorbeeld het niet goed werken van de backupvoorziening. Die ben ik meerdere malen in een risicolijst tegengekomen. Een backupvoorziening is een maatregel voor een risico waarbij je mogelijk informatie kwijtraakt, zoals een ransomware-aanval. Een niet goed werkende backupvoorziening is dus geen risico, het is een slecht functionerende maatregel tegen een ransomware-aanval. Door een slecht functionerende backupvoorziening als risicogebeurtenis te kiezen, heb je mogelijk minder goed zicht op het risico van een mogelijke ransomware-aanval. Wat betreft het toepassen van bowtie, als je een slecht functionerende backupvoorziening als risicogebeurtenis gaat behandelen, ga je daar dan detectieve maatregelen op nemen? Dat lijkt me onzinnig, want je weet immers al dat die niet goed werkt. Ga je daarnaast repressieve maatregelen nemen op de gevolgen van de slecht functionerende backupvoorziening? Een van de gevolgen is dat bij het kwijtraken van informatie, deze niet hersteld kunnen worden. Wil je het herstellen van informatie tegengaan? Dat lijkt me ook niet helemaal de bedoeling.

Een oorzaak als risicogebeurtenis opschrijven kan je voorkomen door tijdens een risicoanalyse jezelf een simpele vraag te stellen, namelijk de vraag “Ja, nou en?”. Bij het antwoord op die vraag stel je jezelf wederom die vraag. Dit doe je net zolang, totdat het antwoord aangeeft dat informatie niet meer beschikbaar, niet meer integer of niet meer vertrouwelijk is. Het vorige antwoord is dan je risicogebeurtenis. Het toepassen van de ja-nou-en-vraag werkt als volgt:

"De backupvoorziening werkt niet." Ja, nou en? "Nou, dan kunnen we systemen niet herstellen." Ja, nou en? "Nou, dan zijn de we klos na bijvoorbeeld een ransomware-aanval." Ja, nou en? "Nou, dan zijn we bij zo'n aanval informatie definitief kwijt!" (informatie is niet meer beschikbaar)

Hieruit volgt dat de ransomware-aanval het daadwerkelijke risico is. Een ander voorbeeld dat ik vaak tegenkom in risicolijsten is het hebben van legacy-systemen.

“We hebben de nodige legacy-sysytemen in ons netwerk.” Ja, nou en? "Nou, als daar een kwetsbaarheid in blijkt te zitten, dan kunnen we die niet patchen." Ja, nou en? "Nou, dan kunnen aanvallers zo'n kwetsbaarheid misbruiken om in te breken." Ja, nou en? "Nou, dan kunnen ze bij de gevoelige informatie op die systemen!" (informatie is niet meer vertrouwelijk)

Een inbraak op een systeem met gevoelige informatie is dus de risicogebeurtenis, waarbij het niet meer kunnen patchen van kwetsbaarheden omdat software niet meer ondersteund wordt, de kans daarop vergroot. Een legacy systeem vormt dus een oorzaak van een risico. De proef op de som bij beide voorbeelden is dat op de daadwerkelijke risicogebeurtenissen (ransomware-aanval en inbraak op systeem) zinnige detectieve maatregelen te bedenken zijn.