Tekniskt mäta och granska sig själv

En av de absolut viktigaste stöttepelarna i en organisations säkerhetsarbete är att mäta och granska hur säkerhetsarbetet fungerar. Här gäller det att se upp och verkligen tänka till så att granskningen görs på ett oberoende sätt. Låt mig ge ett konkret exempel.

I de flesta IT-tunga verksamheter är SIEM och löpande sårbarhetsanalys två exempel på viktig funktionalitet att ha implementerat för att mäta och övervaka säkerhets- och hotnivåer. I den mindre IT-organisationen låter man då kanske sin driftorganisation implementera en SIEM-lösning, kanske med Splunk eller Elastic Stack. Man kanske sätter upp sårbarhetsscanning med Nessus, Nmap eller Nexpose som schemaläggs att köras mot publika IP-adresser med viss regelbundenhet.

Här vill jag dock poängtera att det finns stora risker som bottnar i behov av kompetens och erfarenhet inom området. En tidigare kollega sa en gång att ”any monkey can press the ’Scan’ button” och det ligger mycket i det. Tro det eller ej, men det finns penetrationstestare där ute som levererar skanningsrapporten som sitt enda resultat av penetrationstestet, och det ger naturligtvis inget värde. Samma sak gäller när man kör sin egen sårbarhetsanalys internt – när scanningen väl är avslutad och verktygets analysrapport kommer krävs det mycket erfarenhet för att tolka resultatet och dels hitta men även prioritera de verkliga riskerna.

Samma sak gäller med SIEM som enligt min uppfattning har potential att fylla tre viktiga funktioner; tidig upptäckt av hot och risker, skydd av loggar från förändring och radering samt även med samlad loggning från flera källor vara till stor hjälp vid t.ex. felsökning. Å andra sidan kan en felaktigt konfigurerad SIEM effektivt stänga alla dessa fördelar. Är inte logginformation rätt indexerad i SIEM-lösningen blir den i praktiken bara en hink med råa loggfiler som blir rätt oanvändbara. Är inte larm och tröskelvärden rätt uppsatta kan inte lösningen upptäcka tidiga hot och risker. Och, inte minst, har ”alla” fulla rättigheter i systemet så är inte loggarna skyddade mot otillåten förvanskning och radering.

Summerat är alltså det bästa att inte göra det själv utan att konsumera såväl sårbarhetsanalys och SIEM som tjänst. Det finns en uppsjö med leverantörer som levererar dessa tjänster och mer därtill, ofta paketerade som SOC-tjänster där leverantören i SIEM-fallet tar emot, granskar, analyserar, prioriterar och rapporterar händelser enligt en definierad procedur. Tanken bakom är att leverantören i realtid håller koll på säkerhetsrelaterade händelser via exempelvis loggar och integrationer åt dig och rapporterar om man tror att någonting dåligt är på väg att hända eller i värsta fall redan hänt. Köper man sårbarhetsanalys som tjänst scannar leverantören regelbundet publika IP-adresser från Internet och interna system i nätverket efter kända sårbarheter och analyserar, prioriterar och rapporterar dessa till dig som kund.

Men även här finns anledning att se upp och att tänka till. Det finns idag till exempel många driftleverantörer som gärna adderar SOC-tjänster till exempelvis ett outsourcinguppdrag. Här måste man komma ihåg att en mycket stor del av säkerhetsfunktionaliteten ofta är just outsourcad och måste granskas kritiskt utan risk för intressekonflikt. Som kund måste du vara helt säker på att all rapportering är transparent, och det är klart att det finns en risk att outsourcingleverantören inte kommer rapportera sårbarheter i nätverket som leverantören själv står som ansvarig för. Samma sak gäller i SIEM-fallet – om händelser upptäcks som beror på exempelvis en felaktig konfiguration i hyrd brandväggstjänst kanske den informationen inte kommer att nå dig som kund.

Min skarpa rekommendation här är att alltid se till att den som granskar och mäter är helt och hållet oberoende och opartisk. Med andra ord; sköter ni er IT-drift i egen regi köper ni med fördel SOC-relaterade tjänster från en leverantör som står oberoende från er. Om ni köper IT-drift som tjänst i någon utsträckning bör ni konsumera SOC-tjänster från en helt fristående leverantör som är oberoende från er driftleverantör.

Läs mer: SIEM som tjänst

Tips vid upphandling

• Säkerställ att den som mäter och granskar är helt fristående och oberoende den som på något sätt ska granskas, oavsett om det avser er själva eller er driftleverantör.
• Säkerställ att en leverantörs SIEM-övervakning är automatiserad och inte bygger på ett beroende av mänskliga ögon som ”håller koll” på grafer och trender.
• Det är fördel om SIEM-lösningens regelverk bygger på AI/maskininlärning istället för manuellt uppsatta regler och tröskelvärden.
• Säkerställ att leverantör av sårbarhetsanalys verkligen analyserar och prioriterar fynd samt ger konkreta rekommendationer på åtgärder vid funnen sårbarhet.
• Ska SOC-tjänst vara tillgänglig dygnet runt måste du säkerställa att tjänsten levereras på föredraget språk under kvällar, nätter och helger om det är så ni vill ha det. En svensk SOC kanske bara levereras från Sverige under svensk kontorstid.
• Analysera risker och konsekvenser med den information som avses skickas till en leverantör – så som logginformation som ofta innehåller personuppgifter. Tänk särskilt till kring rättslig grund för behandling och individens rättigheter definierade i GDPR. Teckna om nödvändigt ett personuppgiftsbiträdesavtal.