Att SIEM är något som i princip alla organisationer bör ha i någon form tror jag de flesta inom området informationssäkerhet håller med om. Det är det med ”någon form” som mer har en förmåga att ställa till huvudbry…
Syftet med SIEM
Väldigt grovt tänker jag att en organisation kan ha tre primära syften med SIEM:
- Indexerad lagring av loggar
En SIEM-plattform erbjuder en indexerad och därmed sökbar lagring av loggdata. Du får inte bara tillgång till all logginformation på ett och samma ställe, du kan dessutom indexera upp loggdata i lämpliga fält för att få bättre sökbarhet och statistik, med mera.
- Skydd av logginformation
Många standarder och ramverk (bl. a. ISO 27001, CIS Controls och NIST SP800-53) säger att du ska skydda logginformation från obehörig ändring och radering. En SIEM-lösning kan hjälpa till med det på så sätt att man bara ger rättighet till att ändra och radera information i SIEM till ett fåtal personer som i sin tur inte har rätt att ändra inställningar i källsystemen – så som brandväggar och annan kärninfrastruktur.
- Automatiserad övervakning av loggar
En av de största poängerna med SIEM är väl ändå att få en automatiserad övervakning? SIEM-plattformen bör ha dels en mängd inbyggda och fördefinierade regler och tröskelvärden som kan appliceras samt möjlighet att sätta in egna. Plattformen kan med fördel ha en viss inbyggd intelligens för att t. ex. larma om en ny käll-IP ansluter till en tjänst i större omfattning än normalt mönster, vad det nu är.
Köra sin SIEM själv
En större organisation med tillgång till en tillräckligt stor IT-avdelning (och kanske rentav en säkerhetsenhet) med NOC eller motsvarande kan ha fördelar med att köra SIEM-lösningen själv. Det kommer att krävas viss kompetens för att lyckas få ut effekt från sin SIEM, inte minst i kunskap om hot, sårbarheter och risker för att kunna sätta upp regelverk kring larm och åtgärder på ett adekvat sätt. Man behöver också titta på bemanningen – behöver det finnas en bemanning utanför ordinarie arbetstid?
En nyckelfaktor är valet av teknologi för sin SIEM-plattform. Många är de som vill titulera sig som SIEM-lösning, allt från klassiska logghanteringslösningar så som Elastic och Splunk och om man tänker på punkterna ovan räcker dessa till alldeles utmärkt för att indexera och skydda logginformationen. När det kommer till automatisering av larm och kanske rentav även åtgärder räcker de kanske inte hela vägen. Idag finns även en mängd molnbaserade SIEM-lösningar att välja på.
Det är dessvärre en djungel där det är lätt att gå ner sig. Sätt upp en tydlig krav- och behovsbild kring vad organisationen behöver och önskar få ut.
Köpa SIEM som tjänst
Men nu handlar inlägget alltså om att köpa SIEM som tjänst… Om man nu inte är en större organisation med tillräckliga resurser är det troligen en fördel att köpa in SIEM som tjänst – och om det är en djungel att skaffa sin egen SIEM-plattform är SIEM som tjänst en annan typ av djungel, där valet av teknik inte längre är aktuellt – men nu ställs desto högre krav på kravspecifikationen kring vad organisationen måste, vill och skulle vilja få ut av tjänsten.
Säker och skyddad lagring
Som ett absolut minimum ska tjänsten lagra och skydda er logginformation. Värt att slå vakt om är prissättningen – loggar har en tendens att kräva en del lagringsutrymme (än mer om det är skyddat med redundant lagring, paritet eller liknande) och lagringsutrymme kostar pengar.
Tillgång till logginformation
Ett mervärde av SIEM som tjänst kan vara att få all sin mest kritiska logginformation samlad på ett och samma ställe. En sak att t. ex. brandväggsloggar och säkerhetsloggar från AD:t finns samlat, men ännu mer nytta får man om man dessutom samlar in loggar från sin lagringsplattform, virtualiseringsplattform, sina nätverksenheter och så vidare på samma ställe – det är guld värt vid felsökning att ha det samlat och korrekt indexerat. Detta kräver dock att ni som kun får tillgång till informationen via t. ex. en kundportal.
En viktig aspekt i detta är också hur länge ni har tillgång till logginformationen – hur länge sparas den?
Automatiserad övervakning
Hur tråkigt det än låter kommer en grundfaktor som påverkar prissättningen vara graden av automatisering. Om leverantören är bra på att automatisera vad som ska hända vid upptäckta händelser det (förhoppningsvis) reflekteras i prissättningen. Är det så att leverantörens drift måste göra en massa åtgärder manuellt blir det naturligtvis en dyrare leverans.
Tjänstens fysiska placering
I ljuset av det som skett de senaste åren; införandet av GDPR, Cloud Act, Schrems II och fallet av Privacy Shield, eSAM-uttalanden och så vidare är det klokt att se över var logginformationen som sänds över till SIEM-tjänsten lagras. Är det inom EU är problemet troligen inte så stort ur ett juridiskt perspektiv, men om er organisation är en myndighet kanske logginformationen måste lagras inom landet.
En annan aspekt är ägandet av leverantören. Cloud Act gör gällande att information som hanteras av företag med säte i USA kan tvingas lämna från sig information till rättsvårdande myndighet i USA oavsett var i världen den lagras fysiskt.
Men den viktigaste aspekten är att se över vilken logginformation som skickas över. Är det personuppgifter enligt GDPR är det viktigt att se till så att förordningen följs och att individens rättigheter (så som radering och rättelse) kan tillgodoses. En seriös leverantör har verktyg för t. ex. radering, anonymisering och pseudonymisering av personuppgifter i tjänsten. Ni måste sannolikt teckna personuppgiftsbiträdesavtal med leverantören.
Professionell tolkning av händelser
Den leverantör som ni väljer ska ha en SOC som är bemannad enligt er kravbild. SOC:en ska ha kompetens att kunna tolka den säkerhetsrelaterade information som kommer in, exempelvis information och händelser från brandväggar, Active Directory, O365, AzureAD och så vidare. Och djup kompetens kommer framför allt ur lång erfarenhet. Borra i hur leverantörens SOC arbetar.
Det SLA som tecknas bör förutom tjänstens tekniska tillgänglighet även specificera tillgången till SOC:en – t. ex. tider på dygnet och året och maximal svarstid när man tar kontakt. Dessutom bör det vara specificerat åtgärdstid då tjänsten upptäcker en händelse definierad att agera på.
Och, inte minst, vilket språk använder man i SOC:en och under vilka tider? Leverantörer som jobbar enligt ”follow-the-sun” har kanske flera SOC-center där språk och andra faktorer kan skilja sig. Se till att eventuella utfästelser under säljprocessen dokumenteras och inkluderas i avtalet.
Underliggande teknologi
I grund och botten ska du som kund inte behöva bry dig om den underliggande teknologin när du köper en tjänst, det är liksom en av huvudpoängerna med det hela. Men i takt med att världen och tjänstekartan löpande ritas om förändras även dessa förutsättningarna.
Typexemplet är Microsoft Azure Sentinel. Microsoft erbjuder från tid till annan prisfördelar i Azure Sentinel om organisationen t. ex. har en av de högre Microsoft 365-planerna. I det fallet betalar ni som organisation i praktiken redan en licenskostnad för ett SIEM-system, och detta måste er SIEM-leverantör kunna hantera på samma sätt som sin egenvalda teknologi ”bakom kulisserna”. Ni ska inte tvingas att använda leverantörens teknologi och betala för er del av licensen i så fall utan då betala för övriga delar av tjänstens innehåll.
Summering
Er organisation bör sannolikt ha SIEM-övervakning och om ni inte är tillräckligt stora för att köra det på egen hand är SIEM som tjänst en bra väg att gå. Tänk framför allt på:
- Var informationen placeras fysiskt, utifrån ett GDPR-, Cloud Act- och Schrems II-perspektiv.
- Vilken information som ska skickas, utifrån ett GDPR-, Cloud Act- och Schrems II-perspektiv.
- Graden av automation i övervakningen kombinerat med manuell professionell tolkning.
- Tillgång till logginformation, och hur länge informationen sparas i tjänsten.
- Om egen redan licensierad teknologi kan tas med in i tjänsten (kompetensfråga).
