Løsepengeangrep (del 3) - Under Angrep!

Hva bør virksomheten gjøre dersom den angripes? Hvordan oppdage løsepengeangrepet raskest mulig? Hva bør virksomheten foreta seg når sikkerhetshendelsen er oppdaget? Hvordan forsvare seg og minimere skader under og etter angrepet? Og hva kan man lære av angrepet i etterkant?

Del 3 av 3 i vår serie om løsepengeangrep.
Les også del 1 og del 2.
Artikkelforfattere er Elin Tøndel, Guro Hotvedt, Lasse Eriksen

Tredje og siste del av denne artikkelserien om løsepengeangrep tar for seg håndteringen av et angrep og tiden etter angrepet. Selv om virksomheten har gjennomført tester og forberedt seg godt, har gode rutiner og en god beredskapsplan, vil virksomheten aldri være helt trygg for digitale angrep. Det er derfor viktig å vite hva man bør gjøre hvis angrepet skulle inntreffe.

I denne artikkelen ser vi på fasene oppdage og rapportere (identify, detect & report), vurdere og avgjøre (assessment & decision), respondere (responses) og evaluere (lessons learnt) i ISO 27035 sin modell for hendelseshåndtering. Illustrasjonen er hentet fra Medium.

Fase 2: Oppdage og rapportere

Har man etablert gode rutiner for hvordan oppdage og rapportere unormal aktivitet og mistenkelige handlinger, og disse rutinene blir fulgt, kan man allerede her oppdage, redusere og, i noen tilfeller, eliminere et løsepengeangrep. For å oppdage mulige løsepengeangrep kan sikkerhetsovervåkning benyttes, enten ved å ha det innad egen virksomhet eller leie inn en tredjepart til å betjene denne tjenesten.

Sikkerhetsovervåkning av systemer er en tjeneste som har blitt mer og mer vanlig for å detektere unormal aktivitet og uautoriserte handlinger, og kan bidra til at virksomheten får utført tiltak som begrenser omfanget av et angrep eller stanser angrepet helt. Dette kan være spesielt viktig under et løsepengeangrep da det gjelder å oppdage angrepet før virksomhetens systemer blir kryptert og dermed blir vanskelige å benytte.

To systemer som kan benyttes i dette sikkerhetsovervåkningsarbeidet er SIEM og EDR/xDR som ble introdusert i artikkel to av denne artikkelserien.

Security Information Event Management (SIEM)

Virksomheten har gjerne ti-talls, og ofte flere, systemer som benyttes i daglig drift. Dette inkluderer blant annet e-post, web-, fil- og applikasjonservere. Ikke bare er det mange systemer å administrere og operere, men antall loggoppføringer for enkelte systemer gjør det uoverkommelig for mennesker å håndtere.

For å effektivisere og forenkle kan alle disse loggene sendes til en SIEM for sanntidssammenstilling og -analyse. SIEM vil avdekke uønskede hendelser, og operatører kan aksjonere og / eller rapportere på disse. Uønskede hendelser i forbindelse med et løsepengeangrep kan eksempelvis være en administratorpålogging fra en ukjent lokasjon eller data som blir hentet ut av systemer det vanligvis ikke hentes ut fra.

En SIEM-løsning mottar eller henter inn loggdata og metadata om hendelser fra andre systemer, kalt loggkilder. Typiske loggkilder er brannmurer og annet nettverkssikkerhetsprogramvare, antivirusløsninger og servere som Windows-, web-, applikasjon- og databaseservere. Videre kan kildene være eksterne sikkerhetstjenester som eksempelvis Microsoft Defender ATP, AWS Security Hub og Cisco Umbrella. Ideelt burde alle enheter og tjenester i virksomhetens infrastruktur være loggkilder, men det er i de fleste tilfeller ikke praktisk eller økonomisk mulig.

De fleste SIEM-løsninger er regel- eller betingelsesbasert med bruk av ArtificiaI Intelligence (AI) og maskinlæring i varierende grad. Ved en sikkerhetshendelse vil en SIEM-løsning bruke reglene i betingelsene for å bidra til å minimere angrepet. Reglene kan være svært enkle, som for eksempel "Hvis nettverkstrafikk fra IP x til IP y, utløs varsel", eller svært komplekse med mange betingelser. Dette kan innebære nettverkstrafikk, brukeres adferdsmønster, pålogginger eller påloggingsfeil, forekomst av ord i loggdata, hendelser på web, applikasjon, database eller filservere.

Løsepengeangrep innebærer som regel at filer blir kryptert. Dette kan oppdages ut ifra loggdata fra filservere. Sammenstilles dette med andre hendelser, eksempelvis datatrafikk med en mistenkt Command & Control (C2) server, uvanlige pålogginger og lignende, kan SIEM utløse varsler som incident, offense, alert eller alarm. Ønsker man dermed å benytte SIEM for å oppdage et eventuelt løsepengeangrep bør den inneholde slike regler.

Endpoint Detection and Response/ Extended Detection and Response (EDR/xDR)

Systemet EDR/xDR komplementerer SIEM, men står også på egne ben. EDR/xDR samler data fra endepunkter som datamaskiner og servere. Videre analyserer og behandler den disse i sanntid, eller nær sanntid, og agerer automatisk ut ifra dette. For et løsepengeangrep vil dette si at den agerer på hendelser som kan være i forløpet til en distribuert skadevare, og vil dermed automatisk gjøre handlinger for å hindre at et vellykket løsepengeangrep finner sted. EDR/xDR blir dermed ikke bare brukt i oppdagelses- og rapporteringsfasen, men er også relevant for fase tre og fire av ISO 27035 standarden, der virksomheten vurderer hendelsene og responderer på dem.

Videre er xDR gjerne integrert med antivirusprogramvare slik at den har informasjon til å oppdage og reagere på viruskode man kjenner fra tidligere. Kjent viruskode knyttet til løsepengeangrep kan dermed raskt bli oppdaget. I en slik sammenheng er det verdt å nevne at xDR sender loggdata til SIEM hvis virksomhetene benytter seg av begge systemene. På den måten vil man få en enda bedre sikkerhetsovervåkning av virksomhetens systemer ved benyttelse av begge systemene.

Fase 3: Vurdere og avgjøre

Vurderinger og avgjørelser knyttet til alvorlighetsgraden og potensialet til oppdagede hendelser må håndteres effektivt, hendelsene må prioriteres riktig, og nødvendige ressurser må involveres. ISO 27035 skiller mellom å klassifisere oppdagede aktiviteter som «security events» og «security incidents». Et «security event» blir beskrevet som et mulig brudd på informasjonssikkerhet eller feil i en kontroll. En «security incident» er en hendelse som kan skade verdier og kompromittere deler av, eller hele, virksomheten. Det er derfor viktig å klassifisere aktiviteten riktig.

«Security incidents» skader virksomheten og bør få høyest prioritet. Feilklassifisering av aktivitet vil sannsynliggjøre at et løsepengeangrep får utvikle seg og kommer ut av kontroll. Vi anbefaler at man setter kriterier for klassifisering på forhånd, slik at det går raskere å vurdere og rangere hendelsene riktig.

En hendelse som eksempelvis bør få høy prioritet er dersom en ukjent programvare har blitt lastet ned på en klient, da dette kan være et forløp til et løsepengeangrep. Å klassifisere og prioritere korrekt vil være med på å redusere skadeomfanget og i noen tilfeller stanse et løsepengeangrep. Klassifiseringen bør også samkjøres med eksempelvis regelsett i SIEM-tjenesten slik at hendelser som detekteres her kan vurderes og responderes på.

I xDR-systemet håndteres klassifiseringen av aktivitetene uten at brukeren involveres eller alarmer varsles. xDR -systemet gjenkjenner unormal adferd (anomaly), prosesser som starter eller stopper andre prosesser, samt hva disse prosessene faktisk gjør. Slik kan xDR fastslå om det er et angrep og automatisk forhindre det. Dette vil være gunstig dersom xDR oppdager aktiviteter som kunne vært et forløp til et løsepengeangrep.

De fleste xDR-løsninger kan sammenstille hendelser som skjer i dag. Det kan også være hendelser som formelt sett ikke må ha sammenheng med dagens situasjon, og som daterer langt tilbake i tid. Slik kan man fastslå om det faktisk er et angrep og hva som er rot-årsaken (eksempelvis en datapakke sendt til en server for dager eller uker siden som isolert sett virket uviktig eller ufarlig der og da). Det at dette systemet har evnen til å koble hendelser som ikke nødvendigvis skjer samtidig er særlig relevant for et løsepengeangrep. Her er det mange ledd i prosessen med å kryptere data og det vil være nødvendig å kunne sammenstille hendelser over et lengre tidsrom.

Vanligvis må angripere igjennom prosesser som å få tilgang til brukerkontoer, hente ut data, eskalere rettigheter og få tilgang til sentrale filservere. Det å kunne se hendelser i sammenheng vil være med på å avdekke et eventuelt løsepengeangrep. Det kan forekomme falske positiver i systemet, men disse kan som regel rettes opp i etterkant. Angrep kan videre stoppes ved at prosesser stoppes, filer settes i karantene eller at maskiner isoleres i nettverket.

Med xDR får virksomheten også hjelp til å respondere på aktivitetene, og tjenesten kan inngå i fase fire av ISO 27035 – respondere. For SIEM og andre mer manuelle overvåkningssystemer vil man gå inn i en mer aktiv fase der virksomheten selv må ta valg for hvordan de vil respondere på ulike aktiviteter som kan se ut som aktiviteter i et løsepengeangrep.

Fase 4: Respondere

Etter å ha kategorisert hendelser som «security incidents» er det viktig å respondere så fort som mulig. Virksomheten må da utføre aktivitetene og prosessene som er beskrevet i beredskapsplanen dersom hendelsene er vurdert til å være et mulig løsepengeangrep.Prosesser knyttet til varsling og informering bør iverksettes, samt tekniske tiltak.

I første artikkel anbefalte vi å planlegge en alternativ kommunikasjonskanal i tilfelle løsepengeangrep, og denne bør nå tas i bruk. Når det kommer til hvem som bør varsles og informeres bør dette allerede være satt i beredskapsplanen. Noen generelle anbefalinger vil vi likevel komme med. Det kan være vanskelig å vite om virksomheten har blitt utsatt et løsepengeangrep (eller et angrep generelt), men ved mistanke om et angrep vil vi anbefale at en krisestab settes. Det bør også informeres til alle berørte internt og ekstern, i tråd med planlagte rutiner, regler og lovverk. I noen tilfeller skal angrepet også meldes til politi og/eller myndigheter. Hvis kundedata er berørt bør disse varsles. Til slutt bør man også vurdere om man ønsker å være åpen i media om hendelsen.

Angående tekniske tiltak som skal iverksettes hvis man er rammet av et løsepengeangrep bør dette også være satt i beredskapsplanen og følges i responderingsfasen. Eksempler på tiltak som kan være gunstige i forbindelse med et løsepengeangrep er å koble fra og isolere datamaskiner eller nettverk som er mistenkt infisert. Videre anbefaler vi å bytte passord på alle kontoer på servere og tjenester som er kompromittert.

Når det gjelder gjenoppretting av sikkerhetskopier, anbefaler vi å bruke en sikkerhetskopi man vet er sikker og ikke infisert. Det er viktig å være oppmerksom på at de siste sikkerhetskopiene kan være infisert, så rutinene rundt gjenoppretting bør ta hensyn til dette. Har man en god sikkerhetskopi, samt gode rutiner, kan det redusere nedetid, kostnader og tap av data betraktelig. Dette vil dermed være et av de aller viktigste tiltakene å ha forberedt og ta i bruk i denne fasen.

I et løsepengeangrep vil det være mye å ta inn over seg, og selv om man har planer for hvordan man skal håndtere dette, kan det være lurt å benytte seg av en Incident Response (IR) tjeneste fra en tredjepart. Da vil virksomheten hente bistand for oppfølging av egne planer og rutiner, samt alt det som det ikke er planlagt for.

Under selve angrepet vil IR være sentral i arbeidet med å stoppe angrepet, begrense skadeomfang, innsamling av bevis og annen rådgivning/assistanse underveis. En annen sentral rolle for IR er å gjenopprette «normaltilstand», tilstanden før et angrep. Dette inkluderer bistand i forbindelse med gjenoppretting av data fra sikkerhetskopier og gjenoppbygging av systemer, inkludert anskaffelse av utstyr og programvare. Siden sikkerhetskopier og gjenoppretting er svært sentrale elementer ved et løsepengeangrep, kan IR være en god hjelp til å respondere på dette. Videre er det helt sentralt for IR å dokumentere og fremskaffe bevis for en mulig rettslig prosess eller andre formål.

Gjenoppretting til normaltilstand

Etter et angrep / hendelse har funnet sted og man har gjenopprettet normaltilstand, er tjenestene SIEM og EDR/xDR fremdeles aktuelle. Disse tjenestene benyttes for å vurdere om sårbarheter fremdeles er til stede eller om endringer har introdusert nye, samt analysere datatrafikk og andre logger for å se om angriper fremdeles kan være inne i virksomhetens infrastruktur. Logger fra SIEM, som er lagret utenfor kilden på godt sikrede systemer, kan brukes av IR som bevis og dokumentasjon. xDR forenkler etterforskningen, og tilbyr data til IR, som også er sikkert lagret utenfor enheter som er angrepet.

Bør virksomheten betale?

Et løsepengeangrep vil hemme en virksomhets drift i stor grad, og spørsmålet om virksomheten skal betale løsepengene for å komme raskt opp igjen, og eventuelt unngå publiserte data hvis det er et dobbelt utpressingsangrep, vil dukke opp. NSMs anbefaling er å ikke betale løsepenger, men det er samtidig forståelse for at dette er eneste utvei i enkelte tilfeller.

Det må være opp til virksomheten å ta denne vanskelige beslutningen, men det er viktig at en grundig analyse av angrepet, konsekvensene og mulige alternativer er gjennomført, gjerne sammen med en uavhengig tredjepart, før virksomheten konkluderer.

De siste årene har det også kommet et tilbud om forsikring mot løsepengeangrep fra ulike tilbydere. Dette kan for mange virke som en god løsning på utfordringen med slike angrep. Vi vil kort presisere at en forsikring ikke alltid kun vil ha positive konsekvenser, da trusselaktører mer målrettet kan angripe virksomheter de vet har forsikringen på plass. Det er da større muligheter for aktørene å få utbetalt løsepengene sine, når en forsikring vil dekke slike summer.

Fase 5: Evaluere

Når hendelsen er under kontroll og man er tilbake i normal drift er det viktig å evaluere for å lære, endre, og forbedre.

Hva skjedde? Hvorfor skjedde det? Hvilke inngangsporter ble benyttet til å komme på innsiden av systemene våre? Hvordan har vi håndtert det? Var beredskapsplanen vår god nok? Hva kan vi gjøre bedre neste gang?

Etter en hendelse som et løsepengeangrep ender man ofte opp med en rekke forbedringsmuligheter og tiltak. Det kan dermed være behov for å oppdatere eller gjennomgå nye risikovurderinger og sikkerhetsrutiner. Det kan også være behov for å endre noen prosesser og planer relatert til hendelseshåndtering (planlegge og forberede) eller teknologiske, fysiske eller menneskelige tiltak som vil bedre deteksjon av hendelser eller bevisstgjøring av brukere.

I mange tilfeller konkluderes det med at alle sikkerhetsrutinene var på plass, men at kunnskap om hvordan de skulle tolkes og benyttes var mangelfull blant de som skulle følge dem. Dette kan indikere at virksomheten bør øve mer på slike situasjoner. Alle erfaringer, både gode og dårlige, vil bidra til å forbedre prosedyrer og rutiner i forbindelse med hendelser, og en god evalueringsprosess vil derfor styrke virksomheten i fremtiden.

Det viktigste er å være bevisst og gjøre noe

Arbeidet med å beskytte seg mot løsepengeangrep er en kontinuerlig prosess, og etter et angrep må man jobbe for å bli enda bedre forberedt og sikret mot nye angrep. Gjennom denne artikkelserien ønsker vi å formidle hvor viktig det er å ha gode prosesser for sikkerhetsstyring, ha et bevisst forhold til virksomhetens verdier og hvordan en sikrer disse gjennom tekniske barrierer, samt ha beredskapsplaner å følge dersom man skulle bli rammet.

Løsepengeangrep er under stadig utvikling, og virksomheten kan ikke planlegge for alt. Men, ved å teste ut og oppdatere virksomhetens planer for håndtering av hendelser jevnlig vil virksomheten kunne tilpasse planen til situasjons- og risikobildet. God oversikt bidrar til trygghet. De ansattes oppmerksomhet og bevissthet over egen rolle i sikringen av virksomheten er essensiell, og kontinuerlig opplæring og testing av ansatte, hører alle hjemme i en god sikkerhetsorganisasjon.

Til syvende og sist må virksomheten ha et bevisst forhold til sikringen av data og verdier, og foreta seg noe.

Ved å vektlegge de områdene vi har plukket ut og beskrevet i vår artikkelserie vil i hvert fall virksomheten være bedre rustet til å beskytte seg mot løsepengeangrep og andre cyberangrep i tiden fremover.