Jeg har klippet min hæk tre gange i år. Det plejer jeg egentlig ikke. Jeg plejer at tage en marathon-weekend, hvor jeg klipper hæk i 12 timer og kører på lossepladsen tre gange. Men jeg har en fin udsigt i min baghave til lidt eng, og hvis jeg står på det yderste af mine tæer inde i soveværelset, kan jeg også skimte en sø. Den udsigt forsvinder i den tidlige sommer, hvis jeg ikke klipper min hæk ned, og i år ville jeg gerne beholde udsigten. Det betød, at jeg skulle klippe min hæk tre gange, og det virkede en smule op ad bakke den tredje gang, inden jeg kom i gang. Men da jeg var færdig med at klippe hækken på under en time, hvor min datter havde fulgt mig rundt i haven og samtidig sørget for at samle alt afklip op, tænkte jeg alligevel, at det kan noget, det her med at klippe sin hæk flere gange om året. I IT er der også meget at vinde ved at ‘klippe’ sin patch management op og gøre det struktureret. Patch management er ikke super sexet (Det er okay at gabe lidt nu), men patch management er nødvendigt for at opretholde en sikker infrastruktur. Hvis man gør det struktureret, kan man iøvrigt spare meget tid og mange penge.
Et eksempel på struktureret patch management er Patch Tuesday.
Patch Tuesday er et begreb opfundet af de store amerikanske softwarevirksomheder. Patch Tuesday blev opfundet for at strukturere udrulningen af opdateringer. Tidligere sendte softwareproducenterne opdateringer ud løbende, hvilket betød, at IT-medarbejderne i alle verdens virksomheder kunne stå med pludseligt opstået arbejde alle ugens dage 24/7 for at sikre, at de vigtige sikkerhedsopdateringer kom på deres infrastruktur. For at undgå dette opfandt en gruppe af store amerikanske virksomheder Patch Tuesday. Producenten samler opdateringer i en måned og sender dem i stedet ud i én pakke, én gang om måneden. Ved at vælge en konkret dag på måneden giver det mulighed for at planlægge udrulningen af nye opdateringer samt forberede organisationen på, at der kommer nye opdateringer, som kan sendes ud i et kontrolleret tempo. Hvis vi eksempelvis kigger på Microsoft Windows, giver det mulighed for at starte med enkelte PC’er i IT-afdelingen, inden man sender opdateringen ud til samtlige PC’er i virksomheden. Man kunne også starte i et testmiljø, så man ikke rammer produktionen med de nye opdateringer, før disse er testet af. For mit vedkommende er det måske kun nødvendigt at klippe min hæk én tirsdag i hver af sommermånederne, da det er her, min hæk vokser mest, men med Patch Tuesday (og lignende strategier) bliver det simpelt og forudsigeligt for it-afdelinger at lave løbende planlægning og udførsel og på den måde holde endpoints og infrastruktur sunde og sikre – hele året rundt.
Hvorfor lige tirsdag?
Patch Tuesday. Det lyder super amerikansk, nærmest som Superbowl Sunday, men der er ikke meget fadøl, snacks og bold over Patch Tuesday. Det giver dog super god mening, at det er en tirsdag, da mandag er fri til at følge op på weekendens potentielle udfordringer, inden man bliver ramt af nye udfordringer efter en ny opdatering. Derudover giver tirsdag mest mulig tid frem mod weekenden, hvis der måtte være udfordringer i med nye opdatering.
Et eksempel på en virksomhed, som bruger Patch Tuesday, er Microsoft. Microsoft har valgt den anden tirsdag i måneden, så det samtidig ligger langt fra månedsskiftet, hvor mange virksomheder har frys på ændringer for at undgå udfordringer op til månedsskiftet på grund af regnskab, lønkørsel og lignende.
Hvordan kommer jeg I gang?
Patch management kan virke en smule uoverskueligt, da de fleste virksomheder har mange IT-produkter, men som mine gode kollegaer Thomas Ullerslev og Ole Voldbjerg ofte refererer til i mikrosegmenteringsprojekter, så start med de kritiske produkter eller de mest udsatte produkter. Det kunne eksempelvis være dine perimeter-firewalls og dit datacenter.
Vi skal starte med at sætte os ind i producentens software lifecycle-strategi. Hvis producenten følger Patch Tuesday strategien, så kig på, hvordan du kan indarbejde det i jeres strukturerede arbejde, så det bliver proaktivt.
Ciscos Secure Firewall får planlagte opdateringer to gange om året, og Ciscos IOS-XE-software får fire opdateringer om året, men ikke på en konkret dag. Her skal du indarbejde en proces, som bliver sat i gang, når den nye software er tilgængelig.
Du bør også have en klar proces for, hvordan du håndterer en opdatering, hvis der måtte komme en kritisk opdatering uden for den normale opdateringskalender. Det kan ske, hvis en sårbarhed bliver offentliggjort eller kendt på internettet, og sårbarheden er så kritisk, at producenten ikke mener, det kan vente til det planlagte vindue. Det ser vi desværre oftere og oftere. Ikke fordi koden bliver dårligere hos vores producenter, men ganske enkelt fordi IT bliver mere komplekst, og vores modstandere (hackere, it-kriminelle) bliver bedre og flere.
Hvad giver en struktureret proces os, som virksomhed?
Jeg hørte for nylig om et antal enheder hos en kunde, som ikke havde været softwareopdateret i 9 år (siden de blev sat i drift). Da kunden var langt bagefter med opdateringer, krævede det flere opdateringstrin for at få dem op på det nuværende og sikre niveau. Derfor ville opdateringsprocessen tage 14 dage og kræve flere servicevinduer for at få dem opdateret til nyeste stabile (og sikre) software. Det var energi, tid og penge, som der skulle bruges på hardware, som allerede var end of life og klar til udskiftning. Kunden valgte at opgradere deres hardware i stedet for at opgradere enhederne med softwaren.
Hvis vi i stedet vælger at opgradere proaktivt, når der kommer ny software, så får vi følgende fordele:
- Vi får løbende erfaringer med opdateringsprocessen. Vi skal ikke lede efter opdateringsmanualer og hvor den nye software downloades.
- En klar og aftestet opdateringsplan. Skal vi starte i IT-afdelingen, så vi ikke lægger vores produktionsudstyr ned, hvis opdateringen giver udfordringer?
- Vi kender vores testplaner – Hvad er kritisk at teste? Hvad virker inden opdateringen? Hvad virker efter opdateringen?
- Og ikke mindst sikkerheden…
Der er naturligvis også den primære gevinst: Få lukket sikkerhedshullerne.
Dagen efter Patch Tuesday er også kendt som Exploit Wednesday. For når man slipper en ny opdatering løs, beskriver man også, hvad der er blevet rettet i den nye opdatering. Hvis man ikke får installeret den nye opdatering hurtigt, er der frit slag til at udnytte de nu offentligt kendte sårbarheder, så det er vigtigt at følge med i opdateringerne fra sine producenter. Hvis du ikke selv har mulighed for det, så kan du også bede din driftspartner om at sætte struktur på din patch management.
Så hvis du gerne vil tage styringen og planlægge, hvad der skal stå i din kalender på Exploit Wednesday, så er det værd at kigge på at strukturere sin patch management. For mig og min hæk er det rigtige tal tre klipninger om året – fordelt på for- og sensommer – for at være mest effektiv, men samtidig nyde godt af den fine udsigt hele året. Hvad er det rigtige tal for dig og din patch management-strategi, så du opnår de mål du ønsker?
