Wat doe je als de configuratie van een Oracle cluster per ongeluk fouten bevat waardoor de hele omgeving raar gaat doen? Wat als er een change plaatsvindt op een ica-bestandje van je Citrix omgeving en half India, Zuid Afrika en een deel van Polen kan niet meer inloggen? Wat als iemand per ongeluk een groot deel van Active Directory weggooit? En RACF data op het mainframe? De kans dat dat gebeurt is niet heel erg groot, niet in de laatste plaats omdat we allerlei beschermingen hebben ingebouwd om die kans zo klein mogelijk te maken. Maar de kans is er.

Veel van onze bescherming is gebaseerd op redundantie. Alles wat we belangrijk vinden hebben we minimaal dubbel uitgevoerd. Maar toch kan er nog van alles stuk. Oracle clusters, volledig redundant, maar er zit een relatief klein elementje in wat niet stuk mag gaan, want anders doet ie het niet meer. Dat is trouwens een eigenschap van de meeste cluster technieken: een centraal stuur-element die - als je goed kijkt - een Single Point of Failure vormt. Een SPoF... en als dat deeltje stuk is, dan ben je het haasje. Gebeurt niet vaak, maar de kans daarop is niet nul.

Dat geldt dus niet alleen voor Oracle, dat geldt ook voor VMWare ESX, Loadbalancers, Distrinuted filesystems, Parallel Sysplex in het mainframe, om er maar een paar te noemen.... als je echt goed kijkt zit er altijd een zwak schakeltje in. En ook Cloud gaat dat niet oplossen. Het is namelijk lastig op te lossen met techniek... het is te duur.

Major incidenten van de afgelopen jaren laten ook zien dat er veel stuk kan. En dat wordt vaak veroorzaakt door nare, en soms zelfs zeer kleine verstoringen. Kun je die verstoringen wel voorkomen? We hebben wel aangetoond dat dat niet altijd kan. Vertrouwen we misschien teveel op de techniek? En is meer techniek wel echt de oplossing? Zouden we ons dan misschien beter kunnen richten op het beperken van de impact ervan? Dat betekent als er iets mis gaat, hoe kunnen we dat dan sneller zien, sneller isoleren en sneller corrigeren? Zit het niet gewoon tussen de oren? Geen techniek, maar gedrag?

Wat als iemand het opzettelijk doet? Daar hebben we een mooie term voor bedacht: een destructive cyber scenario. Wat dan? Per ongeluk kunnen we al heel veel, dat laten de major incidenten wel zien. Maar wat als iemand opzettelijk dat ica-bestandje weg gooit? Active Directory? RACF data? Platform configuraties? Door iemand die je organisatie kwaad wil doen, puur sabotage? Dat kan zowel intern als extern gebeuren... d’r is ook eigenlijk helemaal geen intern en extern meer, alles hangt aan elkaar. En dat is niet erg, daar gaat de IT wereld nu eenmaal naartoe. Maar juist dan moet je plannen maken. Heb je alles bij de hand wanneer zo iets gebeurt? Weet je wat je moet doen? En hoe snel kun je dat? Uren, dagen, weken? Negeren is geen strategie.

Je kunt altijd een Resilience Roulette doen, waarmee je kunt aantonen of je goed voorbereid bent. Maar doe je 'm dan ook? Of is er altijd wel iets urgenter? Ga je je belangrijkste systemen onderwerpen aan een Resilience check? Of zeg je "Belangrijk, maar niet nu”, “we zijn net bezig met de migratie naar Azure”, “Ja, dat moeten we echt een keertje doen; we komen erop terug”. Om vervolgens weer over te gaan tot de wanorde van de dag.

We zeggen dat Disaster Recovery, Cyber Recovery... dat IT Resilience belangrijk is. Ik hoor namelijk erg vaak dat het echt belangrijk is en dat ik er vooral mee moet doorgaan.

IT Resilience lijkt dus belangrijk. Maar wanneer wordt het urgent?

Richard Bliek