PATCH MANAGEMENT VOOR GEMEENTEN. Een van de producten van de operationele variant van de Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG)

Transcriptie

1 PATCH MANAGEMENT VOOR GEMEENTEN Een van de producten van de operationele variant van de Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG)

2 Colofon Naam document Patch Management voor gemeenten Versienummer 1.0 Versiedatum oktober 2013 Versiebeheer Het beheer van dit document berust bij de Informatibeveiligingsdienst voor gemeenten (IBD) Copyright 2013 Informatiebeveiligingsdienst voor gemeenten (IBD) 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. ieder 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. In samenwerking met De producten van de operationele variant van de Baseline Informatiebeveliging Nederlandse Gemeenten (BIG) worden vervaardigd in samenwerking met: 2

3 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 Aanleiding voor de oprichting van de IBD vormen enerzijds de leerpunten uit een aantal grote incidenten op informatiebeveiligingsvlak en anderzijds de visie Digitale Overheid 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-Beveilgingsassessment DigiD is een voorbeeld van zo n 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 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 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: WBP, GBA, SUWI, BAG en PUN, 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 in de naleving van dat kader ruimte is voor afweging en prioritering op basis van het pas toe of leg uit principe 3

4 Leeswijzer Dit product maakt onderdeel uit van de operationele variant van de Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG). Doel Patch Management 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. Patch Management wordt meestal uitgevoerd door de ICTafdeling binnen een organisatie. Het doel van Patch Management 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 houden. Doelgroep Dit document is van belang voor het gemeentebestuur voor wat betreft de informatie beveiligings beleid aanvulling voor Patchmanagement. Het management, de CISO/IBF en de ICT-afdeling zijn allen betrokken bij de uitvoering en controle op het Patch Management. Relatie met overige producten Gemeentelijk Beveiligingsbeleid Aansluitdocumentatie IBD Configuratiebeheer Hardening beleid gemeenten Maatregelen tactische variant Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG)

5 Inhoud 1 Inleiding 6 2 Rol IBD bij patchmanagement 8 3 Het proces, een mogelijke invulling Reguliere patches Spoed-patches 11 4 Controle op de werking van het patch proces en rapportage 13 Bijlage: Patch Managementbeleid gemeente <gemeente> 14 5

6 1 Inleiding De Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG) heeft de onderstaande maatregelen beschreven die te maken hebben met patchen van systemen in verband met het verminderen van risico's als gevolg van benutting van gepubliceerde technische kwetsbaarheden. Zie hiervoor hoofdstuk 12.6 van de BIG. Patch Management 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. Patch Management wordt meestal uitgevoerd door de ICTafdeling binnen een organisatie. Patch Management kan worden uitgevoerd met speciale tooling die de gehele infrastructuur inventariseert en het patch proces ondersteunt (vulnerability scanning tools en patch tooling). Zie hiervoor ook de aanwijzing hardening voor gemeenten. Patch Management wordt ook beschreven in het whitepaper Patch Management van het NCSC (2008), link: Doelstelling Patch Management Het doel van Patch Management is tweeledig: 1. het is gericht op het inzichtelijk maken van de actuele stand van kwetsbaarheden en toegepaste patches binnen de beheerde infrastructuur, 2. op een zo efficiënt mogelijk wijze met zo min mogelijk verstoringen stabiele (veilige) systemen te creëren. Patch Management is gericht op het verminderen van risico's als gevolg van benutting van gepubliceerde technische kwetsbaarheden. Leveranciers van software en hardware geven regelmatig informatie over gevonden zwakheden in hun systemen, met daarbij een aanwijziging hoe deze zwakheid te bestrijden. Door de steeds complexere samenhang van de infrastructuur is het niet altijd de beste oplossing om iedere patch door te voeren. Met een defense in depth 1 strategie kan beter bepaald worden waar en wanneer patches doorgevoerd worden of alternatieve oplossingen ingezet kunnen worden. Met defense in depth strategie kan bijvoorbeeld worden bepaald dat een systeem met een kwetsbaarheid niet via internet benaderbaar mag zijn, een ander voorbeeld is het stoppen van bepaalde services. Door de defense in depth strategie wordt de kans dat van een kwetsbaarheid misbruik kan worden gemaakt kleiner. Goed uitgevoerd Patch Management is essentieel om de twee bovenstaande doelstellingen te kunnen realiseren. De indeling van dit document is als volgt: Deze procesbeschrijving is qua opzet geschreven om informatiebeveiligingsmaatregelen te laten samenvallen binnen het bestaande ICT-beheer framework van gemeenten. Ook kan het voorkomen dat er al een bestaand Patch Management proces is binnen de gemeente. Vaak zijn dit ICTprocedures, echter het kan ook voorkomen dat Patch Management wel wordt uitgevoerd, maar dat 1 Defence in Depth of verdediging in de diepte is een concept waarbij meerdere lagen van security controls worden gebruikt binnen een IT systeem met de bedoeling om het uitbuiten van een kwetsbaarheid tegen te gaan. 6

7 dit niet beschreven is. Deze handleiding biedt in beide gevallen een mogelijk aanpak van Patch Management binnen de gemeente. Als laatste wordt een stuk aanvullend gemeentelijk beleid rondom patchmanagement gegeven. Aanwijzing voor gebruik Deze handleiding is qua opzet geschreven om informatiebeveiligingsmaatregelen te laten samenvallen binnen het bestaande ICT- beheer framework van gemeenten. Ook kan het voorkomen dat er al een bestaand Patch Managementproces is binnen de gemeente. Vaak zijn dit ICT-procedures, echter het kan ook vorkomen dat Patch Management wel wordt uitgevoerd, maar dat dit niet beschreven is. Deze handleiding biedt in beide gevallen een mogelijk aanpak van Patch Management binnen de gemeente. Om volledig te voldoen aan de maatregel 12.6 van de BIG moeten de volgende aanbevelingen worden overgenomen: Er is een proces ingericht voor het beheer van technische kwetsbaarheden; dit omvat minimaal het melden van incidenten aan de IBD, periodieke penetratietests, risicoanalyses van kwetsbaarheden en patching. Van softwarematige voorzieningen van de technische infrastructuur kan (bij voorkeur geautomatiseerd) gecontroleerd worden of de laatste updates (patches) door zijn doorgevoerd. Het doorvoeren van een update vindt niet geautomatiseerd plaats, tenzij hier speciale afspraken over zijn met de leverancier. Indien een patch beschikbaar is, dienen de risico's verbonden met de installatie van de patch te worden geëvalueerd (de risico's verbonden met de kwetsbaarheid dienen vergeleken te worden met de risico's van het installeren van de patch). Updates/patches voor kwetsbaarheden waarvan de kans op misbruik hoog is en waarvan de schade hoog is worden zo spoedig mogelijk doorgevoerd, echter minimaal binnen één week. Minder kritische beveiligingsupdates/patches moeten worden ingepland bij de eerst volgende onderhoudsronde. Indien nog geen patch beschikbaar is dient gehandeld te worden volgens het advies van de IBD of een CERT, zoals bijvoorbeeld het NCSC. 7

8 2 Rol IBD bij patchmanagement Er zijn meerdere manieren waarop patch informatie bij de gemeente kan binnenkomen: 1. Via de technisch beheerder: Een technisch beheerder heeft de verantwoordelijkheid om vakmatig bezig te zijn met de systemen die hij of zij moet beheren. Daarbij hoort het volgen van nieuws en waarschuwingen van de leverancier van de betreffende producten. Beheerders hebben hier geen passieve maar een actieve rol. 2. Via de IBD: De IBD zal ook adviezen aan gemeenten zenden, meestal komen die binnen bij de contactpersoon van de IBD of een ander afgesproken contactpunt. De IBD levert aan de gemeenten onder ander de dienst van integrale coördinatie en concrete ondersteuning op gemeente specifieke aspecten in geval van incidenten en crisissituaties op het vlak van informatiebeveiliging. De IBD levert informatie aan gemeenten over patches. Vaak gaat dit vergezeld van een reparatie- pakketje, een patch, of een link waar deze patch te vinden is. Indien men deze patch niet implementeert loopt men dus risico s. Daarmee levert de IBD aan de gemeenten die aangesloten zijn bij de IBD, informatie over incidenten of gevonden zwakheden (advisories) die aan de specifieke gemeente gerelateerd kan worden op basis van IP-informatie of de ICT-foto die door de gemeente verstrekt is binnen het aansluitproces. Dat wil zeggen dat alleen gemeenten die het betreft door de IBD benaderd worden met informatie over zwakheden en mogelijke oplossingen in de vorm van patches. Andere leveranciers van beveiligingspatches en informatie over (systeem) zwakheden kunnen ook de eigen leverancier(s) van de gemeente zijn. De IBD voegt waarde toe door gericht deze waarschuwingen of adviezen te geven, naast de algemenere leveranciers adviezen. Inschaling relevantie door de gemeente zelf (zie ook aansluit document IBD hfst 4.4.4) Om een beveiligingsadvies in te schalen binnen de specifieke context van de gemeente kunnen verschillende vragen worden beantwoord. Een aantal voorbeeldvragen die gesteld kan worden, zijn: Raakt de kwetsbare component de kernprocessen van de gemeente? Deze vraag wordt gesteld om een inschatting te kunnen maken van de impact die uitbuiting van de kwetsbaarheid zou hebben binnen de gemeente. Wanneer een kwetsbaarheid of dreiging mogelijk een kernproces raakt, wordt deze hoger ingeschaald dan wanneer mogelijk een ondersteunend proces wordt geraakt. Wat is de logische locatie van de kwetsbare component? Hiermee kan men omstandigheden laten meetellen die specifiek zijn voor de eigen infrastructuur. Zo kunnen matigende omstandigheden, logische locatie binnen de infrastructuur en additionele maatregelen de ernst van de kwetsbaarheid of dreiging verergeren of verzwakken. Een kwetsbare dienst die direct vanaf het internet benaderbaar is, zal eerder worden uitgebuit dan een dienst die wordt beschermd door meerdere systemen. 8

9 Biedt het geraakte systeem alleen de kwetsbare dienst? Of ook andere diensten? Wanneer een systeem meer dan alleen de kwetsbare dienst biedt, heeft dit mogelijk gevolgen bij uitbuiting. Uitbuiting van een kwetsbare dienst, op een systeem dat meerdere diensten biedt, geeft een aanvaller de mogelijkheid om grotere schade toe te brengen. Verder wordt, bij het compromitteren van een systeem dat meerdere diensten aanbiedt, mogelijk een bredere groep gebruikers geraakt. Is het kwetsbare systeem een productiesysteem? Afhankelijk van de rol van een systeem kan een uitgebuite kwetsbaarheid meer of minder invloed hebben op een organisatie. Een gecompromitteerd productiesysteem raakt direct de eindgebruikers van dit systeem. Een testsysteem biedt geen of beperkt diensten aan eindgebruikers en zal dus minder effect hebben op de productiviteit van een afdeling. De kans is aanwezig dat een testsysteem minder goed wordt onderhouden dan een productiesysteem. Het zou kunnen dat het systeem hierdoor minder veilig is ingericht of dat niet alle updates geïnstalleerd zijn. Een vergeten testsysteem zal sneller worden gecompromitteerd dan een volledig bijgewerkte en goed geconfigureerde machine. Wordt het kwetsbare systeem alleen gebruikt als server? Hoewel een systeem is ingericht om bepaalde diensten te bieden, komt het voor dat er ook andere activiteiten plaatsvinden op het systeem. Hierbij kan bij voorbeeld worden gedacht aan webbrowsen. Wanneer een systeem meer functionaliteit biedt, wordt de kans groter dat er een kwetsbaarheid aanwezig is en kan worden uitgebuit. Externe systemen Voor de bovenstaande vragen moet men bedenken dat systemen ook gehost kunnen zijn. In contracten met beherende partijen moet patchmanagement aandacht hebben, bijvoorbeeld in de vorm van garanties dat systemen up to date worden gehouden en dat hierover regelmatig gerapporteerd wordt. 9

10 3 Het proces, een mogelijke invulling Het Patch Managementproces dient binnen de gemeente effectief en efficient uitgevoerd te worden, Patch Management is geen op zichzelf staand proces. Er wordt van uit gegaan dat binnen de gemeente (ICT-) beheerprocessen zijn ingericht. Het heeft de voorkeur om het Patch Managementproces aan te laten sluiten bij bestaande ICT-beheerprocessen, dit maakt de implementatie van Patch Management makkelijker. Patch Management haakt aan bij de volgende, al dan niet ITIL, beheerprocessen binnen de gemeente: Technisch beheer Het technisch beheerproces wordt uitgevoerd door technisch beheerders. Afhankelijk van de gemeentegrootte kunnen hier specialisten zijn per systeemsoort of meerdere systemen worden door enkele personen technisch beheerd. Netwerk beheer Netwerkbeheerders beheren het gemeentelijke netwerk. Afhankelijk van de organisatie van de gemeente kan dat ook verenigd zijn in de afdeling technisch beheer. Configuratie management Configuratie Managment 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. Service desk De service desk ontvangt (beveiligings-) incidenten en service call s, maar is ook betrokken bij communicatie rondom ICT-updates naar de eindgebruikers Wijzigingsbeheer Het wijzigingsbeheerproces is ervoor om wijzigingen op een beheerste wijze in de apparatuur en applicaties door te voeren. Technisch en functioneel applicatiebeheer Het technisch applicatiebeheer houdt zich voornamelijk bezig met de technische kant van applicaties, bijvoorbeeld de apparatuur waar de applicatie op draait. De functioneel applicatiebeheerders houden zich bezig met de functionele werking en (bron) gegevens, maar ook met vertalen van functionele eisen en wensen, onderhoud van de applicatie, etc. 3.1 Reguliere patches Binnen de ICT-beheerafdelingingen hebben de verschillende soorten ICT-beheerders zelf een verantwoordelijkheid voor het bijhouden van hun vakgebied en nieuws rondom hun eigen specialisatie. Dat wil zeggen dat reguliere leverancierspatches waarover ook een IBD advies zou kunnen komen, idealieter al geimplementeerd zijn binnen de gemeente. Er wordt maximaal gebruik gemaakt van bestaande processen als patches worden doorgevoerd als onderdeel van de reguliere beheerprocessen. 10

11 Dit ziet er als volgt uit: De ICT-beheerder krijgt informatie dat er een patch voorhanden is voor een systeem om een bepaalde zwaktheid te dichten. Is het een standaard patch dan kan deze naar het change proces om als change verder behandeld te worden. In het geval een patch niet standaard is of er is twijfel, overleg dan altijdeerst met de CISO/informatiemanager en de systeemeigenaar hoe verder te gaan. Dit overleg leidt tot het doorvoeren van de patch als change of de patch wordt niet doorgevoerd. Vanuit het change proces en na het uitvoeren van een impact assesment betreffende de change zal de betreffende ICT-beheerder de patch op de testomgeving van de geraakte systemen installeren. Testen worden uitgevoerd door de technisch applicatiebeheerders. Na een succesvolle test dienen de verantwoordelijken voor ketentesten en de functioneel applicatiebeheerders, eventueel aangevuld met enkele eindgebruikers, te testen of de systemen in samenhang nog zo werken als is afgesproken. Deze testen dienen goed gedocumenteerd te zijn en van alle testen dient een testverslag gemaakt te worden. Denk na over roll back, ook bij implementatie van de patch. Na een succesvolle update dient de configuratiedatabase te worden bijgewerkt met de nieuwe versienummers. Van alle uitgevoerde en niet uitgevoerde patches wordt een logboek bijgehouden. 3.2 Spoed-patches Vanuit de IBD kunnen adviezen binnenkomen bij de afgesproken contactpersoon van de gemeente. Als het advies van de IBD de classificatie high/high (kans op misbruik hoog en kans op schade hoog) heeft is het zaak om zo spoedig mogelijk te patchen, voor alle andere patches dient beoordeeld te worden of het standaard/regulier changeproces gedaan kan worden in bijvoorbeeld een onderhoudsweekend. 11

12 Dit proces zou er zo uit kunnen zien: Het advies van de IBD komt binnen bij de contactpersoon van de gemeente. Er wordt overleg gevoerd met de relevante beheerders/partijen, eventueel wordt de configuratie database geraadpleegd om vast te stellen of de patch nog wel van toepassing is. Binnen dit overleg kan ook worden bepaald of andere mitigerende maatregelen te nemen zijn, zodat de patch niet direct nodig is. Blijft de spoed-patch bestaan dan dient het wijzigingsproces verkort doorlopen te worden, echter de patch wordt altijd getest. Na succesvol patchen zijn de systemen weer up to date. De configuratiedatabase wordt bijgewerkt met de nieuwe versienummers. 12

13 4 Controle op de werking van het patch proces en rapportage Om vast te stellen of er nog bekende zwakheden in de eigen ICT- infrastructuur of applicaties aanwezig zijn kan men een zwakhedenscan of vulnerability scan (laten) uitvoeren. Meestal wordt daarbij speciale tooling gebruikt. Deze tooling kent van iedere soort hardware en software wat de laatste updates zijn en kan ook toetsen op het aanwezig zijn van bekende zwakheden. Het resultaat is dan 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. De vulnerability scan kan worden uitgevoerd door een ICT er of bijvoorbeeld de CISO binnen de gemeente. Het uitvoeren van een vulnerability scan is geen hacking of het uitvoeren van een pentest. De vulnerability scan is een belangrijk onderdeel in het onderhouden van de informatieveiligheid binnen de eigen ICT-infrastructuur, immers apparatuur en software wordt geinstalleerd en onderhouden en die veranderingen kunnen weer nieuwe zwakheden introduceren. Het is aan te bevelen om eerdere scanrapportages te bewaren om verschillen te ontdekken, in ieder geval moet dit gedaan 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 change. Verschil vulnerability scan en pentest Hoe vaak uitvoeren Rapportage Resultaat Door wie Vulnerability Scan Zo vaak als mogelijk, als onderdeel van normale werkzaamheden Uitvoerig rapport met alle zwakheden / issues per systeem Lijsten met bekende zwakheden per systeem Is door de security specialist of ICT uit te voeren met de juiste tooling. Penetratie Test Indien nodig Alleen over het te onderzoeken systeem of functie Onderzoek naar onbekende zwakheden en risico s Specialistisch, in te huren Kosten Eigen uren en product kosten Afhankelijk van diepgang en controlepunten 13

14 Bijlage: Patch Managementbeleid gemeente <gemeente> Het Patch Managementbeleid van de gemeente geeft richting aan de wijze waarop de gemeente maatregelen wenst te treffen voor een adequate inrichting en uitvoering van Patch Management. De gemeente onderschrijft het belang van Patch Management omdat het niet op een gestructureerde wijze bijhouden van patches voor gemeentelijke systemen er voor kan zorgen dat kwestbaarheden van die systemen toenemen. Dit beleid is van toepassing op iedereen die binnen de gemeente een rol heeft in het uitvoeren van Patch Management. De volgende uitgangspunten zijn vastgesteld voor de gemeente en deze zijn ontleend aan het gemeentelijk informatiebeveiligingsbeleid, de Code voor Informatiebeveiliging (NEN/ISO 27002:2007) en de BIG: 1. Er is een proces ingericht voor het beheer van kwetsbaarheden en patching van (systeem) software binnen de gemeente. 2. Van softwarematige voorzieningen van de technische infrastructuur kan (bij voorkeur geautomatiseerd) gecontroleerd worden of de laatste updates (patches) in zijn doorgevoerd. Het doorvoeren van een update vindt niet geautomatiseerd plaats, tenzij hier speciale afspraken over zijn gemaakt met de leverancier. 3. Indien een patch beschikbaar is, dienen de risico's verbonden met de installatie van de patch te worden geëvalueerd (de risico's verbonden met de kwetsbaarheid dienen vergeleken te worden met de risico's van het installeren van de patch). Bij deze evanuatie worden minimaal de CISO en de systeemeigenaar betrokken. 4. De technische integriteit van programmapakketten en infrastructurele programmatuur wordt gecontroleerd d.m.v. een hashingmechanisme en een controlegetal van de leverancier, dat via een vertrouwd kanaal is verkregen. 5. Alle patches dienen voor installatie te worden getest. 6. Behoudens de door de leverancier goedgekeurde updates worden er geen wijzigingen aangebracht in programmapakketten en infrastructurele programmatuur. 7. Updates/patches voor kwetsbaarheden waarvan de kans op misbruik hoog is en waarvan de schade hoog is worden zo spoedig mogelijk doorgevoerd, echter minimaal binnen één week. Minder kritische beveiligings-updates/patches moeten worden ingepland bij de eerst volgende onderhoudsronde van het systeem. 8. Indien nog geen patch beschikbaar is dient gehandeld te worden volgens het advies van de Informatiebeveiligingsdienst voor gemeenten of een CERT zoals het NCSC. 9. Als een systeem gepatchet is wordt de systeem documentatie bijgewerkt naar de laatste stand van zaken, de configuratie management database wordt geupdate met de nieuwe versienummers van componenten. 10. Van alle uitgevoerde en niet uitgevoerde patches wordt door de ICT een logboek bijgehouden. Aldus vastgesteld door burgemeester en wethouders van [gemeente] op [datum], [Naam. Functie] [Naam. Functie] 14

15 INFORMATIEBEVEILIGINGSDIENST V00R GEMEENTEN (IBD) NASSAULAAN JS DEN HAAG POSTBUS GK DEN HAAG HELPDESK ALGEMEEN FAX