Safety & Security by design, NIS2 efterlevnad DevSecOps

Artikeln betonar att en säkerhetspolicy är ett fundamentalt styrdokument och en strategisk avsiktsförklaring för en organisations cybersäkerhetsarbete. Den fungerar som en kompass som vägleder beslut och säkerställer att hela organisationen arbetar mot samma mål för att skydda sina digitala tillgångar och tjänster. Policyn ska vara direkt kopplad till organisationens affärsmodell, riskbild och de lagkrav som finns. Artikeln använder talande exempel, som ett stridsflygplan och ett fiktivt hybridangrepp, för att illustrera hur en tydlig policy skapar förutsättningar för snabb och korrekt respons vid en kris.

Den stegvisa metoden för att skapa en säkerhetspolicy

Artikeln presenterar en strukturerad process i flera steg för att utveckla och implementera en effektiv säkerhetspolicy:

1. Skapa strategi med TOWS-analys: Utifrån en tidigare gjord SWOT-analys (styrkor, svagheter, möjligheter, hot) skapas konkreta strategier. Exempelvis kan man använda organisationens styrkor för att möta externa hot.

2. Definiera säkerhetsmål: Baserat på strategierna sätter man upp specifika, mätbara, uppnåeliga, relevanta och tidsbestämda (SMART) mål för säkerhetsarbetet.

3. Sätt krav mot policyer: Konkreta säkerhetskrav definieras för att styra mot målen. Här kan man ta hjälp av etablerade ramverk som ISO 27002 för att identifiera relevanta säkerhetsfunktioner och kontroller.

4. Definiera, godkänn och publicera policyer: Den övergripande säkerhetspolicyn, samt eventuella underliggande och mer detaljerade policyer, skrivs, godkänns formellt av ledningen och publiceras så att den blir tillgänglig för alla berörda.

5. Kommunicera policyer: Det räcker inte att publicera en policy; den måste aktivt kommuniceras ut i organisationen för att säkerställa att den blir förstådd, accepterad och efterlevd.

Kontext enligt Cybersäkerhetslagen och ISO 27000

Att ha en fastställd säkerhetspolicy är inte bara god praxis, det är ett direkt krav från både lagstiftning och internationella standarder.

• ISO 27001: Standarden kräver explicit (i kapitel 5.2) att ledningen ska fastställa en informationssäkerhetspolicy. Denna policy måste vara anpassad till organisationens syfte, inkludera säkerhetsmål och visa på ett åtagande att uppfylla krav och ständigt förbättra säkerhetsarbetet. Hela metoden som artikeln beskriver är i linje med kraven i ISO 27001 för att skapa och underhålla en sådan policy.

• Cybersäkerhetslagen (NIS/NIS2): Lagen kräver att organisationer vidtar lämpliga tekniska och organisatoriska åtgärder för att hantera risker. En central sådan åtgärd är att ha just en säkerhetspolicy och strategier för informationssystemens säkerhet. Policyn blir det formella beviset på att ledningen tar säkerhetsfrågorna på allvar och har en plan för hur organisationens tillgångar ska skyddas, vilket är kärnan i vad lagen syftar till att uppnå.

Det innebär att säkerhetskrav (Security) och funktionssäkerhet (Safety) integreras som en kärnfunktion i systemets hela livscykel. Istället för att se säkerhet som en efterhandskonstruktion, blir det en del av arkitekturen från dag ett.

Safety skyddar människa och miljö från fel i systemet (t.ex. att ett bromssystem inte slutar fungera). Security skyddar systemet från externa angrepp (t.ex. att en obehörig tar kontroll över bromssystemet). I moderna uppkopplade system är de två sidor av samma mynt.

Erfarenheten är att det är många gånger dyrare att rätta ett stort arkitekturfel i ett driftsatt system än att åtgärda det under designfasen. Genom att eliminera sårbarheter tidigt minimerar ni den tekniska skulden.

V-modellen säkerställer spårbarhet. För varje krav på vänstersidan (design) finns en motsvarande kontroll på högersidan (verifiering). Det gör att ni kan bevisa att systemet faktiskt är så säkert som ni lovat kunderna och myndigheterna. Och, man kan vara agil i V-modellen.

NIS2 ställer uttryckliga krav på säkerhet vid förvärv, utveckling och underhåll av nätverks- och informationssystem. Det innebär att organisationer som omfattas av lagen måste kunna visa upp processer för säker utveckling och sårbarhetshantering.

Ja, men AI:n är en assistent, inte arkitekten. AI-genererad kod innehåller ofta sårbarheter. Genom att använda Security by Design sätter ni de arkitektoniska ramarna som AI-verktygen måste hålla sig inom, och mänsklig expertis verifierar resultatet.

Det är en grundprincip som innebär att varje del av systemet bara har tillgång till den information och de funktioner som är absolut nödvändiga för dess uppgift. Detta begränsar skadan dramatiskt om en del av systemet skulle bli komprometterad.

Ett system är aldrig starkare än sin svagaste länk (ofta en underleverantör eller ett öppet källkodskomponent). Security by Design innebär att ni ställer krav på era leverantörers utvecklingsprocesser och har rutiner för att hantera sårbarheter i tredjepartskod.

Det mäts genom regelbundna risk- och sårbarhetsanalyser, penetrationstester och genom att verifiera att systemet uppfyller de definierade säkerhetsmålen i V-modellen. Det är en kontinuerlig process, inte en engångshändelse.

Börja med att göra en kontextanalys och definiera era kritiska tillgångar. Ension hjälper er att sätta upp ramverket, utbilda ledningen och implementera de processer som krävs för att gå från reaktiv brandsläckning till proaktiv kontroll.