Säkerhet i rätt ordning 

Om vill vi vara stringenta så är ”informationssäkerhet” det begrepp vi ska arbeta med. Den gamla svenska definitionen är fortfarande högst relevant. Här är en väldigt bra bild från SIS TR50:2015: 

Bildkälla: Swedish standards institute  - Terminologi för informationssäkerhet

Som vi kan se av bilden är inte informationssäkerhet och it-säkerhet två halvor av verksamheten. Informationssäkerhet består bland annat av it-säkerhet och fysisk säkerhet. Orsaken till att det hänger ihop på det sättet är att vi måste börja med att definiera VAD som ska skyddas. Även om det som ska skyddas inte alltid är information, så är det vitalt att ha information OM det som ska skyddas. Förslagsvis är det bra att kartlägga vilka krav som ställs på konfidentialitet, riktighet och tillgänglighet för respektive process, verksamhet, system, tjänst, produktionsenhet, etc. 

Innebär detta att alla som jobbar med cyber- eller it-säkerhet gör fel? Nej! Det innebär dock att de som fokuserar på cyber- eller it-säkerhet löper risk att göra saker i fel ordning och därigenom har för dålig eller för dyr säkerhet. 

Vad är då rätt ordning? 

Rätt ordning 

Säkerhetspolisen har en oerhört pedagogisk bild över hur säkerhetsarbete ska bedrivas: 

Bildkälla: Säkerhetspolisen: Vägledning i säkerhetsskydd - Introduktion till säkerhetsskydd

Av någon outgrundlig anledning börjar de flesta (inte ni, förstås…) organisationer med nedre vänstra segmentet. De rusar iväg och köper en massa säkerhetshöjande attiraljer, tjänster och tekniska lösningar med en ganska dimmig uppfattning om vad som ska skyddas och mot vad. Det enda som alla är överens om är att det är bråttom. (Måste säkra it-miljön! Nu!) 

Detta leder till att de kommer att ha en säkerhetsnivå som inte motsvarar verksamhetens behov och krav. Alltså, för dyr eller för dålig säkerhetsnivå. 

Det är klart att vissa lösningar (brandvägg, backuplösning, krypterade arbetsstationer, mfl) är ”no-brainers”, dvs där behövs inte så mycket eftertanke, det är bara att köra. Det är när kunderna börjar köpa mer avancerade (=dyra) säkerhetslösningar som de får problem om de inte vet vad som ska skyddas och mot vad. 

Ett av många exempel är en SOC/SIEM-lösning för en offentlig verksamhet. När en SOC/SIEM-lösning sjösätts så brukar det första vara att sätta upp blandade loggar/larm för den tekniska servermiljön utifrån någon form av ”best practice”, vilket är helt rimligt. Men så fort det är dags att fundera över logg/larm för dedikerade tjänster, applikationer eller lagring, så uppstår intrikata frågor som: 

• Vilken information får vi inte spara alls? Hur ofta måste vi rensa? Vilken information måste vi spara? Hur länge? Vilka lagar påverkar? 
• Hur vet vi vilka maskiner (logiska och fysiska) och applikationer som är mest kritiska? Vilka verksamhetskrav ska vi leva upp till? Vad kräver det från vår SOC/SIEM? 
• Vilka typiska hot skall vi skydda oss mot? Hur vet vi det? Hur loggar och larmar man för att möta dessa hot? 
• Vilka risker är störst? Gäller det alla våra miljöer? Om inte, hur vet vi vilka miljöer som kräver vilken typ av loggning? 
• Till vem ska vi eskalera vad och när? Hur vet vi att det är en händelse som måste rapporteras till en myndighet? Finns det en incidentprocess som ska följas? Hur vet vi vilka incidenter som hör till vilken process? Vad ställer respektive myndighet/lagstiftning för krav på loggning för rapporteringen? Hur snabbt måste rapportering ske? 

Liknande frågeställningar uppstår i många andra situationer där tekniska åtgärder ska implementeras, allt från fysiskt skydd via backuplösning till MFA. För att svara på de flesta av dessa frågor, så behöver vi börja i rätt ordning, dvs: 

1. Vad ska skyddas? 
2. Mot vad ska det skyddas? 
3. Hur ska det skyddas? 

Är det svårt? 

Det är lätt att tro att det är väldigt svårt att göra de två första stegen eftersom så många går direkt på steg tre. Nej, det är inte svårt. Det finns massor av bruksanvisningar ni kan ladda ned från blandade myndigheter. Ni kan be lämplig leverantör om hjälp. Ni kan följa de första fem kapitlen i 2017 års version av ISO27002. I mångt och mycket så är det en ”vanlig jädra förstudie”. 

Det som är nyckeln är att få verksamheten att förklara för interna och externa leverantörer vad som faktiskt är skyddsvärt. Detta är ingen it-fråga, det handlar om att verksamheten måste formulera sig tydligt. Den ideala situationen är att ni har en CISO som agerar tolk i triangeln verksamhet-ledning-it och ser till att korrekt formulerade krav utifrån företagets verksamhet, riskaptit, förlusttolerans och budget kommer fram till rätt ställe. 

Hur gör ni då? (Lite förenklat) 

1. Lagkravsanalys. Lämpligen i workshopform med representanter från verksamheten. 
2. Verksamhetskravanalys. Lämpligen i workshopform. Kom ihåg att göra det på lagom hög nivå. Kostnaden ökar exponentiellt med granulariteten. 
3. Informationsklassificering. Även här är det viktigt att inte vara för detaljerad. Det finns sätt att förenkla processen, exempelvis att göra den generellt på processnivå och komplettera med de objekt/system/verksamheter som behöver hanteras som undantag. 
4. Hotbildsanalys. Allt underlag ni behöver kan ni hitta på olika myndigheters hemsidor. Kruxet är att koka ned diverse hotbilder till konkreta saker. En annan svårighet är att ni måste komma ihåg de hotbilder ni ”ärver” från era kunder, samarbetspartners, verksamhetsområden, omgivning, etc. Ligger din datorhall 50 m från staketet runt flygplatsen? Det påverkar nog din hotbild. 
5. Risk- och konsekvensanalys. Det är ett trubbigt verktyg om ni försöker använda det som investeringsunderlag, däremot är det ett utmärkt sätt att prioritera sina åtgärder. Kom också ihåg att risker är irrelevanta när vi pratar Säkerhetsskydd, där är det konsekvensanalysen som styr. 

Varför görs inte saker i rätt ordning? 

Ofta är det en kombination av olika orsaker. Mina erfarenheter, gränsande till fördomar, visar bland annat på följande orsaker: 

• Organisation. Ofta är säkerhetsorganisationen uppbyggd så att det maximerar revirkonflikter, intressekonflikter och ineffektivitet. Mandat, mätning, förankring och förvaltning minimeras. Ansvar, mandat och rollfördelning är ofta otydligt. Inte avsiktligt förstås, men av okunnighet. 
• Bristande insikt om att det är viktigt. Media och leverantörer fokuserar mycket på IT-säkerhet och Cyber-säkerhet, väldigt sällan pratas det om verksamhetsfrågor. Ett tydligt undantag är offentliga sektorn kontra molntjänster, Schrems II, etc. 
• Ovana vid frågorna. Triangeln verksamhet-ledning-IT är ofta ovan vid dialog kring verksamhetskrav när det gäller säkerhet. 
• Det finns en tro att det går långsammare. Möjligen är det en riktig analys, men det är egentligen bara när det gäller det logiska skalskyddet som ledtid är viktigare än kvalitet. 
• ”Instant reward”. Det är lättare att bli hjälte när någon kan peka på en kartong och säga ”I den lådan så ligger lösningen på säkerhetsproblemen X, Y och Z”. Den som pekar på att ”Om vi gör våra förstudier så vet vi bättre vilka krav vi ska leva upp till” blir sällan hjälte. 
• Strutsbeteende. Om huset brinner ned så är det svårt att hävda att det inte hänt något. När någon inte följer upp sin säkerhet, så att de inte vet att de dagligen utsätts för intrång i IT-miljön så är det enkelt att blunda. Ett autentiskt citat från en stor svensk organisation: ”Men vi vill ju inte fråga om saker där vi vet att svaret är nej, då får vi ju ett dåligt resultat”. 

Kontentan 

Beroende på var du är i organisationen så kan du påverka säkerheten på olika sätt, men ett generellt råd är att ständigt upprepa frågorna: ”Har vi gjort förarbetet? Vet vi VAD som ska skyddas? Vet vi MOT VAD det ska skyddas?” så fort någon pratar om att köpa säkerhetslösningar.