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

Transcriptie

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

2 Colofon Naam document Patchmanagement voor gemeenten Versienummer 1.1 Versiedatum november 2017 Versiebeheer Het beheer van dit document berust bij de Informatiebeveiligingsdienst voor gemeenten (IBD) Copyright 2017 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. Wijzigingshistorie: versie datum Opmerkingen Initiële versie Kleine tekstuele aanpassingen Augustus 2016 Taskforce BID verwijderd Minimaal aangepast in maximaal bij patches Juli 2017 Toevoegen risico niet patchen en governance rond Patchmanagement Augustus 2017 Kleine tekstuele aanpassingen door IBD November 2017 Verwerking review gemeenten 1.1 November 2017 Publicatie bijgewerkte versie 2

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

4 Inhoud Inhoud 4 1 Inleiding 5 2 De noodzaak van patchen en governance 7 3 Rol IBD bij Patchmanagement 8 4 Het proces, een mogelijke invulling Reguliere patches Spoed-patches 11 5 Controle op de werking van het patch proces en rapportage 13 Bijlage: Patchmanagementbeleid gemeente <gemeente> 14 4

5 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. Patchmanagement 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. Ieder systeem of apparaat dat software bevat en aan een netwerk gekoppeld is, is in principe onderhevig aan patchmanagent. De meest voor de hand liggende voorbeelden hiervan zijn: besturingssoftware, applicaties, switches, firewalls, servers (ook virtueel), camerasystemen etc. Patchmanagement wordt meestal uitgevoerd door de ICT-afdeling binnen een organisatie. Patchmanagement kan worden uitgevoerd met speciale tooling die de gehele infrastructuur inventariseert en het patchproces ondersteunt (vulnerability scanning tools en patch tooling). 1 Voor patches op applicaties is men voornamelijk afhankelijk van berichtgeving vanuit leveranciers. Patchmanagement wordt ook beschreven in het whitepaper Patchmanagement van het NCSC (2008), link: Doelstelling Patchmanagement Het doel van Patchmanagement 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. Patchmanagement 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 kwetsbaarheden in hun systemen, met daarbij een aanwijzing hoe deze kwetsbaarheden 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 2 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 Patchmanagement is essentieel om de twee bovenstaande doelstellingen te kunnen realiseren. 1 Zie hiervoor het operationele BIG product Hardening-beleid voor gemeenten van de IBD. 2 Defence in Depth of verdediging in de diepte is een concept waarbij meerdere lagen van security controls worden gebruikt binnen een ICT-systeem met de bedoeling om het uitbuiten van een kwetsbaarheid tegen te gaan. 5

6 Indeling van dit document en aanwijzing voor gebruik Deze handleiding is qua opzet geschreven om informatiebeveiligingsmaatregelen te laten samenvallen binnen het bestaande ICT-beheer raamwerk van gemeenten. Ook kan het voorkomen dat er al een bestaand Patchmanagementproces is binnen de gemeente. Vaak zijn dit ICTprocedures, echter het kan ook vorkomen dat Patchmanagement wel wordt uitgevoerd, maar dat dit niet beschreven is. Deze handleiding biedt in beide gevallen een mogelijk aanpak van Patchmanagement binnen de gemeente. Als laatste wordt een stuk aanvullend gemeentelijk beleid rondom Patchmanagement gegeven. 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 maximaal 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. 6

7 2 De noodzaak van patchen en governance Malware maakt gebruik van kwetsbaarheden in systemen of applicaties om zich te kunnen verspreiden en installeren. Door regelmatig te patchen worden bekende kwetsbaarheden tijdig verholpen en wordt de kans op malware besmettingen verlaagd. Er zijn mogelijk tegenstrijdige belangen als het om patchen gaat. Voor het patchen van een systeem/ applicatie kan het noodzakelijk zijn dat deze opnieuw opgestart moet worden. Dit kan leiden tot een (korte) periode van onbeschikbaarheid. Daarnaast kan patchen negatieve impact hebben op de werking van applicaties. Deze conflicterende belangen kunnen invloed hebben op de besluitvorming rond het uitvoeren van patches. Dit maakt het nodig dat er een duidelijke governance rond Patchmanagement ingericht wordt. Aangezien de security patches slechts een deel uitmaken van het totaal aantal patches dat doorgevoerd moet worden, is het niet logisch dat het eigenaarschap van het Patchmanagementproces bij de CISO ligt. De CISO is wel een belangrijke stakeholder in het Patchmanagementproces en er moeten escalatiemogelijkheden zijn om effectief met conflicterende belangen om te kunnen gaan (functiescheiding). Als het niet mogelijk blijkt om binnen de gewenste termijn een beveiligingsupdates door te voeren kan overwogen worden om compenserende maatregelen te implementeren, zoals het inzetten van een Intrusion Prevention System (IPS) of het uitschakelen van bepaalde systeemservices of het betreffende systeem/ applicatie te isoleren zodat het besmettingsgevaar gereduceerd wordt. Door systemen redundant uit te voeren kan eventuele onderbreking van dienstverlening voorkomen worden. Ook kan ervoor gekozen worden om helemaal niets te doen als men naar aanleiding van een gewogen risicoanalyse concludeert dat het risico klein is en de kosten om dit risico weg te nemen niet in verhouding staan tot dit risico Rol CISO ICT beheerder Management/ directie/ proces eigenaar. Verantwoordelijkheid ten aanzien van Patchmanagement: Bewaken vertrouwelijkheid en integriteit van gegevens. Beoordelen noodzaak van de patch om informatiebeveiligingsincidenten te voorkomen. Beoordelen impact van de patch op de informatiebeveiliging. Bewaken beschikbaarheid van gegevens/ diensten. Beoordelen impact van de patch op IT operations. 3 Testen het informatiesysteem na de installatie van de patch. Beslissen in geval van ontbreken van consensus. Testen van de applicatie na installatie van de patch. Op basis van: Aanwezige systemen en configuratie. Ernst van de kwetsbaarheid en kans op misbruik. Impact op de huidige informatiebeveiliging. Complexiteit van de wijziging. Impact op gebruikers en processen. Afweging van risico s die door de CISO en de ICT beheerder zijn voorgelegd. 3 de impact bepaalt de mate waarin getest moet worden en of het nodig is om een roll back plan te hebben 7

8 3 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 4. De IBD levert informatie aan gemeenten over patches. Vaak gaat dit vergezeld van een reparatiepakketje, 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 kwetsbaarheden of geconstateerde dreigingen (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 kwetsbaarheden en mogelijke oplossingen in de vorm van patches. Andere leveranciers van beveiligingspatches en informatie over (systeem) kwetsbaarheden 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 5 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, is: Raakt het kwetsbare systeem 6 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 het kwetsbare systeem? 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 beveiligingslagen. 4 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 5 Zie hiervoor het stappenplan Aansluiten bij de IBD of de factsheet Aansluitproces van de IBD. 6 Onder systeem kunnen o.a. worden verstaan: hardwareonderdelen, besturingssoftware en applicaties. 8

9 Heeft het geraakte systeem impact op meerdere diensten? Wanneer een kwetsbaarheid meerdere diensten raakt, heeft dit gevolgen bij uitbuiting aangezien dit mogelijk een bredere groep gebruikers zal raken. Daarnaast is de totale impact vaak de som van de impact op alle afzonderlijke getroffen diensten, waardoor deze uiteindelijk vele malen hoger kan liggen dan voor één afzonderlijke dienst. Heeft de kwetsbaarheid impact op de productieomgeving? Staat het kwetsbare systeem binnen de productieomgeving of binnen een andere omgeving? Een gecompromitteerd systeem binnen een productie omgeving raakt vaak direct eindgebruikers. Een testsysteem biedt geen of beperkt diensten aan eindgebruikers en zal bij compromittering dus minder impact hebben op de productiviteit van een afdeling. Daartegenover worden testomgevingen vaak minder goed onderhouden dan productie en kan het dat daardoor de beveiliging minder sterk is. In geval van compromittering binnen een ontwikkel, test of acceptatie omgeving dient te worden nagegaan of deze gebruikt kan worden als stepping stone richting productie. Wordt het kwetsbare systeem voor verschillende functionaliteiten? 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 of via de cloud afgenomen kunnen worden. 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 7. 7 Afspraken over patchmanagement kunnen o.a in de verwerkersovereenkomst worden opgenomen. 9

10 4 Het proces, een mogelijke invulling Het Patchmanagementproces dient binnen de gemeente effectief en efficiënt uitgevoerd te worden, Patchmanagement 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 Patchmanagementproces aan te laten sluiten bij bestaande ICT-beheerprocessen binnen de gemeente, dit maakt de implementatie van Patchmanagement makkelijker. Patchmanagement haakt aan bij de volgende, al dan niet ITIL 8, 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. Configuratiebeheer Configuratiebeheer houdt zich bezig met het bijhouden van alle ICT-componenten van de gemeente, deze informatie is cruciaal om vast te stellen of een advies van de IBD of van een leverancier van toepassing is op de gemeentelijke ICT-infrastructuur en applicaties. 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. 9 Het Patchmanagementproces volgt bij voorkeur het standaard wijzigingsbeheerproces inclusief het testen in de OTAP omgevingen. 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, et cetera. 4.1 Reguliere patches Binnen de ICT-beheerafdelingen hebben de verschillende soorten ICT-beheerders (systeem-, applicatie- en functioneelbeheer) 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, idealiter al geïmplementeerd zijn binnen de gemeente. Er wordt maximaal gebruik gemaakt van bestaande processen als patches worden doorgevoerd als onderdeel van de reguliere beheerprocessen. 8 De Information Technology Infrastructure Library (ITIL) is een gestructureerde aanpak voor het leveren van een gewenste kwaliteit van ICT Services. 9 Zie hiervoor het operationel BIG product Handreiking proces wijzigingsbeheer van de IBD. 10

11 Dit ziet er als volgt uit: De ICT-beheerder krijgt informatie dat er een patch voorhanden is voor een systeem met daarin de beschrijving, de mogelijke gevolgen en mogelijke oplossingen van de kwetsbaarheid of dreiging. De ICT-beheerder maakt een eerste inschatting van de urgentie van de patch en de impact op de omgeving. Is het een standaard patch (geen hoge spoed) 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 altijd eerst 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 assessment 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. Indien van toepassing dient na doorvoeren van de patch de ICT foto te worden bijgewerkt. 4.2 Spoed-patches Spoed-patches kunnen op diverse manieren binnenkomen. Patches vanuit het reguliere proces (zie hoofdstuk 4.1) kunnen op basis van risico inschatting opgeschaald worden naar een spoed-patch. Daarnaast kunnen meerdere partijen een bericht uitzenden mbt tot een spoed patch. Dit zijn o.a. de leveranciers van betreffende systemen maar ook met name relevante partijen zoals de IBD en het NCSC. Normaliter zullen gemeenten niet direct van het NCSC patch adviezen ontvangen maar vanuit de IBD. De adviezen vanuit de IBD worden verzonden aan 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: Functioneel applicatiebeheer Testen functioneel applicatiebeheer Nee Test geslaagd? Ja Technisch applicatie beheer Testen technisch applicatiebeheer Ja Test geslaagd? Nee Applicatie aanpassen Patch management spoed patches ICT beheer Change management Reguliere patch via leveranciers Bepalen urgentie en impact Aanmelden change, spoed Patch op testomgeving zetten Patch in productie Afmelden change Patch van toepassing? Spoed patch? DSC / CISO Patch advisory van IBD classificatie Overleg, onderzoeken alternatieven Nee Ja Nee Ja High / High Nee, end Regulier maandelijks onderhoud Het advies van de IBD komt binnen bij de IBD-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 5 Controle op de werking van het patch proces 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. 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 kwetsbaarheden. 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 de ICT beheerders of een externe partij. Het uitvoeren van een vulnerability scan is geen ethical 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 geïnstalleerd en onderhouden en die veranderingen kunnen weer nieuwe kwetsbaarheden 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 wijziging. Het is daarnaast aan te bevelen om de resultaten van vulnerability scans periodiek met het management te bespreken om voldoende commitment te creëren om afwijkingen met de juiste prioriteit op te pakken en tijdig weg te werken. Effectief kwetsbaarhedenbeheer vereist een zo compleet mogelijk inzicht van de aanwezige assets in de ICT-Infrastructuur. De configuratiebeheerdatabase kan hierbij als uitgangspunt dienen. 10 In de praktijk blijkt echter dat de configuratiebeheerdatabase geen juist en volledig beeld geeft van de werkelijkheid. Binnen het kwetsbaarhedenbeheer/ patchmanagementproces moet men hier dus rekening mee houden. Verschil vulnerability scan en Penetratie Test (pentest) Vulnerability Scan Penetratie Test 11 Hoe vaak uitvoeren Zo vaak als mogelijk, als Indien nodig onderdeel van normale werkzaamheden Rapportage Uitvoerig rapport met alle kwetsbaarheden/ issues per Alleen over het te onderzoeken systeem of functie systeem Resultaat Lijsten met bekende kwetsbaarheden per systeem Onderzoek naar onbekende kwetsbaarheden en risico s Door wie Is door de informatiebeveiligingspecialist Specialistisch, in te huren of ICT uit te voeren met de juiste tooling. Kosten Eigen uren en product kosten Afhankelijk van diepgang en controlepunten 10 Zie hiervoor het operationel BIG product Handreiking proces configuratiebeheer van de IBD. 11 Zie hiervoor het operationel BIG product Handreiking-penetratietesten van de IBD. 13

14 Bijlage: Patchmanagementbeleid gemeente <gemeente> Het Patchmanagementbeleid van de gemeente geeft richting aan de wijze waarop de gemeente maatregelen wenst te treffen voor een adequate inrichting en uitvoering van Patchmanagement. De gemeente onderschrijft het belang van Patchmanagement omdat het niet op een gestructureerde wijze bijhouden van patches voor gemeentelijke systemen er voor kan zorgen dat kwetsbaarheden van die systemen toenemen. Dit beleid is van toepassing op iedereen die binnen de gemeente een rol heeft in het uitvoeren van Patchmanagement. 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 evaluatie wordt minimaal de systeemeigenaar betrokken. Bij vermoeden van hoog risico wordt de CISO of informatiebeveilgingsfunctionaris geconsulteerd. 4. De technische integriteit van programmapakketten en infrastructurele programmatuur wordt gecontroleerd door middel van 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 maximaal 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 12 wordt geupdate met de nieuwe versienummers van componenten. 10. Van alle uitgevoerde en niet uitgevoerde patches wordt door de ICT beheerders een logboek bijgehouden. Aldus vastgesteld door burgemeester en wethouders van [gemeente] op [datum], [Naam. Functie] [Naam. Functie] 12 Denk ook aan het bijwerken van de ICT foto (indien van toepassing). 14

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