<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=244692402885131&amp;ev=PageView&amp;noscript=1">

Slik tenker Netsecurity rundt sikkerhetsovervåking

Netsecurity 29. mar 2021


Denne artikkelen er basert på et foredrag Henrik Andersen Byberg, driftssjef MSSP i Netsecurity, holdt på NMK Sikkerhetsseminar i 2020. Dette er et samarbeid med pcsupport.no.
Du kan se hele foredraget her: https://pcsupport.no/sikkerhetsseminar-nmk-opptak/


Temaet i denne artikkelen er hvordan vi i Netsecurity tenker når det gjelder sikkerhetsovervåking, som kanskje sier noe om hvordan dere bør tenke om det også. Essensen: Når angripere benytter seg av automatiske angrep, må også analyse og respons håndteres automatisk for å oppdage og stoppe angrepet.

Kombinasjonen teknologi og kompetanse


I rollen som driftssjef MSSP, altså for våre Manager Security Service Platforms, har jeg det tekniske ansvaret for tjenester vi leverer fra vårt miljø. Det inkluderer blant annet de personene som sitter på SOC (Security Operations Center), og passer på at de har den rette kompetansen for å kunne levere god overvåking.

En god overvåking handler nemlig ikke bare om teknologi, en annen viktig ressurs her er menneskene. Jeg har lang erfaring med IT-drift og sikkerhetsløsninger, men de siste fire årene har jeg jobbet dedikert med sikkerhetsovervåking, spesielt med håndtering av logg og automatisering, i tillegg til såkalte SIEM- (eventhåndtering) og SOAR-systemer (automatisering).


Hva er viktig i sikkerhetsovervåking?


Den tradisjonelle måten å tenke rundt sikkerhetsovervåking på fokuserer på de vanlige indikatorene som IP-adresser og domenenavn. Dette ser vi fremdeles på, men det blokkerer vi enkelt i brannmurer og andre typer blokkeringsmekanismer. Dermed er det ikke lenger der vi ønsker å fokusere. Det handler også om at angriperne så enkelt bytte ut disse artifactene, som domenenavnene og hvilken IP-adresse de snakker med, så fokuset i sikkerhetsovervåking ligger ikke lenger der. Vi har fokusert på TTP (Teknikker, Taktikker og Prosedyrer), altså teknikkene og metodene de kriminelle bruker når de forsøker å ta seg inn i organisasjonen vår.

Angrepet kan begynne med noe så enkelt som en phishing-e-post, og derfra klikker en bruker på en link, hvor man kommer til en nettside der man gir fra seg brukernavn og passord. Deretter logger en angriper seg på via VPN-tilgang, kanskje fra utlandet, og så kjøres det et sett med kommandoer for å utføre inngrep i systemet.

Vi gjør ulike undersøkelser for å se hvor angriperne har fått tilgang. Tidligere var det større fokus på signaturer, men hvilke IP-adresser det kommer fra er egentlig ikke relevant. Vi bryr oss jo ikke om angriperen sitter på en norsk IP-adresse eller om han sitter i Russland. Hvis han krypterer dataene våre så har det ingen betydning hvor angrepet egentlig kommer fra, det viktigste er å stoppe angrepet og kartlegge hvordan han kom seg inn, slik at vi kan tette de hullene.


I denne artikkelen får du noen grunnleggende tips for god sikkerhetsovervåking


Risikoen med hjemmekontor


Teknologien hjelper oss til å sammenstille loggdata, til å korrelere og finne anomalier i dataene, og se på disse såkalte TTP-ene. Hvilke taktikker bruker angriperne? Hvordan gjør de sine forsøk? Scanner de etter servere, åpne porter på internett? Den seneste trenden er nye remote desk-løsninger. Med en eksplosjon i bruk av hjemmekontor, er det mange firma som har satt opp hjemmekontorløsninger i hui og hast, løsninger som ikke er godt nok sikret. Angriperne vet jo også om at dette skjer, og de angriper da i stor skala. Får de tak i brukernavnet og passordet til en bruker da, har de en enkel vei inn i organisasjonen. Dårlige brukernavn og passord, spesielt kombinert med en hasteoppsatt løsning, utgjør en betydelig risiko.


Vår løsning: SOC 2.0


Vi i Netsecurity tilbyr et sikkerhetssenter, som vi kaller SOC 2.0. Der har vi tatt i bruk en SOAR-plattform, security orchestration automation and response, rett og slett for å automatisere analysene som tidligere har vært gjort av mennesker.

I vår SOC opererer vi med endepunktløsninger spesiallaget for hver kunde. Endepunktløsningene leverer fra seg en haug med alarmer, alt som kan oppfattes som unormalt vil aktivere en alarm. SOAR-plattformen har i overkant av 500 forskjellige integrasjoner som kan aktiveres for en kunde. Dette gir støtte for et bredt spekter av sikkerhetsprodukter, og gjør at plattformen raskt og enkelt kan integreres med eksisterende eller nye sikkerhetsprodukter. Vi trenger noen til å håndtere disse alarmene. Tidligere hadde vi ansatte som jobbet med dette, men nå bruker vi mer maskinkraft og såkalte playbooks. En playbook kan sammenlignes med en kokebok, den har oppskrifter på hvordan vi skal håndtere et angrep.


Her kan du lese om hvordan Netsecurity hjalp Multiconsult med behovet for et døgnoperativt sikkerhetsoperasjonssenter


Hvis firmaet ditt har investert i SIEM-systemer som f.eks. Qradar eller Splunk, avansert endepunktsbeskyttelse som Palo Alto XDR eller Microsoft Defender for endpoint og klapper dere selv på skulderen og tenker at det var løsningen på alle våre sikkerhetsproblemer, har dere et problem. Vi ser stadig vekk at virksomheter ikke har nok folk til å håndtere og forstå alt som skjer der. Hvis det oppstår noe på fredag kveld, er det ingen som ser på den alarmen før på mandag. Det vi gjør i vår automatiserte løsning, er å integrere denne plattformen inn i ditt eksisterende SIEM ta ut eventer og alarmer, og håndtere dem i vår automatiseringsplattform. Det eneste som kreves, er et API hvor vi kan hente alarmer.

Hvis vi da, etter å ha hentet en alarm og prosessert den, oppdager at her skjer det noe stygt, kan vi automatisk respondere også. Det er helt avgjørende at reaksjonen kommer kjapt i et slikt tilfelle. Hvis vi ser på snittida hos disse bjørneorganisasjonene, en samlebetegnelse på russiske statssponsende hackergrupper, bruker de i snitt 18 minutter fra de har kompromittert en PC til de har beveget seg videre i organisasjonen din og fått tilgang til en server, fått administratortilgang på PC-en din, eller gjort ett eller annet for å påse at de kommer seg videre. Det betyr at vi har 19 minutter på oss til å stoppe angrepet. Da hjelper det lite at du kan se alarmen fra fredag kveld på mandag morgen, for da er datasenteret ditt gjerne blitt kryptert eller skadet. Så responsen, både hvor hurtig og automatisert den er, blir bare viktigere.

Rask respons


Selve playbook-håndteringen eller genereringen er så visuell at våre SOC-analytikere har mulighet til å følge og oppdatere dette underveis. Ser vi alarmer som trigger mer enn én gang, går vi inn og bygger vi om playbooken litt, kjører en ny kommando. I dag har vi tusenvis av actions vi kan kjøre i disse playbookene, og vi bygger disse etter kundens behov og situasjon. Har du et helt spesielt kundesystem, har vi muligheten til å respondere eller hente informasjon også fra disse.

Vi har en oversikt over responstid på alarmene fra den siste måneden, og der ser vi at maksimal responstid fra oss er 12 minutter. Det betyr at vi er godt innenfor de 18 minuttene vi har til rådighet for å hindre at systemet blir tatt ned, angrepet og kompromittert. Grunnen til at det av og til tar så mye som 12 minutter, er at automatikken ikke kan håndtere 100 prosent av alarmene alene. Derfor trenger vi kompetente mennesker, og hos oss sitter de i SOC-en på vakt 24-7, klare til å ta en avgjørelse. Våre sikkerhetsanalytikere har oversikt over hva som har skjedd, og basert på data, fagekspertise og erfaring avgjør de hva som er det beste neste steget. Skal vi gjøre en automatisk respons, er dette en falsk positiv, eller er dette noe vi kan se gjennom fingrene med? Er det nødvendig å resette passordet til denne brukeren, for eksempel?

Den interne motoren for å håndtere alarmer kalles D-bot. I praksis blir størsteparten av alarmene automatisk prosessert av D-boten, noe som gir våre sikkerhetsanalytikere god tid til å analysere de resterende alarmene som måtte komme. Ofte ligger mengden på rundt 13 000 alarmer som blir håndtert automatisk, mens analytikeren sitter med omtrent 300 som han skal håndtere. I tillegg har alarmer som behandles av en sikkerhetsanalytiker vært gjennom en playbook som har gjort en initiell berikelse, analyse og vurdering. Datagrunnlaget analytikeren har tilgjengelig er derfor mye større og det er enklere å ta en hurtig avgjørelse. Forskjellen mellom å jobbe med og uten automatisering blir dermed enorm. Alle som har jobbet med driftsverktøy vet at selv om det ser overkommelig ut å holde oversikten i en uke, men endringer på servere eller andre deler av infrastrukturen medfører ofte at overvåkingsverktøyet begynner å lage alarmer, og så sitter man plutselig der med et driftsverktøy som alltid lyser rødt. Dette er en utfordring vi ser i mange organisasjoner. Sånn er det med sikkerhetsløsninger også, når de er godt tunet inn, fungerer de bra, men det er behov for kontinuerlige endringer og oppdateringer.

Stopp angrepet i tide


Har du ikke systemer som detekterer eller stopper et hackerangrep, kan de få holde på ganske lenge. SOAR kan analysere alarmer for å detektere et angrep, gjenkjenne at det er noe farlig, og dermed stoppe det før det går for langt. Når det er såpass mange indikatorer på at uvedkommende er inne og foretar seg noe i systemet, gir vi oss ikke før vi har kontroll på hendelsen.

Vi stopper det ved å isolere serveren før angriperen har klart å begynne å kryptere data og har gjort noen større skade. Vi stopper angriperen i en tidlig fase, og dette kan vi gjøre fordi vi kjenner taktikkene og prosedyrene angriperne bruker. Dette gjør at når vi ser enkelte avvik i systemet, trigger det en playbook som stopper angrepet og hindrer at systemet og organisasjonen blir kjørt totalt sønder og sammen.

For å oppsummere


Det er viktig med rask respons og å få tilgang til den komplette loggen som dokumenterer hva som skjer. Å ha loggdata fra flere kilder enn kun det som endepunktverktøyet vårt har stoppet, er verdifullt. Netsecuritys SOC-analytikere er på jobb hele døgnet, og de vet å stille de riktige spørsmålene. Det viktigste er faktisk å forstå hvorfor var det noe å blokkere i utgangspunktet? Vi blir oppmerksomme på at noe er blokkert, og så ser vi på hvorfor. Det er det vi skal finne svar på.

Uten et SOAR-system som automatiserer både analysen og responsen og har mulighet til å f.eks isolere endepunktet vil det åpne seg en hel verden av mulighet for angriperne, de kan leke seg og suse fritt rundt i systemene dine. Og det er det vel ingen av oss som ønsker.

New call-to-action