Praktiska riskanalyser, erfarenheter och lärdomar från it-landskapet (del 2 av x)

Detta är andra inlägget i min redogörelse för hur jag arbetar med riskanalyser på riktigt i min roll som säkerhetsspecialist. Idag tänker jag beskriva min nuvarande metod för att genomföra en riskanalys.

De klassiska riskekvationerna

Riskanalyser har sedan begynnelsen beskrivits genom två perspektiv, det kvantitativa och det kvalitativa. Historien går något i stil med att kvantitativa metoder för riskanalyser utgår ifrån bestämda värden på tillgångar, uppskattar kostnad vid förlust (Single Loss Expectancy, SLE), antalet gånger (Annual Rate of Occurence, ARO) per år man kan förvänta sig att detta händer och sätter detta i relation till kostnaden för en åtgärd.

Det är komplicerat, fullt av uppskattningar och gissningar samtidigt som det döljer eller helt missar andra viktiga detaljer och det är ungefär här den kvalitativa-metoden tar vid. I det kvalitativa perspektivet talar vi istället om relativa risker vars värden oftast beskrivs genom ekvationen risk = sannolikhet x konsekvens.

Problemet med den kvantitativa metoden är att det oftast är väldigt, om inte omöjligt, att göra bra uppskattningar på värdet av en tillgång, speciellt när det handlar om information eller data. Den kvalitativa metoden har givetvis också negativa sidor och härstammar ur det ickediskriminerande och relativa värdet mellan risker. En risk med värde 16 och en annan risk med värde 16, säger ingenting om vilken som bör prioriteras.

Världen är nyanserad och det handlar om att vara pragmatisk. Jag tycker inte någon av dessa fungerar speciellt bra och har istället valt att försöka göra något som, åtminstone för mig, är vettigare och vars resultat ger mig något konkret att arbeta med efter analysen.

Riskanalys 2.0

Ett av mina kanske största problem med “vanliga” riskanalyser är bristen på detaljer om hur man gjort en given bedömning. Jag har vid flertalet tillfällen valt att helt ignorera sannolikhetsbedömning då jag anser att en gissning kan vara farligare än att inte säga något alls. Det är också i detta som mina åsikter tydligen skär sig mot andras så tillåt mig nu att förklara min enkla metodik.

Analysobjektet

Låt oss anta ett exempel i vilket vi ska analysera ett it-system. Det allra första som måste definieras är analysobjektet och lämpliga avgränsningar. I modern cyclebeskrivningen av analysobjektet vill jag veta följande:

1. Vilken verksamhet ska använda systemet?
   1. Vilka är användarna?
   2. Vilken information behandlas?
2. Vilka gränssnitt används för att interagera med it-systemet?Fysiskt, vart befinner sig användarna?
   1. Stationära datorer?
   2. Bärbara datorer?
   3. “Mobila” enheter? (Tänk mobiltelefoner eller plattor)
3. Var befinner sig användarna fysiskt?
4. Vilka systemberoenden finns?
   1. Datalagring
   2. Informationstjänster (Tänk webservices)

Utifrån detta försöker jag skapa mig en mental karta över “intressanta” kopplingar som skulle kunna leda till mindre önskvärda händelser. Konstatera vilka avgränsningar som gäller, och vilka delar som inte ska beaktas samt vilka antaganden som görs.

Tillgångar, aktörer och målsättningar

När det finns en någorlunda vettig beskrivning vad vad som faktiskt ska analyseras och således sätter gränserna för hur långt fantasin behöver gå är det dags för att bli något mer konkret. Tillgångarna styr i stor utsträckning vilka aktörer som behöver beaktas och således vilka hot som kan realiseras.

Tillgångarna

Tillgångar kan vara allt från det uppenbara som t.ex. kundregister, källkod, bokslut och många andra immateriella tillgångar. Det kan också vara saker som åtkomst. Tänk dig en administrationszon i ett näverk från vilket samtliga system kan nås. Det är en tillgång som måste skyddas. I vårt fall kanske det handlar om ett it-system som ska användas för VPN-förbindelser.

Aktörerna

Aktörerna är en av de få saker jag sällan ser i analysrapporter och något jag försöker förändra. Ofta får vi lösrykta beskrivningar som hackare, den grova organiserade brottsligheten eller terrorist. Faktum är att de aktörer som vi behöver beakta i våra hotscenarier är precis de som kan tänkas vara intresserade av våra tillgångar som identifierades tidigare.

Varje aktör kan beskrivas genom ett antal egenskaper som t.ex. riskbenägenhet, kompetens, resurser osv. Sammantaget ger aktörsbeskrivningarna underlag för att senare kunna bedömma sannolikheten, och konsekvensen för ett givet hot. Jag har valt att beskriva aktörer i två dokument (a) en övergripande excelmatris i vilken relevanta aktörer och deras egenskaper beskrivs samt (b) en detaljerad aktörsbeskrivning där motivering till varför en aktör bedöms på ett givet sätt.

Nivån på detaljer avgörs lite av vilken typ av organisation man tillhör. Försvarsmakten har t.ex. en större och mer allvarlig hotbild än Berras korvmojj. Det finns dock hotaktörer även mot korvmojjen, men… låt oss diskutera det vid ett annat tillfälle.

Målsättningarna

Denna del är kanske inte alltid nödvändig att genomföra, men jag föredrar att lämna så lite som möjligt öppet för tolkning. Syftet med att beskriva målsättningarna är att ur en angripares perspektiv försöka komma så nära en realistisk målsättning som möjligt. Vi kan sällan till 100% förstå varför någon gör vad de gör, men vi kan se delar av deras målsättning. Vi kanske inte vet exakt varför någon vill åt kunddatabasen, men vi kan förstå att dom vill det. Därför skulle en målsättning kunna vara “Få åtkomst till kunddatabasen.”

För en VPN-koncentrator skulle målsättningen kunna vara något i stil med “Få möjlighet att ansluta till tredje-part”. Föreställ dig en traditionell supply-chain i vilken en underleverantör ansluter genom VPN till ett större företag för att komma åt nödvändiga it-system. Vi kanske inte vet exakt varför, men kan tänka oss att en angripande aktör vill utnyttja åtkomsten från vår VPN-koncentrator för att ansluta till “tredje part”.

Målsättningarna sätter med andra ord lite mer färg på ett hotscenarie. Det handlar om att försöka måla upp en realistisk bild av varför ett givet hot kan bli aktuellt och varför det behöver adresseras genom någon lämplig åtgärd.

Nästa gång…

Det här inlägget blev visst lite långt, så jag får dela upp inlägget. I nästa inlägg kommer jag skriva om primärhot, eller grundhot, hur dessa leder till mer detaljerade hot och attackvägar, samt hur jag försöker bedöma sannolikhet och konsekvens.

// Christoffer Strömblad
Informationssäkerhetskonsult SAFESIDE SOLUTIONS AB