Fysieke beveiliging: Eerst denken dan Agile doen (bespaart je een hoop poen) Over Thimo Keizer

Transcriptie

1 Fysieke beveiliging: Eerst denken dan Agile doen (bespaart je een hoop poen) Over Thimo Keizer Met een kritische, out of the box, analytische blik help ik organisaties met bedrijfskundige vraagstukken waaronder change management, integrale beveiliging en risico management. Af van de gebaande paden en onderzoeken waar de organisatie op een efficiënte en effectieve wijze verbeterd kan worden zonder dat de organisatie daar last van ondervindt. De bedrijfsvoering, de primaire en secundaire processen en de aspecten die voor de continuïteit van de organisatie van belang zijn worden daarbij door mij steeds als uitgangspunt genomen. Op strategisch en tactisch niveau zijn mijn adviezen gebaseerd op de groei in volwassenheid van de organisatie. Mijn ervaring op het gebied van change management, risico management en integrale beveiliging binnen organisaties als het Ministerie van Defensie, de ABN AMRO Bank en KPN Telecom aangevuld met mijn universitaire opleiding Bedrijfswetenschappen en HBO opleiding Marketing Management helpen mij daarbij. Waarom Het is mijn doel om organisaties te helpen om continuïteit te waarborgen door (beveiligings)risico s en kansen zichtbaar en begrijpelijk te maken, zodat de impact op omzet, kosten en imago kan worden beheerst. Hoe Ik ben een strategische en tactische business consultant met een specialisatie in operationeel risicobeheer voor fysieke beveiliging, informatiebeveiliging en bedrijfscontinuïteit. Wat Ik zorg ervoor dat organisaties hun doelen bereiken door Good Governance (goed bestuur) en maturity (volwassenheid) te waarborgen voor fysieke beveiliging, informatiebeveiliging en bedrijfscontinuïteit. Dat doe ik door het ontwikkelen en implementeren van beveiligingsbeleid, door het evalueren en aanpassen van dat beleid en door middel van quick scans en audits van het beleid en de getroffen beveiligingsmaatregelen. Copyright Thimo Keizer, Vlaardingen 2017 Voor meer informatie: Fysieke beveiliging: Eerst denken dan Agile doen (bespaart je een hoop poen) 1

2 Fysieke beveiliging: Eerst denken dan Agile doen (bespaart je een hoop poen) Een goed begin is het halve werk en beter ten halve gekeerd dan ten hele gedwaald, zomaar twee gezegden die we allemaal wel kennen en die van groot belang zijn voor fysieke beveiliging. Theoretisch weten we dat ook best wel maar in de praktijk zien we toch vooral dat we snel met allerlei fysieke beveiligingsmaatregelen aan de slag gaan zonder dat we de risico's goed in beeld hebben. In de waan van de dag verliezen we deze gezegden uit het oog. Laat ik daarom toelichten waarom deze twee gezegdes van belang zijn en hoe we dat in de praktijk toe kunnen passen. We beginnen met het eerste gezegde. Denken: Een goed begin is het halve werk Een goed begin betekent dat we vooral moeten starten met denken (door vragen te stellen en tussen de regels door te luisteren) en dan pas iets moeten gaan doen. Dat iets hoeft vervolgens helemaal niet te betekenen dat we allerlei dure, lastige beveiligingsmaatregelen treffen want er bestaat ook nog zoiets als het accepteren van risico s. En daar slaan we de spijker op zijn kop: risico s. Het uitgangspunt van fysieke beveiliging moet zijn dat we de risico s inzichtelijk hebben en dat we de onacceptabele risico s terug brengen naar een acceptabel niveau. Het beheersbaar maken van de onacceptabele risico s is dus het doel en de beveiligingsmaatregelen zijn de middelen die we daarvoor kunnen treffen. Daarbij moeten we ook gelijk beseffen dat we de onderkende risico s nooit voor 100% uit kunnen sluiten en dat we ook nooit alle risico s vooraf zullen onderkennen. Er is altijd wel een dreiging, dadertype, aanvalsmiddel, scenario of combinatie daarvan dat zich voor kan doen en er blijven altijd risico s waar we vooraf niet aan hebben gedacht. Hoe ondenkbaar een risico nu misschien nog is, er zullen zich altijd nieuwe risico s voordoen waarop we moeten anticiperen. Fysieke beveiliging: Eerst denken dan Agile doen (bespaart je een hoop poen) 2

3 Een risico analyse voer je niet eenmalig uit maar periodiek waarbij gekeken wordt of er nieuwe dreigingen onderkend kunnen worden en of de in het verleden bepaalde kans en impact nog juist zijn. Maar als we het hebben over onacceptabele risico s beheersbaar maken dan zijn we er natuurlijk nog niet. We moeten ook kijken waarop die risico s van toepassing zijn. Degene die de andere hoofdstukken gelezen hebben weten het inmiddels wel: ik redeneer altijd vanuit de continuïteit van een bedrijf. Dat pellen we vervolgens af naar de omzet, de kosten en het imago van het bedrijf omdat die aspecten er nu eenmaal voor zorgen dat er continuïteit is. (te) weinig omzet + (te) hoge kosten + slecht imago = de ultieme discontinuïteit (faillissement) Toch kunnen we de omzet, kosten en het imago niet zomaar met fysieke beveiligingsmaatregelen beschermen. Het is nog te abstract waardoor we het nog verder af moeten pellen. Kijken we verder dan wordt continuïteit bereikt door de primaire en secundaire processen die een organisatie uitvoert. De primaire processen zorgen daarbij met name voor de omzet, de secundaire processen zorgen daarbij met name voor de kosten en de combinatie daarvan zorgt voor het imago van de organisatie (kort door de bocht, ik weet het, maar voor nu voldoende lijkt me). Allemaal leuk en aardig maar ook de processen kunnen we niet zomaar met beveiligingsmaatregelen beschermen. We moeten dus nog een stap dieper. Die stap dieper betekent dat we op zoek moeten naar die informatie, dat materieel en die personen die ervoor zorgen dat de processen werken. De onderdelen die we met fysieke beveiligingsmaatregelen kunnen beschermen: informatie, materieel en personen Tel daarbij op dat we niet alles even sterk hoeven te beschermen. Niet alle informatie, materieel en personen zijn immers even kritisch voor de continuïteit van de organisatie en het budget is niet toereikend om alle denkbare beveiligingsmaatregelen te treffen (als we dit al zouden willen). We moeten rekening houden met de risk appetite van de organisatie als geheel maar ook met de risk tolerance voor specifieke processen, informatie, materieel en personen. De Committee Of Sponsoring Organizations of the Treadway Commision (COSO) geeft een mooie definitie van risk appetite die ik voor het doel van dit blog iets heb aangepast: De mate van risico, op een breed niveau, die een organisatie wil accepteren in het streven naar waarde. Het reflecteert de risicomanagement filosofie van de organisatie, en beïnvloed de cultuur en stijl van functioneren in de organisatie.... Risk appetite bepaalt de allocatie van middelen.... Risk appetite helpt de organisatie om effectief op risico s te reageren en deze te monitoren. Risk tolerance wordt door COSO geduid als de toepassing van risk appetite op specifieke doelstellingen maar daarbij kan het dus ook gaan om specifieke processen, informatie, materieel en personen. Fysieke beveiliging: Eerst denken dan Agile doen (bespaart je een hoop poen) 3

4 Ook geldt dat we niet alles op ieder moment even zwaar hoeven te beveiligen. We kunnen er nog een tijdsaspect aan toevoegen. Een gebouw dat overdag bijvoorbeeld een publieke functie heeft eist tijdens openingstijden andere maatregelen dan in de nachtelijke uren (denk bijvoorbeeld aan de ruimtelijke detectie die overdag uit staat). Maar bij het tijdsaspect kunnen we ook nog denken aan seizoensinvloeden. Neem als voorbeeld een Zamboni (een ijsdweilmachine die nodig is omdat schaatsbanen slijten en beschadigd raken door gebruik). Als ik er dan toch voor mag kiezen dan heb ik liever dat deze machine hartje zomer gestolen wordt dan op de dag van het Wereldkampioenschap langebaanschaatsen (natuurlijk kost de diefstal ons geld, ook al zijn we daarvoor waarschijnlijk verzekerd, maar de gevolgschade is in de zomer een stuk lager dan tijdens het WK). Kortom: Er moet goed nagedacht worden welke beveiligingsmaatregelen wel en niet wenselijk zijn, die maatregelen moeten we afleiden uit de risico s die we onderkennen en die moeten we dan weer afzetten in de tijd. Het afdekken van het risico is hierbij het doel en de beveiligingsmaatregelen zijn de middelen om dat doel te bereiken. Als we dat alles nu eens samen zouden kunnen vatten in één enkele vraag, hoe zou die vraag er dan uit zien? De vraag waar het bij fysieke beveiligingsrisico s allemaal om draait: Wat willen we, waarom, wanneer tegen welke bedreigingen beschermen? Een goed begin als het gaat om fysieke beveiliging is om deze vraag te stellen. Niet eenmalig overigens maar vaak, heel vaak, voor alle objecten (informatie, materieel en personen) die je wilt beveiligen en repeterend want we hanteren natuurlijk wel de Deming-cyclus. Resultaten uit het verleden geven geen immers garantie voor de toekomst. Daarna kun je, wat mij betreft, even achterover leunen (want dat is misschien wel de beste denkstand) en nadenken over hoe je de risico s met de juiste risico strategie beheersbaar wil maken. Wil (of kun) je het betreffende risico accepteren, mitigeren, overdragen of monitoren. Zodra je dat weet kun je op zoek naar de best passende combinatie van organisatorische, bouwkundige en elektronische beveiligingsmaatregelen waarbij je rekening houdt met de mate van reactie (alarmopvolging). De eerste klap is een daalder waard. Beginnen met nadenken en als het één en ander goed is uitgedacht kun je pas aan doen gaan denken. Voordeel hiervan is dat je flinke kosten kunt besparen omdat je je niet richt op het implementeren van allerlei onsamenhangende beveiligingsmaatregelen die nauwelijks bijdragen aan het beheersbaar maken van risico's, maar dat je de risico's leidend maakt en daar de te treffen combinatie aan beveiligingsmaatregelen op afstemt. Doen: Beter ten halve gekeerd dan ten hele gedwaald Zodra we gaan doen doet zich een nieuwe uitdaging voor. Vroeger (zeg maar tot gisteren) maakten we een plan van aanpak en dat voerden we als project uit. De zogenaamde waterval-methode waarvan Prince2 de bekendste is. Het voordeel daarvan was dat we wisten wat we moesten gaan doen en dat we dat project redelijk goed konden voorspellen. Eerlijk is eerlijk de nadelen waren dat we meestal de tijdslijnen niet haalden, het budget overschreden, het uiteindelijke resultaat toch niet helemaal was wat we vooraf wilden of het resultaat sloot niet meer aan bij de inmiddels gewijzigde omstandigheden. Maar ja, je moest Fysieke beveiliging: Eerst denken dan Agile doen (bespaart je een hoop poen) 4

5 wel een hele grote jongen (M/V) zijn om halverwege je project bij te sturen, laat staan stop te zetten. Inmiddels hoor je om je heen termen als Agile, Scrum en misschien zelfs DevOps. En hoewel dat vooral uit de softwareontwikkelingskant komt, wordt het tegenwoordig binnen organisaties ook op grote schaal op andere gebieden toegepast. Als we met fysieke beveiliging niet achter willen blijven (en dat willen we natuurlijk niet want we zijn een faciliterend, secundair proces dat zo goed mogelijk een bijdrage wil leveren aan de continuïteit van de organisatie) dan zullen we daar ook aan moeten geloven. Maar, ja. Wat de boer niet kent, dat vreet hij niet terwijl verandering van spijs doet eten. Willen we dat fysieke beveiliging serieus genomen wordt dan kunnen we de kont tegen de krib gooien maar daarmee doen we onszelf en het vakgebied te kort. Of we nu willen of niet. Ook wij moeten om naar een Agile manier van werken. Het voordeel van Agile werken (waarbij Scrum één van de bekendste en meest ingeburgerde manieren is) is dat we flexibel zijn. We kunnen tussentijds bijsturen (zonder gezichtsverlies voor een projectleider sterker nog: er is geen projectleider meer maar een Scrum Master en een ontwikkelteam dat als geheel verantwoordelijk is voor de resultaten). Begrijp me overigens goed: Agile werken is een middel en geen doel (en daar zie ik het binnen organisaties op dit moment nog wel eens verkeerd gaan) Om eer te doen aan het gezegde beter ten halve gekeerd dan ten hele gedwaald kunnen we met Sprints gaan werken, ook op het gebied van fysieke beveiliging. Maar dan hebben we natuurlijk wel wat achtergrond informatie over Agile werken nodig. Daarom wordt hieronder kort ingegaan op wat Scrum is en welke begrippen we daar (minimaal) voor moeten kunnen plaatsen. Scrum is een flexibele manier van werken waarbij er gewerkt in multidisciplinaire teams die in korte Sprints, met een vaste lengte van 1 tot 4 weken, werkende producten opleveren. Laat ik maar gelijk duidelijk zijn: ik vind het bij fysieke beveiliging toch meestal praktischer om een Sprint van 4 weken te trekken dan alles in 1 week te proppen maar goed aan jou de keus. De belangrijkste punten en begrippen die we moeten kennen worden hieronder kort toegelicht: Er is een Product Owner aangewezen. Hij of zij is de opdrachtgever die ervoor zorgt dat de rekening betaald wordt en die bepaald wat in welke volgorde moet gebeuren. In dit geval zou dat bijvoorbeeld de security manager kunnen zijn Naast de Product Owner zijn er een Scrum Master en een ontwikkelteam aangewezen. De Scrum Master begeleidt en helpt het team terwijl het team multidisciplinair is en verantwoordelijk is voor het afleveren van het product aan het einde van elke Sprint Fysieke beveiliging: Eerst denken dan Agile doen (bespaart je een hoop poen) 5

6 Er wordt gebruik gemaakt van User stories. Korte beschrijvingen (stories) van wat een gebruiker (user) wil en dat omschreven in gewone mensentaal. Hierin staat 'wie', 'wat', 'waarom' wil. Een User Story is niet gedetailleerd en moet passen op een post-it (nu weet je waarom het hele gebouw tegenwoordig volhangt met post-it s: men is aan het Scrummen) Er is een product backlog opgesteld waarop hetgeen allemaal ontwikkeld moet worden is opgenomen (de user stories dus) en waaraan nieuwe wensen en eisen kunnen worden toegevoegd (nieuwe user stories dus). In dit geval zou je bijvoorbeeld kunnen denken aan het ontwikkelen van beveiligingsbeleid, het uitvoeren van risico analyses, het selecteren van beveiligingsmaatregelen, het opstellen van beveiligingsplannen etc. Er wordt gewerkt in korte Sprints (van 1 tot 4 weken) waarin een werkend product wordt opgeleverd. Bijvoorbeeld het hele beveiligingsbeleid of een beperkt aantal hoofdstukken daarvan, de resultaten van een uitgevoerde risico analyse, de gekozen set aan beveiligingsmaatregelen of een opgesteld beveiligingsplan De User Stories worden op hun beurt uiteengerafeld in taken die tijdens de Sprint ontwikkeld en opgeleverd moeten worden. Welke User Stories en taken uitgevoerd worden, wordt in een Sprint planningsoverleg vastgesteld. In principe (volgens de theorie) moet een taak in 1 dag ontwikkeld kunnen worden maar wat mij betreft mag je er ook voor kiezen om taken te kiezen die je in 1 week uit kunt voeren (voel je vrij: het blijft een middel en geen doel op zich) Er is een Daily Scrum of Stand Up waarin de voortgang, de eventuele issues en de volgende te zetten stappen tijdens de Sprint kort besproken worden (ik weet het, het is vloeken in de kerk maar wat mij betreft mag je ook een weekly of monthly Sprint trekken, nogmaals: blijft een middel om een doel te bereiken) Aan het eind van een Sprint is er een Sprint review (tonen van het opgeleverde product) en een evaluatie (wat ging er goed, wat ging er fout en wat kunnen we daarvan leren). Het gaat te ver om alle ins- en outs van Agile en Scrum hier op te noemen dus voor meer informatie daarover wordt verwezen naar de bijbehorende literatuur (of Google natuurlijk). Geven we de belangrijkste aspecten visueel weer dan zou dat er als volgt uitzien: Fysieke beveiliging: Eerst denken dan Agile doen (bespaart je een hoop poen) 6

7 Eerst denken dan doen Nu we dit allemaal gelezen hebben, wat weten we dan? Kortweg weten we dat we eerst moeten denken voordat we kunnen gaan doen. We beginnen met de vraag: Wat willen we, waarom, wanneer tegen welke bedreigingen beschermen? Daarna kunnen we ons pas afvragen hoe we dat dan gaan doen. Kiezen we voor een Agile manier van werken dan levert die vraag ons een product backlog op waarop hetgeen allemaal ontwikkeld moet worden is opgenomen (user stories). We kunnen op basis van deze product backlog de Sprint planning opstellen waarop de User Stories en de uiteengerafelde taken zijn opgenomen zodat we de eerste Sprint(s) kunnen gaan trekken. Aan het eind van een sprint is er de Sprint review (tonen van het opgeleverde product) en een evaluatie (wat ging er goed, wat ging er fout en wat kunnen we daarvan leren). We zien nog wel eens dat met de invoering van Scrum de organisatie en haar medewerkers als een kip zonder kop rond beginnen te rennen (Sprints beginnen te trekken en overal maar post-it s aan de muur hangen) omdat er nogal eens gedacht wordt dat er vooral niet te lang nagedacht moet worden (want dat voelt teveel als de waterval-methode en dat lijkt tegenwoordig een methoda non grata, en ja dat is mijn persoonlijke vertaling). Het is natuurlijk helemaal niet waar dat we niet meer na hoeven te denken. Je moet nog steeds vooraf goed nadenken voordat je gaat doen. Wat mij betreft geldt het Pareto-principe daarbij nog steeds: 80% van de risico s kun je afdekken met 20% van de beveiligingsmaatregelen. Het grootste verschil tussen de waterval-methode en een Agile manier van werken is dat je niet zozeer het einddoel star voor ogen houdt en met alle macht probeert dat einddoel te bereiken maar dat je continu in ontwikkeling bent om het, op dat moment, beste resultaat te bereiken. Bijkomend voordeel van eerst denken en dan doen is dat het je een hoop poen bespaart: er kan een enorme kostenbesparing gerealiseerd worden bij een gelijkblijvend of zelfs beter beveiligingsniveau. Door eerst te denken pakken we namelijk de meest risicovolle zaken het eerst op (nog een Pareto-principe trouwens: 20% van de risico s zorgt voor 80% van de incidenten) en door Agile te doen kunnen we bijstellen waar dat nodig is (en pakken we die 20% van de beveiligingsmaatregelen die 80% van de risico's afdekken het eerst op). Fysieke beveiliging: Eerst denken dan Agile doen (bespaart je een hoop poen) 7