Få styr på din onboarding proces
30/03/2021

Guide til SIEM

Hvordan dimensionerer du din SIEM løsning

Ved du hvordan du beregner størrelsen på en SIEM løsning, så den opfylder jeres behov?
Få de grundlæggende formler til beregning af den  korrekte dimensionering af din SIEM installation, inden du køber. Så undgår du økonomiske overraskelser.

I Danmark er vi i øjeblikket inde i en fase, hvor mange kunder skifter fra én SIEM leverandør til en anden, fordi de er blevet skuffede over økonomien og den service der er blevet leveret. De økonomiske overraskelser skyldes ofte manglende overblik – både hos dem selv og hos leverandører. Derfor er de havnet i en situation, hvor løsningen lige pludselig er blevet dobbelt så dyr, som først antaget.

Inden du anskaffer dig en SIEM løsning, er det derfor af afgørende betydning, at du har styr på løsningens omfang dvs. antal softwarelicenser, serverinvestering og driftsomkostninger m.m. Du skal have styr på dimensioneringen af løsningen, altså hvor meget udstyr vil du overvåge, dvs. antallet af logs, så du i sidste ende kender økonomien for hele løsningen.

Den faktor mange bruger i SIEM verdenen er EPS events (begivenheder) pr. sekund, som er de log data et givent it-udstyr genererer pr. sekund, hvad enten det drejer sig om en server, et forretningssystem, en klient, eller netværk.

Enheder genererer ikke den samme mængde EPS (fx har Windows servere en tendens til at genererer meget større logfiler end Linux- og Unix- servere). Så for nemheds skyld har vi her i artiklen taget udgangspunkt i en gennemsnitsværdi.

Efter at have beregnet antallet af EPS, som hver enhed genererer, er næste trin at beregne EPD værdien (events pr. dag).

Dvs. man ganger med 86400 (24 timer x 60 minutter x 60 sekunder):

EPD = ∑ EPS X 86400

 Når EPD-værdien er beregnet, skal størrelsen på en gennemsnitlig logmeddelelse findes, så du får et overblik over det daglige behov for lagerplads. IT-udstyr genererer logfiler. Disse logfiler starter fra 200 bytes på netværks- og infrastrukturenheder og op til 10 kilobytes eller mere på applikations- og databasesiden. Syslog-standarden (RFC 5424) indstiller den maksimale størrelse af en logmeddelelse til 2 kilobyte. På baggrund af denne oplysning vil det være fair at antage, at en rå logbeskedstørrelse vil være 500 byte. Dvs. den gennemsnitlige rå logbesked-størrelse er sat til 500 byte, og antallet af daglige logbeskeder i GB beregnes som følger:

Daglig rå log størrelse = EPD * 500 / (1024)3

 SIEM systemet foretager nogle ændringer på logmeddelelserne for at gøre dem forståelige og meningsfulde i selve SIEM systemet. Denne operation kaldes “Normalisering”, hvilket øger log størrelsen afhængigt af den løsning, der bruges. Min personlige erfaring er, at logstørrelsen øges med ca. 90 til 100 % efter ”Normaliseringen”. Nogle har oplevet en stigning på helt op til 200%. Dvs. resultatet af daglig normaliseret logstørrelse beregnes efter nedenstående formel:

Daglig normaliseret log størrelse = Daglig rå logstørrelse * 2

 Den beregnede værdi repræsenterer ikke den faktiske daglige mængde af data for et SIEM system.

SIEM producenterne kommer med forskellige kompressionsløsninger, og nogle hævder, at de komprimerer logfiler 10 gange (10: 1), hvilket er ret optimistisk. Det er min vurdering, at man godt kan antage et komprimeringsforhold på 8: 1 til beregninger.

Der er leverandører der vælger at komprimere det meste af data, så man kun har hurtig adgang til data som er skabt inden for den nærmeste tid. Denne metode er god og brugbar, og besparende for løsningen

Så formlen vil være:

 Dagligt storage behov = Daglig normaliseret logstørrelse / 8

Der skal tages stilling til, hvor lang tid (antal måneder/år) man ønsker at gemme sine logs, også kaldet Retention perioden.

Her skal man være opmærksom på, at jo længere tid man ønsker at gemme data, jo større og dyrere bliver SIEM løsningen.

Jeg antager i dette eksempel, at retention perioden er 1 år altså 365 dage. Det betyder, at det årlige lagerbehov stort set ville være 365 gange det daglige krav til opbevaring, hvis du vil være på den sikre side. Ikke desto mindre falder EPS-antallet alvorligt i weekender og ferier. Så vær opmærksom på, at det øjeblikkelige EPS-tal du har, ikke er det gennemsnitlige EPS-tal for hele perioden. Vi møder tit kunder som kommer med et meget højt EPS-tal og når vi spørger ind til deres storage forbrug, hænger dette ikke sammen med EPS-tallet, så en kraftig anbefaling vil være lige at regne på sit EPS-tal for hele året eller bruge denne model for at lave regnestykket fra EPS-tal til storage størrelse og den anden vej rundt fra storage størrelse til EPS-tal:

Årligt storage forbrug = Dagligt storage forbrug * 365

 Mht. retention perioden har jeg set mange beslutningstagere forsøge at holde sig på den meget sikre side og vælge opbevaringsperioder som er unødigt lange.

Ifølge firmaet Mandiant Solutions var det gennemsnitlige antal dage, en hacker var til stede på et offers netværk, før de blev opdaget: 197 dage i 2019, 205 dage i 2014, fra 229 dage i 2013 og 243 dage i 2012. Dette bringer mig til den konklusion, at retention perioden for sikkerhedsalarmer og overvågningsalarmer, bør være mindst 1 år og ikke længere end 3 år. I den samme undersøgelse af Mandiant Solutions siges det, at “den længste tid, en hacker var til stede, før vedkommende blev opdaget, var seks år og tre måneder”. Sidst men ikke mindst afhænger opbevaringsperioden naturligvis af sårbarheden af de data man har, og hvor strenge krav der er til retention periode. F.eks. vil kravene i den finansielle sektor være høje, lige som der også er højere krav, når det drejer sig om borgeres persondata.

Jeg håber, at du kan bruge denne model til at regne på din EPS og hvor meget Storage der er nødvendig.

Det kan være en rigtig god idé også at regne den modsatte vej – dvs. du kender dit storage forbrug din retention periode og herefter kan du beregne din EPS, fordi kunder ofte har tendens til at beregne det gennemsnitlige EPS-forbrug ud pr. år forkert, fordi de, som nævnt tidligere foretager en måling i en peak periode og ikke tager hensyn til perioder med ferie, helligdage m.v.

I CapMon har vi udarbejdet nogle modeller som hurtigt og præcist kan udregne dit Storage. Har du lyst til at videre mere, kan du kontakte mig på 4079 0385. og få en uformel snak om, hvordan din SIEM løsning skal dimensioneres.