Vad gör en SOC?

Vad står SOC för?

SOC står för Security Operations Center och uttalas oftast som tre bokstäver – S-O-C – men förekommer även som ordet "sock" i tal. Begreppet beskriver både den fysiska eller virtuella enhet där säkerhetsanalytiker arbetar och den operativa funktion de utför: kontinuerlig övervakning och respons på säkerhetshändelser i en organisations IT-miljö.

I praktiken används förkortningen ofta synonymt med "cybersäkerhetsoperationer". En SOC kan vara intern (organisationens eget team), extern (köpt som tjänst från en leverantör) eller hybrid (delar av funktionen internt, delar utlagt). Oavsett modell är uppdraget detsamma: minska tiden mellan att ett angrepp inleds och att det stoppas.

Definition

En SOC är en centraliserad funktion som ansvarar för att upptäcka, analysera och svara på säkerhetshändelser i realtid. Funktionen byggs upp av tre delar: teknik (SIEM, EDR, hotintelligens), processer (incidenthantering, eskalering, rapportering) och kompetens (säkerhetsanalytiker på olika nivåer).

I praktiken arbetar en SOC i tre tiers: Tier 1 triagerar inkommande larm, Tier 2 utreder kvalificerade incidenter, Tier 3 hanterar avancerade hot och tröttar ut angripare med threat hunting. För medelstora företag är detta sällan möjligt att bygga internt – kompetens, verktyg och 24/7-bemanning blir snabbt mångmiljonbelopp per år.

SOC-teamets roller och tiers

Ett moget SOC är organiserat i tre nivåer där varje tier har ett tydligt ansvar. Strukturen säkerställer att enkla larm hanteras snabbt och att specialistresurser bara aktiveras när det verkligen behövs.

• Tier 1 – Triage-analytiker: tar emot inkommande larm, filtrerar bort falska positiva och eskalerar verkliga incidenter. Arbetar i skift dygnet runt.
• Tier 2 – Incidentutredare: gör djupare analys, kartlägger angreppskedjan och initierar containment. Beslutar om en incident ska eskaleras vidare.
• Tier 3 – Threat hunters och forensiker: jagar proaktivt efter dolda hot, hanterar avancerade angrepp (APT) och leder bevissäkring vid allvarliga incidenter.
• SOC Manager: ansvarar för bemanning, processer, rapportering till ledning och kontinuerlig förbättring av detektionsregler.

Hur det fungerar

SOC-teamet använder avancerade verktyg för att övervaka organisationens hela IT-miljö. Loggar samlas centralt från arbetsplatser, servrar, nätverk, identitetssystem och molntjänster. SIEM-plattformen korrelerar händelser, EDR-agenter på endpoints rapporterar misstänkt beteende och hotintelligens berikar bilden med kontext om aktiva angripargrupper.

När ett larm bedöms som verkligt initieras en incidentrespons. Det innebär att angreppet isoleras (t.ex. genom att stänga av en infekterad enhet), bevis samlas in, grundorsaken utreds och miljön återställs. Lärdomar dokumenteras och förebyggande åtgärder införs.

• Loggkorrelation och SIEM-system för centraliserad insyn
• Hotdetektering baserad på beteendeanalys och MITRE ATT&CK
• Incidentrespons med definierade playbooks och eskaleringsrutiner
• Sårbarhetshantering och kontinuerlig riskbedömning
• Threat hunting – proaktiv jakt på dolda hot
• Forensik och bevissäkring vid allvarliga incidenter
• Rapportering till ledning och regulatoriska myndigheter

Teknikstacken bakom en SOC

En SOC är bara så bra som dess verktyg och datakällor. Den moderna stacken bygger på flera samverkande lager där varje komponent fyller en specifik funktion i kedjan från insamling till respons.

• SIEM (Security Information and Event Management) – central insamling och korrelation av loggar
• EDR/XDR – beteendebaserad detektion på endpoints och tvärs miljön
• SOAR – automatisering av repetitiva responssteg och playbooks
• Hotintelligens-flöden – kontext om aktuella angripargrupper, IoC och TTP
• Identitetsövervakning – avvikande inloggningar, privilegieeskaleringar och misstänkta tokens
• Nätverks- och molnloggar – flödesdata från brandväggar, proxys, Azure, Microsoft 365 och Google Workspace

Mätetal och SLA – så följs en SOC upp

En SOC ska kunna bevisa sitt värde med siffror. De viktigaste mätetalen handlar om tid – tiden mellan att något händer och att det stoppas avgör om en incident blir en notering eller en allvarlig dataläcka.

• MTTD (Mean Time To Detect) – tid från att ett angrepp inleds till att larm utlöses
• MTTR (Mean Time To Respond) – tid från larm till containment
• Antal hanterade incidenter per månad och deras klassificering
• Andel falska positiva – mäter detektionsreglernas precision
• Täckningsgrad mot MITRE ATT&CK-matrisen
• Efterlevnad av incidentrapportering enligt NIS2 (24 + 72 timmar)

Intern SOC vs SOC as a service

Att bygga en intern SOC kräver minst 8–12 säkerhetsanalytiker (för 24/7-täckning), licenser för SIEM, EDR och hotintelligens samt processer för incidenthantering. För de flesta medelstora företag är det inte ekonomiskt försvarbart.

SOC as a service – där en extern leverantör driver SOC-funktionen åt flera kunder – ger samma kapacitet till en bråkdel av kostnaden eftersom kompetens och plattform delas. ProjAlpha levererar opererad säkerhet där SOC ingår som ett integrerat lager i den övergripande IT-leveransen, inte som en separat produkt.

SOC och regelverk – NIS2, DORA och GDPR

Flera EU-regelverk ställer i praktiken krav på SOC-liknande förmåga. NIS2 omfattar väsentliga och viktiga entiteter i en lång rad sektorer och kräver att incidenter rapporteras inom 24 timmar (tidig varning) respektive 72 timmar (incidentanmälan). DORA reglerar finanssektorn med liknande krav på operativ motståndskraft och incidenthantering.

GDPR kräver att personuppgiftsincidenter rapporteras till Integritetsskyddsmyndigheten inom 72 timmar efter att de upptäckts. Utan en fungerande detektionsförmåga är det svårt att överhuvudtaget veta när klockan börjar ticka. En SOC är därför inte bara säkerhetshygien – den är en förutsättning för att leva upp till lagkraven.

Vad SOC inte är

Det finns några vanliga missförstånd som är värda att räta ut innan man köper in tjänsten.

• En SOC är inte en helpdesk – den hanterar säkerhetshot, inte lösenordsåterställning
• En SOC är inte en brandvägg eller antivirus – det är funktionen som tolkar vad dessa verktyg signalerar
• En SOC ersätter inte säkerhetspolicyer eller utbildning av personal
• En SOC fungerar bara så bra som loggdatan den får – är inte alla källor anslutna finns blinda fläckar

Varför det är viktigt

Hot uppstår dygnet runt och de flesta angrepp sker utanför kontorstid – kvällar, helger och röda dagar. Utan en SOC är medeldetektionstiden (MTTD) för intrång enligt IBM:s rapport över 200 dagar globalt. En SOC som agerar på minuter kan stoppa ett angrepp innan det utvecklas till en allvarlig dataläcka eller ransomware-incident.

Regulatoriska krav driver också behovet. NIS2 och DORA kräver att kritiska verksamheter har förmåga att detektera och rapportera incidenter inom kort tid – något som i praktiken kräver en SOC-funktion.

Så väljer du SOC-leverantör

Marknaden för SOC-tjänster är spretig och produkterna ser ofta likadana ut på pappret. För att hitta rätt leverantör är det viktigt att titta bortom marknadsföringen och granska hur tjänsten faktiskt levereras.

• Är SOC bemannad 24/7 av egna analytiker, eller bara automatiserad utanför kontorstid?
• Vilka SLA gäller för MTTD och MTTR per incidentklass?
• Vilka datakällor kan anslutas – och vad kostar varje extra källa?
• Ingår incidentrespons och forensik, eller debiteras det per timme när larmet går?
• Hur ser rapporteringen till ledning och styrelse ut?
• Är SOC en separat produkt eller integrerad med övrig IT-drift och identitetshantering?

Hur företag använder detta

De flesta medelstora företag använder en extern SOC-tjänst istället för att bygga en egen. Hos ProjAlpha är SOC ingen separat produkt utan en integrerad del av den opererade IT-miljön. När arbetsplatser, nätverk, identitet och säkerhet redan hanteras i samma plattform har SOC-funktionen tillgång till all data direkt – utan separata integrationer.

Automatisk övervakning och larm dygnet runt. Bemannad larmhantering och support vardagar 08–17. Leveransen kan byggas på med SLA Standard: 4 timmars svarstid vid kritiska ärenden, vardagar 07–19.