Auteur:

Het veilig opslaan van reservekopieen

  door

Nou, nog een keer over de reservekopieen dan voordat we dat verder met rust zullen laten. We hebben de eisen gesteld voor de beschikbaarheid, exclusiviteit en integriteit. We hebben keuzes gemaakt en we hebben getest of de gegevens ook echt benaderbaar zijn. Vandaag stellen we ons de vraag:

Worden de reservekopieen veilig opgeslagen (eventuele externe locatie)?

Waar slaan we de reservekopieen eigenlijk op? Doen we dat op tapes in ons eigen pand of kiezen we ervoor de tapes naar een ander pand te brengen? Hebben we zelf geen tapes en laten we de back-ups via internet overbrengen naar een extern datacenter en wie kunnen er dan eigenlijk allemaal bij? Oh ja, ik weet het, er zijn andere manieren dan tapes, maar het spreekt wel lekker tot de verbeelding, toch?

Laten we eerst ingaan op het opslaan van de reservekopieën in ons eigen pand. Dat is een optie, maar wat als ons hele pand afbrand? Hebben we dan nog ergens de gegevens beschikbaar? Hoe veilig is ons pand eigenlijk en welke incidenten vinden daar zoal plaats? Staat de back-up server op de kapstok bij de ingang (geloof me, ik heb het gezien) of kiezen we voor een veilig serverhok dat netjes op slot kan en waar de airco ervoor zorgt dat het niet al te warm wordt? Wie hebben er dan allemaal toegang tot de serverruimte en hebben zij allemaal die toegangsrechten wel nodig? Ook hier weer een groot aantal vragen die we onszelf kunnen stellen. Misschien kies je voor de, ogenschijnlijk, veiligere optie en host je de back-ups extern.

Maar ook in dat geval komen er een aantal vragen om de hoek kijken. Hebben we de juiste Service Level Agreements opgesteld en houdt de leverancier zich daaraan? Hoe betrouwbaar is die leverancier eigenlijk en wie is eigenaar van de servers en data? Staat de informatie in Nederland of ergens in het buitenland? Welke medewerkers bij de leverancier kunnen eigenlijk bij onze data? Er wordt nog wel eens gewerkt met een algemeen “Admin-account”, maar is nu nog te traceren welke medewerker er op welk moment dat account gebruikt heeft? Zo zie je maar, ook hier een aantal (en nog vele malen meer) vragen waar we toch even bij stil moeten staan.

Het doel blijft zo snel mogelijk weer over de data kunnen beschikken op het moment dat dat nodig is. Afhankelijk van de aard van de organisatie kunnen we ervoor kiezen onze data veilig op te slaan in ons eigen pand, op een andere locatie of extern onder te brengen bij een specialist. Hebben we te maken met echt spannende data die voor het voortbestaan van onze organisatie cruciaal is, dan kan het ook zomaar zijn dat we voor een combinatie kiezen.

Alles voor het voortbestaan van onze organisatie, toch? Ja, maar ook in dit geval moeten de kosten tegen de baten opwegen en met logisch nadenken komen we al een heel eind. Testen we vervolgens of het geplande ook nog werkt dan bieden we toch een bepaalde mate van zekerheid. Vinden we dat nog niet genoeg? Dan zullen we aanvullende maatregelen moeten nemen.

Het testen van reservekopieen

  door

We hebben het van de week ook al even aangehaald, maar vandaag gaan we er iets verder op in. Niet op de techniek, maar de gedachte er achter: Het testen van reservekopieen.

Logisch dan natuurlijk dat de formele vraag als volgt is:

Worden de reservekopieen getest of de gegevens benaderbaar zijn?

Gisteren schreven we het ook al. We maken geen reservekopieen om maar over kopietjes te beschikken of omdat het zo nodig moet van de Code voor Informatiebeveiliging. Nee, we maken ze om na een incident nog over de voor ons waardevolle informatie te kunnen beschikken. Daarom is het ook van belang om te testen of de reservekopien ook echt aan onze eisen voldoen.

Bevat de reservekopie inderdaad de voor ons belangrijke gegevens en zijn die gegevens nog benaderbaar? Als de gegevens uit een nogal exotisch programma komen is het ook van belang om te kijken naar de back-up van dat exotische programma. Anders beschikken we straks wel over de gegevens maar niet over het programma om die gegevens te kunnen lezen.

Ok, ok, maar jullie hebben de reservekopieen extern gehost, zoals dat zo mooi heet. Iedere nacht worden de gewijzigde gegevens weggeschreven naar onze leverancier. Hartstikke goed, maar weten we ook zeker dat we de gegevens weer snel genoeg terug kunnen halen? Hoe lang doen we er straks over om terabytes aan data terug te zetten? Kan dat binnen de tijd die we gesteld hebben voor onze kritische processen? En wat doen we als de internetverbinding door hetzelfde incident getroffen is? Kunnen we dan ook nog op tijd bij de data komen?

Ook moeten we goed kijken naar de kritische processen die als eerste de lucht weer in moeten. We moeten dus keuzes maken in de data die we als eerst terug zetten en de data die minder van belang is en wel even kan wachten. Al die terabytes aan informatie kunnen immers niet op hetzelfde moment over onze interverbinding en komen achter elkaar binnen.

Willen we er echt zeker van zijn dat het allemaal werkt? Ja, dan zullen we toch echt moeten gaan testen. Dat kan een papieren test zijn maar ook een test waarbij we de data echt terug gaan zetten om te kijken wat er gebeurt. De lessen die we daaruit kunnen trekken verwerken we weer zodat we onze aanpak van reservekopieen continu kunnen verbeteren. Je raadt het al: om zekerheid te hebben moeten we vaker testen en misschien zelfs noodscenario’s achter de hand hebben voor het geval dat.

Het maken van reservekopieen

  door

Nu we gekeken hebben naar de eisen die we stellen aan de reservekopieen moeten we ook gaan kijken waar we exact back-ups van willen hebben, wanneer we ze maken en wie ze dan maakt. Kortom, de vraag die relevant is voor vandaag is:

Worden de reservekopieen conform de eisen gemaakt?

We maken reservekopieen niet omdat we zo graag kopietjes willen hebben of omdat het van de Code voor Informatiebeveiliging moet. We maken de reservekopieen zodat we na verlies van informatie snel weer over de gegevens kunnen beschikken en snel weer productie kunnen draaien. Daarbij is de term “snel” relatief en hangt helemaal af van de eisen die we stellen aan de informatievoorziening, de informatiesystemen en dus de reservekopieen.

Als het goed is hebben we al bepaald welke eisen we stellen. Nu is het ook zaak om te kijken waar we dan exact reservekopieen van maken. Doen we dat van de data of ook van bijvoorbeeld de besturingssystemen? Hoe vaak maken we die kopieen eigenlijk en is dat niet teveel of te weinig? Hoelang kunnen we zonder informatie en hoeveel informatie mogen we kwijt zijn na een incident?

Allemaal vragen waar we rekening mee moeten houden. Vaak horen we managers zeggen dat informatiebeveiliging voor hun organisatie niet zo belangrijk is omdat ze toch geen geheime informatie hebben. Op zich kan daar best een kern van waarheid in zitten, maar wij weten inmiddels dat het niet alleen draait om de exclusiviteit maar juist ook om de beschikbaarheid en integriteit.

Iedere organisatie heeft er last van als de financiele administratie definitief verloren gaat (nog los van wat de belastingdienst daarvan vindt), wie moet welke factuur nog betalen en wie moeten wij eigenlijk nog geld geven? Als de CRM-database (ons klantenbestand inclusief historie) onbruikbaar raakt dan weten we ook niet goed meer wat nu de laatste status is, wie heeft er recent nog wat besteld en hebben we dat al geleverd?

Als we onze organisatie serieus nemen dan kijken we dus iets verder dan de geheime gegevens alleen. Veel organisaties zullen inderdaad geen staatsgeheimen hebben, maar toch beschikken ze over vertrouwelijke gegevens waarvan we liever niet hebben dat de concurrent ze onder ogen krijgt. Iedere organisatie heeft administraties die op zijn minst tot last worden als ze niet meer beschikbaar zijn of als de gegevens daarin niet meer correct zijn.

Natuurlijk moet je de zwaarte van de informatiebeveiliging en ook van de reservekopieen af laten hangen van de aard van je organisatie en de daarin aanwezige gegevens. Maar om te stellen dat informatiebeveiliging voor jouw organisatie niet zo belangrijk is, gaat mij toch te ver.

Eisen ten aanzien van reservekopieen

  door

Serieus zijn we inmiddels met informatiebeveiliging bezig en we hebben al allerlei zaken opgestart om incidenten maar zoveel mogelijk te voorkomen binnen de bandbreedte die bij onze organisatie past. Daarnaast zijn we al druk geweest met het opzetten van de calamiteitenplannen en de uitwijkmogelijkheden voor als het echt een keertje fout gaat. Gelukkig kunnen we dan altijd terugvallen op onze reservekopieen (back-ups), toch?

De komende dagen gaan we wat verder in op de eisen ten aanzien van de back-ups en we stellen ons dus de vraag:

Zijn de eisen ten aanzien van reservekopieen (back-up) vastgelegd?

Net als we eisen stellen aan de beschikbaarheid, integriteit en exclusiviteit van de informatievoorziening en de onderliggende informatiesystemen moeten we deze eisen ook stellen aan de reservekopieen.

Hoe snel moeten we, na een incident, kunnen beschikken over deze reservekopieen? Hoe actueel moeten deze zijn of anders gezegd: hoeveel informatie mogen we maximaal kwijtraken? En wie kan er eigenlijk allemaal bij deze reservekopieen?

Het lijkt misschien of het hier puur en alleen gaat om de back-up tapes, maar niets is minder waar. Natuurlijk verandert er een berg met de invoering van virtualisatie en het werken “in the cloud”. Maar dan hebben we het meer over de achterliggende techniek. Hier hebben we het meer over de functionele eisen die we inzichtelijk moeten hebben.

Later deze week zullen we ook nog ingaan op het maken van de reservekopieën, het testen daarvan en de opslag ervan. Toch zijn dit alvast zaken waar we bij het stellen van eisen rekening mee moeten houden. Als we dan toch reservekopieen maken, laten we er dan ook voor zorgen dat we het goed doen. Anders zitten we straks met een berg data die niet aan onze eisen voldoet, die we niet tijdig weer tot onze beschikking hebben, die niet actueel is of waar de hele wereld inmiddels in heeft kunnen kijken.

Hebben we de laatste tijd de back-ups of delen daarvan terug moeten zetten? Ging dat helemaal goed of hebben we daar toch wat “lessons learned” uit kunnen halen? Als we dat nog nooit hebben gedaan wordt het misschien tijd om er toch eens een test tegen aan te gooien…

Implementatie van de beveiligingsmaatregelen

  door

Gingen we gisteren nog in op de OTAP-stappen die we doorlopen voordat we nieuwe informatiesystemen of beveiligingsmaatregelen inzetten. Vandaag gaan we in op het formeel goedkeuren van de maatregelen en het overdragen van die maatregelen aan de staande lijnorganisatie.

We stellen daarom de volgende vraag:

Zijn de beveiligingsmaatregelen geïmplementeerd en zijn systemen formeel goedgekeurd voordat ze in productie worden genomen (overdracht rapportages)?

We hebben al gezien dat we niet zomaar wijzigingen door kunnen voeren omdat dat impact kan hebben op onze productieomgeving…de omgeving waar we ons geld mee verdienen. Voor het gemak gaan we er vanuit dat we inmiddels een goede change management procedure hebben opgesteld en ingevoerd.

Toch zijn we er niet als we “slechts” een wijziging doorvoeren of een nieuw systeem inzetten. We moeten ervoor zorgen dat dat systeem ook geborgd wordt in de organisatie. Iemand binnen die organisatie moet verantwoordelijk zijn voor dat systeem, hij of zij moet weten dat er een verantwoordelijkheid is en deze verantwoordelijkheid moet formeel geaccepteerd worden.

Dat is natuurlijk altijd lastig, want niemand zit te wachten op extra verantwoordelijkheden. Maar als het goed is, is er iemand die opdracht heeft gegeven voor de ontwikkeling van een nieuw systeem. Is hij niet degene die verantwoordelijk is of heeft hij ook weer een opdrachtgever? Borging in de organisatie is van belang om ervoor te zorgen dat het systeem ook zijn werk blijft doen.

Niet makkelijk, maar wel een heel belangrijke stap. Zonder formele eigenaar zouden we een nieuw systeem nooit in de lucht moeten brengen. Overigens zien we hier dat IT vaak verantwoordelijk gesteld wordt, toch is de vraag of dat juist is. Het systeem ondersteund een bedrijfsproces, wie is verantwoordelijk voor dat bedrijfsproces en zou diegene ook niet (functioneel) verantwoordelijk moeten zijn voor dat systeem?

Lastiger wordt het natuurlijk als we met systemen te maken krijgen die meerdere processen ondersteunen. Denk alleen maar eens aan het emailsysteem. Welk proces ondersteund dat? Denk ook maar aan het hele netwerk. Wie is daar verantwoordelijk voor? Het eigenaarschap voor dergelijke systemen is nog weleens niet duidelijk belegd. Misschien toch goed om eens naar de verantwoordelijkheden te kijken. Niet alleen naar de taken, bevoegdheden en verantwoordelijkheden voor de informatiebeveiliging dus (zoals we in eerdere stappen al gedaan hebben) maar ook naar de taken, bevoegdheden en verantwoordelijkheden voor de bedrijfsprocessen en de informatiesystemen.

Hoe we dit exact binnen de organisatie beleggen is niet eens zo relevant. Van belang is dat we keuzes maken, die keuzes vastleggen en dat degene die verantwoordelijk is dat ook weet. Dan kunnen we de discussie verder intern wel voeren.

Ontwikkel, test, acceptatie en productie

  door

De afgelopen dagen zijn we ingegaan op de eisen die we stellen aan de informatievoorziening en de onderliggende informatiesystemen. Daarna zijn we ingegaan op de risicoanalyses voor die informatiesystemen. Allemaal heel erg belangrijk, maar helaas zijn we er niet met het eenmalig uitvoeren van dergelijke stappen. Onze omgeving, de dreigingen maar ook de componenten zijn continue aan ontwikkeling en wijziging onderhevig. Een patch of een update van een component is van groot belang om dat component up-to-date te houden, maar een dergelijke update kan ook weer risico’s met zich meebrengen.

We willen niet dat een patch of update onze informatievoorziening platlegt en stellen daarom de volgende vraag:

Vindt de ontwikkeling/wijziging van informatiesystemen plaats conform de stappen: ontwikkel, test, acceptatie en productie (OTAP procedure, change management)?

Ontwikkeling van nieuwe informatiesystemen of wijziging van bestaande informatiesystemen doen we niet in de productie omgeving. We weten immers nooit zeker hoe dit zal samenwerken met de andere componenten in ons netwerk. We werken daarom met verschillende stappen om een wijziging doorgevoerd te krijgen.

We beginnen uiteraard met het ontwikkelen van de systemen en zodra we denken dat die systemen een vorm van leven beginnen te krijgen gaan we onze ontwikkelingen testen. Werkt het, doet het wat het moet doen, beïnvloedt het andere componenten, voldoet het aan de eisen van beschikbaarheid, integriteit en exclusiviteit en ga zo nog maar even door. Dat doen we niet in de productie omgeving omdat we te weinig zekerheid hebben over de werking van het systeem. Nee, we doen dat in een afgescheiden testomgeving zodat er niets met de productie gebeurt als het fout gaat.

Zijn we er eenmaal zeker van dat het systeem aan alle (technische) eisen voldoet dan gaan we over naar de acceptatie van dat nieuwe systeem. Niet dat we nu pas in overleg gaan met de gebruikers trouwens, want als het goed is ontwikkelen we omdat daar een behoefte aan is. Die behoefte wordt juist gesteld door de gebruikers. Zij hebben echter minder zicht op de achterliggende techniek (en dat hoeft ook helemaal niet) maar zij kunnen wel de functionaliteiten bekijken. Is dit systeem inderdaad wat ze willen? Moet het nog bijgeschaafd worden?

We zitten nog steeds niet in de productieomgeving. Het kan best zijn (en dat is meestal zo) dat we de stappen ontwikkelen, testen en accepteren verschillende malen moeten doorlopen voordat het systeem of de wijziging doorgevoerd kan worden in de productieomgeving.

Hier ontstaat natuurlijk altijd een spanningsveld. De gebruikers willen het nieuwe systeem zo snel mogelijk gaan gebruiken en patches willen we zo snel mogelijk doorvoeren omdat we anders wellicht grote risico’s lopen. Toch is het van belang om goed zicht te houden op de OTAP-stappen. Het middel mag immers niet erger zijn dan de kwaal.

Risicoanalyses voor de informatiesystemen

  door

Zoals we gisteren hebben kunnen zien bepalen de beschikbaarheid, integriteit en exclusiviteit van de verschillende componenten de eisen die we kunnen stellen aan de informatievoorziening. Daarbij moeten we niet vergeten dat de componenten op elkaar inwerken en met elkaar samenhangen. Een losstaand component zegt (in de meeste gevallen) niet zoveel omdat hij van andere componenten gebruik maakt om de informatie daadwerkelijk af te leveren.

Het zal dan ook niet echt een verrassing zijn dat we nu gaan kijken naar de samenhang. We stellen onszelf de vraag:

Worden er risicoanalyses (afhankelijkheid en kwetsbaarheid) uitgevoerd voor de informatiesystemen?

De afhankelijkheids- en kwetsbaarheidsanalyse staat beter bekend als de A&K-analyse. Zonder specifiek in te willen gaan op de A&K-analyse kunnen we ook gebruik maken van CRAMM, FIRM, SPRINT of wat mij betreft iedere andere methode. Het gaat er om dat we op basis van de eisen voor de beschikbaarheid, integriteit en exclusiviteit gaan kijken naar de mogelijke risico’s die die eisen in gevaar kunnen brengen.

We zijn al eerder ingegaan op risicoanalyse en risicomanagement en hiervoor geldt hetzelfde alleen is de scope van onze analyse anders. We moeten de oorzaken en gevolgen niet door elkaar halen en proberen om een reële inschatting te maken. Als we die inschatting hebben gemaakt kunnen we bepalen of we een risico willen accepteren, willen mitigeren of willen overdragen aan een ander (voorkomen kan natuurlijk ook, maar dat heeft implicaties voor de informatievoorziening en daarvoor is een keuze op een ander managementniveau noodzakelijk).

Als het goed is hebben we eerder al risicoanalyses gemaakt voor de totale organisatie, daar passen de risicoanalyses (ja, meervoud, het zijn er meer) bij. Net als we risicoanalyses kunnen en zouden moeten maken voor de assets en de medewerkers. Een totaal pakket aan risicoanalyses waarmee de organisatie leert om te gaan denken in operationele risico’s en minder in beveiligingsmaatregelen.

Het klinkt misschien allemaal erg zwaar en als een hele berg papier. Dat kan maar is helemaal niet nodig. Er kan ook op een pragmatische wijze mee worden omgegaan. Veel papier, dikke informatiebeveiligingsplannen zijn nooit het doel maar zijn (eventueel) een middel om de beveiligingsdoelstellingen te bereiken. En als dat netjes op 1 A4-tje past, dan heeft dat absoluut de voorkeur.

Eisen ten aanzien van de onderliggende informatiesystemen

  door

Zoals we eerder al gezien hebben, wordt de informatievoorziening ondersteund door de informatiesystemen. Stellen we eisen aan de beschikbaarheid, integriteit en exclusiviteit van de informatievoorziening dan moeten de onderliggende componenten er bij elkaar voor zorgen dat we die eisen ook gaan realiseren. Ook hier geldt weer dat de keten zo zwak is als de zwakste schakel. Het “zwakste” systeem bepaald dan uiteindelijk ook de totale beschikbaarheid, integriteit en exclusiviteit van de totale informatievoorziening.

Logischerwijs moeten we onszelf dan ook nog de volgende vraag stellen:

Zijn de eisen ten aanzien van de waarborging van de beschikbaarheid, exclusiviteit en integriteit geformuleerd voor de onderliggende informatiesystemen, netwerkcomponenten en IT-middelen?

De informatievoorziening bestaat uit allerlei componenten die er gezamenlijk voor moeten zorgen dat de informatie beschikbaar is op het moment dat we die nodig hebben, dat de informatie dan actueel en correct is en dat niet iedereen zomaar bij die informatie kan. Op component niveau zullen we die eisen dus door moeten vertalen naar de onderliggende systemen.

Als we dat willen doen, zullen we dus eerst zicht moeten hebben op welke componenten welk deel van de informatievoorziening ondersteunen. Het lukraak stellen van eisen aan componenten heeft weinig zin omdat we naar het grotere geheel moeten kijken.

Redeneren we weer vanuit de kritische bedrijfsprocessen dan komen we tot de kritische informatievoorziening die daarvoor noodzakelijk is en komen we uit bij de kritische componenten die daar invulling aan geven.

Zitten we met een component dat een lage beschikbaarheid, integriteit of exclusiviteit kan geven dan geldt dat niveau voor de gehele informatievoorziening. Of we moeten natuurlijk bereid zijn dat legacy systeem inmiddels te vervangen door een actueel systeem dat wel past binnen de door ons gestelde eisen.

Veelal zijn er allerlei architectuur en infrastructuur plaatjes binnen de organisatie aanwezig. Daar kunnen we goed gebruik van maken waarbij we nog wel de doorvertaling naar de processen moeten maken. Welk deel van die infrastructuur ondersteunt welk deel van de bedrijfsprocessen. Geen gemakkelijke opgave, maar wel een belangrijke exercitie om de doelstellingen van de organisatie te kunnen bereiken.

Eisen ten aanzien van de informatievoorziening

  door

Inmiddels zijn we aangekomen bij het punt waar we wat dieper ingaan op de beveiliging van de geautomatiseerde gegevensverwerking. Zoals we inmiddels al gezien hebben is dat een ondersteunend middel aan het bereiken van de doelstellingen van de organisatie. Daarom houden we de strategie van de organisatie en de doelstellingen waarmee we die strategie gaan bereiken in het achterhoofd en stellen onszelf de volgende vraag:

Zijn de eisen ten aanzien van de waarborging van de beschikbaarheid, exclusiviteit en integriteit geformuleerd voor de informatievoorziening?

Laten we even aftrappen met de definities uit Wikipedia die behoren bij de begrippen beschikbaarheid, exclusiviteit en integriteit:

  • Beschikbaarheid bevat de garanties voor het afgesproken niveau van dienstverlening gericht op de beschikbaarheid van de dienst op de afgesproken momenten (bedrijfsduur, waarbij rekening wordt gehouden met uitvalstijden, storingen en incidenten). Kenmerken van beschikbaarheid zijn tijdigheid, continuïteit en robuustheid.
  • Integriteit geeft de mate aan waarin de informatie actueel en correct is. Kenmerken zijn juistheid, volledigheid en geautoriseerdheid van de transacties.
  • Vertrouwelijkheid is het kwaliteitsbegrip waaronder privacybescherming maar ook de exclusiviteit van informatie gevangen kan worden. Het waarborgt dat alleen geautoriseerden toegang krijgen en dat informatie niet kan uitlekken.

Simpel gesteld moeten we dus kijken naar het feit of de informatie beschikbaar is op het moment dat we die nodig hebben, dat de informatie die we dan willen gebruiken actueel en correct is en willen we zeker stellen dat alleen die mensen die dat mogen ook daadwerkelijk de informatie in kunnen zien.

Hoe hoger we de eisen ten aanzien van de informatievoorziening stellen, hoe meer beveiligingsmaatregelen we in de regel nemen en hoe meer kosten dat met zich mee brengt. Inmiddels hebben we in een eerder stadium ook al gezien dat we rekening moeten houden met de bedrijfsprocessen en dan met name diegene die kritisch zijn voor het voortbestaan van onze organisatie.

De hele kunst bij het stellen van deze eisen is om ze niet te hoog, maar zeker ook niet te laag te stellen. Daarbij komt het gezond boeren verstand weer om de hoek kijken. Stellen we de eisen immers te hoog dan brengt dat enorme kosten met zich mee (en wordt het werken voor de medewerkers meestal ernstig belemmerd), stellen we te lage eisen dan nemen de risico’s toe en deze passen wellicht niet binnen het risicogedrag dat we eerder bepaald hebben.

Hoewel de eisen in samenhang dienen te worden bezien, zien we in de praktijk veelal dat de eis voor beschikbaarheid concreet (of noem het SMART) wordt gesteld en dat de rest er in kwalitatieve zin om heen hangt. Op zich begrijpelijk, want de beschikbaarheid is ook makkelijker meetbaar te maken dan de integriteit en de exclusiviteit. Toch zouden we daar ook de controles op uit moeten voeren.

Voor organisaties die de informatievoorziening hebben uitbesteed, geldt dat de eisen ten aanzien van de beschikbaarheid, integriteit en exclusiviteit in de Service Level Agreement moeten worden opgenomen, dat de leverancier daar verantwoording over af moet leggen en dat we dat met de audits kunnen controleren. Dit grijpt dan uiteraard weer terug op het borgen van de beveiliging door het in de keten op te nemen.

Calamiteiten-, continuiteitsplannen en uitwijkmogelijkheden

  door

Integrale beveiliging heeft nu toch wel onze aandacht en we zijn lekker proactief bezig om de operationele risico’s af te dekken. Nu komt het er op aan dat we onmogelijk alle risico’s af kunnen dekken. We moeten dus accepteren dat we nooit 100% beveiligd zullen zijn. Juist daarom is het ook van belang om te kijken naar de calamiteiten-, continuïteitsplannen en uitwijkmogelijkheden. De vraag die we daar natuurlijk bij stellen is:

Zijn er calamiteiten-, continuïteitsplannen en uitwijkmogelijkheden voor de garantstelling van het voorbestaan / de voortgang van de organisatie?

Proactief zijn we bezig geweest en preventief hebben we al een berg leed voor de organisatie voorkomen. Maar dan, ineens, geheel onverwachts en uit het niets, breekt er een incident uit. Alle maatregelen lijken ineens niet meer te werken en het gaat van kwaad tot erger. Totdat we niet meer te redden zijn en we de brand alleen nog maar gecontroleerd uit kunnen laten blussen (bij wijze van spreken). We kunnen de deuren sluiten, we hebben een paar mooie jaren gehad maar onze continuïteit is nu echt tot een stilstand gekomen.

Een rampenscenario, wellicht, maar ook hiervoor kunnen we proactief iets doen. We kunnen calamiteitenlannen, continuïteitsplannen en uitwijkmogelijkheden creëren om onze continuïteit te borgen. Daarmee moeten we niet wachten tot het incident zich aandient, nee, dan moeten alle zeilen bij gezet worden, we moeten daar al in een vroeg stadium mee beginnen.

Overigens willen we niet zeggen dat er allerlei dikke papieren plannen in de kast liggen te wachten totdat er iets gebeurt. De kunst is nu juist om tijdens een incident snel te kunnen handelen, de eerste paar minuten en uren zijn cruciaal. We hebben helemaal geen tijd om die dikke plannen door te worstelen. We moeten de handen uit de mouwen steken. Daarom is het ook goed om de plannen vooraf te testen en steeds bij te stellen. Zijn de telefoonnummers nog wel actueel? Weet iedereen nog wat hij moet doen? Wie mag er beslissingen nemen?

Geen dikke plannen dus, maar korte lijstjes die de mensen bijna kunnen dromen. Een naslagwerkje dat ze erbij kunnen pakken als ze het in het heetst van de strijd even niet meer weten.

Wat nog belangrijk is om te melden is dat de calamiteitenplannen, continuïteitsplannen en uitwijkmogelijkheden breder moeten zijn dan alleen de informatietechnologie. We moeten wederom de bedrijfsprocessen als uitgangspunt nemen. Die moeten worden gecontinueerd en daarvoor hebben we naast de informatiesystemen ook de assets en medewerkers weer nodig.

Hopelijk blijft jouw organisatie gespaard van grote incidenten, maar de kans dat er iets gebeurt kunnen we helaas niet helemaal uitsluiten. Daarom is het goed om voorbereid te zijn en de medewerkers goed op de hoogte te houden van hun taken, bevoegdheden en verantwoordelijkheden…ook bij het uitbreken van een incident.