Riskanalys Marcus Bendtsen Institutionen för Datavetenskap (IDA) Avdelningen för Databas- och Informationsteknik (ADIT) Risk • risk = konsekvens * sannolikheten • Den klassiska definitionen ger oss en grund att stå på, även om man ibland delar upp dessa: • Sannolikhet är en kombination av brist, hot och sannolikheten för hotet. • Konsekvensen kan vara av olika arter, t ex pengar, förtroende, lagbrott, etc. Exempel: Varje rad i vår databas är värd 0.01kr när den är skyddad. Det finns 10 000 rader i databasen. Sannolikheten för att någon får tag i vår databas är 0.5, då får vi en risk på: (0.01kr * 10000) * 0.5 = 50kr. Om någon då försöker sälja ett skydd till oss för 100kr så skulle vi i praktiken förlora 50kr på den affären, men om någon vill sälja ett skydd för 20kr så kanske vi är intresserade att skydda resterande 30kr. 2 Riskanalys • Riskanalys är en process där vi försöker hitta varje enstaka fall som kan gå fel, och kvantifiera risken med vår ekvation. • 3 risk = konsekvens * sannolikhet • Utmaningen är att göra detta på ett organiserat sätt så att man hittar så många fall som möjligt, samt att kvantifieringen blir korrekt (det är inte alltid möjligt att använda siffror). • Man kan inte hitta alla fall, eftersom ingen enstaka individ eller grupp har full insyn i alla delar av ett system. Riskanalys - Svårigheter • Riskanalys är svårt. • Ibland är det inte så svårt att ta reda på konsekvenserna, ofta har man ganska bra koll på vad det skulle innebära om hotet förverkligas (men inte alltid). • Det är dock svårt att bedöma sannolikheten korrekt. • 4 • Ett system kan bli mål för attacker från någon som testar samma attack på massor med system eller av någon som valt att specifikt attackera det system man skyddar. • Sannolikheten för att hotet realiseras är då väldigt annorlunda. Att bedöma sannolikheten fel kanske gör att man sätter en för hög sannolikhet på ett hot, vilket innebär att man tar resurser från ett hot som man bedömt har lägre sannolikhet (men som i egentligen har högre). Riskanalysmetoder • 5 Man måste avgränsa sin analys beroende på komplexiteten av systemet. • Man kan inte undersöka alla detaljer in i minsta nivå, man hamnar då i en sorts ”analysis paralysis”. • An annan typ av ”analysis paralysis” är när man är klar med sin analys, men tycker att man behöver göra mer, och mer, och mer … • Detaljnivån måste begränsas: Tänker du bara ta hänsyn till vilka processer som körs på datorn, eller tänker du titta på deras källkod och konfiguration också? • Kvalitativ eller kvantitativ: Kommer du använda faktiska siffror för att avgöra konsekvens och sannolikhet, eller tänker du gradera dessa med t ex låg-medel-hög? Riskanalysmetoder 6 • Det finns många metoder för riskanalys. • Problemet som alla metoder har är att de förväntar sig att personen som genomför analysen hittar alla brister, hot, fall, etc. • Detta kommer leda till att subjektiva åsikter blir en del av analysen: vissa kommer väga konsekvensen och/eller sannolikheten av ett hot annorlunda. • Men det finns ingen perfekt matematisk modell som vi kan applicera på problemet, det finns ingen funktion som ger oss svaret på denna fråga, så analysen kommer alltid ha brister. • Vissa metoder förespråkar ”brainstorming” i grupp, så att analysen görs av flera personer. Tanken är att man hittar hot, men det finns givetvis gruppdynamiska problem (t ex att den som pratar högst får rätt, ”Det där har aldrig hänt förut!”). Riskanalysmetoder – Denna föreläsning • I denna föreläsning kommer vi att titta på tre olika riskanalysmetoder: • CORAS • Information Security Risk Analysis Method (ISRAM) • Attack Träd 7 CORAS 8 CORAS • CORAS ger användaren ett språk för att modellera hot och risker. • CORAS består av 7 steg, där varje steg kommer närmare en identifiering och kvantifiering av riskerna (i viss litteratur lägger man till ett 8:e steg, vi gör inte det). • F. den Braber, I. Hogganvik, M. S. Lund, K. Stølen, F. Vraasen, "Model-based security analysis in seven steps - a guided tour to the CORAS method" Absolut nödvändig litteratur för projekt och tentamen 9 CORAS – Steg 1 • Kunder = De som äger systemet som skall säkras. • Säkerhetsexperter = De som skall göra riskanalysen. Kan vara utomstående eller anställda på samma företag som kunderna. • I ett möte mellan säkerhetsexperterna och kunderna kommer man fram till exakt vad det är som skall säkras. • Vi ska säkra något, men vad är detta något. • Vi måste tydligt veta vilka tillgångar som skall skyddas innan vi kan analysera vad som möjligtvis hotar dessa tillgångar. • Vi måste också avgöra hur långt vi ska gå med analysen (dvs finns det delar som vi ska anta är säkra eller som inte ska ingå i denna analys). 10 CORAS – Steg 1 Model-based security analysis in seve analysis leader (req analysis secretary ( representatives of — decision maker — technical exper — users (optional) Modelling guideline: system description — at this stage describe the targe En “low-tech” bild över hur systemet ser ut tas fram i Steg 1. Här kan man ta med ävenpictures or sketche Fig 2 Picture of the target. saker som inte ska säkras. I detta exempel ska inte kopplingen mot databasen säkras,— men the presentati den är ändå med i bilden. 11 the picture we see that speech and other data from the examination of a patient is streamed over a dedicated network, while access to the patient’s health record (stored in a database at the regional hospital) is given more formal mod data-flow diagram CORAS – Steg 2 • Systemet formuleras formellt i UML diagram av säkerhetsexperterna (class, collaboration, activity). • Säkerhetsexperterna tar också fram ett CORAS asset diagram. • Direct assets och indirect assets. • Indirect assets är tillgångar som skadas genom att en direct asset blir skadad. • Pilar visar hur skada på tillgångar påverkar varandra. • Ett nytt möte mellan kunder och säkerhetsexperter där experterna visar diagram och kunderna har möjlighet att göra ändringar. 12 medical equipment cardiologist terminal GP terminal dedicated connection cardiologist GP ased security analysis in seven steps — a guided tour to the CORAS method CORAS – Steg 2 Fig 3 Class diagram showing a conceptual view of the target. Internet hardware communication firewall database focus :medical equipment focus terminal :cardiologist terminal :GP terminal medical equipment cardiologist terminal GP terminal :firewall dedicated connection Fig 4 Class diagram showing a conceptual view of the target. Class diagram hardware communication :medical equipment 13 :GP terminal :database cardiologist GP Fig 3 :firewall CollaborationCollaboration diagram illustrating the physical communication lines. diagram stakeholder that is initiating and paying for the analysis), and its four assets: ‘Health records’, ‘Provision of telecardiology service’, ‘Patient’s health’ and ‘Public’s trust in system’. Because trust and health are difficult to measure, especially in a technical setting like this, the focus analysis leader makes a distinction between direct and indirect assets. He explains direct assets as assets that may be harmed directly by an unwanted incident, while the indirect assets are only harmed if one of the direct :cardiologist assets terminalis harmed first. In the asset diagram the direct assets are placed within the target of analysis region and the indirect are placed outside. in Fig 6 symbolise the client’s, or other intere parties’, relation to the assets. After agreeing on the assets, the analysts condu high-level analysis together with the analysis p ticipants. The short brainstorming should identify most important threats and vulnerabilities, but with going into great detail. In this case the client is concer about hackers, eavesdroppers, system failure whether the security mechanisms are sufficient. These threats and vulnerabilities do not necess involve major risks, but give the analysis leader valu being harm log out log out — indicate assets, Model-based security analysis in seven steps — a guided tour to the CORAS method cardiologist GP Step 2 — summary CORAS – Steg 2 Tasks: log on — assets m log on Fig 5 Activity diagram describing the parallel processes of the GP and the cardiologist. the target as understood by the analysts is presented, the assets are identified, a high-level analysis is conducted. retrieve health record People that should be present: security analysis leader (required), establish connection acknowledge connection connect medical equipment open health record review examination — technical expertise (required), Modelling guidelines: patient’s health health records — place the direct assets within the region, Direct provision of telecardiology service log out — indicate with arrows which assets may affect other assets, — assets may be ranked according to their importance, Fig 5 Activity Activity diagram describingdiagram the parallel processes of the GP and the cardiologist. 14 Ministry of Health public trust in system telecardiology service — place the indirect assets outside the region (indirect Asset part of assets are a harmed as aCORAS consequence of a6diagram directAsset asset(not Fig diagram. being harmed first), log out — create m features o configurati be work pro — decision makers (required), Indirect — draw a region that logically or physically represents the target of analysis, close connection — use a fo [1], but ens ly so that th representatives of the client: asset diagrams: update health record target desc Ministry of Health (client) security analysis secretary (required), — users (optional). examine patient — if the an should be a — if the analysis has more than one client, the clients should be associated with their assets, target descriptions: — use a formal or standardised notation such as UML UML) — for the diagrams a notations) a — for the d diagrams a notations). CORAS – Steg 2 • När man har kommit överens om i detalj vilka tillgångar som skall skyddas har man en brainstorming session (både kunder och säkerhetsexperter). • Det viktiga är att få fram vilka hot som klienten är orolig för, t ex att någon ser/hör något de inte får, hackare som får tillgång till information, etc. • Dessa hot är inte nödvändigtvis de som är viktigast, men det är en utgångspunkt för säkerhetsexperterna. • En risktabell skapas. 15 Model-based security analysis in seven steps — a guided tour to the CORAS method CORAS – Steg 2 Table 1 threat scenario threat (deliberate) threat (accidental) High-level risk table. unwanted incident asset threat (non-human) Who/what causes it? How? What is the incident? What does it harm? vulnerability What makes it possible? Hacker Breaks into the system and steals health records Insufficient security Employee Sloppiness compromises confidentiality of health records Insufficient training Eavesdropper Eavesdropping on dedicated connection Insufficient protection of connection System failure System goes down during examination Unstable connection/immature technology Employee Sloppiness compromises integrity of health record Prose-based health records (i.e. natural language) Network failure Transmission problems compromise integrity of medical data Unstable connection/immature technology Employee Health records leak out by accident — compromises their confidentiality and damages the trust in the system Possibility of irregular handling of health records 4. Step 3 — approval Risktabell The last of the preparatory steps is the approval step. The approval is often conducted as a separate meeting, but may also take place via e-mail. The main goal is to finalise the 16 documentation and characterisation of target and assets, and get this formally approved by the client. At the end of this meeting there should be a document (possibly with a list A risk is the potential for an unwanted incident to have an impact upon objectives (assets) [4], or in other words to reduce the value of at least one of the identified assets. Often the client accepts some risks that are not judged to be critical rather than eliminating or reducing them. This may be because of shortage of resources to implement changes, conflicting concerns, or the CORAS – Steg 3 • Sista steget i förberedelserna. • Det skall i slutet av detta steg finnas ett antal dokument som fått godkännande av alla parter. • Fyra ytterligare dokument måste man komma överens om: • Sortering av tillgångar (vilka risker är viktigast) • Konsekvens-skalor (ibland flera beroende på vilka typer av tillgångar, det är lätt att sätta ett numeriskt värde på pengar och svårt/omöjligt på andra). • Sannolikhetsskalor (tid: år, veckor, timmar, etc. eller sannolikheter: 10%,20%,1%). • Riskutvärderingsmatris 17 riteria. The pts for each ted the omments nd asset cussions he highe of the inition. of the and ata in ment. to be or consequence they have on the assets. The analysts until the maximum possible number of incidents per year initiate the discussion by suggesting scale of is reached. Because assets of differenta types arelikelihood involved, intervals have an increasing number of expected events based on the following rule of thumb — the lower they make separate consequence scales for each of the until the maximum possible number of incidents per year incident likelihood ‘rare’ set tothe be aconsequence maximum of scale one direct assets. Table 3 is shows is reached. Because assets of different types are involved, occurrence the target’s lifetime; the remaining defined for during the asset ‘Health records’ in terms of number they make separate consequence scales for each of the of health records affected. If feasible, the consequence direct assets. Table 3 shows the consequence scale description for an asset Table 2 may Assetinclude table. more than one defined for the asset ‘Health records’ in terms of number measure, e.g. ‘major’ could be the number of disclosed of health records affected. If feasible, the consequence health or the number of deleted records, etc. Asset records, Typeone description for an asset Importance may include more than Table 4 gives likelihood defined forofthedisclosed target as measure, e.g. the ‘major’ could scale be the number Health records 2 Direct asset such. By usingorthe scale for all scenarios and health records, thesame number of deleted records, etc. incidents, it the is possible extract combinedDirect likelihood Table 4ofgives likelihoodtoscale target as Provision 3 defined for the asset values as shown later in the risk estimation step. telecardiology service the same scale for all scenarios and such. By using assets as well. the participants decide to thisfor matrix cover the the other After completing thislettask all assets analysts assets as well. and the participants have the framework and vocabulary they need to start identifying threats (a potential cause After completing this task for all assets the analysts of an unwanted incident [5]), vulnerabilities (weaknesses and the participants have the framework and vocabulary which can be exploited by one or more threats [5]), they need to start identifying threats (a potential cause unwanted incidents and risks, and can move on to the of an unwanted incident [5]), vulnerabilities (weaknesses next step. which can be exploited by one or more threats [5]), CORAS – Steg 3 incidents, it is possible to extract combined likelihood values as shown later in the risk estimation step. Public’s trust in system (Scoped Indirect asset Table 3 Consequence scaleout) for ‘health records’. Consequence Description Indirect asset Patient’s healthvalue 1 Table 3 Consequence scale for ‘health(HRs) records’. Catastrophic 1000+ health records are affected Major Consequence value Moderate Catastrophic Minor Major Insignificant Moderate Minor Insignificant 100-1000 HRs are affected Description 10-100 HRs are affected 1000+ health records (HRs) are affected 1-10 HRs are affected 100-1000 HRs are affected No HRs HR isare affected 10-100 affected 1-10 HRs are affected No HRscale. is affected Table 4 Likelihood Likelihood Table 4 Likelihood scale.3 Description value Certain Five times or more per year (50-*: 10y = 5-*: 1y) Likelihood Description3 value Likely Two to five times per year (21-49: 10y = 2,1-4,9: 1y) Certain Five times or amore year10y (50-*: 10y = 1y) 5-*: 1y) Possible Once yearper (6-20: = 0,6-2: Likely TwoLess to five times 10y==0,2-0,5: 2,1-4,9:1y) 1y) Unlikely than onceper peryear year(21-49: (2-5: 10y Possible Onceonce a year 10y(0-1:10y = 0,6-2: 1y) Rare Less than per(6-20: ten years = 0-0,1:1y) 18Unlikely Less than once per year (2-5: 10y = 0,2-0,5: 1y) Rare Finally, Less once per ten years = 0-0,1:1y) the than representatives of (0-1:10y the client need to unwanted incidents and risks, and can move on to the Step — summary next 3step. Tasks: Prioriteringar Step 3 — summary Tasks: the client approves target descriptions and asset descriptions, the approves target according descriptions and asset theclient assets should be ranked to importance, descriptions, consequence scales must be set for each asset within the ranked according to importance, theassets scopeshould of thebe analysis, Konsekvensskalor, kan behövas consequence scalesmust must set for each asset within a likelihood scale bebedefined, the för scope of theassets analysis, olika olika the client must decide risk evaluation criteria for each a likelihood scale must be defined, asset within the scope of the analysis. the client must decide risk evaluation criteria for each Participants: asset within the scope of the analysis. the same as in the previous meeting, but, since this step Participants: sets the boundaries for the further analysis, it is Sannolikhetsskalor the same as inthat the previous meeting,decision-makers but, since this stepare important the relevant sets the boundaries for the further analysis, it is present. important that the relevant decision-makers are present. 5. Step 4 — risk identification To identify risks CORAS makes use of a technique called 5.structured Stepbrainstorming. 4 — risk identification Structured brainstorming may be a risk with a specific likelihood and consequence will belong to the intersecting cell. Based on a discussion in the group, the security analysis leader marks the cells in the matrix as ‘acceptable’ or ‘must be evaluated’. The resulting risk evaluation matrix is shown in Table 5, and risks than individuals or a more homogeneous group wou have managed. The findings from the brainstorming are documente with the CORAS security risk modelling language. We w now exemplify how we model risks with the CORA language, using the symbols presented in Fig 7. CORAS – Steg 3 50-*:10y is short for 50 or more incidents per 10 years, equivalent to 5 or ore incidents per year. Table 5 Risk evaluation matrix. Frequency Consequence Insignificant Minor Moderate Major Catastrophic Rare Acceptable Acceptable Acceptable Acceptable Must be evaluated Unlikely Acceptable Acceptable Acceptable Possible Acceptable Acceptable Likely Acceptable Certain Must be evaluated Must be evaluated Must be evaluated Must be evaluated Must be evaluated Must be evaluated Must be evaluated Must be evaluated Must be evaluated Must be evaluated Must be evaluated Must be evaluated Must be evaluated Must be evaluated Riskutvärderingsmatris BT Technology Journal • Vol 25 No 1 • January 200 Måste bestämma oss för vilka risker vi kan leva med och vilka som vi vill förhindra 19 CORAS – Steg 4 • Risk identifiering genom strukturerad brainstorming (bara experter). • En genomgång av systemet som skall analyseras. • Olika personer i gruppen har olika kompetens, bakgrund och intressen. (Behöver inte bara vara IT-personer) • Gruppen kommer hitta fler (och andra typer av) hot än vad en person själv skulle kunna göra. Model-based security analysis in seven steps — a guided tour to the CORAS method • Dokumenteras med CORAS security risk modelling language. logical or physical region threat (accidental) threat (deliberate) threat (non-human) threat scenario treatment scenario unwanted incident Fig 7 asset stakeholder vulnerability and or risk Symbols from the CORAS risk modelling language. 20 The analysis leader challenges the participants to work with questions such as: What are you most worried structured manner and the identified unwanted incidents are documented on-the-fly (using the guidelines CORAS – Steg 4 21 • Alla dokument som man skapat i steg 1, 2 och 3 används som input till brainstorming sessionen. • Dessutom har man förberett threat scenario diagrams (”hot scenario diagram”). • Dessa initiala dokument baseras på de hot som kunderna pekat ut i steg 2. • Dessa dokument uppdateras och görs större under sessionen. specific scenarios. Since people may be involved at different stages of the analysis, it is essential that information gathered during this session is documented in a simple and comprehensive way. The analysis leader uses the target models from Step 2 (FigsBrist 2, 3, 4 and 5) as input to the brainstorming session. The models are assessed in a stepwise and and sloppiness may compromise the integrity and confidentiality of the patient’s health records. The system also allows for irregular handling of health records where an employee may accidentally cause a leakage of records. A confidentiality or integrity breach may harm the health record in the sense that it is no longer secret nor correct. In the outmost consequence a faulty health record may affect the patient’s health. CORAS – Steg 4 . Hot scenario Incident telecardiology service insufficient training employee sloppy handling of records compromises confidentiality of health records patient’s health prose-based health records health record leakage compromises integrity of health records possibility of irregular handling of health records Fig 8 Indirekt Initial threat diagram — accidental actions. Initialt hot diagram för mänskliga misstag. 108 BT Technology Journal • Vol 25 No 1 • January 2007 22 health records Direkt CORAS – Steg 4 Model-based security analysis in seven steps — a guided tour to the CORAS method telecardiology service steals health records breaks into system insufficient security hacker eavesdropping on dedicated connection eavesdropper health records insufficient protection of connection Fig 9 telecardiology service 23 compromises confidentiality of data transmitted Initial threat diagram — deliberate actions. Initialt hot diagram för mänskliga attacker. immature technology system goes down during examination examination disrupted provision of telecardiology service eavesdropping on dedicated connection compromises confidentiality of data transmitted records insufficient protection of connection eavesdropper CORAS – Steg Initial threat diagram — deliberate4 actions. Fig 9 telecardiology service immature technology system goes down during examination examination disrupted system failure transmission problems network error compromises integrity of medical data unstable connection Fig 10 provision of telecardiology service health records Initial threat diagram — non-human threats. In the threat diagram describing deliberate harmful by employees’ accidental actions (Fig 8) receives much Initialt hot diagram för ”icke-mänskliga” hot. the participants and develops into actions caused by humans, the participants have attention among identified two main threats — hacker and eavesdropper Fig 11. (Fig 9). A hacker may exploit insufficient security Due to space limitations, we will not explore the other mechanisms to break into the system and steal health two threat diagrams further, but concentrate on just this records. An eavesdropper is a person that, due to one. insufficient protection of communication lines, may gather data that is transmitted and thereby compromise 24 CORAS – Steg 4 Model-based security analysis in seven steps — a guided tour to the CORAS method possibility of irregular handling of health records GP health records sent to unauthorised people compromises confidentiality of health records insufficient training health records health record copies stored on local computer prose-based health records wrong input in health record compromises integrity of health records no input validation misconfiguration of system IT personnel insufficient access control patient is given wrong diagnosis slow system unable to set diagnosis due to slow system lack of competence provision of telecardiology service telecardiology service Expanderat hot diagram för mänskliga misstag Fig 11 Final threat diagram — accidental actions.efter session. 25 people without the required competence become responsible for critical changes. This may lead to misconfiguration of the system, which again may slow it Modelling guideline: threat diagrams: patient’s health CORAS – Steg 5 • I en workshop uppskattar man sannolikheter och konsekvenser. • Varje deltagare i workshopen ger en sannolikhet till varje hot scenario. Ibland kan man använda existerande data. • Konsekvensen av hotet uppskattas och ett värde från konsekvensskalorna i steg 3 tillsätts varje hot scenario. • Dessa värden används sedan tillsammans med riskutvärderingsmatrisen för att avgöra om risken är värd att analysera vidare och åtgärda, eller om man bara ska acceptera risken. 26 ‘unwanted incident — asset’ relation. The consequence value is taken from the consequence scale of the asset decided in Step 3. In this workshop it is especially important to include people with the competence needed to estimate realistic likelihoods and consequences, meaning that technical expertise, users and decision makers must be included. method that is quite straightforward and transparent. The threat scenario ‘Health records sent out to unauthorised people’ and ‘Health record copies stored on local computer’ can both lead to ‘Compromises confidentiality of health records’. Table 6 shows how the combined likelihood is estimated. The technique is informal, but suitable for the Var creative försiktigstructured med detta! CORAS – Steg 5 possibility of irregular handling of health records GP health records sent to unauthorised people [rare] compromises confidentiality of health records [rare] insufficient training de mo health record copies stored on local computer [unlikely] compromises integrity of health records [possible] prose-based health records wrong input in health record [possible] IT personnel insufficient access control no input validation lack of competence mod er at misconfiguration of system [possible] slow system [possible] health records e rat patient is given wrong diagnosis [unlikely] catas troph Konsekvens ic unable to set diagnosis due to slow system [likely] mod erate provision of telecardiology service telecardiology service 27 e Fig 12 Threat diagram with likelihood and consequence estimates. r ajo m patient’s health In our case the risk value is determined by the risk evaluation matrix. From the four unwanted incidents in the threat diagram, the analysis secretary extracts five g. For more precise calculation of risks. ‘Compromising the confidentiality of health e analysis (FTA)[6] may be used. It is records’ (CC1) may affect health records. ‘Compromising that the combined estimates reflect the integrity of health records’ may also harm health t the combined estimates should be records (CI1), in addition to patient’s health if it ticipants for validation. contributes to a faulty diagnosis (PR1). Finally, ‘slow system’ may slow down an examination (SS2) and harm e participants reject the suggested • Risk evaluering the patient’s health (SS1). Only CC1 is within acceptable promises confidentiality of health risk levels,confidentiality the rest needoffurther 7 shows • Extrahera health evaluation. records CC1Table = moderate / rare) t the likelihood is less than ‘unlikely’ risker (compromises the risks placed in the risk evaluation matrix. . unlikely interval. CORAS – Steg 6 • Använd tidigare tabeller och uppskattningar för att placera riskerna i riskutvärderingsmatrisen. Table 7 Risk evaluation matrix with risks consequence. Consequence nario must be given a likelihood wanted incident likelihoods based Faller utanför, are behöver inte arbetas vidare med. tween an unwanted incident and an en a consequence estimate. Rare Moderate Major Catastrophic CC1 Unlikely Possible Likely PR1 CI1, SS2 SS1 Certain • Kunden godkänner om denna matrisleader är ok gives eller inte, kan behövaan justera The analysis the participants opporkonsekvenser eller sannolikheter. tunity to adjust likelihood and consequence estimates, • risksom acceptance levels, makemed surederas that the results En sista bild över deand risker analyserats tastofram, respektive evaluering. reflect reality as much as possible. present: eader (required), Likelihood Insignificant Minor 28 ecretary (required), The participants request an overview of the risks. CORAS – Steg 6 Kommer alltså inte hanteras Model-based security analysis in seven steps — a guided tour to the CORAS method CC1 compromises confidentiality of health records [acceptable] health records GP CI1 compromises integrity of health records [unacceptable] PR1 patient is given wrong diagnosis [unacceptable] patient’s health SS2 unable to set diagnosis due to slow system [unacceptable] SS1 slow system [unacceptable] IT personnel provision of telecardiology service telecardiology service Fig 13 Risk overview. 29 People that should be present: 8. Step 7 — risk treatment CORAS – Steg 7 • Alla risker som man valt att hantera (dvs som faller på rätt plats i riskutvärderingsmatrisen) behöver behandlas. • I en workshop utvärderar man varje risk för att ta fram tillvägagångssätt som reducerar antingen konsekvensen eller sannolikheten för risken. • Vissa tillvägagångssätt kan vara dyrare än andra, och därför väger man även in ”cost-benefit”. • Till sist har man en plan för vilka metoder och tillvägagångssätt som är nödvändiga. Denna presenteras för kunden (eller en förenklad variant). 30 estimates should be dation. eject the suggested entiality of health is less than ‘unlikely’ the integrity of health records’ may also harm health records (CI1), in addition to patient’s health if it contributes to a faulty diagnosis (PR1). Finally, ‘slow system’ may slow down an examination (SS2) and harm the patient’s health (SS1). Only CC1 is within acceptable risk levels, the rest need further evaluation. Table 7 shows the risks placed in the risk evaluation matrix. CORAS – Steg 7 Table 7 Risk evaluation matrix with risks consequence. Consequence e given a likelihood likelihoods are based Likelihood Insignificant Minor anted incident and an ce estimate. Rare Moderate Major Catastrophic CC1 Unlikely Possible Likely PR1 CI1, SS2 SS1 Certain Detta måste vi alltså behandla. Vi behöver flytta SS1 till ett fält. The analysis leader gives the participants anvitt oppor- tunity to adjust likelihood and consequence estimates, and risk acceptance levels, to make sure that the results reflect reality as much as possible. Hur gör vi det? , Vi har två val, vi kan minska konsekvensen (dvs gå åt vänster) eller minska sannolikheten (dvs gå uppåt). The participants request an overview of the risks. They want to know who, or what, is initiating them and Det sista steget i analysen är att ta fram förslag secretary på hur vimodels flyttar de which assets they harm. The analysis therisker vi inte kan acceptera. risks with their associated risk values in a risk diagram according to the guidelines (see summary). The final risk diagram for unwanted incidents accidentally caused by he target (required), employees is shown in Fig 13. Since the risk of ed), 31 Model-based security analysis in seven steps — a guided tour to the CORAS method extend training programme (1 - 2 days) CORAS – Steg 7 CI1 GP insufficient training prose-based health records health record copies stored on local computer wrong input in health record compromises integrity of health records health records patient is given wrong diagnosis no input validation unable to set diagnosis due to slow system misconfiguration of system IT personnel insufficient access control PR1 SS2 slow system lack of competence SS1 provision of telecardiology service telecardiology service revise access lists 32 Fig 14 Treatment diagram. patient’s health CORAS - Summering • Det är många dokument, men när man följer en metod kan man inte ta bort bitar som man inte förstår eller tycker är direkt nödvändiga. • Läs artikeln ett par gånger, och när ni sedan själva applicerar CORAS kommer det bli tydligare hur det fungerar. • Tänk på att CORAS även kan vara del av tentamen. 33 Information Security Risk Analysis Method ISRAM 34 ISRAM - Introduktion • Fokuserar på ett hot och försöker uppskatta risken för detta: • Risken för att datorer på ett nätverk blir infekterade av virus. • Använder sig av speciellt utformade frågeformulär som besvaras av användare, experter, mm. • Svaren på frågeformuläret uppskattar risken för hotet (genom att uppskatta sannolikheten och konsekvensen). 35 ISRAM – Steg 1 och 2 • Steg 1 – Identifiera att det finns ett hot: virusinfektion. • Steg 2 – Identifiera faktorer som påverkar sannolikheten och konsekvensen av hotet, samt vikta dessa faktorer. 36 ISRAM – Steg 2 Sannolikhetsfaktorer Konsekvensfaktorer Typen av bifogade filer i mejl 3 Backup av filer 3 Antalet mejl per dag 1 Fysisk plats av filsystem 2 Antalet nedladdade filer per dag 1 Beroende av applikaCon 1 Källan av USB-‐sCckor 2 • Antalet faktorer för sannolikhet behöver inte vara samma som för konsekvens. • Fler vikter kan eventuellt användas, men det är svårt att särskilja på 3 och 4 i en 10 gradig skala. • Definitionen av vikterna kan variera. Vikt Förklaring 37 3 Faktorn påverkar risken direkt 2 Faktorn påverkar risken något 1 Faktorn påverkar risken indirekt ISRAM – Steg 3 • Steg 3 – Konvertera faktorer till frågor, skapa svarsalternativ till varje fråga och ge varje alternativ en poäng. Fråga A B C D Hur många mejl får du per dag? 0-‐10 (1) 11-‐30 (2) 31-‐40 (3) 41+ (4) Vems USB-‐sCckor Endast de jag får använder du? av företaget (0) Tar med mig hemifrån (4) Hur oQa gör du Varje dag (1) backuper av filer? Varje vecka (2) • • • 38 Aldrig (4) Poäng för svarsalternativet är i parenteserna (anges inte på formuläret som skickas). Blandar frågor angående sannolikhet och konsekvens. Poängen är 0 till 4. ISRAM – Steg 4 • Beräkna det minimala och det maximala antalet poäng som frågorna angående sannolikhet kan ge. • Beräkna det minimala och det maximala antalet poäng som frågorna angående konsekvens kan ge. • Skapa sedan intervall så att poäng kan konverteras till en skala från 1 till 5. Poäng Kvalita<v skala Kvan<ta<v skala Poäng Kvalita<v skala Kvan<ta<v skala 29-‐48 Väldigt låg sannolikhet 1 47-‐68 Försumbar konsekvens 1 49-‐68 Låg sannolikhet 2 69-‐90 Liten konsekvens 2 69-‐88 Medel sannolikhet 3 91-‐111 Förhöjd konsekvens 3 89-‐108 Hög sannolikhet 4 112-‐133 Allvarlig konsekvens 4 108-‐128 Väldigt hög sannolikhet 5 39 134-‐160 Mycket allvarlig konsekvens 5 ISRAM – Steg 4 • Skapa en slutgiltig risktabell. Risk = Sannolikhet x Konsekvens 1: Försumbar 2: Liten 3: Förhöjd 4: Allvarlig 5: Mycket allvarlig 1: Väldigt låg 1: Väldigt låg 2: Väldigt låg 3: Väldigt låg 4: Låg 5: Låg 2: Låg 2: Väldigt låg 4: Låg 6: Låg 8: Medel 10: Medel 3: Medel 3: Väldigt låg 6: Låg 9: Medel 12: Medel 15: Hög 4: Hög 4: Låg 8: Medel 12: Medel 16: Hög 20: Väldigt hög 5: Väldigt hög 5: Låg 10: Medel 15: Hög 20: Väldigt hög 25: Väldigt hög 40 ISRAM – Steg 5 och 6 • Steg 5 – Genomför undersökningen. Den kan skickas till användare av de datorer som är på det nätverk som man vill uppskatta risken för, eventuellt andra experter mfl. • Steg 6 – Använd en ekvation för att beräkna ett värde för risken (baserat på faktorerna för sannolikhet och konsekvens). Använd resultatet av ekvationen i risktabellen för att beräkna den slutgiltiga risken. 41 ISRAM – Steg 6 Risk = 42 N P [Ts ( n=1 I P i=1 N ! ↵i si,n )] N P n=1 [Tk ( J P j kj,n )] j=1 N ! • N = antal respondenter • I = antal frågor om sannolikhet • J = antal frågor om konsekvens • αi = vikten av sannolikhetsfråga i • si,n = poängen för det svarsalternativ som respondent n gett sannolikhetsfråga i • βj = vikten av konsekvensfråga j • kj,n = poängen för det svarsalternativ som respondent n get konsekvensfråga j • Ts en funktion som översätter ett heltal till sannolikhetsskalan 1 till 5 • Tk en funktion som översätter ett heltal till konsekvensskalan 1 till 5 ISRAM – Steg 6 Risk = N P n=1 [Ts ( I P i=1 N ! ↵i si,n )] N P [Tk ( n=1 J P j kj,n )] j=1 N ! Respondent Summan av sannolikhetsfrågor TS Summan av konsekvensfrågor TK 1 94 4 103 3 2 74 3 136 5 Medel: 3.5 Medel: 4 Risk = 3.5 * 4 = 14 vilket ligger mellan medium och hög risk, men närmare hög risk 43 ISRAM – Steg 7 • Steg 7 – Utvärdering av resultat 44 • Den slutgiltiga uppskattade risken är det viktigaste utfallet av metoden. • Risk uppskattningen kan användas för att ta beslut om man skall göra förändringar i policies och/eller mekanismer. • Samtidigt har man samlat in mycket information om användandet av systemet, t ex kan man få reda på om användare håller sina system kontinuerligt uppdaterade, om de använder adminkonton på rätt sätt, etc. • Den extra informationen är värdefull när det kommer till att bestämma vilka förändringar som bör göras. ISRAM - Slutsatser • ISRAM är användbart när man vill uppskatta risken för ett specifikt hot. • Det behövs bara en person som administrerar riskanalysen om det finns respondenter. (Det kan vara fördelaktigt att flera administrerar riskanalysen då man avgör poäng och vikter). • 45 Utfallet av riskanalysen är väldigt beroende på de vikter och poäng som sätts, och dessutom på vilka frågor som ställs (man kan inte få svar på frågor som man inte ställer). ATTACK TRÄD 46 Attack träd Representera attacker mot ett system i en trädstruktur, med målet av attacken som rotnod och de olika vägarna att lyckas med attacken som grenar och löv. 47 Attack Träd Open Safe Pick lock Learn combo Find written combo Threaten Blackmail Cut open Get combo from target Eavesdrop Listen to conversation 48 Install improperly Bribe Get target to state combo Attack Träd Open Safe Pick lock Learn combo Find written combo Threaten Blackmail Cut open Get combo from target Eavesdrop Bribe and Listen to conversation 49 Install improperly Get target to state combo Attack Träd P Open Safe I P Pick lock P Learn combo I Get combo from target I Threaten Install improperly Cut open P Find written combo I I I Blackmail P Eavesdrop Bribe and P I Listen to conversation 50 Get target to state combo Attack Träd P Open Safe $10 I P Pick lock $30 P Learn combo $20 I $20 $75 I Threaten $60 Cut open $10 $100 Get combo from target I Blackmail $100 P Eavesdrop $60 Bribe $20 and P Listen to conversation $20 51 Install improperly P Find written combo I I I Get target to state combo $40 Attack Träd • Vi kan annotera trädet med många olika typer av Booleska eller reella värden: • “Laglig” och “Ej laglig” • “Kräver special utrustning” och “Kräver ingen specialutrustning” • Sannolikheten för att man lyckas, sannolikheten av attack, etc. • När vi har annoterat trädet kan vi ställa frågor: • Vilken attack kostar mindre än $10? • Vilka lagliga attacker kostar mer än $50? • Är det värt att betala en person $80 för att öka motståndskraften mot korruption? 52 Attack Träd • Identifiera målen (rotnoderna). • Varje mål blir ett eget träd. • Lägg till alla attacker som du kan komma på som löv till rotnoden. • Expandera varje attack som om den vore ett mål i sig själv. • Låt någon annan titta på ditt träd, få kommentarer från andra experter, iterera… • Behåll träden uppdaterade och använd de när du tar beslut om säkerhetspolicies och mekanismer. 53 Riskanalys - Summering Riskanalysen är en grundsten: • Utveckling av programvara kräver att man först gör en riskanalys för att identifiera områden som kräver extra försiktighet. • Expansion av ett företag till nya miljöer kräver riskanalys av fysisk säkerhet. • Byte av nätverkssystem kräver riskanalys för att identifiera vilka sektioner och säkerhetsnivåer som behövs. • … 54 Riskanalys - Summering • Många olika metoder existerar, gäller att hitta den som passar resurserna och målet. • CORAS, ISRAM och Attack Träd har alla sina egna för- och nackdelar. • Riskanalys är svårt, väldigt svårt, och en lyckad analys är beroende av experterna som genomför den. • Att begränsa analysen, ta hjälp av andra experter och att vara organiserad är viktigt för att öka möjligheterna för en lyckad analys. 55 www.liu.se
© Copyright 2024