riskanalys - IDATDDD82/slides/security/riskanalys.pdf · • 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

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. •  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.

3

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.

•  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).

4

Riskanalysmetoder

•  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?

5

Riskanalysmetoder

•  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!”).

6

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"

9

Absolut nödvändig litteratur för projekt och tentamen

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

11

Model-based security analysis in seven steps — a guided tour to the CORAS method

BT Technology Journal • Vol 25 No 1 • January 2007 103

the picture we see that speech and other data from theexamination of a patient is streamed over a dedicatednetwork, while access to the patient’s health record(stored in a database at the regional hospital) is giventhrough an encrypted channel over the Internet. Next inline after the IT manager is the medical doctor from thePHCC. She talks about her personal experiences fromusing the system.

After the presentations, a discussion on the scope andfocus of the analysis follows. The representative of theministry emphasises that they are particularly worriedabout the confidentiality and integrity of the healthrecords and other medical data, first and foremost for thesake of the patients’ health, but also because of thepublic’s trust in the national healthcare system. For themedical doctor the most important thing is the patient’shealth and well-being, and hence the availability andintegrity of the telemedicine system. The IT managerexplains that they have already made a security analysisof the health record database and the encrypted access,so she is confident that this part of the system is secureand reliable. After some discussion the representative ofthe ministry decides that the focus will be onconfidentiality and integrity of medical data, and theavailability of the service, but that the access to thehealth record database is outside the scope of analysis.

As the last point on the agenda, the participants setup a plan for the rest of the analysis with dates andindications of who should be present.

Step 1 — summaryTasks:

x the security analysis method is introduced,

x the client presents the goals and the target of theanalysis,

x the focus and scope of the analysis is set,

x the meetings and workshops are planned.

People that should participate:

x analysis leader (required),

x analysis secretary (required),

x representatives of the client:

— decision makers (required),

— technical expertise (optional),

— users (optional).

Modelling guideline:

x system description:

— at this stage of the analysis it can be useful todescribe the target with informal models like drawings,pictures or sketches on a blackboard,

— the presentation can later be supplemented withmore formal modelling techniques such as UML ordata-flow diagrams.

3. Step 2 — high-level analysisThe second step is called the high-level analysis, and as thename indicates this involves conducting an initial analysis ofthe target. This step also typically involves a meetingbetween the analysts and the representatives of the client.The main purpose is to identify assets and get an overview ofthe main risks. Finding the assets that need protection isinitiated in step 2 and completed in step 3. The remainingfour steps of the analysis will be directed towards theseassets. The outcome of the high-level analysis helps theanalysts to identify the aspects of the target having the mosturgent need for in-depth analysis, and hence makes it easierto define the exact scope and focus of the full analysis.

The second meeting starts with the security analysisleader presenting the analysts’ understanding of thetarget to be analysed. The information presented by theclient at the previous meeting, as well as documentationreceived in the mean time, has been formalised in UMLdiagrams [1] . The UML class diagram (Fig 3) shows therelevant concepts and how they relate, while the UMLcollaboration diagram (Fig 4) illustrates the physicalorganisation of the target. Furthermore, the medicaldoctor’s description of use has been captured as a UMLactivity diagram (Fig 5). During this presentation theparticipants representing the client make corrections andeliminate errors, so that the result is a target descriptionall parties can agree upon. In the class and collaborationdiagrams the security analysis leader has also indicatedwhat areas are understood to be the focus of the analysis.

After agreeing on a target description, the analysismoves on to asset identification. An asset is something inor related to the target to which the client assigns greatvalue. Based on the discussion at the introductorymeeting, the analysis leader has prepared an initial‘CORAS asset diagram’ (Fig 6) to help with specifying thescope of the analysis. The asset diagram shows theNational Ministry of Health as the client (i.e. the

Fig 2 Picture of the target.En “low-tech” bild över hur systemet ser ut tas fram i Steg 1. Här kan man ta med även saker som inte ska säkras. I detta exempel ska inte kopplingen mot databasen säkras, men den är ändå med i bilden.

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

CORAS – Steg 2

13


BT Technology Journal • Vol 25 No 1 • January 2007104

stakeholder that is initiating and paying for the analysis),and its four assets: ‘Health records’, ‘Provision oftelecardiology service’, ‘Patient’s health’ and ‘Public’strust in system’. Because trust and health are difficult tomeasure, especially in a technical setting like this, theanalysis leader makes a distinction between direct andindirect assets. He explains direct assets as assets thatmay be harmed directly by an unwanted incident, whilethe indirect assets are only harmed if one of the directassets is harmed first. In the asset diagram the directassets are placed within the target of analysis region andthe indirect are placed outside.

The arrows show dependencies between the assets,such that, for example harm to ‘Health records’ maycause harm to ‘Public’s trust in system’. The dashed lines

in Fig 6 symbolise the client’s, or other interestedparties’, relation to the assets.

After agreeing on the assets, the analysts conduct ahigh-level analysis together with the analysis par-ticipants. The short brainstorming should identify themost important threats and vulnerabilities, but withoutgoing into great detail. In this case the client is concernedabout hackers, eavesdroppers, system failure andwhether the security mechanisms are sufficient.

These threats and vulnerabilities do not necessarilyinvolve major risks, but give the analysis leader valuableinput on where to start the analysis. The analysissecretary documents the results by filling in the high-level risk table shown in Table 1 .

Fig 3 Class diagram showing a conceptual view of the target.

Fig 4 Collaboration diagram illustrating the physical communication lines.

firewall

GP

terminal

cardiologist

terminal

dedicated

connection

GP cardiologist

medical

equipment

Internet

database

terminal focus

:GP

terminal

:cardiologist

terminal

:firewall:firewall :database

:medical

equipment

hardware communication

focus



stakeholder that is initiating and paying for the analysis),and its four assets: ‘Health records’, ‘Provision oftelecardiology service’, ‘Patient’s health’ and ‘Public’strust in system’. Because trust and health are difficult tomeasure, especially in a technical setting like this, theanalysis leader makes a distinction between direct andindirect assets. He explains direct assets as assets thatmay be harmed directly by an unwanted incident, whilethe indirect assets are only harmed if one of the directassets is harmed first. In the asset diagram the directassets are placed within the target of analysis region andthe indirect are placed outside.

The arrows show dependencies between the assets,such that, for example harm to ‘Health records’ maycause harm to ‘Public’s trust in system’. The dashed lines

in Fig 6 symbolise the client’s, or other interestedparties’, relation to the assets.

After agreeing on the assets, the analysts conduct ahigh-level analysis together with the analysis par-ticipants. The short brainstorming should identify themost important threats and vulnerabilities, but withoutgoing into great detail. In this case the client is concernedabout hackers, eavesdroppers, system failure andwhether the security mechanisms are sufficient.

These threats and vulnerabilities do not necessarilyinvolve major risks, but give the analysis leader valuableinput on where to start the analysis. The analysissecretary documents the results by filling in the high-level risk table shown in Table 1 .

Fig 3 Class diagram showing a conceptual view of the target.

Fig 4 Collaboration diagram illustrating the physical communication lines.

firewall

GP

terminal

cardiologist

terminal

dedicated

connection

GP cardiologist

medical

equipment

Internet

database

terminal focus

:GP

terminal

:cardiologist

terminal

:firewall:firewall :database

:medical

equipment

hardware communication

focus

Class diagram Collaboration diagram

CORAS – Steg 2

14

Activity diagram

CORAS Asset diagram (not part of UML)




x the target as understood by the analysts is presented,

x the assets are identified,

x a high-level analysis is conducted.

People that should be present:

x security analysis leader (required),

x security analysis secretary (required),



— technical expertise (required),


Modelling guidelines:

x asset diagrams:

— draw a region that logically or physically representsthe target of analysis,

— place the direct assets within the region,

— place the indirect assets outside the region (indirectassets are a harmed as a consequence of a direct assetbeing harmed first),

— indicate with arrows which assets may affect otherassets,

— assets may be ranked according to their importance,

— if the analysis has more than one client, the clientsshould be associated with their assets,

x target descriptions:

— use a formal or standardised notation such as UML[1], but ensure that the notation is explained thorough-ly so that the participants understand it,

— create models of both the static and the dynamicfeatures of the target (static may be hardwareconfigurations, network design, etc, while dynamic maybe work processes, information flow, etc),

— for the static parts of the description UML classdiagrams and UML collaboration diagrams (or similarnotations) are recommended,

— for the dynamic parts we recommend UML activitydiagrams and UML sequence diagrams (or similarnotations).

log on

acknowledgeconnection

open healthrecord

reviewexamination

log on

retrieve healthrecord

connect medicalequipment

update healthrecord

closeconnection

establishconnection

examinepatient

log out log out

GP cardiologist

Fig 5 Activity diagram describing the parallel processes of the GP and the cardiologist.

patient’shealth

healthrecords

provision oftelecardiology

service

public trustin system

Ministryof Health

(client)

telecardiologyservice

Fig 6 Asset diagram.




x the target as understood by the analysts is presented,

x the assets are identified,

x a high-level analysis is conducted.









x asset diagrams:

— draw a region that logically or physically representsthe target of analysis,

— place the direct assets within the region,

— place the indirect assets outside the region (indirectassets are a harmed as a consequence of a direct assetbeing harmed first),

— indicate with arrows which assets may affect otherassets,

— assets may be ranked according to their importance,

— if the analysis has more than one client, the clientsshould be associated with their assets,

x target descriptions:

— use a formal or standardised notation such as UML[1], but ensure that the notation is explained thorough-ly so that the participants understand it,

— create models of both the static and the dynamicfeatures of the target (static may be hardwareconfigurations, network design, etc, while dynamic maybe work processes, information flow, etc),

— for the static parts of the description UML classdiagrams and UML collaboration diagrams (or similarnotations) are recommended,

— for the dynamic parts we recommend UML activitydiagrams and UML sequence diagrams (or similarnotations).

log on

acknowledgeconnection

open healthrecord

reviewexamination

log on

retrieve healthrecord

connect medicalequipment

update healthrecord

closeconnection

establishconnection

examinepatient

log out log out

GP cardiologist

Fig 5 Activity diagram describing the parallel processes of the GP and the cardiologist.

patient’shealth

healthrecords


service

public trustin system

Ministryof Health

(client)


Fig 6 Asset diagram.

Indirect

Direct

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

CORAS – Steg 2

16



4. Step 3 — approvalThe 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

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

of required changes) to which all parties agree and commit.

The approval also involves defining consequence scales (for

each asset) and a likelihood scale. Multiple consequence

scales are used when it is difficult or inappropriate to

measure damage to all assets according to the same scale,

e.g. it is easier to measure ‘income’ in monetary values than

‘company brand’.

There should only be one likelihood scale appropriate for

the analysis scope, e.g. based on a time-interval (years,

weeks, hours, etc) or probabilities. The last activity of the

approval is to decide upon the risk evaluation criteria. The

criteria states which level of risk the client accepts for each

of the assets.

The security analysis leader has updated the

presentation from the last meeting based on comments

from the other participants, and the target and asset

descriptions are now approved. Based on the discussions

in the first two meetings and issues identified in the high-

level analysis, it is decided to narrow the scope of the

analysis, and agree upon the following target definition.

The target of analysis will be the availability of the

telecardiology service, and confidentiality and

integrity of health records and medical data in

relation to use of the service and related equipment.

The indirect asset ‘Public’s trust in system’ is to be

kept outside the scope.

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

treatment costs will be greater than the benefits. As a

first step towards distinguishing risks that can be

accepted from those that cannot, the representatives

from the client are asked to rank the assets according to

their importance (1 = very important, 5 = minor impor-

tance) and fill in the asset table (Table 2). Then the final

treatment step can address the risks for the most

important asset first.

Having finished the asset table, they go on to define

the likelihood scale (a general description of frequency or

probability [4]) of which incidents occur, and the impact

or consequence they have on the assets. The analysts

initiate the discussion by suggesting a scale of likelihood

based on the following rule of thumb — the lower

incident likelihood ‘rare’ is set to be a maximum of one

occurrence during the target’s lifetime; the remaining

Table 1 High-level risk table.

Who/what causes it? How? What is the incident? What does it harm? 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

threat

(accidental)

threat

(deliberate)

threat

(non-human)

threat

scenario

asset

unwanted

incident

vulnerability

Table 2 Asset table.

Asset Importance Type

Health records 2 Direct asset

Provision of

telecardiology service

3 Direct asset

Public’s trust in system (Scoped out) Indirect asset

Patient’s health 1 Indirect asset

Risktabell

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

CORAS – Steg 3

18



4. Step 3 — approvalThe 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

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

of required changes) to which all parties agree and commit.

The approval also involves defining consequence scales (for

each asset) and a likelihood scale. Multiple consequence

scales are used when it is difficult or inappropriate to

measure damage to all assets according to the same scale,

e.g. it is easier to measure ‘income’ in monetary values than

‘company brand’.

There should only be one likelihood scale appropriate for

the analysis scope, e.g. based on a time-interval (years,

weeks, hours, etc) or probabilities. The last activity of the

approval is to decide upon the risk evaluation criteria. The

criteria states which level of risk the client accepts for each

of the assets.

The security analysis leader has updated the

presentation from the last meeting based on comments

from the other participants, and the target and asset

descriptions are now approved. Based on the discussions

in the first two meetings and issues identified in the high-

level analysis, it is decided to narrow the scope of the

analysis, and agree upon the following target definition.

The target of analysis will be the availability of the

telecardiology service, and confidentiality and

integrity of health records and medical data in

relation to use of the service and related equipment.

The indirect asset ‘Public’s trust in system’ is to be

kept outside the scope.

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

treatment costs will be greater than the benefits. As a

first step towards distinguishing risks that can be

accepted from those that cannot, the representatives

from the client are asked to rank the assets according to

their importance (1 = very important, 5 = minor impor-

tance) and fill in the asset table (Table 2). Then the final

treatment step can address the risks for the most

important asset first.

Having finished the asset table, they go on to define

the likelihood scale (a general description of frequency or

probability [4]) of which incidents occur, and the impact

or consequence they have on the assets. The analysts

initiate the discussion by suggesting a scale of likelihood

based on the following rule of thumb — the lower

incident likelihood ‘rare’ is set to be a maximum of one

occurrence during the target’s lifetime; the remaining

Table 1 High-level risk table.

Who/what causes it? How? What is the incident? What does it harm? 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

threat

(accidental)

threat

(deliberate)

threat

(non-human)

threat

scenario

asset

unwanted

incident

vulnerability

Table 2 Asset table.

Asset Importance Type

Health records 2 Direct asset

Provision of

telecardiology service

3 Direct asset

Public’s trust in system (Scoped out) Indirect asset

Patient’s health 1 Indirect asset



intervals have an increasing number of expected events

until the maximum possible number of incidents per year

is reached. Because assets of different types are involved,

they make separate consequence scales for each of the

direct assets. Table 3 shows the consequence scale

defined for the asset ‘Health records’ in terms of number

of health records affected. If feasible, the consequence

description for an asset may include more than one

measure, e.g. ‘major’ could be the number of disclosed

health records, or the number of deleted records, etc.

Table 4 gives the likelihood scale defined for the target assuch. By using the same scale for all scenarios and

incidents, it is possible to extract combined likelihood

values as shown later in the risk estimation step.

Table 3 Consequence scale for ‘health records’.

Table 4 Likelihood scale.

Finally, the representatives of the client need to

define the risk evaluation criteria, the criteria which

assert whether a risk to an asset is acceptable or whether

it is necessary to evaluate possible treatments for it. Theydefine these criteria by means of a risk evaluation matrix

for each asset. The security analysis leader draws the

matrix for the asset ‘Health records’ on a blackboard. It

has likelihood and consequence values as its axes so that

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

the participants decide to let this matrix cover the other

assets as well.

After completing this task for all assets the analysts

and the participants have the framework and vocabulary

they need to start identifying threats (a potential cause

of an unwanted incident [5]), vulnerabilities (weaknesses

which can be exploited by one or more threats [5]),

unwanted incidents and risks, and can move on to the

next step.


x the client approves target descriptions and asset

descriptions,

x the assets should be ranked according to importance,

x consequence scales must be set for each asset within

the scope of the analysis,

x a likelihood scale must be defined,

x the client must decide risk evaluation criteria for each

asset within the scope of the analysis.

Participants:

x the same as in the previous meeting, but, since this step

sets the boundaries for the further analysis, it is

important that the relevant decision-makers are

present.

5. Step 4 — risk identificationTo identify risks CORAS makes use of a technique called

structured brainstorming. Structured brainstorming may be

understood as a structured ‘walk-through’ of the target of

analysis and is carried out as a workshop. The main idea of

structured brainstorming is that since the analysis par-

ticipants represent different competences, backgrounds and

interests, they will view the target from different perspec-

tives and consequently identify more, and possibly other,

risks than individuals or a more homogeneous group would

have managed.

The findings from the brainstorming are documented

with the CORAS security risk modelling language. We will

now exemplify how we model risks with the CORAS

language, using the symbols presented in Fig 7.

Consequence value DescriptionCatastrophic 1000+ health records (HRs) are affected

Major 100-1000 HRs are affected

Moderate 10-100 HRs are affected

Minor 1-10 HRs are affected

Insignificant No HR is affected

Likelihood value Description3

Certain Five times or more per year (50-*: 10y = 5-*: 1y)

Likely Two to five times per year (21-49: 10y = 2,1-4,9: 1y)

Possible Once a year (6-20: 10y = 0,6-2: 1y)

Unlikely Less than once per year (2-5: 10y = 0,2-0,5: 1y)

Rare Less than once per ten years (0-1:10y = 0-0,1:1y)

Table 5 Risk evaluation matrix.

ConsequenceInsignificant Minor Moderate Major Catastrophic

Freq

uenc

y

Rare Acceptable Acceptable Acceptable Acceptable Must be evaluated

Unlikely Acceptable Acceptable Acceptable Must be evaluated Must be evaluated

Possible Acceptable Acceptable Must be evaluated Must be evaluated Must be evaluated

Likely Acceptable Must be evaluated Must be evaluated Must be evaluated Must be evaluated

Certain Must be evaluated Must be evaluated Must be evaluated Must be evaluated Must be evaluated

3 50-*:10y is short for 50 or more incidents per 10 years, equivalent to 5 ormore incidents per year.































assets as well.







next step.



descriptions,







Participants:




present.










have managed.


















Freq

uenc

y







Prioriteringar

Konsekvensskalor, kan behövas olika för olika assets

Sannolikhetsskalor

CORAS – Steg 3

19































assets as well.







next step.



descriptions,







Participants:




present.










have managed.


















Freq

uenc

y







Riskutvärderingsmatris

Måste bestämma oss för vilka risker vi kan leva med och vilka som vi vill förhindra

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.

•  Dokumenteras med CORAS security risk modelling language.

20



The analysis leader challenges the participants towork with questions such as: What are you most worriedabout with respect to your assets (threat scenarios andunwanted incidents)? Who/what may initiate these(threats)? What makes this possible (vulnerabilities)? Thisinformation is modelled by the secretary in threatdiagrams.

The analysis leader has used this technique onnumerous occasions before, but does not use exactly thesame procedure in every case, adapting it to fit the targetdomain. Often it is useful to include checklists and ‘bestpractices’ for a specific technology or domain. In this caseIT experts and medical personnel (general practitioners)must participate in the brainstorming, but some will onlyparticipate when their competences are needed forspecific scenarios. Since people may be involved atdifferent stages of the analysis, it is essential thatinformation gathered during this session is documentedin a simple and comprehensive way.

The analysis leader uses the target models from Step2 (Figs 2, 3, 4 and 5) as input to the brainstormingsession. The models are assessed in a stepwise and

structured manner and the identified unwanted incidentsare documented on-the-fly (using the guidelinespresented in the summary).

A set of initial threat scenario diagrams (Figs 8, 9and 10) has been prepared by the analysis secretary onthe basis of the high-level analysis table (Table 1). Theserepresent a starting point for discussion and are oftenunderspecified. She has decided to structure the threediagrams according to the ISO categorisation [5],describing the different types of threats — humanaccidental, human deliberate and non-human threats(environmental).

The threat diagram in Fig 8 shows how a combinationof insufficient training or prose-based health records,and sloppiness may compromise the integrity and con-fidentiality of the patient’s health records. The systemalso allows for irregular handling of health records wherean employee may accidentally cause a leakage of records.A confidentiality or integrity breach may harm the healthrecord in the sense that it is no longer secret nor correct.In the outmost consequence a faulty health record mayaffect the patient’s health.

threat(accidental)

threat(deliberate)

threat(non-human)

asset stakeholder vulnerability

logical orphysicalregion

and orthreatscenario

treatmentscenario

unwantedincident

risk

Fig 7 Symbols from the CORAS risk modelling language.

.

Fig 8 Initial threat diagram — accidental actions.

employee

healthrecords

insufficienttraining sloppy handling

of recordscompromises

confidentiality ofhealth records

prose-basedhealth records

possibility of irregularhandling of health records

health recordleakage compromises

integrity ofhealth records

patient’shealth


CORAS – Steg 4

•  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.

21

CORAS – Steg 4

22



The analysis leader challenges the participants towork with questions such as: What are you most worriedabout with respect to your assets (threat scenarios andunwanted incidents)? Who/what may initiate these(threats)? What makes this possible (vulnerabilities)? Thisinformation is modelled by the secretary in threatdiagrams.

The analysis leader has used this technique onnumerous occasions before, but does not use exactly thesame procedure in every case, adapting it to fit the targetdomain. Often it is useful to include checklists and ‘bestpractices’ for a specific technology or domain. In this caseIT experts and medical personnel (general practitioners)must participate in the brainstorming, but some will onlyparticipate when their competences are needed forspecific scenarios. Since people may be involved atdifferent stages of the analysis, it is essential thatinformation gathered during this session is documentedin a simple and comprehensive way.

The analysis leader uses the target models from Step2 (Figs 2, 3, 4 and 5) as input to the brainstormingsession. The models are assessed in a stepwise and

structured manner and the identified unwanted incidentsare documented on-the-fly (using the guidelinespresented in the summary).

A set of initial threat scenario diagrams (Figs 8, 9and 10) has been prepared by the analysis secretary onthe basis of the high-level analysis table (Table 1). Theserepresent a starting point for discussion and are oftenunderspecified. She has decided to structure the threediagrams according to the ISO categorisation [5],describing the different types of threats — humanaccidental, human deliberate and non-human threats(environmental).

The threat diagram in Fig 8 shows how a combinationof insufficient training or prose-based health records,and sloppiness may compromise the integrity and con-fidentiality of the patient’s health records. The systemalso allows for irregular handling of health records wherean employee may accidentally cause a leakage of records.A confidentiality or integrity breach may harm the healthrecord in the sense that it is no longer secret nor correct.In the outmost consequence a faulty health record mayaffect the patient’s health.

threat(accidental)

threat(deliberate)

threat(non-human)

asset stakeholder vulnerability

logical orphysicalregion

and orthreatscenario

treatmentscenario

unwantedincident

risk

Fig 7 Symbols from the CORAS risk modelling language.

.

Fig 8 Initial threat diagram — accidental actions.

employee

healthrecords

insufficienttraining sloppy handling

of recordscompromises

confidentiality ofhealth records


possibility of irregularhandling of health records

health recordleakage compromises

integrity ofhealth records

patient’shealth


Initialt hot diagram för mänskliga misstag.

Brist

Hot scenario Incident

Direkt Indirekt

CORAS – Steg 4

23

Initialt hot diagram för mänskliga attacker.



In the threat diagram describing deliberate harmfulactions caused by humans, the participants haveidentified two main threats — hacker and eavesdropper(Fig 9). A hacker may exploit insufficient securitymechanisms to break into the system and steal healthrecords. An eavesdropper is a person that, due toinsufficient protection of communication lines, maygather data that is transmitted and thereby compromiseits confidentiality.

The participants also worry about threats like systemfailure and network failure (Fig 10). They fear thatunstable connections or immature technology arevulnerabilities that may lead to system crashes duringexamination or transmission problems. A transmissionproblem may interfere with the data that is stored in thesystem and leave the health records only partly correct.

During the brainstorming session the initial threatdiagrams are expanded with new information on-the-fly.If the amount of information is too large, the secretarymay choose to write it down or use audiovisualequipment to make sure that nothing is missed. Thediagrams may then be updated and completed after thesession. The threat diagram illustrating incidents caused

by employees’ accidental actions (Fig 8) receives muchattention among the participants and develops into Fig 11.

Due to space limitations, we will not explore the othertwo threat diagrams further, but concentrate on just thisone.

The participants decide that the threat ‘employee’must be specified into ‘general practitioner (GP)’ and ‘ITpersonnel’ since they may cause different incidents. If theGP has too little security training, she may store copies ofhealth records on a local computer. This may compromisethe integrity of the records and in the worst case lead toan erroneous diagnosis of a patient. The same incidentsmay also occur if the GP enters wrong information in thepatient’s health record. The system allows for irregularhandling of health records which makes it possible toaccidentally send records to unauthorised people. Thiswould compromise the confidentiality of the healthrecord. The policy of the IT personnel with respect toaccess control has been very ‘loose’. They explain thiswith their responsibility for making critical updates inemergencies and that they do not have the time to waitfor a person with correct access rights to show up. Anunfortunate consequence of this is that sometimes

Fig 9 Initial threat diagram — deliberate actions.

Fig 10 Initial threat diagram — non-human threats.

healthrecords

insufficientsecurity

breaks intosystem

steals healthrecords

insufficient protectionof connection

eavesdroppingon dedicatedconnection

compromisesconfidentiality ofdata transmitted


hacker

eavesdropper

healthrecords

immaturetechnology

system goesdown duringexamination

examinationdisrupted

unstableconnection

transmissionproblems

compromisesintegrity of

medical data



service

networkerror

systemfailure

CORAS – Steg 4

24

Initialt hot diagram för ”icke-mänskliga” hot.



In the threat diagram describing deliberate harmfulactions caused by humans, the participants haveidentified two main threats — hacker and eavesdropper(Fig 9). A hacker may exploit insufficient securitymechanisms to break into the system and steal healthrecords. An eavesdropper is a person that, due toinsufficient protection of communication lines, maygather data that is transmitted and thereby compromiseits confidentiality.

The participants also worry about threats like systemfailure and network failure (Fig 10). They fear thatunstable connections or immature technology arevulnerabilities that may lead to system crashes duringexamination or transmission problems. A transmissionproblem may interfere with the data that is stored in thesystem and leave the health records only partly correct.

During the brainstorming session the initial threatdiagrams are expanded with new information on-the-fly.If the amount of information is too large, the secretarymay choose to write it down or use audiovisualequipment to make sure that nothing is missed. Thediagrams may then be updated and completed after thesession. The threat diagram illustrating incidents caused

by employees’ accidental actions (Fig 8) receives muchattention among the participants and develops into Fig 11.

Due to space limitations, we will not explore the othertwo threat diagrams further, but concentrate on just thisone.

The participants decide that the threat ‘employee’must be specified into ‘general practitioner (GP)’ and ‘ITpersonnel’ since they may cause different incidents. If theGP has too little security training, she may store copies ofhealth records on a local computer. This may compromisethe integrity of the records and in the worst case lead toan erroneous diagnosis of a patient. The same incidentsmay also occur if the GP enters wrong information in thepatient’s health record. The system allows for irregularhandling of health records which makes it possible toaccidentally send records to unauthorised people. Thiswould compromise the confidentiality of the healthrecord. The policy of the IT personnel with respect toaccess control has been very ‘loose’. They explain thiswith their responsibility for making critical updates inemergencies and that they do not have the time to waitfor a person with correct access rights to show up. Anunfortunate consequence of this is that sometimes

Fig 9 Initial threat diagram — deliberate actions.

Fig 10 Initial threat diagram — non-human threats.

healthrecords

insufficientsecurity

breaks intosystem

steals healthrecords

insufficient protectionof connection

eavesdroppingon dedicatedconnection

compromisesconfidentiality ofdata transmitted


hacker

eavesdropper

healthrecords

immaturetechnology

system goesdown duringexamination

examinationdisrupted

unstableconnection

transmissionproblems


medical data



service

networkerror

systemfailure

CORAS – Steg 4

25

Expanderat hot diagram för mänskliga misstag efter session.



people without the required competence becomeresponsible for critical changes. This may lead tomisconfiguration of the system, which again may slow itdown. A slow system may make it impossible to set apatient’s diagnosis, and also the ability to provide atelecardiology service.


x the initial threat diagrams should be completed withidentified threats, vulnerabilities, threat scenarios andunwanted incidents.

People that should participate:




— decision makers (optional — because this workshopoften has a technical focus and the decision makers’competence is more relevant in the next step),


— users (required) .


x threat diagrams:

— use the region from the asset diagram and add moreregions if necessary,

— model different kinds of threats in separatediagrams, e.g. deliberate sabotage in one diagram,mistakes in an other, environmental in a third, etc (theISO/IEC standard [5] contains a useful classification) —this makes it easier to generalise the risks, e.g. ‘theserisks are caused by deliberate intruders’ or ‘these risksare caused by human errors’,

— threats are placed to the left in the region, whilethreats that can be classified as external (hackers,intruders, etc) are placed outside the region,

— assets are listed to the right, outside the region,

— unwanted incidents are placed within the region inrelation to the assets on which they have an impact,

— assets that are not harmed by any incidents areremoved from the diagram,

— add threat scenarios between the threats and theunwanted incidents in the same order as they occur inreal time (i.e. in a logical sequence),

Fig 11 Final threat diagram — accidental actions.

insufficienttraining


insufficientaccess control

possibility ofirregular handlingof health records

lack ofcompetence

no inputvalidation

healthrecords


service

patient’shealth

health recordssent to

unauthorisedpeople

health recordcopies stored onlocal computer

wrong input inhealth record

misconfigurationof system

GP

ITpersonnel


health records

compromisesconfidentiality

of health records

slow system

patient isgiven wrong

diagnosis

unable to setdiagnosis dueto slow system


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

CORAS – Steg 5

27



— insert the vulnerabilities before the threat scenarioor unwanted incident to which they lead, e.g. avulnerability called ‘poor back-up solution’ is typicallyplaced before the threat scenario ‘the back-up solutionfails to run the application database correctly’.

6. Step 5 — risk estimationWhen the threat scenarios, unwanted incidents, threats andvulnerabilities are properly described in threat diagrams it istime to estimate likelihood values and consequences. This istypically done in a separate workshop. The values are used tocompute the risk value which decides whether the riskshould be accepted or evaluated for treatments. Theparticipants in the workshop provide likelihood estimates foreach threat scenario in the threat diagrams. For scenariosthat are difficult to estimate, the analysis leader givessuggestions based on historical data like security incidentstatistics or personal experience. The likelihood of the threatscenarios are used to extract a combined likelihood forunwanted incidents. Consequences are estimated for each‘unwanted incident — asset’ relation. The consequencevalue is taken from the consequence scale of the assetdecided in Step 3. In this workshop it is especially importantto include people with the competence needed to estimaterealistic likelihoods and consequences, meaning thattechnical expertise, users and decision makers must beincluded.

The analysis leader organises the estimation as aseparate workshop where the input is the threat diagramsfrom the previous workshop. In this workshop it isespecially important to include users, technical expertsand decision makers to obtain estimates that are ascorrect as possible. The analysis participants decide that‘most likely’ estimates will provide more realistic riskvalues than ‘worst case’ estimates. Firstly, they provide asmany estimates as possible for the threat scenarios whichhelp estimating the likelihood of the unwanted incidents(if this cannot be established by other means). Secondly,the consequences of the unwanted incidents for eachharmed asset are estimated. The estimates are docu-mented by annotating the diagrams as shown in Fig 12— further details can be specified in a table.

There are different ways of computing the likelihoodof an incident that may be caused by more than onethreat scenario. If the estimates are suitable formathematical calculations a computerised tool may beused. Since the likelihood scale in our case is in the formof intervals, the analysis leader decides to use an informalmethod that is quite straightforward and transparent.The threat scenario ‘Health records sent out tounauthorised people’ and ‘Health record copies stored onlocal computer’ can both lead to ‘Compromisesconfidentiality of health records’. Table 6 shows how thecombined likelihood is estimated. The technique isinformal, but suitable for the creative structured

Fig 12 Threat diagram with likelihood and consequence estimates.




possibility ofirregular handlingof health records

lack ofcompetence

no inputvalidation

healthrecords


service

patient’shealth

health records sent to unauthorised

people[rare]


[unlikely]


[possible]

misconfigurationof system[possible]

GP

ITpersonnel


health records[possible]

compromisesconfidentiality

of health records[rare]

slow system[possible]


diagnosis[unlikely]


[likely]


moderate

moderate

moderate

major

catastrophic

Var försiktig med detta!

Konsekvens

CORAS – Steg 6

•  Risk evaluering •  Extrahera risker (compromises confidentiality of health records CC1 = moderate / rare) •  Använd tidigare tabeller och uppskattningar för att placera riskerna i

riskutvärderingsmatrisen.

•  Kunden godkänner om denna matris är ok eller inte, kan behöva justera konsekvenser eller sannolikheter.

•  En sista bild över de risker som analyserats tas fram, med deras respektive evaluering.

28



brainstorming setting. For more precise calculation ofprobabilities fault tree analysis (FTA)[6] may be used. It isof course important that the combined estimates reflectreality, meaning that the combined estimates should bepresented to the participants for validation.

In this case, the participants reject the suggestedestimate for ‘Compromises confidentiality of healthrecords’, arguing that the likelihood is less than ‘unlikely’and adjust it to ‘rare’.

Step 5 — summary Tasks:

x every threat scenario must be given a likelihoodestimate and unwanted incident likelihoods are basedon these,

x every relation between an unwanted incident and anasset must be given a consequence estimate.






— technical expertise regarding the target (required),

— users (required).


x risk estimation on threat diagrams:

— add likelihood estimates to the threat scenarios,

— add likelihood estimates to the unwanted incidents,based on the threat scenarios,

— annotate each unwanted incident-asset relationwith a consequence taken from the respective asset’sconsequence scale.

7. Step 6 — risk evaluationThe risk evaluation consists of two activities. Firstly, theanalysis secretary uses the likelihood and consequenceestimates to compute the risk values and to place the risks inthe risk matrix. Secondly, the resulting risk matrices arepresented to the client for inspection. This presentation maybe given in a separate meeting or included in the treatmentworkshop (Step 7).

In our case the risk value is determined by the riskevaluation matrix. From the four unwanted incidents inthe threat diagram, the analysis secretary extracts fiverisks. ‘Compromising the confidentiality of healthrecords’ (CC1) may affect health records. ‘Compromisingthe integrity of health records’ may also harm healthrecords (CI1), in addition to patient’s health if itcontributes to a faulty diagnosis (PR1). Finally, ‘slowsystem’ may slow down an examination (SS2) and harmthe patient’s health (SS1). Only CC1 is within acceptablerisk levels, the rest need further evaluation. Table 7 showsthe risks placed in the risk evaluation matrix.

Table 7 Risk evaluation matrix with risks consequence.

The analysis leader gives the participants an oppor-tunity to adjust likelihood and consequence estimates,and risk acceptance levels, to make sure that the resultsreflect reality as much as possible.

The participants request an overview of the risks.They want to know who, or what, is initiating them andwhich assets they harm. The analysis secretary models therisks with their associated risk values in a risk diagramaccording to the guidelines (see summary). The final riskdiagram for unwanted incidents accidentally caused byemployees is shown in Fig 13. Since the risk ofcompromising the confidentiality of health records iswithin the acceptable risk levels it will not be assessed inthe treatment identification.


x likelihood and consequence estimates should beconfirmed or adjusted,

x the final adjustments of the acceptable area in the riskmatrices should be made (if needed),

x an overview of the risk may be given in a risk diagram.

Table 6 Combined likelihood estimates.

Threat scenario Likelihood Unwantedincident

Combined likelihood

Health records sent out to unauthorised people

Rare (0-1:10y)

Compromises confidentiality of health records

(0-1:10y)+(2-5:10y)=(2-6:10y) Some overlap between unlikely and possible, but it fits best in the unlikely interval.

Health record copies stored on local computer

Unlikely (2-5:10y)

ConsequenceLi

kelih

ood

Insignificant Minor Moderate Major Catastrophic

Rare CC1

Unlikely PR1

Possible CI1, SS2

Likely SS1

Certain

Faller utanför, behöver inte arbetas vidare med.

CORAS – Steg 6

29








— technical expertise regarding the target (required/optional4),

— users (required/optional4).


x risk diagrams:

— use the threat diagram and replace all unwantedincidents with risk symbols, showing a short riskdescription and whether the risk is acceptable or not,

— remove threat scenarios and vulnerabilities, but keepthe relations between the threats and the risks,

— if useful, split the risk diagrams into several diagramsaccording to type of threat, part of the target or assetimportance (e.g. show all risks related to network, allrisks for specific assets).

8. Step 7 — risk treatmentThe last step in the security analysis is the treatmentidentification, which is also often organised as a workshop.The risks that are not acceptable are all evaluated in order tofind means to reduce their likelihood and/or consequence.Since treatments can be costly, they are assessed withrespect to their cost/benefit, before a final treatment plan ismade.

The initial treatment diagrams are similar to the finalthreat diagrams except that every relation between an un-wanted incident and an asset representing an unacceptablerisk is symbolised with a risk icon and an identifier.

The analysis leader presents each of the threatdiagrams showing the unacceptable risks. He knows thatanalysis participants often find it most intuitive toaddress vulnerabilities when looking for treatments.Hence, he highlights the possibility of treating otherparts of the target as well, such as threats or threatscenarios. The participants become involved in adiscussion of potential treatments, and decide whichones will reduce the risks to acceptable levels. On someoccasions, if focus is slightly out of scope, the analysisleader suggests treatments taken from best-practicedescriptions for network solutions, encryption, etc, tohelp the discussion back on track. The diagrams areannotated with the identified treatment optionsindicating where they will be implemented. Finally, thefollowing treatments are suggested and annotated to thetreatment diagram in Fig 14:

4 Depending on whether this step is included in step 7 or not — if it is partof step 7’s workshop, all representatives should be present, otherwise itmay be sufficient for only the decision makers to be present.

Fig 13 Risk overview.

healthrecords


service

patient’shealth

GP

ITpersonnel

CI1 compromisesintegrity of

health records[unacceptable]

CC1 compromisesconfidentiality

of health records[acceptable]

SS1 slow system[unacceptable]

PR1 patient isgiven wrong

diagnosis[unacceptable]

SS2 unable to setdiagnosis dueto slow system[unacceptable]


Kommer alltså inte hanteras

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

CORAS – Steg 7

31



brainstorming setting. For more precise calculation ofprobabilities fault tree analysis (FTA)[6] may be used. It isof course important that the combined estimates reflectreality, meaning that the combined estimates should bepresented to the participants for validation.

In this case, the participants reject the suggestedestimate for ‘Compromises confidentiality of healthrecords’, arguing that the likelihood is less than ‘unlikely’and adjust it to ‘rare’.

Step 5 — summary Tasks:

x every threat scenario must be given a likelihoodestimate and unwanted incident likelihoods are basedon these,

x every relation between an unwanted incident and anasset must be given a consequence estimate.






— technical expertise regarding the target (required),



x risk estimation on threat diagrams:

— add likelihood estimates to the threat scenarios,

— add likelihood estimates to the unwanted incidents,based on the threat scenarios,

— annotate each unwanted incident-asset relationwith a consequence taken from the respective asset’sconsequence scale.

7. Step 6 — risk evaluationThe risk evaluation consists of two activities. Firstly, theanalysis secretary uses the likelihood and consequenceestimates to compute the risk values and to place the risks inthe risk matrix. Secondly, the resulting risk matrices arepresented to the client for inspection. This presentation maybe given in a separate meeting or included in the treatmentworkshop (Step 7).

In our case the risk value is determined by the riskevaluation matrix. From the four unwanted incidents inthe threat diagram, the analysis secretary extracts fiverisks. ‘Compromising the confidentiality of healthrecords’ (CC1) may affect health records. ‘Compromisingthe integrity of health records’ may also harm healthrecords (CI1), in addition to patient’s health if itcontributes to a faulty diagnosis (PR1). Finally, ‘slowsystem’ may slow down an examination (SS2) and harmthe patient’s health (SS1). Only CC1 is within acceptablerisk levels, the rest need further evaluation. Table 7 showsthe risks placed in the risk evaluation matrix.

Table 7 Risk evaluation matrix with risks consequence.

The analysis leader gives the participants an oppor-tunity to adjust likelihood and consequence estimates,and risk acceptance levels, to make sure that the resultsreflect reality as much as possible.

The participants request an overview of the risks.They want to know who, or what, is initiating them andwhich assets they harm. The analysis secretary models therisks with their associated risk values in a risk diagramaccording to the guidelines (see summary). The final riskdiagram for unwanted incidents accidentally caused byemployees is shown in Fig 13. Since the risk ofcompromising the confidentiality of health records iswithin the acceptable risk levels it will not be assessed inthe treatment identification.


x likelihood and consequence estimates should beconfirmed or adjusted,

x the final adjustments of the acceptable area in the riskmatrices should be made (if needed),

x an overview of the risk may be given in a risk diagram.

Table 6 Combined likelihood estimates.

Threat scenario Likelihood Unwantedincident

Combined likelihood

Health records sent out to unauthorised people

Rare (0-1:10y)

Compromises confidentiality of health records

(0-1:10y)+(2-5:10y)=(2-6:10y) Some overlap between unlikely and possible, but it fits best in the unlikely interval.

Health record copies stored on local computer

Unlikely (2-5:10y)

ConsequenceLi

kelih

ood

Insignificant Minor Moderate Major Catastrophic

Rare CC1

Unlikely PR1

Possible CI1, SS2

Likely SS1

Certain

Detta måste vi alltså behandla. Vi behöver flytta SS1 till ett vitt fält. 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). Det sista steget i analysen är att ta fram förslag på hur vi flyttar de risker vi inte kan acceptera.

CORAS – Steg 7

32



x extend the training programme for practitioners by1-2 days, with a special focus on security aspects,

x revise the list of people that have maintenanceaccess, and restrict access to only the users thathave competence on critical configuration tasks.

When the final results from the analysis are to bepresented to the client and other interested parties, anoverview of the risks and the proposed treatments isuseful. In our case the treatment overview diagram of Fig15 is used for this purpose.


x add treatments to threat diagrams,

x estimate the cost/benefit of each treatment and decidewhich ones to use,

x show treatments in risk overview diagrams.









x treatment diagrams:

— use the threat diagrams as a basis and annotate allarrows from unwanted incidents to assets with riskicons, showing only the unacceptable risks,

Fig 14 Treatment diagram.




lack ofcompetence

no inputvalidation

healthrecords


service

patient’shealth

extend trainingprogramme(1 - 2 days)



misconfigurationof system

GP

ITpersonnel


health records

slow system


diagnosis



SS1

SS2

PR1

CI1

revise accesslists

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

ISRAM Information Security Risk Analysis Method

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

37

Vikt Förklaring

3 Faktorn påverkar risken direkt

2 Faktorn påverkar risken något

1 Faktorn påverkar risken indirekt

Sannolikhetsfaktorer

Typen av bifogade filer i mejl 3

Antalet mejl per dag 1

Antalet nedladdade filer per dag 1

Källan av USB-‐sCckor 2

Konsekvensfaktorer

Backup av filer 3

Fysisk plats av filsystem 2

Beroende av applikaCon 1

•  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.

ISRAM – Steg 3

•  Steg 3 – Konvertera faktorer till frågor, skapa svarsalternativ till varje fråga och ge varje alternativ en poäng.

38

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 använder du?

Endast de jag får av företaget (0)

Tar med mig hemifrån (4)

Hur oQa gör du backuper av filer?

Varje dag (1) Varje vecka (2) 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.

39

Poäng Kvalita<v skala Kvan<ta<v skala

29-‐48 Väldigt låg sannolikhet 1

49-‐68 Låg sannolikhet 2

69-‐88 Medel sannolikhet 3

89-‐108 Hög sannolikhet 4

108-‐128 Väldigt hög sannolikhet 5

Poäng Kvalita<v skala Kvan<ta<v skala

47-‐68 Försumbar konsekvens 1

69-‐90 Liten konsekvens 2

91-‐111 Förhöjd konsekvens 3

112-‐133 Allvarlig konsekvens 4

134-‐160 Mycket allvarlig konsekvens 5

ISRAM – Steg 4

•  Skapa en slutgiltig risktabell.

40

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

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

•  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

42

Risk =

NPn=1

[Ts(IP

i=1

↵isi,n)]

N

! NPn=1

[Tk(JP

j=1

�jkj,n)]

N

!

1

ISRAM – Steg 6

43

Risk =

NPn=1

[Ts(IP

i=1

↵isi,n)]

N

! NPn=1

[Tk(JP

j=1

�jkj,n)]

N

!

1

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

ISRAM – Steg 7

•  Steg 7 – Utvärdering av resultat

•  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.

44

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).

•  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).

45

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

48

Open Safe

Pick lock Learn combo Cut open Install improperly

Find written combo

Get combo from target

Threaten Blackmail Eavesdrop Bribe

Listen to conversation

Get target to state combo

Attack Träd

49

Open Safe


Find written combo





and

Attack Träd

50

Open Safe


Find written combo





and

P I

I P I I

P I

P I I P

P

Attack Träd

51

Open Safe


Find written combo





and

P I

I P I I

P I

P I I P

P

$20 $40

$60 $20 $100 $60

$75 $20

$20 $30 $10 $100

$10

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

Documents

riskanalys - IDATDDD82/slides/security/riskanalys.pdf · • 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