Onderscheid tussen incidenten en beveiligingsincidenten

We zijn er vorige week al kort op ingegaan, maar vandaag zoomen we nog wat dieper in op het verschil tussen incidenten en beveiligingsincidenten.

De vraag is dan ook niet voor niets:
Wordt er onderscheid gemaakt tussen beveiligingsincidenten en overige incidenten?

We schreven al dat we vanuit beveiligingsoptiek graag willen weten welke beveiligingsincidenten zich voordoen. Hier kunnen we namelijk onze aanpak op bijstellen. Doen we de juiste dingen en doen we de dingen nog juist? Het verschil tussen een incident en een beveiligingsincident kan hier het verschil in maken. Gisteren voegden we daaraan toe dat we het melden van incidenten zo makkelijk mogelijk willen maken om geen informatie verloren te laten gaan.

Nu kunnen we op papier en met een beetje Googlen best wat leuke definities ontwerpen voor het verschil tussen incidenten en beveiligingsincidenten. Dat moeten we zeker niet nalaten, maar we moeten degene die de incidenten als eerste te horen krijgen daar ook in trainen. En dat is makkelijker gezegd dan gedaan. De helpdesk medewerker heeft zijn “target” en moet binnen 5 minuten de klant weer op pad sturen (soms met een kluitje het riet in, maar het target is gehaald).

Daarmee gaat kostbare informatie verloren, die daarna wellicht nooit meer is terug te halen. Voor die beveiligingsincidenten die zich vaker voordoen is het nog mogelijk om mensen daarin te trainen. Ga maar na: na een alarmmelding van het inbraakdetectiesysteem weet de beveiligingsbeambte inmiddels wel wat hij moet doen en hoe hij moet reageren. Maar hoe reageert hij of zij als er een melding wordt ontvangen van een gijzeling op de directieverdieping?

Als het goed is hebben we natuurlijk allerlei procedures voor het opvolgen van incidenten maar het gaat er juist ook om dat degene die er mee geconfronteerd wordt zo creatief (en stressbestendig) is dat er ook echt wat in gang wordt gezet. De procedures zijn een goed hulpmiddel, maar niemand gaat, als het gebouw in de brand staat, een dik calamiteitenplan lezen.

We zullen dus mensen moeten trainen in het ontdekken van (mogelijke) beveiligingsincidenten maar juist ook in de opvolging daarvan. Dat geldt overigens niet alleen voor meer fysieke incidenten maar ook voor incidenten op informatiebeveiligingsgebied. Zien we dat de website uit de lucht gaat dan moeten we snel analyseren of het een technische storing betreft of een aanval van een scriptkiddie. De opvolging moet daarop worden afgestemd.

Omdat het verschil tussen een incident en een beveiligingsincident niet altijd duidelijk is, moeten we de meldpunten een mindset meegeven waarbij ze signalen herkennen. Jammer dat ze de targets even niet halen, maar het reageren op een beveiligingsincident is toch echt even belangrijker.

Juist als we helpdesken uitbesteden (al dan niet naar het buitenland) wordt het risico groter dat we beveiligingsincidenten missen. Er is immers weinig betrokkenheid bij onze “business” en de targetdruk is alleen maar groter. Een serieus risico waar we rekening mee moeten houden.

Als laatste halen we hier nog even kort de oorzaak-gevolg relatie aan. Dat hebben we al vaker gedaan, dus daar verwijs ik graag naar. De melding is veelal een gevolg (“mijn account is geblokkeerd”), de oorzaak kan soms een beveiligingsincident zijn (een collega heeft geprobeerd mijn account te gebruiken). Bij de melding moeten we dus op zoek naar de melding achter de melding…tenminste, als we echt iets van de incidenten willen leren…en dat verschilt dan weer juist niet tussen incidenten en beveiligingsincidenten want we willen beide structureel oplossen, toch?

Meldingsprocedure voor beveiligingsincidenten

We zijn al even kort ingegaan op het verschil tussen een incident en een beveiligingsincident en zullen daar morgen nog wat dieper op ingaan. Maar we kunnen alleen maar wat doen aan incidenten als we ze ook daadwerkelijk opmerken. Het kan natuurlijk zo zijn dat we vanuit beveiliging vreemde zaken opmerken, maar we kunnen hierbij ook de hulp van alle medewerkers en zelfs van klanten inschakelen.

We moeten er dan alleen voor zorgen dat we het ze zo makkelijk mogelijk maken, dat we de melder bedanken (en eventueel belonen, in wat voor vorm dan ook want een simpel bedankje voelt ook al als een beloning) en dat we de melder ook informeren over hoe we met het incident zijn omgegaan en wat we er aan hebben gedaan.

De volgende vraag is dan ook niet meer dan logisch:
Is er een meldingsprocedure voor beveiligingsincidenten?

In de meest enge zin is het een procedure die op papier staat en die onder een dikke laag stof is opgeborgen. Leuk dat we ooit zo’n stap hebben gezet, maar dat was toch nooit het doel? Nee, het doel is dat we een juist mechanisme voor detectie hebben. Dat kan deels geautomatiseerd (door allerlei alarmsystemen of intrusion detection systems) maar kan ook gewoon door onze mensen te verzoeken hun ogen open te houden en vreemde zaken te melden.

Juist als het gaat om het melden van incidenten is het van belang om het juiste optimum te vinden tussen de risico’s die we af willen dekken en de maatregelen die we treffen. Teveel maatregelen zorgt ervoor dat de medewerkers juist gedwongen worden de regels te overtreden omdat ze anders hun werk niet kunnen doen.

Een voorbeeld? Ok, dat kan: stel dat we voor 20 applicaties een inlognaam en wachtwoord verstrekken. Het wachtwoord moet om de 90 dagen worden gewijzigd, maar voor alle 20 applicaties is dat op een andere dag. Ook zijn de eisen die we stellen aan de wachtwoorden per applicatie verschillend. Zo moeten we bij de een 2 cijfers, 2 hoofdletters en minimaal 8 karakters gebruiken terwijl we bij de andere applicatie dan maar 6 karakters vereisen. Geen mens dat 20 wachtwoorden kan onthouden, dus we schrijven het op een post-IT en plakken het onder het toetsenbord…een duidelijk geval waarbij we het optimum nog niet hebben gevonden.

Nu weer terug naar de meldingsprocedure. Een voorwaarde daarvoor is dat we het de ontdekker van het incident zo makkelijk mogelijk maken en hij of zij moet het ook nog eens anoniem kunnen melden als dat even mogelijk is. Dus niet iemand 20 minuten in de wachtstand zetten als hij de helpdesk belt, nee, gewoon het nummer noteren en zelf, actief, terugbellen. Dat is niet alleen goed voor de beveiligingsincidenten maar ook nog eens erg klantvriendelijk.

Neem als voorbeeld de phishing mails die we tegenwoordig allemaal ontvangen. Vaak van grote banken omdat daar nu eenmaal het geld te halen is. Zelf wil ik graag dergelijke mails doorsturen naar de banken zodat ze ze kunnen analyseren en de bijbehorende sites uit de lucht kunnen laten halen. Heb wel eens, tevergeefs, gezocht naar waar ik het dan heen kon sturen…helaas. Nu verdwijnen ze in de “verwijderde items” en wordt er niets mee gedaan. Een gemiste kans als je het mij vraagt. Natuurlijk zal de bank deze mails best ontvangen en analyseren…maar ik wil graag mijn bijdrage leveren…en dat versterkt ook nog eens het gevoel dat ik bij die bank heb (klantbetrokkenheid).

Een leuke tegenstrijdigheid bij het juist invoeren van een meldingsprocedure is dat we in eerste instantie meer incidenten gemeld krijgen. Vaak horen we dat dat lastig te “verkopen” is aan het management. Hoe kan dat nou? We doen er alles aan en het aantal incidenten gaat juist omhoog. Niet waar natuurlijk, dat aantal incidenten (en waarschijnlijk nog veel meer dan die we weten) was er altijd al, alleen krijgen we er nu zicht op. Krijgen we er zicht op dan kunnen we er ook wat aan doen. Na verloop van tijd en veel fine tuning zal dan het aantal meldingen afnemen en hebben we ons doel bereikt.

Willen we alleen maar compliant zijn dan volstaat misschien een stoffige papieren meldingsprocedure, maar willen we echt “in control” raken dan maken we dankbaar gebruik van de informatie die we ontvangen.

Beveiligingsincidenten

Als we beveiliging goed (genoeg) inrichten dan kunnen we er op vertrouwen dat we de risico’s voldoende hebben afgedekt. Preventief zijn we bezig om juist die activiteiten op te pakken die bijdragen aan de continuïteit van onze organisatie. Toch zullen we zien dat preventieve maatregelen alleen niet genoeg zijn, nee, we zullen ook detectie moeten inregelen voor het geval er toch iets onverwachts gebeurt. We moeten met onze repressieve en correctieve maatregelen daarop in kunnen spelen om zo snel mogelijk terug te gaan naar de “business as usual”.

De vraag die daarbij speelt is:
Is er vastgelegd wat verstaan wordt onder beveiligingsincidenten?

Vanuit de IT zijn we gewend om te werken met incidenten. Een verstoring van de applicatie melden we bij de helpdesk zodat we zo snel mogelijk weer aan het werk kunnen. Logisch en als we er echt serieus mee bezig zijn dan richten we het incident management proces in conform ITIL.

Daar moeten we vooral mee door blijven gaan, want dit is zeker een aspect dat bijdraagt aan de continuïteit van de organisatie. Toch moeten we ook na gaan denken over wat we exact verstaan onder een beveiligingsincident. Deze kan veel overeenkomsten vertonen met een incident (conform IT), maar kan wel degelijk op een andere wijze worden opgelost.

Om het niet te cryptisch te maken even een kort voorbeeld: stel je komt terug van vakantie en bent je wachtwoord vergeten. Je probeert 3x in te loggen en blokkeert helaas je account. Helpdesk bellen en na een paar minuten kun je gelukkig toch weer aan de slag. Een incident dat we op moeten lossen omdat je anders liever weer terug gaat naar je vakantieadres. Maar stel nu dat tijdens jouw afwezigheid een collega geprobeerd heeft om met jouw account in te loggen. Hij moest even in je mailbox zijn om een mailtje te lezen. Jij komt terug en kunt niet meer inloggen, terwijl je er zeker van bent dat je het juiste wachtwoord hebt gebruikt. Verstaan we dit nog onder een incident of hebben we het hier toch eerder over een beveiligingsincident?

Enerzijds is het dus niet altijd gemakkelijk om de juiste definitie te hanteren voor beveiligingsincidenten, maar anderzijds is het ook nog lastig om ze te detecteren. Hoe kan de medewerker van de helpdesk nu weten of het een incident is omdat jij je wachtwoord bent vergeten of dat het een beveiligingsincident is omdat een collega geprobeerd heeft in te loggen?

Lekker relevant zul je zeggen. Ik ben net terug van vakantie en wil (of moet) weer aan de slag. Toch is het voor de beveiligingsaanpak relevant. Misschien probeert die collega namelijk nog wel meer illegale activiteiten uit te voeren. Stel dat het was gelukt om in te loggen en dat hij namens jouw een mail had gestuurd aan de directeur die hij voor stommeling uit maakt dan zijn de gevolgen wel anders.

Vanuit beveiligingsoptiek willen we graag weten welke beveiligingsincidenten zich voordoen. Hier kunnen we namelijk onze aanpak op bijstellen. Doen we de juiste dingen en doen we de dingen nog juist? Het verschil tussen een incident en een beveiligingsincident kan hier het verschil in maken.

Omgang met informatiebeveiligingsplannen

Zoals we gisteren al schreven, maken we geen beveiligingsplannen om ze in de kast te zetten en ze te laten verstoffen. Nee, de beveiligingsplannen hebben een doel en we moeten dus ook goed kijken wat we exact met deze plannen willen en kunnen bereiken.

De vraag die daarbij hoort, is:
Is er een goed begrip binnen de organisatie met betrekking tot de omgang met deze beveiligingsplannen?

De plannen die we opstellen moeten ervoor zorgen dat de gemaakte keuzes vastliggen. Zover niets bijzonders, dat kan inderdaad eenmalig en vervolgens laten we flinke lagen stof ontstaan op deze plannen. Maar dat kan nooit het doel zijn. De plannen leggen vast wat we beloven, we zullen ze dus als kaders moeten gebruiken bij het afdekken van risico’s en het implementeren van maatregelen.

Dat zouden we natuurlijk ook eenmalig kunnen doen. Maar dan lijkt het meer op een projectplan dan op een beveiligingsplan. Een project is immers uniek en voeren we eenmalig uit, maar beveiliging is geen eenmalige activiteit. Nee, beveiliging is een continu proces.

Daarom moeten we na verloop van tijd goed kijken of onze plannen nog aansluiten bij de risico’s. Het kan best zo zijn dat de risico’s inmiddels gewijzigd zijn. Er zijn nieuwe dreigingen bij gekomen, de omgeving is gewijzigd of het risicogedrag van de organisatie is bijgesteld.

Nu vormen de plannen een mooie basis om onze evaluatie uit te voeren. Doen we het conform plan? Moeten we het plan bijstellen? De “lessons learned” helpen ons verder op onze weg om het juiste niveau van beveiliging te bereiken. Niet te weinig, maar zeker ook niet teveel doen.

De praktijk leert ons dat we bij de eerste cyclus die we doen eerder te weinig of het verkeerde aan beveiliging doen omdat we nog niet helemaal gewend zijn om risico’s af te dekken en niet slechts maatregelen te implementeren. Naarmate we verder in het traject komen zien we dat we juist eerder maatregelen af kunnen schaffen of technische maatregelen kunnen vervangen door organisatorische (die vaak goedkoper zijn en meer effect sorteren). Dat komt omdat iedereen zijn of haar rol beter in gaat vullen en beter leert te denken in de risico’s. Die risico’s hoeven we niet per definitie af te dekken en al helemaal niet met technische maatregelen, nee, we leren beter te kijken naar kosten en baten en daarmee bereikt de beveiliging al een beter niveau.

Informatiebeveiligingsplannen

We hebben nu een basis beveiligingsniveau en voeren afzonderlijke risico analyses uit voor de verschillende systemen, de verschillende gebouwen, de processen, de projecten en alles waarbij we beveiliging in moeten bouwen. We willen deze informatie en onze keuzes niet verloren laten gaan en het mag ook niet bij een beperkt aantal mensen in het hoofd zitten. Nee, we moeten een aantal zaken vast gaan leggen.

De vraag die hierbij hoort is:
Zijn de beveiligingsmaatregelen per informatiesysteem vastgelegd in beveiligingsplannen?

Hoe een beveiligingsplan er exact uit komt te zien kan per organisatie verschillen. Wel kunnen we op centraal niveau onze eisen stellen aan dergelijke plannen. Wat willen we er minimaal in hebben, wie is er verantwoordelijk voor en welk format hanteren we. De basis voor het beveiligingsplan is het basis beveiligingsniveau aangevuld met de resultaten van onze risico analyse. We weten welke risico’s we lopen en hebben keuzes gemaakt voor de beheersingsmaatregelen die we willen treffen. Dergelijke zaken leggen we vast.

We leggen ze daarbij niet vast omdat we kasten vol met papier willen, maar omdat we in een later stadium na willen gaan waarom we sommige keuzes gemaakt hebben. Het kan immers best zo zijn dat we nu een keuze maken die logisch is, maar die over een poosje meer vragen dan antwoorden oproept.

Ook willen we voorkomen dat de aanpak die we hanteren en de maatregelen die we treffen alleen in het hoofd van een beperkt aantal functionarissen zit. Het risico is immers dat deze mensen ooit de organisatie verlaten en we blind worden voor de risico’s en de maatregelen.

Daarnaast kan het beveiligingsplan goed dienen als normenkader voor de auditors die komen controleren of onze aanpak echt zo goed is. Natuurlijk kunnen ze keuzes ter discussie stellen, maar dat is niet erg. Hebben we geen beveiligingsplan dan is het risico groot dat ze met een eigen normenkader aan de slag gaan en zelf keuzes maken. Het gevolg is dat wij de auditfindings aan de broek krijgen, terwijl we juist bewuste keuzes hadden gemaakt om risico’s te accepteren.

Het voordeel van beveiligingsplannen is dat we aantoonbaar kunnen maken dat we serieus met beveiliging (en risicomanagement) bezig zijn en dat onze keuzes ook in de toekomst nog terug te halen zijn. Gebruiken we de formats die op centraal niveau zijn vastgesteld dan ontstaat er herkenning van deze plannen en dat draagt weer bij aan het bewustzijn binnen de organisatie.

Natuurlijk heeft het ook een keerzijde. We kunnen gewezen worden op onze keuzes, doen we het niet conform onze plannen dan kunnen we daarop worden aangesproken. Maar draagt dit nu juist niet bij aan het volwassen worden van beveiliging binnen onze organisatie?

Beveiliging: centraal of decentraal

Gisteren hebben we al gezien dat het wiel dat we uitvinden rond is en dat we er daarom ook voor kunnen kiezen om te gaan werken met een basis beveiligingsniveau. Bovenop dat basisniveau implementeren we dan de aanvullende maatregelen die komen uit onze risico analyse (want die doen we, toch?).

Maar als we er dan toch voor kiezen om een aantal maatregelen standaard te implementeren. Dan is de volgende vraag een logisch vervolg:
Is vastgesteld welke beveiligingsmaatregelen centraal en/of decentraal genomen (moeten) zijn?

Gaan we werken vanuit een basisniveau, corporate security framework, beveiligingspolicy of weet ik welke naam er binnen jouw organisatie aan gegeven is, dan kunnen we ook onderscheid gaan maken in de maatregelen die we centraal of juist decentraal moeten nemen.

Een beleidsdocument dat geldt voor de gehele organisatie is logischerwijs natuurlijk al snel een centrale maatregel die we eventueel op lokaal (decentraal) niveau door kunnen vertalen naar de specifieke eisen, wensen, wet- en regelgeving. Stel dat we in het beleid bepalen dat we aan toegangsbeveiliging tot ons gebouw gaan doen, dan kunnen we lokaal kijken of we dat doen met een toegangscontrole systeem op basis van toegangspasjes of dat we er toch liever voor kiezen om een gewapende wacht met een kalashnikov voor de deur te zetten.

Je zult zien dat het abstractieniveau nodig is omdat we niet voor iedere locatie, ieder land, ieder systeem dezelfde maatregel voor kunnen schrijven. Die gewapende wacht met een kalashnikov is in het buitenland misschien heel normaal, maar in Nederland is het niet toegestaan. Daarmee zouden we dus de wet overtreden.

Maar het gaat om meer dan de wet overtreden. We haalden eerder al het voorbeeld aan waarbij we ervoor kozen om te werken met een inlognaam, pincode en toegangspas. Maar kunnen alle systemen daar wel mee over weg? Hebben we niet wat, inmiddels verouderde, systemen staan die met pijn en moeite met inlognaam en wachtwoord werken? Naast de mogelijke overtreding van wetgeving moeten we er dus ook naar kijken wat (technisch) haalbaar is.

Juist daarom is het dus de kunst om het abstractieniveau zodanig te kiezen dat het algemeen toepasbaar is, maar niet zo algemeen dat het niet meer de richting voor beveiliging aangeeft. Hebben we dat gedaan en komen we uit op allerlei standaard maatregelen die we minimaal implementeren dan kunnen we daarbij ook kijken wat we daarvan centraal beleggen en wat we aan de lijnorganisatie over laten.

Laten we teveel in de lijn liggen dan is er weinig uniformiteit en bestaat het risico dat het een allegaartje wordt. Doen we echter teveel op centraal niveau dan zal er in de organisatie weinig betrokkenheid bij het afdekken van risico’s ontstaan. Willen we het goed doen dan moeten we kijken naar de cultuur van de organisatie en kunnen we kijken naar hoe we het op andere vlakken hebben ingericht. Is voor P&O zaken bijvoorbeeld veel belegd op decentraal niveau, dan is dat misschien een goed voorbeeld voor de aanpak van beveiliging.

In de praktijk lijkt het er op dat een top-down benadering van beveiliging veelal wat meer centraal aangestuurd wordt, terwijl een bottom-up benadering juist meer activiteiten in de lijn belegd. Hoe is jouw organisatie ingericht en zegt ons dat al iets over de wijze waarop we beveiliging daarin in kunnen passen? Het advies is om het vooral niet anders in te richten dan de rest van de zaken in de organisatie, beveiliging is al lastig genoeg, dus we zitten niet op allerlei organisatorische afwijkingen te wachten, toch?

Basis beveiligingsniveau

We zijn inmiddels een aardig stuk onderweg en zijn al goed bezig om beveiliging ook echt werkend en geborgd te krijgen in de organisatie. We doen aan risico analyse en bepalen wat ons risicogedrag is. Voor die risico’s die we niet kunnen accepteren gaan we op onderzoek uit om de beheersingsmaatregelen te bepalen.

Hierbij komen we al snel tot de conclusie dat een aantal van die maatregelen toch minimaal geïmplementeerd moeten zijn en dat we iedere keer terug komen op diezelfde maatregelen (een deur in een gebouw is toch wel handig om buitenstaanders buiten te houden). Om te voorkomen dat we iedereen afzonderlijk deze basis maatregelen laten bepalen, gaan we op zoek naar de grote gemene deler.

De vraag die we daarom stellen is:
Is er een vastgesteld basis beveiligingsniveau waaraan alle informatiesystemen (maar ok gebouwen, processen, etc.) minimaal moeten voldoen?

Door de hele organisatie heen kunnen we een basis leggen waaraan we minimaal moeten voldoen. We nemen steeds dezelfde maatregelen en proberen die zo uniform mogelijk te maken. Waarom zouden we het wiel iedere keer opnieuw uitvinden als we toch weten dat een wiel dat rond is, het beste rolt?

Gelukkig kunnen we gebruik maken van allerlei standaarden die er op de markt te verkrijgen zijn. Neem bijvoorbeeld de Code voor Informatiebeveiliging waar we het basis beveiligingsniveau uit af kunnen leiden. Met common sense, of gewoon boeren verstand, kunnen we echt wel bepalen wat we als standaard zouden moeten hanteren.

We moeten echter wel even stil staan bij het abstractieniveau waarop we het basis beveiligingsniveau bepalen. Willen we bijvoorbeeld als standaard opnemen dat we iets aan logische toegangsbeveiliging moeten doen of nemen we expliciet op dat er gebruik moet worden gemaakt van een inlognaam, pincode en toegangspas? Dat laatste is misschien wel concreet, maar gaat het voor ieder systeem werken? We zijn natuurlijk niet op zoek naar papierentijgers maar naar een aanpak die ook echt de risico’s afdekt.

De kunst is juist om het optimum te vinden in het abstractieniveau en vervolgens de detaillering of specifieke invulling over te laten aan degene die we verantwoordelijk hebben gemaakt voor het informatiesysteem, maar net zo goed voor het fysieke gebouw en processen natuurlijk, want ook daarvoor kunnen we basis beveiligingsniveaus opstellen.

Het voordeel is dat we uniform maatregelen kunnen implementeren en dat we niet iedere keer opzoek hoeven naar zaken die standaard al ingeregeld zijn. Een juiste omgang met een basis beveiligingsniveau ondersteund dus het lijnmanagement, zorgt ervoor dat we aan de minimale eisen voldoen die passend is voor onze bedrijfsstrategie en kan er ook nog eens voor zorgen dat we schaalvoordelen bereiken bij de aanschaf van maatregelen.

Nog niet nagedacht over het basis beveiligingsniveau? Dan is dat nu een mooi moment om te doen voordat we verzanden in allerlei dubbele of onzinnige maatregelen die uiteindelijk veel meer kosten dan ze opleveren.

Beveiligingseisen in de keten

Ja hoor, hier is hij weer: de keten is zo zwak als de zwakste schakel. Hoe vaak hebben we dat inmiddels niet genoemd? Misschien te vaak, maar toch geldt ook voor de eisen de we stellen aan beschikbaarheid, exclusiviteit en integriteit dat we over onze eigen grenzen heen moeten kijken om het goed te regelen.

Daarom de volgende vraag:
Zijn de eisen ten aanzien van de waarborging van de beschikbaarheid, exclusiviteit en integriteit in de systeemketen (IV-keten) afgestemd?

Allemaal erg leuk en aardig als we ons huis op orde hebben, maar wat als de buren er een zooitje van maken? Hoe ziet de straat er dan uit? Juist. Intern mogen we dan hard werken aan verdere professionalisering van onze bedrijfsprocessen en informatiesystemen, maar deze staan veelal niet los van de systemen die leveranciers of andere interne afdelingen aanbieden. Heeft de leverancier zijn zaakje niet op orde dan ondervinden wij daar last van en als wij daar last van ondervinden dan ondervinden onze klanten daar nog meer last van. De vraag is zomaar wie dat wordt aangerekend? Weet de klant eigenlijk wel dat we dat systeem hebben uitbesteed of schaadt het juist ons imago als het fout gaat?

Meestal is het laatste het geval en voor de klant natuurlijk terecht. Die heeft immers helemaal niets te maken met jouw leveranciers. Nee, hij of zij wil gewoon een dienst geleverd krijgen, daarvoor wordt goed geld betaald en jij moet er maar voor zorgen dat de keten werkt.

Stel je koopt een paar gloednieuwe schoenen bij de schoenwinkel. Je kiest voor kwaliteit en die kwaliteit heeft uiteraard een prijs. Na 2 dagen zit er al een gat in je zool en je gaat terug naar de schoenwinkel. De schoenwinkel kan natuurlijk zeggen dat het aan de fabrikant ligt, maar daar heb jij geen boodschap aan. Nee, de schoenwinkel moet gewoon een nieuw paar leveren en gaat maar lekker zelf in conclaaf met de fabrikant of importeur. Zo ook voor informatiesystemen. Als consument koop ik een dienst, daar betaal ik voor en of je leverancier het nu goed doet of niet, ik wil gewoon gebruik maken van die dienst en daar heb jij voor te zorgen.

Leuk dus dat wij allemaal eisen stellen aan de beschikbaarheid, exclusiviteit en integriteit van de informatie. Maar als de keten inderdaad zo zwak is als de zwakste schakel dan zullen we in overleg moeten met die zwakste schakel. Kan hij voldoen aan onze eisen? Moeten we aanvullende maatregelen nemen? Of moeten we accepteren dat we de eisen naar beneden toe bijstellen?

Leuk dat we een eis stellen van 99,9% beschikbaarheid voor een applicatie, maar als die applicatie gebruik maakt van het internet…welke beschikbaarheid is gegarandeerd door onze internetprovider? Als we voor ons netwerk een garantie afgeven van 95%, kunnen we dan voor afzonderlijke applicaties 99,9% garanderen?

Hier is een waarschuwing op zijn plaats. Er worden hoge percentages geroepen naar de klant toe (en daar betaald de klant grof voor), maar wat houdt dat percentage precies in? Of anders gezegd: wat is de scope? Het kan zijn dat er voor een applicatie bijvoorbeeld 99,9% wordt afgegeven maar dat het netwerk buiten de scope valt. Als je niet oplet betaal je kapitalen terwijl de end-to-end beschikbaarheid eigenlijk niet gegarandeerd kan worden. Leuk dat die applicatie gewoon doordraait (in het rekencentrum) als het internet een storing geeft, maar op afstand kunnen wij ons werk niet doen omdat de applicatie niet benaderbaar is, en daar ging het nu toch juist om?

Nee, ook bij het stellen van eisen aan de beschikbaarheid, exclusiviteit en integriteit moeten we goed kijken dat het geen wassen neus wordt en dat we niet teveel betalen. Als de zwakste schakel “slechts” 90% kan garanderen dan moeten we geen 99,9% aan de klant verkopen…tenminste als we integer willen zijn. Bij het stellen van de eisen moeten we dus een goede analyse loslaten op de keten, willen we de eisen naar boven toe bijstellen dan zal dat doorgevoerd moeten worden in die gehele keten. De dooddoener blijkt maar weer eens waar te zijn: de keten is zo zwak als de zwakste schakel.

Beveiliging en de afstemming op de processen

Inmiddels beginnen we steeds meer te denken aan het beschermen van de processen om de continuïteit van onze organisatie beter te borgen. We hebben inmiddels ook wel door dat het helemaal niet draait om allerlei technische beveiligingsmaatregelen als firewalls, anti-virus en intrusion detection. Nee, inmiddels weten we dat de keuzes die we maken draait om het verhogen van de omzet, het verlagen van de kosten en het beschermen van ons imago. Dat we daarvoor uiteindelijk allerlei beveiligingsmaatregelen moeten nemen geloven we wel en is meer een zaak van de IT- en Facility-afdeling.

Willen we de uitvoerende afdelingen hun werk goed kunnen laten doen dan moeten we op tactisch niveau de kaders stellen waarbinnen zij kunnen opereren. Daarom de volgende vraag:
Zijn de eisen ten aanzien van de waarborging van de beschikbaarheid, exclusiviteit en integriteit op processen (bedrijfsvoering) afgestemd?

Denken we aan continuïteit van de bedrijfsprocessen en informatiesystemen dan denken we al snel aan de beschikbaarheidseisen die de waaraan moeten stellen. Meestal drukken we die uit in percentages als 95%, 98% of 99,9% die we doorvertalen naar brons, zilver en goud, omdat de klant die percentages helemaal niet wil horen. De percentages kunnen we meten en de IT-afdeling kan daar mooi verantwoording over afleggen. Hoewel dit allemaal makkelijker gezegd is dan gedaan, is er nog niet echt iets nieuws onder de zon.

Maar naast de beschikbaarheid moeten we ook kijken naar de eisen die we stellen aan exclusiviteit en integriteit. Exclusiviteit gaat in op de wijze waarop we ervoor zorgen dat alleen geautoriseerde personen of systemen toegang krijgen tot de informatie, terwijl integriteit juist ingaat op de juistheid, volledigheid en tijdigheid van de informatie.

Stellen we geen of de verkeerde eisen aan de exclusiviteit dan kan dat ervoor zorgen dat de informatie door ongeautoriseerde personen benaderbaar is en onze informatie al snel op straat komt te liggen. We lopen hiermee het risico dat ons imago een flinke deuk oploopt.

Hebben we te weinig zicht op de integriteit van de informatie dan kan dat er bijvoorbeeld voor zorgen dat we verkeerde keuzes maken op basis van onbetrouwbare informatie. Dit kan ons veel omzet schelen maar kan ook voor enorme kosten zorgen. Verkeerde keuzes kunnen ook leiden tot imagoschade. Denk maar aan het geval waar een arts op basis van de verkeerde informatie het verkeerde been van een patiënt amputeert.

Willen we dus continuïteit van onze organisatie en haar bedrijfsprocessen dan stellen we beschikbaarheids-, exclusiviteits, en integriteitseisen aan de informatiesystemen. Daarbij laten we de kosten en baten weer meewegen want hoe meer maatregelen we nemen, hoe meer kosten dat met zich meebrengt en hoe moeilijker de medewerkers hun werk kunnen doen. De kunst is niet om lukraak de eisen te stellen maar juist om het optimum te vinden waarbij de eisen zo goed mogelijk aansluiten bij de missie van onze organisatie. Daarbij moeten we zeker in de gaten houden dat het allemaal wel werkbaar moet blijven omdat de medewerkers er anders omheen gaan werken.

De eisen die we stellen kunnen per organisatie verschillen. Zo zal een geheime dienst andere eisen stellen dan de bakker om de hoek (als die laatste al eisen stelt). Maar ook per informatiesysteem kunnen de eisen verschillen. De kritische informatiesystemen krijgen wellicht hogere eisen opgelegd dan een niet kritisch systeem. Hierbij houden we uiteraard weer de relatie tussen de bedrijfsprocessen en informatiesystemen goed in het oog en leiden we het een en ander af uit de missie van onze organisatie. Wel stellen we graag eisen die haalbaar zijn, we maken ze SMART om te voorkomen dat het er op papier allemaal leuk uit ziet, maar in de praktijk nooit gaat werken.

Kritische bedrijfsprocessen en informatiesystemen

Inmiddels weten we dat we het beheer van de informatiesystemen heel goed in kunnen richten met standaarden als ITIL, ASL en BiSL. Besluiten we om dat te gaan doen dan gaan we eerst nog wat aanvullende keuzes maken. Het heeft niet zoveel zin om te beginnen met professioneel beheren van informatiesystemen die we nauwelijks gebruiken. We moeten kijken naar de relatie tussen kritische bedrijfsprocessen en informatiesystemen. Daarvoor moeten we dus zicht hebben op de bedrijfsprocessen aan de ene kant en de ondersteunende informatiesystemen aan de andere kant.

We stellen ons daarom de volgende vraag:
Is er inzichtelijk welke kritische bedrijfsprocessen van welke informatiesystemen, netwerkcomponenten en IT-middelen afhankelijk zijn?

Bij de kritische bedrijfsprocessen denken we wellicht direct aan die processen waarmee we ons geld verdienen, de primaire processen. Inderdaad veelal belangrijke en kritische processen. Maar we moeten niet vergeten dat er ook veel secundaire processen zijn die voor het voortbestaan van de organisatie kritisch kunnen zijn. Met deze secundaire processen verdienen we dan niet direct ons geld, maar ze zijn wel erg belangrijk om de primaire processen hun werk te kunnen laten doen.

We zullen dus zicht moeten hebben op de processen die ervoor zorgen dat onze organisatie werkt zoals ze werkt. Vervolgens zullen we goed moeten kijken welke informatiesystemen, netwerkcomponenten en IT-middelen een belangrijke bijdrage leveren aan die kritische bedrijfsprocessen. Juist voor deze systemen, componenten en middelen willen we het beheer goed inregelen. Waarom? Simpel: omdat uitval daarvan ons direct geld kost.

Klinkt weer eens erg cryptisch, maar geen nood. Een simpel voorbeeld: stel dat we een productiebedrijf zijn. Onze productiestraat is van groot belang en deze is inmiddels geheel geautomatiseerd. Tot zover niets bijzonders. Voor de toegang tot onze productiehal gebruiken we een geautomatiseerd toegangssysteem. Geen pasje, geen toegang, lekker veilig. Maar wat als het toegangssysteem hapert en de medewerkers niet naar binnen kunnen? Hoe snel kunnen we ervoor zorgen dat er een andere deur open gaat zodat de productie kan worden opgestart? Juist: het toegangssysteem hebben we nooit als kritisch gemarkeerd (en dat is misschien ook helemaal niet nodig), maar we hebben er wel enorme last van als de medewerkers een dag niet naar binnen kunnen en we een dag dus geen productie kunnen draaien.

We hebben het al vaker geschreven: processen kunnen we niet (of nauwelijks) beveiligen omdat een proces slechts een beschrijving is. De activiteiten en middelen die ervoor zorgen dat dat proces werkt, die kunnen we wel beschermen. Daarbij zagen we eerder al dat we ons kunnen richten op de informatiesystemen (inclusief netwerkcomponenten, IT-middelen, etc.) en op de assets en de mensen.

De moeilijkheid zit hem er in om de juiste relatie te leggen tussen die processen en informatiesystemen. Lukt ons dat dan kunnen we het beheer van die informatiesystemen die een belangrijke bijdrage leveren als eerste professionaliseren. De beschikbaarheid van deze systemen moeten gegarandeerd worden omdat bij uitval van dat systeem we daar last van ondervinden. Maar hoe snel ondervinden we er last van? Dat is een van de vragen die van belang is voor de inspanningen die we moeten verrichten.

Kan een proces 1 minuut, 1 uur, 1 dag, 1 week of 1 maand uit de lucht zijn? Wanneer ondervinden onze klanten (want daar doen we het voor, toch?) er last van en hoe lang duurt het voordat zij overstappen naar onze concurrent? Afhankelijk van het antwoord op die vraag nemen we een juiste set aan maatregelen om de kritische bedrijfsprocessen en informatiesystemen te beheersen. Daarbij moeten we kijken naar de gehele keten en ervoor zorgen dat alle onderdelen van die keten aan de gestelde beschikbaarheidseisen kunnen voldoen. De keten is zo zwak als de zwakste schakel, dat geldt net zo goed voor de continuïteit van de bedrijfsprocessen en de onderliggende informatiesystemen.