Handreiking

Procedure nieuwe ICT-voorzieningen

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

2

Colofon Naam document

Handreiking Procedure nieuwe ICT voorzieningen

Versienummer

2.0

Versiedatum

Maart 2019

Versiebeheer

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

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

Tenzi j anders vermeld, i s 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: Al le 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. Publ icaties 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 d e 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 vrijwaring

De 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 na latigheden. 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 aan

De expertgroep en de reviewgemeenten die hebben bijgedragen aan het vervaardigen van dit product.

3

Wijzigingshistorie

Versie Datum Wijziging / Actie

1.0 Juni 2014 Eerste versie

1.0.1 Augustus 2016 Taskforce BID verwijderd, WBP vervangen door Wbp, GBA vervangen

door BRP

2.0 Maart 2019 BIO update

Over de IBD De IBD is een gezamenlijk initiatief van a lle Nederlandse Gemeenten. De IBD is de sectorale CERT / CSIRT voor a lle

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 vi tale sectoren en met leveranciers. Al le Nederlandse gemeenten kunnen gebruikmaken van de

producten en de generieke dienstverlening van de IBD.

De IBD is ondergebracht bij VNG Realisatie.

Leeswijzer Dit product i s een nadere uitwerking voor gemeenten van de Baseline Informatiebeveiliging Overheid (BIO). De BIO is

eind 2018 bestuurlijk vastgesteld als gezamenlijke norm voor informatiebeveiliging voor a lle Nederlandse overheden.

Doel Het doel van dit document is om aanwijzingen te geven voor het vastleggen van de verschillende s tappen die

noodzakelijk zijn om nieuwe versies, releases of updates van ICT-voorzieningen goed te keuren alvorens deze in

productie worden genomen.

Doelgroep

Dit document is van belang voor de CISO, de systemeigenaren, applicatiebeheerders en de ICT-afdeling.

Relatie met overige producten • Baseline Informatiebeveiliging Overheid (BIO)

• Informatiebeveiligingsbeleid van de gemeente

• ICT-beheer

• Uitbesteding ICT-diensten

• Procedure configuratiebeheer

• Procedure wijzigingsbeheer

• Service Level Agreements (SLA)

• Verwerkersovereenkomsten

• (ICT)-contracten

4

Verwi jzingen naar de Baseline Informatiebeveiliging voor de Overheid (BIO)

14.1.1 Analyse en specificatie van informatiebeveiligingseisen

14.2.9 Systeemacceptatietests

15.1.2 Opnemen van beveiligingsaspecten in leveranciersovereenkomsten

15.1.3 Toeleveringsketen van informatie- en communicatietechnologie

Wat is er veranderd ten opzichte van de BIG?

Er zi jn worden meer eisen gesteld bij de inkoop van nieuwe ICT voorzieningen. Overeenkomsten met leveranciers

behoren eisen te bevatten die betrekking hebben op de informatiebeveiligingsrisico’s in verband met de

toeleveringsketen van de diensten en producten op het gebied van informatie- en communicatietechnologie.

5

Inhoudsopgave

1. Inleiding ...............................................................................................................................................................................6

1.1. Aanwijzing voor gebruik.......................................................................................................................................................6

2. Handreiking goedkeuringsprocedure .................................................................................................................................7 2.1. Zakelijke goedkeuring ..........................................................................................................................................................9 2.2. Functionele goedkeuring ...................................................................................................................................................10

2.3. Beveiligingsgoedkeuring ....................................................................................................................................................12 2.4. Technische goedkeuring ....................................................................................................................................................13

Bijlage 1: Definities .....................................................................................................................................................................14

Bijlage 2: Literatuur / bronnen...................................................................................................................................................16

6

1. Inleiding Bi j de aanschaf van nieuwe ICT-voorzieningen dienen met een aantal aspecten rekening gehouden te worden, waarvan informatiebeveiliging er één is. Binnen de gemeente dient er een goedkeringsprocedure te zijn voor nieuwe ICT -voorzieningen. Als er een overeenkomst wordt gesloten met een leverancier dan is het ook belangrijk om de eventuele subleveranciers mee te nemen in de risico afweging. Dit allen zorgt voor een soepele nieuwe ICT-voorziening met zo min mogelijk ri sico’s.

ICT-voorzieningen

Onder ICT-voorzieningen va llen de volgende ICT-componenten: applicatie, systeemsoftware en hardware.

Doelstelling van de goedkeuringsprocedure voor ICT-voorzieningen1

Deze goedkeuringsprocedure voor ICT‐voorzieningen draagt er zorg voor dat wijzigingen op de 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.

Beheerdoelstellingen van de goedkeuringsprocedure voor ICT-voorzieningen

De volgende beheerdoelstellingen dienen met een redelijke mate van zekerheid te worden gewaarborgd:

• ICT‐voorzieningen dienen te worden geautoriseerd met inachtneming van de risico’s voor de ICT -diensten. De impact

van de ICT‐voorzieningen dient van tevoren op beschikbaarheids-, capaciteits-, continuïteits- en beveiligingsaspecten,

evenals (eind)gebruikersaspecten te worden getoetst.

Indien ICT‐voorzieningen niet zijn geautoriseerd na evaluatie van de risico’s, bestaat het ri sico dat de ICT‐

voorzieningen ongewenste (neven)effecten hebben op ICT-diensten, die soms niet volledig kunnen worden overzien

door de initiator van de wijziging. Het is daarom van belang om deze effecten gestructureerd in kaart te brengen en de

impact af te s temmen met a lle belanghebbenden, zoals de eigenaar van de ICT-dienst, beheerders van ICT-middelen

en de betrokkenen van andere ICT-beheerprocessen.

• ICT‐voorzieningen dienen te worden beoordeeld op doeltreffendheid.

Indien de doeltreffendheid van ICT‐voorzieningen niet wordt geëvalueerd, bestaat het ri sico dat de ICT‐voorzieningen

niet, of slechts gedeeltelijk, bijdragen aan verbetering van de ICT-diensten of zelfs verstorend zijn voor de ICT-

diensten. Indien ICT‐voorzieningen niet het beoogde effect blijken te hebben, is het van be lang om terug te kunnen

keren naar de oorspronkelijke situatie (ook wel: back-out of terugvalscenario).

1.1. Aanwijzing voor gebruik Deze handleiding is geschreven om handreikingen te geven voor een goedkeuringsprocedure voor ICT-voorzieningen. De gemeentelijke beleidsregels met betrekking tot goedkeuringsprocedures voor ICT-voorzieningen zijn:2

• Er behoort een goedkeuringsproces voor nieuwe ICT-voorzieningen te worden vastgesteld en geïmplementeerd.

o Er i s een goedkeuringsproces voor nieuwe ICT-voorzieningen en wijzigingen in ICT-voorzieningen

• Wijzigingen in ICT-voorzieningen en informatiesystemen behoren te worden beheerst.

o In de procedure voor wi jzigingenbeheer i s minimaal aandacht besteed aan:

1. Het administreren van significante wijzigingen.

2. Impactanalyse van mogelijke gevolgen van de wijzigingen.

3. Goedkeuringsprocedure voor wijzigingen.

1 Dit wordt ook wel als autorisatieproces voor ICT-voorzieningen aangeduid.

2 Zie ook het voorbeeld ‘Algemene informatiebeveiligingsbeleid’ van de IBD.

7

2. Handreiking goedkeuringsprocedure De goedkeuring van ICT-voorzieningen omvat vier onderdelen:

1. Een zakelijke goedkeuring:

Bi j een zakelijke goedkeuring dient getoetst te worden of de ICT-voorzieningen voldoen aan de gestelde afspraken

tussen de leverancier en de gemeente3, binnen het gestelde budget en Return on Investment (ROI)4 et cetera.

2. Een functionele goedkeuring:

Bi j de functionele goedkeuring dient door middel van testen door de functioneel beheerder/eindgebruikers getoetst

te worden of de ICT-voorzieningen voldoen aan de eisen en wensen, zoals vermeld in het programma van eisen. 5

3. Een beveiligings- en privacygoedkeuring:

Bi j de beveiligings- en privacygoedkeuring dient op basis van de vastgestelde beveiligings- en privacyeisen van de

gemeente nagegaan te worden of alle relevante beveiligings- en privacyeisen en procedures worden nageleefd.

4. Een technische goedkeuring:

Bi j de technische goedkeuring dient door de ICT-afdeling gecontroleerd te worden of de nieuwe ICT-voorzieningen

naar behoren zullen functioneren in de bestaande ICT-omgeving van de gemeente.

Uitgangspunten

Onderstaande uitgangspunten dienen in acht te worden genomen:

• Voor implementatie van applicaties en/of systeemsoftware wordt gecontroleerd of er een actuele back -up

beschikbaar i s ten behoeve van een back-out (terugvalscenario) procedure.

• De systeembeheerder implementeert nieuwe versies van de applicatie en/of systeemsoftware pas nadat de

documentatie i s aangepast en de software en/of hardware is getest. Bijvoorbeeld door de applicatiebeheerder of de

systeembeheerder.

• De leverancier kan voor de uitvoering van deze goedkeuringsprocedure niet worden ingeschakeld om een duidelijke

scheiding te maken tussen, aan de ene kant de rol van de productleverancier en aan de andere kant die van de

gemeente, die moet testen of producten aan de gestelde (beveiligings)eisen voldoen. De goedkeuringsprocedure

moet worden uitgevoerd door een partij die onafhankelijk is van de ICT-voorziening.

• De goedkeuringsprocedure en het testen maken onderdeel uit van wijzigingsbeheer.6

Uitvoering

1. De configuratiebeheerder ontvangt de ICT-voorziening en de bijbehorende documentatie van de leverancier en geeft

deze documentatie aan degene die een rol spelen in dit goedkeuringsproces.7 Bijvoorbeeld de applicatie-, netwerk-

en/of systeembeheerder.

2. De documentatie wordt door de belanghebbende bestudeerd. Hierbij dient rekening te worden gehouden met de

eventuele beïnvloeding van andere ICT-componenten. Bij eventuele onduidelijkheden, wordt contact gezocht met de

leverancier om deze onduidelijkheden weg te nemen.

3. De ICT-voorziening wordt in de test- en acceptatieomgeving getest. Dit aan de hand van acceptatiecriteria welke

vooraf door de belanghebbende zi jn opgesteld. Het verloop van de test en de resultaten ervan worden vermeld in een

testrapportage. Aangezien het testen van de ICT-voorziening een belangrijk onderdeel is in de goedkeuringsprocedure

wordt hieronder extra a andacht besteed aan de verschillende tests die uitgevoerd dienen te worden:

• Zowel de ICT-voorzieningen als de fall-back-procedure en de invoermethode van de ICT-voorziening dienen

grondig te worden getest. Afwijkingen van dit principe worden vooraf formeel goedgekeurd. De

toets ingsresultaten worden geaccordeerd door belanghebbenden.

3 Zie hiervoor ook het operationele product ‘Inkoopvoor waar den en informatiebeveiligingseisen’.

4 http://nl.wikipedi a.org/wi ki/Return_on_investment

5 Het programma van eisen is een geschreven verzameling van eisen en wensen ten aanzien van een mogelijk te ontwerpen product, constructie, aan te schaffen dienst,

of anderszins. De bedoeling van een programma van eisen is van tevoren de randvoorwaarden en limieten te definiëren. De ‘eisen’ zijn de criteria waaraan voldaan moet

worden, de ‘wensen’ zijn de criteria waaraan de verwachting is dat er zo veel mogelijk aan voldaan wordt..Hier maken beveiligingseisen en privacy eisen ook deel van uit

6 Zie hiervoor ook het operationele product ‘Wijzigingsbeheer’.

7 Zie hiervoor ook het operationele product ‘Configuratiebeheer’.

8

• Als het ICT-voorzieningen betreft met impact op de informatiebeveiliging, wordt in overleg met de

beveiligingsbeheerder bepaald of er specifieke informatiebeveiligingstesten uitgevoerd moeten worden

(penetratietesten, code reviews et cetera). Waar nodig wordt apparatuur en programmatuur gecontroleerd

op compatibiliteit met andere systeemcomponenten.

• Als het ICT-voorzieningen betreft met impact op de privacy, wordt in overleg met de

proces/systeemeigenaar bepaald of er specifieke privacy gerelateerde testen uitgevoerd moeten worden.

• Er dient voor de testwerkzaamheden een aparte testomgeving te zijn. Testen worden uitgevoerd door de

degenen die het wijzigingsverzoek hebben ingediend of vertegenwoordigers daarvan (gebruikersorganisatie

van de gemeente) en ICT-beheer.

De leverancier of bouwers kunnen voor de uitvoering van deze tests niet worden ingeschakeld, om een

duidelijke scheiding te maken tussen aan de ene kant de rol van de productleverancier, en aan de andere

kant die van de gemeente die moet testen of producten aan de gestelde eisen voldoen. Tevens dienen

systemen voor Ontwikkeling, Test en/of Acceptatie (OT(A)) logisch gescheiden te zijn van Productie (P).

• Acceptatietests worden uitgevoerd door zowel gebruikers (gebruiksacceptatie) als de beheerders

(productie-acceptatietest). De acceptatietest maakt deel uit van het geheel aan testen die in het kader van

de goedkeuringsprocedure plaatsvinden.

• Er zi jn duidelijke voorschriften nodig voor het toezicht houden op de kwaliteit van het testen en van de

documentatie van de testresultaten. De testrapportage wordt ter beschikking gesteld aan de

beveiligingsbeheerder en wordt opgenomen in de bij de ICT-voorziening horende versiedocumentatie.

4. Indien de tests tot een bevredigend resultaat leiden, wordt de ICT-voorziening in productie genomen. Indien de test

niet tot een bevredigend resultaat leidt, wordt dit zo spoedig mogelijk teruggekoppeld naar de leverancier. Bij

ontvangst van een door de leverancier aangepaste release wordt de voorliggende procedure herhaald.

Beoordelen van de kwaliteit van de goedkeuringsprocedure voor ICT-voorzieningen

Onderstaande vragenlijst kan door de gemeente worden gebruikt om de goedkeuringsprocedure voor ICT-voorzieningen te

beoordelen. Deze vragenlijst i s zeker niet volledig, maar geeft voldoende handvatten om een eerste inschatting van de s tatus met betrekking tot de goedkeuringsprocedure voor ICT-voorzieningen te maken:

• Bestaat er een goedkeuringsprocedure voor de installatie van nieuwe voorzieningen of wijziging van bestaande ICT-

voorzieningen voor informatietechnologie (apparatuur en programmatuur)?

• Is daarin vastgelegd dat geen ongeautoriseerde voorzieningen mogen worden geïnstalleerd en gebruikt?

• Moet volgens die goedkeuringsprocedure elke installatie formeel worden goedgekeurd, waarbij het doel en het

gebruik worden geautoriseerd, en bestaat er zowel een zakelijk als een technisch autorisatieniveau?

• Is bekend wie van de gemeente zakelijke goedkeuring mogen verlenen?

• Behoren daartoe ook de medewerkers die verantwoordelijk zijn voor het onderhoud van het systeem, zodat zekerheid

bestaat over naleving van de relevante beveiligingseisen en -procedures?

• Is bij de goedkeuring ook rekening gehouden met de effectiviteit en de efficiency van de informatiebeveiliging, zoals

beheerskosten, mate van controleerbaarheid en soort rapportage?

• Is bekend wie van de gemeente technische goedkeuring mogen verlenen?

• Mag s lechts apparatuur of programmatuur in een netwerk worden geplaatst van een technisch goedgekeurd type?

• Mag s lechts apparatuur of programmatuur worden gebruikt van een technisch goedgekeurd type, zodat het

dienstverlenend bedrijf dat het onderhoud verzorgt niet voor verrassingen komt te s taan?

• Wordt s teeds gecontroleerd of de voorschriften uit de procedure worden nageleefd?

• Is bekend wie van de gemeente die controle uitvoert en aan wie wordt gerapporteerd?

• Bestaat er een migratiekalender voor de ICT-voorzieningen?

9

2.1. Zakelijke goedkeuring

Bi j een zakelijke goedkeuring dient getoetst te worden of de ICT-voorzieningen voldoen aan de gestelde afspraken tussen de leverancier en de gemeente, binnen gesteld budget en Return on Investment (ROI) et cetera. In deze paragraaf zal vooral

aandacht worden besteed aan de afspraken met betrekking tot informatiebeveiliging. Bi j het verwerven van ICT-producten of ICT-diensten is het van belang om in een vroegtijdig s tadium aan mogelijke

leveranciers kenbaar te maken welke beveiligingseisen de gemeente wenst te nemen, of door haar leverancier uitgevoerd wenst te zien. De gemeentefunctionaris die verantwoordelijk is voor de betreffende opdracht, is er ook verantwoordelijk

voor om er op toe te zien dat de leverancier van de betreffende diensten aan deze eisen voldoet.

Beoordelen van de kwaliteit van de dienstverleningsovereenkomst

Onderstaande vragenlijst kan door de gemeente worden gebruikt om de dienstverleningsovereenkomst te beoordelen. Deze vragenlijst is zeker niet volledig, maar geeft voldoende handvatten om een eerste inschatting van de status met betrekking tot de dienstverleningsovereenkomst te maken.8

Algemene vragen:

• Is de verantwoordelijkheid voor het beheer van contracten duidelijk belegd binnen de gemeente?

• Bevat het contract de verplichtingen va n alle partijen waarop de overeenkomst betrekking heeft?

• Is bij het opstellen van dat contract gebruik gemaakt van de expertise van een juridisch deskundige?

• Bestaat het recht om de contractuele verantwoordelijkheden te controleren?

• Zi jn er in het contract beperkende bepalingen opgenomen, ten aanzien van het kopiëren en openbaar maken van

informatie?

• Bevat het contract bepalingen met sancties of boetebedingen voor het geval dat een contractpartij de verplichtingen

niet naleeft?

• Heeft men maatregelen getroffen die er op gericht zi jn om bij het beëindigen van het contract de informatie en

goederen terug te geven of te vernietigen?

• Is in het contract rekening gehouden met verantwoordelijkheden op grond van wettelijke eisen?

• Wordt bi jgehouden welke contracten zijn afgesloten?

• Beschrijft het contract welke ICT-producten of -diensten beschikbaar worden gesteld?

• Heeft men de verzekering dat installatie van het nieuwe systeem (of systeemcomponenten) geen nadelige invloed

heeft op bestaande systemen, in het bijzonder tijdens de drukste verwerkingstijden (zoals aan het einde van de

maand)?

• Wordt er voorzien in cursussen? Vraagstukken met betrekking tot informatiebeveiliging:

• Wordt in het contract aandacht besteed aan het a lgemene beleid ten aanzien van informatiebeveiliging?

• Draagt de leverancier zorg voor een Escrow?

• Zi jn in dat contract de noodzakelijke beveiligingsvoorwaarden opgenomen?

• Wordt door de gemeente gecontroleerd dat de beveiligingseisen ook worden nageleefd door de leverancier? Of wordt

hiervoor door de leveranciers een Third Party Mededeling (TPM)9 overhandigd?

• Wanneer er persoonsgegevens worden bewerkt in systemen van de leverancier buiten de gemeente (bijvoorbeeld bij

Software as a Service (SaaS)10), accepteert de leverancier dan een bewerkersovereenkomst11 als onderdeel van het

contract?

• Worden de maatregelen uit de Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG), voor zover van

toepassing verklaard door de gemeente, door de leverancier geaccepteerd en toegepast op de geleverde p roducten

en/of diensten?

• Indien de wens bestaat tot een hoge beschikbaarheid, is er dan in het contract aandacht besteed aan

continuïteitsvoorzieningen?

8 Zie hiervoor ook het operationele product ‘Inkoopvoor waar den en informatiebeveiligingseisen’ .

9 Een TPM is een verklaring welke afgegeven wordt door een onafhankelijke audit partij over de kwaliteit van een ICT-dienst.

10 http://nl.wikipedi a.org/wi ki/Software_as_a_Ser vice

11 Zie hiervoor ook het operationele product ‘Bewerkersovereenkomst’.

10

• Bevat de dienstverleningsovereenkomst met leveranciers passages over aansprakelijkheid en betrouwbaarheid van de

dienstverlening en maximaal toelaatbare duur van uitval?

• Zi jn de tijdstippen en dagen, waarop de dienst beschikbaar moet zijn, vastgelegd in het contract?

• Bevatten de leveringsvoorwaarden van de gemeente eisen betreffende ingehuurd personeel in het kader van

informatiebeveiliging?

• Zi jn de overeenkomsten, die betrekking hebben op de toegang tot ICT-voorzieningen van de onderneming door

externe gebruikers, gebaseerd op een formeel contract?

• Wordt er gecontroleerd of een contract i s getekend, voordat er toegang tot de ICT-voorzieningen wordt verleend?

• Is in het contract vastgelegd welke toegangsmethoden zijn toegestaan en hoe gebruikersidentificaties en

wachtwoorden moeten worden beheerd en gebruikt?

• Wordt in het contract verwezen naar procedures voor de bescherming van bedrijfsmiddelen, waaronder ook

informatie?

• Is per contract de verantwoordelijkheid geregeld voor de installatie en het onderhoud van apparatuur en

programmatuur?

• Zi jn eventuele vereiste fysieke beveiligingsmaatregelen in het contract beschreven?

• Bevat het contract procedures die ervoor zorgen dat de beveiligingsmaatregelen worden opgevolgd?

• Zi jn in het contract maatregelen beschreven ter voorkoming van het verspreiden van vi russen?

• Is in het contract aandacht besteed aan de autorisatieprocedure voor de toegangsrechten van de gebruikers?

• Zi jn in het contract de afspraken vastgelegd over onderzoek en rapportage van beveiligingsincidenten?

2.2. Functionele goedkeuring Bi j de functionele goedkeuring dient, door middel van testen door de functioneel beheerder/eindgebruikers, getoetst te worden of de ICT-voorzieningen voldoen aan de eisen en wensen, zoals vermeld in het programma van eisen.

Hieronder worden aandachtpunten beschreven die een rol spelen bij het opstellen van het programma van eisen van de ICT-voorziening door de gemeente. Deze opsomming is zeker niet volledig, maar biedt voldoende handvatten om een programma van eisen op te stellen en te controleren:

• Is de (te ontwikkelen) ICT-voorziening inclusief de eventuele (specifieke) naam beschreven?

• Is omschreven waarom er behoefte i s aan de nieuwe ICT-voorziening?

Di t kan van grote invloed zijn op het ontwerp, wanneer één of meerdere functies of eigenschappen dominant in het

product aanwezig dienen te zijn.

• Dient de nieuwe ICT-voorziening bestaande producten te gaan vervangen? Indien ja ; welke bestaande kenmerken

moeten in de nieuwe ICT-voorziening aanwezig zijn, of welke juist niet?

• Moet er een huisstijl worden toegepast?

• Voor welke markt of voor welk marktsegment is de ICT-voorziening bedoeld?

• Wat zi jn de kenmerken van deze markt(en) en segmenten?

• Welke eisen s tellen deze markten met betrekking tot normen, voorschriften, productaansprakelijkheid et cetera?

• Zi jn de gewenste/feitelijke gebruikers van de nieuwe ICT-voorziening, de doelgroep(en), omschreven?

• Zi jn de verwachtingspatronen van de gebruiker(s) waarmee rekening moet worden gehouden beschreven?

• Zi jn er richtlijnen met betrekking tot het gebruik van de ICT-voorziening?

Denk aan configuratiemogelijkheden, bediening, beveiligingsrisico’s et cetera.

• Zi jn de beveiligingsvoorschriften vermeld?

• Zi jn onderhoudvoorschriften en wat te doen in geval van storingen beschreven?

• Is er een functionele applicatie test uitgevoerd (FAT)

11

Beoordelen van kwaliteitscontrole op acceptatie van ICT-voorzieningen

Onderstaande vragenlijst kan door de gemeente worden gebruikt om de controle op acceptatie van ICT-voorzieningen te beoordelen. Deze vragenlijst i s zeker niet volledig, maar geeft voldoende handvatten om een eerste inschatting van de

s tatus met betrekking tot de controle op acceptatie van ICT-voorzieningen, en in het bijzonder wijzigingen in het besturingssysteem en softwarepakketten te maken.

ICT-voorzieningen:

• Is er door de gemeente een projectorganisatie ingevoerd ten behoeve van selectie, acceptatie (inclusief testen) en

implementatie (inclusief beveiliging) van nieuwe ICT-componenten?

• Zi jn de eisen en de cri teria ten aanzien van nieuwe ICT-componenten vastgelegd en goedgekeurd door de

verantwoordelijke van de gemeente?

• Is voor het testen een testplan opgesteld?

• Zi jn in het testplan de volgende onderwerpen opgenomen:

o De soort test die dient te worden uitgevoerd

o Te testen onderdelen, met het verwachte resultaat

o Acceptatiecriteria

o Fout-, herstel- en herstartprocedures

o Routinematige bedieningsprocedures

• Worden de testresultaten adequaat vastgelegd en geëvalueerd (evaluatie en/of eindrapport)?

• Is bij het testen i n toereikende mate, aandacht gegeven aan het testen van beveiligings-, privacy- en

controlemaatregelen?

• Heeft men de verzekering dat installatie van het nieuwe systeem (of systeemcomponenten) geen nadelige invloed

heeft op bestaande systemen, in het bijzonder tijdens de drukste verwerkingstijden (zoals aan het einde van de

maand)?

• Wordt er voorzien in cursussen

• Wordt di rect na het installeren van de technische ICT-voorzieningen getest of deze voldoen aan de vooraf opgestelde

specificaties?

Besturingssysteem:

• Wordt bi j wijzigingen in het besturingssysteem nagegaan welke consequenties die wijzigingen hebben voor de

beveiliging van de applicaties?

• Worden er door de systeemprogrammering release notes opgesteld en tijdig gedistribueerd?

• Wordt in de release notes aandacht besteed aan de gevolgen voor beveiliging en controle (beveiligingsparagraaf)?

• Zi jn de beveiligings- en controleconsequenties afgestemd met de beveiligings- respectievelijk de controlediscipline?

• Zi jn er nood- en/of terugvalscenario’s opgesteld?

• Omvat het jaarplan budgetten voor onderzoek en systeemtesten, naar aanleiding van wijzigingen in het

besturingssysteem?

• Worden wijzigingen in het besturingssysteem tijdig aangekondigd, zodat de benodigde controles/testen voorafgaand

aan de implementatie van de wi jzigingen kunnen plaatsvinden?

• Bestaat er een testprocedure voor de beoordeling van wijzigingen in het besturingssysteem?

• Worden de continuïteitsplannen van de gemeente aangepast naar aanleiding van wijzigingen in het

besturingssysteem? Softwarepakketten:

• Is getest of de aangebrachte wijzigingen de beveiligingsmaatregelen en integriteitsprocessen niet in gevaar brengen?

• Is getest of de aangebrachte wijzigingen geen inbreuk doen op de privacy vereisten?

• Is er toestemming verkregen van de leverancier?

• Is het mogelijk om de wi jzigingen door de leverancier te laten aanbrengen?

• Is het mogelijk om na de aanpassing nog nieuwe versies van de leverancier te gebruiken?

• Zi jn de aangebrachte wijzigingen zodanig gedocumenteerd dat zi j opnieuw aangebracht kunnen worden?

12

2.3. Beveiligingsgoedkeuring

Bi j de beveiligingsgoedkeuring dient er op basis van de vastgestelde beveiligingseisen van de gemeente, nagegaan te worden of a lle relevante beveiligingseisen en procedures worden nageleefd.

Het i s essentieel dat de gemeente haar beveiligingseisen bepaalt. Hierbij kunnen de volgende bronnen worden gebruikt om deze beveiligingseisen vast te stellen:

• De beoordeling van de risico’s waar de gemeente aan blootgesteld is. Via een risicobeoordeling worden bedreigingen

voor bedri jfsmiddelen vastgesteld en de kwetsbaarheid voor-, en de waarschijnlijkheid dat, een bepaalde bedreiging

zich voordoet geëvalueerd en wordt de potentiële impact geschat.12

• De wettelijke- en regelgevende eisen waaraan de gemeente, haar leveranciers en dienstverleners moeten voldoen.

(denk hier ook aan privacy)

Beoordelen kwaliteitsanalyse en specificatie van beveiligingseisen

Onderstaande vragenlijst kan door de gemeente worden gebruikt om de analyse en specificatie van beveiligingseisen te

beoordelen. Deze vragenlijst i s zeker niet volledig, maar geeft voldoende handvatten om een eerste inschatting van de s tatus te maken.

• Is er ti jdens de definitiestudie/het ontwerpen van nieuwe systemen of releases van bestaande systemen een analyse

gemaakt van de beveiligingseisen?

• Is bij de definitie van beveiligingseisen naast de geautomatiseerde (ingebouwde) maatregelen ook aandacht besteed

aan ‘handmatige’ maatregelen (procedures)?

• Zi jn er eisen geformuleerd ten aanzien van de waarborging van vertrouwelijkheid, integriteit en beschikbaarheid van

de informatievoorziening?

• Zi jn er privacy eisen geformuleerd of afkomstig van een DPIA die meegenomen moeten worden?

• Zi jn er eisen geformuleerd ten aanzien van het voorkomen, opsporen en herstellen van storingen en incidenten?

• Zi jn de beveiligingseisen gedefinieerd in a lle relevante documentatie?

• Is er bij de analyse van de beveiligingseisen onder andere aandacht gegeven aan:

o Logische toegangsbeveiliging (Identity & Access Management (IAM))

o Leveranciers toegang

o Standaard wachtwoorden

o Integratie met bestaande gemeentelijke systemen, bijvoorbeeld Single Sign-on (SSO) berichtenstandaarden

en open standaarden.

o Encryptie van gegevens

o Het maken van reservekopieën

o Interne en externe uitwijkvoorzieningen

o Registratie van bijzondere gebeurtenissen (audit tra ils)

o Mogel ijkheden om de integriteit van vi tale gegevens te controleren en te beschermen.

o Het voldoen aan wettelijke/contractuele vereisten

o Het voorkomen van ongeautoriseerde wijzigingen

o Systeemupdates

o Logging mogelijkheden

o Hardening

o De (mogelijk negatieve) impact op de werking (van de beveiliging) van bestaande systemen?

12 Zie hiervoor ook het operationele product ‘Basis risico analyse methode gemeenten’).

13

2.4. Technische goedkeuring

Bi j de technische goedkeuring dient door de ICT-afdeling gecontroleerd te worden of de nieuwe ICT-voorzieningen naar behoren zullen functioneren in de bestaande ICT-omgeving van de gemeente.

Beoordelen van kwaliteit acceptatie van ICT-componenten

Onderstaande vragenlijst kan door de gemeente worden gebruikt om de acceptatie van ICT-componenten te beoordelen. Deze vragenlijst is zeker niet volledig, maar geeft voldoende handvatten om een eerste inschatting te maken.

• Is er door de gemeente een projectorganisatie ingevoerd ten behoeve van selectie, acceptatie (inclusief testen) en

implementatie (inclusief beveiliging) van nieuwe ICT-componenten?

• Zi jn de eisen en de cri teria ten aanzien van nieuwe ICT-componenten vastgelegd en goedgekeurd door het

management?

• Is er voor het testen een testplan opgesteld?

• Zi jn in het testplan de volgende onderwerpen opgenomen:

o Acceptatiecriteria

o Te testen onderdelen, met verwacht resultaat

o Fout-, herstel- en herstartprocedures

o Routinematige bedieningsprocedures

• Worden de testresultaten adequaat vastgelegd en geëvalueerd (evaluatie en/of eindrapport)?

• Is bij het testen in toereikende mate aandacht gegeven aan het testen van beveiligings-, privacy- en

controlemaatregelen?

• Heeft men de verzekering dat installatie van het nieuwe systeem (of systeemcomponenten) geen nadelige invloed

heeft op bestaande systemen, in het bijzonder tijdens de drukste verwerkingstijden (zoals aan het einde van de

maand)?

• Wordt er voorzien in cursussen voor bediening en gebruik van nieuwe systemen (of systeemcomponenten)?

14

Bijlage 1: Definities

Back-out (terugvalscenario):

Een activi teit die een dienst of een ander configuratie-item terugzet op een eerder uitgangspunt. Back-out wordt gebruikt a ls een vorm van herstel wanneer een wijziging of uitgifte niet lukt.

Configuratiebeheer:

Het proces dat verantwoordelijk i s 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 i s,

wanneer en waar dat nodig is. Die informatie omvat details over hoe de bedrijfsmiddelen zijn samengesteld en details over relaties tussen bedrijfsmiddelen.

Dienstenniveaubeheer:

Het proces dat verantwoordelijk i s 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 dienstenniveau doelen.

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.

Terugval/terugrol:

Ondernomen acties voor herstel na een mislukte wijziging of uitgifte. Terugval kan back-out, activering van

dienstcontinuïteitsplannen bevatten of andere acties om het bedrijfsproces te continueren.

Uitgifte/release:

Een of meer wijzigingen aan een ICT-dienst die samen worden gebouwd, getest en uitgerold. Een enkele uitgifte kan wi jzigingen omvatten aan hardware, software, documentatie, processen en andere componenten.

Wijziging:

De toevoeging, verandering of verwijdering van alles dat een effect kan hebben op ICT-diensten. Het bereik is gericht op a l le wijzigingen van a lle architecturen, processen, instrumenten, meetwaarden en documentatie, en op wijzigingen van ICT -diensten en andere configuratie-items.

Wijzigingsadviescommissie/Change Advisory Board (CAB):

Een groep mensen die de beoordeling, de prioriteitsstelling, de autorisatie en de planning van wijzigingen ondersteunt. Een wi jzigingsadviescommissie bestaat veelal uit vertegenwoordigers van alle afdelingen binnen de ICT-dienstenaanbieder, het

bedri jf en derden (zoals toeleveranciers).

Wijzigingsbeheer:

Het proces dat verantwoordelijk i s voor het beheersen van de levenscyclus van alle wijzigingen, om verbeteringen met minimale verstoring van de ICT-diensten uit te voeren.

15

Wijzigingsplan/changeplan:

Een document dat alle geautoriseerde wijzigingen en geplande implementatiegegevens met de geschatte datums van wi jzigingen op langere termijn beschrijft. Een wijzigingsschema wordt soms een voorlopig wijzigingsschema (forward

schedule of change) genoemd, terwijl het ook informatie over a l geïmplementeerde wijzigingen bevat.

Wijzigingsregistratie:

Een registratie van de details van een wijziging. Elke wijzigingsregistratie documenteert de levenscyclus van een afzonderlijke wijziging. Een wijzigingsregistratie wordt gecreëerd voor elk wijzigingsverzoek dat binnenkomt, ook voor die verzoeken die later afgewezen worden. Wijzigingsregistraties verwijzen naar de configuratie-items die door de wijziging worden beïnvloed. Wijzigingsregistraties worden opgeslagen in het configuratiebeheersysteem of ergens anders in het diensten kennisbeheersysteem.

16

Bijlage 2: Literatuur / bronnen Voor deze publicatie is gebruik gemaakt van onderstaande bronnen: Titel: Praktijkgids Code voor informatiebeveiliging Wie: Ernst Oud Uitgeverij: Academic Service Datum: 2002 EAN: 9789052614274

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) Titel: Studierapport Normen voor de beheersing van uitbestede ICT-beheerprocessen

Wie: gezamenlijk initiatief van de NOREA en het Platform voor Informatiebeveiliging (PvIB) Datum: 12 december 2007

Kijk voor meer informatie op:

www.informatiebeveiligingsdienst.nl

Nassaulaan 12

2514 JS Den Haag

CERT: 070 373 80 11 (9:00 – 17:00 ma – vr)

CERT 24x7: Piketnummer (instructies via voicemail)

info@IBDGemeenten.nl / incident@IBDGemeenten.nl