Sådan 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 her. Beregn den korrekte dimensionering af din SIEM løsning – 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. 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.

Kend økonomien for hele løsningen

Inden du anskaffer dig en SIEM løsning, er det af afgørende betydning, at du har styr på løsningens omfang. Det omfatter antal softwarelicenser, serverinvestering og driftsomkostninger m.m. Hvor meget udstyr vil du overvåge, dvs. antallet af logs. Du bør kende ø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. Dette gælder uanset, om det drejer sig om en server, et forretningssystem, en klient, eller netværk.

Enheder genererer ikke den samme mængde EPS. Windows servere har fx. en tendens til at generere 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. du 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. Det giver dig 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 kilobytes. 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 logstø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 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 logstø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. 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 besparende for løsningen

Så formlen vil være:

Evaluering af den aktuelle server-konfiguration for at sikre optimal drift og ressourceudnyttelse

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. 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: “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. Og der stilles også højere krav, når det drejer sig om borgeres persondata.

Evaluering af den aktuelle server-konfiguration for at sikre optimal drift og ressourceudnyttelse

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. Herefter kan du beregne din EPS, fordi kunder ofte har tendens til at beregne det gennemsnitlige EPS-forbrug ud pr. år forkert. Som nævnt tidligere foretager de ofte en måling i en peak periode og tager ikkehensyn 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 og få en uformel snak omdin SIEM løsning

Flere artikler fra CapMon