Cybersäkerhetsrisk i praktiken: Så identifierar du vad som verkligen spelar roll

Problemet: För mycket data, för lite tydlighet

De flesta organisationer saknar inte riskdata.

Tvärtom — de flesta drunknar i den. Varje verktyg som läggs till genererar nya larm, nya rapporter och nya siffror att förhålla sig till. Mängden data växer snabbare än organisationens förmåga att tolka den, och resultatet blir att riskhanteringen mäts i antal rapporter snarare än i faktisk minskad risk.

De har:

• sårbarhetsscanningar
• säkerhetsrapporter
• revisioner
• compliancekrav

Listorna växer för varje kvartal. Nya verktyg läggs till, nya rapporter genereras, nya KPI:er rapporteras till styrelsen. Ändå är det svårt att svara på en enkel fråga:
Vad spelar egentligen roll?

Det är inte ovanligt att en säkerhetsavdelning kan redovisa flera hundra öppna sårbarheter, fördelade över dussintals system, utan att kunna säga vilka tio som faktiskt spelar roll för verksamheten. Resultatet blir att allt hanteras som om det vore lika viktigt — vilket i praktiken betyder att ingenting prioriteras alls.

Det här är inte ett mätproblem — det är ett tolkningsproblem. Fler verktyg ger fler datapunkter, men sällan bättre beslut, eftersom verktygen i sig inte vet vad som är viktigt för just er verksamhet. Den kunskapen finns hos affärsledningen, inte i scanningsrapporten.

Problemet är inte brist på information.
Det är brist på prioritering.

Varför traditionell riskanalys inte räcker

Många arbetar med:

• teknisk allvarlighetsgrad
• antal sårbarheter
• checklistor och regelkrav

Det ger en skev bild.
För att:

• en kritisk sårbarhet i ett mindre viktigt system kanske inte spelar så stor roll
• en medelhög risk i ett affärskritiskt system kan få stora konsekvenser

Tekniska poängsystem som CVSS är byggda för att beskriva en sårbarhets karaktär — inte dess konsekvens för just din verksamhet. Två organisationer kan ha exakt samma sårbarhet, med exakt samma tekniska poäng, men helt olika risk. Skillnaden ligger i vad systemet används till, inte i sårbarheten själv.

Samma sak gäller compliance. Att uppfylla ett regelverk visar att grundläggande kontroller finns på plats. Det säger ingenting om huruvida just de kontrollerna skyddar det som faktiskt skulle skada er mest om det gick fel.

Det betyder inte att tekniska riskmodeller eller compliancekrav är fel. De fyller en viktig funktion — men som en del av bilden, inte som hela bilden. Problemet uppstår när de blir det enda underlaget för prioritering, eftersom de då besvarar fel fråga lika konsekvent varje gång.

Utan affärskontext blir riskanalysen brus.

Skiftet: Från teknisk risk till affärspåverkan

För att riskanalysen ska vara relevant behöver perspektivet förändras.

Istället för att fråga: “Vad är mest allvarligt?”

Fråga: → “Vad skulle skada verksamheten mest?”

Det flyttar fokus till:

• intäktspåverkan
• operativa störningar
• kundpåverkan

Det är där verklig prioritering sker. En IT-avdelning som arbetar isolerat kommer naturligt att rangordna risker efter teknisk svårighetsgrad. En ledningsgrupp som involveras tidigt rangordnar dem istället efter vad som faktiskt drabbar kunder, intäkter och förtroende. Det är inte samma lista — och det är därför affärsägare måste vara med i prioriteringen, inte bara informeras om resultatet i efterhand.

I praktiken innebär det att riskgenomgångar inte längre kan vara ett rent IT-möte. Affärsägare för respektive process behöver finnas med i rummet, eftersom det är de som har svaret på vad ett avbrott faktiskt kostar — i kronor, kunder eller förtroende. Den kunskapen kan inte hämtas ur ett scanningverktyg.

Vad som faktiskt spelar roll

En effektiv riskanalys börjar med att förstå vad som är kritiskt.

Det är fyra områden som tillsammans ger en affärsrelevant bild: vilka processer som driver verksamheten, vilka system de är beroende av, vilka scenarier som faktiskt skulle inträffa, och var ni saknar alternativ om något går fel. Tillsammans bildar de underlaget för att prioritera — var och en för sig ger bara en del av bilden.

Affärskritiska processer

Identifiera:

• kärnverksamhet
• intäktsdrivande aktiviteter
• kundnära tjänster

Om dessa påverkas, påverkas hela affären. För ett tillverkande bolag kan det vara produktionslinjen. För ett tjänsteföretag kan det vara fakturerings- eller leveranskedjan. Poängen är att processerna sällan är hemliga — de är bara aldrig uttryckligen kopplade till en riskbedömning.

System och beroenden

Kartlägg:

• system som stödjer kritiska processer
• integrationer
• beroenden till externa leverantörer

Här syns var risken finns. Många organisationer har god koll på sina egna system, men betydligt sämre koll på vilka externa tjänster och leverantörer som sitter mellan dem och kunden. Ett enskilt API från en underleverantör kan vara den svagaste länken i hela kedjan — utan att stå med på någon riskkarta.

Scenarier med hög påverkan

Fokusera på realistiska scenarier:

• driftstopp
• dataintrång
• leverantörsproblem

Inte teoretiska hot. Det är lätt att fastna i exotiska angreppsscenarier som låter dramatiska men sällan inträffar. De vanligaste incidenterna är betydligt mer vardagliga: ett driftstopp på grund av en felaktig uppdatering, en felkonfigurerad åtkomst, eller en leverantör som plötsligt inte kan leverera. Bygg riskbilden kring det som faktiskt brukar hända — inte kring det som är mest spektakulärt att presentera.

Enskilda beroenden

Identifiera:

• system utan redundans
• processer beroende av en leverantör
• brist på alternativ

Detta är ofta underskattade risker. Ett system kan ha låg teknisk risk men ändå utgöra en enorm affärsrisk, helt enkelt för att det inte finns någon plan B om det faller bort. Frågan att ställa är inte bara “hur sårbart är detta?”, utan “vad händer om det här försvinner i morgon, och har vi ett alternativ?”

En praktisk modell för prioritering

För att gå från teori till praktik:

1. Identifiera kritiska tillgångar

Vad driver verksamheten? Lista de processer, system och tjänster som, om de slutade fungera, skulle ha en direkt och mätbar effekt på intäkter, leverans eller kundförtroende. Detta är grunden — utan en tydlig lista över vad som faktiskt är kritiskt blir resten av modellen gissningslek.

2. Bedöm affärspåverkan

Vilka blir konsekvenserna? För varje kritisk tillgång, beskriv konsekvensen av ett bortfall i konkreta termer: förlorad intäkt per timme, antal påverkade kunder, eventuella avtalsviten eller regulatoriska följder. Konkreta siffror gör det betydligt enklare att prioritera än vaga beskrivningar som “stor påverkan”.

3. Kartlägg beroenden

Vad är ni beroende av? Koppla varje kritisk tillgång till de system, integrationer och leverantörer som krävs för att den ska fungera. Det är i denna kartläggning som dolda enskilda beroenden — den där leverantören utan backup — brukar bli synliga.

4. Prioritera efter påverkan

Vad skadar mest? Rangordna åtgärder efter affärspåverkan, inte efter teknisk allvarlighetsgrad. En medelhög teknisk risk i ett affärskritiskt system ska normalt prioriteras före en kritisk teknisk risk i ett system utan verksamhetsbetydelse.

Resultatet:

• färre, tydligare prioriteringar
• bättre beslut
• effektivare resursanvändning

Vanliga misstag att undvika

Många organisationer:

• försöker hantera alla risker lika
• fokuserar för mycket på compliance
• lutar sig på tekniska riskmodeller

Det leder till:

• splittrat arbete
• låg effekt
• bortslösade resurser

Ett vanligt mönster är att säkerhetsteamet presenterar en lång lista med tekniska fynd för ledningen, som i sin tur inte har förutsättningar att avgöra vad som faktiskt behöver agerande. Mötet avslutas utan tydligt beslut, listan växer till nästa kvartal, och förtroendet för riskrapporteringen sjunker.

Över tid blir effekten dubbel: ledningen tappar förtroendet för att riskrapporterna säger något relevant, och säkerhetsteamet tappar förtroendet för att ledningen någonsin kommer agera på det de lyfter fram. Den spiralen är svårare att bryta än den ursprungliga risken — och den uppstår nästan alltid av samma orsak: avsaknad av ett gemensamt språk för vad som faktiskt spelar roll.

Målet är inte att täcka allt.

Målet är att fokusera rätt.

Vad det innebär för ledningen

Ledningen behöver inte mer data.

Den behöver:

• tydlighet kring vad som är viktigt
• förtroende för prioriteringar
• samsyn i organisationen

Det möjliggör:

• snabbare beslut
• bättre investeringar
• minskad riskexponering

En ledningsgrupp som litar på att riskbilden är affärsrelevant kan fatta beslut på ett enda möte istället för att skicka frågan fram och tillbaka mellan IT och styrelse i flera veckor. Det är skillnaden mellan en organisation som agerar och en som fortsätter diskutera.

Det handlar också om trovärdighet utåt. När styrelse, revisorer eller kunder frågar hur organisationen prioriterar sina cybersäkerhetsrisker, är “vi täcker allt” inget svar. “Vi vet vad som skulle skada oss mest, och vi arbetar med det först” är det.

Från analys till handling

Riskanalys skapar bara värde om den leder till handling.

Det kräver:

• tydligt ägarskap
• prioriterade åtgärder
• samordning mellan IT och verksamhet

Varje prioriterad risk behöver en namngiven ägare, en tidsplan och ett tydligt avstämningstillfälle. Utan det blir även den bästa prioriteringslistan en pappersprodukt. Annars stannar det vid analys.

Ägarskapet behöver ligga hos den som faktiskt kan agera — ofta en affärsägare i samarbete med IT, snarare än enbart hos säkerhetsfunktionen. Säkerhetsteamet kan identifiera och rekommendera, men det är verksamheten som äger konsekvensen av att en process slutar fungera, och det är därför verksamheten som måste äga prioriteringen av åtgärden.

Så kommer du igång

Du behöver inte en ny plattform eller ett halvårslångt projekt för att börja. De flesta organisationer kan ta de första stegen med det underlag som redan finns.

• Samla affärsägarna för era viktigaste processer i ett rum — inte bara IT
• Lista de fem till tio processer som skulle skada er mest om de slutade fungera
• Koppla varje process till de system och leverantörer den är beroende av
• Gå igenom era befintliga riskrapporter och filtrera bort allt som inte rör listan
• Bestäm vem som äger respektive prioriterad risk, och sätt ett datum för uppföljning

Resultatet av den övningen är sällan en lång lista. Det är tvärtom poängen: en kort, gemensam lista som hela organisationen är överens om är viktig, är mer värd än hundra sidor teknisk riskdata som ingen agerar på.

Vad kommer härnäst

När du vet vad som spelar roll är nästa steg att bygga upp förmågan att hantera störningar.

Att prioritera rätt risker är en förutsättning — men prioritering i sig stoppar inget driftstopp. Nästa fråga är hur snabbt verksamheten kan återhämta sig när något ändå inträffar, trots att ni har gjort rätt prioriteringar.

I nästa artikel går vi från risk till affärsresiliens.

Att veta vad som spelar roll är inte slutpunkten. Det är startpunkten för att bygga en organisation som tål att något går fel.

Artikelserie: Cybersäkerhet, risk och resiliens för ledning och organisation

• NIS2, cybersäkerhetslagen, CER & CRA förklarat: Vad det innebär för din organisation i praktiken
• Varför cybersäkerhet är en affärsrisk – inte bara en IT-fråga
• Cybersäkerhetsrisk i praktiken: Så identifierar du vad som verkligen spelar roll
• Från cyberrisk till affärsresiliens: Så bygger du en kontinuitetsstrategi som fungerar
• Incidenthantering inom cybersäkerhet: När (inte om) något händer
• Tredjepartsrisk inom cybersäkerhet: Din största dolda sårbarhet
• Styrning och ägarskap för cyberrisk: Vem ansvarar i din organisation?
• Från compliance till konkurrensfördel: Så skapar cybersäkerhet affärsvärde
• Så skulle jag bygga cyberresiliens i din organisation