Scenario-based (IT) Risk Assessment & Management · Abstract (I) Scenario-based (IT) Risk Assessment & Management • Following the proliferation of regulations such as the Sarbanes-Oxley

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


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


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



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)



Analysis Security Aspects Criteria based on ISO27002; Tool © Bitterli Consulting



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



Monitoring of State Useful for Managers with Need for Detailed Information



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


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


4: Defining Acceptable Risk Levels Using Examples from the Risk IT Framework


?

4: Defining Acceptable Risk Levels Using Examples from the Risk IT Framework


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


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


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


IT Risk Landscape Example from the Risk IT Framework


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


Excel Tool used for Verification Assessment of Threats Catalogue



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


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


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


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


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


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


S S S S S S13 sda lkjsdldjfkflwenllkj lksfdjf lsdkj

dfslkdjslsdaf ksdfjl sdjldsfj kddS S S S S P S


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


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


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


X X X X X X13 sda lkjsdldjfkflwenllkj lksfdjf lsdkj

dfslkdjslsdaf ksdfjl sdjldsfj kddX X X X X X X


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


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


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


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


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


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


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


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


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


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


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!

Documents

Scenario-based (IT) Risk Assessment & Management · Abstract (I) Scenario-based (IT) Risk Assessment & Management • Following the proliferation of regulations such as the Sarbanes-Oxley