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

2

Inleiding

6

1.1 1.2

6 6

Procesgerichte aanpak Aanwijzing voor gebruik

Beheerprocessen en de BIG

2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9

8

ISMS en PDCA Risicomanagement Incidentbeheer Patchmanagement Hardening Wijzigingsbeheer Configuratiebeheer Bedrijfscontinuïteitsbeheer Totaaloverzicht

8 10 11 13 15 16 19 21 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

Relaties met andere processen

Figuur 1 Procesgerichte aanpak

1.2 Aanwijzing voor gebruik 6

Uitvoer

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 risicoanalyses2, een Business Impact Analyse (BIA)3 en classificatie van informatie4. 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 Incidentbeheer7 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.

 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.

incidentbeheer

wijzigingsbeheer  Informatie over geplande wijzigingen en status daarvan.

configuratiebeheer  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).

Figuur 2 Incidentbeheer en relaties met de overige beheerprocessen

Incidentbeheer 

Wijzigingsbeheer

Oplossen van incidenten door uitgevoerde wijzigingen.



Informatie over wijzigingen die incidenten



veroorzaken.

 Incidentbeheer 

Informatie over geplande wijzigingen en status daarvan. Configuratiebeheer

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).

Informatie over en relaties tussen CIs, eventueel gerelateerde problemen8 of bekende



fouten9 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 Patchmanagement10 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. 



Verzoeken voor bepaling impact, goedkeuring, of evaluatie van standaard patch op de ICT-infrastructuur.

Patchmanagement 

Configuratiebeheer

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.

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. 15

Met opmaak: Nederlands (standaard)

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 

Configuratiebeheer

Informatie over de systeemconfiguratie.

 

Hardening 



Informatie over de systeemconfiguratie (baselines) van de verschillende CIs.

Wijzigingsbeheer

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. 



Verzoeken voor bepaling impact, goedkeuring, of evaluatie van wijzigingen op de beveiliging.

Tabel 3 Hardening en relaties met de overige beheerprocessen

2.6 Wijzigingsbeheer Wijzigingsbeheer13 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. (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.

 Informatie over en relaties tussen CIs die door een wijziging worden geraakt, onder andere ter ondersteuning van de impactanalyse.


incidentbeheer

wijzigingsbeheer  Informatie over geplande wijzigingen en status daarvan.

configuratiebeheer  Informatie over de wijziging van bij een wijziging betrokken CIs (koppelen wijziging aan CIs).

 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

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.


Figuur 5 Wijzigingsbeheer en relaties met de overige beheerprocessen

Wijzigingsbeheer 

Configuratiebeheer

Informatie over de wijziging (bijvoorbeeld statuswisseling) 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.

17


Incidentbeheer

Informatie over geplande wijzigingen en status daarvan.

 



Oplossen van incidenten door uitgevoerde wijzigingen.



Informatie over wijzigingen die incidenten veroorzaken.

Wijzigingsbeheer







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. 

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

Verzoeken voor bepaling impact, goedkeuring, of evaluatie van standaard



patch op de ICT-infrastructuur. 

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

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.

Tabel 4 Wijzigingsbeheer en relaties met de overige beheerprocessen

18

2.7 Configuratiebeheer Configuratiebeheer14 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).

Wijzigingen15 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

(ICT) Bedrijfscontinuïteitsbeheer / Beschikbaarheidsbeheer  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 (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 de wijziging van bij een wijziging betrokken CIs (koppelen wijziging aan CIs).

incidentbeheer

configuratiebeheer

wijzigingsbeheer  Informatie over en relaties tussen CIs die door een wijziging worden geraakt, onder andere ter ondersteuning van de impactanalyse.

 Informatie over en relaties tussen CIs, eventueel gerelateerde problemen of bekende fouten inclusief de workaround, ten behoeve van het registreren van incidenten (incidentrecord).  Informatie (bijvoorbeeld versienummer) over de CIs die door een patch worden geraakt

 Informatie over de systeemconfiguratie (baselines) van de verschillende CIs.

patchmanagement

hardening  Informatie over welke systemen worden geraakt door de patch, en of de patch überhaupt wel van toepassing is.

 Informatie over de systeemconfiguratie

Figuur 6 Configuratiebeheer en relaties met de overige beheerprocessen

Configuratiebeheer

Incidentbeheer

Informatie over en relaties tussen CIs, eventueel gerelateerde problemen17 of bekende fouten18 inclusief de workaround, ten



behoeve van het registreren van incidenten (incidentrecord). 

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).

Configuratiebeheer 

Wijzigingsbeheer

Informatie over en relaties tussen CIs die door een wijziging worden geraakt, onder andere ter ondersteuning van de



impactanalyse. 



Informatie over de wijziging (bijvoorbeeld statuswisseling) van bij een wijziging betrokken CIs (koppelen wijziging aan CIs).



Informatie over de ICT-infrastructuur en

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 de opbouw van de ICT-infrastructuur zodat



de ICT-infrastructuur, na een calamiteit, hersteld kan worden. 


Wijzigingen in de uitwijkinfrastructuur.

Patchmanagement

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.


Hardening

Informatie over de systeemconfiguratie



(baselines) van de verschillende CIs.





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

ICTdienstencontinuïteitsbeheer Bedrijfscontinuïteitsbeheer (BCM)

Afspraken (Service Level Agreements) 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


Informatiebeveiligingsplan

 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.

configuratiebeheer  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.

wijzigingsbeheer  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.

 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 

Incidentbeheer

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. 

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



Initiëren wijzigingen (bijvoorbeeld in 23

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 beschikbaarheid.


Configuratiebeheer

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 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.


Risicomanagement

 Informatie over de continuïteitsspecificaties



van de kritische bedrijfsprocessen en welke mate van bescherming tegen de gevolgen van een calamiteit noodzakelijk is.

Tabel 6 Bedrijfscontinuïteitsbeheer en relaties met de overige beheerprocessen

2.9 Totaaloverzicht In deze paragraaf wordt het complete overzicht van de procesrelaties weergegeven van de in de vorige paragraven behandelde beheerprocessen (zie hiervoor figuur 9).

24

Informatie Beveiligings Management Systeem (ISMS) en samenhang met de overige beheerprocessen

 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

Risicomanagement

 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.

 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.


 Informatie over en relaties tussen CIs die door een wijziging worden geraakt, onder andere ter ondersteuning van de impactanalyse.


De baselinetoets BIG Diepgaande risicoanalyse Privacy Impact Assessment

 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.

incidentbeheer

wijzigingsbeheer


Informatiebeveiligingsplan

 Informatie over de standaard of spoed patch.  Impactanalyses, goedkeuringen of adviezen voor bijstelling en evaluatie van wijzigingen vanwege mogelijk invloed op de ICTinfrastructuur.


 Initiëren wijzigingen voor aanpassingen van de ICTcomponenten.  Impactanalyses, goedkeuringen of adviezen voor bijstelling en evaluatie van wijzigingen vanwege mogelijk invloed op de beveiliging.


 Informatie over de wijziging van bij een wijziging betrokken CIs (koppelen wijziging aan CIs).

configuratiebeheer patchmanagement

hardening

 Informatie over de systeemconfiguratie

 Informatie over de systeemconfiguratie (baselines) van de verschillende CIs.  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  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).  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 ICTinfrastructuur, na een calamiteit, hersteld kan worden.  Wijzigingen in de uitwijkinfrastructuur.

Figuur 9 Totaaloverzicht procesrelaties 25

Bijlage 1: Matching Incident Prioritering en Alarmfasen Inleiding De Incident Prioritering Leidraad19 beschrijft de regels voor het toekennen van prioriteiten aan incidenten, met inbegrip van de definitie van wat een belangrijk incident is. De Incident Prioritering wordt herleid uit een tweetal factoren: urgentie en impact. Het toewijzen van de juiste prioriteit aan een incident is essentieel voor het activeren van de geschikte incident maatregelen. De prioriteit van een incident wordt meestal bepaald door de beoordeling van de impact en urgentie, waarbij: 

Urgentie de maat is voor hoe snel de oplossing van het incident vereist is.



Impact de maat is voor de omvang van het incident en van de mogelijke schade als gevolg van het incident voordat het kan worden opgelost.

Incident urgentie (categorieën) In de linker kolom van tabel 7 worden urgentie categorieën beschreven. Om de urgentie van een incident vast te stellen, kiest u de hoogste waarde van de desbetreffende categorie. Deze categorieën dienen slechts als voorbeeld. Incident impact (categorieën) In de bovenste rij van tabel 7 worden incident impact categorieën beschreven. Om de impact van het incident vast te stellen, kiest u de hoogste desbetreffende categorie. Deze categorieën dienen slechts als voorbeeld. Incident Prioriteiten Matrix De Incident Prioriteit (Incident Prioriteringsklassen) wordt verkregen door urgentie en impact tegen elkaar af te zetten. Als er klassen zijn gedefinieerd om urgentie en impact in te schalen, dan kan een Incident Prioriteit Matrix gebruikt worden om prioriteringsklassen te herleiden. In het tabel 7 zijn de klassen uitgewerkt met een code en kleuren. In deze tabel zijn de alarmfase 20 gematched op de verschillende incident prioriteringsklassen. Per alarmfase zijn de kenmerken, de impact, opschaling en bijzonderheden weergegeven.

19 20

Zie ook de ‘Incident Management en responsebeleid’ van de Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG). Zie ook de ‘Voorbeeld Informatiebeveiligingsbeleid Gemeenten’ van de Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG) 26

Incident impact (categorieën)

Incident urgentie (categorieën)

 Relatief veel personeel is geraakt door het incident en/of kan zijn/haar werk niet meer doen. Meerdere afdelingen zijn geraakt, de publieksbalie moet gesloten worden.  Inwoners van een gemeente zijn geraakt en/of lijden schade, op welke wijze dan ook, als gevolg van het incident. Persoonsgegevens zijn gecompromitteerd.  De financiële impact van het incident is (bijvoorbeeld) hoger dan €10.000.  Er is reputatie schade, de krant wordt gehaald.  Er zijn lichamelijk gewonden.

 Enig personeel is geraakt door het incident en/of kan zijn/haar werk niet meer doen, bijvoorbeeld een afdeling.  Enkele inwoners van een gemeente zijn geraakt en/of lijden schade, op welke wijze dan ook, als gevolg van het incident. Persoonsgegevens zijn gecompromitteerd.  De financiële impact van het incident is (bijvoorbeeld) hoger dan €1.000,- en lager dan €10.000,-.  Er is kans op reputatie schade.

 Enkele personeelsleden zijn geraakt door het incident en/of kunnen niet meer hun werk doen.  Enkele inwoners van een gemeente zijn geraakt en/of lijden schade, maar dit is zeer minimaal. Persoonsgegevens zijn gecompromitteerd.  De financiële impact van het incident is (bijvoorbeeld) lager dan €1.000, Er is geen kans op reputatie schade.

 De schade veroorzaakt door het incident neemt snel toe.  Werk dat moet worden hersteld door personeel is zeer arbeidsintensief.  Een groot incident kan worden voorkomen door bij een klein incident onmiddellijk te handelen.

1 (Om: Kritiek, R: Onmiddellijk, Opl: 1 uur)21  Alarm fase: 4  Kenmerk: ICT-incident is concern overstijgend (landelijk)  Impact: Impact op de gemeentelijke dienstverlening is manifest.  Opschaling: Mogelijk treedt de GRIP structuur in werking. Het kernteam is dan in beginsel adviserend en voert desgewenst coördinatie (binnen het ICT domein).  Bijzonderheden: Er is sprake van landelijke opschaling via de technische lijn (IBD  NCSC) of via de maatschappelijke lijn (NCC).

2 (Om: Hoog, R: 10 Minuten, Opl: 4 uur)  Alarm fase: 3  Kenmerk: Concernbreed ICT-incident (en mogelijk andere gemeenten)  Impact: Impact op de gemeentelijke dienstverlening wordt echt ervaren.  Opschaling: Kernteam komt bij elkaar. Afhankelijk van het incident (impact) treedt de GRIP structuur in werking. Bestuur, CIO en directies worden geïnformeerd.  Bijzonderheden: Melding aan CISO. Melding bij IBD (indien nodig). Gemeentelijke afdeling communicatie is vereist.

3 (Om: Medium, R: 1 uur, Opl: 8 uur)  Alarm fase: 2  Kenmerk: ICT-incident bij meerdere afdelingen.  Impact: Nog steeds een geïsoleerd probleem: bron - + effectbestrijding.  Opschaling: In beginsel niet. Probleem wordt opgelost door ICT.  Bijzonderheden: Melding aan CISO. Melding bij IBD indien nodig. Gemeentelijke communicatie is optioneel.

 De schade veroorzaakt door het incident neemt in de tijd aanzienlijk toe.  Er gaat werk verloren, maar dit is relatief snel te herstellen.

2 (Om: Hoog, R: 10 Minuten, Opl: 4 uur)  Alarm fase: 3  Kenmerk: Concernbreed ICT-incident (en mogelijk andere gemeenten)  Impact: Impact op de gemeentelijke dienstverlening wordt echt ervaren.  Opschaling: Kernteam komt bij elkaar. Afhankelijk van het incident (impact) treedt de GRIP structuur in werking. Bestuur, CIO en directies worden geïnformeerd.  Bijzonderheden: Melding aan CISO. Melding bij IBD (indien nodig). Gemeentelijke afdeling communicatie is vereist.

3 (Om: Medium, R: 1 uur, Opl: 8 uur)  Alarm fase: 2  Kenmerk: ICT-incident bij meerdere afdelingen.  Impact: Nog steeds een geïsoleerd probleem: bron - + effectbestrijding.  Opschaling: In beginsel niet. Probleem wordt opgelost door ICT.  Bijzonderheden: Melding aan CISO. Melding bij IBD indien nodig. Gemeentelijke communicatie is optioneel.

4 (Om: Laag, R: 4 uur, Opl: 24 uur)  Alarm fase: 1  Kenmerk: Lokaal ICT-incident bij één afdeling.  Impact: Oplosbaar probleem: bronbestrijding.  Opschaling: In beginsel niet. Probleem wordt opgelost door ICT.  Bijzonderheden: Melding aan CISO

3   

4  Alarm fase: 1  Kenmerk: Lokaal ICT-incident bij één afdeling.  Impact: Oplosbaar probleem: bronbestrijding.  Opschaling: In beginsel niet. Probleem wordt opgelost door ICT.  Bijzonderheden: Melding aan CISO

5 (Om: Zeer laag, R: 1 dag, Opl: 1 Week)  Alarm fase: 1  Kenmerk: Lokaal ICT-incident bij één afdeling.  Impact: Oplosbaar probleem: bronbestrijding.  Opschaling: In beginsel niet. Probleem wordt opgelost door ICT.  Bijzonderheden: Melding aan CISO

 De schade veroorzaakt door het incident neemt in de tijd maar weinig toe.  Het werk dat blijft liggen is niet tijdsintensief.

(Om: Medium, R: 1 uur, Opl: 8 uur) Alarm fase: 2 Kenmerk: ICT-incident bij meerdere afdelingen. Impact: Nog steeds een geïsoleerd probleem: bron - + effectbestrijding.  Opschaling: In beginsel niet. Probleem wordt opgelost door ICT.  Bijzonderheden: Melding aan CISO. Melding bij IBD indien nodig. Gemeentelijke communicatie is optioneel.

Tabel 7 Matching Incident Prioritering en Alarmfasen 21

OM staat voor Omschrijving, R staat voor Reactietijd en Opl staat voor Oplossing. 27

Bijlage 2: Definities Bron: http://www.exin-library.com/Player/eKnowledge/itildutchglossary.pdf Bekende fout: Een probleem dat een gedocumenteerde onderliggende oorzaak eneen workaround heeft. Bekende fouten worden tijdens hun levenscyclus gecreëerd en beheerd door probleembeheer. Bekende fouten kunnen ook worden geïdentificeerd door ontwikkeling en leveranciers. Configuratiebeheer: Het proces dat verantwoordelijk is om te garanderen dat de bedrijfsmiddelen, die nodig zijn om diensten te leveren op een adequate wijze, worden beheerd en dat accurate en betrouwbare informatie over die bedrijfsmiddelen beschikbaar is, wanneer en waar dat nodig is. Die informatie omvat details over hoe de bedrijfsmiddelen zijn samengesteld en details over relaties tussen bedrijfsmiddelen. Configuratiebeheerdatabase (CMDB): Een gegevensbestand dat wordt gebruikt om de configuratieregistraties op te slaan tijdens hun levenscyclus. Het configuratiebeheersysteem onderhoudt een of meer CMDBs, en elke CMDB slaat attributen van configuratie-items op. Evenals relaties met andere configuratie-items. Configuratie-item (CI): Elk component of ander dienstenbedrijfsmiddel dat beheert moet worden voor de levering van een ICT-dienst. Informatie over elk configuratie-item is geregistreerd in een configuratieregistratie binnen het configuratiebeheersysteem, en wordt onderhouden tijdens zijn levenscyclus door dienstenbedrijfsmiddelen- en configuratiebeheer. Wijzigingsbeheer is verantwoordelijk voor wijzigingen aan configuratie-items. Kenmerkende configuratie-items zijn bijvoorbeeld: ICT-diensten, hardware, software, gebouwen, mensen, en formele documentatie, zoals procesdocumentatie en diensten niveau overeenkomsten (DNO). Dienstenniveaubeheer: Het proces dat verantwoordelijk is om realiseerbare diensten niveau overeenkomsten af te spreken en garandeert dat daaraan wordt voldaan. Dienstenniveaubeheer is verantwoordelijk voor de garantie dat alle ICT-dienstenbeheerprocessen, operationele overeenkomsten en onderliggende contracten zijn afgestemd op de overeengekomen dienstenniveaudoelen. Dienstenniveaubeheer bewaakt dienstenniveaus, rapporteert erover, evalueert de dienstverlening regelmatig met de klant en identificeert vereiste verbeteringen. De Diensten Niveau Overeenkomst (DNO): Een overeenkomst tussen een ICT-dienstenaanbieder en een klant. De DNO beschrijft de ICT-dienst, legt dienstenniveaudoelen vast en definieert de verantwoordelijkheid van de ICT-dienstenaanbieder en de klant. Een afzonderlijke overeenkomst kan verschillende ICT-diensten of verscheidene klanten bevatten. Urgente wijziging / noodwijziging / emergency change: Een wijziging die zo snel mogelijk dient teworden geïntroduceerd. Bijvoorbeeld: om een ernstig incident op te lossen of een beveiligingspatch te implementeren. Het wijzigingsbeheerproces heeft gewoonlijk specifieke procedures voor het omgaan met noodwijzigingen. Normale wijziging / normal change: Een wijziging die geen noodwijziging of standaardwijziging is. Normale wijzigingen volgen de gedefinieerde stappen van het wijzigingsbeheerproces. Standaardwijziging / standaardchange: Een vooraf geautoriseerde wijziging met een laag risico, die relatief veel voorkomt en een procedure of werkinstructie volgt, zoals het resetten van een wachtwoord of een 28

nieuwe medewerker voorzien van standaardapparatuur. Voor het implementeren van een standaardwijziging zijn wijzigingsverzoeken niet vereist. Standaard wijzigingen worden geregistreerd en gevolgd met een ander mechanisme zoals een dienstverleningsverzoek. Wijziging: De toevoeging, verandering of verwijdering van alles dat een effect kan hebben op ICT-diensten. De scope is gericht op alle wijzigingen van alle architecturen, processen, instrumenten, meetwaarden en documentatie, en op wijzigingen van ICT-diensten en andere configuratie-items. Wijzigingsbeheer: Het proces dat verantwoordelijk is voor het beheersen van de levenscyclus van alle wijzigingen, om verbeteringen met minimale verstoring van de ICT-diensten uit te voeren. Wijzigingsverzoek / Verzoek tot Wijziging (VTW/RFC): Formeel verzoek voor een wijziging. Een wijzigingsverzoek bevat details van de voorgestelde wijziging, en kan op papier worden geregistreerd of elektronisch. De term wijzigingsverzoek wordt vaak verkeerd gebruikt als wijzigingsregistratie of de wijziging zelf.

29

Bijlage 3: Literatuur/bronnen Voor deze publicatie is gebruik gemaakt van onderstaande bronnen: Titel: Basisnormen Beveiliging en Beheer ICT-infrastructuur Wie: Platform Informatiebeveiliging (opgegaan in Platform voor Informatiebeveiliging (PvIB)) Uitgeverij: LEMMA BV Datum: 2003 ISBN-10: 90-5931-228-7 (niet meer leverbaar) Link: https://www.pvib.nl/links&collectionId=6254637 Titel: Studierapport Normen voor de beheersing van uitbestede ICT-beheerprocessen Wie: gezamenlijk initiatief van de NOREA en het Platform voor Informatiebeveiliging (PvIB) Met opmaak: Engels (Groot-Brittannië)

Datum: 12 december 2007 Link: http://www.norea.nl/readfile.aspx?ContentID=36811&ObjectID=345039&Type=1&File=0000021661_NoreaPvI

Gewijzigde veldcode

Bhandreiking.pdf

Met opmaak: Engels (Groot-Brittannië)

Titel: Foundations of IT Service Management, op basis van ITIL

Met opmaak: Engels (Groot-Brittannië)

Datum: september 2009 Uitgever: van Haren Publishing ISBN-13: 978-9077212714 Titel: Security Management Datum: 2004 Uitgever: TSO (The Stationery Office) ISBN-10: 0-11-330014-X ISBN-13: 978-0113300143

30

INFORMATIEBEVEILIGINGSDIENST V00R GEMEENTEN (IBD) NASSAULAAN 12 2514 JS DEN HAAG POSTBUS 30435 2500 GK DEN HAAG HELPDESK 070 373 80 11 ALGEMEEN 070 373 80 08 FAX 070 363 56 82 [email protected] WWW.IBDGEMEENTEN.NL

31

SAMENHANG BEHEERPROCESSEN EN INFORMATIEBEVEILIGING

Recommend Documents