ISO 27005, en guide för riskhantering

Riskhantering, hur svårt kan det vara? Ta reda på vad som kan gå fel, se till att det inte blir fel, inte så mycket varje fall, och planera för att ta hand om fel som inträffar.

ISO/IEC 27005 är vägledningen för hur informationssäkerhetsrisker ska hanteras. Den fullständiga titeln på nuvarande utgåva är "Information security, cybersecurity and privacy protection, Guidance on managing information security risks". Det är fjärde utgåvan, publicerad i oktober 2022, i Europa antagen som EN ISO/IEC 27005:2024. Den ersatte 2018 års utgåva och skrevs om ordentligt för att passa både ISO/IEC 27001:2022 och ISO 31000:2018.

Standarden är vägledning, inte krav. Ni kan inte certifiera er mot 27005. Den finns för att hjälpa er uppfylla kraven i ISO/IEC 27001:2022 avsnitt 6.1 och kapitel 8, alltså det som handlar om att bedöma och behandla risk. Det är också de kraven cybersäkerhetslagen (NIS2), DORA och CRA i praktiken ställer.

Jag är stridspilot och ingenjör, och har arbetat med flygsäkerhet och signalsystem för järnväg. I de branscherna är frågan aldrig om systemet är byggt enligt en standard. Frågan är om någon kan visa att det är säkert nog, och hur säkert är säkert nog. Ingen kliver ombord på ett flygplan där teknikerna tejpar fast reservmotorn precis före start, men vi driftsätter system på det sättet varje dag.

Den största nyheten är att standarden nu beskriver två sätt att identifiera risk. Det tillgångsbaserade utgår från tillgångar, hot och sårbarheter och arbetar uppåt. Det händelsebaserade utgår från organisationens kontext, dess intressenter och rimliga riskkällor, och arbetar nedåt genom scenarier.

Det andra är vad flyg- och järnvägsbranschen alltid gjort. Man börjar i vad som ska fungera, letar farorna som hotar det, och arbetar sig ner till tekniken. Vår metod med HAZID på verksamhetsnivå och HAZOP i processerna är den logiken, byggd innan 27005 hade ett ord för den. Det är också vad NIS2 kräver.

Kontextetablering betyder att sätta samman den interna och externa kontexten för riskhanteringen. Det här avsnittet kopplar direkt mot ISO/IEC 27001:2022 avsnitt 4.1.

Er kontext, affärsmodellen och vad i den som ska skyddas, är grunden för ett fungerande säkerhetssystem. Standarden delar det i två:

• Extern kontext är den omgivning där organisationen försöker nå sina mål: den politiska, legala, regulatoriska, finansiella och tekniska miljön, drivkrafter och trender som påverkar era mål, externa intressenters förväntningar och värderingar, avtalsåtaganden, samt komplexiteten i era nätverk och beroenden.
• Intern kontext är vision och värderingar, styrning, organisationsstruktur, roller och ansvar, strategi och policyer, kultur, de standarder och modeller ni antagit, era förmågor i form av kapital, tid, människor, processer och teknik, era data och informationsflöden, interna intressenter samt interna beroenden.

Inom flygvapnet innebar kontextanalysen inte bara att förstå uppdrag och hot, utan också interna frågor som vem jag utför uppdraget tillsammans med. Det är precis den distinktionen standarden nu gör explicit.

Ni ska identifiera vilka intressenter som är relevanta och vad de kräver. Här ligger de nya regelverken: cybersäkerhetslagen (NIS2), DORA och CRA är krav från en tillsynsmyndighet som är en intressent, precis som kunder, ägare, försäkringsgivare och underleverantörer är det. Det är också här kravet på att skydda den samhällsviktiga funktionen kommer in, inte som en tolkning av standarden, utan som ett intressentkrav ni fångar i kontexten.

Omfattningen och gränserna för riskbedömningen ska definieras, så att relevanta delar av verksamheten faktiskt kommer med. Omfattningen behöver inte vara hela organisationen, den kan gälla en avdelning, en plats, en tjänst eller ett enskilt system, och ni kan ha flera bedömningar med olika omfattning parallellt.

ISO/IEC 27001:2022 avsnitt 6.1.2 a) kräver två uppsättningar kriterier, och det är dem 6.4 handlar om.

• Riskacceptanskriterier (6.4.2) anger var gränsen går för vad ni tar. De kan uttryckas som flera trösklar med en önskad målnivå och undantag som godkänns av högsta ledningen, eller som ett förhållande mellan uppskattad nytta och uppskattad risk. Kriterierna hänger ihop med organisationens riskaptit — den mängd och typ av risk ni är villiga att eftersträva eller behålla.
• Kriterier för att genomföra riskbedömningar (6.4.3) är skalorna och reglerna för själva bedömningen: hur konsekvens mäts, hur sannolikhet mäts, hur de kombineras till en risknivå, och när en bedömning ska genomföras. Konsekvenskriterierna ska visa hur en informationssäkerhetshändelse slår mot verksamhet, ekonomiskt värde, planer och tidsfrister, anseende samt legala, regulatoriska och avtalsmässiga krav.

Frågor att väga in när ni sätter kriterierna: affärsprocessens strategiska värde, kritikaliteten hos de tillgångar som berörs, legala och regulatoriska krav och avtalsåtaganden, den operativa betydelsen av tillgänglighet, riktighet och konfidentialitet, samt intressenternas förväntningar och konsekvenser för anseende.

Metoden ska väljas här, inte improviseras fram senare. Valet gäller både angreppssätt, händelsebaserat eller tillgångsbaserat, och skalor, alltså kvalitativt, kvantitativt eller en kombination.

Vi väljer ett händelsebaserat angreppssätt på verksamhetsnivå, med HAZID som strukturerad screening ur ett allriskperspektiv (människa, process, teknik, miljö), och kompletterar med tillgångs- och systemnära analys längre ner i arkitekturen med stöd av HAZOP. Kombinationen gör att vi fångar både de scenarier som hotar den samhällsviktiga funktionen och de tekniska orsakerna till dem.

Riskbedömning består av tre aktiviteter: identifiera, analysera och värdera. Resultatet är en prioriterad lista över risker med fastställda risknivåer och en utpekad ägare för varje risk.

Syftet är att avgöra vad som kan hända, och att förstå hur, var och varför det kan hända. 2022-utgåvan beskriver två angreppssätt. De utesluter inte varandra, de kompletterar.

Händelsebaserat angreppssätt. Här utgår ni från organisationens kontext, dess intressenter och rimliga riskkällor, och arbetar er nedåt genom scenarier till de tillgångar som drabbas. En riskkälla är något som ensamt eller i kombination kan ge upphov till risk, och standarden delar dem i mänskliga, miljömässiga och tekniska. Mänskliga riskkällor kan vara avsiktliga eller oavsiktliga.

Ett riskscenario är sekvensen eller kombinationen av händelser som leder från den ursprungliga orsaken fram till den oönskade konsekvensen.

Tillgångsbaserat angreppssätt. Här utgår ni istället från tillgångarna och arbetar er uppåt: vilka hot finns mot dem, vilka sårbarheter kan utnyttjas, vilka säkerhetsåtgärder finns redan, och vilka konsekvenser blir det.

• Tillgångar, mer än hårdvara och programvara. Data, informationsflöden, personal, processer och beroenden till externa parter.
• Hot, av naturligt eller mänskligt ursprung, avsiktliga eller oavsiktliga.
• Sårbarheter, i organisation, processer och rutiner, personal, fysisk miljö, systemkonfiguration, hårdvara, programvara, kommunikationsutrustning och i beroenden till externa parter.
• Befintliga säkerhetsåtgärder, vad som redan skyddar, och hur väl det fungerar.
• Konsekvenser, förlorad effektivitet, försämrade driftförhållanden, utebliven affär, skadat anseende, personskada.

Vilket ska ni välja? Det tillgångsbaserade ger detaljerad täckning men riskerar att missa scenarier som uppstår ur kombinationer och beroenden. Det händelsebaserade fångar det som hotar verksamhetens och samhällets funktion, men behöver kompletteras för att bli tillräckligt konkret att bygga på. För verksamheter under NIS2 rekommenderar vi att börja händelsebaserat och gå tillgångsbaserat i de delar där risknivån motiverar djupet.

Det är också den ordning vi själva arbetar i. Den preliminära riskanalysen börjar i affärsmodell och verksamhet och ringar in vad som är kritiskt för affären och samhället, genom en HAZID-screening ur ett allriskperspektiv. Därefter dyker vi ner i processerna och använder den funktionella och logiska arkitekturen för att hitta orsakerna till farliga händelser, ofta med stöd av HAZOP.

Varje identifierad risk ska ha en ägare: den person eller enhet som har både ansvaret och befogenheten att hantera risken. Två ord som båda måste stämma. En chef utan mandat att fatta beslut om åtgärder eller att acceptera kvarvarande risk är inte en riskägare.

Riskägaren återkommer i 8.6.2, där behandlingsplanen ska godkännas, och i 8.6.3, där kvarvarande risk ska accepteras. ISO/IEC 27001:2022 avsnitt 6.1.2 c) 2) ställer kravet.

Riskanalys är processen att förstå riskens natur och fastställa dess nivå. Skalorna och angreppssättet — kvalitativt, kvantitativt eller en kombination — bestämdes redan i kontexten (6.5).

Bedöma potentiella konsekvenser. Vad blir utfallet om scenariot inträffar, mätt mot konsekvenskriterierna från 6.4.3. Konsekvenser kan eskalera genom kaskad- och kumulativa effekter — särskilt relevant för samhällsviktiga funktioner med beroenden till andra aktörer.

Bedöma sannolikhet. Hur troligt scenariot är, med hänsyn till hur ofta hoten uppträder, hur lätt sårbarheterna kan utnyttjas och vilka säkerhetsåtgärder som redan finns på plats. Standarden använder medvetet "sannolikhet" i bred bemärkelse — oavsett om den bestäms objektivt eller subjektivt, kvalitativt eller kvantitativt.

Fastställa risknivåer. Risknivån är riskens betydelse uttryckt som kombinationen av konsekvenser och deras sannolikhet. Bilaga A i standarden ger exempel på skalor och matriser.

Jämföra mot kriterierna. Analysresultaten ställs mot riskkriterierna som fastställdes i 6.4, för att avgöra om risken är acceptabel eller tolerabel.

Prioritera inför behandling. Riskerna rangordnas så att behandlingen i kapitel 8 kan börja i rätt ände.

Här ligger riskbeslutspunkt 1: räcker underlaget för att avgöra vad som krävs för att få ner riskerna till acceptabel nivå? Om inte gör ni en ny iteration, med ändrad omfattning eller kompletterande expertis.

Riskanalysen slutade med en prioriterad lista med risker. Nu ska säkerhetsåtgärderna hittas, dokumenteras och godkännas.

För varje risk väljs ett eller flera alternativ, baserat på riskvärderingen och en avvägning mellan kostnad och nytta:

• Undvika risken genom att besluta att inte starta eller inte fortsätta med den aktivitet som ger upphov till den.
• Ta bort riskkällan.
• Ändra sannolikheten att scenariot inträffar.
• Ändra konsekvenserna om det inträffar.
• Dela risken med en eller flera andra parter, genom avtal eller riskfinansiering.
• Behålla risken genom ett informerat beslut.

Ett sjunde alternativ finns i ISO 31000 — att ta eller öka risk för att jaga en möjlighet — men det gäller inte informationssäkerhetsrisker. Det kan däremot finnas i er allmänna riskhantering.

Två saker att vara vaken på. Riskdelning betyder inte att ansvaret delas: ansvaret för konsekvenserna ligger kvar hos organisationen, och i hur hög grad risken faktiskt fördelas beror på hur tillförlitliga och tydliga överenskommelserna är. Legala eller regulatoriska krav kan dessutom begränsa, förbjuda eller tvinga fram riskdelning. Och att behålla risken är en temporär acceptans — inte ett avslut. Nivån som behålls beror på era riskkriterier och risken ska fortsatt övervakas.

Riskbehandling kan också skapa nya risker eller ändra befintliga. Det ni gör för att sänka en risk måste därför gå tillbaka in i bedömningen.

En säkerhetsåtgärd är en åtgärd som upprätthåller och/eller ändrar risk. Det behöver inte vara teknik — det kan vara en process, en policy, en enhet, en rutin eller andra förhållanden. Standarden lägger till en varning värd att ta på allvar: säkerhetsåtgärder utövar inte alltid den avsedda eller antagna effekten.

Ni fastställer åtgärderna utifrån de behandlingsalternativ ni valt — inte genom att bläddra i en lista. Åtgärderna ska svara mot både prestandakrav och säkerhetskrav, och begränsningar i tid, ekonomi och teknik är oftast det som styr vad som faktiskt går att göra.

Vår metod arbetar i fyra steg här. Först identifieras nödvändiga säkerhetsfunktioner. Sedan definieras funktionssäkerhetskraven, alltså kraven mot säkerhetsfunktionerna. Därefter bestäms kraven på integritet — hur säkra säkerhetsfunktionerna måste vara. Slutligen översätts detta till säkerhetsfunktioner på logisk nivå, hur systemet ska byggas i den logiska arkitekturen.

När åtgärderna är fastställda jämförs de mot bilaga A i ISO/IEC 27001:2022 för att verifiera att ingen nödvändig åtgärd har utelämnats. Bilaga A innehåller 93 åtgärder i fyra teman — organisatoriska, personrelaterade, fysiska och tekniska. ISO/IEC 27002:2022 är vägledningen som förklarar dem.

Riktningen spelar roll. Bilaga A är en kontrollista i efterhand, inte en meny att välja ur. Det är riskerna som styr vilka åtgärder ni behöver.

Uttalandet om tillämplighet, ofta kallat SoA efter engelskans Statement of Applicability, samlar de nödvändiga åtgärderna, motiveringen till varför var och en tagits med, huruvida den är genomförd, och motiveringen till varför åtgärder i bilaga A uteslutits.

Det är det dokument som binder ihop riskbedömningen med det ni faktiskt gör, och det är det första en revisor ber om.

Processen ser ut så här:

1. Utforma planen. Vilka åtgärder, i vilken ordning, av vem, när, med vilka resurser, och hur effekten ska följas upp.
2. Godkännande av riskägare. Den riskägare som utsågs i 7.2.2 godkänner planen. Det förutsätter att ägaren har mandatet — annars är godkännandet en formalitet utan innehåll.
3. Acceptans av kvarvarande risk. Kvarvarande risk är den risk som återstår efter behandling. Riskägaren accepterar den formellt. Risker som accepteras trots att de inte uppfyller organisationens ordinarie riskacceptanskriterier listas med motivering.

Två saker att komma ihåg om kvarvarande risk: den kan innehålla risk ni inte identifierat, och den innehåller den risk ni medvetet valt att behålla. Accepterad risk står under fortsatt övervakning.

Här ligger riskbeslutspunkt 2. Om den kvarvarande risken inte är acceptabel kan ni antingen söka ytterligare behandling eller gå tillbaka till riskbedömningen, helt eller delvis. Kunskap om hot och sårbarheter som kommit fram under behandlingsarbetet ger bättre beslut i nästa varv.

Riskbehandlingen är alltså i sig iterativ: formulera och välja alternativ, planera och genomföra, bedöma effekten, avgöra om det som återstår är acceptabelt, och behandla vidare om det inte är det.

Kapitel 6 till 8 beskriver hur processen sätts upp. Kapitel 9 handlar om att köra den.

1. Genomföra riskbedömningsprocessen. Riskbedömningar ska genomföras vid planerade intervall och när väsentliga förändringar inträffar — i verksamheten, i hotbilden, i regelverken eller i arkitekturen. Resultatet från varje omgång ska bevaras, både för att kunna jämföra över tid och för att kunna visa att bedömningen faktiskt utförts.
2. Genomföra riskbehandlingsprocessen. Riskbehandlingsplanen genomförs, och resultatet bevaras. Här stämmer ni också av att åtgärderna gav den effekt ni antog — säkerhetsåtgärder utövar inte alltid den avsedda verkan.

Det är i det här kapitlet de två cyklerna från 5.2 blir konkreta. Den strategiska cykeln utlöser en ny eller omfattande bedömning när organisationens övergripande kontext förändras. Den operativa cykeln går kortare varv, där scenarier och tillhörande behandling ses över.

Riskhanteringen står inte för sig själv. Åtta processer i ledningssystemet bär den, och alla finns redan som krav i ISO/IEC 27001:2022.

Organisationens kontext. Kontexten från kapitel 6 är inte satt en gång för alla. När den förändras påverkas riskkriterierna, omfattningen och i förlängningen bedömningarna.

Ledarskap och åtagande. Högsta ledningen äger riskkriterierna och de undantag som görs från dem. Utan det mandatet blir riskägarnas godkännanden i 8.6.2 formaliteter. Det som i 2011 hette "organisation för hantering av informationssäkerhetsrisker" ligger nu här och i den interna kontexten.

Kommunikation och samråd. Riskkommunikation är en uppsättning fortlöpande och iterativa processer för att ge, dela eller inhämta information och föra dialog med intressenter om hur risk hanteras. Informationen kan gälla riskens existens, natur, form, sannolikhet, betydelse, värdering, acceptans och behandling.

Samråd är en tvåvägskommunikation inför ett beslut. Standarden är tydlig med vad det inte är: samråd påverkar ett beslut genom inflytande, inte genom makt, och är indata till beslutsfattandet — inte gemensamt beslutsfattande.

En kommunikationsplan bör finnas för både normal drift och nödsituationer.

Dokumenterad information. Standarden skiljer på två sorter, och distinktionen är användbar. Dokumentation om processer är metoden: kriterierna, skalorna, valet av angreppssätt, rollerna. Dokumentation om resultat är utfallet: riskregistret, riskbehandlingsplanen, uttalandet om tillämplighet, acceptansbesluten. Det första visar att ni har en process, det andra att ni kört den.

Övervakning och granskning. Risker förändras, och 10.5.2 handlar specifikt om att övervaka de faktorer som påverkar dem. Håll koll på:

• nya eller förändrade tillgångar och ändrade tillgångsvärden
• nya riskkällor och nya hot
• nya sårbarheter
• ökade konsekvenser eller sannolikheter som lyfter risken över acceptabel nivå
• inträffade informationssäkerhetsincidenter
• förändrade riskkriterier, legala krav och konkurrenssituation

Ledningens genomgång. Riskbilden är indata till ledningens genomgång — det är där kvarvarande risk, avvikelser från kriterierna och behovet av resurser ska upp.

Korrigerande åtgärd och ständig förbättring. När något inte fungerat som avsett rättas orsaken, inte bara symptomet. Resultatet av övervakningen kan leda till ändringar i den metod eller det verktyg ni använder i riskhanteringsprocessen.