Behov ställs mot teknik

Transkript

1 1

2 Behov ställs mot teknik Introduktionsföreläsningen gick igenom lite grundläggande begrepp för säkerhet (konfidentialitet, integritet och tillgänglighet) som beskriver olika sätt ett system eller tillgångar kan påverkas av externa personer. I normalfallet så försöker man skydda sig med någon form av teknisk lösning, t.ex. en brandvägg, olika former av kryptering, osv. Men hur vet man vad för lösning man ska ha? Vilken lösning är det som ger bäst resultat gentemot dess kostnad? Att systematiskt utröna vilka säkerhetsmekanismer man ska investera i är vad vi ska gå igenom i den här föreläsningen. Vad vi vill att ni ska ta med er från den här föreläsningen är att informationssäkerhet inte bara är tekniska lösningar, för att kunna installera sådana bör man först och främst veta vilka behov man har och om det är värt att inkludera flera system i det man vill skydda. 2

3 Vad serien illustrerar är att alla inblandade spelar inte efter samma regler, bara för att man själv avgränsar sin bild av systemet innebär det inte att alla andra gör det. Ens modell av verkligheten behöver nödvändigtvis vara så lik verkligheten som möjligt för att man ska kunna ta bra beslut om vad som ska göras. Det är vad i grund och botten vad riskhantering handlar om. 3

4 Säkerhet kan definieras som ett minimerande av sannoliketen att något oönskat ska hända eller konsekvensen av att en oönskad händelse inträffar. Det räcker däremot inte med att anta att systemet kommer att användas på rätt sätt av alla. Oavsett vad för system man designar och implementerar så behöver man ta hänsyn till den miljö det kommer befinna sig i. Därför räcker det inte heller med att göra antaganden om vad som är säkert eller inte utan att ha analyserat det omkringliggande landskapet, många har fallit för det genom åren. Som exempel på det kan vi ta Sony som fick playstation 3-konsolen hackad p.g.a. en sårbarhet i de kryptologiska mekanismer de implementerat för att _skydda_ systemet. Så det finns även möjlighet att man ökar risken för systemet genom att lägga in mer funktioner. Budskapet är helt enkelt att utan att analysera systemets behov utefter de krav man har så kommer man inte ha en aning om hur säker man är, oavsett hur mycket kryptering eller andra lösningar man sätter på det. Det finns gott om lösningar som i sig själva är bevisat säkra, t.ex. krypterad kommunikation kan anses relativt säker rent matematiskt. Men vad hjälper det om lagringen, nyckelhanteringen, och resterande system är osäkrade? Vad som behövs för att man ska kunna uttala sig om säkerheten i sina system är en medvetenhet om hur det faktiskt ser ut med hot och risker gentemot systemet. Om man känner till vad som skulle kunna hända så kan man ta ett aktivt beslut om att göra någonting eller ingenting. 4

5 Det finns i stora drag tre områden som kommer tas upp i föreläsningen: Terminologi och definitioner av risk och hot, riskanalys och de olika metoderna som finns, samt riskhantering och vad man egentligen får ut av det. Fokus kommer att ligga på riskanalys och riskhantering, eftersom det är vad man har störst användning av rent praktiskt när man jobbar med system. 5

6 Ett hot är enkelt sagt någonting som kan orsaka en oönskad händelse med negativ konsekvens. Vad som alltid är sant för ett hot är att det påverkar en tillgång (eng. asset) som vi gärna vill se opåverkad av negativa händelser. En tillgång kan vara vad som helst som man vill skydda, information, personer, etc. Dock finns det många definitioner om vad ett avsiktligt hot egentligen är. En användbar definition är att ett hot har tre komponenter: (1) agent, någon som utför en attack (2) en metod som agenten använder (3) ett mål, d.v.s. vad attacken ska åstadkomma i termer av tillgångar. Vanligtvis känner man till tillgångarna i ett system men hotagenterna och metoderna de använder sig av är ofta okända variablerna. 6

7 Skillnaden mellan ett hot och en risk är uppskattningen i sannolikheten för att en oönskad händelse kommer ske samt med vilka konsekvenser. En risk är helt enkelt en oönskad händelse med dessa två värden. Vanligtvis talar man också om riskens magnitud, vilket enkelt uttryckt är sannolikheten multiplicerat med konsekvensen. En risk är per definition någonting som har en negativ inverkan, men det är inte alltid pengar som avses. Det finns betydligt mer aspekter av vad man kan förlora genom en attack. T.ex. så spelar ryktet utåt en stor roll för ett företag i en konkurrensutsatt marknad. Beroende på företagets produkter och storlek så kan man absorbera olika mängder dålig publicitet. 7

8 Ta t.ex. RSA, ett amerikanskt företag som tillverkar hardware tokens för att generera engångslösenord genom en kryptografisk algoritm. Tidigare i år fick de all källkod stulen från sina databaser, vilket ledde till att de till slut erbjöd sig att byta ut alla hårdvarutokens som de levererat till kunder samt att de förlorat kunder och förtroende från omvärlden. RSA hade bland annat Lockheed Martin som kund, vilka levererar fighterjets och andra vapensystem till amerikanska militären. Och vad var sårbarheten som tillät dem att göra det? Hanteringen av flashobjekt i excel och användare som fick en infekterad fil i phishingmail. Inte direkt en lättidentifierad sårbarhet rent tekniskt, men man borde kunna identifiera metoden i stora drag, så som phishing och trojaner. Istället för att försöka identifiera så pass obskyra sårbarheter så bör man kolla längre längs kedjan av sårbarheter. I det här fallet så var viktig säkerhetsrelaterad information sparad i en och samma databas som var åtkomlig för de som utförde attacken. Exemplet visar också på ett typiskt problem för riskanalyser, hur bedömer man sannolikheten för att något som det här kan hända? 8

9 Lite kort om olika definitioner av risk som man kan stöta på. Risk innebär alltid sannolikhet gånger konsekvens, dock kan båda dessa faktorer brytas ner i andra element. T.ex. så beror sannolikheten på vilka hot och sårbarheter som finns och vilka sannolikheter dessa besitter. Man kan ha flertalet sårbarheter i ett system men om dessa inte är exponerade överhuvudtaget finns det egentligen ingen större sannolikhet att dessa utnyttjas av någon annan och man kanske därför inte bör spendera stora summor på att säkra upp just de sårbarheterna. Konsekvenser omfattar, som tidigare beskrivits, flera olika aspekter av negativ inverkan; direkta ekonomiska förluster, förlorade kunder, förlorat förtroende, osv. 9

10 Så varför ska man hålla på med riskanalyser? Enkelt sagt så är det för att vi vill kunna försvara det som är vårat. Om man inte har en aning vad som kan gå fel så kan man inte sätta upp ett försvar som täcker in det som _faktiskt_ kan hända. När man utvecklar ett system så behöver man alltid ta hänsyn till vilket hotlandskap systemet kommer befinna sig i, eftersom det kommer påverkar hur man bygger systemet. Utan att genomföra hot- och riskanalyser skulle man inte ha en aning om hur landskapet ser ut, systemet kommer därför operera utifrån att det inte finns något farligt alls utanför det. Att arbeta utifrån ett sådant antagande är aldrig rätt, det finns alltid scenarion man inte tagit med i beräkningarna. Ibland kan man ha tur och lyckats skydda mot ett hot utan att identifiera det men det är väldigt sällan en vinnande taktik. Om man istället genomför analyser av vad som kan hända så finns det möjlighet att förutsäga vissa scenarion och vidta åtgärder. Oftast så är det väldigt stor skillnad i kostnad mellan att vara proaktiv och förhindra vissa händelser istället för att reagera när de väl inträffar. Tänk själva vad som skulle hända om ni är i slutet av ett projekt av något slag och upptäcker att ni gjort fel och behöver göra om allt från början för att få det helt rätt. Många sådana scenarion kan man undvika genom att vidta åtgärder i tidigt skede. Själva området riskanalys är en snårskog av olika metoder och sätt att analysera system, attacker, sårbarheter, etc. I den här delen av föreläsningen går vi igenom ett par aspekter av riskanalys, vad som vanligtvis ingår och ett par olika metoder för att genomföra riskanalyser. 10

11 Vad som brukar ingå i de metoder som finns och arbetas fram är främst tre saker: (1) Definition av analysens omfattning. Ibland kan den vara implicit i och med att man analyserar enbart systemet och dess interna struktur eller så kan den sträcka sig utanför systemet till att inkludera omkringliggande fysisk miljö. (2) Att identifiera hoten/riskerna. Här kan det finnas lite olika användning av terminologi eftersom vissa skiljer på stegen att uppskatta risken och att identifiera hotet. (3) Beräkna risknivån, här ingår det att uppskatta sannolikhet och konsekvens för hotet man identifierade i steg 2. (4) Vad man sedan gör med riskerna man identifierat brukar räknas in i riskhanteringsprocessen. Men ibland inkluderar metoder ett fjärde steg då man identifierar möjliga sätt att förhindra hotet från att inträffa. När man har genomfört en riskanalys så har man i teorin gått från att enbart ha ett system och ingen kunskap om vad som hotar det till en lista med uppskattade risker för systemet. Innan vi går in på faktiska metoder för riskanalys ska vi titta på lite problem och utmaningar för de olika stegen som ingår i riskanalyser. Anledningen till det är att man oftast stöter på utmaningar i varje steg och behöver känna till dem för att kunna ta beslut om vad man ska göra. 11

12 Hur omfattande en riskanalys ska vara är något man måste bestämma sig för innan man börjar analysera, annars kan man råka på något som kallas för analysis paralysis. När man analyserar systemet efter hot och risker till absurdum och aldrig blir klar för att kunna göra någonting med den information man har, man blir mer eller mindre handlingsförlamad. Man behöver oftast inte ta hänsyn till väldigt osannolika händelser som kanske skulle kunna påverka sina tillgångar, därmed inte sagt att man inte kan planera för extrema händelser. För att kunna göra lämplig begränsning på analysens omfattning ska man därför ha kunskap om vilka aktörer och system som ingår och hur kommunikationen mellan dessa är tänkt. Har man annan kunskap om systemet man ska skydda, t.ex. att den fysiska säkerheten för kontorsbyggnaden är väldigt hög så behöver man inte ta med sådana hot i analysen, men man måste dokumentera varför man inte tagit hänsyn till dem. 12

13 Att faktiskt identifiera hot och sedan klassificera dem som risker är något av det knepigaste i hela processen. Bara en sådan sak som att veta vilken detaljnivå som krävs på analysen är ofta svårt nog, de som sitter inne på pengarna och tar besluten har oftast ingen aning om vad små detaljer handlar om, samtidigt som det oftast bara finns ett fåtal experter som kan analysera ett system på riktigt detaljerad nivå. Ett annat problem är att välja en metod att använda sig av för att identifiera hot och risker. Det finns ett stort antal metoder med olika för och nackdelar och anpassade till olika typer av system, att hitta någonstans mellan stycken olika varianter på befintliga metoder lär inte vara alltför svårt. Därför är det viktigt att man förstår vad man letar efter i sin analys och vad för resurser man har tillgängliga. En del metoder förlitar sig helt och hållet på att man som analytiker är tillräckligt kunnig och kreativ för att skriva upp alla risker gentemot systemet, medan andra är mer systematiska och hjälper att strukturera analysen. Det är därför viktigt att man tränar sig på att använda riskanalysmetoder (och inse skillnaderna mellan dem) så att man vet när man bör applicera vilken. 13

14 När man ska uppskatta risken med ett hot man identifierat så finns det två sätt man kan göra det: kvalitativt eller kvantitativt. Skillnaden mellan dem är att i kvantitativ riskanalys så försöker man använda sig av så exakta siffror som möjligt för att beräkna magnituden av en risk. D.v.s. man använder exakta siffror för sannolikhet och konsekvens. För kvantitativa analyser baserar man sig ofta på tidigare statistik för händelser, hur ofta de inträffat och hur mycket varje incident har kostat. Detta slår man sedan ut över en definierad tidsperiod så man har en referensram för att jämföra förväntade förluster mot kostnaden att investera i lösningar för att skydda mot händelsen. NIST som utfärdar diverse standarder även inom riskhantering diskuterar enbart användningen av kvantitativa analyser för att beräkna kostnaderna för användning i cost/benefit-analyser. Kvantitativ riskanalys används inte alltför ofta för informationssäkerhet. Detta är oftast på grund av att det är väldigt svårt att bedöma just sannolikheten för att någon kommer att attackera ditt system på ett specifikt sätt. Det finns just inget bra sätt att kvantifiera sannolikheten för att okända sårbarheter kan utnyttjas och ha en negativ effekt på ett system. Detta är ett aktivt forskningsfält där det kommer förslag på nya metoder för att mäta och kvantifiera risk och säkerhet. För kvalitativa metoder så gäller det istället att skapa egna skalor för sannolikheter och konsekvenser. 14

15 När man använder sig av kvalitativ riskanalys så måste man alltid definiera vad varje nivå betyder. T.ex. om det handlar om funktionalitet kan man prata om hur märkbar funktionalitetsdegraderingen av en produkt är, används av t.ex. Ericsson. Liknande skalor kan göras fast för andra aspekter som monetära förluster, skador på system eller människor, osv. På samma sätt definierar man sin skala för sannolikheten att en händelse kommer att inträffa. Skalor som dessa kan man basera på kunskap om hur ofta de inträffat förut, för andra eller genom egen erfarenhet. Man behöver vara noggrann att definiera nivåer som skiljer sig åt tillräckligt mycket för att enkelt kunna klassificera händelser utefter nivåerna. 15

16 Detta använder man sedan för att skapa en riskutvärderingsmatris där man kan placera in de risker man identifierat och uppskattat efter de två skalorna man har. Det är ett välanvänt och användbart verktyg för att visualisera vilka risker man har och vilka risker man bör prioritera. Matriserna kan se lite olika ut beroende på vilka allvarlighetsnivåer man bestämmer sig för att använda. En del drar en diagonal och åtgärdar endast risker på ena sidan och gör ingenting åt risker på andra sidan för att det troligen inte är resonabelt att investera i åtgärder. 16

17 De olika riskanalysmetoderna har ofta olika typer av struktur på analysen. Vanligtvis pratar man om ett fåtal typer: *Brainstorming, där man helt enkelt sitter och försöker tänka sig fram till möjliga scenarion utan någon direkt struktur på hur man gör det. *Checklistor, det finns metoder för riskanalys som helt enkelt går ut på att man går igenom en checklista med olika punkter på och ser hur systemet stämmer överens med checklistan. *Induktiv analys. När man använder sig av induktiv analys så tar man ofta en hanterbar komponent av ett system och ställer sig själv frågor om vad som skulle kunna hända ifall någonting ändrar sig. *Deduktiv analys. För deduktiv analys så gäller det omvända, man sätter istället upp oönskad händelser och försöker från dem och den definierade omfattning härleda vad som skulle kunna leda till att händelsen skulle kunna ske. Vad man ska använda vid en specifik situation beror på flera saker; vilken typ av system, vilken information man har, vilken kunskap och expertis som finns under analysprocessen, tid man kan lägga ner och detaljnivå man vill åstadkomma. [Zürich Risk Engineering Which Hazard Analysis?, sammanställd tabell över olika attribut hos metoder] 17

18 Nu ska vi titta närmare på de olika typerna av riskanalysmetoder och gå igenom tre stycken exempel på olika metoder med olika fokus. 18

19 Riskanalysmetoder kan i stora drag kategoriseras i tre olika kategorier: (1) De hotcentrerade metoderna som fokuserar på hoten och de attacker som de kan tänkas använda sig av för att komma åt tillgångar i ett system. (2) De systemcentrerade analysmetoderna som utgår från systemet i fråga. I de här metoderna bryter man ofta ner systemet i komponenter och försöker hitta sårbarheterna i dessa, för att sedan identifiera vad de kan leda till för konsekvenser. (3) I den tredje typen av analysmetod så utgår man från vilka tillgångar man har i systemet, för att sedan titta vidare på hur de hanteras och vilka hot som kan finnas mot dem. Den här kategoriseringen beskriver egentligen bara startpunkterna för analysen och till slut kommer alla aspekterna behöva finnas med i slutresultatet. Kategorierna har dock en viss betydelse för strukturen i analysen. Ofta så är systemcentrerade metoder mer strukturerade i hur analysen genomförs än vad de hotcentrerade metoderna är. 19

20 Vi ska nu gå igenom ett exempel och applicera ett exempel på varje typ av metod på det för att se hur det kan se ut när man analyserar med de metoderna. Vi gör tre antaganden för att bestämma omfattningen av analysen: (1) Systemet är åtkomligt via internet, (2) Det finns inga fysiska hot mot systemet, (3) webbservern och databasen ligger på samma nätverk som andra system. De två första metoderna kommer illustreras med kortare exempel medan CORAS kommer att gås igenom i detalj. Anledningen för det är att CORAS explicit tar med fler koncept av riskanalys än de andra två metoderna. 20

21 Attackträd är en av de mer populära metoderna i litteratur idag, mestadels p.g.a. att den är väldigt intuitiv och lättanvänd. Vad den går ut på är att man börjar med att formulerar ett attackmål och sedan försöker bryta ner det i olika sätt att uppnå det målet. När man listat alla olika sätt man kan komma på så fortsätter man att bryta ner dem i en nivå till, och fortsätter på det viset tills man är nöjd med abstraktionsnivåerna eller har kommit ner till en sådan detaljerad nivå att man kan börja göra antaganden om sannolikhet. Här lär vi dock lägga vikten på alla olika sätt man kan komma på. Det finns ingen utarbetad process för hur man ska komma på olika sätt att attackera ett system. Utan process kräver det att man har en väldigt stor kunskap om systemet samt att man kan tänka ut alla sätt det kan attackeras på, något som är väldigt svårt i verkligheten. Det finns flera detaljer kring vad man kan inkludera i ett attackträd; t.ex. hur flera aktiviteter krävs för att uppnå ett attackmål, kostnadsuppskattning per gren i attackträdet, etc. Generellt sett kan man säga att attackträd är bra för att skapa sig en översiktsbild och för att bryta ner attacker när man väl kommit på dem. 21

22 FMEA (Failure mode and effect analysis) är en systemcentrerad analysmetod som har använts flitigt sen den infördes vid Flertalet stora industrier använder den för att analysera både projekt och produkter, mestadels för att identifiera sårbarheter som kan leda till oavsiktliga risker. FMEA är dock väldigt användbar för att analysera vad som kan hända om någonting går fel, oavsett om det är avsiktligt eller oavsiktligt. När man gör en FMEA så brukar det finnas tabellmallar att följa som definierar vad som ska ingå i analysen. I det här exemplet så har vi numret på risken, vilken komponent som berörs, vad för felmod det är, vilken konsekvens den har, vilken konsekvensnivå det handlar om, vilken skyddsåtgärd som finns och till slut vilken/vilka den/de rekommenderad(e) åtgärderna är. Tabellen på powerpointen är ett exempel på hur en FMEA-analys kan se ut. I det här fallet så har vi två komponenter, en databas och en webbserver. För var och en av dem så finns det en felmod identifierad, t.ex. så kan det vara så att det finns korrupt data i databasen, vilket skulle kunna leda till att användare får felaktig information. Beroende på informationen som finns så bestämmer man konsekvensnivå för hotet (i det här exemplet finns ingen kolumn för sannolikhet men det är också vanligt att ha med). Det finns vissa problem med att använda sig av den här typen av analys. För det första riskerar den att bli svåröverskådlig när man kommer upp i många risker, tänk er samma tabell fast med hundratals rader. Det är dessutom väldigt svårt att modellera risker som beror på fler än en felmod på ett översiktligt vis. I många fall så är ett intrång på en hemsida en kedja av olika händelser som inte är lätt att beskriva med bara text. 22

23 CORAS är metoden som vi ska undersöka mer i detalj. CORAS är precis som attackträd en grafisk analysmetod, men man kan uttrycka betydligt mer information i diagrammen än jämfört med attackträd. Själva metoden är en lite nyare metod framtagen av ett forskningsinstitut i Norge och består av sju steg (alternativt åtta beroende på vilken beskrivning av den man använder sig av). Vi kommer i de följande slidesen gå igenom webbsideexemplet och visa vad som sker i varje steg av metoden och hur analysen utvecklar sig genom den. 23

24 Steg 1 i CORAS är ett introduktionssteg då en klient beskriver systemet och hjälper till att definiera omfattningen av analysen för analytikern. I det här exemplet så beskriver klienten det berörda systemet så som att det finns ett internt nätverk med webbserver, databas och klienter anslutna. Det interna nätverket är anslutet mot internet via en router och folk kan ansluta till webbservern utifrån. 24

25 I steg två så ska analytikern beskriva sin förståelse av systemet, detta sker t.ex. genom att göra ett systemdiagram som är mer detaljerat än det som kunden i sig kommer med i steg ett. T.ex. så kan man vara mycket tydligare med vilka typer av kommunikationskanaler eller protokoll som finns tillgängliga för systemet. All systeminformation som kan påverka riskanalysen är viktig att få med, även om det bara är en översiktlig skiss av systemet. Missar man något i det här steget så kommer man inte få med risken i de senare stegen heller. Analytikern har förfinat systemskissen litegrann och adderat en mailserver som också är ansluten till det interna nätverket samt specificerat ett par protokoll som används internt. 25

26 Utöver analytikerns egna systemdiagram så gör man även vad som kallas för ett tillgångsdiagram där man beskriver vilka tillgångar som man tar hänsyn till under analysens gång. Har vi t.ex. en hemsida med en databas i bakgrunden så anser vi t.ex. att webbgränssnittet och själva datat i databasen är direkta tillgångar, både för oss och för den som använder webbsidan för information. Ofta så finns det också flera tillgångar som beror på de direkta. För den som äger sidan spelar så betyder ryktet mycket för hur många användare och kunder man kan få, men om själva webbgränssnittet skulle bli hackat och deface:at eller liknande så finns det en risk att ryktet får sig en törn eftersom webbgränssnittet går ner. Därför markerar man ut att det finns ett beroende mellan tillgångarna och hur de påverkas indirekt av händelser hos andra tillgångar. 26

27 I det här steget så ska alla inblandade komma överens om synen på vad systemet är och vad som ska göras åt det. I det ingår systembeskrivningar och vilka tillgångar som omfattas av studien. Den viktigaste delen av det här steget är dock att man definierar skalorna som man ska använda sig av i riskmatrisen i nästa steg. Exempel på en konsekvensskala skulle kunna vara som på sliden. Scenariot att användare och kunder slutar använda en webbsida är det värsta som kan hända ifall man får in pengar och popularitet beroende på hur många som använder sidan. En seriös men ändå mindre allvarlig konsekvens skulle vara att användare temporärt inte kan nå sidan eller få fel information från webbsidan. En lindrig konsekvens skulle kunna vara att man får längre svarstider från webbservern. Vad skalorna tjänar till är helt enkelt att försöka sätta konkreta exempel på olika konsekvensnivåer, för att då lättare kunna klassificera även andra risker eftersom man har en referensram att jämföra mot. 27

28 I steg fyra påbörjas processen med att faktiskt identifiera olika oönskade händelser, vilka hotscenarion som kan leda till dem och vilka sårbarheter som möjliggör för hotscenariona. Själva processen man följer är vad man kan kalla för en semistrukturerad process, i det här fallet menar jag att det finns vissa steg att följa men att det inte finns något egentligt sätt att komma fram till resultaten för varje steg. Här blir det extra tydligt att erfarenhet och kreativitet spelar en ganska stor roll i riskanalysprocesser, eftersom man måste kunna komma på så många svar som möjligt till de tre frågorna som styra CORAS-processen. Först identifierar man vad man inte vill ska hända med tillgångarna, d.v.s. oönskade händelser. Detta kan vara t.ex. att man förlorar all data i databasen, att webbsidan inte längre visar rätt information, att ingen kommer åt webbsidan osv. För andra frågan så identifierar man för varje oönskad händelse de scenarion som kan leda till att händelsen inträffar, d.v.s. t.ex. vilka typer av attacker en hotagent kan genomföra. För den tredje och sista frågan så försöker man identifiera vilken/vilka sårbarheter som gör varje hotscenario möjligt. Alla svar strukturerar man sedan i ett hotdiagram. 28

29 Vanligtvis när man använder sig av CORAS så börjar man med att sätta ut sina tillgångar längst till höger i diagrammet, för att sedan fortsätta med att identifiera hotscenarion (dvs vad vill man inte ska hända med tillgångarna man har i systemet). Sedan arbetar man sig bakåt från hotscenariona med att identifiera situationer som skulle göra det möjligt för scenariona att inträffa. Till exempel kan vi ta scenariot då webbgränssnittet modifieras av en oauktoriserad person. Svaret på första hur? är att han byter ut hemsidan i webbservern, men hur går man tillväga för att åstadkomma det? T.ex. så kan han utnyttja sårbarheter i en opatchad webbserver eller få tillgång via ett admingränssnitt. [Kan ni hitta några fler sätt?] Som ni nog förstår så kan diagrammen bli väldigt plottriga om man håller en hög detaljnivå, därför är det viktigt att man dokumenterar sådant man inte kan visa upp direkt i diagrammen. Det finns lite fler riktlinjer för hur man går tillväga med att skapa diagrammet, t.ex. så tar man bort alla tillgångar man inte kan hitta oönskade händelser för från diagrammet. 29

30 När alla kedjor av hot, sårbarheter, scenarion och oönskade händelser har etablerats och man anser sig klar med den delen så kommer man till steg 5 som handlar om att göra scenariona till faktiska risker, genom att sätta en sannolikhet och en konsekvens för varje oönskad händelse. Om man inte kan sätta ett direkt värde på sannolikheten så kan man istället arbeta sig fram till en sannolikhet genom att bedöma alla hotscenarion som leder fram till den och sätta sannolikhet på dem istället. Därmed får man en härledning till vilket sannolikhetsvärde som är rimligt för den oönskade händelsen. 30

31 Här har vi samma diagram som tidigare, med skillnaden att vi lagt till uppskattningarna på risknivåer för de oönskade händelserna. T.ex. kan vi se att scenariot där informationen sprids på nätet kan inträffa ibland och med oftast katastrofiska konsekvenser till följd. Hur man sätter sannolikheterna och konsekvenserna har vi gått igenom men hur man bedömer dem kommer som oftast sagt ner till subjektiva åsikter om hur allvarligt någonting är. 31

32 När alla risker blivit beräknade och namngivna så använder man sig i CORAS av en riskmatris för att skapa sig en översikt över de risker man identifierat. Exakt hur riskmatrisen ska se ut är något man också kommer överens om i steg 3 i CORAS. Vissa använder sig t.ex. av tre stycken olika nivåer när det närmar sig riskhanteringen och kan göra diagonalen till en egen nivå eller inkluderar den i den röda kategorin. Genom matrisen får man som tidigare nämnt en bra översikt om hur många och hur allvarliga risker man har i analysen. 32

33 Det sista steget i CORAS handlar om att åtgärda eller mildra riskerna. I CORAS så innebär det att man ger sig på de identifierade sårbarheterna och försöker hitta sätt att eliminera dem eller minimera konsekvenserna av dem. I CORAS markerar man ut sådana åtgärder med den lilla skiftnyckeln och en kort förklaring av åtgärden. Här så finns tre sårbarheter som åtgärdas på olika sätt, t.ex. att anslutning till webbserver och admingränssnitt bara får ske från det interna nätverket. En policy för användarrättigheter kan ta hand om en del hotscenarion gällandes insiders, och nattliga backups kan vara en bra åtgärd för att snabbt komma tillbaka i operation om all data försvunnit. 33

34 Det finns fyra stycken olika klasser av åtgärder för identifierade risker: (1) Undvika risken, d.v.s. att försöka eliminera risken helt och hållet och se till att inga konsekvenser kan inträffa. (2) Minska risken, d.v.s. definiera och implementera åtgärder för att minska sannolikheten att risken inträffar eller konsekvenserna ifall risken inträffar. (3) Acceptera risken, d.v.s. gör ingenting åt risken men var beredd på att ta hand om konsekvenserna ifall den inträffar. (4) Överföra risken till någon annan. Oftast något som fungerar bättre i större projekt med många delar där man kan hyra in andra för att göra vissa komponenter och då ta riskerna som de komponenterna medför. Alternativt gör man det med hjälp av försäkringar. 34

35 När man ska välja vilka åtgärder man ska ta mot ett hot så behöver man väga olika scenarion mot varandra. NIST föreslår att man bör bestämma svaren för de fyra punkterna jag skrivit upp: (1) Vad blir konsekvenserna av att införa nya kontroller? Inför man nya möjliga sårbarheter i systemet? Kommer all risk att mitigeras? Osv. (2) Vad blir konsekvenserna av att inte införa nya kontroller? Den här punkten har man troligen redan svaret på från riskanalysen men man ska ta med den i övervägandet. (3) Vad blir kostnaden för att införa nya kontroller? Vad för hård-/mjukvara behöver man? Vilka konsekvenser får det på driften, kostnader för personal, träning av personal osv? (4) Och sist men inte minst, vilka kontroller är viktigast att införa sett från systemet, riskbilden mot systemet och kostnaden för kontrollen. Nr 1 och 2 är inte nödvändigtvis konkreta i sin natur utan mestadels uppskattade konsekvenser, blir en hotagent mindre angelägen om att attackera med den här kontrollen eller inte? Nr 3 kan däremot bestämmas i absoluta termer av kostnad i pengar och tid. 35

36 Ytterligare en viktig aspekt när man ska välja åtgärder är att välja sådana som blir accepterade av användare. T.ex. så har vi debatten om kroppsscanners vid flygplatser, det finns väldigt många argument mot dem men ändå har de införts på grund av risken för en terroristattack. Man kan debattera väldigt länge om säkerhetsåtgärderna är proportionella gentemot vad risken är, och det är ett väldigt bra exempel på en händelse som sträcker sig långt från att enbart involvera ekonomiska perspektiv. 36

37 Riskhanteringen är en process som inkluderar riskanalys som vi tidigare beskrev och består utav ytterligare ett par steg. Vad man strävar efter att uppnå i riskhanteringsprocessen är de optimala besluten när det kommer till att välja vad man ska göra med de olika risker man identifierat. I CORASexemplet som gicks igenom innan så var steg 6 och 7 egentligen hantering av risker och inte så mycket riskanalys, vilket de presenterar metoden som. Sådana beskrivningar finns det gott om och de skapar vissa förvirringar mellan vad som är riskanalys och vad som är riskhantering. Vad är egentligen problemet med CORAS beskrivning av processen? Deras metod beskriver hela processen med riskanalys och riskhantering som en linjär instans, vilket riskhantering _inte_ är. Riskhantering är någonting som alltid måste finnas där och är inget som är färdigt bara för att man har följt en metod en gång. Vi ska kolla närmare på ett exempel av en riskhanteringsprocess, Risk management framework. 37

38 Koppling av tekniska risker till affärsmässiga risker RMF består utav fem stycken steg och är en cyklisk process i de fyra sista stegen. Vad som gör RMF lite mer speciellt är det första steget och dess koppling till det andra steget. Man börjar nämligen med att explicit identifiera de affärsrelaterade riskerna som man kan råka ut för med ett specifikt system/projekt, riskerna ska alltid uttryckas i form av vad man förlorar: marknadsandelar, kostnader, osv. Dessa ska man sedan i steg två koppla till de tekniska riskerna man upptäcker. Tanken är att man på så vis enklare ska kunna kvantifiera de tekniska riskernas konsekvenser i affärsmässiga termer, och på så vis enklare kunna rangordna dem i steg 3. Man kan beskriva det som att man i steg 1 och 2 lägger på ett till lager att prioritera från, d.v.s. prioriteten i de affärsrelaterade riskerna. Resultaten från steg 3 är enkelt uttryckt en lista över alla risker, rangordnade efter vilken prioritet de har för att tas hand om. Steg 4 handlar om att definiera åtgärder gentemot de tekniska riskerna man upptäckt, det är dock inte lika enkelt som beskrivet i CORAS. För varje åtgärd man identifierar så måste man också definiera kostnaden, tiden för implementation, sannolikheten att åtgärden lyckas, hur komplett åtgärden är samt hur den påverkar resterande risker. Som man nog kan förstå så handlar riskhantering väldigt mycket om business och pengar, vilket är anledningen till att man överhuvudtaget bryr sig om att genomföra riskanalyser. Det sista steget i ett varv av RMF är att utföra och validera åtgärderna man bestämde sig för att genomföra i steg 4. Sedan upprepar man det här i de olika faserna av systemets/projektets livscykel, speciellt inom IT där hotlandskapet förändrar sig kontinuerligt är det viktigt att följa upp och iterera riskhanteringen. 38

39 Riskhantering måste finnas med i alla steg utav ett projekt, redan i initieringen av projektet behöver man ta hänsyn till riskerna i kravställningarna och vad riskerna är rent marknads- och affärsmässigt. I de två nästkommande stegen handlar det om utvecklingen av systemet där man dels behöver se till att vad man producerar faktiskt överensstämmer mot kraven för att undvika otydliga tolkningar av krav vid implementationen. Just otydligheter i vad som ska göras är en vanlig källa till sårbarheter i systemen, tolkar en designer ett krav på ett sätt men en utvecklare designen på ett helt annat sätt så finns det element som inte bör finns i det färdiga systemet, vilket kan bidra till sårbarheter som ingen förutsåg i början av projektet. Ett rent konkret sätt att börja leta efter kända sårbarheter är att t.ex. använda sig av CVE-databaser ( och undersöka om man kan hitta sårbarheter av intresse för projektet man håller på med. Något som man bör hålla i åtanke under projektets gång är i vilken miljö ett system är tänkt att operera. Förändringar i var och hur ett system används har orsakat stora problem för många organisationer genom åren, speciellt med gamla offlinesystem som blir uppkopplade mot internet. Då har man i princip bara stoppat i en nätverkssladd och möjligen en brandvägg, utan att tänka på hur mycket som egentligen förändras i systemet och vad det medför för risk och hotbilderna. 39

40 40