Säkerhetspolicy, fem steg att skapa en för cybersäkerhet.

Säkerhetspolicy är en avsiktsförklaring för att styra beslut inom cybersäkerhet. På affärsnivå beskriver policyn för mål och tillvägagångssätt för att klara cybersäkerhet och hybridattacker.

Ulf Dellborg

Podd

Ett stridflygplan, Värmland, på meters höjd i 1150 km/h. Lågt och fort är säkert för en stridspilot. Plötligt smäller de till och flygplanet bromsas kraftigt upp. Med solen i ögonen har piloten träffat en kraftledning. Kraftledningen är av liksom strömmen för massor av människor. Piloten och flygplan klarar sig. Elnätetsoperatören får det häktisk. Försvaret tar till sig tillbudet och förbättrar säkerhetspolicy och instruktioner, kraftledningar bör passeras vid en kraftledningsstolpe.

Säkerhetspolicyn ska styra säkerheten

Med den inledande historien hoppas jag få dig som chef att förstå vikten av en säkerhetspolicy.

Jag som gammal stridspilot vet hur viktigt säkerhet är. Från toppen i organisationen till att markera kraftledningar med bred röd tusch på kartan innan flygpasset.

Här beskriver jag hur du skapar en säkerhetspolicy som ser till att piloter inte kör in i kraftledningar och som skyddar oss mot hybridattacker och felkonstruktion.

(Jag är inte bara en gammal pilot, jag är även civilingenjör som arbetat med flygsäkerhet och säkerhet i järnväg, med lång erfarenhet som konsult inom IT och ledning).

Vad är en säkerhetspolicy?

Säkerhetspolicyn för cybersäkerhet är strategin att skydda dina digitala tjänster, så att dina och samhällsviktiga tjänster fungerar. Den är strategier och policys på hög nivå som styr dina mer detaljerade operativa beslut.

Krav på en säkerhetspolicy

Policy för informationssystemens säkerhet, krav från NIS2 genomförandeförordning

Säkerhetspolicyn lägger grunden för att leda säkerhet och skapa säkerhetskultur

NIS2 kräver "Strategier för informationssystemens säkerhet", säkerhetspolicy. Säkerhetspolicyn delas i förordningen för implementation av NIS2 upp i två policys. "Policy för säkerhet i nätverks- och informationssystem" och "Policy för riskhantering".

Strategier för riskanalys och informationssystemens säkerhet skriver du i er säkerhetspolicy. Krav på ledningen (Säkerhetspolicy och resurser) finns i ISO 27001 kapitel 5.

Läs om NIS2 krav

Säkerhetspolicyn ska baseras på och komplettera nuvarande och framtida affärsmodell

Säkerhetspolicyn gör cybersäkerheten affärsdriven

Säkerhetspolicyn ska komplettera organisationens affärsstrategi och mål. Det har du tidigare definierat din nuvarande och framtida affärsmodell. Enligt ISO 27000 ska ledningen ska etablera en säkerhetspolicy som är lämplig för organisationens syfte. Den ska baseras på:

Affärsmodellen med strategi;
Regelverk och avtal;
Aktuella och förväntad hotmiljön.

Läs mer

Metod för att ta fram en policy för cybersäkerhet

Säkerhetspolicy, process enligt Cybersäkerhetslagen / NIS2, ISO 27001 & 27002

Metoden för att skapa policy uppfyller cybersäkerhetslags och ISO 27001. Den är uppdelad isex steg:

Definiera avgränsningar för säkerhetssystemet.
Definiera säkerhetsmål.
Krav mot säkerhetspolicys
Definiera , godkänn och publicera policys. Arbetet med att skapa säkerhetspolicys.
Kommunicera policy så de gör nytta.

Riskkriterierna sattes i kontextanalysen och prövades mot verkligheten vid riskbeslutspunkt 1. Här fastställs de.

1. Definiera avgränsningar för säkerhetssystemet

1.1. Avgränsa Säkerhetssystemets BIP, produkten som implementerar affärsmodellens säkerhetssystem

Du ska nu definiera säkerhetssystemets omfattning relaterat affärsmodellen. Säkerhetssystemets Business Implementing product (BIP). Det är det säkerhetssytem som skyddar hela affärsmodellen och dess tjänster. Det gör du baserat på kunskapen från steg1 till 4.

Specificera vilka värdeströmmar eller delar av värdeströmmar som säkerhetssystemet ska skydda och målen för säkerhetssystemet relaterat detta. Definiera även vad som måste fungera för att uppfylla legala krav från t ex cybersäkerhetslagen.

1.2. Avgränsa Säkerhetssystemets MVP

För att ta dig till din BIP måste du hitta steg på vägen. Första steget är att avgränsa säkerhetssystemets MVP Minimum Viable Product. Det är det minsta tänkbara säkerhetssystemet som är ett långsiktigt byggblock i det certifierade säkerhetssystemet (Säkerhetssystemets BIP).

Värdeströmmen ska väljas så att det ger intressenterna tillräcklig nytta från första stund. Syftet är att du snabbt ska "komma ut på marknaden", säkerhetssystemets marknad. Tänk på att det ska vara reviderbart. Det är så du kan lära dig mer och fatta välgrundade beslut för hur säkerhetssystemet ska vidareutvecklas.

1.3 Avgränsa BIP och MVP mot Cybersäkerhetslagen och NIS2 genomförandeförordning / ISO 27001 / ISO 61508

I sista steget bestämmer du hur stor del av kraven i ISO 27001 du vill implementera i din MVP.

Gör en kompletterande analys enligt punkt 1-3 inom denna avgränsning och definiera vilka krav från ISO-27001 som säkerhetssystemets BIP skall implementera och specificera hur dessa skall tillämpas

2. Definiera säkerhetspolicyns säkerhetsmål

2.1. Säkerhetsmål, vad är det?

Säkerhetsmål i säkerhetspolicyn för att uppnå cybersäkerhet i affärsmodellen

SWOT-analysen satte styrkor, svagheter, möjligheter och hot. TOWS-analysen strategin för att ta dig framåt. Baserat på dessa analyser sätter vi specifika, mätbara, uppnåeliga, relevanta och tidsbestämda mål för säkerhet.

Om du identifierar en svaghet i IT-säkerheten med en ökad risk för cyberattacker, kan ett mål vara att genomföra en säkerhetsutbildning för alla anställda inom ett år. Ska du skydda dig mot hybridattacker som den i det inledande exemplet krävs mål som rör samarbete med andra aktörer.

2.2. Gå igenom de farliga händelser och beskriv hur de hindras

NIS2, CER, DORA, lagar för att skydda samhällets funktion

Riskanalys är att analysera inträffade risker för förbättring av riskhanteringen

När jag som pilot gjorde riskanalys inför flygning frågade jag mig "Var är risken stor att jag krockar med en fågel?", vare sig kul för mig eller fågeln! Eller, "Var kan jag köra in i kraftledningar?", vare sig kul för mig eller elkonsumenter! Det var en anlys ur ett allriskperspektiv, för att hitta faror för mig eller andra. Utifrån detta vidtog jag åtgärder.

I den preliminära riskanalsen hittade du alla faror, dina outcomes. Du knöt dem mot din organisations viktigaste processer. Nu skall du sätta upp strategier för att optimalt åtgärda riskerna och knyta dem mot dina mål.

2.3. Analysera en fara/risk i taget

Regelverk med krav på säkerhet: Cybersäkerhetslagen, NIS2, DORA, AI, CER

Cybersäkerhetslagen, NIS2, DORA, AI, CER säkrar att samhället fungerar

Det första steget är att analysera syntesen från prelimära riskanalysen. Analysera en risk i taget, ett resultat (Outcome) i taget. Syftet är att hitta hur de farliga händelserna i händelsekedjan mot resultatet kan stoppas.

Lägg outcomes i centrum för den inre rutan och händelsekedjan runt denna. Lägg sedan i yttre rutan de arbetssätt du ska använda för att bryta händelsekedjan.

Tänk på, nu kommer du märka att du missat en del händelser, fyll på med dem. I slutändan kommer du behöva gå igenom varje resultat igen och komplettera.

2.4. Vårdkaos är att exempel som blockeras med sex strategier

Säkerhetsanalys av scenariot vårdkaos med säkerhetsstrategier och säkerhetsmål

För gipsat.nu visar modellen att normal IT-säkerhet inte är tillräcklig mot moderna hybridhot. Du måste lägga till Safety by design, rimlighetskontroller och agilt samarbete för att säkra funktionen.

Med t ex "Vårdkaos" i centrum så har gipsat.nu "Safety by design" och "Skydd mot skadlig kod (27002, 8.7)" som strategi mot "Falsklarm p g a skadlig mjukvara" . Agilt samrbete skyddar sjukhusets planeringssytem.

2.5. För gipsat.nu är det sju analyser för att hitta strategier för riskhantering

Strategier pch säkerhetsmål för att hantera riskerna i riskmatrisen

Nu återstår att presentera dina strategier i en samlad bild. risker i en samlad Lägg outcomes i centrum för den inre rutan och händelsekedjan runt denna. Lägg sedan i yttre rutan de arbetssätt du ska använda för att bryta händelsekedjan.

Tänk på, nu kommer du märka att du missat en del händelser, fyll på med dem. I slutändan kommer du behöva gå igenom varje resultat igen och komplettera.

2.6 Prioritera bland strategierna

Nu har ni strategier mot varje risk, men ni kan inte införa allt på en gång. Risklistan räcker inte som ordning — en strategi adresserar flera risker, och en risk kräver flera strategier. Tar man riskerna uppifrån undervärderas de bredverkande strategierna, som ofta är de bästa.

Därför en prioriteringsmatris. Den är också ledningens underlag: NIS2 artikel 20 kräver att ledningsorganet godkänner riskhanteringsåtgärderna, och godkännandet blir meningsfullt först när det framgår varför just dessa strategier, inte bara att de finns. Så här tas prioriteringsmatrisen fram:

Ställ först upp riskerna med sina WPRF-poäng i raderna och de strategier ni överväger i kolumnerna. I varje cell skattar ni hur stor del av risken strategin tar bort, mellan 0 och 1.

Sedan sätts strategins värde till summan av riskpoäng gånger täckningsgrad över alla risker den rör.

Strategins värde = Σ ( riskpoäng × täckningsgrad )

Skattningen är grov och det är i sin ordning. Poängen är att en strategi som tar bort en femtedel av tre risker slår en som tar bort hälften av en.

Slutligen divideras värdet med insatsen, organisationens förändringskapacitet. En policy som kräver att fyrahundra personer ändrar arbetssätt är dyr även om den inte kostar en rad kod.

- Prioriteringsmatrisen för gipsat.nu

För Gipsat.nu gav den preliminära riskanalysen tre risker över tröskeln. Ställda mot de strategier som togs fram i 2.3, 2,4 och 2.5 ser matrisen ut så här:

	Vårdkaos 3,90	Patient får inte vård 3,80	Brott mot patientdatalagen 3,60	Värde
Safety by design	0,4	0,3	0,2	3,4
Rimlighetskontroll av resultat	0,4	0,2	–	2,3
Agilt samarbete med partners	0,3	0,1	–	1,6
Skydd mot skadlig kod (27002 8.7)	0,3	0,1	–	1,6

Safety by design vinner trots att den inte tar bort mest av någon enskild risk — den rör alla tre. Agilt samarbete och skydd mot skadlig kod hamnar lika i värde, men skiljer sig kraftigt i insats: det ena kräver att två organisationer ändrar arbetssätt, det andra är ett inköp och en konfiguration.

3. Sätt krav mot policyerna

3.1 Principer är policyns innehåll

I ArchiMate är en princip en kvalitativ avsiktsförklaring som arkitekturen ska uppfylla. Det är precis vad en policyskrivning är, och därför modelleras säkerhetspolicyn som en uppsättning principer.

Ett krav är något som måste realiseras. Här sätts kraven mot principerna: kravet är beställningen, principen är leveransen.

Håll isär två sorters krav. Ett krav mot en princip säger vad policyn ska innehålla. Ett krav mot systemet säger vad som ska byggas. Båda är Requirements i modellen, men de realiseras av olika saker — det första av en princip, det andra av en komponent. Systemkraven hör hemma i säkerhetskravsartikeln.

3.2 Fyra källor till kraven

Varje krav ska gå att spåra till sitt ursprung. Strategierna från 2.5. Varje prioriterad strategi ska bäras av minst en princip. Strategierna kommer från två håll, TOWS-analysen i kontextanalysen, som parar styrkor och svagheter mot möjligheter och hot, och riskanalysen, som pekar ut vad som måste hanteras. Prioriteringsmatrisen väger dem mot varandra oavsett ursprung.

Riskerna. En risk över tröskeln som ingen princip adresserar är en lucka. Kontrollen går åt båda håll: från risk till princip, och från princip tillbaka till den risk den finns för.

Regelverken. Genomförandeförordningen och cybersäkerhetslagen kräver att vissa områden är reglerade oavsett vad er riskanalys visat. De kraven är ofrånkomliga och ska märkas som sådana.

Intressentkraven från kontextanalysen. Vad kunder, partners och myndigheter kräver av er, som inte alltid syns i riskanalysen.

3.3 Bygg modellen först, skriv sedan

Bygg en modell av de principer som ska finnas, innan någon formulerar text. Knyt varje krav till sin princip och varje princip till sitt ursprung.

Först då skrivs själva formuleringarna. Det är samma ordning som i riskanalysen: relationerna avslöjar vad som saknas, och de avslöjar det innan någon lagt tid på att skriva.

ISO 27002 kapitel 5 är användbar som kontroll av att ni täckt de organisatoriska områdena — roller och ansvar, informationsklassificering, leverantörsrelationer, incidenthantering. Läs den i efterhand, inte som en meny att välja ur. Det är riskerna och regelverken som styr vad ni behöver.

3.4 Tre kontroller i modellen

När principerna och kraven är modellerade går tre saker att se direkt.

Princip utan krav. Ingen har beställt den. Antingen finns ett krav som inte skrivits ner, eller så är principen ett arv från en tidigare policy. Det andra är vanligare.

Krav utan princip. En lucka i policyn. Något ni bestämt ska gälla har ingen skrivning som bär det.

Strategi utan princip. Prioriteringen i 2.5 fick inget genomslag. Ni valde en inriktning och styrde sedan inte mot den.

Det är samma sorts kontroll som de tomma fälten i riskanalysen, och den fungerar av samma skäl: en relation som saknas syns, medan en tanke som aldrig tänktes inte gör det.

3.5 En princip ska gå att bryta mot

Ett krav som inte går att kontrollera är en förhoppning.

"Resultat i säkerhetskritiska flöden ska rimlighetskontrolleras mot förväntat utfall" går att kontrollera. "Systemen ska vara säkra" gör det inte.

Det är också vad säkerhetsbeviset vilar på. Principen säger vad som ska gälla, systemkraven vad som ska byggas, testerna att det gör det. Bryts kedjan någonstans går efterlevnaden inte att visa.

3.6 Avstegsvägen

En policy utan undantagsväg kringgås i stället för att följas.

Varje princip ska därför ha en angiven väg för avsteg: vem som begär, vem som prövar, vem som godkänner, och var beslutet dokumenteras. Avsteg som godkänns blir kvarvarande risk, och de hamnar på den lista ledningen ska se.

Cockpit-exemplet i säkerhetskravsartikeln är ett sådant avsteg: MFA väljs bort för transportledningen, med kompenserande åtgärder och ett dokumenterat beslut. Utan avstegsvägen hade det antingen inte gjorts, eller gjorts tyst.

4. Definiera, godkänn, publicera säkerhetspolicy

Process för att agilt skapa säkerhetspolicy

Nu ska säkerhetspolicy och ämnesspecifika policys tas fram. Du ska ta fram processer som den för riskhantering samt teknisk styrning, som t ex att beptövan teknik ska användas i säkerhetskritiska system. Använd exempel och scerior som det om hybridattacken.

Sno någon annans policy och applicera dina krav. Detta görs i modellen, den du hittils sakta byggt upp. På detta sätt fås spårbarhet mot affärsmodellen och kontext.

Läs mer

5. Kommunicera policys

Sista steget är att kommunicera dina policys. Använd en kombination av kanaler för att nå olika målgrupper. Intranät, medarbetarmöten, utbildningar och personlig kommunikation är exempel:

Genom att involvera medarbetare i utvecklingen och implementeringen av policyn startar du kommunikionen. Det beöver sedan informeras och utbildas i den. Genom att sedan i förändringsarbetet hela tiden knyta krav mot polycyn så hålls den levande i det dagliga arbetet.

Nyttan av en säkerhetspolicy

I början av artikeln fanns två scenarier: piloten som flög in i kraftledningen, och hybridangreppet mot elnätet. Vad hade en säkerhetspolicy gjort för skillnad?

Kraftledningen. Försvaret hade en policy som sa att man flyger lågt och fort. Efter tillbudet kom en till: kraftledningar passeras vid en stolpe. Det är hela poängen med en princip på en rad — den är kontrollerbar, den går att bryta mot, och den fanns i huvudet på nästa pilot som flög samma sträcka.

Elnätsoperatörens sida av samma händelse är mindre uppbygglig. Frågorna de borde ha kunnat svara på: var ledningen och ställverken skyddade, fanns redundans, hade avbrott på ledningar analyserats. Om svaret krävde en utredning fanns ingen policy.

Hybridangreppet visar samma sak på systemnivå. Var det nya balanseringssystemet moget för drift? Var teknik som aldrig använts i säkerhetskritiska system ett bra val? Fanns loggar så att det gick att spåra varför det gick ned? Hur skulle IT-systemen återställas med flera nyckelpersoner sjuka?

Varje fråga motsvarar en princip som antingen fanns eller inte fanns. Beprövad teknik i säkerhetskritiska system. Spårbarhet i drift. Ersättare för nyckelroller.

Och det angreppet visar något policyn ensam inte löser. Magsjukan spreds via vattennätet, elnätet slogs ut, och personalen var sjuk samtidigt. Ingen av organisationerna kunde ha analyserat sig fram till helheten var för sig. Det är därför NIS2 artikel 21.2 d handlar om leverantörskedjan, och därför säkerhetspolicyn måste innehålla krav på samverkan med dem ni är beroende av.

Vad policyn gör, konkret. Den gör beslut fattade i förväg. När något händer behöver ingen komma på vad som gäller — det är bestämt, och det är bestämt av någon som hade tid att tänka.

En policy som inte gör det är en avsiktsförklaring. Skillnaden märks bara den dag den behövs.