Konkrete tiltak for å senke skykostnader.

Sikkerhet og sikkerhetsovervåking er ingen billig affære – spesielt i skyen. En skybasert SIEM er ofte lett å starte med, men mange opplever at kostnadene for logging ofte overgår forventningene. Det er ofte en tung kamel å svelge, da sikkerhetslogger er nødvendig for både overvåking og deteksjon, samt andre formål som threat hunting, incident response og compliance.
Microsoft Sentinel er et godt eksempel på en skybasert SIEM som er lett å komme i gang med. Når løsningen først kom gjorde den mesteparten av jobben med å hente inn loggene og indeksere dem for deg – du trengte bare å betale. Loggene som brukes for aktiv søking og alarmering kalles “analytic tier logs”. Det er dette Microsoft refererer til som “primære sikkerhetsdata”, data som skal aktivt brukes og har høye krav til fart og funksjonalitet.
Disse loggene koster også en del. I Norge pleier man å regne rundt 60 kroner per GB dersom man befinner seg i et Norsk datasenter. Når loggmengdene blir store blir det altså fort store kostnader også. I tillegg har ofte loggene et visst krav til levetid, både mens de aktivt brukes og hvor lenge de skal være tilgjengelig overhodet.
Microsoft Sentinel kommer som standard med 30 dager levetid i analytic tier, uten noe standard arkivering. Det er inkludert opp til 90 dagers levetid i analytic tier uten ekstra kost, man må bare huske å konfigurere det. Skal man lagre data utover 90 dager må man betale ekstra, om det er varm eller kald lagring.
I Defender XDR sendes data fra verktøyene i Defender-porteføljen, blant annet Defender for Endpoint, Office og Identity. Loggene samles inn og lever i 30 dager inkludert i lisensen. Tidligere måtte man sende loggene over til Microsoft Sentinel via “log streaming” som kostet standard inntakskostnad i Microsoft Sentinel. På grunn av volumet var dette ikke veldig utbredt da kostnadene knyttet til det var for store.
Løsningene for å lagre data i lengre tid har lenge vært begrenset til arkivering direkte i Sentinel eller eksport, da til Azure Data Explorer eller Storage Account. Samtlige av løsningene er innviklet på sin egen måte, men ingen var en fullverdig løsning der dataen var brukbar, kosten var relativt lav og man hadde relativt lav kompleksitet i oppsett og drift.
Det har endret seg. I 2025 introduserte Microsoft først “Unified Experience”, hvor Microsoft Sentinel og Defender XDR kobles sammen i Defender-portalen. Dette gjorde at vi etterhvert kunne søke på data på tvers av Defender og Sentinel – uten å streame dataen. Dette er allerede ekstremt kostnadsbesparende.
I tillegg introduserte Microsoft en ny utvidelse av Sentinel, nemlig Sentinel Data Lake. Her kan man sende strukturert og ustrukturert data for lagring i opp til 12 år til en ekstremt redusert pris sammenlignet med analytic tier. Loggene som sendes til Data Lake kaller vi “data lake tier”. Disse loggene kan sendes til Microsoft på alle støttede måter og man endrer bare typen logg direkte i Defender-portalen for å sette over fra analytic tier til data lake tier.
Kosten per GB blir ca 2 kroner (varierer utifra hvor mange GB data man søker i). Det vil si at det er mer optimalt å lage gode, presise søk over å søke bredt når man jobber mot data lake tier, ettersom kosten bestemmes av datamengden søket returnerer.
Regnestykket blir enkelt hvis man for eksempel ser på brannmurlogger. Dette er en typisk «støyete»-loggkilde, der det er mye data og lite ren deteksjonsverdi i dataen. Det er likevel en loggkilde som er viktig for helheten, og deler av dataen kan være kritisk for god deteksjon. Sender man all dataen (la oss si 10 GB per dag) til analytic tier koster det oss ca 600 kroner dagen, mens den daglige kosten blir 20 kroner i data lake tier for samme mengde data.
Hvis vi ser for oss at vi likevel sender 1 GB daglig opp fra data lake tier til analytic tier via en KQL job og det koster oss rundt 60 kroner dagen er det fremdeles mye penger spart. Over en måned er det en besparelse på ca 15 000 NOK, ned fra en fullpris i analytic tier på 18 000 NOK.
Det er selvfølgelig noe mindre funksjonalitet i data lake tier, man kan for eksempel ikke lage deteksjon på dataen og man har ikke full støtte for Kusto (søkespråket til Microsoft). I tillegg må man betale en lav pris for å søke, men bruksområdet er også beregnet på det Microsoft regner som “sekundære sikkerhetsdata” – altså data som ikke brukes direkte i deteksjon eller threat hunting.
Her er det mye besparingsmuligheter, og du har også muligheten til å sende utvalgte data opp fra “data lake tier” til “analytic tier”. Uansett er anbefalingen her er klar – ta i bruk data lake og ta aktive valg for loggkildene dine.
En ting som nylig har blitt mulig er å sende enkelte XDR-tabeller, altså data fra Defender-verktøyene, direkte til “data lake tier” uten å betale for “streaming”. Du får full 30 dagers støtte for deteksjon og threat hunting i Advanced Hunting gjennom Defender-portalen, i tillegg til å kunne lagre dataen opp til 12 år en relativt lav pris. En skikkelig “best of both worlds”.
Mer data er ikke alltid det beste. Erfaring tilsier at mye data forblir ubrukt direkte til deteksjon og kunne blitt behandlet annerledes. Det gjelder også på lavere nivå, når vi ikke ser direkte på datakilden, men dataen i seg selv. Kanskje inneholder en tabell med data 20 felter, men vi bruker kun fire av dem. Da har man flere muligheter til å filtrere bort disse ekstra feltene.
Kanskje det beste eksempelet på dette i praksis er Windows Event Logging fra servere og den innebygde datakoblingen i Microsoft Sentinel. Hver eneste event som sendes inneholder et eget felt, som inneholder hele eventet i råformat – du får altså i praksis den samme dataen to ganger. Filtrerer man ut dette feltet kan man i teorien redusere kostnaden på en loggkilde med opp mot 50%.
Det er lett å si at mer data alltid er bedre, men da har man gjerne ikke regnet kostnad og budsjett med. Vi må være pragmatiske og smarte – vi kan ikke tenke “hva skal vi gjøre med all denne dataen vi samler inn?” og heller tenke “vi må beskytte oss mot dette, hva slags data trenger vi da?”

Vi må starte med å identifisere hva vi ønsker å detektere eller stoppe. I bildet over kan du se en normal flyt fra datakilde helt til en sikkerhetshendelse. Ideen her er å tenke baklengs, altså hva slags alarmer ønsker vi å få? Dette baserer vi på hva vi ønsker å beskytte og det vi er bekymret for, slik at vi kan omdanne dette til et søk.
Start alltid med hvilke hendelser, problemer eller hypotetiske scenarioer vi vil oppnå eller stoppe og jobb deretter derfra mot hva slags søk man trenger og hvilke data som må samles inn fra hvor for at søket skal fungere.
Mange organisasjoner har data liggende som kan utnyttes for å øke sikkerheten, samtidig som mange også har unødvendig mye data liggende i kostbare lagringsmedier som ikke er nødvendige. Det er kritisk å ta aktive valg rundt dataene man samler og bruker. Det vil spare penger over tid og samtidig gi økt innsikt og sikkerhet.



