Hands on IT risk assessment

1

Layer One conference

Hands on: IT Risk Assessment

George D. Delikouras, CISM, CGEIT, C-RISK

Athens International Airport S.A. Head Information security

IT&T Business Unit [email protected]

3rd DATA CENTER INFRASTRUCTURES NETWORKING & CABLING CONFERENCE,

ATExcelixi, October 11, 2013

mailto:[email protected]

Key Findings from the industry

• Despite risk assessment being specified in certain regulations and numerous de facto standards, many organizations have not implemented formal risk assessment processes for reasons that include a lack of demonstrated benefit and a lack of skilled personnel.

• Risk assessments do not address risks at a sufficiently granular level and seldom deliver pragmatic, implementable advice to resource owners.

Key Findings from the industry

• Risk and security teams are looking for a simple risk assessment method that makes low time demands on IT and business personnel.

• The method we present, provides a standard approach to IT risk assessments and resolves the stumbling blocks to performing formal, regular risk assessments.

Recommendations

• Develop business-focused evaluation criteria and reusable templates and reference tables for consistency and standardization.

• Define the scope and objectives of your risk assessments to focus the risk-assessment process.

• Use Risk Assessment Methodology to identify and evaluate risks.

• Develop formal treatment plans for treatment tracking and reporting.

Analysis - Definitions

Risk management is the process of identifying risk, assessing risk and taking steps to reduce risk to an acceptable level. The risk management process — when effectively applied — enables organizations to balance the financial and operational costs of control measures with the level of risk caused by exposure to threats that could adversely affect the achievement of business objectives.

Analysis - Definitions

Risk Combination of the probability of an event and its consequence

Probability Extent to which an event is likely to occur

Risk assessment Overall process of risk analysis and risk evaluation

Risk control Actions implementing risk management decisions

Risk reduction Actions taken to lessen the probability, negative consequences, or both, associated with a risk

Mitigation Limitation of any negative consequence of a particular event

Risk transfer Sharing with another party the burden of loss or benefit of gain, for a risk

Residual risk Risk remaining after risk treatment

Risk acceptance Decision to accept a risk

What people think we do

What usually happens

An assessment may be performed on IT as a whole or on specific processes to determine IT's risk profile or its criticality to the organization. In reality, risk assessments tend to be performed in an ad hoc manner, usually at a high level, to satisfy corporate operational risk reporting requirements, rather than to derive practical treatment options to reduce risks.

Overcoming Objections

Understanding the objections, real and perceived, that limit the adoption of risk assessment is the first step toward implementing risk assessment as a formal, measurable process that adds value to the business. Objections are usually based on negative experiences from past assessments, which were time-consuming and did not result in practical actions to address risk.

Other objections

• Risk Security personnel have to be taken away from normal operational activities (often from departments that are short-staffed) to perform risk assessments.

• Risk and security personnel are concerned about the potentially repetitive and tedious nature of the process.

• Involvement of business personnel in a process in which they do not see business benefit.

• The perception that risk assessments are too subjective to provide anything more than conceptual information.

Always remember: Perception is stronger than reality

Justification for Risk Assessments

Risk assessments provide a formal, standardized, repeatable process for identifying and treating a wide range of risks, including risks to efficient and effective operations, and strategic risks, such as reputation damage.

The value of a formal, repeatable method is in consistent risk measurement and comparative reporting across business divisions, the use of standard terminology, and the ability to record risk information for current management and to obtain historical perspectives.

Practical reasons for risk assessment

• Gaining a better understanding of the organization's IT risk profile

• Addressing IT and information security risks

• Providing management assurance that IT risks are managed

• Identifying critical IT resources

• Complying with regulations and policies

• Risk, security and business continuity planning

• Prioritizing spending on risk control complying with regulations and policies

Foundation Documents I

Risk Assessment is a methodology that can be applied to achieve multiple risk assessment objectives and meet diverse risk reporting requirements.

The method uses a foundation comprising risk evaluation criteria, threat tables, impact control tables, statements of materiality, statements of acceptable risk and data classification to ensure the consistent assessment of risks.

Foundation Documents II

An initial set of artifacts is developed, which is refined after each assessment to create a complete set for streamlining ongoing assessments.

Certain artifacts, such as risk scenarios, will be defined during the assessment phase and refined over time.

The artifacts are consolidated in a single repository or risk catalog. The risk catalog also holds a history of past assessments and the current risk register to facilitate risk reporting

Foundation process

Process Artifact Description

Build/review foundation

Risk evaluation criteria

Define/refine the criteria against which risk will be evaluated, statements of materiality, definition of acceptable risk, data classification and definitions of probability.

Threats and impacts Define/refine a list of plausible threats and impacts to the business.

Risk register The risk register documents risks that have been identified for treatment in order of priority.

Risk catalogue The risk catalog is a central repository for risk-related information, including all related artifacts and past risk treatment activities.

Controls Define/refine a table of existing controls and evaluate control maturity.

Data classification Define/refine data classes and an associated, required security baseline.

Resource owners Define/refine resources and resource owners.

The Delphic Technique

A team of people having knowledge of the subject being assessed is appointed to iteratively review scenarios, incorporating threats, impacts, probabilities and time.

A member of the risk and security team develops the first-pass scenarios from previously defined threat/impact and control tables.

The scenarios are sent to individual team members three times for review and comment, each iteration having an updated version of the scenarios with consolidated responses from the preceding round and with a different focus.

Phase 1: Develop scenario

Subprocess/Task Description

Scope and objectives

■ Define the purpose (for example, risk reporting, risk reduction,

risk and security planning, IT processes and so on). ■ Define the resources in scope (for example, specific

application, platform, data, IT process and so on). ■ Define the deliverable (for example, treatment plan,

prioritization of resources for detailed assessment or risk status report).

Appoint evaluation team

■ Appoint a review team of four to six experts, depending on the

assessment type. ■ Appoint an administrator.

Scenario development

■ Based on the scope and objectives, develop a set of scenarios

for review.

Phase 2: Risk evaluation


Plausible scenarios are developed and distributed to the evaluation team for anonymous responses. Team will review threats, impacts, probabilities and controls.

Pass 1: Scenario evaluation

■ Distribute scenarios with questions to team for review and

response. ■ Consolidate responses from Pass 1.

Pass 2: Risk modelling

■ Distribute updated scenarios with questions relating to

impacts and probabilities. ■ Consolidate responses from Pass 2.

Pass 3: Controls review

■ Distribute updated scenarios with questions relating to

controls. ■ Consolidate responses from Pass 3.

Phase 3: Prepare response


Develop the risk treatment plan.

Address consensus failure

■ Resolve consensus issues with resource owner or assessment

sponsor.

Develop a treatment plan

■ Define a residual risk statement for acceptance by the

resource owner. ■ If the residual risk is unacceptable, then develop a risk

treatment proposal. ■ On acceptance of the proposal, develop a treatment action

plan.

Develop a final deliverable

■ For assessments that do not require a treatment plan, produce

the final assessment report in the required format.

Phase 4: Plans and documentation


Develop the risk treatment plan.

Address consensus failure

■ Resolve consensus issues with resource owner or assessment

sponsor.

Develop a treatment plan

■ Define a residual risk statement for acceptance by the

resource owner. ■ If the residual risk is unacceptable, then develop a risk

treatment proposal. ■ On acceptance of the proposal, develop a treatment action

plan.

Develop a final deliverable

■ For assessments that do not require a treatment plan, produce

the final assessment report in the required format.

Using Time

… as the Basis for a Continuous Risk Program

Time is included as a variable in the risk scenarios to show the change in risk over time.

Impacts and the probability of impact change for various reasons, for example, the value of the resource to the business could change, causing any loss to have a higher impact, or the value of the resource to competitors could increase, causing the probability of loss to rise.

The threat itself may change because of societal, legal or environmental shifts.

Example of annual risk planning

Hands-on IT risk assessment

• Examples on risk assessment for IT systems

• Examples on risk assessment for IT projects

• The phases: – Initiation: Identify the threats – Phase 1: Assess the impact – Phase 2: Assess the probability – Phase 3: Assess the control over threats – Calculate and present the risks

Probability: The subjective factor

• Scale selection is critical for the exercise success!

• A scale from 1 to 5 is the best choice

• The middle of the scale, 3 represents absolute uncertainty. Probability is 50% (heads or tails)

• The basis of the scale, 1 represents absolute certainty that the threat will NOT occur

• The top of the scale, 5 represents absolute certainty that the threat will occur

• Then it is relatively easy to choose between 2 and 4!

An IT project example

Risk assessment form (step 1 of 5: Identify the threats)

Project name: Decision support system roll-out Step 1: Identify the threats Risk ID

Project definition (scope-objectives-deliverables) is not clear or not exists 1 Time plan does not exist or problematic 2 No or poor progress reporting 3 No or poor financial reporting 4 Steering Committee not defined or inactive 5 Budget does not exist or is not secured 6

Contractor is not in position to continue the project because of dispute with 7 Delays due to resource shortage/unavailability from contractor 8 Delays due to resource shortage/unavailability from customer 9

Delays due to technical problems as a result of inefficient design during 10 Delays due to slow decision making process from steering committee or 11 Communication problems between project team members (for contractors in 12 Communication problems due to language differences 13 (all the above are indicative threats, replace with actual)


Risk assessment form (step 2: Assess the impact)

Project name: Decision support system roll-out Step 2: Assess the impact of each threat Impact factor

Expert 1 Expert 2 Expert 3 Expert 4 Expert 5 Expert 6

Project definition (scope-objectives-deliverables) is not clear or not exists 4 4 2 2 3 4

Time plan does not exist or problematic 2 4 3 3 3 3

No or poor progress reporting 2 3 2 2 2 3

No or poor financial reporting 2 3 2 2 2 3

Steering Committee not defined or inactive 3 3 3 3 4 3

Budget does not exist or is not secured 4 4 5 4 4 4

Contractor is not in position to continue the project because of dispute with customer 5 5 4 4 4 5

Delays due to resource shortage/unavailability from contractor

Delays due to resource shortage/unavailability from cuctomer 4 4 3 3 4 3

Delays due to technical problems as a result of inefficient design during development phase 4 4 4 3 3 4

Delays due to slow decision making process from steering committee or customer 4 4 3 4 4 3


Risk assessment form (step 4: Assess the probability)

Project name: Decision support system roll-out Step 3: Assess the probability for each threat Probability








Contractor is not in position to continue the project because of dispute with customer 2 2 1 1 2 1


Delays due to resource shortage/unavailability from customer 3 3 3 2 3 2


Delays due to slow decision making process from steering committee or customer 4 4 3 3 3 4

Communication problems between project team members (for contractors in consortia) 2 2 2 1 2 2

Communication problems due to language differences 3 3 2 1 2 2

Delays due to budget limitations from cuctomer part 3 3 2 2 2 2

Delays due to contractual/administrative/legal disputes with cuctomer 3 3 3 5 3 4

Delays due to compliance issues (change management failure, failover procedure not clear) 2 2 2 2 2 1

Procurement delays for equipment from vendors 1 1 1 1 1 1


Risk assessment form (step 3: Assess the control)

Project name: Flight information system roll-out Step 3: Assess the control over each threat Control








Contractor is not in position to continue the project because of dispute with cuctomer 2 2 1 1 2 1


Delays due to resource shortage/unavailability from cuctomer 3 3 3 2 3 2


Delays due to slow decision making process from steering committee or cuctomer 4 4 3 3 3 4

Communication problems between project team members (for contractors in consortia) 2 2 2 1 2 2

Communication problems due to language differences 3 3 2 1 2 2

Delays due to budget limitations from cuctomer part 3 3 2 2 2 2

Delays due to contractual/administrative/legal disputes with cuctomer 3 3 3 5 3 4

Delays due to compliance issues (change management failure, failover procedure not clear) 2 2 2 2 2 1

Procurement delays for equipment from vendors 1 1 1 1 1 1


1,83

2,33

1,50 1,67

2,67

2,33 3,83

0,00

4,50

2,00

3,50

2,50 2,33 2,50

5,00

2,17

3,00

2,83

4,00

5,00

4,00

0,00

5,00

4,67 3,33

3,50 4,00

0,00 0,00

2,33

0,00

5,00

10,00

15,00

20,00

25,00

0,00 1,00 2,00 3,00 4,00 5,00

Ris

k

Control

Risk assessment

High risk

but good

Low risk

and good

Low risk but

not good

High risk

and no

Column A Column B

Product AXB (Impact) X (Probability) Risk control

13,55 7,39 1,83

14,00 6,00 2,33

6,42 4,28 1,50

7,13 4,28 1,67

15,48 5,81 2,67

17,82 7,64 2,33

25,88 6,75 3,83

0,00 0,00 0,00

42,00 9,33 4,50

12,22 6,11 2,00

44,92 12,83 3,50

11,46 4,58 2,50

11,80 5,06 2,33

14,58 5,83 2,50

78,75 15,75 5,00

11,92 5,50 2,17

10,50 3,50 3,00

33,06 11,67 2,83

40,00 10,00 4,00

30,56 6,11 5,00

10,00 2,50 4,00

0,00 0,00 0,00

28,89 5,78 5,00

45,50 9,75 4,67

29,63 8,89 3,33

44,72 12,78 3,50

56,00 14,00 4,00

0,00 0,00 0,00

0,00 0,00 0,00

19,96 8,56 2,33

29,56 9,33 3,17

24,50 7,00 3,50

10,39 5,19 2,00

19,56 7,33 2,67

All values above 31,25 in the column "Product AXB" indicate risks that need risk management

Impact assessment example

Probability assessment example

Risk control assessment example

Recommendations

• Develop business-focused evaluation criteria and reusable templates and reference tables for consistency and standardization.

• Define the scope and objectives of your risk assessments to focus the risk-assessment process.

• Use Risk Assessment methodology to identify and evaluate risks.

• Develop formal treatment plans for treatment tracking and reporting

• Consolidate risk information in a data repository for risk reporting, ongoing risk management and maintaining a history of risk management activities.

37

Athens International Airport S.A.

Thank you for your attention!

George D. Delikouras

CISM, CGEIT, C-RISK

Athens International Airport S.A. IT&T Business Unit

[email protected]

Hands on IT risk assessment

Documents

Transcript of Hands on IT risk assessment