Patch Management Beleid en Procedure v3.2

Transcriptie

1 Patch Management Beleid en Procedure v3.2 Auteurs: Marius van Oers / Martijn Mol Aanmaak datum: 19 augustus 2015 Laatste wijziging: 26 oktober 2016

2 Versiebeheer Versie Datum Auteur Status/Wijzigingen /04/13 Jan van Tiggelen Concept /05/13 Jan van Tiggelen Tekstuele aanpassingen om leesbaarheid te verbeteren /09/13 Martijn Mol/Marius van Oers /12/13 Marius van Oers Komplete herschrijving /12/13 Marius van Oers Komplete herschrijving /12/13 Marius van Oers Modificaties n.a.v. terugkoppeling van Paul/Rob/George /12/13 Marius van Oers Flowcharts toegevoegd /01/14 Marius van Oers Modificaties n.a.v. terugkoppeling van Monique/Jolien /01/14 Marius van Oers Modificaties n.a.v. terugkoppeling van George/Jolien /03/14 Marius van Oers Modificaties n.a.v. terugkoppeling van 27A - Erik de Vries 27B - Harvey vd Meer 27C - Wim van Iersel 27D - Erik Manders 27 E - Theo van Dijk 27 F - Martien Noij 27G - Jan van Tiggelen - gecombineerde reactie van Systeembeheer /03/14 Marius van Oers Opmaak - vele kleine mods /04/14 Marius van Oers Modificaties n.a.v. terugkoppeling van Paul /04/14 Marius van Oers Modificatie n.a.v. terugkoppeling van Richard /05/14 MT POI Vastgesteld in MT POI. Een implementatieplan dient opgesteld te worden /03/15 Marius van Oers A1.5 - Documentatie gevuld m.b.t. registratie proces van bewust niet ge-installeerde patches /8/15 MvO & Rik Reinink Wijzigingen/verduidelijkingen in Appendix A1.5.1 & A1.5.2 & Inhoudsopgave n.a.v. terugkoppeling Rik/George/Hikmet. Bestandsnaam: Patch Management Beleid en Procedure Pagina 2 van 22

3 Inhoud 1.0 Patch Mananagement Beleid Inleiding Beleid Scope Rollen en verantwoordelijkheden Gerelateerde documenten Appendix A - Patch Management Procedure A1.0 - Kans en Impact classificaties bepalen het Risico niveau A1.1 - Kans - classificatie van een patch A Impact - classificatie voor de Gemeente Tilburg A Impact - Showstoppers A1.3 - Risico - classificatie voor de Gemeente Tilburg A1.4 - Change Management proces A1.5 - Documentatie A Registratie Niet ge-installeerde Patch A Omzetten niet-geïnstalleerde patch naar niet-standaard Change A1.6 - Flowcharts A Flowchart patches mbt reguliere changes A Flowchart patches mbt standaard changes Bestandsnaam: Patch Management Beleid en Procedure Pagina 3 van 22

4 1.0 Patch Mananagement Beleid 1.1 Inleiding Wat is een patch? Een softwarematige patch is software dat wordt uitgebracht om bijvoorbeeld fouten op te lossen of verbeteringen door te voeren in de software. Indien er in uitgebrachte software naderhand tekortkomingen worden geconstateerd dan kunnen deze vaak worden verholpen door middel van het toepassen van een patch. Een patch is dus een aanpassing van bestaande software om bijvoorbeeld fouten in de software te verhelpen. Deze fouten kunnen bijvoorbeeld betrekking hebben op beveiligings issues omtrent de software, het niet goed werken van de software op zichzelf alsmede het niet goed werken van de software in relatie met andere hard en software. Patch management is een onderdeel van het beheer van systemen. Het behelst het beoordelen, verkrijgen, testen en installeren van patches (code wijzigingen) op beheerde computersystemen. Patch Management is het proces waarmee patches op gecontroleerde, beheerste (risico beperkende) wijze uitgerold kunnen worden. Patch management omvat onder andere: Het bijhouden van informatie mbt welke patches er beschikbaar zijn. Het beslissen welke patches nodig zijn voor bepaalde systemen voor de situatie van de Gemeente Tilburg. Het beslissen in welk tijdsframe patches geïnstalleerd dienen te worden. Het volgen van alle bijbehorende (installatie) procedures. Het ervoor zorgen dat patches correct zijn geïnstalleerd. Het testen van systemen na installatie van patches. Patches zijn onder te verdelen in 4 gebieden: Adaptief - voor aanpassingen in de gebruikersomgeving waarin het zich bevindt - bijvoorbeeld naar aanleiding van veranderde wet en regelgeving of gevraagde nieuwe functionaliteit. Perfectief - voor het verbeteren van de efficiency van het beheer van het systeem of de applicatie Preventief (voor het voorkomen van incidenten) Correctief (voor het oplossen van incidenten) Dit patchbeleid zet de norm voor de komende jaren. De daadwerkelijke invoering bestrijkt in ieder geval de planperiode van het informatiebeveiligingsbeleid, dwz tot en met Bestandsnaam: Patch Management Beleid en Procedure Pagina 4 van 22

5 1.2 Beleid Dit document beschrijft het Patch Management Beleid. De Gemeente Tilburg maakt gebruik van een breed pakket van software oplossingen voor het uitvoeren van haar taken. Software ontwikkelingen gaan snel en software dient dan ook ten alle tijden bijgehouden te worden. Dit is niet alleen noodzakelijk om compatibiliteit met bijvoorbeeld huidige versies van operating systemen alsmede andere applicaties te behouden. Een andere reden is dat malware en hackers op grote schaal misbruik maken van kwetsbaarheden/vulnerabilities in zowel huidige (zero day exploits) als oude software. Veelal is het zo dat nieuwere versies van de software minder kwetsbaarheden bevatten. Het patchmanagementbeleid voor de Gemeente Tilburg houdt in dat : De hoogste/laatste op het moment beschikbare Patch dient ge-installeerd te worden. De richtlijn is dat alle software (patches,updates.upgrades) moet idealiter continue up to date worden gehouden. Software upgrades/updates - voor zowel de major als minor versie - moeten bijgewerkt worden tot de laatste release versie of de vorige versie. Indien software pakket XYZ een versie heeft van v7.5, dan is 7 de major versie en.5 de minor versie. De applicatie- en systeem beheerders van de diverse applicaties en/of systemen zijn zelf verantwoordelijk voor de uitvoering van het patchmanagement beleid voor hun eigen applicatie/systeem. Dit geldt voor alle beheerders - applicatie/database/netwerk/systeem beheerders etc. Bij beschikbaarheid van patches dient er een afweging gemaakt te worden met betrekking tot Kans en Impact ter bepaling van het Risico voor de situatie bij de Gemeente Tilburg. Aan zowel de Kans als de Impact wordt de classificatie laag, middel of hoog toegekend. Op grond hiervan wordt de Risico Classificatie voor de Gemeente Tilburg vastgesteld en wordt de urgentie bepaald waarbinnen een patch geïmplementeerd dient te worden. Indien een patch überhaupt niet doorgevoerd kan worden doordat er onderlinge afhankelijkheden zijn dan dient dit in zijn verband opgepakt te worden. Een aangekoppelde applicatie dient zich aan te passen aan de hoofdapplicatie. De problematiek rond onderlinge afhankelijkheden dient ook gecommuniceerd te worden richting de coördinator informatiebeveiliging en eventueel de security officer. Indien er andere redenen zijn om een patch überhaupt of voorlopig niet door te kunnen voeren dan dient dit gecommuniceerd te worden richting de coördinator informatiebeveiliging en eventueel de security officer. Patches moeten het Changemanagement proces doorlopen. Patches dienen idealiter eerst te worden getest alvorens deze volledig in de Produktie omgeving worden ge-implementeerd. Ook kan gefaseerde invoering overwogen worden. Nieuwe IT componenten (servers, desktops, etc.) moeten volledig gepatched worden voordat ze aan de productie omgeving worden toegevoegd. Nieuwe software op IT componenten van de gemeente Tilburg moet volledig zijn gepatched om zo nieuwe risico's te beperken. Bestandsnaam: Patch Management Beleid en Procedure Pagina 5 van 22

6 Het Tilburgse patchmanagement beleid is in overeenstemming met het patchmanagement beleid van de IBD. Alhoewel de onderstaande items veelal inherent al zijn geaddresseerd worden ze hierbij nogmaals expliciet vermeld. Bron : Er dient een proces ingericht te zijn voor het beheer van kwetsbaarheden en patching van (systeem) software binnen de gemeente. De IBD stuurt niet alleen Kwetsbaarheidsmeldingen richting de Gemeente Tilburg, de Gemeente Tilburg kan zelf ook Incidenten melden bij de IBD. Er dienen periodieke kwetsbaarheden/penetratietesten uitgevoerd te worden. Ook dienen er risicoanalyses uitgevoerd te worden van kwetsbaarheden en patching. Van softwarematige voorzieningen van de technische infrastructuur dient - bij voorkeur geautomatiseerd - gecontroleerd te worden of de laatste patches zijn doorgevoerd. 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). 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. In de meeste gevallen gebeurt dit ook intern in de patch door middel van een zelfcheck aan het begin van de installatie. Alle patches dienen voor installatie te worden getest. Behoudens de door de leverancier goedgekeurde updates worden er geen wijzigingen aangebracht in programmapakketten en infrastructurele programmatuur. 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. Indien nog geen patch beschikbaar is dient gehandeld te worden volgens het advies van de Informatiebeveiligingsdienst voor gemeenten of een CERT (Computer Emergency Response Team) zoals het NCSC, dit ter migitatie van kwetsbaarheden. Als een systeem gepatched is wordt de systeem documentatie bijgewerkt naar de laatste stand van zaken, de configuratie management database moet worden geupdated met de nieuwe versienummers van componenten. Van alle uitgevoerde en niet uitgevoerde patches wordt door de ICT een logboek bijgehouden, conform afspraken in het changemanagement proces. Bestandsnaam: Patch Management Beleid en Procedure Pagina 6 van 22

7 1.3 Scope Dit beleid is van toepassing op (systeem) software aanwezig op IT componten waar de Gemeente Tilburg eigenaar van is en/of het beheer van doet. Van leveranciers wordt hetzelfde verwacht; dit wordt afgesproken in contracten en er wordt toegezien op de naleving hiervan. Enkele voorbeelden van componenten die hieronder vallen zijn onder andere: Servers, Desktop, Laptops, Mobiele devices. Dit omvat niet alleen het operating systeem maar ook alle door de Gemeente Tilburg ondersteunde software. Applicatie Software, zoals bijvoorbeeld alle interne Applicaties, Oracle, Java, Adobe Acrobat Reader, Shockwave Flash etc. (Systeem) software aanwezig op Routers : firmware updates etc Firewalls : de huidige "next generation"firewalls bevatten veel software componenten zoals bijvoorbeeld IDS/IPS functionaliteit en deze dienen dan ook up to date gehouden te worden. Web Security Gateways : vanzelfsprekend dient dit up to date bijgehouden te worden. Anti-Virus Software : vanzelfsprekend dient dit up to date bijgehouden te worden. Information Rights Management Software : Seclore FileSecure protectors & (client ) agents moeten bijgwerkt en in sync met elkaar blijven. Data Loss Prevention Software : protectors & client agents moeten bijgwerkt en in sync met elkaar blijven. Externe leveranciers; bijvoorbeeld SaaS providers, web site hostings Bestandsnaam: Patch Management Beleid en Procedure Pagina 7 van 22

8 1.4 Rollen en verantwoordelijkheden De applicatie- en systeem beheerders van de diverse applicaties en/of systemen zijn zelf verantwoordelijk voor de uitvoering van het patchmanagement beleid voor hun eigen applicatie/systeem software. Dit geldt voor alle beheerders: applicatie/database/netwerk/systeem beheerders etc. Indien er, met betrekking tot patches, security vraagstukken zijn dan dienen die eerst intern in het desbetreffende team gecommuniceerd en geaddresseerd te worden. Aanspreekpunt is de security technisch operationeel contactpersoon bij de teams Systeembeheer, Advies & Ontwikkeling en Funktioneel/Applikatie Beheer. Komt men er niet uit dan kan advies worden gevraagd van de coördinator informatiebeveiliging en eventueel security officer. Alle teammanagers zien toe op het naleven van de beleidsregels en zijn mede verantwoordelijk voor het uitdragen van het opgestelde beleid. Bij het niet naleven van de afspraken neemt de teammanager passende maatregelen. Informatie met betrekking tot security incidenten en beschikbaarheid van patches dient door de beheerders zelf bijgehouden te worden. Dit kan door bijvoorbeeld het bijhouden van/registreren op Ncsc, Sans, Secunia, alsmede de website van de Software leverancier. De IBD (Informatie Beveiligings Dienst) voor gemeenten stuurt onder andere kwetsbaarheidswaarschuwingen. Een van de doelen is dat de IBD dagelijks gaat signaleren welke kwetsbaarheden en patches er voor onze systemen beschikbaar zijn. Dit is te zien als een soort vangnet functie om te voorkomen dat we iets missen of niet tijdig zien. Ongeacht of er wel of geen relevante kwetsbaarheidsberichten zijn dienen de beheerders toch minimaal 1x per maand te checken of er patches beschikbaar zijn op de website van de leverancier. Incidenten kunnen vanuit de Gemeente Tilburg ook aan de IBD gemeld worden. Van alle uitgevoerde en niet uitgevoerde patches wordt door de ICT een logboek bijgehouden. Wellicht dat dit in de toekomst richting het bijhouden in de CMDB kan gaan. De beveiligingsspecialisten bij de desbetreffende afdelingen leveren periodiek (1x per kwartaal) een rapportage aan - aan de coördinator informatiebeveiliging en security officer - ter controle of de juiste security patches alsmede volgens de richttijd zijn uitgevoerd. De afdeling PO&I adviseert de directie, afdelingen en het college inzake beveiliging, formuleert het beveiligingsbeleid, bewaakt de stuurcyclus en treedt op als opdrachtgever van controle programma's. Hiertoe is binnen de afdeling PO&I de strategisch adviseur informatisering aangewezen als Security officer. De Coördinator InformatieBeveiliging voert steeksproef gewijs lijncontroles uit op naleving en werking van de technische uitwerkingen, in deze context wordt bedoeld controle of de laatste patches zijn doorgevoerd. Planning & Controle voert periodiek controles uit op naleving van deze beleidsregels. Zonder nadere aankondiging kunnen er vanuit de beveiligingsorganisatie checks, penetratie- en kwetsbaarheids testen en audits worden uitgevoerd op de naleving van het patchmanagement beleid. Daarnaast vind er een jaarlijkse interne kwaliteitstoetsing plaats op het gebied van Informatiebeveiliging (KIB). Bestandsnaam: Patch Management Beleid en Procedure Pagina 8 van 22

9 Het document dat het basisbeveiligingsniveau beschrijft inclusief de aanvullende maatregelen voor de meer kritieke processen is normenkader informatiebeveiliging Tilburg en is gebaseerd op Tilburgse ervaringen, best practices en de code voor informatiebeveiliging. Dit patchbeleid is een nadere invulling /uitwerking van een maatregel uit het normenkader. Hoofdstuk 12 gaat over de Verwerving, Ontwikkeling en Onderhoud van informatiesystemen. Hoofdstuk 12.6 heeft als titel "Beheer van technische kwetsbaarheden", quote: "Doelstelling: Risico's verminderen als gevolg van benutting van gepubliceerde technische kwetsbaarheden. Er behoort tijdig informatie te worden verkregen over technische kwetsbaarheden van de gebruikte informatiesystemen. De mate waarin de organisatie bloot staat aan dergelijke kwetsbaarheden behoort te worden geëvalueerd en er behoren geschikte maatregelen te worden genomen voor behandeling van daarmee samenhangende risico's. " In de Appendix A van het normenkader document staan de BIV (Beschikbaarheid, Integriteit, Vertrouwelijkheid) classificaties vermeld. Bestandsnaam: Patch Management Beleid en Procedure Pagina 9 van 22

10 1.5 - Gerelateerde documenten Versie Titel 1.0 Gemeente Tilburg Informatiebeveiligingsbeleid Normenkader Gemeente Tilburg 3.0 G:\TBPOI\Algemeen\ITIL\CHANGEMANAGEMENT\WERKINSTRUCTIES\ Werkinstructies changemanagement v3.doc Bestandsnaam: Patch Management Beleid en Procedure Pagina 10 van 22

11 Appendix A - Patch Management Procedure A1.0 - Kans en Impact classificaties bepalen het Risico niveau. Patches komen continue beschikbaar en de verwachting is dat dit in de nabije toekomst niet anders zal zijn. De applicatie- en systeem beheerders van de diverse applicaties en/of systemen zijn zelf verantwoordelijk voor de uitvoering van het patchmanagement beleid voor hun eigen applicatie/systeem. De beheerders dienen zelf bij te houden of er patches beschikbaar zijn. Dit kan bijvoorbeeld door middel van aanmelden voor kwetsbaarheidswaarschuwingen bij de leverancier van de software. Ook via sites als Secunia kan waardevolle informatie worden verkregen. Aanvullend hierop zal in de toekomst de IBD specifieke waarschuwingen mbt kwetsbaaarheden toesturen die van toepassing zijn op het het Tilburgse ICT (operating/applikatie) landschap. Ongeacht of er wel of geen relevante kwetsbaarheidsberichten zijn dienen de beheerders toch minimaal 1x per maand te checken of er patches beschikbaar zijn op de website van de leverancier. Aangezien de Gemeente Tilburg een behoorlijk groot (operating) Systeem- alsmede Applicatielandschap heeft is het zinvol om een gestandaardiseerde manier van patchen toe te passen waarbij de spelregels van te voren bekend zijn en er alleen gestuurd hoeft te worden op afwijkingen (management by exception). Hiervoor moeten we richtlijnen meegeven: Hoe patches geclassificeerd kunnen worden Binnen welke termijn patches geimplementeerd dienen te worden Bestandsnaam: Patch Management Beleid en Procedure Pagina 11 van 22

12 A1.1 - Kans - classificatie van een patch Indien er een patch wordt uitgebracht dan wordt er meestal door de software provider een classificatie aan toegekend. Bijvoorbeeld software leverancier Microsoft brengt een patch uit ter addressering van een bepaalde vulnerability in Office365 met als risico classificatie High Risk. De risk classificatie bepaald de kans dat iets misbruikt kan gaan worden. Meestal wordt er voor de Kans - classificatie gebruik gemaakt van de waarden: Low Medium High Indien er (bijvoorbeeld door de leverancier) andere waarden (bijvoorbeeld 5 in plaats van 3 classificaties) worden toegekend dan dienen deze te worden geconverteerd naar Low/Medium/High. Kans classificaties komen veelal ook van externe partijen zoals security boards, enkele voorbeelden zijn onder andere: Ncsc (het vroegere Govcert) - IBD (Informatiebeveiligingsdienst voor gemeenten) - Sans - Secunia - Bestandsnaam: Patch Management Beleid en Procedure Pagina 12 van 22

13 A Impact - classificatie voor de Gemeente Tilburg Niet alleen de kans classificatie van een patch op zich is een wegingsfaktor. Een andere faktor is de impact voor de Gemeente Tilburg. Stel in het voorgaande voorbeeld dat Office365 uberhaupt niet in gebruik is bij de Gemeente Tilburg dan is de impact voor de Gemeente Tilburg op dat moment nul. Elke vulnerability alert en patch release moet geverifierd worden of deze van toepassingen is op de systemen en diensten van de Gemeente Tilburg voordat actie wordt ondernomen, dit om onnodig patchen te voorkomen. Lang niet alle patches zijn van toepassing op de systemen en software die de gemeente heeft. Voor alle patches dient er getoetst te worden wat de mogelijke impact voor de Gemeente Tilburg kan zijn en dient er een soortgelijke impact classificatie opgesteld te worden met de waarden: Low Medium High In de praktijk blijkt dat de impact classificatie voor de Gemeente Tilburg veelal belangrijker is dan de kans classificatie van een patch. De impact classificatie gebeurt meestal onbewust. De verantwoordelijke beheerders dienen zelf zo goed mogelijk de impact te bepalen. Indien er, met betrekking tot patches, security vraagstukken zijn dan dienen die eerst intern in het desbetreffende team gecommuniceerd en geaddresseerd te worden. Aanspreekpunt is de security technisch operationeel contactpersoon bij de teams Systeembeheer, Advies & Ontwikkeling en Funktioneel/Applikatie Beheer. Komt men er niet uit dan kan advies worden gevraagd van de coördinator informatiebeveiliging en eventueel security officer. Is er uiteindelijk dan nog geen overeenstemming dan kan bij uitzondering worden afgeweken van de procedure en kan men de impact bepalen op Medium. A Impact - Showstoppers Tijdens de beoordeling van de Impact dient er ook een afweging te worden gemaakt of er dringende redenen zijn om een patch niet door te voeren. Indien een patch überhaupt niet doorgevoerd kan worden omdat er bijvoorbeeld onderlinge afhankelijkheden zijn dan dient dit in zijn verband opgepakt te worden. Ter verdieping en verduidelijking enkele voorbeelden: -Een applicatie die aanhaakt bij het endpoint moet zich aanpassen voor wat betreft de koppeling naar het endpoint, bijvoorbeeld als Octopus niet werkt op P8 moet Octopus zich aanpassen en niet p8. -Indien een aangekoppelde applicatie niet werkt nadat de hoofdapplicatie is gepatched, dan dient de aangekoppelde applicatie te worden gemodificeerd (update/patch). Bijvoorbeeld hoofdapplicatie FileNet, hier zijn zeer veel koppelingen. Wanneer er een patch moet worden geïnstalleerd mag een aangehaakte applicatie idealiter geen showstopper zijn. De problematiek rond onderlinge afhankelijkheden dient ook gecommuniceerd te worden richting de coördinator informatiebeveiliging en eventueel de security officer. Indien er andere redenen zijn om een patch überhaupt of voorlopig niet door te kunnen voeren dan dient dit gecommuniceerd te worden richting de coördinator informatiebeveiliging en eventueel de security officer. Bestandsnaam: Patch Management Beleid en Procedure Pagina 13 van 22

14 A1.3 - Risico - classificatie voor de Gemeente Tilburg Aan zowel de Kans als de Impact wordt de kwalificatie laag, middel of hoog toegekend. Op grond hiervan wordt de Risico Classificatie voor de Gemeente Tilburg bepaald via het onderstaande schema. High Impact Medium Low Low Medium High Kans In de praktijk blijkt dat de impact classificatie veelal belangrijker is dan de kans. Ter verduidelijking een voorbeeld. De Software Leverancier (of andere input zoals via Secunia) bepaalt de kans (h/m/l) (Secunia hoog = enkel de kans) Wat de impakt is voor de specifieke situatie voor de gemeente tilburg dat dienen we zelf te bepalen. (h/m/l) De combinatie van kans en impakt bepaalt het risico voor de gemeente tilburg. Dus als de kans hoog is maar impakt laag dan is de Risico Classificatie voor de Gemeente Tilburg "2". Aan de hand van de Risico classificatie voor de Gemeente Tilburg kan er bepaald worden welke prioriteit er aan een bepaalde patch moet worden gegeven en binnen welke termijn een patch geïmplementeerd dient te worden. De termijn start vanaf het moment dat er een patch beschikbaar is. Risico Classificatie 1 : patch dient idealiter binnen 2 maanden geïmplementeerd te zijn Risico Classificatie 2 : patch dient idealiter binnen 1 maand geïmplementeerd te zijn Risico Classificatie 3 : patch dient idealiter binnen 2 weken geïmplementeerd te zijn Risico Classificatie 4 : patch dient idealiter binnen 1 week geïmplementeerd te zijn Er zijn enkele Applicaties die veel en vaak worden misbruikt door malware en/of hackers en door zo'n beetje iedereen binnen de gemeente worden gebruikt. Hier kunnen we in de toekomst van overwegen dat we hier een strikter patch schema op hanteren mbt het tijdsframe waarbinnen de patch geïmplementeerd dient te worden. Enkele voorbeelden hiervan zijn: Adobe Acrobat reader Adobe Flash player Adobe Shockwave Java Microsoft Activex Microsoft Office (voor met name ms-word exploits) Google Chrome Microsoft Internet Explorer Mozilla Firefox Safari Bestandsnaam: Patch Management Beleid en Procedure Pagina 14 van 22

15 A1.4 - Change Management proces Patches moeten het Change Management proces doorlopen. Het change management proces bepaalt uiteindelijk of een change (zoals een patch) uitgevoerd mag gaan worden. Het change management proces is aan veranderingen onderheven en derhalve verwijzen we hier naar het officiële change management beleid en procedure voor de correcte informatie. De werkinstructies van het change management proces staan hier: G:\TBPOI\Algemeen\ITIL\CHANGEMANAGEMENT\WERKINSTRUCTIES\Werkinstructies changemanagement v3.doc Momenteel zijn er 3 soorten changes: Reguliere changes, Standaard changes en Emergency changes. Patches dienen idealiter eerst te worden getest alvorens deze volledig in de Produktie omgeving worden ge-implementeerd. Ook kan gefaseerde invoering overwogen worden. Indien er hierbij fouten worden geconstateerd dan dient men terug te gaan naar de oorspronkelijke situatie dmv rollbacks: terugzetten snapshots etc. Bottlenecks dienen struktureel (in zijn verband) aangepakt te worden waarna het patchproces weer doorlopen kan gaan worden. Het patchen van OTA omgevingen is vooralsnog geen harde vereiste. Wel is het zo dat een betrouwbaarder beeld verkregen kan worden indien (bijvoorbeeld) de verschillen tussen de A en P omgeving zo klein mogelijk zijn. Indien er in het change management proces twijfel ontstaat mbt de Impact zoals bepaald door enerzijds de aanvrager van de change - de beheerder van de applicatie die een patch wil doorvoeren - en anderzijds de CAB leden dan kan kontakt worden gezocht met de coördinator informatiebeveiliging om een verdere beoordeling te doen en advies te geven. De coördinator informatiebeveiliging kan eventueel verder escaleren richting de security officer. Bij een emergency patch ( zoals Patches met Risico Classificatie 4 ) volgt een emergency change. De indiener geeft dit aan bij het indienen, de change manager beslist vervolgens of het daadwerkelijk een emercengy change wordt. De Change manager doet de beoordeling, mogelijk met ruggespraak van de coördinator informatiebeveiliging, de security officer en emergency CAB. Indien een change is verklaard tot een standaard change dan doorloopt een identieke change het proces voor standaard changes, met inachtneming van dezelfde eerder bepaalde risicoclassificatie en tijdsframe waarbinnen de patch idealiter geïmplementeerd dient te worden. De bepaling wat een standaard change is wordt gedaan door de CAB leden, eventueel in overleg met de coördinator informatiebeveliging en/of security officer. Bestandsnaam: Patch Management Beleid en Procedure Pagina 15 van 22

16 A1.5 - Documentatie Van alle uitgevoerde en niet uitgevoerde patches wordt door de ICT een logboek bijgehouden, conform afspraken in het changemanagement proces. Patches moeten het Change Management proces doorlopen. Het change management proces bepaalt uiteindelijk of een change (zoals een patch) uitgevoerd mag gaan worden. Voor patches die we wel zouden moeten installeren maar waarvan de afweging wordt gemaakt om een patch bewust niet te installeren moet worden gedocumenteerd dat deze afweging bewust is gemaakt en er dient ook een reden opgegeven te worden in de toelichting. Indien op een later tijdstip alsnog wordt besloten om eerder niet ge-installeerde patch nu wel te installeren dan kan deze registratie worden heropend. Bestandsnaam: Patch Management Beleid en Procedure Pagina 16 van 22

17 A Registratie Niet ge-installeerde Patch Aanmaken nieuwe niet-geïnstalleerde patch: 1. Ga naar TOPdesk en selecteer "Nieuwe wijzigingsaanvraag" 2. Onder Aanmelder: vul je Naam in 3. Onder Details: vul de Korte omschrijving in Kies bij Sjabloon : Niet ge-installeerde patch/update/release/fix De bij Soort : Niet ge-installeerde patch/update/release/fix 4. Onder Object/Ruimte: Selecteer het juiste Object ID. 5. Onder Aanvraag : geef de reden aan waarom de patch niet geïnstalleerd is: vul de tekst aan: Niet geïnstalleerd omdat: 6. Onder Actieveld: Vul eventueel nog een actie in bij het actieveld. 7. Onder Aanvraag autoriseren: vink Afwijzen aan 8. Sla de wijziging op (herbevestig afwijzen) NB. De hieromtrent vanuit het servicepunt kan genegeerd worden. (De aanvraag wordt door de betrokken disciplines beoordeeld. Je ontvangt nog een bericht wanneer de aanvraag wordt goedgekeurd of afgewezen.) Bestandsnaam: Patch Management Beleid en Procedure Pagina 17 van 22

18 A Omzetten niet-geïnstalleerde patch naar niet-standaard Change Wanneer een patch toch uitgevoerd wordt moet de afgewezen wijziging omgebouwd worden naar Niet-Standaard Change: 1 Zoek in TOPdesk door middel van de zoekfunctie naar de eerder afgewezen patch. Zoek op soort: "Wijzigingen". Zoektermen om te gebruiken zijn bijvoorbeeld de naam van de software, het versienummer en "niet geïnstalleerd" 2 Selecteer uit de resultaten de niet geïnstalleerde patch en open deze door tweemaal te klikken 3 Verwijder het vinkje bij afwijzen, bevestig dit door de kaart op te slaan 4 Open het tweede tabblad van de kaart; details 5 Selecteer bij Soort: "Niet standaard wijziging" Bestandsnaam: Patch Management Beleid en Procedure Pagina 18 van 22

19 5 Vermeld in het actievak dat de change opgenomen moet worden in het reguliere changeproces. 6 Stuur het volledig ingevulde RFC document op naar het Servicepunt met de vermelding naar het W-nummer zodat deze door het reguliere changeproces opgenomen kan worden. Als het een standaard change betreft vergeet niet het goedgekeurde W-nummer te vermelden. Het RFC dient volledig ingevuld te worden volgens de normale Change Management standaarden zodat deze door het CAB beoordeeld kan worden. Bestandsnaam: Patch Management Beleid en Procedure Pagina 19 van 22

20 A1.6 - Flowcharts Op de volgende pagina's zijn de patch management flowcharts weergegeven voor patches mbt reguliere changes standaard changes. Bestandsnaam: Patch Management Beleid en Procedure Pagina 20 van 22

21 A Flowchart patches mbt reguliere changes Bestandsnaam: Patch Management Beleid en Procedure Pagina 21 van 22

22 A Flowchart patches mbt standaard changes Bestandsnaam: Patch Management Beleid en Procedure Pagina 22 van 22