IT-säkerhet enligt HPS

Det är en gammal sanning att hävda att säkerhet är riskhantering. Inget ont om det. Riskanalys däremot, en av de gängse metoderna för att hantera risker, hur det med dem? Är riskanalys verkligen en bra idé?

Riskanalys i teorin
Riskanalyser genomförs i bl a utvecklingsprojekt i syfte att avgöra vilken typ och nivå av "säkerhet" som behövs för att uppnå en "tillräckligt låg risknivå". Först, låt oss normalisera våra begrepp. Vi håller det enkelt och nöjer oss med att


där KONSEKVENS är den negativa effekten av att något (i regel oönskat) inträffar och SANNOLIKHET är, ja, sannolikheten att det inträffar. RISK defineras sedan helt enkelt som produkten av dessa, d v s det är en uppskattning av hur ofta något slår och hur hårt det slår.

Riskanalys i praktiken
Ett riskanalysarbete kan innefatta att en samling personer som har kunskaper om ett analysobjekt, ett mailsystem t ex, sätter sig runt ett bord och brainstormar scenarier som kan leda till oönskade konsekvenser för att sedan bedöma sannolikheten att de inträffar. Idéer diskuteras fram och tillbaka, vissa saker kommer man överens om, vissa inte. Ofta utmynnar arbetet sedan i en lista på scenarier, konsekvenser, sannolikheter och riskvärden, sorterade efter de senare. Projektet ska sedan använda denna lista för att prioritera i säkerhetsarbetet.

Riskanalys i verkligheten
Det finns två relativt uppenbara problem med riskbegreppet som det är definierat ovan: (1) hur bedömer vi konsekvensen? och (2) hur bedömer vi sannolikheten?

Konsekvensproblemet
Konsekvensproblemet är enklast att förklara. För analysobjektet mailsystem, tänk scenariot angripare skickar mail med vår domän som avsändare. En rimlig och fullt tänkbar risk (ibland används begreppet risk slarvigt såhär). Vad är konsekvensen av detta för oss som företag? Redan här stöter vi på problem; konsekvenserna kan vara flera beroende på vad mailet ifråga innehåller och vem det skickas till.

Scenariot måste specificeras; angripare skickar mail till vår kund och utger sig för att vara oss. Det är för öppet, vi kan fortfarande inte bedöma konsekvensen. Vad sägs om angripare lurar till sig kundens lösenord genom att utge sig för att vara oss. Mja, vi är fortfarande inte där, vad kan de göra med lösenordet? Sabba för kunden? Tappar vi kundens förtroende då? Tappar vi kunden? Vad innebär det? Här börjar vi närma oss konsekvensen.

Det stämmer ju att den enda konsekvens ett företag bryr sig om är den som kan mätas i någon valuta. Förutom i enstaka fall är det generellt slöseri med tid att sikta på monetära konsekvenser. Istället brukar man falla tillbaka på någon diskret skala i stil med obetydlig, lindrig, betydlig och allvarlig för att göra bedömningen.

Konsekvensproblemet är att medan vi närmar oss ett tillräckligt specifikt scenario där konsekvensen är möjlig att uppskatta förlorar vi täckning. Det är tydligt ovan att lura till sig lösenord är en specificering av attacker som involverar att spoofa avsändardomäner i mail. Vi täcker inte lika många scenarier helt enkelt, nu måste vi t ex också ta ställning till vad som händer om mailet till kunden ovan syftar till något annat eller är riktat till en leverantör istället.

Att vi behöver specifiera oss så här gör att processen tar längre tid, att det resulterar i mera utdata, att det blir svårare att överblicka o s v. Det är inte mycket att göra åt. Så är det när man arbetar med komplicerade system. Konsekvensproblemet är inte allvarligt, bara jobbigt.

Vi tar sannolikhetsproblemet i en uppföljande post. Fortsättning följer...

--
Stefan Pettersson