Riskanalys fo r kritiska IT-system - metodbeskrivning

Transkript

1 Riskanalys fo r kritiska IT-system - metodbeskrivning Kim Weyns, kim.weyns@gmail.com Martin Höst, martin.höst@cs.lth.se Inledning Denna rapport innehåller en metodbeskrivning för en riskanalysmetod speciellt utvecklad för verksamhetskritiska, distribuerade IT-system. Metoden är speciell utvecklad för att vara lätt att tillämpa på många sorters IT-system. Resultatet av metoden är en skattning av hur ofta avbrott (båda kortvariga och långvariga) förväntas förekomma samt en översikt över vilka komponenter eller delsystem som förväntas orsaka de allvarligaste problemen med systemets tillförlitlighet. Resultatet kan sedan användas i en bredare riskanalys av verksamheten som är beroende av systemet samt vara underlag till möjliga åtgärdar för att förbättra systemets tillförlitlighet. Metoden illustreras med ett mindre (fiktivt) exempel. I bilaga finns ett Excel-blad som illustrerar beräkningarna i exemplet. Metoden har utvecklats vid institutionen för datavetenskap vid Lunds Tekniska Högskola inom ramen av PRIVAD (Programme for Risk and Vulnerability Analysis Development) projektet. Metodbeskrivning Metoden för riskanalysen är baserad på Reliability Block Diagrams -metoden (RBD). Riskanalysen består av följande steg: 1. Avgränsning 2. Definition av avbrottskategorier 3. Bygga upp systemmodellet 4. Estimera avbrottsfrekvensen för alla komponenter 5. Analys 6. Presentation av resultatet 1. Avgränsning Det är viktigt att tydligt definiera risken man vill analysera. Först och främst måste systemets gränser definieras: Vilka delsystem eller funktioner ingår i analysen? Ska vissa delar exkluderas från analysen (till exempel för att de inte är lika kritiska)? Vill man analysera avbrott som påverkar en användare, flera användare eller alla användare av systemet?

2 Vad räknas som ett kritiskt avbrott i systemets funktionalitet? För att kunna besvara dessa frågar, behövs det input från båda verksamheten och ITdriftpersonal som har stor erfarenhet med systemet. Som exempelsystem studerar vi ett journalsystem som används inom äldrevården. Efter diskussion mellan systemförvaltare och IT-personal bestäms att riskanalysen ska fokuseras på ett specifikt äldreboende, där risken ska analyseras att många datorer på äldreboendet inte har tillgång till informationen som lagras i journalsystemet. Otillgänglighet från enstaka datorer eller för enstaka användare är mindre kritisk och analyseras därför inte. Resultatet av analysen kan sedan enkelt uppdateras med eventuella skillnader med andra äldreboende. 2. Definiera avbrottskategorier Den största skillnaden med den klassiska RBD metoden är att denna metod använder sig av ett fåtal avbrottskategorier, baserad på avbrottets längd. Detta tillägg har flera fördelar. Först och främst så förenklar det skattningarna och datainsamlingen som ligger till grund för analysen. Samtidigt blir resultatet mer konkret och lättare att tolka. Dessutom tillåter dessa kategorier att flera olika felorsakar kan fångas på hög nivå i systemmodellen utan att de allra minsta fysiska och logiska komponenter av systemet behöver modelleras separat. Till slut förenklar detta också beräkningarna i analysen. Kategorierna, baserat på längden av avbrottet i systemets funktionalitet, har betydelse båda för verksamheten och för driften av systemet. Längre avbrott är mer alvarliga än kortvariga avbrott och ökar risken att avbrottet få allvarliga konsekvenser för verksamheten. Från driften synpunkt är korta avbrott dessa som lätt kan avhjälpas av driftpersonal själv, genom att till exempel starta om eller byta ut en viss komponent av systemet. Långvariga avbrott orsakas ofta av sådana fel som inte driftpersonal själv enkelt kan lösa och som till exempel kräver att vissa ersättningskomponenter beställs. För exempelsystemet valdes följande avbrottskategorier: Korta avbrott kortare än 5 timmar (medellängd 2,5 timmar) Medellånga avbrott mellan 5 och 24 timmar (medellängd 14,5 timmar) Långvariga avbrott längre än 24 timmar (medellängd 3 dagar) För verksamheten på äldreboendet påverkar korta avbrott oftast endast ett arbetsskift och stör därför inte informationsflödet så mycket. Den viktigaste informationen i systemet finns alltid tillgängligt på papper och skrivs ut dagligen. Medellånga avbrott påverkar flera arbetsskift och kräver att informationen sprids på papper istället för genom systemet, men mängden informationen som behöver uppdateras är begränsad och kan enkelt kommuniceras mellan vårdgivare. Vid långvariga avbrott ökar mängden information som måste spridas på papper och är risken för att informationen tappas bort störst, vilket kan ha allvarliga konsekvenser för patienternas vård. För IT-personalen motsvarar korta avbrott oftast sådana avbrott som kan avhjälpas genom att starta om enstaka komponenter av systemet (IT-personal finns tillgängligt 24/7). Medellånga avbrott är sådana som kräver att komponenter byts ut (från lager) och ominstalleras. Långvariga avbrott orsakas av problem kräver att externa konsulter kopplas i eller att komponenter måste beställas från leverantören.

3 3. Bygga upp systemmodellet I detta steg, ritas en RBD modell av systemet, börjande från en högnivåmodell med få komponenter som sedan byggs ut till en mer avancerad modell där komponenterna lätt kan analyseras var för sig. Systemmodellen består av två noder som kopplas ihop genom ett nätverk av fysiska och logiska komponeter av systemet. Systemet är tillgängligt så länge minst än väg finns mellan dessa två noder. När det inte lägre finns en förbindelse genom fungerade komponenter uppträder ett avbrott i systemet. Komponenter kan kopplas samman i serie eller i parallell. Figur 1. RBD-Systemmodell för ett system som är tillgängligt om A, C och B1 eller B2 är tillgängliga. Avbrott kan orsakas av avbrott i komponent A, eller C samt av avbrott i komponenter B1 och B2 samtidigt. Uppbyggandet av systemmodellen är den svåraste stegen i metoden. Det är viktigt att inse att komponenterna inte behöver vara fysiska komponenter men också kan vara logiska komponenter. Varje komponent överensstämmer i princip med en eller flera avbrottsorsakar för systemet eller för delsystem av systemet. Komponenterna borde vara oberoende av varandra och inte kunna slås ut av samma fel som uppträder. Om till exempel flera komponenter eller delsystem alla är beroende på samma strömförsörjning ska denna elförsörjning lyftas ut och läggas till som en komponent i serie med alla dessa komponenter. I vårt förenklade exempel byggdes systemmodellen ut från till

4 4. Estimera avbrottsfrekvensen av alla komponenter för varje avbrottskategori Nästa steg, är att ta fram skattningar för avbrottsfrekvensen för varje komponent i systemmodellen och för varje kategori. Detta kan göras baserad på historisk data eller genom skattningar av experterna med mycket erfarenhet av dessa komponenter. Det är viktigt att dokumentera hur dessa värden tas fram och hur stor osäkerheten är på dessa skattningar. Det är bra att notera en beskrivning av vilka felorsaker har inkluderats och hur dessa möjliga problem kan lösas som underlag för all data. För varje kategori av avbrott uttrycks avbrottsfrekvensen enklast som antal förväntade avbrott per år. Om det är svårt att uttrycka en oberoende avbrottsfrekvens för en komponent då beror det oftast på att systemmodeller behöver förbättras genom att dela upp, sammanfoga eller omorganisera vissa komponenter. Tabellen med avbrottsfrekvenser kommer oftast att innehålla ganska många nollar, för att vissa komponenter till exempel alltid snabbt kan återställas och andra typiskt alltid orsakar långa avbrott. För exemplet gjordes följande skattningar: < 5 hours 5 < x < 24 hours > 24 hours Klient PCs 0 0,1 0,03 Nätverk 3G 10 0,7 0 ADSL 0 0,7 0,1 Serverrum App server 1 0 0,3 Databas 0,3 0 0 Serverrummet 0 0,2 0 Som motiveras med följande beskrivningar:

5 PCs 3G ADSL App server Databas källa IT: Karl Karsson IT + 3G-leverantör IT + bredbandsleveran tör IT: Anders Andersson IT: Magnus Magnusson g anmärkningar Lösning Först måste en lösning hittas som kan ta bort viruset. Det kan finnas redå (test och installation på flera PC: 8 timmar) eller ta flera dagar at utvecklas av antivirus-företag, sedan måste den installeras på alla Det finns många PC, det enda som kan slå ut datorerna. Äldrevården prioriteras om flera alla är ett virus förvaltningar är drabbade. Avbrott i 3g-routern lokalt eller vid serverrummet, eller avbrott/överbelastning i Ny router levereras inom 24 timmar, enligt leverantörens nät avtal. Överbelastning är oftast kortvarigt. Avbrott i bredbandsroutern lokalt eller vid serverrummet, eller kabelfel, eller avbrott i leverantörens nät Virtuell server, kan drabbas av hårdvarueller programvarufel Mycket tillförlitlig server med flera redundanta diskar. Ny router levereras inom 24 timmar enligt avtal, kabelfel kan ta flera dagar att laga. Vid hårdvarufel kan systemet lätt startas på annan maskin (ungefär 2 timmar), vid programvarufel måste detta lösas av leverantören (2 dagar) Skulle servern bråka ihop, måste databasen installeras och laddas in från backup på annan maskin, detta tar ungefär 4 timmar. Serverrummet IT: Per Persson Det finns två helt oberoede serverrum, i fall Flytt till det andra rummet (datan finns alltid av brand, översvämmning, skadegörelse eller tillgänglit i båda rummen) inklusive strömavbrott måste systemerna startas upp omkonfiguration och test av systemen tar på servers i det andra rummet. Förlust av ungefär 12 timmar. Journalsystemet båda rummen är väldigt osannolik. prioriteras. 5. Analys av data I detta steg ska avbrottsfrekvensen av komponenterna sammansällas till avbrottsfrekvenser för hela systemet. Detta görs enklast genom att räkna om avbrottfrekvenser till tillförlitlighet för varje komponent och kategori. Till exempel en komponent med 3 avbrott per år med en medellängd på 5 timmar har en tillförlitlighet R = 1-3 avbrott/år x 5 timmar / (24 timmar/dag) / (365,25 dagar/år) = 0,9983 = 99,83%. För att sammanställa två komponenter A och B kan följande två formler användas: Seriekopplade komponenter: R_serie_AB = R_A x R_B Parallellkopplade komponenter: R_parallel_AB = 1 (1-R_A) x (1-R_B) Med dessa två formler kan tillförlitligheten för hela systemet beräknas för varje avbrottskategori, som sedan tillbaka till ett estimerat antal avbrott och avbrottstid för hela systemet. Tidigare erfarenheter har visats att parallella komponenter är relativt sällsynta och att dessa först behöver sammanställas till en gemensam komponent (se exempel). För att sammanställa tillförlitlighet över alla avbrottskategorier kan också tillförlitligheterna för varje kategori multipliceras. Observera att totala estimerade avbrottstiden för hela systemen varken är lika med summan av avbrottstiden för varje delsystem i serie eller för varje avbrottskategori för att flera avbrott i princip kan förekomma samtidigt. För realistiska system med en normal tillförlitlighet kommer skillnaden däremot vara mycket mindre än osäkerheten på resultatet.

6 För exemplet ger detta följande beräkningar: < 5 hours 5 < x < 24 hours > 24 hours Först måste 3G-komponenten och ADLS-komponenten räknas ihop till en gemensam Nätverkskomponent. Nätverkskomponenten har ett avbrott av en viss längd enbart om en av båda parallella komponenter har ett avbrott i denna kategori och den andra komponenten har ett minst lika lång avbrott. Sedan kan denna nätverkskomponent räknas som en komponent i serie med alla andra komponenter. Detta ger då till slut en beräknade nertid av ungefär 30 timmar om året för hela systemet (medelvärde). 6. Presentation av resultat I det sista steget kan resultaten presenteras på ett översiktligt sätt genom att till exempel göra cirkeldiagram för att jämföra bidraget till den totala avbrottstiden av olika avbrottskategorier eller delsystem. Det viktigaste är att presentera resultatet anpassad till olika målgrupper. För exemplet kan vi till exempel presentera resultatet genom följande grafer. Först för alla kategorier tillsammans: Total Downtime (min) Klient PCs 0 100,000% 0,1 99,983% 0,03 99,975% 99,959% 217 Nätverk 3G 10 99,715% 0,7 99,884% 0 100,000% 99,599% ADSL 0 100,000% 0,7 99,884% 0,1 99,918% 99,802% Nätverk Total 0,02 99,9994% 0,00 100,000% 0,00 100,000% 99,999% 5 Serverrum App server 1 99,971% 0 100,000% 0,3 99,754% 99,725% Databas 0,3 99,991% 0 100,000% 0 100,000% 99,991% 45 Serverrummet 0 100,000% 0,2 99,967% 0 100,000% 99,967% 174 System 1,32 99,962% 0,30 99,950% 0,33 99,729% 99,642% Och om vi enbart tittar på de mest kritiska avbrott (>24 timmar):

7 Om vi vill förbättra tillförlitligheten av systemet ser vi enkelt att det är App-servern som är den viktigaste komponenten. Genom att till exempel fördela den över flera fysiska servrar, skulle tillförlitligheten kunna höjas märkbart. I datan ser vi också att, även om både enstaka nätverkssystem inte är speciellt tillförlitliga, så är kombinationen av båda mer än tillräckligt bra jämfört med de andra komponenterna i systemet. Diskussion Metoden har testats på flera olika system, och i dessa försök fått mycket positiv respons. Metoden har gett användare en bättre förståelse för möjliga risker med systemet, samt gett IT-personal en bättre översikt av de olika komponenters bidrag till systemets tillförlitlighet. En del möjliga problemkomponenter har också identifierats och genom det har tillförlitligheten förbättrats. Förutom estimeringen av risken har själva analysprocessen också bidragit till en bättre förståelse mellan systemförvaltare, IT-personal och informationssäkerhetssamordnare. Analysen har också gjort att en del viktiga, praktiska frågar inom informationssäkerhetsarbetet har tagits upp och besvarats. Metoden är relativt enkelt att genomföra och ger lättförståeliga resultat. Uppbyggnaden av systemmodellen är den svåraste uppgiften. Som med de flesta riskanalysmetoder, så finns det ingen garanti att alla risker är identifierade eller korrekt bedömda. Kvalitén på resultaten beror helt på kunskapen av experterna som tar fram estimeringar för alla komponenter. Metoden kräver många skattningar och även om det är enklare att estimera avbrottsfrekvenser med hjälp av kategorierna, så är det alltid ganska stor osäkerhet på dessa skattningar och därför också på resultatet. Siffrorna anger oftast endast storleksordningen av de olika risker, inte de exakta värdena. Samtidigt är det de bästa estimeringar som finns, och det är bättre än inga estimeringar alls. För alla skattningar är det däremot mycket viktigt att notera hur och av vem dessa har tagits fram, samt eventuellt hur stor osäkerheten på dessa skattningar är.

8 En viktig fördel med metoden är också att stora delar av tidigare analyser kan återanvändas när nya system analyseras, eftersom en del komponenter (som till exempel serverrummet och nätverket) är gemensamma för flera kritiska system. En nackdel med metoden är att det är svårare att också räkna in risken med planerade avbrott. Dessa uppträder inte lika slumpmässigt som oplanerade avbrott och kan därför inte analyseras på samma sätt. Risken för planerade avbrott och nya problem som uppstår i samband med underhåll på systemet behöver därför analyseras separat. Till slut är det också viktigt att påpeka att denna analys enbart är en liten del i informationssäkerhetsarbetet med systemet. Det är viktigt att resultatet av analysen integreras i riskanalysen för verksamheten som är beroende av det analyserade systemet. Enbart i sammanhanget med en större risk- och sårbarhetsanalys av verksamheten kan beslut tas om tillförlitligheten av det analyserade systemet är tillräckligt bra eller inte.