19 oktober 2021

Så, du utsetter å patche systemer fordi du skal kvalitetssikre sikkerhetsoppdateringene?

3 min lesetid

19. oktober 2021

Er du en av dem som utsetter å installere oppdateringer fra leverandøren, fordi du frykter nedetid og vil kvalitetssikre oppdateringene?

Det første spørsmålet mitt er da, kan jeg få se QA-skjemaet ditt? For du har vel noe du gjør for å "kvalitetssikre" oppdateringen? Eller er det bare et påskudd, og sannheten er at du utsetter å oppdatere av gammel vane eller mangel på tid?

Om du utsetter fordi du er redd for uønsket nedetid, og derfor vil kvalitetssikre først, uten å gjøre noe aktivt for å teste, er gevinsten ved å utsette allerede her null, og kan faktisk ende opp med å gå i minus ved at risikoen øker med nye sårbarheter som har blitt kjent, og ikke patchet.

Dersom du faktisk utfører en skikkelig testing for hver oppdatering produsenten leverer, med integrasjonstesting, regresjonstesting osv., gratulerer, da er du en av svært få som gjør det. Men det betyr ikke at det er en fornuftig strategi.

Her må vi stille spørsmålet: Hvor ofte skaper en oppdatering fra en produsent produksjonsproblemer? For store seriøse produsenter som Microsoft, Apple, Google og andre, så skjer dette svært sjelden, fordi de utfører omfattende testing før de slipper oppdateringene. En kritisk feil i en sikkerhetsoppdatering som medfører ukontrollert nedetid forekommer kanskje noe slikt som hvert 10. år per produkt for en gitt produsent.

Utnyttelse av nulldagssårbarheter har preget det internasjonale risikobildet det siste året. En nulldagssårbarhet er en sårbarhet som ikke er kjent for leverandøren av programvaren, og som kan utnyttes av en trusselaktør. Koden for å utnytte en nulldagssårbarhet er vanligvis lite kjent før den er avdekket. Leverandøren må da utvikle en sikkerhetsoppdatering før de som visste om nulldagssårbarheten slipper utnyttelseskoden bredt, for å unngå at den utnyttes av alle som har kompetanse til det. En leverandør vil bruke noe tid på å utvikle en sikkerhetsoppgradering for å lukke sårbarheten. Det vil også gå tid fra en sikkerhetsoppgradering er tilgjengelig til brukere av programvaren installerer oppgraderingen. Virksomheter som ikke har rukket å installere sikkerhets- oppdateringer vil dermed fortsatt være sårbare.

NSM: Nasjonalt digitalt risikobilde 2021

 

Har du tenkt på hvilken risiko du utsetter deg for ved å vente?

Si at produsenten slipper oppdateringer som lapper kritiske sårbarheter en gang per kvartal. Du utsetter hver av disse i en uke, for å "kvalitetssikre". I løpet av ti år, vil du da ha 10 år x 4 x 7 dager = 280 sårbare døgn per system som mangler kritiske oppdateringer.


Hvor mange angrep er det per dag?

Ikke så lett å si, men for en ubeskyttet internetteksponert server dreier dette seg fort om noen titalls tusen per døgn, la oss si 50.000 forsøk per døgn. I løpet av 10 år, vil du da utsette hvert sårbare system for 280 x 50.000 = 14.000.000 potensielle hendelser/angrep. Og dette er angrep som det allerede finnes en oppdatering for. De er med andre ord ikke zero-days, men kjente sårbarheter, der kriminelle enkelt kan finne dokumentasjon på hvordan det skal misbrukes på internett. Man kan stort sett laste ned ferdige scripts som krever null kunnskap eller kjøpe det som en tjeneste. Jada, de kriminelle benytter også skytjenester. Og dette er per produkt per eksponerte system, så du må gange opp med antall produkter per enhet og antall sårbare enheter.

Når man begynner å regne på det, skjønner man fort at det å utsette kritiske oppdateringer ikke er en farbar vei. Derfor anbefaler også produsentene at du benytter automatisk oppdatering, så får du heller tåle at systemet potensielt er nede en gang hvert 10 år. Og husk at et angrep ikke bare medfører nedetid, det kan også eksponere deg for datatap, med bøter i millionklassen. Både frekvensen og konsekvensen av risikoen ved å utsette kritiske sikkerhetsoppdateringer er altså mange magnituder større enn frekvensen og konsekvensen på risikoen for å få en "dårlig oppdatering".


Tallene er bare for å illustrere, men de er ikke helt "borte vekk"

Du kan godt bruke andre tall, men risikoen ved å kjøre usikrede systemer er fortsatt dramatisk høye. Om en produsent bare har en kritisk oppdatering per år, og du bare får 10.000 angrep per døgn, så er det fortsatt 10x1x7x10.000 = 700.000 potensielle hendelser. Om en produsent slipper en "dårlig oppdatering" så ofte som en gang per år, så er det fortsatt 700.000:10 i odds. 14.000.000:1 er unektelig dramatisk mye verre enn 700.000:10, men det siste er fortsatt ille.

Konsekvensen av nedetid kan være mindre enn å ikke patche

Sannsynligheten for driftsforstyrrelser ved patching eksisterer, men vi håper denne artikkelen belyser dette på en slik måte at man ser at dette er lite sannsynlig. Vår oppfordring er derfor å ta en intern diskusjon, eller med oss, for å diskutere risiko ved å patche umiddelbart opp mot risiko for nedetid. Om det er en kritisk sårbarhet, bør dette kanskje veie så tungt at du er villig til å ta en bitteliten risiko for å skape driftsproblemer. Noen ganger er uønsket nedetid verdt det for den totale sikkerheten.

I tillegg til gode patcherutiner, er lagvis sikkerhet en god anbefaling. Som et ledd i dette er god endepunktsikkerhet viktig. Å ha et produkt er ikke synonymt med at det er bra. Gjør verifiseringer, gjerne opp mot Mitre Att&ck sine tester. Serverne står gjerne i et datasenter, bak en brannmur, gjerne en Neste Generasjons Brannmur (NGFW). Aktiver SSL dekryptering. Aktiver alle sikkerhetsfunksjoner for preventiv sikkerhet, inkludert beskyttelse mot misbruk av sårbarheter. Dette er ting vi i Data Equipment daglig hjelper våre kunder med. Ta kontakt for en risikovurdering og evaluering av dine verdier.

Øystein Kaldhol

Skrevet av Øystein Kaldhol

Senior Network Security Engineer