Risk Management

S.S. Yau

CSE494/598, Fall 2005

What is a risk
Vulnerability

Threat (attacker)

Information System
At Risk

Concepts revisit
A threat is a potential occurrence that can have an
undesirable effect on the system assets or resources
A vulnerability is a weakness that makes a threat to possibly
occur
A risk is a possible future negative event that may affect the
successful operations of a system
A risk is not necessarily an ongoing problem, but it may become one

S.S. Yau

CSE494/598, Fall 2005

Identify Possible Risks

What is at risk?

Product design documents

Customer information
Companys future plan

What is the threat and where does the threat come from?

Who? (competitors, foreign agents, hackers)

Motivation (national security, money, fame, fun)
Target (see confidential data, change data, deface)
Capabilities (intellect, equipment, money)

What vulnerabilities can be exploited

S.S. Yau

Technology
Process
Network
People
CSE494/598, Fall 2005

Cost/Benefit Analysis
After identifying possible risks, a cost/benefit analysis
needs to be performed due to the following reasons:
Infeasible or sometimes impossible to implement a perfect
secure systems
Cost/benefit analysis helps identify risks which will most
likely happen, and will cause severe damages if happens
Some risks always there (residual risk), but highly unlikely
to become a problem; or even if they become problems,
they can easily be contained and solved. These risks are
treated as acceptable risks in a system.
Results of a cost/benefit analysis can help allocate limited
system resources to most needed areas
S.S. Yau

CSE494/598, Fall 2005

Risk Analysis
A process to systematically identify assets, threats, and
(potential) vulnerabilities in a system, and address three
fundamental questions:
What am I trying to protect?
What is threatening my system?
How much time, effort, and money am I willing to spend?

Should be a continuous process over the life cycle of a

system (design, implementation, testing, deployment,
update and termination)
Two basic types of risk analysis:
Quantitative and qualitative
S.S. Yau

CSE494/598, Fall 2005

Quantitative Risk Analysis

Attempts to establish and maintain an independent set
of risk metrics and statistics, including
Annualized loss expectancy (ALE): single loss expectancy
multiplied by annualized rate of occurrence.
Probability: chance, in a finite sample, that an event will occur
or that a specific loss value may be attained should the event
occur.
Control: risk-reducing measure that acts to detect, prevent, or
minimize loss associated with the occurrence of a specified
threat or category of threats.

S.S. Yau

CSE494/598, Fall 2005

Quantitative Risk Analysis (cont.)

Pros:

Objective, independent process

Solid bases for cost/benefit analysis
Credibility for audit, management
Useful for many kinds of reliability-related design questions
(e. g., redundant servers, etc.), where threats and likelihood of
events are easy to be measured

Cons:
Problems associated with unreliability and inaccuracy of data
Probability can rarely be precise and can, in some cases,
promote complacency
Very time consuming, costly to do correctly
S.S. Yau

CSE494/598, Fall 2005

Qualitative Risk Analysis

Most widely used approach to risk analysis
Probability data not required
Only estimated potential loss used

Establishing classes of loss values (impact)

Low, medium, high
Under $10K, between $10K and $1M, over $1M
Type of loss (e. g. compromise of credit card #, compromise
of SSN, compromise of highly personal data)

Establishing classes of likelihood of compromise

Low, medium, high

Focusing effort on high loss items

S.S. Yau

CSE494/598, Fall 2005

Qualitative Risk Analysis (cont.)

Pros:
Easy to understand and carry out
Not depend on possibly inaccurate data

Cons:
More subjective to person defining classes of
impacts and likelihood of compromise
Depends on history experience and expertise

S.S. Yau

CSE494/598, Fall 2005

Controls
Countermeasures for vulnerabilities
Deterrent controls reduce likelihood of a deliberate
attack
Preventative controls protect vulnerabilities and make
an attack unsuccessful or reduce its impact
Corrective controls reduce the effect of an attack
Detective controls discover attacks and trigger
preventative or corrective controls
Recovery controls restore lost computer resources or
capabilities to recover from security violations
S.S. Yau

CSE494/598, Fall 2005

10

Risk Management
Concerned with preventing risks from becoming problems
How you deal with risks identified in the risk analysis
Old philosophy: risk avoidance
Do whatever you can to avoid risks

New philosophy: risk management

Understand risks
Deal with them in an appropriate, cost effective manner

Choices for each risk

Risk acceptance: tolerate those risks with low impact or small occurremce
Risk reduction (also called risk mitigation)
Risk transfer (to another entity): let others handle the risk

Typically use a combination of acceptance, reduction, and transfer

for different risks

S.S. Yau

CSE494/598, Fall 2005

11

Examples
Choices for risk

Car theft risk

Risk acceptance

Deductibles on car
insurance

Risk reduction

Locks, alarms, GPS

locator

Risk transfer
S.S. Yau

Car insurance
covering theft
CSE494/598, Fall 2005

Hacker break-in
risk
Minimal security
(e. g., you just delete
all the spam emails
after you get them)
Strong security
mechanisms (firewall,
encryption, etc.)

Rely on ISP to
provide security
guarantees
12

Risk Management Process

Step 1: System characterization
Input: hardware, software, system interfaces, system mission, people, data
information
Output: system boundary, system functions, system and data criticality
and sensitivity

Step 2: Threat identification

Input: attack history, data from intelligence agencies or mass media
Output: threat statement

Step 3: Vulnerability identification

Input: prior risk assessment reports, audit comments, security
requirements, security test results
Output: list of potential vulnerabilities

Step 4: Control Analysis

Input: current controls, planned controls
Output: list of comparison of current and planned controls
S.S. Yau

CSE494/598, Fall 2005

13

Risk Management Process (cont.)

Step 5: Likelihood determination
Input: threat-source motivation, threat capacity, nature of
vulnerability, current controls
Output: likelihood rating

Step 6: Impact analysis

Input: mission impact analysis, asset criticality assessment,
data criticality and sensitivity
Output: impact rating

Step 7: Risk determination

Input: likelihood of threat exploitation, magnitude of impact,
adequacy of planned or current controls
Output: risks and associated risk levels
S.S. Yau

CSE494/598, Fall 2005

14

Risk Management Process (cont.)

Step 8: Control recommendations
Output: recommended controls

Step 9: Results documentations

Output: A set of documents including risk identification, assessment,
cost-effective evaluation, suggest control list, etc.
A well documented risk management process at one phase is a starting
point for the analysis at the next phase

Step 10: System monitoring:

Whether system configuration has changed: new hardware installed,
software updates, mission goal changed, etc.
Performance of the suggest controls: how many possible attacks have
been prevented by those controls; any failures or unwanted outcome, etc.

Restart the whole process from Step 1 again:

Periodically as part of the system maintenance procedure
When system configuration changed, it may generate some new risks not
been covered during the last risk management process
When some suggested control by the last run of process fail to prevent
the risk turn into attacks
S.S. Yau

CSE494/598, Fall 2005

15

Risk Management Process (Cont.)

Threat
Identification

System
Characterization

Vulnerability
Identification

Results
Documentation

Control
Recommendation

Control Analysis

Likelihood
Determination

S.S. Yau

System
Monitoring

Impact Analysis

CSE494/598, Fall 2005

Risk
Determination
16

Homework #2
Case study
Given a supermarket like Walmart with 10 to 20 POS
adjuncts, where each register has one POS adjunct
installed for credit card authorization.
Generate a risk management report for this scenario
following the risk management process we introduce
during the lecture
Due Monday, October 10 before class, submitted
through myASU digital dropbox

S.S. Yau

CSE494/598, Fall 2005

17

Background Information for Homework

A store already has a centralized facility (CFAC) database of its
own credit cards for authorization of charges
That CFAC also links to external credit card company facilities
to authorize charges on other cards
A new POS adjunct (POSA) at each register will obtain the sale
information from the register, scan the card, accept the PIN (for
debit cards), submit the information for authorization, display
the results (yes or no), and signal the register to complete the
transaction if it is approved
We assume that CFAC and the register are secure, except for
new interfaces added for POSA
Three parties are involved when you identify and analyze
possible risks:
Store
Customer
Credit card company
S.S. Yau

CSE494/598, Fall 2005

18

Functional Diagram for Homework

(4) Sale & user information
(8) Complete transaction

CFAC
(5) Yes/No

(1) Sale information

(7) Complete Trans.

Register

(6) Yes/No

POSA
(2) Display
Sale Info

(3) User CC
information

USER

S.S. Yau

CSE494/598, Fall 2005

19