IT Risk Management, Planning and Mitigation TCOM 5253 / MSIS 4253 Quantifying Risk – the $$$

(c) 2007 Charles G. Gray 1

IT Risk Management, Planning and Mitigation

TCOM 5253 / MSIS 4253

Quantifying Risk – the $$$

25 October/1 November 2007

Charles G. Gray


Qualitative vs. Quantitative• We used the Qualitative approach first to:

– Identify risks– Prioritize the work– Avoid time-consuming quantitative analyses

early in the process• Extensive time and effort needed to agree on

monetary estimates• Avoid delays in the analysis due to disagreements

among stakeholders

• Attempt to strike a balance between accuracy and efficiency


The Hard Work Begins - $$$• Task one - Assign a monetary value to each

asset class• Task two - Identify the asset value for each risk• Task three - Produce the single loss expectancy

value• Task four - Determine the Annual Rate of

Occurrence (ARO)• Task five - Determine the Annual Loss

Expectancy (ALE)


A New Industry Developing• The insurance industry is just beginning to

insure IT risks

• Actuarial tables may soon be available– Aid in estimating asset value– Assign risk probabilities

• Financial risk management team may have insurance valuation and coverage for specific assets

• Stay tuned – call your insurance broker


Assigning Monetary Values

• Begin with the “HBI” assets

• Assign monetary values for – Tangible assets

• Equipment, facilities, software, etc.

– Intangible assets• Intellectual property, personnel skills, “goodwill”,

corporate image, etc.

• Be warned! - This is not easy


Categories of Values (TCO)• Replacement cost• Maintenance cost• Redundancy/availability • Organization/market reputation• Organization productivity• Annual revenue/profit generated• Competitive advantage• Internal operating efficiencies• Legal/compliance liability


Choosing an Asset Value• From slide 6, total the values to determine the

TCO estimate for the asset• Repeat the process for EACH HBI asset

– The Risk Management Team should plan to devote considerable time to this effort – it is not simple

• From all HBI assets, select one monetary value to represent the worth of the asset class– Most conservative is to choose the lowest, but a

company may also use an average (or other) value– Value must be meaningful to the organization– This is a management/stakeholder decision


An Alternate Approach for HBI Assets

• Use FASB guidelines for the definition of “materiality” in financial statements for publicly traded companies as a reference point only (no “formula” approach)– General rule of reference is “5% of financial

statement values”• For a $5B company = $250M

– Values vary significantly between organizations– May NOT work for MBI and LBI values


MBI and LBI Asset Classes• Repeat the activities on slides 5, 6, and 7

for the MBI and LBI classes– May choose the current costs of security-

specific controls for each asset class• Example: estimated total cost for software,

hardware and operational resources in order to provide antivirus services for the organization

– Or any other value that the stakeholders/business owners agree upon


Identify the Asset Value

• Assign an asset value to each asset class– HBI = ?? (e.g., from slide 8, $250M)– MBI = ?? (e.g., could be HBI / 2)– LBI = ?? (e.g., could be MBI / 2)

• It has to be supportable with documentation or experience of the stakeholders, and agreed by all

• Note: Each organization should plan to revise value estimates based on experience


Single Loss Expectancy (SLE)

• SLE = Asset value * Exposure factor

• Use the same exposure ratings that were developed for the detailed risk analysis– May require adjustments as more experience

is gained– Exposure factor is the estimated percent of

damage to an asset


SLE ExampleHBI value = $250M

(Example only)

Exposure Rating

Exposure Factor (%)

Single Loss Expectancy

Asset Class

(1)

Value

(2) (3) (4) (5)

High Business Impact $250M 5 100

MBI $125M 4 80

LBI $50M 3 60 $30M

(Example Only)

2 40

1 20

Estimated risk value (or SLE) = Asset class value * Exposure factor


Annual Rate of Occurrence (ARO)• What is the probability of the risk occurring?

• In today’s environment, are these “description examples” adequate? Should time frames be shorter?

• The Information Security Group must still select ONE value to represent the ARO.

Qualitative

Rating

Description ARO Range Description Examples

High Likely > = 1 Impact once or more per year

Medium Probable 0.99 - 0.33 At least once every 1-3 years

Low Not highly probable

< 0.33 Less frequent than every three years


Annual Loss Expectancy (ALE)• Annualized Loss Expectancy

– ALE = SLE * ARO

• Attempt to annualize the potential cost of the risk– NOT an annualized expense that can be

budgeted for (such as depreciation)• Useful for estimating cost/impact ONLY

– IF the risk is realized, the impact may occur in its entirety (regardless of the exposure rating and ARO estimates)


ALE Example

Risk description

(1)

Asset class value

(2)

Exposure rating

(3)

Exposure value

(%)

(4)

SLE

(= 2 * 4)

(5)

ARO

(6)

ALE

(= 5 * 6)

(7)

LAN Host compromise

$125M

(MBI)

4 80 $100M 0.5 $50M

Unauthorized remote access risk

$125M

(MBI)

5 100 $125M 1 $125M


Summary

• Planning, data gathering and prioritization steps seek to balance accuracy and efficiency

• Use a hybrid approach applying qualitative steps first to triage risks, and then use financial techniques (quantitative analysis) to provide further definition


The Result of the Risk Management Assessment Phase

• A prioritized list of risks to the organization’s most valuable assets

• Estimates of financial impact


Risk Management Project Status Check

• At this point, all concerned must acknowledge the results obtained thus far, and agree to the ongoing process– Stakeholders/business owners– Security Risk Management Team– Executive Sponsor

• Next step is to determine appropriate mitigation actions


Next Objective

• Develop clear plans to control, accept, transfer, or avoid each of the top risks identified in the risk assessment process


Risk Mitigation Options (1)• Assumption – Accept the potential risk and

continue to operate the IT system– Also known as “self insurance”

• Avoidance – Eliminate the risk cause and/or consequence– Add controls to prevent risk from occurring– Remove certain functions– Shut down the system

• Not highly likely – so avoidance is not considered to be a viable option for most organizations


Risk Mitigation Options (2)• Limitation – Implement controls that

minimize the adverse impact of a threat– Use of supporting, detection or preventive

controls– Limited system operation pending

implementation of additional mitigation actions

• Transfer – Use other options to compensate for the loss (e.g., insurance)


Process Overview

1

2

3 4

5

6

Security Risk Management Team

Mitigation Owner

Security Steering Committee

Define functional requirements

Identify control solutions

Review solutions

Estimate risk reduction

Estimate cost of solution

Select the risk mitigation strategy


Roles and Responsibilities (1)• Business Operations

– Identify procedural controls available to manage risk

• Business Owner– Owns the cost/benefit analysis for the assets

• Finance– Assists with the C/B analysis and with budget

development

• Human Resources– Identifies personnel training requirements and

controls


Roles and Responsibilities (2)• IT – Architecture

– Identifies and evaluates potential controls

• IT – Engineering– Determines cost of control solutions and how

to implement them

• IT – Operations– Implements technical control solutions

• Internal Audit– Identifies compliance requirements and

review control effectiveness


Roles and Responsibilities (3)

• Legal– Identifies legal, policy and contractual

controls and validates value estimates created for brand impact, corporate liability, and other business issues

• Public Relations– Validates value estimates created for brand

impact, corporate liability, other business issues


Roles and Responsibilities (4)• Security Steering Committee

– Selects control solutions based on recommendations from the Risk Management Team

• Risk Management Team– Defines functional requirements for the

controls for each risk, communicates project status to stakeholders and affected users as needed

• SME/security technologist assigned to each identified risk


Keys to Success• Players must recognize that significant

resources will be required ($$ and heads)– RM team must clearly explain expectations

• Build consensus– Underlying dissention may undermine RM team

recommendations even after presentation to the security steering (executive) committee

• Avoid filibusters– Refusal to agree to a recommendation– Seek to impose a minority position on the

majority


Process Overview

1

2

3 4

5

6


Mitigation Owner




Review solutions





Define Functional Requirements

• Defined clearly for each risk

• Functions desired, not technologies to be specified

• Define what the controls must accomplish

• Define what needs to be done – not how it is to be done

• Review at least annually, or when a risk is perceived to change


Key Words in Requirements• MUST, REQUIRED, SHALL

– An absolute requirement

• MUST NOT, SHALL NOT– An absolute prohibition

• SHOULD, RECOMMENDED– Consider particular circumstances– Weigh full implications of choosing a different course

of action (may apply to LBI risk)

• SHOULD NOT, NOT RECOMMENDED– Understand the full implications

• MAY, OPTIONAL – Only if truly “optional”


Process Overview

1

2

3 4

5

6


Mitigation Owner




Review solutions





Identify Control Solutions• List of potential controls for each risk

• Assistance from the Information Security Group, consultants, SMEs

• Two basic methods (covered on the following slides)– Informal brainstorming– Identify potential controls by: organizational,

operational, technical, subdivided into• Prevention, detection/recovery, management


Brainstorming Questions• What steps could be taken to resist or

prevent the risk from occurring?• What could the organization do to recover

from a risk exploit?• What could be done to detect a risk exploit

while it is occurring?• How can controls be audited and

monitored?• How can effectiveness be validated?• What else could be done to manage a risk?


Organizational Controls (1)– Preventive controls– Clear (documented) roles and responsibilities– Separation of duties – least privileges

• Compartmentalization

– Documented security plans and procedures– Security training/awareness campaigns– Controls for granting/terminating access– Processes for granting access to contractors,

vendors, partners and customers• Compartmentalization


Organizational Controls (2)• Detection Controls

– Ongoing risk management programs– Recurring reviews of controls to ensure

continued effectiveness– Background investigations on candidates for

employment• Consider internal promotions with different

responsibilities

– Rotate duties• Ferret out possible nefarious activities by members

of the IT staff


Organizational Controls (3)

• Management Controls– Incident response planning

• Quickly react to and recover from security violations

• Minimize impact of the incident• Prevent the spread to other systems

– Business continuity planning• Aids in recovering from catastrophic events that

might impact a large portion of the IT infrastructure


Operational Controls (1)• Preventive controls

– Physical protection for computing facilities• Locks, fences, guards, intrusion detection

– Physical protection for end-user systems• Mobile computer locks, encryption for mobiles

– Emergency backup power– Fire protection – automatic fire suppression– Temperature and humidity control– Media access control and disposal procedures– Off-site backup storage facilities


Operational Controls (2)• Detection and recovery controls

– Physical security• Sensors, • Alarms, • Cameras, • Motion detectors

– Environmental security• Smoke/fire detectors• Alarms• Sensors• Flood detectors


Technological Controls (1)

• All of the technological components of an organization’s IT systems– System architecture/design– Engineering– Hardware– Software– Firmware

• Controls vary considerably in complexity and effectiveness



• Preventive controls– Authentication

• Validating the credentials of a person, process or device

– Digital signatures, smart cards, biometric data, combination of username/password

– Authorization• Granting a person, process or device access to

certain information– Derived from the identity of the person or device

requesting access, verified through authentication


Technological Controls (3)• More preventive controls

– Nonrepudiation• Ensure that an IT system user cannot falsely deny

that they performed an action• Undeniable proof that the user took a specific

action, such as money transfer, authorizing a purchase, or sending a message

– Access control• Limit user access based on identity or membership

in a predefined group

– Protected communications• Encryption to protect the integrity and

confidentiality of information transmitted



• Detection and Recovery controls– Audit systems

• Monitor and track system behavior deviating from standards

• Fundamental tool for detecting, understanding, and recovering from security breaches

– Antivirus programs• Detect and respond to malicious software

– System integrity tools• Detect unauthorized system changes• Should run automatically in the “background”


Technological Controls (5)• Management controls

– Security administration tools included in some operating systems

• Maintain, support and troubleshoot security feature

– Cryptography • Foundation for many other controls• Create, store and distribute crypto keys

– Identification• Accountability• Access control (discretionary, role-based, mandatory)


Next Week

• How well do the proposed solutions meet the requirements?

• Estimating the risk reduction

• Estimating the solution cost

• Cost/benefit analysis

• Selecting solutions and preparing for implementation

Documents

IT Risk Management, Planning and Mitigation TCOM 5253 / MSIS 4253 Quantifying Risk – the $$$