När man arbetar med cybersäkerhet och ska segmentera sina system i säkerhetszoner är det en god idé att använda sig av riskanalys. På detta sätt undviker man att säkerhetsarbetet blir utfört enligt en odefinierad ”ad hoc”-metod och dessutom blir det oftast enklare att förklara och motivera de investeringar man vill göra om man kan redogöra för vilka risker man åtgärdar eller reducerar. Standarden IEC 62443 är en bra metod att använda när man gör sin riskbaserade zonindelning.
I denna text förklarar vi i detalj vad som är viktigt att tänka på när man genomför en riskanalys och en riskbaserad zonindelning enligt IEC 62443.
Varför gör man en riskanalys?
För att kunna veta åt vilket håll man ska gå i sitt cybersäkerhetsarbete måste man utvärdera verksamheten så som den ser ut idag – genom att göra en analys av de risker som finns i nuläget i verksamhetens system.
I en initial, enkel riskanalys identifierar man det värsta som kan hända idag utan att ha introducerat några riskreducerande åtgärder. Senare görs en detaljerad riskanalys för separata zoner och flöden. Detta steg tar man först när man gjort indelningarna av zoner och flöden som baserats på den initiala riskanalysen.
Målet med dessa riskanalyser är att i slutändan kunna applicera rätt riskreducerande åtgärder och skapa en säkrare verksamhet där krutet läggs på rätt ställen.
Hur gör man en initial riskanalys?
I den initiala, enkla riskanalysen tittar man på ett worst case-scenario, alltså det värsta som kan hända i verksamheten. Här räknar man med att man inte vidtagit några åtgärder för att reducera de risker som finns. Man behöver en del input i denna fas, så som:
- Övergripande systemarkitektur – man behöver veta vilka system som ingår för att systematiskt kunna gå igenom dem.
- Riskkriterier och riskmatris med tolererbar risk – vilka risker kan vi acceptera och vad måste vi åtgärda? Hur mäter vi risk?
- Befintliga riskanalyser – har vi gjort någon slags riskanalys tidigare och kan använda oss av delar därifrån?
- Information om hotbild – vad skulle kunna hända? Vilka hot finns gentemot organisationen?
Ovan är ett exempel på en riskmatris där man lätt kan se hur allvarlig en risk är beroende på konsekvens och sannolikhet. I detta exempel har man bestämt att:
- Tolererbar risk, en risk man är villig att ta, är turkos.
- Signifikant risk, alltså en risk man kanske bör göra något åt, är mellanblå.
- Ej tolerabel risk alltså en risk man måste göra någonting åt, är mörkblå.
Utifrån denna input kan man alltså räkna ut en worst case-risk som de olika delarna i systemet blir utsatta för utan säkerhetsfunktioner eller segmentering. Det man ska fråga sig är vilken påverkan en cyberattack som medför att systemen sätts ur spel får på verksamheten? Hur stor blir spridningseffekten? Hur stora geografiska områden påverkas och hur många människor påverkas? Om eldistributionen skulle stängas av kan många människor påverkas. Finns det kritisk verksamhet (t.ex. sjukhus) som är beroende av eltillförsel? I den initiala riskanalysen är man bara intresserad av konsekvensen och antar då att sannolikheten är ’ofta’, vilket innebär att vi kommer röra oss i den högra kolumnen i figuren ovan.
Genom att definiera våra olika worst-case-scenarion och koppla dessa till de olika systemen kan vi göra en initial zonindelning där systemen placeras i zoner tillsammans med andra system med samma nivå av skyddsvärde.
Hur gör man en detaljerad riskanalys?
Efter den initiala riskanalysen gör man en indelning av zoner och dataflöden. Mer om hur du gör en zonindelning kan du läsa om i vårt blogginlägg!
När man gjort denna indelning kan man göra en detaljerad riskanalys. Enligt IEC 62443 gör man en detaljerad riskanalys om den initiala risken överskrider den acceptabla risken. I den detaljerade riskanalysen gör man en riskanalys per zon och flöde och utgår från samma riskmatris som för den initiala riskanalysen. I den detaljerade riskanalysen utgår man från ett antal steg:
1. Identifiera hot och hotaktörer mot zoner och flöden
I detta steg identifierar man vilka hot och hotaktörer som kan påverka ens zoner och flöden. Detta kräver kunskap om hotbilden mot verksamheten – här kan man använda sig av omvärldsbevakning. Man kan titta på flera olika källor, bland annat från MUST och Säkerhetspolisen. Detta är för övrigt någonting som organisationens säkerhetschef bör ha koll på.
2. Identifiera sårbarheter som kan utnyttjas
Nästa steg är att identifiera sårbarheter där syftet är att hitta möjliga svagheter eller ”hål” som kan utnyttjas. Det finns ett antal källor man kan använda sig av för att hitta potentiella sårbarheter:
- Nätverksarkitektur: Vilka anslutningspunkter finns, vilka vägar finns ut på internet?
- Trafikanalys: Avslöjar trafik som kanske inte borde vara där. Finns det produkter som kommunicerar ut på internet som inte borde göra detta?
- Penetrationstester: Genomförs ofta av externa experter.
- Sårbarhetsskanning: Kan också utföras av extern expertis.
- Säkerhetspolicys: Är de uppdaterade gentemot hotbilden?
- Säkerhetskritisk personal: Vilken säkerhetskritisk personal finns och vad har man i form av instruktioner, processer, utbildning, bakgrundkontroll? Notera att många attacker görs på grund av misstag av den egna personalen.
- Intervjua personalen: Ofta sitter personalen på mycket information om säkerhetsbrister som de har identifierat.
3. Bedöm omitigerad konsekvens, sannolikhet och risk
Sedan måste man bedöma omitigerad konsekvens, sannolikhet och risk. Kombinationen av sannolikhet och konsekvens innebär en risk som mitigeras/mildras av en åtgärd. En omitigerad risk är alltså en kombination av sannolikhet och konsekvens innan vi introducerat en eller flera skyddsåtgärder. Exempel på typer av konsekvenser är:
- Personsäkerhet
- Ekonomisk påverkan
- Avbrott i verksamheten
- Miljöpåverkan
- Nertid, skada på utrustning
När man har analyserat de konsekvenser som skulle kunna ske måste man undersöka hur sannolika de är. Det kan ibland vara svårt att förutse, men här är några saker man kan ha i åtanke:
- Har det hänt förr?
- Har andra liknande verksamheter drabbats?
- Hur attraktiv är tillgången?
- Hur exponerad är tillgången?
- Ständigt pågående hot?
- Hur motiverad och välfinansierad är hotagenten?
- Hänsyn tas till fysisk säkerhet och andra funktioner i systemet som kan minska sannolikheten, t.ex. en säkerhetsventil eller arbetssätt/procedurer.
När både konsekvens och sannolikhet har räknats ut kan man använda en matris, till exempel den matris som nämnts tidigare, för att få ut den omitigerade risken.
4. Inför riskreducerande åtgärder
Då kommer vi in på vilka åtgärder man kan ta för att minska sin risk. Risker kan antingen mitigeras (genom att införa åtgärder), överföras till någon annan (t.ex. genom att försäkra sig) eller accepteras (vi lever med det och hoppas att den inte faller in). Om man väljer att mitigera risken måste man jobba vidare mot att införa lämpliga åtgärder.
I standard IEC 62443 definieras en ”trappa” av så kallade säkerhetsnivåer (eng. Security Level). Det finns fem nivåer – på dessa nivåer kan ens zoner och flöden placeras in. Syftet med de fem nivåerna är att kunna kommunicera detta på ett tydligt sätt till de som designar, implementerar och upprätthåller IT-säkerheten. Det vill säga att man kan säga att ”den här zonen ligger på säkerhetsnivå 4” och därmed vet man ett antal saker som enligt standarden ska göras. Enligt IEC 62443 kan man använda dessa punkter för att definiera vilken nivå en zon eller flöde ska hamna på:
- Skillnad mellan omitigerad risk och acceptabel risk – blir det stor skillnad mellan dessa måste man upp en säkerhetsnivå.
- Enligt definitionerna av säkerhetsnivå i IEC 62443.
- Genom att ”gissa” och göra om riskanalysen med mitigerande åtgärder och eventuellt justera säkerhetsnivån.
Vanligt är att man får jobba iterativt och ”gissa” säkerhetsnivån, göra om riskanalysen och sedan jämföra kvarvarande risk med acceptabel risk. Från säkerhetsnivån kan man senare få fram de säkerhetskrav som ska uppfyllas.
5. Bedöm reducerad konsekvens, sannolikhet och risk
När åtgärderna är införda görs en ny riskbedömning, men den här gången med åtgärderna inräknade. Den kvarvarande risken accepteras, mitigeras eller överförs. Viktigt är att det är ledningen som äger kvarvarande risk. Det vill säga, ledningen måste bli inblandad i beslutet att acceptera eller införa fler åtgärder.
6. Reducerad risk ok? Om inte, inför fler åtgärder
Om målet inte nås (målet är att endast acceptabla risker finns kvar) måste ytterligare åtgärder införas. När den reducerade risken understiger den acceptabla risken har man kommit i mål med sina riskreducerande åtgärder.
För att mitigera sina risker kan det krävas olika åtgärder. Advenica erbjuder flera lösningar för er cybersäkerhet – läs våra lösningsbeskrivningar för att lära dig mer om vad vi kan hjälpa till med!
Vill du veta mer om standard IEC 62443? Läs mer här!
Vill du läsa mer om hur du gör en säker IT/OT-integration baserad på IEC 62443? Läs vårt blogginlägg!
