SAMENHANG BEHEERPROCESSEN EN INFORMATIEBEVEILIGING

SAMENHANG BEHEERPROCESSEN EN INFORMATIEBEVEILIGING Een van de producten van de operationele variant van de Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG)

Colofon Naam document Samenhang beheerprocessen en informatiebeveiliging Versienummer 1.0 Versiedatum Februari 2015 Versiebeheer Het beheer van dit document berust bij de Informatiebeveiligingsdienst voor gemeenten (IBD). Copyright 2014 Kwaliteitsinstituut Nederlandse Gemeenten (KING). Alle rechten voorbehouden. Verveelvoudiging, verspreiding en gebruik van deze uitgave voor het doel zoals vermeld in deze uitgave is met bronvermelding toegestaan voor alle gemeenten en overheidsorganisaties. Voor commerciële organisaties wordt hierbij toestemming verleend om dit document te bekijken, af te drukken, te verspreiden en te gebruiken onder de hiernavolgende voorwaarden: 1. KING wordt als bron vermeld; 2. Het document en de inhoud mogen commercieel niet geëxploiteerd worden; 3. Publicaties of informatie waarvan de intellectuele eigendomsrechten niet bij de verstrekker berusten, blijven onderworpen aan de beperkingen opgelegd door KING; 4. Iedere kopie van dit document, of een gedeelte daarvan, dient te zijn voorzien van de in deze paragraaf vermelde mededeling. Rechten en vrijwaring KING is zich bewust van haar verantwoordelijkheid een zo betrouwbaar mogelijke uitgave te verzorgen. Niettemin kan KING geen aansprakelijkheid aanvaarden voor eventueel in deze uitgave voorkomende onjuistheden, onvolledigheden of nalatigheden. KING aanvaardt ook geen aansprakelijkheid voor enig gebruik van voorliggende uitgave of schade ontstaan door de inhoud van de uitgave of door de toepassing ervan. Met dank aan De expertgroep en de reviewgemeenten die hebben bijgedragen aan het vervaardigen van dit product. In samenwerking met De producten van de operationele variant van de Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG) zijn vervaardigd in samenwerking met: 2

Voorwoord De IBD is een gezamenlijk initiatief van de Vereniging van Nederlandse Gemeenten (VNG) en het Kwaliteitsinstituut Nederlandse Gemeenten (KING) en actief sinds 1 januari 2013. Aanleiding voor de oprichting van de IBD vormen enerzijds de leerpunten uit een aantal grote incidenten op informatiebeveiligingsvlak en anderzijds de visie Digitale Overheid 2017. De IBD is er voor alle gemeenten en richt zich op bewustwording en concrete ondersteuning om gemeenten te helpen hun informatiebeveiliging naar een hoger plan te tillen. De IBD heeft drie doelen: 1. Het preventief en structureel ondersteunen van gemeenten bij het opbouwen en onderhouden van bewustzijn als het gaat om informatiebeveiliging. 2. Het leveren van integrale coördinatie en concrete ondersteuning op gemeente specifieke aspecten in geval van incidenten en crisissituaties op het vlak van informatiebeveiliging. 3. Het bieden van gerichte projectmatige ondersteuning op deelgebieden om informatiebeveiliging in de praktijk van alle dag naar een hoger plan te tillen. De ondersteuning die de IBD biedt bij het ICT-Beveiligingsassessment DigiD is een voorbeeld van een dergelijk project. Hoe realiseert de IBD haar doelen? Om invulling te kunnen geven aan haar doelen is door de IBD op basis van de Baseline Informatiebeveiliging Rijksdienst (BIR) een vertaalslag gemaakt naar een baseline voor de gemeentelijke markt. Deze Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG) betreft twee varianten, een Strategische- én een Tactische Baseline. Beide varianten van de BIG zijn beschikbaar voor alle gemeenten op de website en community van de IBD, zodat door iedere gemeente tot implementatie van de BIG kan worden overgegaan. Bestuur en management hebben met deze baseline een instrument in handen waarmee zij in staat zijn om te meten of de organisatie in control is op het gebied van informatiebeveiliging. Om de implementatie van de Strategische en Tactische Baseline te ondersteunen, zijn door de IBD in samenwerking met de Taskforce Bestuur en Informatieveiligheid Dienstverlening (Taskforce BID) producten ontwikkeld op operationeel niveau. Dit heeft een productenportfolio opgeleverd, genaamd de Operationele Baseline Nederlandse Gemeenten. Onderhavig product is er één van. Naast een productenportfolio, heeft de IBD voor gemeenten ook een dienstenportfolio ontwikkeld. Voor een volledig overzicht van het producten- en dienstenportfolio, kunt u terecht op de website van de IBD. De gemeente is zelf verantwoordelijk voor het opstellen en/of uitvoeren en/of handhaven van de regels. Hierbij geldt: - Er is wetgeving waar altijd aan voldaan moet worden, zoals niet uitputtend: GBA, SUWI, BAG, PUN en WBP, maar ook de archiefwet. - Er is een gemeenschappelijk normenkader als basis: de Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG). - De gemeente stelt dit normenkader vast, waarbij er ruimte is in de naleving van dat kader voor afweging en prioritering op basis van het pas toe of leg uit principe. 3

Leeswijzer Dit product maakt onderdeel uit van de operationele variant van de Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG). Doel Het beschrijven van de samenhang tussen de beheerprocessen die in de BIG zijn beschreven, zodat de diverse beheerprocessen naadloos op elkaar aansluiten. Dit document geeft tevens inzicht in welke informatie als invoer wordt gebruikt voor de diverse beheerprocessen en welke beheerprocessen deze informatie dienen te leveren. Voor een gedetailleerde beschrijving van de afzonderlijke beheerprocessen wordt verwezen naar de afzonderlijke operationele producten van de BIG. Doelgroep Dit document is van belang voor de systeemeigenaren, technisch-, applicatiebeheerders en de ICTafdeling. Relatie met overige producten Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG) o Strategische variant van de Baseline Informatiebeveiliging voor Gemeenten o Tactische variant van de Baseline Informatiebeveiliging voor Gemeenten Informatiebeveiligingsbeleid van de gemeente Managementsysteem voor informatiebeveiliging/information Security Management Systeem (ISMS) Baselinetoets BIG Diepgaande risicoanalyse GAP- en impactanalyse Incident Management en responsebeleid Basis procedure configuratiebeheer Basis procedure wijzigingsbeheer Patchmanagement Hardening Business Continuity Management (BCM) Basis beveiligingsparagraaf Service Level Agreement (SLA) Uitbesteding ICT-diensten 4

Inhoud 1 Inleiding 6 1.1 Procesgerichte aanpak 6 1.2 Aanwijzing voor gebruik 6 2 Beheerprocessen en de BIG 8 2.1 ISMS en PDCA 8 2.2 Risicomanagement 10 2.3 Incidentbeheer 11 2.4 Patchmanagement 13 2.5 Hardening 15 2.6 Wijzigingsbeheer 16 2.7 Configuratiebeheer 19 2.8 Bedrijfscontinuïteitsbeheer 21 2.9 Totaaloverzicht 24 Bijlage 1: Matching Incident Prioritering en Alarmfasen 26 Bijlage 2: Definities 28 Bijlage 3: Literatuur/bronnen 30 5

1 Inleiding De Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG) heeft maatregelen beschreven die te maken hebben met diverse beheerprocessen. Voor de beheerprocessen die in dit document worden behandeld zijn afzonderlijke operationele BIG-producten opgeleverd. Dit document bevat geen handreikingen of aanvullend beleid met betrekking tot het gebruik en implementatie van de afzonderlijke beheerprocessen. Doel Het doel van dit document is het verkrijgen van inzicht in de relatie, de logische samenhang, tussen de beheerprocessen die relevant zijn voor de BIG. 1.1 Procesgerichte aanpak Beheer wordt over het algemeen ingericht volgens een procesgerichte aanpak, Information Technology Infrastructure Library (ITIL) is daar een voorbeeld van. In figuur 1 wordt hiervoor het gehanteerde model weergegeven. Beheerprocessen zijn opgebouwd uit activiteiten die zijn onder te verdelen in: plannen, implementeren, evalueren en onderhouden. Dit is beter bekend als de Plan-Do-Check-Act (PDCA)-cyclus. Ieder beheerproces bestaat met een doel. Dit doel wordt bereikt door het uitvoeren van een verzameling activiteiten. Deze activiteiten staan niet op zichzelf maar hangen met elkaar samen. Daarom spreken we van een proces. De trigger van het proces vormt de invoer, de resultaten van het proces de uitvoer. De samenhang met de andere processen wordt beschreven in de relaties. Proces Doelstellingen Invoer Proces Activiteiten Uitvoer Relaties met andere processen Figuur 1 Procesgerichte aanpak 1.2 Aanwijzing voor gebruik 6

Naast een korte beschrijving van het beheerproces ligt de nadruk vooral op de interactie tussen de beheerprocessen. Concreet betekent dit, wat is de in- en uitvoer voor de verschillende beheerprocessen. Dit document bevat dan ook geen handreikingen of aanvullend beleid met betrekking tot het gebruik en implementatie van de afzonderlijke beheerprocessen. Per beheerproces wordt aangegeven welke gegevens door het beheerproces worden geleverd (aangegeven door ) aan een ander beheerproces, en welke gegevens het ontvangt (aangegeven door )van een ander beheerproces. De uitvoer van het ene beheerproces is de invoer voor een ander beheerproces. Dit wordt steeds in een figuur en tabel weergegeven. 7

2 Beheerprocessen en de BIG In het kader van informatieveiligheid zijn er diverse beheerprocessen noodzakelijk. In dit hoofdstuk worden de belangrijkste uitgelicht. Daarmee is niet gezegd dat de niet genoemde beheerprocessen niet uitgewerkt dienen te worden. Als men het bekijkt vanuit de dreigingen die op gemeente afkomen, hebben een aantal beveiligingsbeheerprocessen topprioriteit. 2.1 ISMS en PDCA Een managementsysteem voor informatiebeveiliging/information Security Management Systeem (ISMS) 1 is binnen de gemeente noodzakelijk om informatieveiligheid ook over een langere tijd te laten werken. Het is hierbij van belang dat beveiligingsmaatregelen continue worden beoordeeld of ze (nog) passend zijn en indien nodig bijgestel worden. Het hebben van een ISMS is geen eenmalige activiteit, het is een voortdurend proces dat binnen de gemeente dient te worden uitgevoerd. Het ISMS legt de basis voor passende beveiligingsmaatregelen door bijvoorbeeld risicoanalyses 2, een Business Impact Analyse (BIA) 3 en classificatie van informatie 4. Een ISMS helpt gemeenten om de beveiligingsdoelstellingen te ondersteunen. Bijvoorbeeld door: Het faciliteren van bedrijfscontinuïteit. Het verbeteren van de manier hoe op informatiebeveiligingsincidenten wordt gereageerd. Het omgaan met verantwoording en rapportage. Het reduceren van kosten die nodig zijn om beveiligingsmaatregelen te implementeren. Het bijdragen aan een juiste beveiliging van middelen van de gemeente. Het bijdragen aan verbeterde interne controle over beveiliging. Hieronder worden de onderwerpen risicobeoordeling, GAP- en impactanalyse en het opstellen van een informatiebeveiligingsplan beschreven, aangezien dit de basis vormt voor passende beveiligingsmaatregelen. Risicobeoordeling In principe dient de gemeente te voldoen aan de maatregelen van de Tactische Baseline, waarbij ruimte is voor een afweging op basis van pas toe of leg uit. De Tactische Baseline is zo opgebouwd dat er, zonder de voor het basisniveau getroffen maatregelen aan te tasten, een verdieping bovenop gebouwd kan worden. Zo kan worden voldaan aan hogere of specialistische eisen. Voor de specialistische maatregelen voor afwijkende situaties of hogere beveiligingsniveaus dan het basisniveau, moet teruggegrepen worden naar een gerichte risicoafweging. De middelen hiervoor zijn: De baselinetoets BIG, om vast te stellen of een informatiesysteem door de maatregelen in de BIG voldoende beschermd wordt. De baselinetoets BIG doet een uitspraak over de impactniveaus voor vertrouwelijkheid, integriteit, beschikbaarheid en tevens de privacy. 1 Zie hiervoor ook het operationele product Information Security Management System van de Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG). 2 Zie hiervoor ook het operationele product Diepgaande Risicoanalysemethode gemeenten van de Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG). 3 Zie hiervoor ook het operationele product Baselinetoets BIG van de Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG). 4 Zie hiervoor ook het operationele product Handreiking dataclassificatie van de Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG). 8

Als er meer maatregelen nodig zijn: het hanteren van een vaste risicobeoordelingsaanpak, de diepgaande risicoanalyse. Deze risicoanalyseaanpak geeft ruimte voor het vaststellen van welke risico s onaanvaardbaar zijn en daarom moeten worden beperkt. Als de diepgaande risicoanalyse goed wordt uitgevoerd is de uitkomst de maatregelen die nodig zijn bovenop de BIG. De Privacy Impact Assessment (PIA) legt in de eerste plaats de risico s bloot van projecten die te maken hebben met privacy, en dragen bij aan het vermijden of verminderen van deze privacyrisico s. Op basis van de antwoorden van de PIA wordt op systematische wijze inzichtelijk gemaakt of er een kans is dat de privacy van de betrokkene wordt geschaad, hoe hoog deze is en op welke gebieden dit is. Het overblijvende risico dient beheerd te worden door middel van zorgvuldig opgestelde bedrijfsregels, procedures en controlemechanismen. Het kiezen van een standaard risicobeoordelingsmethode voor alle gemeenten is een van de belangrijkste onderdelen van het opzetten van het ISMS. Daarnaast kan het operationele BIGproduct voor het classificeren van bedrijfsmiddelen en gegevens van pas komen: Uitvoeren GAP- en impactanalyse De gemeente dient inzicht te hebben in de te beschermen bedrijfsinformatiesystemen en hun status ten opzichte van de Tactische Baseline. Door het uitvoeren van de GAP- en impactanalyse wordt inzicht verkregen in ontbrekende maatregelen, gemeentebreed of per informatiesysteem. De impactanalyse geeft daarnaast input aan het op te stellen informatiebeveiligingsplan. Opstellen informatiebeveiligingsplan Als bekend is welke maatregelen uit de impactanalyse en een eventuele aanvullende diepgaande risicoanalyse nog niet zijn geïmplementeerd, dienen deze maatregelen in een informatiebeveiligingsplan te worden opgenomen. In dit plan worden aan maatregelen actiehouders toegewezen, welke verantwoordelijk zijn voor de invoering van de maatregelen. Planning & Control cyclus (P&C-cyclus) Door het informatiebeveiligingsbeleid in te bedden in de reguliere Planning & Control (P&C)-cyclus en hierover door de afdelingen verantwoording af te laten leggen in reguliere voortgangsrapportages, heeft informatiebeveiliging een duidelijke rol in de verticale sturingskolom van een gemeente. De P&C-cyclus gaat over de beheersing en kwaliteitshandhaving van de bedrijfsvoeringcyclus/-processen en is veelal vastgelegd in de gemeentelijke begrotingssystematiek. Aansluiting hierbij voorkomt dat informatiebeveiliging als een eigenstandig onderwerp wordt behandeld en daardoor laag geprioriteerd wordt. Over het functioneren van de informatiebeveiliging wordt conform de P&C-cyclus binnen de gemeente en richting het college van burgemeester en wethouders (college B&W) verantwoording afgelegd door het management. Dit aansluiten bij de P&C-cyclus is noodzakelijk, omdat de in te voeren beveiligingsmaatregelen moeten worden ingepland en worden begroot. De middelen voor beveiligingsmaatregelen dienen door een goede onderbouwing op tijd aangevraagd te worden. Het ISMS moet effectief zijn over de langere termijn, in verband met het effectueren van informatiebeveiliging, en dient onderhouden te worden volgens de Plan-Do-Check-Act (PDCA)- cyclus. Na het vaststellen wat nodig is, worden maatregelen getroffen en wordt gecontroleerd of die maatregelen het gewenste effect sorteren (controle). Deze controle kan direct aanleiding geven tot bijsturing in de maatregelen. Ook kan het totaal van eisen, maatregelen en controle aan revisie toe zijn (evaluatie). Het goed doorlopen van 9

deze kwaliteitscirkel zorgt voor kwaliteitsbeheersing door continue controle en verbetering van het beveiligingsniveau. Verbetercyclus De basis van het managementsysteem is een verbetercyclus opgesteld, hierin zijn de volgende vier activiteiten noodzakelijk die de essentie van de PDCA-cyclus vormen: PLAN, Opstellen verbeterplan: verbetervoorstellen om de tekortkomingen op te heffen. DO, Uitvoeren verbeterplan: invoeren van de verbetervoorstellen. CHECK, Evalueren: om mogelijke tekortkomingen vast te stellen. ACT, Update processen: input van de check fase. Het ISMS wordt echter vaak als de ultieme oplossing gezien bij de invoering van informatiebeveiliging binnen organisaties. Echter het ISMS is geen doel op zich, net zo min als ITIL een doel op zich is. Het ISMS is het middel om beveiliging te laten werken en te verankeren binnen de organisatie. Het managementsysteem dient te worden afgestemd op de behoefte van de gemeente. De uitgebreidheid hangt onder andere af van de beschikbare specialisaties binnen de gemeenten. Vaak ligt bij een ISMS de nadruk op de documentatie en administratie en wordt voor de administratie naar een tool gegrepen. Een deel van de documentatie is echter maar noodzakelijk om de doelstelling met betrekking tot informatieveiligheid te ondersteunen. 5 De rest van documentatie is vooral bedoeld om belanghebbenden de gelegenheid te geven controles uit te voeren. De focus dient vooral te liggen op de eerste set aan documentatie. Uiteraard kan een tool wel bijdragen aan de effectiviteit van een ISMS. Om het ISMS als proces effectief te laten zijn, dient de directie dat proces actief te ondersteunen. Dit houdt in dat taken, verantwoordelijkheden en bevoegdheden gekoppeld dienen te worden aan personen om de (virtuele) beveiligingsorganisatie vorm te geven. Een van de operationele producten van de BIG is een functieprofiel van de Chief Information Security Officer (CISO). Daarnaast hebben ook andere personen een rol. 2.2 Risicomanagement Het primaire uitgangspunt voor informatiebeveiliging is en blijft risicomanagement en het is de basis voor passende beveiligingsmaatregelen (zie ook paragraaf 2.1 ISMS en PDCA ). Risicomanagement is het systematisch opzetten, uitvoeren en bewaken van acties om risico s te identificeren, te prioriteren en te analyseren. Om vervolgens voor deze risico s oplossingen te bedenken, te selecteren en uit te voeren. De BIG biedt al een vastgestelde set aan maatregelen die voor alle gemeenten geldt, echter er is ruimte voor pas toe en leg uit. Dat betekent dat op basis van een risicoafweging een maatregel in individuele gevallen niet van toepassing verklaard kan worden. Deze keuze dient wel te worden vastgelegd en verantwoord. Daarnaast kan men de instrumenten baselinetoets BIG en diepgaande risicoanalyse gebruiken. De baselinetoets BIG bevat een aantal vragenlijsten om te bepalen of de BIG voldoende dekking biedt. Zo niet, dan kan er een diepgaande risicoanalyse worden uitgevoerd. De baselinetoets BIG geeft ook uitsluitsel of een Privacy Impact Assessment (PIA) 6 noodzakelijk is. Deze instrumenten zijn aan 5 Als doelstelling wordt hier bedoeld: Informatieveiligheid over een langere periode op een steeds hoger niveau uitvoeren 6 Zie hiervoor ook het operationele product Privacy Impact Assessment van de Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG). 10

te bevelen bij nieuwe informatiesystemen of bij twijfel als men denkt dat er bij een bestaand informatiesysteem meer maatregelen nodig kunnen zijn. 2.3 Incidentbeheer Incidentbeheer 7 is belangrijk omdat 100% beveiligen niet bestaat en los daarvan, incidenten niet te voorkomen zijn. Het is niet de vraag óf er iets gaat gebeuren maar wanneer. De belangrijkste te verwachte incidenten kunnen van te voren bedacht worden. De bijpassende reactie- en escalatieprocedure kan dus ook van te voren uitgewerkt en geoefend worden. Incidenten staan vaak niet op zichzelf en kunnen een uitwerking hebben naar andere ketenpartners. Sommige incidenten doen zich niet bij één gemeente, maar bij meerdere gemeenten voor. Een incident dient daarom behalve intern opgelost soms ook extern geëscaleerd te worden. Zo kunnen anderen gemeenten gewaarschuwd worden en daarmee kan de impact van het incident zo klein mogelijk gehouden worden. Extern escaleren gebeurt naar de IBD. Zij hebben het overzicht, de contacten en de middelen om andere (keten)partners en gemeenten snel te kunnen waarschuwen. Ook hebben zij een directe ingang bij het Nationaal Cyber Security Center (NCSC). Zij bijlage 1 voor de match tussen incident prioritering en alarmfasen. Incidenten Een incident, in het kader van Incidentbeheer, is een gebeurtenis die de bedrijfsvoering negatief kan beïnvloeden. Incidentbeheer is het geheel van organisatorische maatregelen die ervoor moeten zorgen dat een incident adequaat gedetecteerd, gemeld en behandeld wordt. Dit om de kans op uitval van bedrijfsvoeringsprocessen of schade, ontstaan als gevolg van het incident, te minimaliseren dan wel te voorkomen. Incidentbeheer kan het beste aansluiten bij het bestaande Incidentbeheerproces van de ICTafdeling van de gemeente. Neem maatregelen om de oorzaak van het incident te blokkeren of te verwijderen, verminder de impact door verdere blootstelling van de gevoelige gegevens te voorkomen, maak een start om de bedrijfsprocessen te herstarten als deze gestopt waren als gevolg van het incident en zorg ervoor dat risico s die verband houden met dit incident worden gemitigeerd. 7 Zie hiervoor ook het operationele product Incidentmanagement en responsebeleid van de Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG). 11

(ICT) Bedrijfscontinuïteitsbeheer / Beschikbaarheidsbeheer Informatie (rapportages) over opgetreden incidenten die als (potentiële) calamiteit zijn aangemerkt met behulp waarvan onder andere gegevens over aard, duur (hersteltijden, reparatietijden) en dergelijke worden verkregen. Op basis hiervan worden de gerealiseerde beschikbaarheden bepaald. Voortgangsbewaking en statusinformatie van tijdens uitwijktesten opgetreden incidenten. incidentbeheer Oorzaken van beschikbaarheidgerelateerde incidenten (problemen). Normen voor het classificeren van incidenten als een (potentiële) calamiteit. Incidentmeldingen van tijdens uitwijktesten geconstateerde verstoringen en knelpunten. Oplossen van incidenten door uitgevoerde wijzigingen. Informatie over wjzigingen die incidenten veroorzaken. Informatie over geplande wijzigingen en status daarvan. wijzigingsbeheer Informatie (middels incidenten) over de afwijkingen die geconstateerd worden tussen de ICT-infrastructuur en de CMDB. Informatie over incidenten van bij een incident betrokken CIs (koppelen incident aan CIs, status bijwerken). configuratiebeheer Informatie over en relaties tussen CIs, eventueel gerelateerde problemen of bekende fouten inclusief de workaround, ten behoeve van het registreren van incidenten (incidentrecord). Figuur 2 Incidentbeheer en relaties met de overige beheerprocessen Incidentbeheer Oplossen van incidenten door uitgevoerde wijzigingen. Informatie over wijzigingen die incidenten veroorzaken. Incidentbeheer Informatie (vanuit incidenten) over de afwijkingen die geconstateerd worden tussen de ICT-infrastructuur en de CMDB. Informatie over incidenten van bij een incident betrokken configuratie-item (CI) (koppelen incident aan CIs, status bijwerken). Wijzigingsbeheer Informatie over geplande wijzigingen en status daarvan. Configuratiebeheer Informatie over en relaties tussen CIs, eventueel gerelateerde problemen 8 of bekende fouten 9 inclusief de workaround, ten behoeve van het registreren van incidenten (incidentrecord). 8 Een probleem is een ongewenste situatie die de nog onbekende oorzaak van een of meer bestaande of potentiële incidenten aanduidt. 9 Known errors zijn problemen waarvan de oorzaak met succes is vastgesteld (gereproduceerd). 12

Incidentbeheer Bedrijfscontinuïteitsbeheer Informatie (rapportages) over opgetreden incidenten die als (potentiële) calamiteit zijn aangemerkt met behulp waarvan onder andere gegevens over aard, duur (hersteltijden, reparatietijden) en dergelijke worden verkregen. Op basis hiervan worden de gerealiseerde beschikbaarheden bepaald. Voortgangsbewaking en statusinformatie van tijdens uitwijktesten opgetreden incidenten. Oorzaken van aan beschikbaarheid gerelateerde incidenten (problemen). Normen voor het classificeren van incidenten als een (potentiële) calamiteit. Incidentmeldingen van tijdens uitwijktesten geconstateerde verstoringen en knelpunten. Tabel 1 Incidentbeheer en relaties met de overige beheerprocessen 2.4 Patchmanagement Patchmanagement 10 is het proces waarmee patches op gecontroleerde beheerste (risico beperkende) wijze uitgerold kunnen worden. Patches zijn doorgaans kleine programma s die aanpassingen maken om fouten op te lossen, of verbeteringen aan te brengen in bestaande programmatuur en/of hardware. Behoudens de door de leverancier goedgekeurde beveiligingsupdates/patches worden er geen wijzigingen aangebracht in applicaties en infrastructurele programmatuur. Patchmanagement sluit het beste aan bij het proces wijzigingsbeheer van de ICT-afdeling. Het doel van Patchmanagement is tweeledig. Ten eerste is het gericht op het inzichtelijk maken van de actuele stand van kwetsbaarheden en toegepaste patches binnen de beheerde infrastructuur. Het tweede doel is op een zo efficiënt en effectief mogelijke wijze met zo min mogelijk verstoringen stabiele (veilige) systemen te creëren en te behouden. Patches Indien een patch beschikbaar is, dienen de risico's die verbonden zijn met de installatie van de patch te worden geëvalueerd (de risico's die verbonden zijn met de kwetsbaarheid dienen vergeleken te worden met de risico's van het installeren van de patch). Configuratiebeheer houdt zich bezig met het bijhouden van alle ICT-componenten van de gemeente, deze informatie is cruciaal om vast te stellen of een advies van de IBD of van een leverancier van toepassing is op de gemeentelijke ICT-infrastructuur en applicaties. Beveiligingsupdates/patches voor kwetsbaarheden waarvan de kans op misbruik hoog is en waarvan de schade hoog is (spoed-patch) is het zaak om zo spoedig mogelijk te patchen. Echter 10 Zie hiervoor ook het operationele product Patch Management voor gemeenten van de Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG). 13

minimaal binnen één week. Hierbij dient het wijzigingsbeheerproces verkort doorlopen te worden. De patch dient voor installatie wel altijd getest te worden. Minder kritische beveiligingsupdates/patches kunnen wijzigingsbeheerproces in om als (reguliere) wijziging verder behandeld te worden. Bijvoorbeeld het doorvoeren van de patch tijdens een gepland onderhoudsweekend. Vanuit het wijzigingsbeheerproces en na het uitvoeren van een impact assessment betreffende de wijziging, dient de patch uitvoerig te worden getest op de testomgeving van de geraakte systemen. Indien nog geen patch beschikbaar is, dient gehandeld te worden volgens het advies van de IBD of een andere Computer Emergency Response Team (CERT), zoals het Nationaal Cyber Security Centrum (NCSC). Na een succesvolle update zijn de gemeentelijke systemen weer up to date en dient de systeemdocumentatie en configuratiebeheerdatabase (CMDB) bijgewerkt te worden naar de laatste stand van zaken. Bijvoorbeeld nieuwe versienummers van de ICT-componenten. Testen, monitoring en rapportage Om vast te stellen of er nog bekende kwetsbaarheden in de eigen ICT- infrastructuur of applicaties aanwezig zijn kan men een kwetsbaarhedenscan of vulnerability scan (laten) uitvoeren. De daarbij gebruikte hulpmiddelen (tooling) kent van iedere soort hardware en software wat de laatste updates zijn en kan ook toetsen op het aanwezig zijn van bekende kwetsbaarheden. De vulnerability scan is een belangrijk onderdeel in het onderhouden van de informatieveiligheid binnen de eigen ICT-infrastructuur, immers apparatuur en software wordt geïnstalleerd en onderhouden en die veranderingen kunnen weer nieuwe kwetsbaarheden introduceren. Het resultaat is een rapport met alle mogelijke aanbevelingen welke geprioriteerd zijn op belangrijkheid. Met dit rapport kan men gericht patches installeren of systemen vervangen voor nieuwere versies. Het is aan te bevelen om eerdere scanrapportages te bewaren om verschillen te ontdekken, in ieder geval dient dit gedaan te worden voor belangrijke systemen. Alle veranderingen in systemen (open netwerkpoorten, toegevoegde services) dienen onderzocht te worden. Veranderde open netwerkpoorten en veranderde services zijn een belangrijke indicator voor het aanwezig zijn van malware, een ondernomen hack poging of een niet geautoriseerde wijziging. wijzigingsbeheer Informatie over de standaard of spoed patch. Impactanalyses, goedkeuringen of adviezen voor bijstelling en evaluatie van wijzigingen vanwege mogelijk invloed op de ICTinfrastructuur. Verzoeken voor bepaling impact, goedkeuring, of evaluatie van standaard patch op de ICT-infrastructuur. patchmanagement configuratiebeheer Informatie over welke systemen worden geraakt door de patch, en of de patch überhaupt wel van toepassing is. Informatie (bijvoorbeeld versienummer) over de CIs die door een patch worden geraakt Figuur 3 Patchmanagement en relaties met de overige beheerprocessen 14

Patchmanagement Wijzigingsbeheer Informatie over de standaard of spoed patch. Impactanalyses, goedkeuringen of adviezen voor bijstelling en evaluatie van wijzigingen vanwege mogelijk invloed op de ICT-infrastructuur. Patchmanagement Informatie (bijvoorbeeld versienummer) over de CIs die door een patch worden geraakt. Verzoeken voor bepaling impact, goedkeuring, of evaluatie van standaard patch op de ICT-infrastructuur. Configuratiebeheer Informatie over welke systemen worden geraakt door de patch, en of de patch überhaupt wel van toepassing is. Tabel 2 Patchmanagement en relaties met de overige beheerprocessen 2.5 Hardening Eén van de makkelijkste doelen voor een aanvaller is een niet goed actueel gehouden systeem met de laatste patches en beveiligingsupdates en een systeem waarbij functionaliteiten en privileges niet zijn teruggebracht tot het minimum dat noodzakelijk is voor het uitvoeren van de taak. Aanvallen op systemen kunnen ook plaatsvinden door het misbruiken van functies van informatiesystemen en hardware die standaard aan staan als men software of hardware koopt en installeert. Het proces om ervoor te zorgen dat functies die niet nodig zijn worden uitgeschakeld heet hardening, vrij vertaald, het harder maken van systemen. Hardening 11 wordt uitgevoerd door de ICT-afdeling van de gemeente. Hardening van de actieve infrastructuur, servers en netwerkcomponenten, is een belangrijke stap in de strijd om persoonlijke gegevens en informatie te beschermen. Dit proces werkt aan de hand van het elimineren van een aanval door het patchen van kwetsbaarheden en het uitschakelen van niet-wezenlijke diensten. Bij het hardenen van een ICT-componenten worden wijzigingen op ICT-componenten aangebracht en deze wijzigingen dienen onder verantwoordelijkheid van wijzigingsbeheer doorgevoerd te worden. Configuratiebeheer houdt zich bezig met het bijhouden van de gegevens van alle ICT-componenten van de gemeente, hieronder vallen ook de systeemconfiguraties van de ICT-middelen. Maatregelen Maatregelen voor hardening staan nooit op zichzelf, er dienen ook andere maatregelen te worden uitgevoerd. Zoals patchmanagement, het inzetten van antivirus oplossingen, het inzetten van logging, het inzetten van Firewalls en IDS en IPS 12, die allen bijdragen aan een verdediging in lagen strategie. Het regelmatig toepassen van leveranciers beveiligingsupdates/patches is de eerste stap om computersystemen te hardenen. 11 Zie hiervoor ook het operationele product Hardening beleid van de Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG). 12 Intrusion Detection System en Intrusion Prevention System. Met opmaak: Nederlands (standaard) 15

Testen, monitoring en rapportage Hardening kan deels getest worden door middel van de genoemde kwetsbaarhedenscan of vulnerability scan voor patchmanagement. Alle apparatuur moet regelmatig worden getest op bekende kwetsbaarheden zoals beschreven in de paragraaf 2.4 patchmanagement. wijzigingsbeheer Initiëren wijzigingen voor aanpassingen van de ICTcomponenten. Impactanalyses, goedkeuringen of adviezen voor bijstelling en evaluatie van wijzigingen vanwege mogelijk invloed op de beveiliging. Verzoeken voor bepaling impact, goedkeuring, of evaluatie van wijzigingen op de beveiliging. hardening configuratiebeheer Informatie over de systeemconfiguratie Informatie over de systeemconfiguratie (baselines) van de verschillende CIs. Figuur 4 Hardening en relaties met de overige beheerprocessen Hardening Informatie over de systeemconfiguratie. Hardening Initiëren wijzigingen voor aanpassingen van de ICT-componenten. Impactanalyses, goedkeuringen of adviezen voor bijstelling en evaluatie van wijzigingen vanwege mogelijk invloed op de beveiliging. Configuratiebeheer Informatie over de systeemconfiguratie (baselines) van de verschillende CIs. Wijzigingsbeheer Verzoeken voor bepaling impact, goedkeuring, of evaluatie van wijzigingen op de beveiliging. Tabel 3 Hardening en relaties met de overige beheerprocessen 2.6 Wijzigingsbeheer Wijzigingsbeheer 13 draagt er zorg voor dat wijzigingen op een beheerste wijze op de gemeentelijke ICT-infrastructuur (ICT-middelen en -diensten) efficiënt en effectief worden doorgevoerd. Met zo min mogelijk verstoring van de kwaliteit van de dienstverlening. Zodat deze dienstverlening blijft voldoen aan de eisen die hieraan zijn gesteld. 13 Zie hiervoor ook het operationele product Handreiking proces wijzigingsbeheer van de Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG). 16

Onder een wijziging wordt het toevoegen, veranderen of verwijderen van alles dat een effect kan hebben op ICT-diensten verstaan. Kwetsbaarheden die verholpen worden door een beveiligingsupdate (patch) zijn een ander voorbeeld van een wijziging. De implementatie van wijzigingen in ICT-voorzieningen en informatiesystemen behoren te worden beheerst door middel van formele procedures voor wijzigingsbeheer. In de procedure voor wijzigingsbeheer is minimaal aandacht besteed aan: Het aanmelden van wijzigingen. Wijzigingen verlopen via een formeel verzoek (Verzoek tot Wijziging (VTW) of Request for Change (RFC)) en bevat details van de voorgestelde wijziging. Het administreren van wijzigingen. Met een mogelijkheid om te registreren welke CIs bij de wijziging betrokken zijn (bevat een relatie met de CMDB). De impactanalyse van mogelijke gevolgen van de wijzigingen. Een goedkeuringsprocedure voor wijzigingen, waaronder nieuwe ICT-voorzieningen en afvoeren ICT-voorzieningen. Informatie over geplande wijzigingen en status daarvan, zodat plannen kloppend en actueel blijven bij wijzigingen van invloed op dienstverlening of uitwijk. Verzoeken voor bepaling impact, goedkeuring, of evaluatie van wijzigingen op beschikbaarheidimpact. (ICT) Bedrijfscontinuïteitsbeheer / Beschikbaarheidsbeheer Initiëren wijzigingen (bijvoorbeeld in verband met zwakke CIs) die beschikbaarheid/continuïteit dienstverlening verbeteren. Initiëren wijzigingen voor aanpassingen van de uitwijkinfrastructuur. Impactanalyses, goedkeuringen of adviezen voor bijstelling en evaluatie van wijzigingen vanwege mogelijk invloed op de beschikbaarheid dienstverlening en/ of uitwijkplannen. incidentbeheer Oplossen van incidenten door uitgevoerde wijzigingen. Informatie over wjzigingen die incidenten veroorzaken. wijzigingsbeheer Informatie over en relaties tussen CIs die door een wijziging worden geraakt, onder andere ter ondersteuning van de impactanalyse. configuratiebeheer Informatie over geplande wijzigingen en status daarvan. Informatie over de wijziging van bij een wijziging betrokken CIs (koppelen wijziging aan CIs). patchmanagement Informatie over de standaard of spoed patch. Impactanalyses, goedkeuringen of adviezen voor bijstelling en evaluatie van wijzigingen vanwege mogelijk invloed op de ICT-infrastructuur. Verzoeken voor bepaling impact, goedkeuring, of evaluatie van standaard patch op de ICT-infrastructuur. Verzoeken voor bepaling impact, goedkeuring, of evaluatie van wijzigingen op de beveiliging. Initiëren wijzigingen voor aanpassingen van de ICT-componenten. Impactanalyses, goedkeuringen of adviezen voor bijstelling en evaluatie van wijzigingen vanwege mogelijk invloed op de beveiliging. Figuur 5 Wijzigingsbeheer en relaties met de overige beheerprocessen hardening Wijzigingsbeheer Informatie over de wijziging (bijvoorbeeld statuswisseling) van bij een wijziging betrokken CIs (koppelen wijziging aan CIs). Configuratiebeheer Informatie over en relaties tussen CIs die door een wijziging worden geraakt, onder andere ter ondersteuning van de impactanalyse. 17

Wijzigingsbeheer Incidentbeheer Informatie over geplande wijzigingen en status daarvan. Oplossen van incidenten door uitgevoerde wijzigingen. Informatie over wijzigingen die incidenten veroorzaken. Wijzigingsbeheer Bedrijfscontinuïteitsbeheer Informatie over geplande wijzigingen en status daarvan, zodat plannen kloppend en actueel blijven bij wijzigingen van invloed op dienstverlening of uitwijk. Verzoeken voor bepaling impact, goedkeuring, of evaluatie van wijzigingen op beschikbaarheid. Wijzigingsbeheer Verzoeken voor bepaling impact, goedkeuring, of evaluatie van standaard patch op de ICT-infrastructuur. Wijzigingsbeheer Verzoeken voor bepaling impact, goedkeuring, of evaluatie van wijzigingen op de beveiliging. Initiëren wijzigingen (bijvoorbeeld in verband met zwakke CIs) die beschikbaarheid/continuïteit dienstverlening verbeteren. Initiëren wijzigingen voor aanpassingen van de uitwijkinfrastructuur. Impactanalyses, goedkeuringen of adviezen voor bijstelling en evaluatie van wijzigingen vanwege mogelijk invloed op de beschikbaarheid dienstverlening en/of uitwijkplannen. Patchmanagement Informatie over de standaard of spoed patch. Impactanalyses, goedkeuringen of adviezen voor bijstelling en evaluatie van wijzigingen vanwege mogelijk invloed op de ICT-infrastructuur. Hardening Initiëren wijzigingen voor aanpassingen van de ICT-componenten. Impactanalyses, goedkeuringen of adviezen voor bijstelling en evaluatie van wijzigingen vanwege mogelijk invloed op de beveiliging. Tabel 4 Wijzigingsbeheer en relaties met de overige beheerprocessen 18

2.7 Configuratiebeheer Configuratiebeheer 14 draagt er zorg voor dat de gegevens over de ICT-infrastructuur (ICT-middelen en -diensten) betrouwbaar worden vastgelegd en dat accurate en betrouwbare informatie over die ICT-middelen beschikbaar is, wanneer en waar dat nodig is. Deze gegevens over de ICTinfrastructuur worden aangeduid als configuratie-item (CI) en hebben betrekking op hard- en software, netwerkverbindingen en documentatie. Deze gegevens omvatten details over hoe de ICT-infrastructuur is samengesteld en details over relaties tussen de ICT-middelen onderling en de relaties met ICT-diensten. Configuratiebeheer zorgt ervoor dat geen CI wordt toegevoegd, aangepast, vervangen of verwijderd, zonder dat daarvan passende documentatie aanwezig is, zoals een goedgekeurd wijzigingsverzoek of een aangepaste specificatie. Het is de verantwoordelijkheid van configuratiebeheer om alleen wijzigingen op de ICT-infrastructuur toe te staan, die via wijzigingsbeheer zijn geautoriseerd. Wijzigingsbeheer is verantwoordelijk voor wijzigingen aan de ICT-middelen. Dit wordt bijgehouden in een Configuratie Beheer Database (CMDB) en deze dient ook als middel bij het identificeren van beveiligingsupdates en patches. Uitgangspunten (gemeentelijke beleidsregels) voor een goede werking van configuratiebeheer zijn onder andere: Alle bedrijfsmiddelen moeten geïdentificeerd zijn. Hiervan dienteen inventaris van worden bijgehouden. Alle informatie en de bedrijfsmiddelen die verband houden met ICT-voorzieningen dienen aan een 'eigenaar' (een deel van de organisatie) te zijn toegewezen. De verantwoordelijkheid voor specifieke beheersmaatregelen mag door de eigenaar worden gedelegeerd. Maar de eigenaar blijft verantwoordelijk voor een goede bescherming van de ICT-middelen. ICT-voorzieningen, zoals apparatuur, informatie en programmatuur van de organisatie, mogen niet zonder toestemming vooraf, van de locatie worden meegenomen. Alle classificaties van alle bedrijfskritische systemen zijn centraal vastgelegd door de CISO en dienen jaarlijks gecontroleerd te worden door de eigenaren. Het object van classificatie informatie is en dat er wordt geclassificeerd op het niveau van informatiesystemen (of informatieservices). Wijzigingen 15 op CIs kunnen door verschillende gemeentefunctionarissen en als gevolg van verschillende oorzaken aan configuratiebeheer gemeld worden, bijvoorbeeld: Bij het oplossen van een incident wordt een fout in de CMDB geconstateerd. Er wordt een wijziging om een incident of bekend probleem op te lossen doorgevoerd. Er wordt een nieuwe release van een applicatie doorgevoerd. De CIs worden in de CMDB gewijzigd aan de hand van de ontvangen gegevens, zodat de CMDB weer overeenkomt met de fysieke situatie van de CIs. 16 Er dient te worden vastgesteld of een wijziging op een CI gevolgen heeft op de gegevens van, of de relatie met andere CIs. De mogelijke wijzigingen worden in de CMDB doorgevoerd. Bij wijzigingen in de CMDB is geborgd dat de relaties consistent blijven. 14 Zie hiervoor ook het operationele product Handreiking proces configuratiebeheer van de Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG). 15 De wijziging moet goedgekeurd zijn door wijzigingsbeheer. De uitvoerder van een wijziging controleert of er mogelijk ook andere configuratie-items wijzigen als gevolg van een door hem gemaakte aanpassing in de ICTinfrastructuur. 16 Configuratiebeheer verifieert bij wijzigingsbeheer of de wijziging is goedgekeurd. 19

Informatie over de ICT-infrastructuur en uitwijkinfrastructuur voor opbouw/herstel infrastructuur. Informatie in verband met de analyse welke CIs bijdragen aan een dienst en het identificeren van zwakke CIs. (ICT) Bedrijfscontinuïteitsbeheer / Beschikbaarheidsbeheer Informatie van basisconfiguraties en van de opbouw van de ICT-infrastructuur zodat de ICT-infrastructuur, na een calamiteit, hersteld kan worden. Wijzigingen in de uitwijkinfrastructuur. incidentbeheer Informatie (middels incidenten) over de afwijkingen die geconstateerd worden tussen de ICT-infrastructuur en de CMDB. Informatie over incidenten van bij een incident betrokken CIs (koppelen incident aan CIs, status bijwerken). Informatie over en relaties tussen CIs, eventueel gerelateerde problemen of bekende fouten inclusief de workaround, ten behoeve van het registreren van incidenten (incidentrecord). configuratiebeheer Informatie over de wijziging van bij een wijziging betrokken CIs (koppelen wijziging aan CIs). Informatie over en relaties tussen CIs die door een wijziging worden geraakt, onder andere ter ondersteuning van de impactanalyse. wijzigingsbeheer patchmanagement Informatie (bijvoorbeeld versienummer) over de CIs die door een patch worden geraakt Informatie over welke systemen worden geraakt door de patch, en of de patch überhaupt wel van toepassing is. Informatie over de systeemconfiguratie (baselines) van de verschillende CIs. Informatie over de systeemconfiguratie Figuur 6 Configuratiebeheer en relaties met de overige beheerprocessen hardening Configuratiebeheer Informatie over en relaties tussen CIs, eventueel gerelateerde problemen 17 of bekende fouten 18 inclusief de workaround, ten behoeve van het registreren van incidenten (incidentrecord). Configuratiebeheer Informatie over en relaties tussen CIs die door een wijziging worden geraakt, onder andere ter ondersteuning van de impactanalyse. Configuratiebeheer Informatie over de ICT-infrastructuur en Incidentbeheer Informatie (vanuit incidenten) over de afwijkingen die geconstateerd worden tussen de ICT-infrastructuur en de CMDB. Informatie over incidenten van bij een incident betrokken CIs (koppelen incident aan CIs, status bijwerken). Wijzigingsbeheer Informatie over de wijziging (bijvoorbeeld statuswisseling) van bij een wijziging betrokken CIs (koppelen wijziging aan CIs). Bedrijfscontinuïteitsbeheer 17 Een probleem is een ongewenste situatie die de nog onbekende oorzaak van een of meer bestaande of potentiële incidenten aanduidt. 18 Known errors zijn problemen waarvan de oorzaak met succes is vastgesteld (gereproduceerd). 20

uitwijkinfrastructuur voor opbouw/herstel infrastructuur. Informatie in verband met de analyse welke CIs bijdragen aan een dienst en het identificeren van zwakke CIs. Informatie van basisconfiguraties en van Configuratiebeheer Informatie over welke systemen worden geraakt door de patch, en of de patch überhaupt wel van toepassing is. Configuratiebeheer Informatie over de systeemconfiguratie (baselines) van de verschillende CIs. de opbouw van de ICT-infrastructuur zodat de ICT-infrastructuur, na een calamiteit, hersteld kan worden. Wijzigingen in de uitwijkinfrastructuur. Patchmanagement Informatie (bijvoorbeeld versienummer) over de CIs die door een patch worden geraakt. Hardening Informatie over de systeemconfiguratie. Tabel 5 Configuratiebeheer en relaties met de overige beheerprocessen 2.8 Bedrijfscontinuïteitsbeheer Ondanks dat Bedrijfscontinuïteitsbeheer de gemeentelijke bedrijfsprocessen als uitgangspunt heeft, wordt in deze paragraaf ook beschikbaarheidsbeheer en ICT-dienstencontinuïteitsbeheer kort beschreven (zie figuur 7). Deze processen zijn alleen van belang als de gemeente een eigen ICTorganisatie heeft. (klant) Organisatie ICT-organisatie Bedrijfscontinuïteitsbeheer (BCM) Afspraken (Service Level Agreements) ICTdienstencontinuïteitsbeheer Beschikbaarheidsbeheer Figuur 7 Samenhang continuïteits-/beschikbaarheidsprocessen. Bedrijfscontinuïteitsbeheer Bedrijfscontinuïteitsbeheer (BCM) is een proces dat verantwoordelijk is voor het beheersen van risico s die een bedrijf ernstige schade kunnen toedienen. Het proces bevat het reduceren van 21

risico s tot een aanvaardbaar niveau en het maken van plannen voor herstel van de meest kritische bedrijfsprocessen wanneer de bedrijfsvoering verstoord is. Hierbij treft de organisatie de nodige maatregelen om ongeacht de omstandigheden de continuïteit van de meest kritische processen te garanderen. In geval van een onderbreking van één of meerdere van deze processen, dient de organisatie in staat te zijn snel en kordaat op te treden. Zodat de gevolgen van verstoringen binnen de kritische processen tot een acceptabel minimum beperkt blijven. Bedrijfscontinuïteitsbeheer zal de kans op een verstorend incident verkleinen en ervoor zorgen dat, als er toch een storing optreedt, de organisatie op gepaste wijze kan reageren. Zo kan de mogelijke schade door een storing drastisch wordt verkleind. Bedrijfscontinuïteitsbeheer bepaalt de doelstellingen, scope en vereisten voor ICT-dienstencontinuïteitsbeheer. Bedrijfscontinuïteitsplan Bedrijfscontinuïteitsplan (BCP) is een plan dat de vereiste stappen voor het herstellen van bedrijfsprocessen na een storing definieert. Het doel is om de onderbrekingstijd van de bedrijfsprocessen tot een minimum te beperken. Het plan identificeert ook de aanleiding voor activering, de maatregelen en belangrijke gegevens van de bedrijfsprocessen van de gemeente, de mensen die betrokken moeten worden, de communicatie, et cetera. ICT-dienstencontinuïteitsbeheer ICT-dienstencontinuïteitsbeheer is het proces dat verantwoordelijk is voor het beheersen van risico's die ICT-diensten ernstig kunnen schaden. Dit proces garandeert dat de ICTdienstenaanbieder de ICT-infrastructuur en de ICT-diensten na het optreden van een calamiteit zo snel mogelijk weer worden hersteld binnen de afspraken (overeengekomen dienstenniveaus) die hierover met de klanten zijn gemaakt. Dit doen zijdoor de risico's tot een aanvaardbaar niveau te reduceren en plannen te maken voor het herstel van ICT-diensten. ICT-dienstencontinuïteitsbeheer ondersteunt bedrijfscontinuïteitsbeheer. Hierbij wordt een calamiteit gedefinieerd als een ongeplande situatie waarbij verwacht wordt dat de duur van het niet-beschikbaar zijn van één of meer ICT-diensten afgesproken drempelwaarden wordt overschrijden. Het bepalen van de continuïteitsspecificaties (vaststellen uitwijk-/herstelniveaus) wordt niet tot de scope van het proces ICT-dienstencontinuïteitsbeheer gerekend omdat dit buiten de verantwoordelijkheid van de ICT-organisatie valt. Het is de taak van de klantenorganisatie om op basis van een risicoanalyse van de bedrijfsprocessen te bepalen in welke mate bescherming tegen de gevolgen van calamiteiten nodig is. Het is echter wel de taak van het proces ICTdienstencontinuïteitsbeheer om het door de klantenorganisatie verlangde niveau op haalbaarheid te toetsen en ervoor te zorgen dat dit naar duidelijke afspraken in Service Level Agreements (SLA s) wordt vertaald. De uitvoering van het proces ICT-dienstencontinuïteitsbeheer is in principe onafhankelijk van de gekozen ICT-infrastructuur. Bij het beschrijven van de normen die aan het operationeel deel van het proces worden gesteld, is echter uitgegaan van de variant waarin de gevolgen van een calamiteit worden opgevangen door de gegevensverwerking naar een uitwijkcentrum (uitbesteed of in eigen beheer) te verplaatsen en daar te hervatten. Beschikbaarheidsbeheer Beschikbaarheidsbeheer is het proces dat verantwoordelijk is om te garanderen dat ICT-diensten, op een zo kosteneffectieve manier, voldoen aan de eisen en wensen zoals afgesproken in SLA s. Beschikbaarheidsbeheer richt zich op het meten, registreren, analyseren en rapporteren van de beschikbaarheid van de ICT-dienstverlening en het initiëren van technische aanpassingen in de 22

ICT-infrastructuur om zo aan de afgesproken dienstenniveaudoelen voor beschikbaarheid te voldoen of de beschikbaarheid verder te verbeteren. Beschikbaarheidsbeheer houdt zich niet bezig met het niet beschikbaar zijn van ICT-diensten als gevolg van calamiteiten. Het beheersen van het calamiteitensituaties behoort tot het proces ICTdienstencontinuïteitsbeheer. Risicomanagement De baselinetoets BIG Diepgaande risicoanalyse Privacy Impact Assessment GAP- en impactanalyse Informatiebeveiligingsplan configuratiebeheer Informatie over de ICT-infrastructuur en uitwijkinfrastructuur voor opbouw/herstel infrastructuur. Informatie in verband met de analyse welke CIs bijdragen aan een dienst en het identificeren van zwakke CIs. Informatie van basisconfiguraties en van de opbouw van de ICT-infrastructuur zodat de ICT-infrastructuur, na een calamiteit, hersteld kan worden. Wijzigingen in de uitwijkinfrastructuur. Informatie over de continuïteitsspecificaties van de kritische bedrijfsprocessen en welke mate van bescherming tegen de gevolgen van een calamiteit noodzakelijk is. (ICT) Bedrijfscontinuïteitsbeheer / Beschikbaarheidsbeheer Initiëren wijzigingen (bijvoorbeeld in verband met zwakke CIs) die beschikbaarheid/continuïteit dienstverlening verbeteren. Initiëren wijzigingen voor aanpassingen van de uitwijkinfrastructuur. Impactanalyses, goedkeuringen of adviezen voor bijstelling en evaluatie van wijzigingen vanwege mogelijk invloed op de beschikbaarheid dienstverlening en/of uitwijkplannen. Informatie over geplande wijzigingen en status daarvan, zodat plannen kloppend en actueel blijven bij wijzigingen van invloed op dienstverlening of uitwijk. Verzoeken voor bepaling impact, goedkeuring, of evaluatie van wijzigingen op beschikbaarheidimpact. wijzigingsbeheer Oorzaken van beschikbaarheidgerelateerde incidenten (problemen). Normen voor het classificeren van incidenten als een (potentiële) calamiteit. Incidentmeldingen van tijdens uitwijktesten geconstateerde verstoringen en knelpunten. Informatie (rapportages) over opgetreden incidenten die als (potentiële) calamiteit zijn aangemerkt met behulp waarvan onder andere gegevens over aard, duur (hersteltijden, reparatietijden) en dergelijke worden verkregen. Op basis hiervan worden de gerealiseerde beschikbaarheden bepaald. Voortgangsbewaking en statusinformatie van tijdens uitwijktesten opgetreden incidenten. incidentbeheer Figuur 8 Bedrijfscontinuïteitsbeheer en relaties met de overige beheerprocessen Bedrijfscontinuïteitsbeheer Oorzaken van aan beschikbaarheid gerelateerde incidenten (problemen). Normen voor het classificeren van incidenten als een (potentiële) calamiteit. Incidentmeldingen van tijdens uitwijktesten geconstateerde verstoringen en knelpunten. Bedrijfscontinuïteitsbeheer Initiëren wijzigingen (bijvoorbeeld in Incidentbeheer Informatie (rapportages) over opgetreden incidenten die als (potentiële) calamiteit zijn aangemerkt met behulp waarvan onder andere gegevens over aard, duur (hersteltijden, reparatietijden) en dergelijke worden verkregen. Op basis hiervan worden de gerealiseerde beschikbaarheden bepaald. Voortgangsbewaking en statusinformatie van tijdens uitwijktesten opgetreden incidenten. Wijzigingsbeheer 23