Gemeente Zandvoort. Telefoon: Fax:

Transcriptie

1 Vastgesteld door het college : d.d. 19 mei 2015 Gepubliceerd in de Zandvoortse Courant : d.d. 26 mei 2015 Inwerkingtreding : d.d. 19 mei 2015 Registratienr: 2015/05/ Auteur: R. Zwietering

2 Gemeente Zandvoort Telefoon: Fax: Internet: Postadres: Postbus AA Zandvoort Bezoekadres: Swaluëstraat 2 Zandvoort Bankrekening: NL64 BNGH Registratienr: 2015/05/ Datum: 12 mei 2015

3 INHOUDSOPGAVE 1 INLEIDING PATCHING BELEID PATCHING PROCESSEN CONTROLE EN RAPPORTAGE... 8

4 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. Patch Management is het proces waarmee patches op gecontroleerde en risico beperkende wijze uitgerold kunnen worden. Patches zijn doorgaans kleine aanpassingen om fouten op te lossen of verbeteringen aan te brengen in bestaande programmatuur en / of hardware. Patch Management wordt uitgevoerd door de ICTbeheer binnen de 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 aanwijzing 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. 2015/05/ d.d. 19 mei /9

5 2 PATCHING BELEID Het Patchingbeleid 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 evaluatie 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 beveiligingsupdates/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. Een geïnstalleerde patch wordt automatisch gelogd en bijgewerkt. 2015/05/ d.d. 19 mei /9

6 3 PATCHING PROCESSEN Er zijn meerdere manieren waarop patch informatie bij de gemeente kan binnenkomen: 1. Via de systeembeheerder: Een systeembeheerder 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. 1. Via de IBD: 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. Reguliere patches De systeembeheerder 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, wordt met de CISO/informatiemanager en applicatiebeheerder overlegd hoe verder te gaan. Dit overleg leidt tot het doorvoeren van de patch als change of de patch wordt niet doorgevoerd. Bij het doorvoeren van de patch wordt vooraf een snapshot gemaakt. Eventuele testen worden uitgevoerd door de 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. Wanneer een test of patch niet goed blijkt te werken kan de snapshot teruggezet worden. Na een succesvolle patch dient de configuratiedatabase te worden bijgewerkt met de nieuwe versienummers. Van alle uitgevoerde en niet uitgevoerde patches wordt een logboek bijgehouden. Spoedpatches 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. 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 spoedpatch bestaan dan dient het wijzigingsproces verkort doorlopen te worden, echter de patch wordt altijd getest. Na succesvol patchen zijn de systemen 2015/05/ d.d. 19 mei /9

7 weer up to date. De configuratiedatabase wordt bijgewerkt met de nieuwe versienummers. Patches worden geclassificeerd en afhankelijk van de classificatie verwerkt. Spoed Regulier z.s.m. Dagelijks Maandelijks (in een weekend) Maandelijks, maar afhankelijk van derden zoals leveranciers of Antivirus MSWindows VMware Firewall Java Development Kit (JDK) afnemers GegevensMakelaar Opmerking: GreenValley is verantwoordelijk voor het gehele websitesysteem, waaronder de website, Apache Tomcat server, SQLserver, Filezilla en Java Runtime Environment (JRE). 2015/05/ d.d. 19 mei /9

8 4 CONTROLE 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 ICTinfrastructuur, 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. Een penetratietest wordt uitgevoerd bij een audit. Verschil vulnerability scan en pentest Vulnerability Scan Penetratie Test Hoe vaak uitvoeren Rapportage Resultaat Door wie Kosten 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 Eigen uren en product kosten Indien nodig Alleen over het te onderzoeken systeem of functie Onderzoek naar onbekende zwakheden en risico s Specialistisch, in te huren Afhankelijk van diepgang en controlepunten 2015/05/ d.d. 19 mei /9

9 2015/05/ d.d. 19 mei /9