Jeg har klippet hekken min tre ganger i år. Det er ikke noe jeg pleier å gjøre. Vanligvis har jeg en maratonhelg hvor jeg klipper hekken i 12 timer og kjører tre turer til gjenvinningsstasjonen.
Men jeg har en fin utsikt fra hagen min som går over en eng, og hvis jeg står på tærne i soverommet, kan jeg til og med få et glimt av en innsjø. Den utsikten forsvinner tidlig på sommeren hvis jeg ikke klipper hekken ned, og i år ønsket jeg å beholde den. Det betydde at jeg måtte klippe hekken tre ganger, og det føltes litt tungt den tredje gangen før jeg begynte. Men etter at jeg var ferdig med jobben på under en time, med datteren min som fulgte meg rundt i hagen og plukket opp alle avklippene, tenkte jeg for meg selv, det er virkelig noe med å klippe hekken flere ganger i året.
I IT er det også mye å vinne på å «trimme» patchhåndteringen din og gjøre det på en strukturert måte. Patch management er ikke akkurat spennende (det er greit om du gjesper litt nå), men det er essensielt for å opprettholde en sikker infrastruktur. Og hvis det gjøres på en organisert måte, kan det spare deg for mye tid og penger.
Et eksempel på strukturert patchhåndtering er Patch Tuesday
Patch Tuesday er et konsept utviklet av store amerikanske programvareselskaper for å strukturere utrullingen av oppdateringer. Tidligere slapp programvareprodusenter oppdateringer kontinuerlig, noe som betydde at IT-ansatte over hele verden kunne møte uventet arbeid når som helst, 24/7, for å sikre at kritiske sikkerhetsoppdateringer ble brukt på infrastrukturen deres. For å forhindre dette introduserte en gruppe store amerikanske selskaper Patch Tuesday. Produsenten samler oppdateringer gjennom måneden og slipper dem i en samlet pakke én gang i måneden.
Ved å sette av en spesifikk dag i måneden kan IT-team planlegge utrullingen av nye oppdateringer og forberede organisasjonen på kommende endringer på en kontrollert måte. For eksempel, med Microsoft Windows, gjør denne tilnærmingen at du kan begynne med å oppdatere noen få PC-er i IT-avdelingen før du ruller ut oppdateringer over hele selskapet. Du kan også starte i et testmiljø og sikre at de nye oppdateringene bare påvirker produksjonen etter grundig testing.
Jeg trenger kanskje bare å klippe hekken én tirsdag i hver av sommermånedene, for det er da den vokser mest. Men med Patch Tuesday (og lignende strategier) blir det enkelt og forutsigbart for IT-avdelinger å planlegge og gjennomføre jevnlige oppdateringer, og holde endepunkter og infrastruktur sunne og sikre gjennom hele året.
Hvorfor tirsdag?
Patch Tuesday. Det høres veldig amerikansk ut, nesten som Super Bowl Sunday, men det er ikke mye øl, snacks eller fotball involvert med Patch Tuesday. Det gir imidlertid mye mening at det er på en tirsdag. Mandag er fri til å ta igjen eventuelle problemer fra helgen før man tar fatt på nye utfordringer fra en oppdatering. Dessuten gir tirsdag maksimalt med tid før helgen til å håndtere eventuelle problemer som kan oppstå fra oppdateringene.
Et eksempel på et selskap som følger Patch Tuesday er Microsoft. De har valgt den andre tirsdagen i måneden, strategisk plassert et stykke unna slutten av måneden. Mange selskaper innfører en endringsfrys rundt månedsslutt for å forhindre problemer knyttet til regnskap, lønnskjøring og andre lignende prosesser.
Hvordan kommer jeg i gang?
Patch management kan virke overveldende, spesielt siden de fleste selskaper bruker mange forskjellige IT-produkter. Men som mine kolleger som jobber med mikrosegmenteringsprosjekter ofte nevner, start med de mest kritiske eller eksponerte produktene dine. Eksempler på dette kan være dine perimeter brannmurer eller datasenteret ditt.
Start med å forstå programvarelivssyklusstrategien til leverandørene du bruker. Hvis leverandøren følger en Patch Tuesday-strategi, vurder hvordan du kan innlemme det i dine strukturerte prosesser for å gjøre det mer proaktivt.
For eksempel mottar Cisco’s Secure Firewall planlagte oppdateringer to ganger i året, mens Cisco’s IOS-XE-programvare får fire oppdateringer årlig, men ikke på en spesifikk dag. I disse tilfellene må du implementere en prosess som settes i gang når ny programvare blir tilgjengelig.
Du bør også ha en klar prosess for håndtering av kritiske oppdateringer utenfor den vanlige oppdateringsplanen. Dette kan skje når en sårbarhet blir offentlig kjent eller blir kjent på nettet, og problemet er så alvorlig at leverandøren bestemmer at det ikke kan vente til det planlagte oppdateringsvinduet. Dessverre ser vi dette skje oftere—ikke fordi koden blir dårligere, men fordi IT blir mer komplekst, og våre motstandere (hackere, cyberkriminelle) blir dyktigere og flere.
Hva gir en strukturert prosess oss som selskap?
Jeg hørte nylig om flere enheter hos en kunde som ikke hadde blitt oppdatert på 9 år (siden de ble satt i drift). Fordi kunden var så langt bak på oppdateringer, krevde det flere trinn for å få dem opp på dagens sikre nivå. Dette betydde at oppdateringsprosessen ville ta 14 dager og kreve flere vedlikeholdsvinduer for å bringe alt opp til den nyeste stabile (og sikre) programvareversjonen. Det var en betydelig investering av tid, innsats og penger på maskinvare som allerede var på slutten av sin livssyklus og klar for utskiftning. Kunden valgte til slutt å oppgradere maskinvaren sin i stedet for å oppdatere enhetene.
Hvis vi velger å oppdatere proaktivt når ny programvare blir utgitt, får vi flere fordeler:
- Vi får kontinuerlig erfaring med oppdateringsprosessen, og eliminerer behovet for å lete etter manualer eller plasseringen av nye programnedlastinger.
- En klar og testet plan for oppdatering. Kanskje vi bør starte med IT-avdelingen for å unngå forstyrrelser i produksjonsutstyr hvis problemer oppstår.
- Kjennskap til testplanene våre—hva som er kritisk å teste, hva som fungerer før oppdateringen, og hva som fungerer etterpå.
- Og viktigst av alt, forbedret sikkerhet.
Exploit Wednesday
Selvfølgelig er den primære fordelen å tette sikkerhetshull. Dagen etter Patch Tuesday kalles ofte Exploit Wednesday. Når en ny oppdatering blir utgitt, inkluderer den vanligvis informasjon om sårbarhetene som har blitt adressert. Hvis oppdateringen ikke blir anvendt raskt, kan disse nå offentlig kjente sårbarhetene utnyttes, noe som gjør det avgjørende å holde seg oppdatert på oppdateringer fra leverandørene dine. Hvis du ikke kan håndtere dette internt, kan du be tjenesteleverandøren din om hjelp til å strukturere din patch management.
Så hvis du vil ta kontroll og planlegge hva som står på kalenderen for Exploit Wednesday, er det verdt å vurdere en strukturert tilnærming til patch management. For meg og hekken min, holder tre klipp i året—delt mellom tidlig og sent på sommeren—prosessen effektiv, mens jeg kan nyte utsikten året rundt. Hva er riktig antall for deg og din patch management-strategi for å nå dine mål?