riskanalys - IDATDDD82/slides/security/riskanalys.pdf · • Ett system kan bli mål för attacker...
Transcript of riskanalys - IDATDDD82/slides/security/riskanalys.pdf · • Ett system kan bli mål för attacker...
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
Model-based security analysis in seven steps — a guided tour to the CORAS method
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
Model-based security analysis in seven steps — a guided tour to the CORAS method
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
Class diagram Collaboration diagram
CORAS – Steg 2
14
Activity diagram
CORAS Asset diagram (not part of UML)
Model-based security analysis in seven steps — a guided tour to the CORAS method
BT Technology Journal • Vol 25 No 1 • January 2007 105
Step 2 — summaryTasks:
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),
x representatives of the client:
— decision makers (required),
— technical expertise (required),
— users (optional).
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.
Model-based security analysis in seven steps — a guided tour to the CORAS method
BT Technology Journal • Vol 25 No 1 • January 2007 105
Step 2 — summaryTasks:
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),
x representatives of the client:
— decision makers (required),
— technical expertise (required),
— users (optional).
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.
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
Model-based security analysis in seven steps — a guided tour to the CORAS method
BT Technology Journal • Vol 25 No 1 • January 2007106
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
Model-based security analysis in seven steps — a guided tour to the CORAS method
BT Technology Journal • Vol 25 No 1 • January 2007106
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
Model-based security analysis in seven steps — a guided tour to the CORAS method
BT Technology Journal • Vol 25 No 1 • January 2007 107
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.
Step 3 — summaryTasks:
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.
Model-based security analysis in seven steps — a guided tour to the CORAS method
BT Technology Journal • Vol 25 No 1 • January 2007 107
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.
Step 3 — summaryTasks:
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.
Prioriteringar
Konsekvensskalor, kan behövas olika för olika assets
Sannolikhetsskalor
CORAS – Steg 3
19
Model-based security analysis in seven steps — a guided tour to the CORAS method
BT Technology Journal • Vol 25 No 1 • January 2007 107
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.
Step 3 — summaryTasks:
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.
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
Model-based security analysis in seven steps — a guided tour to the CORAS method
BT Technology Journal • Vol 25 No 1 • January 2007108
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
telecardiologyservice
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
Model-based security analysis in seven steps — a guided tour to the CORAS method
BT Technology Journal • Vol 25 No 1 • January 2007108
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
telecardiologyservice
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.
Model-based security analysis in seven steps — a guided tour to the CORAS method
BT Technology Journal • Vol 25 No 1 • January 2007 109
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
telecardiologyservice
hacker
eavesdropper
healthrecords
immaturetechnology
system goesdown duringexamination
examinationdisrupted
unstableconnection
transmissionproblems
compromisesintegrity of
medical data
telecardiologyservice
provision oftelecardiology
service
networkerror
systemfailure
CORAS – Steg 4
24
Initialt hot diagram för ”icke-mänskliga” hot.
Model-based security analysis in seven steps — a guided tour to the CORAS method
BT Technology Journal • Vol 25 No 1 • January 2007 109
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
telecardiologyservice
hacker
eavesdropper
healthrecords
immaturetechnology
system goesdown duringexamination
examinationdisrupted
unstableconnection
transmissionproblems
compromisesintegrity of
medical data
telecardiologyservice
provision oftelecardiology
service
networkerror
systemfailure
CORAS – Steg 4
25
Expanderat hot diagram för mänskliga misstag efter session.
Model-based security analysis in seven steps — a guided tour to the CORAS method
BT Technology Journal • Vol 25 No 1 • January 2007110
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.
Step 4 — summaryTasks:
x the initial threat diagrams should be completed withidentified threats, vulnerabilities, threat scenarios andunwanted incidents.
People that should participate:
x security analysis leader (required),
x security analysis secretary (required),
x representatives of the client:
— decision makers (optional — because this workshopoften has a technical focus and the decision makers’competence is more relevant in the next step),
— technical expertise (required),
— users (required) .
Modelling guideline:
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
prose-basedhealth records
insufficientaccess control
possibility ofirregular handlingof health records
lack ofcompetence
no inputvalidation
healthrecords
provision oftelecardiology
service
patient’shealth
health recordssent to
unauthorisedpeople
health recordcopies stored onlocal computer
wrong input inhealth record
misconfigurationof system
GP
ITpersonnel
compromisesintegrity of
health records
compromisesconfidentiality
of health records
slow system
patient isgiven wrong
diagnosis
unable to setdiagnosis dueto slow system
telecardiologyservice
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
Model-based security analysis in seven steps — a guided tour to the CORAS method
BT Technology Journal • Vol 25 No 1 • January 2007 111
— 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.
insufficienttraining
prose-basedhealth records
insufficientaccess control
possibility ofirregular handlingof health records
lack ofcompetence
no inputvalidation
healthrecords
provision oftelecardiology
service
patient’shealth
health records sent to unauthorised
people[rare]
health recordcopies stored onlocal computer
[unlikely]
wrong input inhealth record
[possible]
misconfigurationof system[possible]
GP
ITpersonnel
compromisesintegrity of
health records[possible]
compromisesconfidentiality
of health records[rare]
slow system[possible]
patient isgiven wrong
diagnosis[unlikely]
unable to setdiagnosis dueto slow system
[likely]
telecardiologyservice
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
Model-based security analysis in seven steps — a guided tour to the CORAS method
BT Technology Journal • Vol 25 No 1 • January 2007112
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.
People that should be present:
x security analysis leader (required),
x security analysis secretary (required),
x representatives of the client:
— decision makers (required),
— technical expertise regarding the target (required),
— users (required).
Modelling guideline:
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.
Step 6 — summaryTasks:
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
Model-based security analysis in seven steps — a guided tour to the CORAS method
BT Technology Journal • Vol 25 No 1 • January 2007 113
People that should be present:
x security analysis leader (required),
x security analysis secretary (required),
x representatives of the client:
— decision makers (required),
— technical expertise regarding the target (required/optional4),
— users (required/optional4).
Modelling guideline:
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
provision oftelecardiology
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]
telecardiologyservice
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
Model-based security analysis in seven steps — a guided tour to the CORAS method
BT Technology Journal • Vol 25 No 1 • January 2007112
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.
People that should be present:
x security analysis leader (required),
x security analysis secretary (required),
x representatives of the client:
— decision makers (required),
— technical expertise regarding the target (required),
— users (required).
Modelling guideline:
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.
Step 6 — summaryTasks:
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
Model-based security analysis in seven steps — a guided tour to the CORAS method
BT Technology Journal • Vol 25 No 1 • January 2007114
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.
Step 7 — summaryTasks:
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.
People that should be present:
x security analysis leader (required),
x security analysis secretary (required),
x representatives of the client:
— decision makers (required),
— technical expertise (required),
— users (required).
Modelling guidelines:
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.
insufficienttraining
prose-basedhealth records
insufficientaccess control
lack ofcompetence
no inputvalidation
healthrecords
provision oftelecardiology
service
patient’shealth
extend trainingprogramme(1 - 2 days)
health recordcopies stored onlocal computer
wrong input inhealth record
misconfigurationof system
GP
ITpersonnel
compromisesintegrity of
health records
slow system
patient isgiven wrong
diagnosis
unable to setdiagnosis dueto slow system
telecardiologyservice
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
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
and
Attack Träd
50
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
and
P I
I P I I
P I
P I I P
P
Attack Träd
51
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
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