Denne artikkelen er basert på et foredrag i samarbeid med pcsupport.no.
IRT rykker ut på hendelser, både remote og on-site. Av og til er det nødvendig med utrykning, andre ganger reiser vi ut til kunden for å bidra til å beholde roen rundt situasjonen. Mange ledere er ikke forberedt på hva som treffer dem, og vi kommer for å hjelpe ledelsen og bedriften, men også for å roe ned stemningen, som ofte kan være preget av redsel, usikkerhet og frykt. Vi kommer med en forsikring om at hjelpen er her, vi har erfaring og kan gi de gode rådene.
Utover å ha de nødvendige sertifiseringene for å kunne bistå, er vi opptatt av at dette er et samarbeid. Det er dere som kjenner systemene deres best, deres teknikere som har kontroll på hva som skjer i systemene. Dette kan ikke vi ha innsikt i for alle kundene våre, så her kommer de beste resultatene når vi samarbeider.
Vi er generelt opptatt av å jobbe som et team, og holder møter også under en hendelse, for å hente ut mest mulig nyttig informasjon fra teamet. Vi har hele verdikjeden innad på drift, og har alltid noen å støtte oss på.
Et vanlig hendelsesforløp er at vårt NSOC, Netsecurity Security Operations Centre, mottar et anrop fra en kunde, der de melder fra om situasjonen som har oppstått. De som sitter på NSOC gjør så en vurdering på om situasjonen skal gå videre til IRT. Selv om vi skal passe oss for å sammenligne oss selv med brannmenn for ofte, så er det jo faktisk det vi driver med her: brannslukking. Og dette er det første steget.
Arbeidsmetodikken vår kalles PICERL og står for Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned. Dette har mange fellestrekk med kriseledelse.
Preparation er der dere er i dag, fasen før det smeller. Det er ikke alt man kan være forberedt på, men å ha en viss grunnberedskap vil i mange tilfeller være til stor hjelp når det gjelder å stoppe angrep og begrense skadeomfang.
I denne fasen er det mulig å kartlegge hva man har og hvordan man kan bruke det. Har dere testet om beredskapen fungerer i praksis? Fungerer backupen? Flere kunder sier til oss at de har backup, de har det på tape, mens når vi da spør når de sist testet det, viser det seg at de kanskje aldri har testet om backupen fungerer. Vi skulle jo helst hatt tilgang på alle dataene så fort vi ankommer kunden, men med tape kan det ta ei uke å få tilgang på alle dataene. En kort huskeliste er å ha oversikt over ansatte, utstyr, kontaktinformasjon og hvem som har tilganger hvor i systemene, og hvilke backupkontorer som finnes, altså kontoer som kan komme seg inn i systemene deres dersom alt går ned for telling.
Vi starter alltid en identifiseringsfase med å se på hva som har skjedd, hva er omfanget, hvilke logger har vi, og hvor finner vi loggene? Ved en ransomware-hendelse kan loggene være krypterte. Hva gjør vi da? Har vi andre løsninger?
Det er utrolig viktig å identifisere hva som har skjedd. Av og til kan man være heldig og finne spor som kan forklare nøyaktig hva som har skjedd, andre ganger må man jobbe ut fra en hypotese om hva som har skjedd.
Omfanget i de casene vi blir kalt inn på er som regel av viktige filer krypteres, e-post er på avveie, og vi må sette i gang neste fase.
Mellomfasen, med containment og eradication, kaller vi ofte operasjon stopp blødningen. Det betyr at vi stenger nede systemer eller deler av systemer på kort eller lang sikt. Hva er kritisk for at bedriften kan leve videre? Her ligger mye av verdien i å være forberedt, nemlig i å ha verdivurderingene klare. Her er vi ute etter en prioritert liste: Hva er det som MÅ på beina først? De aller fleste angrepene vi ser, er jo fredag klokken 16, når du er klar for å gå hjem og ta helg, eventuelt sent torsdag kveld slik at du starter fredagen din med å oppdage angrepet.
Vi jobber for å sikre bevisene, gjøre nødvendige endringer, og kanskje må du koble rundt på nettet ditt slik at du kan skille ut skadede eller sårede systemer for å kunne få ting opp og gå igjen midlertidig. Kanskje innser du at det vil ta en hel uke å få alt opp og gå igjen. Dette er helt umulig å si noe om på forhånd, og presset om å komme seg på beina igjen er stort. Målet vårt er alltid å få kundens systemer opp og gå igjen så fort som mulig på en trygg og sikker måte, Sitter det noen i andre enden og styrer angrepet så kan de plutselig snu hele angrepsmønsteret sitt mens vi er inne og jobber for å reparere. Derfor er det helt avgjørende at man i containment fasen er forberedt på for eksempel å dra ut hele internettet for hele bedriften. Det kan virke som drastiske endringer, men det er da du får byttet passord, fjernet unødvendige administratortilganger, endre brannmuren og lignende. Alt du kan gjøre for å stenge mulighetsrommet for en angriper, skal skje i denne fasen. Akkurat det ser vi fryktelig mye av, at alle ansatte er administratorer på alle PC-er, fordi det er enklest. Ja, det er enkelt, men det gjør det også enkelt for angripere.
Den neste fasen er den jeg liker best, nemlig når vi skal prøve å sparke ut inntrengerne. Ta ned og ut systemer du ikke er sikker på, fjern malware og artifakter, og forbedre sikkerhetsmekanismene.
Vi nærmer oss sluttfasen, recovery, vi ser lyset, men det er veldig viktig å være klar over at det ikke er over før det er over her. Businesseiere må verifisere at ting er oppe igjen. Det betyr kanskje at noen må ta en telefon og sjekke noen systemer, selv om det er søndag. Er kunden rigget for det? Vi ser at det ikke er alle som er klare for å svare på hastetelefoner på en søndag. Vi anbefaler at det er gjort baseline av systemene, slik at kunden vet hvordan det skal se ut til vanlig.
I en recoveryfase, dersom man oppdager noe nytt, kan fort føre deg noen skritt tilbake, helt tilbake til identifikasjonsfasen hvis du finner nye ting. I recoveryfasen, hvis du holder på helt til du sier at nå har vi ikke tid eller ressurser til å holde på mer, så leter du etter nye kompromitteringer. Du håper at du har funnet veien inn, og kanskje har du det.
Så har det gått noen uker, kanskje noen dager, du er relativt sikker, systemene er i produksjon, da er det viktig å se på hva man har lært av hendelsen. Da er vi over i Lessons Learned, og skal se på hvilke prosesser som fungerte og hvilke som bør forbedres. Her er vi ikke ute etter å plassere skyld eller peke finger, her er det prosessene som er viktige: Hva fungerte, hva fungerte ikke, hva kan vi forbedre, hva kan vi forbedre teknologisk, vi kan få tilbakemelding som incident responders: hva synes dere som kunde om håndteringen av hendelsen? Dette er ting vi snakker med kunden om i et møte, som vi prøver å gjennomføre så snart som mulig etter at balansen er gjenopprettet. Her er det viktig å dokumentere grundig hva som har skjedd. Vi i Incident Response skriver en rapport om hendelsen, som kunden kan kommentere og komme med innspill til.