Annonsørinnhold fra  
Advertiser company logo

Du patcher alltid for sent - en avgjørende holdning

Del

Å patche kan veldig ofte være for sent. Så hva gjør du med det?

Sårbarheter har eksistert så lenge det har eksistert kode. Men kan de rekke å bli misbrukt før du rekker å patche? Å ja.

Den nye Log4J sårbarheten, CVE-2021-44228, ble annonsert fredag 10. desember, og ble misbrukt allerede 12 timer etter annonseringen. I videoen SANS presenterte mandag 13. desember sier de at et foretak i England ble utsatt for ransomware som følge av denne sårbarheten allerede lørdag 11. desember.

NCSC sier: Det er meldt om observasjoner av utnyttelse så tidlig som 1. desember 2021. Det er derfor et potensial for at trusselaktører kan ha utnyttet sårbarheten på et tidligere tidspunkt enn offentliggjøringen. Virksomheter bør derfor undersøke om berørte applikasjoner har tegn på kompromittering tilbake i tid, i hvert fall til 1. desember.

Zero day vulnerability og patching

En ukjent sårbarhet er som regel ufarlig så lenge ingen kjenner til den. Men så fort «noen» får kjennskap til den, begynner det å bli farlig (ref. informasjonen fra NCSC). Om denne/disse «noen» ikke er produsenten, snakker vi om en 0-dagssårbarhet, som vil gå under radaren for de aller fleste. Den er ikke kjent av produsent eller sikkerhetsleverandører. Det finnes ingen patch, og heller ingen signaturer for gjenkjennelse eller beskyttelse.

Artikkelforfatter Gøran Tømte har bred og lang erfaring fra IT-bransjen, er CISO i Netsecurity og beskriver seg selv som en «Zero Trust soldier, working to change and enhance». Gøran har et brennende hjerte for IT-sikkerhet og mener at alt starter med mindset. Målet er et sikrere Norge. <i>Foto: Thomas B Eckhoff</i>
Artikkelforfatter Gøran Tømte har bred og lang erfaring fra IT-bransjen, er CISO i Netsecurity og beskriver seg selv som en «Zero Trust soldier, working to change and enhance». Gøran har et brennende hjerte for IT-sikkerhet og mener at alt starter med mindset. Målet er et sikrere Norge. Foto: Thomas B Eckhoff

Så fort en sårbarhet blir gjort kjent for en produsent, er det en uskreven regel som gir dem 90 dager på å komme med en fiks. I denne 90-dagers perioden skal melder ikke si noe om dette ut i markedet. Den dagen produsenten melder om sårbarheten til markedet, sammen med en fiks, vil sårbarheten være kjent for allmennheten, inkludert de kriminelle. Og da kan det i en del tilfeller haste med å agere. Det er nå klokka starter. Tiden fra sårbarheten blir kjent til de kriminelle finner måter å misbruke dette på er kritisk. For CVE-2021-44228 tok dette 12 timer. Kanskje enda mindre, som i at den ble misbrukt allerede før dette ble annonsert. Det er funnet spor av misbruk tilbake til 1. desember 2021.

Hvor lenge etter sårbarheten ble gjort kjent patcher du? I dette vinduet har de kriminelle kanskje allerede rukket å gjøre noe. Har du merket det? Du patcher, sårbarheten er borte, men det kan allerede være for sent. Hvordan vet du det, og når vet du det? Har de kanskje allerede etablert en bakdør som de om noen måneder vil misbruke for f.eks. ransomware?

Se her hva Center for Internet Security sier i forbindelse med Log4J sårbarheten og patching:
"It is important to note that simply updating Log4j may not resolve issues if an organization is already compromised. In other words, updating to the newest version of any software will not remove accesses gained by adversaries or additional malicious capabilities dropped in victim environments."

Tenk at du var for sen - alltid

Tenk at du er for sent ute hele tiden, at de kriminelle allerede har misbrukt sårbarheten og er på innsiden. De har etablert fotfeste, men ikke nødvendigvis gjort noen skade enda, eller har de det? Har de startet å utnytte deg for cryptomining, noe du kanskje aldri oppdager? Kanskje de har startet å hente ut informasjon, som del av spionasje, eller forberedelse før en dobbelt utpressingssak. Denne prosessen kan ta uker eller måneder. Vi har sett tilfeller der det kan gå over 6 måneder fra misbruk av sårbarhet, med etablering av bakdør, til ransomware, som endte i en dobbelt utpressingssak. Uten tilstrekkelig logging, overvåking og alarmering, er det vanskelig å være helt sikker. 

Helhetlig sikkerhet

Se NSM grunnprinsipper for IKT-sikkerhet og Zero Trust (Assume Breach) for mer informasjon om dette emnet.

Patching er viktig. Rask patching er noen ganger veldig viktig. Vinduet fra kjennskap —> patching er veldig viktig. Det er viktig å vite hva man har, for å vite hva man skal patche. Å tenke helhetlig sikkerhet er alltid viktig. Mindset er viktig i denne sammenheng. Om man antar at noen allerede er på innsiden, vil man automatisk begynne å tenke annerledes. Hva kan de få tilgang til? Hva har de allerede gjort? Har de beveget seg? Er de ferdig med å misbruke sårbarheten (uavhengig av software sårbarhet eller manglende MFA)

  • Kan de nå andre servere?
  • Er det tilstrekkelig segmentering i datasenteret for god tilgangskontroll mellom DMZ og domenekontroller?
  • Er servere unødvendig tilgjengelig på RDP?
  • Er det MFA for RDP tilgang, også for interne servere? For er de på innsiden, er MFA viktig. Det viser seg stadig vekk.
  • Hvordan er sikkerheten på backupserveren? Har backupserveren internettilgang? Hva trenger den mot internett?
  • Er det etablert offline backup? Kommer de seg på innsiden, og sletter backupen din, er dette et viktig punkt.
  • Er det etablert offline/ekstern logging? Skjer en hendelse, er logger meget sentralt. Det er derfor viktig å sikre at disse er tilgjengelige.
  • Kan de etablere en bakdør mot internett? Hva er tillatt fra serverne mot internett?
  • Hvilke brukere har hvilke rettigheter? Har en vanlig bruker administrator rettigheter?
  • Hva sier loggingen? Har vi en analyseløsning på plass? 

Listen er lang, og lengre enn nevnt. Det viktige er tankesettet rundt trusselbildet, og ha respekt for det. Det kan være en ny sårbarhet, ref Log4J, eller det kan være en fjernaksessløsning uten MFA, ref Østre Toten kommune. Uansett sårbarhet er det liten tvil om at de kriminelle kommer seg på innsiden, og at man på bakgrunn av det må ta høyde for nettopp dette. Gjør man det, vil en sårbarhet som Log4Shell plutselig bli mye mindre alvorlig. Uten dette tankesettet, de nevnte tiltak, og flere, blir det gjerne katt og mus, armer og bein, stress og høy puls.

Hvitelist utgående servertrafikk

Et eksempel på et regelsett som hvitelister trafikk fra en Ubuntu server mot internett. Dette regelsettet ville hindret misbruk i forbindelse med Log4J for denne serveren:

 
 

Tilsvarende regelsett benyttes mellom servere i datasenteret for på den måten å redusere angrepsflaten. Det er opp til oss mennesker.

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

Les flere artikler fra Netsecurity