Vi tar alle en rekke valg gjennom dagen. Før vi bestemmer oss, gjør vi som regel en analyse av informasjonen vi har tilgjengelig. Se for deg at du skal krysse en vei. Fra der du står, ser du trafikken og risikobildet fra én synsvinkel.

Men så står det en buss til høyre for gangfeltet som gjør at du ikke ser trafikken fra den kjøreretningen. Du har med andre ord begrenset med informasjon til å klare å ta en god beslutning rundt trafikkbildet. For å få fullstendig oversikt over situasjonen, er du nødt til å flytte på deg.

Det samme gjelder når du skal sette opp en sikkerhetsløsning. Målet er å redusere risiko. Sikkerhetsløsningen vil bli implementert slik du “tolker trafikkbildet”, det vil si dine egne eller andres erfaringer. Derfor er det viktig å vite at denne situasjonsforståelsen ofte er begrenset eller bygget på et bestemt miljø - uten at alle synsvinkler nødvendigvis er hensyntatt.

Hvordan analysere en sikkerhetshendelse

Når du skal analysere en sikkerhetshendelse, er det naturlig å begynne med å danne et bilde av hendelsen, for deretter å lage antagelser basert på bildet du har skapt. Formulerer du antagelsen for raskt, vil du ofte – uten å tenke over det – se etter informasjon som støtter antagelsen.

Det er menneskelig å ta valg basert på begrenset informasjon - så hva gjør vi da?

Vi alle har predisposisjoner, synspunkter og antagelser basert på erfaringen vi har bygd opp. Og vi må erkjenne at vi ikke vet alt hver gang. La meg illustrere:

Se for deg at du får beskjed om å lete etter en katt i et mørkt rom. Du får deretter vite at katten er helt sort. Du skal altså lete etter en sort katt i ett sort rom. Men det du ikke er klar over, er at det ikke finnes noen katt.

Et kjent ordtak sier at “det er som å lete etter nåla i høystakken”. Å finne nåla er kanskje ikke umulig, men det er veldig vanskelig. Dette er basert på en tanke om at det finnes en nål. Og selv om det finnes en nål, er det ikke alltid vi klarer å finne den.

Poenget mitt er at når vi kommer fram til en konklusjon, er det viktig å få fram på hvilket grunnlag du har konkludert. Det vil si at vi må referere til underbyggende data og datakilder vi har brukt for å komme til konklusjonen. En konklusjon bør også redegjøre for hvilke andre synsvinkler du har tatt i betraktning – og eventuelt utelukket – og synliggjøre andre mulige teorier. Da utfører du en “stabil konklusjon” som skaper tillit.

Hva kan få oss til å miste evnen til å tenke kritisk når vi analyserer sikkerhetshendelser?

Det er stadig vanligere å bruke automasjonsløsninger for analyse av sikkerhetshendelser. Det betyr at hendelser blir analysert automatisk. I veldig mange tilfeller vil disse løsningene klare å fange opp hendelser. Utfordringer er bare – på samme måte som våre analyser av trafikkbilder – at automasjonsløsningen er laget med predisposisjoner for hvordan hendelser skal analyseres. Dette kan føre til en dårlig eller feil analyse.

Slik bør det gjøres: Metodisk sikkerhetsanalyse

En sikkerhetsanalytiker i et sikkerhetsoperasjonssenter (SOC) får en strøm med alarmer hele tiden. Det er ikke mulig eller fornuftig å analysere alle alarmene, det er derfor hensiktmessig å bruke automasjon til å fjerne alarmer som ikke medfører risiko.

Når det gjelder de andre alarmene, skal disse analyseres av en analytiker. Det bør da brukes en metodisk prosess som er lik for hver analytiker. Dette for å sikre at grunnlaget er likt, og påliteligheten til resultatet blir ivaretatt. Følgende metode er basert på de vitenskapelige analyseprosessene Inductive Reasoning og ACH-metoden, som jeg håper flere kan la seg inspirere av:

0. Trigger & Scope

En alarm er triggeren for analyseprosessen, men før analysen foregår det enten en automatisk eller manuell scoping-prosess. Scoping blir brukt for å finne ut omfanget av alarmen: Hvilke enheter, brukere, eller filer er involvert? Utfordringen er at analytikeren ofte lager “conformation bias”, det vil si danner seg et bilde av hendelsen og leter etter data for å støtte sin antagelse.

Det som bør inkluderes i scopingen, og som kan bli glemt, er å se etter korrelerende alarmer basert på felles datapunkter. En alarm indikerer én aktivitet, på ett tidspunkt, i én hendelse. En hendelse består ofte av flere alarmer. Ved å analysere flere alarmer, skal scoping-prosessen bidra til å skape flere mulige hypoteser om hva som kan ha skjedd.

Nå starter Analysen, Konklusjonen og Kommunikasjonen.

1. Analysér

Når omfanget av analysen er blitt definert og mulige hypoteser blitt kartlagt, kan vi bruke ACH-metodikken til å komme fram til en stabil konklusjon. ACH står for “Analysis of Competing Hypothesis”, og er analysemetode som setter antagelser opp mot hverandre. Metoden krever at du finner bevismaterialer som beviser for eller imot en hypotese.

All kontekstuell informasjon til en hendelse kan brukes som bevis. En god analytiker vil samle inn mer informasjon enn det som er blitt gitt ved hjelp av analyseverktøyene, og analytikeren vil da få et bedre informasjonsgrunnlag. Kontekstuell informasjon kan være følgende:

• Funn – IOC, brukerkontoer, enheter
• Metadata – enhetsinformasjon og rettigheter
• Tidslinje – aktivitet rundt hendelsen: Hva skjedde før og etter alarmen ble utløst?
• Angrepskjede – Hvor langt er angrepet kommet?
• Trusseletterretning – Hvem er det som mulig kan angripe meg?

Det er viktig å ikke stole blindt på informasjonen som blir gitt ved hjelp av analyseverktøyene, fordi verktøy kan lyve. For eksempel blir logger i XDR vist i lokaltid, men hvis du spør etter data innenfor en hvis tidsperiode ved hjelp av XQL, blir det filtrert i epoch tid (UTC 0). «config timeframe between <start> <end> | [resten av spørringen]». Dette er et problem, fordi det skaper forvirring om når ting har skjedd. En korrekt tidslinje for når ting har skjedd, er svært viktig i alt analysearbeid.

Eksempel på en veldig enkel ACH-matrise:

- Hypotese #1: “ORGANISASJON A” HAR BLITT KOMPROMITTERT AV EN EKSTERN TRUSSEL

- Hypotese #2: “ORGANISASJON A” HAR BLITT KOMPROMITTERT AV EN INTERN TRUSSEL

2. Konkluder

Det kan være fristende å konkludere med at «Det er ikke noe bevis for x og y … derfor er dette ufarlig». Men analytikeren bør stille seg spørsmålet: Hvis denne hypotesen er sann, kan jeg finne bevis for det?

For eksempel, hvis en maskin blir kompromittert av en USB-pinne, kan analytikeren finne bevis for det? ACH-prosessen vil bidra til at analytikeren stiller seg slike spørsmål, og det igjen vil føre til at du samler inn mer informasjon enn du ellers ville gjort.

3. Kommuniser

Formidling av analysen til både kunder, kollegaer og ledelse i virksomheten er en svært viktig del av analyseprosessen. Mottakeren må forstå konklusjonen slik den blir formidlet. Konklusjonen bør bli formidlet på en måte som beskriver ACH-prosessen. Her er et eksempel:

"Det er høyst sannsynlig at angrepet skyldes en ekstern trusselaktør, basert på logger fra brannmur og overvåkningskameraer. Men med informasjonen som er tilgjengelig kan vi ikke utelukke en intern trussel under angrepet."

Oppsummering:

• Vær klar over din egen predisposisjon og ståsted, og regn med at du ikke vet alt. Derfor bør vi stille spørsmål til kollegaer eller andre for å få andres synspunkter på en sak, og om de har opplevd lignende situasjoner.
• Prøv å unngå å la hjernen gå på autopilot når du analyserer, bare fordi automasjon hjelper deg til å ta valg. Vi bør fortsatt tenke kritisk over hvordan saken er blitt analysert på forhånd.
• Ha en felles analysemetodikk som er kjent. Her kan det være lurt å ha et spørreskjema som skal besvares under analysen, for å verifisere at analysen er utført på en strukturert måte. Ta gjerne inspirasjon fra ACH-metoden når du utformer en felles analysemetodikk.
• Husk å kommunisere konklusjonen på en måte som formidler analyseprosessen og inkluderer mulige andre synsvinkler. 

Last ned vår sjekkliste for analyse av en sikkerhetshendelse her, så får du et godt grunnlag og et så godt bilde av hendelsen som mulig: