Categorie: Geen categorie

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.

Kritische assets en middelen

  door

Inmiddels hebben we het gehad over de kritische informatie en de kritische afdelingen en medewerkers. Zoals eerder aangegeven worden processen ondersteund door die informatie en dat personeel, maar de assets of middelen mogen we ook niet vergeten tegen het licht te houden. De volgende vraag die we stellen zal je inmiddels niet meer verrassen:

Zijn de kritische assets en middelen van de organisatie inzichtelijk?

Kritische assets en middelen. Daar valt eigenlijk alles onder wat we niet konden vatten onder de informatie (geautomatiseerd of niet) en het personeel. Het kunnen dus zijn de gebouwen waar we in gehuisvest zijn, de robotstraat die de producten maakt maar ook bijvoorbeeld de hardware (pc’s, laptops, servers, etc.).

Het hangt helemaal af van de organisatie en de aard van die organisatie over hoeveel kritische assets en middelen beschikken. De ene locatie zal een grotere impact hebben op ons voortbestaan dan de ander. Kijk ook goed naar waar de informatie is opgeslagen, hebben we die uitbesteed of beheren we ons eigen data center?

Een kleine organisatie in de dienstverlening zal misschien snel door kunnen werken na een brand omdat iedereen beschik over een laptop en de data is ondergebracht in een goed beveiligd data center. Een grotere organisatie die zelf een data center beheert heeft wellicht meer problemen bij het uitbranden van dat data center.

Bij het beveiligen van de kritische assets en middelen komen we misschien al meer terecht op het gebied van de fysieke beveiliging. Maar dat heeft alles te maken met de definitie die we er aan koppelen. Wij maken liever geen onderscheid en benaderen de aanpak integraal. We kunnen immers de firewall wel dichtzetten met inlognaam en wachtwoord maar als er een crimineel met een hamer de firewall aan gort slaat dan hebben we toch echt problemen.

Dit is ook de gedachte achter de filosofie dat we niet zozeer naar de maatregelen moeten kijken maar dat we de risico’s als uitgangspunt moeten nemen. Als het risico is: uitval van de firewall, dan moeten we goed kijken wat daar de mogelijke oorzaken van kunnen zijn. Denk bijvoorbeeld aan een hack poging van buiten af of een crimineel die inbreekt en de firewall steelt. In beide gevallen kan het gevolg uitval van de firewall zijn terwijl de oorzaken en dus de maatregelen totaal anders kunnen zijn.

Hoe meer we doen aan informatiebeveiliging hoe groter de kans wordt dat een aanvaller voor de makkelijkere weg kiest. Informatiebeveiliging en fysieke beveiliging moeten elkaar dan ook ondersteunen en met elkaar in evenwicht zijn. Ook hier geldt: de keten is zo zwak als de zwakste schakel. Een superieure aanpak van informatiebeveiliging met een zeer zwakke fysieke beveiliging lost het probleem niet op…of anders gezegd: dekt het risico niet voldoende af.

Kritische afdelingen en medewerkers

  door

Na het, redelijk, zware onderwerp van gisteren gaan we vandaag door met de kritische afdelingen en medewerkers. Een onderwerp waarbij we ons waarschijnlijk wat meer voor kunnen stellen. Toch moeten we dit aspect niet onderschatten want uiteindelijk zorgen de mensen in onze organisatie ervoor dat we omzet halen. Daarom vandaag de volgende vraag:

Zijn de kritische afdelingen en medewerkers van de organisatie inzichtelijk?

De ene afdeling of medewerker levert nu eenmaal een directere bijdrage aan de kritische bedrijfsprocessen dan de ander. Niet dat de een meer of minder belangrijk is, want als het goed is hebben we iedereen binnen de organisatie hard nodig. Wel kunnen we er meer last van hebben als een kritische afdeling uitval vertoond dan een ander. Sommige activiteiten kunnen we niet een paar uur of een paar dagen uitstellen terwijl dat met andere activiteiten wel kan.

Nogmaals: verwar kritisch in dit geval niet met belangrijk. De totale organisatie zorgt voor ons voortbestaan, mensen die daaraan geen enkele bijdrage (hoe groot of klein ook) leveren hebben we niet nodig. Dat klinkt misschien hard en is ook nooit helemaal zuiver te maken, maar de nuance zit hem nu juist in het feit dat iemand een grote of kleine bijdrage kan leveren en dan toch toegevoegde waarde heeft. Niemand hoeft dus, wat mij betreft, bang te zijn voor zijn baantje, maar ze moeten wel een bijdrage leveren.

Maar goed, we dwalen wat af. Wat bedoelen we nu met de kritische afdelingen en medewerkers? We bedoelen daarmee dat je voor continuïteit moet zorgen bij die afdelingen en medewerkers. We moeten de kennis die daar aanwezig is goed borgen zodat bij vertrek van een medewerker of uitval van een afdeling de rest van de organisatie daar geen last van ondervindt.

Gelijk toegegeven: niemand is onmisbaar, maar lastig kan het wel zijn als een kritische medewerker spontaan besluit om zijn biezen te pakken, als er een griepepidemie over een afdeling dwaalt of iedereen tegelijk op vakantie gaat. Meestal is het gat dat valt wel op te vullen, maar het is geen reden om er niet extra alert op te zijn.

Hoe vaak zien we niet dat de kennis geborgd is in een persoon, er staat niets op papier en als hij met vakantie gaat dan vrezen we het ergste. Hebben we er tijdens zijn of haar vakantie ook echt last van dan is dat een mooi aanknopingspunt om na de vakantie te zorgen voor kennisdeling en borging. Hadden we er geen last van maar dachten we dat alleen, dan kunnen we ons afvragen hoe kritisch de persoon is.

Mensen zijn innovatief en verzinnen echt wel mogelijkheden om door te kunnen werken, niemand is onmisbaar maar lastig kan het wel zijn. Een gevleugelde uitspraak in deze: “we kunnen niet zonder jou, maar gaan het toch proberen”