Det er nå siste uke i Nasjonal sikkerhetsmåned, og vi starter med denne ukens tema, «Patching, hva og hvorfor?»
I denne artikkelen kan du lese om noen av overskriftene som ble snakket om i Dig. lunsj 24. oktober. Se opptak her:
Hva betyr patching?
Patching er et klassisk IT-begrep, som ofte brukes uten at man vet om den som lytter forstår. Ordet “patching”, kan bety “lapping” på norsk, som i bunn og grunn er det patching i IT-miljøet betyr; man lapper noe som trengs å lappe, enten fordi det er gått i stykker, eller at det har hull som bør tettes.
Ett annet begrep som kan brukes på samme måte som “patching”, er “oppdatere”. Dette begrepet er flere av oss kjent med, og har blitt en normal del av hverdagen, når telefonen må oppdateres med jevne mellomrom, TV-en må oppdateres, nye biler må oppdateres, ja til og med hvitevarer kan trenge en oppdatering innimellom.
Helt konkret hva patching betyr, hvis vi skal se bort fra selve navnet, vil det si at man gjør forbedringer på programvare, og da gjerne forbedringer som gjøre programvaren tryggere. Tidligere patchet man ikke ofte, og i noen tilfeller ikke i det hele tatt. Med dagens teknologi, kan man patche programvare mye enklere enn før, og det gjør det mulig for oss å holde tjenestene bedre og sikrere, for ja, en patch betyr ikke nødvendigvis at det skal fikse noe som er feil.
Noen har kanskje hørt begrepet patching i spill sammenheng. At noen nevner at det har kommet en ny patch til spillet, eller at de gleder seg til neste patch. Dette er akkurat det samme. De som har laget spillet, kan forbedre spillet, eller legge til nytt innhold ved å patche. Før var ikke den muligheten der. Da måtte man kjøpe spillet, og hvis noe var feil måtte man fint leve med det, og hvis det kom en ny versjon av spillet, måtte man kjøpe det.
Hvorfor patcher vi?
I korte trekk, kan vi si at patching gjøres for å gjøre en tjeneste bedre og tryggere. Og måten dette gjøres på, og tidspunktene for når det gjøres vil variere etter behovene.
Ved sikkerhetstrusler, patches systemene så fort som mulig. Mens når systemer skal forbedres (nye funksjoner eller retting av feil), vil patchene vanligvis komme i en regelmessig intervall.
Det skal også nevnes at patching i seg selv kan medføre nye sikkerhetshull, så i noen sjeldene tilfeller, må en patch rettes av en ny patch ganske kjapt.
Hvordan administrere vi dette?
I Indigo IKT-samarbeidet, har vi veldig mange forskjellige systemer vi administrerer. Nesten alle disse patches regelmessig, og systemene må vedlikeholdes. Vi gjør dette ved hjelp av noe som kalles “patch managment”. Her er en oppsummering av hva dette gir oss:
- Få oversikt over IT-systemene.
- Sette risikonivå på IT-systemene. Jo mer utsatt for angrep jo høyere prioritet.
- Planlegge oppdateringene for å redusere nedetid.
- Holde seg oppdatert på leverandørenes patch-beskjeder.
- Utføre riktige tiltak ved unntak av patching. Noen ting kan kanskje ikke patches fordi det vil ødelegge systemet. Så her kommer risikoanalysene inn.
- Omstart av enheter ved oppdatering. Systemfiler kan ikke modifiseres før etter omstart av maskinen.
- Testing av systemene. Dette kan for eksempel gjøres ved at det blir lagt ut systemer til en gruppe, eller at man tester i et testmiljø.
- Tilbakerulleringsplan. Noen ganger går ikke en patching etter planen, og man har behov for å gå tilbake til opprinnelig versjon.
- Automatisere åpen kildekode-patching. Denne kan være vrien, men kort fortalt betyr det at patchingen skjer automatisk ved at patchene distribueres via åpne kilder.
Versjonering
I denne artikkelen har det blitt nevnt “versjon” noen ganger. Et system kommer ofte med et versjons-nummer. Et helt nytt system vil ofte bli publisert som f.eks. “Versjon 1.0.0”. For de av dere som bruker smarttelefoner, vil dere nok kjenne til at Apple lanserer en ny versjon av iOS, eller at det kommer en ny versjon av Android.
På denne måten kan man patche systemene og holde oversikt over versjonene, slik at man kan føre historikk over hva som gjøres, og enklere gå tilbake hvis noe ikke fungerer.
Patchene deles ofte opp i kategorier, basert på hvor store de er (hvor mye de endrer i systemet).
- Major: X.0.0 – større endring i funksjon eller større strukturelle endringer i grensesnittet, er ikke bakover-kompatibel. I eksemplet over, med Apple, kan dette f.eks. være iOS 15. I noen tilfeller gir man de store oppdateringene egennavn, slik som Android gjorde tidligere (versjon 8.0.0 av Android het “Oatmeal Cookie”)
- Minor: 0.X.0 – ny funksjonalitet, mindre strukturelle endringer, er bakover-kompatibel.
- Patch som 0.0.X – “bugfix”, små endringer, lapper sikkerhetshull, er også bakover-kompatibel.
EOL
EOL – End of life. Når en leverandør bestemmer seg for å ikke lenger følge opp et system, gis det oftest en EOL-dato. Dette er tidspunktet hvor systemet ikke lenger blir patchet fra leverandøren, og i enkle trekk slutten for livet til systemet. Når dette skjer, vil systemet være sårbart for sikkerhetstrusler, og man må finne en erstatning av systemet. Så lenge leverandøren passer på sitt system, har vi en avtale på dette (mellom Indigo IKT-samarbeidet og leverandør). Når denne avtalen ikke gjelder lenger, og systemet går mot EOL, blir det som å kjøre bil uten forsikring – det kan gå bra en stund, men hvis og når det smeller, sitter man med store tap. Vi kan ikke ha systemer som ikke følges opp i vårt IT-miljø, når dette utgjør en stor sikkerhetstrussel.