scenario-based (it) risk assessment & management · abstract (i) scenario-based (it) risk...
TRANSCRIPT
Scenario-based (IT) Risk Assessment & Management
EuroCACS 2010 Session 214
Peter R. Bitterli, CISA, CISM, CGEIT http://www.bitterli-consulting.ch [email protected] Please observe the copyright: You are allowed to use and further distribute this presentation only with this copyright notice attached. If you use parts of this documentation in presentations or other diagrams you have to refer to the source. Any commercial use of this presentation is only allowed with written consent of the author.
Abstract (I) Scenario-based (IT) Risk Assessment & Management
• Following the proliferation of regulations such as the Sarbanes-Oxley Act, Basel II or Solvency II, the possible approaches to (operational) risk management exploded – leading to a multitude of tools that are supposed to guarantee effective risk management. By this, however, seen from the speaker’s point of view, the know-how and experience of trained staff has been replaced by mechanistically following an approach enforced by an uncaring and inflexible tool, hardly suited for the specific issues found within IT.
Abstract (II) Scenario-based (IT) Risk Assessment & Management
• Scenario-based risk assessment – if designed and implemented correctly – enables a team of (IT) professionals to consistently identify, assess and treat risks using a combination of the experience of internal resources, collected through structured but creative risk identification workshops, with a demonstrably mature risk management process.
Abstract (II) Scenario-based (IT) Risk Assessment & Management
• The session will contain several short “hands-on” elements to explain some of the more important aspects.
• Although the approach presented is applicable to risks outside IT, it has primarily been used for identifying information/IT security related risks.
Learning Objectives The participants will learn about …
After this session, participants will be able to…
• understand the advantages and disadvantages of scenario-based IT risk assessment
• tailor a scenario-based approach to the specific needs of any company using a step-by-step process explained during the session
• perform scenario-based risk assessments consistently and efficiently
• link IT risk scenarios to ISO27001/2 for effective integration into an information security management system (ISMS)
• combine this type of risk assessment with an overall (IT) risk management process
Contents
• Introduction – Definitions – Risk analysis methodologies (examples)
• First-time assessment: Step-by-step • How to ensure completeness • Applying the IT Risk Landscape • SOP for maintenance of IT Risk Landscape • Wrap up / Questions
Introduction: Definitions
Contains the most important definitions; should be worked out by oneself.
Risk management
Risk assessment
Terms for Risk Management Based on ISO Guide 73 and EN14971
Risk analysis
Risk evaluation
Risk control/treatment
Identification of risks, hazards and root causes This is a creative process
Risk estimation and evaluation This is a systematic process
Risk remediation/mitigation This is a project management issue
Must be em
bedded in overall context
Risk management (Assess and manage IT risks PO 9)
Risk assessment
Terms for Risk Management Based on COBIT PO 9
Risk analysis (Event identification PO 9.3)
Risk evaluation (Risk asssessment PO 9.4)
Risk treatment (Risk response PO 9.5) Maintenance and monitoring of a risk action plan (PO 9.6)
Identification of risks, hazards and root causes This is a creative process
Risk estimation and evaluation This is a systematic process
Risk remediation/mitigation This is a project management issue
Must be em
bedded in overall context (IT risk m
anagement fram
ework P
O 9.1)
(Establishm
ent of risk context PO
9.2)
Varied Approaches to RA Entry Points .
Vulnerability Assessment
Risk Assessment
Risk Management
Threat Assessment
Effective Risk Management
Original source: unknown
Important Terms (EN14971) An Introduction for IT Audit, IT Security and IT-Governance
Harm Physical injury or damage to health of people, property, environment
Hazard Potential source of harm Intended use Use of a product according to specifications, instructions and information by
the manufacturer Life cycle All phases of a medical device from conception to disposalResidual risk Risk remaining after risk control measures have been takenRisk Combination of the probability of occurance of a harm and the severity of that
harmRisk analysis Systematic use of available information to identify hazards and estimate the
riskRisk control Process in which decisions are made by which risks are reduced to, or
maintained within specified levelsRisk evaluation Process of comparing the estimated risk against given risk criteria to
determine the acceptability of the riskRisk management Systematic application of policies, procedures and practices to te task of
analyzing, evaluating and controlling risksSafety Freedom from unacceptable risksVerification Confirmation by the provision of objective evidence, that specifications have
been fulfilled
Terms Risk IT Framework
Source: Risk IT Framework, © ITGI
Introduction: Risk Analysis Methodologies (Examples)
Contains some typical examples to explain some of the many different
approaches to risk assessment that exist
Risk Analysis/Management Countless and Highly Divers Methodologies
CORAS Computer Safety, Reliability and SecurityCRAMM Centre for Information Systems Risk Analysis und Management MethodEBIOS Expression des Besoins et Identification des Objectifs de SécuritéETA Event Tree AnalysisFMEA Project: Mission Assurance Analysis Protocol (MAAP) FTA Fault Tree AnalysisHAZOP Hazard Operability AnalysisHACCP Hazard Analysis and Critical Control PointMAAP Mission Assurance Analysis Protocol (MAAP) MEHARI Méthode Harmonisée d’Analyse de RisquesOCTAVE Operationally Critical Threat, Asset, and Vulnerability Evaluation
Incomplete list of methods used for risk management (partly the methods cannot be separated from the product): @Risk, Analyse des Risques Programmes, AnalyZ, ARES, AROME+, ASRAM, BDSS, BIS RISK ASSESSOR, Buddy System, COBRA, CONTROL-IT, CONTMAT, CoP-IT, CORA, CORAS UML, CRAMM, CRITI CALC, DDIS, EBIOS, ETA, FMEA, FTA, GRA/SIS, HAZOP, HACCP, IS CASE, IST/RAMP, JANBER, LAVA, LRAM (& ALRAM), MAGHERIT, MAAP, MARION, MEHARI, MELISA, MicroSecure Self Assessment, MINIRISK, Octave, Octave-s, PREDICT, PRISM, Proteus, PSICH, R1, RA/SYS, RANK-IT, RISAN, Risiko, RiskCALC, RiskPAC, Riskwatch, Security by Analysis, SISSI, XRM, …
Note: This is an incomplete listing of tools and methodologies that can be used for risk identification, assessment and management
Risk Analysis Annual Planning of (IT) Audit for Different Locations
Criteria and Tool © Bitterli Consulting AG
Note: This is an example - ratings are for demonstration purposes only
0%
20%
40%
60%
% o
f eva
luat
ed a
pplic
atio
ns
life threatening serious
significant low
none
Security requirements
Impact on business if requirements are not met
Risk Analysis (Diagram) Critical Applications and Potential (Negative) Impact
SourceESF 1997Method Sprint163 critical business applications;Thereof classified 65% as “life threatening”
Sour
ceG
AO: I
nfor
mat
ion
Secu
rity
Ris
k As
sess
men
t - P
ract
ices
of L
eadi
ng
Org
aniz
atio
ns (G
AO/A
IMD
-00-
33)
Operational Risks Criteria: based on GAO Study
Note: This is an example - ratings are for demonstration purposes only
Project Requirements Analysis Criteria: COBIT Information Criteria
Landscape of Security Requirements
Security (K1: Confidentiality, K2: Availability, K3: Integrity)
Qua
lity
(K
4: E
ffect
iven
ess,
K5:
Effi
cien
cy)
low medium high
low
m
ediu
m
high
Orderliness (K6: Compliance, K7: Reliability)
low medium high
Solution domains B2B, B2C
Applications Infrastructure
© Bitterli Consulting AG
Note: This is an example - ratings are for demonstration purposes only
Project Risks Total
1 2 3 CM
S
War
ehou
se
Tolli
ng
Sal
ary
VA
Tplu
s
Sec
ureI
T
HR
2
360
ZV 2
005
Inve
st+
Sal
aryI
I
Dire
kcB
illin
g
Info
2000
Sig
natu
r
Add
ress
Team
Tim
eRep
ort
Mig
ratio
nZIP
E-S
hop
Rol
ebas
ed A
Cou
rseR
epor
t
Cha
nge
Ber
mud
a
Bill
ing
You
Ban
k
Gua
rdia
n
SO
X-li
ght
Net
Enc
rypt
Car
eerP
lan
1 1
Confidentiality low medium high 3 3 1 3 1 1 2 3 1 1 3 1 1 1 2 2 1 2 1 2 2 1 1 3 1 2 1 2 1.71
Availability low medium high 3 2 3 2 3 2 1 2 3 2 2 3 2 3 2 3 3 2 3 1 3 2 1 2 2 3 1 3 2.29
Integrity low medium high 2 1 2 2 1 1 1 1 2 1 2 3 1 3 2 1 1 2 1 2 1 1 1 1 2 1 1 1 1.46
Effectiveness low medium high 1 2 1 2 2 1 2 1 3 1 2 1 1 2 2 2 1 2 2 1 2 1 1 2 2 1 2 1 1.57
Efficiency low medium high 1 2 1 2 2 1 2 1 1 1 2 1 1 1 2 3 2 1 3 1 2 1 1 1 2 2 1 1 1.50
Reliability low medium high 2 2 2 2 2 1 1 1 1 2 1 2 2 1 2 1 2 1 2 2 2 1 2 1 2 3 2 3 1.71
Compliance low medium high 1 1 2 2 1 1 1 1 2 1 1 1 1 1 1 2 1 2 1 1 1 1 1 2 1 1 2 1 1.25
Total per Application 13 13 12 15 12 8 10 10 13 9 13 12 9 12 13 14 11 12 13 10 13 8 8 12 12 13 10 12
Evaluation 13 13 12 15 12 8 10 10 13 9 13 12 9 12 13 14 11 12 13 10 13 8 8 12 12 13 10 12
Selected Projects X X X X X X X X X
Risk Assessment Project
Project Requirements Analysis Criteria: COBIT Information Criteria
Note: This is an example - ratings are for demonstration purposes only
© Bitterli Consulting AG
01234 3.1
4.14.2
4.35.1
5.2
6.1
6.2
6.3
7.1
7.2
7.3
8.1
8.2
8.38.4
8.58.6
8.79.1
9.29.3
9.4
9.5
9.6
9.7
9.8
10.1
10.2
10.3
10.4
10.5
11.112.1
12.212.3
Full target level Minimal target level Milestone 3 Milestone 2 Milestone 1 Start
Analysis Target Achievement Criteria ISO27002
• Current State (green area)
• State at Milestone 1 • State at Milestone 2 • State at Milestone 3
• Minimal Target Level (Rating 3)
• Maximal Target Level (Rating 4)
Note: This is an example - ratings are for demonstration purposes only
© Bitterli Consulting AG
Analysis Security Aspects Criteria based on ISO27002; Tool © Bitterli Consulting
Note: This is an example - ratings are for demonstration purposes only
© Bitterli Consulting AG
Presentation of Results Example: Expected benefit vs. actual maturity level
ISO 17799:2005 SELF ASSESSMENT
2.40
2.33
2.23 3.07
2.97
2.40
2.472.13
2.602.70
2.40
3.50
2.65
3.80
2.40
2.25
2.20
2.40
1.79
3.40
2.632.11
2.53
1.62
1.87
1.60
1.83
1.88
3.40
2.90
2.80
1.67
1.63
1.57
3.10
1.72
1.78
1.89
1.00
1.50
2.00
2.50
3.00
3.50
4.00
1.50 2.00 2.50 3.00 3.50 4.00
LEVEL
NU
TZ
EN
5.1
6.1
6.2
7.1
8.1
8.2
8.3
9.1
9.2
10.1
10.2
10.3
10.4
10.5
10.6
10.7
10.8
10.9
10.10
11.1
11.2
11.3
11.4
11.5
11.6
11.7
12.1
12.2
12.3
12.4
12.5
12.6
13.1
13.2
14.1
I II
III IV
Need for improvement !
Import issues well done
Efficient? Unimportant issues not done
Note: This is an example - ratings are for demonstration purposes only
© Bitterli Consulting AG
Monitoring of State Useful for Managers with Need for Detailed Information
Note: This is an example - ratings are for demonstration purposes only
© Bitterli Consulting AG
Building a Scenario-based (IT) Risk Landscape the 1st time
This section explains the reasoning behind building an (IT) Risk Landscape and shows
a step-by-step approach for the first-time development of such a landscape
Classical Approach to Risk Analysis Bottom-up Approach
• Identification, exploration and assessment of operational risks on a detailed level is an extensive and tedious task that takes considerable time and effort. After having completed such risk assessments in all relevant areas on a detailed level, the information could be aggregated to achieve a gross and well substantiated overview of the risk situation of the whole organization.
Classical Approach to Risk Analysis Bottom-up Approach
• This bottom-up approach is rarely practical, because complete, detailed and up-to-date information about all risks is normally not available and would require too much time to generate and collect.
Overall Goals of our Approach Scenario-based Risk Analysis
• Establishing a high-level IT risk landscape with about 20 top risks
• Implementing a Standard Operation Procedure (SOP) for maintaining the IT risk landscape
© Bitterli Consulting AG
Scenario-based Risk Analysis Top-down Approach
• The method follows a top-down approach to establish a top level view of the risk situation in absence of a complete account of detailed studies. It relies on the available data about weaknesses and incidents, on prior findings from audits and reviews as well as on the knowledge and imagination of experienced (IT) security specialists.
Approach to Build IT Risk Landscape
• 1st Compilation by core team • Regular/periodic reassessment
– Effects of security projects can be shown (i.e. target state)
– Reassessment shows changes (i.e. actual state) • Permanent amendment through input from:
– Risk Controlling – (IT) Security – (IT) Audit
Building the 1st IT Risk Landscape Pragmatic Approach Using Available Knowledge & Experience
• First round with (internal) IT staff, without involvement of business
• Support by internal/external “consultant” to ensure quality and correct scoping
• Definition of a SOP for future maintenance • Involvement of business through a structured
process
Define “Trivialities” Clearly Determine Fundamental Issues
1. Direction of axes 2. Scale of axis “Probability” 3. Scale of axis “Severity” 4. Defining acceptable Risk Levels 5. Scenario types 6. Information to be collected
Definition Risk
A risk is defined as: • a threat directed at a
specific object, which has been assessed in regard to the probability and impact (i.e. severity).
1: Direction of Axes Clearly Determine Fundamental Issues
• Most common way of labeling the axes
• Compatible to the typical internally used methodologies for operational risk management
Prob
abili
ty
Severity
2: Scale of Axis Probability Useful Logarithmic Scaling
Prob
abili
ty
Frequent = 1 per day Probable = 1 per 10 days Occasional = 1 per 100 days Remote = 1 per 1,000 days Improbable = 1 per 10,000 days
3: Scale of Axis Severity Useful Logarithmic Scaling (see next slide)
Min
or
Mod
erat
e
Con
side
rabl
e
Crit
ical
Cat
astr
ophi
c Severity
Each of the severity categories is defined in terms of • operational impact, • intangible impact • financial impact
(see next slide)
Severity Operational Impact Intangible Impact Financial Impact1 Minor No significant impact Only few internal staff notice
incidentNo significant costs (e.g. below 10‘000)
2 Moderate Slight disturbance of business operations
(back to normal < 1 day)
Incident is only noticed by internal staff and few externals. General public is not informed. Minor regulatory issues
Potential costs are noticeable but don‘t threaten profit
(e.g. 10‘000 -100‘000)
3 Considerable Substantial disturbance of business operations
(back to normal < 1 week)
Incident noticed by external parties and media coverage. Regulatory compliance threatened, i.e. warning letter
Potential costs have significant influence on profit
(e.g. 100‘000 - 1 Mio.)
4 Critical Extensive efforts required to recover and restore normal business operations (back to normal < 1 month)
Incident has significant impact on external parties and makes headlines. Regulatory compliance at stake
Potential costs reach the order of magnitude of yearly profit
(e.g. 1 Mio - 10 Mio.)
5 Catastrophic Recovery procedures not sufficient to fully restore business operations for a longer time span (back to normal > 1 month)
The confidence of affected parties is likely to be lost.
Regulatory compliance definitively lost.
Potential costs surmount financial reserves
(e.g. above 10 Mio.)
3: Scale of Axis Severity Useful Logarithmic Scaling
red italics: must be calibrated to risk appetite of enterprise
3: Scale of Axis Severity Using Examples from the Risk IT Framework
Source: Risk IT Framework, © ITGI
4: Defining Acceptable Risk Levels Using Examples from the Risk IT Framework
Source: Risk IT Framework, © ITGI
?
4: Defining Acceptable Risk Levels Using Examples from the Risk IT Framework
Source: Risk IT Framework, © ITGI
4: Defining Acceptable Risk Levels Typical IT Risk Landscape
Prob
abili
ty
Severity
4: Scenario Types Need to be Clearly Determined to Avoid Difficulties
• Which risk is going to be measured?
– Inherent risk (i.e. the maximal possible risk if all measures fail)
– Current risk (i.e. actual residual risk, taking into consideration the implemented measures)
– Target risk (i.e. residual risk after implementing further security measures)
Within our scenario-based risk analysis we evaluate typical and reasonable scenarios while considering the currently implemented (security) measures
Severity
Pro
babi
lity
16
16
inherent
current
target
1616 16
• Your turn now!
Flooding Scenario A
water height 8m
Flooding A – The Truth
Earth Quake Scenario B
1 2
Earth Quake Scenario B – the Truth
1 2
Airplane Crash Scenario C
1 2
Airplane Crash Scenario C – The Truth
1 2
4: Defining Acceptable Risk Levels Possible Results for Our Case Study A–C
Prob
abili
ty
Severity
C AB
In Case of Difficulties: Be Smart Compare with other Risks – or Vote
Severity/Impact
Prob
abili
ty
EFrequent
D Probable
COccasional
BRemote
1Minor
2Moderate
3Considerable
4Critical
5catastrophic
every day
every 10 days
every 100 days
every 1000 days
every 10000 daysA
Improbable
C Number of risk scenario
© Bitterli Consulting AG
A
B C
5: Scenario Description (I) Information to be Collected/Determined
• Scenario Number • Scenario name and (short) term/title • Scenario description • Summary of the set of related risks and
potential events that are considered in the scenario
• Agent (cause) and trigger that lead to the existence of this risk and make the damaging events occur
5: Scenario Description (II) Information to be Collected/Determined
• Nature: physical, technical, logical • Source: internal, external • Description of the effects that may result
from the damaging events (direct/indirect, immediate/future, tangible/intangible)
• Description of (one or more) typical versions of the scenario that where specifically considered for pinning down the assessment
• Examples, if possible from within enterprise
5: Scenario Description (III) Information to be Collected/Determined
• Assessment of probability category (i.e. assessment of the probability of occurrence of a typical event; incl. justification)
• Assessment of severity category (i.e. assessment of the amount of damage that may typically be caused; incl. justification) Remarks:
– A risk scenario may be split into two or more sub-scenarios that share the same descriptions for points 2 to 6 above but come in several versions with different severity and probability categories.
– The sub-scenarios of scenario N are numbered Na, Nb, et cetera.
5: Scenario Description (IV) Information to be Collected/Determined
Source: Risk IT Framework, © ITGI
Analysis of Risk Scenarios Typical IT Risk Landscape
Severity/Impact
Prob
abili
ty
EFrequent
D Probable
COccasional
BRemote
1Minor
2Moderate
3Considerable
4Critical
5catastrophic
every day
every 10 days
every 100 days
every 1000 days
every 10000 daysA
Improbable
6
14
1
11 7
12
15
4 5 13
8
10 3 9
1 Number of risk scenario
Typical IT Risk Scenarios:
1 Half-day power outage 2 Flooding of data center
site 3 “Loss” of confidential
client information 4 Malicious code 5 Access Management 6 Telebanking (Phishing) 7 Patch Management 8 Non-compliance to rules 9 Network outage 10 Legal issues 11 Loss of key staff 12 Handling of passwords 13 Application of new
technologies 14 Application dependent
controls 15 Insufficient BCM/BCP 16 Internal Sabotage
Note: Ratings are for demon-stration purposes only
16
2
© Bitterli Consulting AG
IT Risk Landscape Example from the Risk IT Framework
Source: Risk IT Framework, © ITGI
How to Ensure the Completeness of a Scenario-based (IT) Risk Landscape
This section explains which techniques and tools can be used
to ensure that the (IT) risk landscape is complete
Reasoning
• The (first version of the) Risk Landscape has been put together through a creative process
• This helps to identify realistic scenarios typical for the enterprise in question
• But – there is absolutely no indication whether the risk landscape is complete (too much bias of “experts”)
• We therefore need an approach for finding additional scenarios possibly missing
Completeness of Scenarios Identification of all Relevant Risks
• General sources: – Institutions, public authorities, associations
• E.g. CERT, SANS, … – Known threats, own experience
• E.g. disasters, flood, power/network outage, viruses, • Norms • ISO/IEC 27002 • ISO/IEC 27005 (BS 7799-3): Appendix C, D • COBIT: Management Guidelines, Quickstart, Control
Objectives, … • BSI-Grundschutzhandbuch: Threat List
Completeness of Scenarios Identification of all Relevant Risks: Additional Sources
• Additional Sources – Regional Threats, e.g.
• Earthquake • Mud slides • Nuclear accidents
– Threats specific to single locations, e.g. • Transport routes (trains, roads, airline crash, ...) • Companies in the direct neighborhood
Much information is available from local authorities – but with varying level of detail and of quality
Using Local Risk Maps
Completeness of Scenarios Additional Sources: Loss Categories of Basel II
Completeness of Scenarios Additional Sources: Swiss Risk Report 2004
You will find something similar for your own country / region / district / …
Completeness of Scenarios Additional Sources: ISO27005
• Acts of terrorism • Air conditioning failure • Airborne particles / dust • Bomb attack • Breach of legislation or
regulations • Breaches of contractual
obligations • Compromise of assets • Compromise of security • ...
• Disruption to business processes
• Dust • Earthquake • Eavesdropping • Environmental
contamination • Equipment failure • Errors • Failure of communication
services • ...
Completeness of Scenarios Additional Sources: Threats Catalogue of German Manual
Example: Grundschutzhandbuch Description of Threat T 1.2
How does our Approach (Tool) Work? Ensuring Completeness of IT Risk Landscape
1. Copy threats catalogue of BSI Grundschutzhandbuch (one line per threat)
2. Evaluate threats based on predefined criteria 3. If threat is not in “green area”:
• Consider threat for possible addition to risk landscape • If threat fits an existing scenario:
» note its number (as the threat is already covered)
• All remaining threats need to be reevaluated for addition to the risk landscape
Excel Tool used for Verification Template based on the BSI Grundschutzhandbuch
© Bitterli Consulting AG
Excel Tool used for Verification Assessment of Threats Catalogue
© Bitterli Consulting AG
Note: This is an example - ratings are for demonstration purposes only
How to effectively use/apply a Scenario-based
(IT) Risk Landscape
This section explains to which purposes one can use an (IT) risk landscape
How to use a Scenario-based (IT) Risk Landscape effectively
Some examples 1. Showing the effects of planned/actual
security activities on risks over time 2. Explaining effects of initiatives on scenarios 3. Mitigating risk scenarios with measures
correlated to ISO27002
1: Showing Changes over Time E.g. By Animating the “Movement” of Scenarios
7
10
6 14
9
20
2111
19 12
3
15
4
5
16
17 18 8
1
2
2 6 14
20
1
2111
7
12
15
4
5
13
17 18 8 13
10
16
3
9
19
Severity
Prob
abili
ty
EFrequent
D Probable
C Occasional
B Remote
1Minor
2Moderate
3Considerable
4Critical
5Catastrophic
1 per day
1 per 10 days
1 per 100 days
1 per 1000 days
1 per 10000 daysAImprobable
© Bitterli Consulting AG
Severity
Prob
abili
ty
EFrequent
D Probable
C Occasional
B Remote
1Minor
2Moderate
3Considerable
4Critical
5Catastrophic
1 per day
1 per 10 days
1 per 100 days
1 per 1000 days
1 per 10000 daysAImprobable
2: Explaining Effects of Initiatives By Looking at Individual Risk Scenarios
2 6 14
20
1
2111
7
12
15
4
5
13
17 18 8
10
16
3
9
1916
Risk Scenario 16: Remote Access will be reduced by security initiatives: A: Remote Access Server, Single Sign On B: Awareness C: Policies & Procedures
(fictitious example*)
© Bitterli Consulting AG
3: Mitigating risk scenarios with measures correlated to ISO27002
1.2
SLA
s
1.3
Proj
ect
initi
atio
n
1.4
Ana
lysi
s an
d de
sign
1.5
Proj
ect
exec
utio
n
1.6
Dat
a m
igra
tion
2.1
Mgn
t. o
f pr
ogra
m
chan
ges
2.2
SLA
s2.
3 D
ocum
enta
tion
of
chan
ges
2.4
App
rova
l of
chan
ges
2.6
Dep
loym
ent
of
chan
ges
2.7
Emer
genc
y ch
ange
s
3.4
App
licat
ions
inte
grity
3.5
Syst
ems
a. in
fras
tr.
sec.
4.1
SLA
Nr. scenario name
scenario description
1.1.
1
1.1.
2
1.1.
3
1.2.
1
1.3.
1
1.4.
1
1.5.
1
1.6.
1
1.7.
1
1.7.
2
1.7.
3
1.7.
4
1.8.
1
1.8.
2
2.1.
1
2.2.
1
2.3.
1
2.4.
1
2.5.
1
2.5.
2
2.6.
1
2.7.
1
2.8.
1
2.8.
2
3.1.
1
3.1.
2
3.1.
3
3.2.
1
3.2.
2
3.2.
3
3.2.
4
3.2.
5
3.3.
1
3.3.
2
3.4.
1
3.5.
1
3.6.
1
3.6.
2
3.7.
1
3.7.
2
4.1.
1
4.2.
1
4.2.
2
4.3.
1
4.3.
2
4.3.
3
4.4.
1
4.4.
2
4.4.
3
1 Blabla sdsd lkj dsaljsd ofiawh dosansdolfij k jlsajkdl fdkjlsdaj dlsfkjsad
X X X X X X X X X X2 sdfljkjln skld ldskj dslakmaldskmf
ljwoeiewfosdsd lsdk flsdkj dsfljksdf X X X X X X X X X X X X X X
3 sadf lksdjlds kjdlkjd flsd,d,msf X X X X X4 as kldskjdsl dskj,sdfam sdlfdkssj flds X X X X X X X X X X X X X X X X X5 sdfew jdsh kfdjhdf ksdjsd X X X X X X X X X X X X X X X X X X6 Blabla sdfa d ads hdksafjhdskdhj ksdahj
kdsjhX X X X
7 dfgs lkjsd lfjkdsl jds.,adsmsd foldfkj X X X X X X X X8 dsf lksdj ldfjdslms,.as,mfmlasdkjsdl X X X X X9 zh fdadsfads sdfsd adsjkh
sdakjhwekerhkash das kfsjahX X X X X X X X
10 Blabla sa dldsjlsdfakjweljk falds.,sdfm sdlksdj X X X11 dd ddssd dssds dafjlsdfk sdflasdkjfl fjfasl
sladfj lj sdlksdf ldfsjkdsf lsadf lsdf l X X X X X X X
12 Blabla sk hskds kd hkwjehkehsdk jfhk sdh fkjsdfhk dsh kdsjhwekrhj ewrkh ewrkj
X X X X X X13 sda lkjsdldjfkflwenllkj lksfdjf lsdkj
dfslkdjslsdaf ksdfjl sdjldsfj kddX X X X X X X
14 sdsafdwe ioweur oweri uo uiwer erwoi weroiewru weroui ewro wer
X X X X X X X X15 swert kjlds ldskj lsdkj sdwee X X X X X X X
4.4
Back
up a
nd r
ecov
ery
3.6
Net
wor
k se
curit
y
3.7
Phys
ical
sec
urity
4.2
Job
sche
dulin
g
4.3
Inci
dent
s m
anag
emen
t
2.8
Doc
umen
tatio
n an
d tr
aini
ng
3.1
Info
rmat
ion
secu
rity
man
agem
ent
3.2
Acc
ess
to
appl
icat
ions
3.3
Priv
ilege
acc
ess
to
syst
ems
and
data
1.1
Prog
ram
de
velo
pmen
t m
etho
dolo
gy
1.7
Test
ing
and
acce
ptan
ce
1.8
Doc
umen
tatio
n an
d tr
aini
ng
2.5
Test
ing
and
acce
ptan
ce
Version 1: “Just” showing which measures will reduce specific risk scenarios
3: Mitigating risk scenarios with measures correlated to ISO27002
1.2
SLA
s
1.3
Proj
ect
initi
atio
n
1.4
Ana
lysi
s an
d de
sign
1.5
Proj
ect
exec
utio
n
1.6
Dat
a m
igra
tion
2.1
Mgn
t. o
f pr
ogra
m
chan
ges
2.2
SLA
s2.
3 D
ocum
enta
tion
of
chan
ges
2.4
App
rova
l of
chan
ges
2.6
Dep
loym
ent
of
chan
ges
2.7
Emer
genc
y ch
ange
s
3.4
App
licat
ions
inte
grity
3.5
Syst
ems
a. in
fras
tr.
sec.
4.1
SLA
Nr. scenario name
scenario description
1.1.
1
1.1.
2
1.1.
3
1.2.
1
1.3.
1
1.4.
1
1.5.
1
1.6.
1
1.7.
1
1.7.
2
1.7.
3
1.7.
4
1.8.
1
1.8.
2
2.1.
1
2.2.
1
2.3.
1
2.4.
1
2.5.
1
2.5.
2
2.6.
1
2.7.
1
2.8.
1
2.8.
2
3.1.
1
3.1.
2
3.1.
3
3.2.
1
3.2.
2
3.2.
3
3.2.
4
3.2.
5
3.3.
1
3.3.
2
3.4.
1
3.5.
1
3.6.
1
3.6.
2
3.7.
1
3.7.
2
4.1.
1
4.2.
1
4.2.
2
4.3.
1
4.3.
2
4.3.
3
4.4.
1
4.4.
2
4.4.
3
1 Blabla sdsd lkj dsaljsd ofiawh dosansdolfij k jlsajkdl fdkjlsdaj dlsfkjsad
S S P S S S S P S S2 sdfljkjln skld ldskj dslakmaldskmf
ljwoeiewfosdsd lsdk flsdkj dsfljksdf S S P S S S S S S P S S S S
3 sadf lksdjlds kjdlkjd flsd,d,msf S S S S S4 as kldskjdsl dskj,sdfam sdlfdkssj flds S S S S S P S S P S S S S S S S S5 sdfew jdsh kfdjhdf ksdjsd S S S P S S S P S S S S S S S S S S6 Blabla sdfa d ads hdksafjhdskdhj ksdahj
kdsjhS P S S
7 dfgs lkjsd lfjkdsl jds.,adsmsd foldfkj S S S S S S S P8 dsf lksdj ldfjdslms,.as,mfmlasdkjsdl S S S S S9 zh fdadsfads sdfsd adsjkh
sdakjhwekerhkash das kfsjahS S S S S P S S
10 Blabla sa dldsjlsdfakjweljk falds.,sdfm sdlksdj S S S11 dd ddssd dssds dafjlsdfk sdflasdkjfl fjfasl
sladfj lj sdlksdf ldfsjkdsf lsadf lsdf l S S P S S S S
12 Blabla sk hskds kd hkwjehkehsdk jfhk sdh fkjsdfhk dsh kdsjhwekrhj ewrkh ewrkj
S S S S S S13 sda lkjsdldjfkflwenllkj lksfdjf lsdkj
dfslkdjslsdaf ksdfjl sdjldsfj kddS S S S S P S
14 sdsafdwe ioweur oweri uo uiwer erwoi weroiewru weroui ewro wer
S S S S S S P S15 swert kjlds ldskj lsdkj sdwee S S P S P S S
1.1
Prog
ram
de
velo
pmen
t m
etho
dolo
gy
1.7
Test
ing
and
acce
ptan
ce
1.8
Doc
umen
tatio
n an
d tr
aini
ng
2.5
Test
ing
and
acce
ptan
ce
2.8
Doc
umen
tatio
n an
d tr
aini
ng
3.1
Info
rmat
ion
secu
rity
man
agem
ent
3.2
Acc
ess
to
appl
icat
ions
3.3
Priv
ilege
acc
ess
to
syst
ems
and
data
4.4
Back
up a
nd r
ecov
ery
3.6
Net
wor
k se
curit
y
3.7
Phys
ical
sec
urity
4.2
Job
sche
dulin
g
4.3
Inci
dent
s m
anag
emen
t
Version 2: Distinguish between primary and secondary measures
1.2
SLAs
1.3
Proj
ect
initi
atio
n
1.4
Anal
ysis
and
des
ign
1.5
Proj
ect
exec
utio
n
1.6
Data
mig
ratio
n
2.1
Mgn
t. o
f pro
gram
ch
ange
s2.
2 SL
As2.
3 Do
cum
enta
tion
of
chan
ges
2.4
Appr
oval
of c
hang
es
2.6
Depl
oym
ent
of
chan
ges
2.7
Emer
genc
y ch
ange
s
3.4
Appl
icat
ions
inte
grity
3.5
Syst
ems
a. in
fras
tr.
sec.
4.1
SLA
Nr. scenario name
scenario description
1.1.
1
1.1.
2
1.1.
3
1.2.
1
1.3.
1
1.4.
1
1.5.
1
1.6.
1
1.7.
1
1.7.
2
1.7.
3
1.7.
4
1.8.
1
1.8.
2
2.1.
1
2.2.
1
2.3.
1
2.4.
1
2.5.
1
2.5.
2
2.6.
1
2.7.
1
2.8.
1
2.8.
2
3.1.
1
3.1.
2
3.1.
3
3.2.
1
3.2.
2
3.2.
3
3.2.
4
3.2.
5
3.3.
1
3.3.
2
3.4.
1
3.5.
1
3.6.
1
3.6.
2
3.7.
1
3.7.
2
4.1.
1
4.2.
1
4.2.
2
4.3.
1
4.3.
2
4.3.
3
4.4.
1
4.4.
2
4.4.
3
maturity 1 1 2 1 2 3 2 3 2 2 1 2 3 2 1 2 1 2 3 2 1 2 1 1 2 1 2 1 0 2 1 2 1 2 2 3 2 1 2 1 2 1 1 1 2 3 2 1 2
1 Blabla sdsd lkj dsaljsd ofiawh dosansdolfij k jlsajkdl fdkjlsdaj dlsfkjsad
X X X X X X X X X X2 sdfljkjln skld ldskj dslakmaldskmf
ljwoeiewfosdsd lsdk flsdkj dsfljksdf X X X X X X X X X X X X X X
3 sadf lksdjlds kjdlkjd flsd,d,msf X X X X X4 as kldskjdsl dskj,sdfam sdlfdkssj flds X X X X X X X X X X X X X X X X X5 sdfew jdsh kfdjhdf ksdjsd X X X X X X X X X X X X X X X X X X6 Blabla sdfa d ads hdksafjhdskdhj ksdahj
kdsjhX X X X
7 dfgs lkjsd lfjkdsl jds.,adsmsd foldfkj X X X X X X X X8 dsf lksdj ldfjdslms,.as,mfmlasdkjsdl X X X X X9 zh fdadsfads sdfsd adsjkh
sdakjhwekerhkash das kfsjahX X X X X X X X
10 Blabla sa dldsjlsdfakjweljk falds.,sdfm sdlksdj X X X11 dd ddssd dssds dafjlsdfk sdflasdkjfl fjfasl
sladfj lj sdlksdf ldfsjkdsf lsadf lsdf l X X X X X X X
12 Blabla sk hskds kd hkwjehkehsdk jfhk sdh fkjsdfhk dsh kdsjhwekrhj ewrkh ewrkj
X X X X X X13 sda lkjsdldjfkflwenllkj lksfdjf lsdkj
dfslkdjslsdaf ksdfjl sdjldsfj kddX X X X X X X
14 sdsafdwe ioweur oweri uo uiwer erwoi weroiewru weroui ewro wer
X X X X X X X X15 swert kjlds ldskj lsdkj sdwee X X X X X X X
1.1
Prog
ram
de
velo
pmen
t m
etho
dolo
gy
1.7
Test
ing
and
acce
ptan
ce
1.8
Docu
men
tatio
n an
d tr
aini
ng
2.5
Test
ing
and
acce
ptan
ce
2.8
Docu
men
tatio
n an
d tr
aini
ng
3.1
Info
rmat
ion
secu
rity
man
agem
ent
3.2
Acce
ss t
o ap
plic
atio
ns
3.3
Priv
ilege
acc
ess
to
syst
ems
and
data
4.4
Back
up a
nd re
cove
ry
3.6
Netw
ork
secu
rity
3.7
Phys
ical
sec
urity
4.2
Job
sche
dulin
g
4.3
Inci
dent
s m
anag
emen
t
3: Mitigating risk scenarios with measures correlated to ISO27002
Version 3: Relating needed security measures to maturity levels of ISO27002 topics
01234 3.1
4.14.2
4.35.1
5.2
6.1
6.2
6.3
7.1
7.2
7.3
8.1
8.2
8.38.4
8.58.6
8.79.1
9.29.3
9.4
9.5
9.6
9.7
9.8
10.1
10.2
10.3
10.4
10.5
11.112.1
12.212.3
Full target level Minimal target level Milestone 3 Milestone 2 Milestone 1 Start
SOP for Maintenance of the Scenario-based (IT) Risk Landscape
This section shows a step-by-step Standard Operating Procedure (SOP) for
maintaining an (IT) risk landscape
Reasoning for SOP A Standard Operating Procedure to Ensure a Mature Process
• All risks as presented in an (IT) risk landscape are subject to (constant) change
• We therefore need a standard approach to consistently reevaluate the known scenarios and to possibly “catch” new scenarios evolving
Interfaces of SOP Linking the IT Risk Landscape to Overall Risk Management
• The current IT Risk Landscape is an important source of information for the overall IT Risk Management Process.
• Every time a new version of the IT Risk Landscape is published it will trigger the IT Risk Management Process.
Interfaces of the SOP Linking the IT Risk Landscape to Overall Risk Management
Risk Management Process Topic of this session
Monitoring
Reporting
Planning
Tracking
Analysis
Triage
Data collection
Status Report (quarterly)
Process: Scenario-based
risk analysis
Risk Treatment
Plan
IT Risk Landscape
Open Items
Varied information
sources
Key Risk Indicators
Open Item Management
ISMS Key Indicators
Updating
A C
D
B © Bitterli Consulting AG
Purpose of the Standard Operating Procedure
This SOP • defines the process of maintaining an
IT Risk Landscape; • explains the intention and benefit of the
IT Risk Landscape; • defines the interfaces to the
IT Risk Management process; • …?
Table of Contents of the SOP for Maintaining the IT Risk Landscape
• Definitions • Roles & Responsibilities • Process Steps
Operational Risk & IT Risk Clear Definitions help to Ensure Consistent Risk Assessment
• An operational risk is the risk of loss resulting from inadequate or failed internal processes, people and systems or from external events.
• An IT risk is an operational risk related to the development, operation and use of information technology.
IT Risk Scenario Clear Definitions help to Ensure Consistent Risk Assessment
• An IT risk scenario is a description of a class of related IT risks together with their possible causes, triggers and effects.
IT Risk Landscape Clear Definitions help to Ensure Consistent Risk Assessment
• An IT risk landscape is a collection of IT risk scenarios together with assessments of their severities and probabilities. The severity and probability categories of the IT risk scenarios are graphically represented by positioning the scenario numbers in a two-dimensional diagram.
Scope of the Standard Operating Procedure
• The stipulations in this SOP apply to the entire company / the XXXX Division.
• Functional Scope The IT Risk Landscape covers all operational risks related to the development, operations and use of information technology
• Out of Scope Excluded are risks that are exclusively related to business / to …
Roles & Responsibilities of the Standard Operating Procedure
• Risk Landscape Team • Risk Landscape Secretary • Risk Landscape Manager • (?) IT Quality Manager • …
3. Roles and Responsibilities IT Risk Landscape Team
• The IT Risk Landscape Team is responsible for – collecting, updating and assessing any
information about threats, vulnerabilities and incidents;
– defining IT risk scenarios and sub-scenarios; – assessing the expected damages and
probabilities of occurrence of the risk scenarios; – reviewing and including feedback.
3. Roles and Responsibilities IT Risk Landscape Secretary
• The IT Risk Landscape Secretary is a member of – the IT Risk Landscape Team and responsible for – keeping records during the scenario workshops; – keeping the documentation of the IT Risk
Landscape up-to-date; – making the documentation available to the
members of the team and other selected parties; – collecting feedback from team members;
management, business and experts.
3. Roles and Responsibilities
IT Risk Landscape Manager
• The IT Risk Landscape Manager is responsible for – staffing the IT Risk Landscape Team; – ensuring the availability of information about
threats, vulnerabilities and incidents; – scheduling and moderating the workshops; – deciding about the distribution of the
documentation; – liaising with the IT Risk Management Process; – reporting to management.
3. Roles and Responsibilities
IT Quality Function
• The IT Quality Function is responsible for – approving the documentation of the IT Risk
Landscape.
Process Steps of the Standard Operating Procedure
1. Convene the workshop 2. Prepare the workshop 3. Perform the workshop 4. Document scenarios 5. Verify scenarios 6. Versioning of risk landscape 7. Communicate results
Convene Workshop
Prepare Workshop
Perform Workshop
Document Scenario
Verify Scenario
Process Steps
Landscape Versioning
Communicate Results
Step 1: Convene the Workshop Trigger
• 1–2 times a year the IT Risk Landscape Manager schedules a regular scenario workshop, where the IT Risk Landscape Team meets to discuss and update the risk landscape.
• In case of urgency, the IT Risk Landscape Manager may convene the team in an exceptional workshop to discuss specific matters such as conflicting views on previously released documents.
Convene Workshop
Prepare Workshop
Perform Workshop
Document Scenario
Verify Scenario
Process Steps
Landscape Versioning
Communicate Results
Step 2: Prepare the Workshop
• Between the scheduled workshops, all members of the IT Risk Landscape Team collect relevant information.
• Sources for such information include: – actual security related incidents and ITSM
problems that occur internally or elsewhere; – reports of internal or external audits or security
reviews (including penetration tests); – standards, checklists and other literature; – feedback on the current or previous versions of
the risk landscape.
Convene Workshop
Prepare Workshop
Perform Workshop
Document Scenario
Verify Scenario
Process Steps
Landscape Versioning
Communicate Results
Step 2: Prepare the Workshop
• The members of the IT Risk Landscape Team prepare their input to the workshop as proposals to create, modify, merge or delete risk scenarios.
• The IT Risk Landscape Secretary redistributes this information to the IT Risk Landscape Team.
• The IT Risk Landscape Manager makes sure that input from the IT Risk Management Process is appropriately handled.
Convene Workshop
Prepare Workshop
Perform Workshop
Document Scenario
Verify Scenario
Process Steps
Landscape Versioning
Communicate Results
Step 3: Perform the Workshop
• The IT Risk Landscape Manager moderates the scenario workshop and determines which topics will be discussed.
• For every new or modified scenario the required information is recorded by the IT Risk Landscape Secretary.
• Finally, the probability and severity rating of each scenario are agreed by the members of the IT Risk Landscape Team.
Convene Workshop
Prepare Workshop
Perform Workshop
Document Scenario
Verify Scenario
Process Steps
Landscape Versioning
Communicate Results
Step 4: Document all Scenarios
• The scenario descriptions and the graphical representation of the IT risk landscape are updated immediately after the workshop by the IT Risk Landscape Secretary.
• The updated documentation is forwarded to all members of the IT Risk Landscape Team by the IT Risk Landscape Secretary for verification and feedback.
Convene Workshop
Prepare Workshop
Perform Workshop
Document Scenario
Verify Scenario
Process Steps
Landscape Versioning
Communicate Results
Step 5: Verify the Scenarios
• Feedback from team members and other persons is collected by the IT Risk Landscape Secretary and made available to all members of the IT Risk Landscape Team.
• The IT Risk Landscape Manager decides whether certain changes and new scenarios need to be forwarded to other persons for verification.
Convene Workshop
Prepare Workshop
Perform Workshop
Document Scenario
Verify Scenario
Process Steps
Landscape Versioning
Communicate Results
Step 5: Verify the Scenarios
• Purely editorial or straight-forward proposals resulting from the feedback are immediately included into the documen-tation by the IT Risk Landscape Secretary.
• In case of substantial changes that may require further discussion, the IT Risk Landscape Manager decides on the urgency of the matter. The topic may either be scheduled for the next regular workshop or an exceptional workshop may be convened.
Convene Workshop
Prepare Workshop
Perform Workshop
Document Scenario
Verify Scenario
Process Steps
Landscape Versioning
Communicate Results
Step 6: Version the Risk Landscape
• Upon considering the feedback of the verification step, the IT Risk Landscape Manager decides whether the documented and verified results of the scenario workshop become the new version of the risk landscape replacing the current published version.
• Otherwise the current version stays valid at least until after the next scenario workshop.
Convene Workshop
Prepare Workshop
Perform Workshop
Document Scenario
Verify Scenario
Process Steps
Landscape Versioning
Communicate Results
Step 7: Communicate the Results
• The new version of the IT Risk Landscape is provided as input to the IT Risk Management Process and presented to management by the IT Risk Landscape Manager to reflect the overall IT risk situation.
Convene Workshop
Prepare Workshop
Perform Workshop
Document Scenario
Verify Scenario
Process Steps
Landscape Versioning
Communicate Results
Wrap up
Wrap up (I)
• Using scenario-based (IT) risk landscape is one of many approaches to (IT) risk assessment
• The value of this approach lies in the appropriate use of internally available knowledge and experience
• The creative process of identifying risks must be supplement by a systematic verification of the completeness of the risks found
Wrap up (II)
• The main difficulty of this approach that it needs consistent application of a mature Standard Operating Procedure
• The results of the IT Risk Landscape Process must be integrated into the overall approach for – IT Risk Management (!) – Operational Risk Management (?)
For More Information:
Peter R. Bitterli, CISA, CISM, CGEIT
Bitterli Consulting AG ITACS Training AG BPREX Consulting Group AG
[email protected] www.bitterli.com / www.itacs.com / www.bprex.ch
Thank you!