Is het al moeilijk om een goede business case te maken voor een ict-investering, voor een investering in ict ten behoeve van beveiliging is het als het kan nog moeilijker. Dit komt vooral doordat we het schrijven van een business case niet serieus nemen. Zelden wordt een business case achteraf ook geëvalueerd, wat niet bepaald aanspoort om vooraf je feiten goed te verkennen en de argumenten helder te formuleren.
Bij een business case voor de implementatie van een beveiligingsproduct hebben we te maken met factoren dat we met dit product beveiligingsproblemen gaan voorkomen. Hoeveel is dat waard? Zeg het maar. Een ander argument is wat breder op ict van toepassing: met dit product gaan we de door automatisering beheerskosten met X procent verminderen. Operationeel beheer is vaak een aaneenschakeling van activiteiten volgens strak stramien en het nalopen van checklisten. Typisch activiteiten die geestdodend zijn en eenvoudig grotendeels geautomatiseerd kunnen worden.
Dit heeft echter een probleem: Wie gaat de beheerders vertellen dat ze X procent minder gaan werken, of dat X procent van hun collega's na implementatie op straat staat? Vroeger, in betere economische tijden, kon je dit nog koppelen aan het argument om even wat minder te groeien. Nu kun je dat wel vergeten, het wordt een slecht-nieuws bericht en de beveiligingsafdeling wordt er op aangekeken. Dus als je deze route wilt bewandelen zul je gedegen werk moeten doen om je geldschieter enthousiast te maken. Dit zal meestal de directeur ict zijn. Laat hem dan maar het slechte nieuws verder vertellen.
De business case kun je beter proberen te halen uit het verminderen van de kosten voor andere producten of diensten. Als je een product inzet wat de hoeveelheid online opslag met X procent verminderd is de enige die wellicht niet blij is de storage-leverancier. De ontvanger van het slechte nieuws komt zo iets verder van je af te liggen, maar optimaal is het nog niet.
Het mooiste is als je de business case niet hoeft te verantwoorden vanuit een vermindering aan ict-kosten, maar juist kan bekostigen uit meer opbrengsten voor ict, betaald door de business. Dit werkt alleen maar als de business ook naar rato betaalt voor ict-diensten en vergt van ict om te kunnen meedenken met de business en over een goede business-it alignment. Niet alleen weten wat je doet voor je klanten in de business, maar ook weten wat het je klanten oplevert. Een veelgebruikt argument bij beveiligingsinvesteringen is dat het nodig is om compliant te zijn, te voldoen aan een wet of andere norm. Wanneer je dit gebruikt kun je maar beter wel begrijpen waarom dat zo is.
Het kan bijvoorbeeld best zo zijn dat goed gebruikersbeheer in Active Directory je helpt om SOx (Sarbanes-Oxley) compliant te worden, maar de verantwoording daarvan vergt wel even uitleg of een juiste referentie naar een accountantsrapport voordat degene die het geld ter beschikking moet stellen begrijpt dat dit een effectieve investering is. De effectiviteit wordt door de business gemeten in termen van wat er gebeurt als ze het niet doen. Ook dat moet je meenemen in de business case.
Het is prachtig dat er in de zorgsector een beveiligingsnorm is, de NEN7510, maar zolang de waakhond niet optreedt tegen overschrijdingen van deze norm is het animo bij de zorgsector nog niet bijster groot om serieus naar deze norm te kijken.
Vergelijk het maar met het kopen van een auto. Als je een goed rijdende Golf hebt van een paar jaar oud krijg je niet zomaar geld los om een Mercedes te kopen omdat hij lekker rijdt. Maar dat is precies hoe veel business cases voor ict-beveiligingsinvesteringen in elkaar lijken te zitten. Je komt veel verder met argumenten van vermindering aan onderhoudskosten en verhoging van de bedrijfszekerheid na aanschaf van de nieuwe auto.
Het grote probleem met businesscases voor ICT security is dat de risico’s lastig te kwantificeren zijn. Beslissers hebben dan ook vaak een houding van “laat er eerst maar eens daadwerkelijk iets fout gaan voordat ik er geld aan ga uitgeven” en dat is op zich niet onbegrijpelijk.
Er zijn echter ontwikkelingen gaande binnen de EU die een dergelijke afwachtende houding ten opzichte van ICT security kunnen veranderen. Lees bijvoorbeeld eens :
http://www.enisa.europa.eu/act/it/dbn/
Het is niet onwaarschijnlijk dat Data Breach notification wetgeving ook buiten de telecommmunicatiesector gaat gelden. Security incidenten kunnen daardoor meetbare en kwantificeerbare gevolgen hebben. Zie bijv. rapporten als “The Cost of A Data Breach” van het Ponemon institute ( http://www.ponemon.org/news-2/23 ). Persoonlijk verwacht ik dan ook dat binnen ICT Security management het accent langzamerhand gaat verschuiven van compliancy (controle op naleving van voorschriften) naar daadwerkelijke security (het dichten van kwetsbaarheden).
Zeg het maar… Accountancyfirma’s passen doorgaans de formule kans van optreden maal schade toe. Op die manier ontstaan vergelijkbare getallen met een investering in potentiële maatregelen. Voor de kwalitatieve onderbouwing vormt (toekomstige) wetgeving nog steeds de belangrijkste driver.
“laat er eerst maar eens daadwerkelijk iets fout gaan voordat ik er geld aan ga uitgeven” is een begrijpelijke houding. Hiervoor hoeft niet zelf schade geleden te worden, maar kan ook naar de buurman gekeken worden. Notification wetgeving werkt als een boete: je gaat niet per se je kwetsbaarheden aanpakken, maar je gaat je ook richten op de pakkans verminderen. Om bij de auto te blijven: mensen rijden nog steeds te hard, alleen niet bij de camera’s.
Een heel optellijstje van kans maal schade wordt niet altijd even serieus genomen. Soms is het veel te gedetailleerd, soms is het veel te veel naar boven afgerond. Uiteindelijk moet je iets met de onzekerheden die er overblijven. Naar boven afronden blijft het meest veilig. Business managers weten dat en corrigeren naar beneden bij.