Tag: kritische bedrijfsprocessen

Begeleiding van nieuwe medewerkers

  door

Inmiddels is de nieuwe medewerker alweer een aantal dagen aan de slag. Het gaat goed en hij begint zijn draai aardig te vinden. Zijn introductie zit er op en we durven hem of haar steeds meer los te laten. Toch willen we nog wel wat controle houden en vertrouwen moet groeien dus daar nemen we de tijd voor.

De vraag:
Zijn er maatregelen genomen om te voorkomen dat nieuw en onervaren personeel schade veroorzaakt (kan veroorzaken) aan gevoelige systemen en kritische bedrijfsprocessen?

De systemen worden tegenwoordig steeds ingewikkelder en handleidingen of trainingen voor het gebruik van nieuwe systemen geven we inmiddels niet meer. Iedereen moet maar gewoon aan de slag en de systemen moeten maar “foolproof” zijn. Klinkt waarschijnlijk allemaal bekend.

Toch moeten we ons de vraag stellen of we onze gloednieuwe peperdure auto zomaar aan iemand meegeven zonder dat we weten of hij een rijbewijs heeft en als hij dat al heeft, hoe goed hij dan kan rijden. Dit zelfde geldt natuurlijk voor de gevoelige en kritische systemen.

Leuk hoor dat de nieuwe medewerker zijn certificaat voor dat systeem heeft, maar hoe goed kan hij er echt mee omgaan? En is hij bekend met de wijze waarop wij dat systeem hebben ingericht. Zet iemand voor het eerst in een rechts gestuurde auto en het is toch weer even wennen en uitkijken. Laat hem los op onze systemen en hij zal zich toch onze inrichting eigen moeten maken.

We zullen de medewerker dus moeten begeleiden. Dat is niet alleen erg vriendelijk van ons, maar kan ook grote problemen voorkomen. Hoeveel begeleiding de medewerker nodig heeft hangt af van zijn ervaring en zijn leercurve. Misschien hebben we aan een uur of een middag genoeg misschien moeten we een begeleidingstraject opzetten waar we een senior verantwoordelijk voor maken.

Doen we dat op een goede manier dan helpen we de nieuwe medewerker in het zadel en zorgen we ervoor dat de senior er (tijdelijk) een leuke nieuwe uitdaging bij krijgt. Iedereen blij, mits het allemaal niet te belerend wordt, natuurlijk.

Apart eigenlijk dat we veel inspanningen doen om nieuwe medewerkers te recruiten, te screenen, te beoordelen om ze vervolgens los te laten in de organisatie. Iedereen moet zijn eigen weg maar zien te vinden, alle informatie die ze nodig hebben staat op het intranet en als ze nog meer willen weten dan vragen ze het wel aan een collega of hun manager.

Maar hoe goed is ons intranet ingericht en hoe makkelijk is de informatie te vinden? Hoeveel weet de collega of manager eigenlijk van informatiebeveiliging? Of wordt het erg makkelijk afgedaan allemaal?

We zeiden het eerder al: we hebben maar een kans om een eerste indruk te maken en dat geldt zeker niet alleen voor informatiebeveiliging. We moeten dus niet stoppen met onze inspanningen zodra de medewerker zijn of haar handtekening onder het contract heeft gezet, nee, dan begint het pas.

Kritische bedrijfsprocessen en informatiesystemen

  door

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.

De kritische bedrijfsprocessen (en objecten)

  door

Voor dat we verder gaan is het goed om even in te zoomen op de kritische bedrijfsprocessen en de kritische objecten. We moeten immers wel de juiste zaken beschermen omdat we anders alsnog uit het veld kunnen worden geslagen. Niet geheel verrassend is de volgende vraag dan ook:

Zijn de kritische bedrijfsprocessen (en bedrijfsobjecten) van de organisatie inzichtelijk?

Hanteren we een top-down benadering op het gebied van integrale beveiliging dan moeten we ook redeneren vanuit de kritische bedrijfsprocessen die zo zijn ingericht dat we de doelstellingen van de organisatie (in termen van winst of omzet) kunnen realiseren. Omdat we geen oneindig beveiligingsbudget voor handen hebben moeten we goed kijken naar de wijze waarop we het budget inzetten. Daarbij moeten we natuurlijk die zaken als eerste aanpakken die voor het voortbestaan van onze organisatie van groot belang zijn. Oh ja, nog even voor de zekerheid: we implementeren geen maatregelen maar kijken natuurlijk eerst naar de operationele risico’s.

Nogal logisch is het kritische bedrijfsproces het primaire proces, maar was het maar zo eenvoudig. Veel organisaties hebben meerdere primaire processen. Kortweg: de processen waar we ons geld mee verdienen. Maar ja, die processen staan niet op zich en worden weer ondersteund door de secundaire processen. Kortweg: de processen die ons geld kosten. Het kan dus best zijn dat een secundair proces van groot belang is voor het voortbestaan van onze organisatie. Daarom moeten we dus niet alleen kijken naar de primaire processen maar juist ook naar de secundaire.

We gaan het nog een stukje ingewikkelder maken, ben ik bang. Een proces op zicht is niets, dat is slechts de term die we ergens aan hangen (ja, ja procesdeskundigen zullen het misschien anders omschrijven, sorry in dat geval). Processen worden ondersteund door informatie (geautomatiseerd en niet geautomatiseerd), assets (of materieel) en personen. Je kunt er allerlei definities aan hangen maar dat is op zich niet zo van belang. Het gaat hier om de uitgangspunten.

Willen we dus de kritische bedrijfsprocessen beveiligen dan kijken we nu naar de primaire en secundaire processen maar ook naar de informatie, assets en het personeel dat voor de uitvoering van die processen van belang is.

Het klinkt misschien allemaal ingewikkeld en niet zozeer als een taak die de Security Manager uit moet voeren om zijn of haar werk te kunnen doen. Toch zou het theoretisch allemaal wel mee moeten vallen. Als het goed is zijn de kritische bedrijfsprocessen en ondersteunende middelen namelijk al inzichtelijk. Hoe bestuurt de directie anders de organisatie?

We hoeven hiervoor dus misschien niet eens zelf de kritische bedrijfsprocessen inzichtelijk te maken maar kunnen misschien wel gebruik maken van de gegevens die in het kader van kwaliteitsmanagement of IT al eens inzichtelijk zijn gemaakt. Voordat we dus deze lastige oefening zelf uit gaan voeren moeten we eerst even op zoek wat er allemaal al beschikbaar is.

In een volwassen organisatie is al veel beschikbaar en op basis daarvan kunnen we ook een volwassen aanpak van beveiliging inrichten. Is de organisatie in zijn totaliteit nog niet zo ver dan moeten we ook even goed beseffen dat de beveiliging wel aan moet sluiten bij de volwassenheid van de totale organisatie.

Kijken we naar bijvoorbeeld de Capability Maturity Modellen (CMM) en komen we met de gehele organisatie op level 2 uit, dan heeft het nu nog niet zoveel zin om de beveiliging op level 4 of 5 in te richten (als we dat al ooit willen en kunnen bereiken). Sluit aan bij het volwassenheidsniveau van de organisatie en groei daar mee mee. Dan zijn we geen vreemde eend in de bijt en begrijpt iedereen ook waar we mee bezig zijn en waarom we dat doen.