(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
(c) 2007 Charles G. Gray 2
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
(c) 2007 Charles G. Gray 3
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)
(c) 2007 Charles G. Gray 4
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
(c) 2007 Charles G. Gray 5
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
(c) 2007 Charles G. Gray 6
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
(c) 2007 Charles G. Gray 7
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
(c) 2007 Charles G. Gray 8
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
(c) 2007 Charles G. Gray 9
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
(c) 2007 Charles G. Gray 10
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
(c) 2007 Charles G. Gray 11
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
(c) 2007 Charles G. Gray 12
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
(c) 2007 Charles G. Gray 13
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
(c) 2007 Charles G. Gray 14
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)
(c) 2007 Charles G. Gray 15
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
(c) 2007 Charles G. Gray 16
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
(c) 2007 Charles G. Gray 17
The Result of the Risk Management Assessment Phase
• A prioritized list of risks to the organization’s most valuable assets
• Estimates of financial impact
(c) 2007 Charles G. Gray 18
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
(c) 2007 Charles G. Gray 19
Next Objective
• Develop clear plans to control, accept, transfer, or avoid each of the top risks identified in the risk assessment process
(c) 2007 Charles G. Gray 20
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
(c) 2007 Charles G. Gray 21
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)
(c) 2007 Charles G. Gray 22
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
(c) 2007 Charles G. Gray 23
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
(c) 2007 Charles G. Gray 24
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
(c) 2007 Charles G. Gray 25
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
(c) 2007 Charles G. Gray 26
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
(c) 2007 Charles G. Gray 27
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
(c) 2007 Charles G. Gray 28
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
(c) 2007 Charles G. Gray 29
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
(c) 2007 Charles G. Gray 30
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”
(c) 2007 Charles G. Gray 31
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
(c) 2007 Charles G. Gray 32
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
(c) 2007 Charles G. Gray 33
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?
(c) 2007 Charles G. Gray 34
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
(c) 2007 Charles G. Gray 35
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
(c) 2007 Charles G. Gray 36
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
(c) 2007 Charles G. Gray 37
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
(c) 2007 Charles G. Gray 38
Operational Controls (2)• Detection and recovery controls
– Physical security• Sensors, • Alarms, • Cameras, • Motion detectors
– Environmental security• Smoke/fire detectors• Alarms• Sensors• Flood detectors
(c) 2007 Charles G. Gray 39
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
(c) 2007 Charles G. Gray 40
Technological Controls (2)
• 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
(c) 2007 Charles G. Gray 41
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
(c) 2007 Charles G. Gray 42
Technological Controls (4)
• 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”
(c) 2007 Charles G. Gray 43
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)
(c) 2007 Charles G. Gray 44
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