Hvorfor er dette viktig?

De fleste sikkerhetsverktøy vi kjøper kommer ofte ut av boksen med en konfigurasjon som er mindre gunstig. Likevel lar mange det være med kjøp eller installasjon, og etterlater med det et stort gap i sikkerheten og masse uutnyttet potensiale i sine verktøy. I denne artikkelen skal vi se på noen konkrete tiltak vi kan gjøre for å motvirke dette.

Introduksjon til XDR (Extended Detection and Response)

Et av de viktigste punktene i den operative sikkerhetsstrategien til de fleste firmaer inkluderer i dag en XDR, som Microsoft Defender XDR. Det er ikke standardisert eksakt hva som ligger i en XDR på tvers av leverandører, men typisk ser vi at det er en sammenslåing av verktøy som EDR, CNAPP, SIEM og ofte en Security Data Lake.

Styrken til en XDR-plattform er ofte misforstått – mange tenker at det gir god synlighet å samle verktøyene i en «single pane of glass» og at det gjør arbeidet mer effektivt, men det er ofte bare en liten bonus.

Den store styrken til gode XDR-plattformer er at man samler og korrelerer data fra hele bedriften. Dette bidrar til at man kan gå fra å se på enkeltsignaler til å se på angrepsstier gjennom nettverket, analysere dem og stenge dem ned før det blir problematisk.

«Secure by default»

Et av de største problemene med XDR og verktøyene knyttet til plattformen er at mange misforstår jobben som kreves for å sette opp og drifte dem. Installer en EDR-agent på et endepunkt eller en server, så skal det være OK, ikke sant? Vel, ikke alltid.

De fleste EDR-agenter, uavhengig av leverandør, vil søke å være minst mulig støyende ved installasjon. Det vil si at de ofte legger seg litt på «latsiden» når det kommer til konfigurasjon, man tillater altså mer enn det vi vanligvis kanskje ville ønsket.

Eksempelvis endret Microsoft en stund tilbake standard oppførsel for Linux-maskiner i Azure som innrulleres via Defender for Cloud. De settes nå som standard i passive-mode, som vil si at det kun overvåkes og ikke gjøres noe aktiv respons fra EDR-produktet. Dette er dokumentert som standard av Microsoft, men ofte ligger disse systemene i passiv modus lenge.

Det er ekstremt viktig i alt av sikkerhet at man alltid setter innstillinger eksplisitt. Det vil si at dersom man ønsker at innstilling skal være 1 og standarden er 1 må man fremdeles eksplisitt sette innstillingen til 1. Dette er fordi leverandører ofte endrer hva som er standard, som kan påvirke systemet når det endres om man ikke får det med seg.

Et eksempel er Defender for Cloud-endringen fra tidligere – der endret standarden seg fra at EDR sto i aktivt til at det ble satt i «passive-mode». Hadde vi eksplisitt satt innstillingen til aktiv beskyttelse hadde ikke endringen påvirket oss.

Problemet ligger ikke hos leverandørene – det ligger oss som bruker verktøyene. De fleste EDR-verktøy gjør det lett å sette konfigurasjon som øker sikkerheten betydelig, uten at det merkes nevneverdig i brukervennlighet. Da er det opp til oss å ta i bruk disse mulighetene for å heve sikkerheten til å matche vår appetitt for risiko.

Hva kan vi gjøre?

En ting som er absolutt kritisk å starte med er å sørge for at man har Cloud Protection aktivert dersom man bruker Microsoft Defender for Endpoint (DFE).

Cloud Protection står på som standard, men mange kan ha slått det av uten å tenke på det gjennom å slå av cloud sample submission. Dette må være på, enten ved at «send all samples automatically» eller «send safe samples automatically» er slått på. Styrer man via group policy er «MAPS»-innstillinger tilsvarende «cloud-delivered protection» i Intune.

Cloud Protection lar oss blant annet bruke «Tamper Protection» som beskytter oss mot uønskede endringer på systemet vårt. «Block at first sight» eller «BAFS» som betyr at Microsoft stopper alle filer de aldri har sett før og gjør automatisk analyse før den får lov å kjøre. Denne «BAFS» funksjonaliteten er en av de viktigste kapabilitetene DFE har og er avhengig av tilkobling til internett og Defender-konsollen.

Cloud protection level og cloud block timeout

Når vi har sørget for at Cloud Protection er slått på kan vi også konfigurere nivået på beskyttelsen. Cloud Protection level er som standard satt til «Not configured», noe som ikke er ønskelig.

Alternativene man har til Cloud Protection level er «High», «High Plus» og «Zero Tolerance». Her anbefaler vi som minimum å sette innstillingen til «High». Av de to andre alternativene er «High Plus» relativt lik som «High», men gjør en del ekstra som kan påvirke ytelsen på en klient. «Zero Tolerance» blokkerer alle ukjente filer som standard og anbefales kun til ekstra sensitive eller kritiske systemer.

Cloud Block timeout sier noe om hvor lenge DFE stopper mistenkelige filer fra å kjøre mens den gjør seg opp en mening om det er grunnlag for mistanken. Standarden er satt til 10 sekunder og maks er 50 sekunder. På de fleste systemer anbefaler vi å øke til minst 30 sekunder, men det er god praksis å sette til 50 sekunder der man kan. Dette vil selvfølgelig kunne ha litt innvirkning på brukeropplevelsen ved installasjon av filer.

Integrer Defender for Cloud Apps

Det beste verktøyet i kampen mot skygge-IT er Defender for Cloud Apps (MDA), også tidligere kjent som «MCAS». Det mange ikke vet er at en integrasjon mot Defender for Endpoint (MDE) er den viktigste kilden til å oppdage nye applikasjoner for MDA. Logger fra endepunktene dine sendes til Cloud Apps for å gi innsikt i applikasjonsbruk i din organisasjon. Denne integrasjonen er ikke slått på som standard.

Når du markerer applikasjoner for blokkering eller overvåking i MDA gjelder det i utgangspunktet kun applikasjoner som besøkes via nettleser og kun når du bruker firmabrukeren din. Når du kobler MDA og MDE sammen vil du også kunne blokkere applikasjoner på endepunktene dine for alle brukere og dermed begrense skygge-IT på firmaets utstyr.

Konfigurasjonen er relativt simpel – i Defender XDR-konsollen går du til Settings > Endpoints > General > Advanced features. Her finner du flere innstillinger som kan slås på, men spesifikt er det «Microsoft Defender for Cloud Apps» og «Custom network indicators» innstillingene som skal settes til «On».

I tillegg må du slå på integrasjon mot MDE fra MDA. Fremdeles i Defender XDR-konsollen går du til Settings > Cloud Apps > Cloud Discovery > Microsoft Defender for Endpoint. Her setter du «Enforce App Access» til å være på. Det er også mulig å endre alvorlighetsgrad på alarmer her, men det er anbefalt å gjøre dette reaktivt basert på data over tid.

Spar penger på Data Lake

Nytt fra 2025 er at Microsoft Sentinel brukergrensesnittet flytter inn i Defender XDR-konsollen. Dette gjelder alle nye Microsoft Sentinel kunder og vil gjelde alle kunder fra Mars 2027.

Dette har en del positive endringer med seg – blant annet kan man allerede i dag slå på integrasjonen mellom Sentinel og Defender som kalles «Unified Experience». Her kan man gjøre søk på tvers av data fra Sentinel og XDR-verktøyene uten ekstra kost. Dette måtte man tidligere sette på «streaming» av logger fra XDR til Sentinel for å gjøre, som kostet en betydelig sum penger.

Microsoft har også tilgjengeliggjort Microsoft Sentinel Data Lake i de fleste regioner. Sentinel Data Lake er en Security Data Lake som skal supplere funksjonaliteten i Microsoft Sentinel. Der Sentinel er en tradisjonell SIEM-plattform, laget for å ta imot strukturert data som skal brukes som grunnlag for dynamisk og rask deteksjon er data lake laget for å tilby lagring av store mengder data. Dataen kan være både strukturert og ustrukturert, og kan lagres lengre perioder til en betydelig lavere sum, men da med mindre funksjonalitet.

Microsoft skiller på primær- og sekundær-data for sikkerhet:

• Primær-data er det som typisk brukes til løpende deteksjoner og må kunne være tilgjengelig fort med bred funksjonalitet.
• Sekundær-data er typisk data som har lavere verdi for deteksjon, er støyete (altså har en lav kost/nytte verdi for volum opp mot deteksjon) eller brukes for andre formål som f.eks compliance.

Her kan man spare mye penger på å sende sekundær-data direkte inn i data lake.

Hvis man kun trenger en liten del av sekundær-dataene som sendes inn til data lake kan man bruke funksjoner som «KQL jobs» som lar deg hente ut deler av datafeltene i loggene og gjør dem om til primær-data automatisk i gitte tidsintervaller.

Bildet under illustrerer forskjellen på primær-data («analytics tier», blå farge) og sekundær-data («data lake tier», oransje farge), samt prosessen med å sende spesifikk sekundær-data opp som primær-data.

AI og MCP

Med Microsoft Sentinel Data Lake ble det også tilgjengeliggjort et MCP-endepunkt («Model Context Protocol») for Sentinel. Dette gir muligheten for at analytikere nå kan jobbe sammen med agenter f.eks i VSCode for å løse saker.

Agentene kan kjøre semantisk søk, der det tas hensyn til kontekst, intensjon og språkforståelse mot dataen i Data Lake, samt benytte seg av innebyggede og egenlagde ferdigheter (tools). Disse ferdighetene er eksponerte funksjoner som kan brukes av agenter til å utføre oppgaver.

Det gis stadig ut nye ferdigheter som kan brukes, men per i dag har man støtte for følgende ferdigheter:

• Analysere tabeller

• Hente ned data

• Analysere entiteter som er støttet av Sentinel

• Lage nye Security Copilot-agenter

• Gjøre hendelseshåndtering

• Proaktiv «threat hunting».

Det er anbefalt å sette seg inn i hvordan disse verktøyene funker og hvordan det kan bistå i det daglige sikkerhetsarbeidet.

Eksempler på bruksområder kan være bistand til å proaktivt lukke ned angrepsstier i miljøet, eller hjelp til å videreutvikle og teste deteksjon man har skrevet eller ønsker å skrive.

Ta grep – det er ditt ansvar

Microsoft Defender XDR har ekstremt mange innstillinger på tvers av mange forskjellige verktøy. Denne artikkelen nevner noen få av de viktigste, men det er mange flere som må følges opp både i Defender XDR og på tvers av Microsoft 365 og Azure.

Har man E5-lisens har man kanskje mange av disse kapabilitetene uten å skikkelig utnytte dem. Det er viktig at man ikke forveksler det å ha lisenser på et verktøy eller en kapabilitet med at det er konfigurert og fungerer – man må ta egne grep for å konfigurere sine verktøy slik at det gir beskyttelsen man trenger og forventer.

Det er også viktig å ikke undergrave innstillingene man setter – det blir stadig funnet metoder for å omgå verktøy som EDR på, men de fleste av disse metodene krever at man har lokal administrator på maskinen. Et av de viktigste sikkerhetstiltakene man kan fatte er altså fremdeles å fjerne lokal administrator og bruke «just-in-time»-tjenester som «MakeMeAdmin» der det trengs.

Sicra anbefaler å ta en grundig gjennomgang av sikkerhetsinnstillinger i hele Defender XDR-porteføljen, Microsoft 365 og Entra ID ved jevne mellomrom. Bruk av verktøy som Maester kan være med å automatisere deler av jobben – dette sikrer at man utnytter lisenser man har, hindrer konfigurasjonsdrift og tar i bruk nye kapabiliteter når de er tilgjengelige.