Handreiking

Samenhang Beheerprocessen en Informatiebeveiliging

Een operationeel kennisproduct ter ondersteuning van de implementatie van de Baseline Informatiebeveiliging Overheid (BIO)

2

ColofonNaam document Handreiking Samenhang Beheerprocessen en Informatiebeveiliging

Versienummer 2.01

Versiedatum Juni 2019

Versiebeheer Het beheer van dit document berust bij de Informatiebeveiligingsdienst voor gemeenten (IBD).

Vereniging van Nederlandse Gemeenten / Informatiebeveiligingsdienst voor gemeenten (IBD) (2018)

Tenzij anders vermeld, is dit werk verstrekt onder een Creative Commons Naamsvermelding-Niet Commercieel-Gelijk Delen 4.0 Internationaal licentie. Dit houdt in dat het materiaal gebruikt en gedeeld mag worden onder de volgende voorwaarden: 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. De IBD 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 de IBD en / of de Vereniging van Nederlandse Gemeenten;4. Iedere kopie van dit document, of een gedeelte daarvan, dient te zijn voorzien van de in deze paragraaf

vermelde mededeling.

Wanneer dit werk wordt gebruikt, hanteer dan de volgende methode van naamsvermelding: “Vereniging van Nederlandse Gemeenten / Informatiebeveiligingsdienst voor gemeenten”, licentie onder: CC BY-NC-SA 4.0.

Bezoek http://creativecommons.org/licenses/by-nc-sa/4.0 voor meer informatie over de licentie.

Rechten en vrijwaringDe IBD is zich bewust van haar verantwoordelijkheid een zo betrouwbaar mogelijke uitgave te verzorgen. Niettemin kan de IBD geen aansprakelijkheid aanvaarden voor eventueel in deze uitgave voorkomende onjuistheden, onvolledigheden of nalatigheden. De IBD 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 aanDe expertgroep en de reviewgemeenten die hebben bijgedragen aan het vervaardigen van dit product.

3

Wijzigingshistorie

Versie Datum Wijziging / Actie1 Juli 2013 Initiele versie1.01 Juni 2015 Kleine tekstuele aanpassingen1.02 Augustus 2016 Tekstuele aanpassingen en links hersteld2.0 Februari 2019 BIO update 2.01 Juni 2019 Links hersteld en kleine tekstuele aanpassing

Over de IBDDe IBD is een gezamenlijk initiatief van alle Nederlandse Gemeenten. De IBD is de sectorale CERT / CSIRT voor alle Nederlandse gemeenten en richt zich op (incident)ondersteuning op het gebied van informatiebeveiliging. De IBD is voor gemeenten het schakelpunt met het Nationaal Cyber Security Centrum (NCSC). De IBD ondersteunt gemeenten bij hun inspanningen op het gebied van informatiebeveiliging en privacy / gegevensbescherming en geeft regelmatig kennisproducten uit. Daarnaast faciliteert de IBD kennisdeling tussen gemeenten onderling, met andere overheidslagen, met vitale sectoren en met leveranciers. Alle Nederlandse gemeenten kunnen gebruikmaken van de producten en de generieke dienstverlening van de IBD.

De IBD is ondergebracht bij VNG Realisatie.

LeeswijzerDit product is een nadere uitwerking voor gemeenten van de Baseline Informatiebeveiliging Overheid (BIO). De BIO is eind 2018 bestuurlijk vastgesteld als gezamenlijke norm voor informatiebeveiliging voor alle Nederlandse overheden.

DoelHet doel van dit document is het beschrijven van de kritische IT beheerprocessen zodat deze 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.

DoelgroepDit document is van belang voor de CISO, de systeemeigenaren, applicatiebeheerders en de ICT-afdeling.

Relatie met overige producten Baseline Informatiebeveiliging Overheid (BIO) Informatiebeveiligingsbeleid van de gemeente Handreiking patchmanagement voor gemeenten Handreiking proces configuratiebeheer Handreiking incidentmanagement Handreiking proces wijzigingsbeheer Handreiking ISMS Handreiking hardening-beleid voor gemeenten Handreiking Model Continuiteitsstrategie Handreiking Continuiteitsplan

4

Inhoudsopgave

1. Inleiding....................................................................................................................................................................51.1. Procesgerichte aanpak.....................................................................................................................................................51.2. Aanwijzing voor gebruik...................................................................................................................................................5

2. Beheerprocessen en de BIO......................................................................................................................................62.1. ISMS en PDCA...................................................................................................................................................................62.2. Risicomanagement...........................................................................................................................................................82.3. Incidentmanagement.......................................................................................................................................................82.4. Patchmanagement...........................................................................................................................................................92.5. Hardening.......................................................................................................................................................................102.6. Wijzigingsbeheer............................................................................................................................................................112.7. Configuratiebeheer........................................................................................................................................................112.8. Bedrijfscontinuïteitsbeheer............................................................................................................................................12

Bijlage 1: Totaal overzicht................................................................................................................................................14

Bijlage 2: Definities...........................................................................................................................................................15

5

1. InleidingEen aantal kritische IT beheerprocessen zijn verankerd in de BIO en zijn een belangrijke drijfsveer om informatiebeveiliging goed in te richten en laten landen in de gemeente. Om de kritische IT beheerprocessen goed om elkaar aan te laten sluiten beschrijft dit document de samenwerking tussen de verschillende processen. Dit document bevat geen handreikingen of aanvullend beleid met betrekking tot het gebruik en implementatie van de afzonderlijke beheerprocessen.

1.1. Procesgerichte aanpakBeheer 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 ActiviteitenInvoer Uitvoer

Relaties met andere processen

ProcesDoelstellingen

Figuur 1: Procesgerichte aanpak

1.2. Aanwijzing voor gebruikNaast 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.

6

2. Beheerprocessen en de BIOIn 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, heeft een aantal beveiligingsbeheerprocessen topprioriteit.

2.1. ISMS en PDCAEen managementsysteem voor informatiebeveiliging, ook wel Information Security Management Systeem (ISMS)1 genaamd, 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 bijgesteld 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 Baselinetoets BIO, een Business Impact Analyse (BIA)3 en classificatie van informatie4. Evaluatie van maatregelen door middel van het beoordelen van opgetreden incidenten en uitgevoerde audits zijn ook input voor het ISMS.

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 controls en verplichte maatregelen uit de BIO.. De BIO kent drie beveiligingsniveau’s, waarbij niveau 3 niet van toepassing is op gemeenten. Afhankelijk van de te beschermen belangen en de risico’s kunnen daarmee passende maatregelen worden getroffen. Als de belangen en/of de risico’s hoog zijn, kan teruggegrepen worden naar een gerichte risicoafweging. De middelen hiervoor zijn:

De baselinetoets BIO, om vast te stellen of een informatiesysteem door de maatregelen in de BIO voldoende beschermd wordt. De baselinetoets BIO doet een uitspraak over de impactniveaus voor vertrouwelijkheid, integriteit, beschikbaarheid en tevens de privacy.

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

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. Een resultaat kan hier ook zijn dat er meer beveiligingsmaatregelen moeten worden genomen.

1 Zie hiervoor ook het operationele product ‘Information Security Management System’ 2 Zie hiervoor ook het operationele product ‘Diepgaande Risicoanalysemethode gemeenten’ 3 Zie hiervoor ook het operationele product ‘Baselinetoets BIO’ 4 Zie hiervoor ook het operationele product ‘Handreiking dataclassificatie’.

7

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 BIO-product 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 BIO.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 informatiebeveiliging 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. Het college legt op haar beurt weer horizontaal verantwoording aan de raad af en verticaal aan de stelselverantwoordelijken. 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 (check). Deze controle kan direct aanleiding geven tot bijsturing in de maatregelen. Ook kan het totaal van eisen, maatregelen en controle aan revisie toe zijn (check). Het goed doorlopen van deze kwaliteitscirkel zorgt voor kwaliteitsbeheersing door continue controle en verbetering van het beveiligingsniveau.

Verbetercyclus

De basis van het managementsysteem is een verbetercyclus, 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. Waar nodig moet een en ander worden bijgesteld.

8

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 (GRC)5 tool gegrepen. Een deel van de documentatie is echter maar noodzakelijk om de doelstelling met betrekking tot informatieveiligheid te ondersteunen.6 De rest van documentatie is vooral bedoeld om belanghebbenden de gelegenheid te geven controles uit te voeren. De focus tijdens het opzetten 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 CISO, proceseigenaren en het MT hebben alleen belangrijke rol die ze goed dienen op te pakken en dit is noodzakelijk om informatiebeveiliging op een goed niveau te krijgen en houden.

2.2. RisicomanagementHet 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 BIO 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 BIO’ en ‘diepgaande risicoanalyse’ gebruiken. De baselinetoets BIO bevat een aantal vragenlijsten om te bepalen of de BIO voldoende dekking biedt. Zo niet, dan kan er een diepgaande risicoanalyse worden uitgevoerd. De baselinetoets BIO geeft ook uitsluitsel of een Data Protection Impact Assessment (DPIA)7 noodzakelijk is. Deze instrumenten zijn aan te bevelen bij nieuwe informatiesystemen of bij wijzigingen op een bestaand informatiesysteem.

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

5 GRC staat voor Governance, Riskmanagement & Compliance6 Als doelstelling wordt hier bedoeld: “Informatieveiligheid over een langere periode op een steeds hoger niveau uitvoeren”7 Zie hiervoor ook het operationele product ‘Privacy Impact Assessment’.8 Zie hiervoor ook het operationele product ‘Incidentmanagement en responsebeleid’

9

Incidenten

Een incident, in het kader van incidentmanagement, is een gebeurtenis die de bedrijfsvoering negatief kan beïnvloeden. Incidentmanagement 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.

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 en zorg ervoor dat risico’s die verband houden met dit incident worden gemitigeerd. Bedenk dat er achter een incident een dieperliggende oorzaak kan zitten, dus het oplossen kan bestaan uit een eenvoudige (nood) oplossing gevolgd door een structurele aanpak. Een voorbeeld: een openstaande netwerkpoort kan eenvoudig worden dichtgezet, er kan ook daarna worden onderzocht waarom een bepaalde poort is opengezet, zijn beheer processen wel gevolgd? Evaluatie van het incident is belangrijk om ervan te leren en met een structurele oplossing te komen.

2.4. PatchmanagementPatchmanagement9 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 moet het proces wijzigingsbeheer van de ICT-afdeling volgen.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 IBD10 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 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 het gewone 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 (CBDB) bijgewerkt te worden naar de laatste stand van zaken. Bijvoorbeeld nieuwe versienummers van de ICT-componenten.

9 Zie hiervoor ook het operationele product ‘Patch Management voor gemeenten’.10 https://www.informatiebeveiligingsdienst.nl/product/stappenplan-aansluiten-bij-de-ibd-2/

10

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) zoekt in het netwerk en kent van veel soorten 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 van de scan is een rapport met alle mogelijke aanbevelingen welke geprioriteerd zijn op belangrijkheid. Met dit rapport kan men gericht kijken naar de kwetsbaarheden in de systemen, 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.

2.5. HardeningEén van de makkelijkste doelen voor een aanvaller is een niet goed actueel gehouden systeem met de laatste patches en beveiligingsupdates waardoor de kans op kwetsbaarheden een stuk groter is. Een systeem waarbij functionaliteiten en privileges niet zijn teruggebracht tot het minimum dat noodzakelijk is voor het uitvoeren van de taak vormt ook een makkelijk doel. 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. Hardening11 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 en is nodig om de basis op orde te hebben. 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. Patchmanagement, het inzetten van antivirus oplossingen, het inzetten van logging, het inzetten van Firewalls en IDS, IPS12, SIEM13, etc, dragen allen bij aan een verdediging in lagen strategie.

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.

11 Zie hiervoor ook het operationele product ‘Hardening beleid’.12 Intrusion Detection System en Intrusion Prevention System.13 security information and event management

11

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

Onder een wijziging wordt het toevoegen, veranderen of verwijderen van alles dat een effect kan hebben op ICT-diensten verstaan.

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

De impactanalyse van mogelijke gevolgen van de wijzigingen. Een goedkeuringsprocedure voor wijzigingen, waaronder nieuwe ICT-voorzieningen en afvoeren ICT-voorzieningen.

2.7. ConfiguratiebeheerConfiguratiebeheer15 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 ICT-infrastructuur 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 ConfigurationmanagementDatabase (CBDB) 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. Hier dient een 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 minimaal jaarlijks of bij grote wijzigingen gecontroleerd te worden door de eigenaren.

14 Zie hiervoor ook het operationele product ‘Handreiking proces wijzigingsbeheer’ 15 Zie hiervoor ook het operationele product ‘Handreiking proces configuratiebeheer’

12

Wijzigingen16 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 CBDB 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 CBDB gewijzigd aan de hand van de ontvangen gegevens, zodat de CBDB weer overeenkomt met de fysieke situatie van de CIs. 17 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 CBDB doorgevoerd. Bij wijzigingen in de CBDB is geborgd dat de relaties consistent blijven.

2.8. BedrijfscontinuïteitsbeheerOndanks dat Bedrijfscontinuïteitsbeheer de gemeentelijke bedrijfsprocessen als uitgangspunt heeft, wordt in deze paragraaf ook beschikbaarheidsbeheer en ICT-dienstencontinuïteitsbeheer kort beschreven (zie figuur 7).

Bedrijfscontinuïteitsbeheer (BCM)

ICT-dienstencontinuïteitsbeheer

Beschikbaarheidsbeheer

ICT-organisatie(klant) Organisatie

Afspraken(Service Level Agreements)

Figuur 2: Samenhang continuïteits-/beschikbaarheidsprocessen.

Bedrijfscontinuïteitsbeheer

Bedrijfscontinuïteitsbeheer (BCM) is een proces dat verantwoordelijk is voor het beheersen en zo snel mogelijk herstellen van risico’s die een bedrijf ernstige schade kunnen toedienen. Het proces bevat het reduceren van 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 impact door een storing drastisch wordt verkleind. Bedrijfscontinuïteitsbeheer bepaalt de doelstellingen, scope en vereisten voor ICT-dienstencontinuïteitsbeheer.

16 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 ICT-infrastructuur.17 Configuratiebeheer verifieert bij wijzigingsbeheer of de wijziging is goedgekeurd.

13

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 ICT-dienstenaanbieder 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 zij door 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 ICT-dienstencontinuï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 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 ICT-dienstencontinuïteitsbeheer.

Bijlage 1: Totaal overzicht

Bijlage 2: Definities

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 (CBDB): Een gegevensbestand dat wordt gebruikt om de configuratieregistraties op te slaan tijdens hun levenscyclus. Het configuratiebeheersysteem onderhoudt een of meer CBDBs, en elke CBDB 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 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.

Kijk voor meer informatie op:www.informatiebeveiligingsdienst.nl

Nassaulaan 122514 JS Den HaagCERT: 070 373 80 11 (9:00 – 17:00 ma – vr)CERT 24x7: Piketnummer (instructies via voicemail)info@IBDGemeenten.nl / incident@IBDGemeenten.nl