SOC – modeord eller nödvändighet?

Vad är en SOC?

NGFW, AMP, IPS, SASE, ZTN, NDR… Listan av förkortningar inom it-säkerhetsområdet kan göras lång. Flera är att anse som viktiga, kanske till och med nödvändiga för att skydda verksamhet och tillgångar. I centrum av allt detta utmålas ofta en så kallad SOC. Jag får ibland känslan av att många uppfattar SOC som ett magiskt trollspö, eller i alla fall lösningen på de flesta problemen runt it-säkerhet. Finns det någon substans i ett sådant antagande, eller är det kanske även så att SOC kan leda till falsk säkerhet?

OC i SOC står för Operations Center, det vill säga en fokalpunkt för någonting. Annorlunda uttryckt är det en drifts- eller ledningscentral som bemannas av operatörer. De flesta tänker förmodligen på ett rum med stora skärmar som i realtid visar status på det som ska övervakas eller utföras. Det kan vara flygtrafik i luften, fordonstrafik på vägarna eller tågtrafik på järnvägarna. Inom tele- och datakommunikation kan det innebära övervakning, felavhjälpning eller underhållsarbete av mobilnät och infrastruktur.

Gemensamt för dessa drifts- och ledningscentraler är att de har inrättats för att verksamheten ser ett behov av stark kontroll och förmåga att skyndsamt agera på avvikelser. Det är också utifrån det behovet som ett särskilt utrustat rum med stora skärmar kommer in i bilden. Man efterfrågar visuell överblick för att se och agera på larm.

Det som är gemensamt för de flesta driftcentralerna är att de arbetar reaktivt. När de ser att något börjar gå överstyr agerar de på tillgänglig information och åtgärdar problemet. Omstart av utrustning, skicka ut en entreprenör eller stänga ner nätverk vid ett befarat cyberangrepp – allt beror på ledningscentralens uppdrag (och kompetens).

För att ledningscentralen ska förbli proffs på att agera reaktivt behöver den fokusera på just reaktiva händelser. En driftcentral för järnvägstrafiken sitter inte med utbyggnadsplaner för att tillskapa mer spårkapacitet. De kan däremot informera den organisation som har hand om utbyggnad av infrastrukturen var det behövs mer kapacitet när de ser att det uppstår flaskhalsar. Självklart ska de dock ha god insikt i de förändringsarbeten som planeras eller utförs inom järnvägstrafiken.

En SOC har normalt uppdraget att övervaka it-infrastruktur ur ett säkerhetsperspektiv, och det innebär ett reaktivt arbetssätt. Att en SOC kan säkerhetsövervaka nätverk och dess säkerhetskomponenter innebär att de har möjlighet att upptäcka när något går snett. Riskerna är intrång, otillåten dataförflyttning eller anslutningsförsök av okänd utrustning. Hoten är sabotage, oavsiktligt misstag eller riktad cyberbrottslighet – något som behöver hanteras och där SOC kan vara just en fokalpunkt för reaktiva säkerhetsåtgärder.

Hur ska en SOC samverka med andra?

En SOC har i regel inte uppdraget att proaktivt bygga de säkerhetslösningar som skyddar. De ska däremot ha uppdrag att informera den förebyggande it-säkerhetsansvariga om de upptäcker att hot inte kan omhändertas med befintliga verktyg. Det ska då leda till att man skapar nya skyddsbarriärer.

Låt oss göra ett exempel av det.

SOC upptäcker att en mobil enhet (smartphone) försöker nå otillåtna resurser i den egna infrastrukturen. Det är något som mobila enheter inte ska ha tillgång till eftersom de ofta har en sämre ingående säkerhet samt enklare smittas av skadlig kod. Med mobila enheter finns en förhöjd risk för fjärrstyrning av en angripare.

Med de rätta verktygen kan en SOC, i realtid, stoppa mobila enheter från att nå särskilt skyddsvärda resurser. När händelsen är hanterad ska SOC ta kontakt med den resurs som hanterar mobila enheter, exempelvis för att se över skyddet för de mobila enheterna så att de skyddas på liknande sätt som datorer. En SOC bör alltså både ta in information, reaktivt agera och återkoppla förbättringar till de som har ansvarar över det förebyggande skyddet.

Eftersom en SOC ska bestå av särskilda kompetenser och säkerhetsverktyg bör en SOC ha förmåga att i detalj förstå hur en attack utförts, och ge rekommendationer för att det inte ska kunna ske igen. En så kallad SIEM med logginformation om detaljer kring tillvägagångssätt av en attack, drabbade enheter och inträffad skada är en grundläggande förmåga för att en SOC ska kunna reagera och lära verksamheten av inträffade händelser.

Vilka begränsningar bör finnas i en SOC?

Som regel har en SOC inte förmågan att återställa data om skadan är omfattande. Om exempelvis ransomware tar sig in i infrastrukturen och krypterar servrar och data finns två val (men bara ett som hanterar problemet).

Det ena, som ni inte ska välja, är att följa angriparens begäran – exempelvis betala en lösensumma eller utlämna annan skyddsvärd information.

Kvar återstår att laga efter läge; isolera miljöer, testa backuper, identifiera den skadliga kod som med all sannolikhet även finns i backuper, avlägsna denna och kontrollerat bygga upp förmågan igen. Som ni förstår tar återställandet tid och innebär egna risker, som exempelvis att även backuper förstörs.

Trots SOC, interna experter och ansvariga för den dagliga driften är det sannolikt att det kommer behövas även extern säkerhetskompetens – experter som återkommande hanterar den händelse (eller trauma) ni just då genomgår. Det är varken lämpligt, eller möjligt, att en SOC ska få uppdraget att hantera händelser av sådan omfattning.

En SOC bör alltså i dessa sammanhang i första hand vara behjälplig med att undersöka när och hur ett ransomware-virus kom in i infrastrukturen, där andra uppgifter i stället fördelas till respektive expert.

Exemplet ovan visar på när en SOC kan skapa värde och tydlighet- Det visar också på att SOC kan vara en viktig förmåga, men däremot aldrig kommer vara ett trollspö som löser allt på egen hand.

Till sammanhanget följer också att en SOC aldrig kan göra ett bra jobb om förutsättningarna är fel. Med en satsning på SOC följer också en satsning på verktyg som ger insikt, och kan skilja driftrelaterade variationer mot it-attacker. Det skulle vara förödande om en SOC reagerar på ett felaktigt larm, exempelvis att en röntgenutrustning försöker nå en databas den har rätt att kommunicera med, men där larmfunktionen konfigurerats fel. Om en SOC stänger ned utrustning eller nätverk för röntgenutrustningen innebär det att en livsviktig funktion slutar fungera.

Även om det inte gäller liv och hälsa – att en SOC stänger ned hela nätverk i en industriprocess för att en enhet misstänkts smittats av ett virus kommer innebära att pappersbruket, gruvan eller ett valsverk vid en stålindustri stannar. En överdriven åtgärd är med andra ord inte heller önskad. En framgångsrik SOC måste därför initialt och långsiktigt arbeta tillsammans med systemägarna för att både utforma skydd och larmnivåer, men också definiera hur man ska agera vid olika typer av hot eller händelser.

Vid sidan av dialog med systemägare bör SOC arbeta med att upprätta och utveckla den reaktiva säkerhetsförmågan, ofta en CSIRT eller annan säkerhetsfunktion.

Säkerhetsdesign med stöd av tekniska säkerhetslösningar möjliggör säkerhet över tid

I ett tidigare blogginlägg skrev Martin Fransson om vikten av NGFW, nästa generationens brandväggar. Det är en av flera elementära byggstenar för att uppnå säkerhet över tid. När man bygger större hus måste man bygga för att begränsa konsekvensen av en brand, brandceller och sprinklersystem.

I ett it-nätverk finns inte motsvarande regler men även här måste man begränsa konsekvenser av en skada. Därför måste man både segmentera nätverk samt analysera och begränsa möjligheterna till kommunikation för att risk- och skademinimera.

Tar man säkerhet på allvar investerar man också tid och resurser för att uppnå så kallad mikrosegmentering. När, inte om, man drabbas av ett intrång blir då skadan så minimal som möjligt.

För att få god kontroll på sitt nätverk måste man veta vad och vilka som befinner sig på nätverket. Att validera alla enheter genom tekniska lösningar, exempelvis så kallad 802.1x, innebär att endast enheter ni godkänt på nätverket kan ansluta nätverket. Utan 802.1x kan en angripare använda olika verktyg för att ta sig och ta sig vidare, både för att avlyssna och stjäla information eller sprida skadlig kod såsom ransomware.

Ytterligare åtgärder som försvårar för en angripare är att införa MFA (Multi Factor Authentication eller flerfaktorautentisering) på en eller flera kritiska platser i it-infrastrukturen. Det bör helst gälla för åtkomst till såväl datorer som servrar, nätverk eller system, och både inom den egna infrastrukturen eller för anslutning till privata och publika moln.

Behöver ni en SOC så behöver ni alltid en SIEM (logghantering) med förmågor som ger SOC:en nödvändiga insikter. Ta höjd för att bygga in automation, både för skyndsamhet och kvalitet. Denna förmåga ryms i en så kallad SOAR (Security Orchestration Automation and Response). Detta är ytterligare ett exempel på verktyg där tekniska verktyg som med säkerhetskompetenser i en ledningsfunktion (SOC) kan agera och långsiktigt lära av de säkerhetshändelser som inträffar i er it-infrastruktur.

Sammanfattning

Som ni förstått vill jag trycka på att en SOC kan vara del av en lösning, men inte lösningen ensam. Listan på säkerhetshöjande åtgärder är lång, och det här var ett axplock. Det jag vill lyfta fram är att it-säkerhet både är en lagsport och ett maraton. Det krävs flera lager av skyddsåtgärder. Förmågorna ska arbeta förebyggande, reaktivt och lärande kring inträffade händelser och nya hot. SOC är inte ett modeord, utan en viktig byggsten i it-säkerhetsarbetet.

En SOC måste dock utformas och få uppdraget att agera som en ledningscentral med första linjens hantering av säkerhetshändelser. För verksamheten i stort gäller att bygga säkerhet från grunden, där det mest skyddsvärda fastslås och sedan skyddas med skydd i flera lager.

Du är alltid välkommen att kontakta oss om du vill veta mer.

Vänliga hälsningar Torbjörn Zars Säkerhetsexpert Tele2 Företag