40
QuickTime™ and a TIFF (Uncompressed) decompressor are needed Information System Security Engineering and Management INFORMATION SECURITY RISK MANAGEMENT Dr. William Hery [email protected]

Information System Security Engineering and Management INFORMATION SECURITY RISK MANAGEMENT Dr. William Hery [email protected]

Embed Size (px)

Citation preview

QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.Information System Security Engineering and Management

INFORMATION SECURITYRISK MANAGEMENT

Dr. William [email protected]

QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.

Risk Concept

Information AssetAt Risk Threat (attacker)

Vulnerability

Risk analysis starts with understanding what assets are potentially at risk, what the threats are, and what are the vulnerabilities that could be exploited. This forms the basis for finding the “sweet spot” of putting in enough security for to protect the value of the assets.

QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.Three Elements That Determine Risk

• What is at risk (national security, lives, property, money, image)? Some risk models are based on $ values

• What is the threat and 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 Technology Process People

QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.

Risk Analysis

• Risk analysis is a process to systematically identify the assets, threats, and (potential) vulnerabilities in a system

• A risk is a combination of an asset, a threat, and a (potential) vulnerability An “event” (“bad thing” in some papers) is when a

threat uses a vulnerability to compromise an asset. Determining the likelihood of an event is a key part of

the risk analysis

• Note that the terminology used is not standardized, so you may see some of these terms used with slightly different meanings

QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.Risk Analysis as a Continuous Process

• Risk analysis is a continuous process over the life of a system:

• In the early design phases, it is an input to basic system design decisions (e. g., wired vs. wireless links) to address potential vulnerabilities

• In the detailed design phases, it is an input to technology and security design (e. g., whether to use encryption on a WiFi link)

• When a system is deployed, risk analysis should continue to identify new threats, vulnerabilities, and assets

• When a system is being updated/upgraded/modified, risk analysis is an input

• A well documented risk analysis at one phase is a starting point for the analysis at the next phase

QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.

Risk Management

• Risk Management is how you deal with the risk identified in the risk analysis.

• Old philosophy: risk avoidance Do whatever you can to avoid risk

• New philosophy: risk management Understand the risks Deal with them in an appropriate, cost effective manner

• Risk management choices for each risk Risk acceptance Risk reduction (also called risk mitigation) Risk transfer (to another entity)

QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.

Risk Management Overview

• The default risk management approach is to accept the risk. If you choose this, make sure you do it knowingly!

• A typical approach is to use a combination of acceptance, reduction, and transfer for different risks

• Overall system design, security technology, and methodology are used to reduce risk. These are called controls, safeguards, countermeasures, etc. Risk analysis is a key input to the system design process A preliminary risk analysis is a starting point for security

requirements A detailed risk analysis is based on the system design

QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.Risk Management Decision Overview

• The decision about which approach and control to use for each risk is based on a cost benefit analysis of the cost of the control versus the expected/potential loss if the “event” occurs. This is part of the systems engineering process (next lecture).

• The cost of a control includes development, procurement and life cycle management costs

QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.Examples of Approaches to Risk Management

Approach to RiskManagement

Home owner theftrisk

IT example

Eliminate/ReduceRisk

Locks on doors, alarmsystem

Strong security, e. g.,firewalls, crypto, etc.

Transfer Homeownersinsurance

Insurance;Network Service Providerwith security guarantees

Accept Deductible oninsurance

Minimal security (e. g., aninformational web siteaccepting risk ofdefacement)

QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.Risk Management and Dependable Systems

• The risk analysis and risk management approaches described here also apply to the design and development of dependable systems.

• The primary difference is that threats are external events, not intentional acts: Hardware failures Software failures Acts of nature (storms knocking out power lines, floods,

etc.)

• Much of the early work in risk analysis for systems was done for control systems on nuclear reactors

QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.

Example System

• The following simple example will be used to illustrate the key principals in this course

• Our analysis will be incomplete, even for a simple system

• The kind of analysis of this simplified example “system” here and in future lectures will be ones that you will be doing on your term projects

• This example is much simpler than what your project systems will be

QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.

Example System: POS Credit Card Authorization Adjunct

(simplified)

• Background assumptions: A store already has a centralized facility (CFAC) database of

its own credit cards used for authorization of charges That central facility also links to external credit card company

facilities to authorize charges on other cards A new POS adjunct (POSA) at each register will get 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

• The “system” we will use as an example is the set of POSA terminals, the networks connecting them to the CFAC and registers, and the interfaces.

QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.

POSA Functional Diagram

POSA

CFAC

USER

1 Sale information7 Complete Trans.

Register

5 Y/N

4 Sale & user information8 Complete transaction

3 User CCinformation

6 Y/N 2 DisplaySale Info

QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.

Functional Diagrams

• The functional diagram shows only the major functional elements of the system and the information flow paths among them.

• This sample only show the specific information flows for a completed transaction. A full system diagram would show all the flows for all

possibilities…that is a later step in the process

• The system functional diagram is a basic step in the systems engineering process.

• Technologies to be used are not part of this yet--they will be added in the system design process

QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.

Risk Analysis Step I: Identify Assets

• Identify and inventory assets at risk, such as Human safety, lives Items with dollar values that can be readily established (e. g.,

the value of an account that might be drained; equipment that can be damaged through a security breach)

Intellectual property (estimate value?) Corporate or personal reputation (how do you value that?) Other intangibles (e. g., family photos stored only on your

laptop)

• Prioritize the list of assets so you can focus on the most valuable things

QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.Time Value of Assets

• The value of an asset may vary over time in different ways, and this will impact the way a threat acts and the kinds of protection needed. Here are a few examples

• Stolen credit card numbers only have value until the theft is reported. Therefore an attacker who wants to steal credit card numbers will not want the theft detected. One possible safeguard from the credit card company’s perspective would be something that detects unauthorized access to card numbers and automatically cancels the accounts.

• A signing key for legal documents may have to be protected for a very long time, depending on the kinds of documents it protects: even if a compromise is known, it may be possible to forge back dated documents that are signed. (Note that if an independent signed time stamping service is also used, this is not possible.)

QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.Time Value for Military Secrets

• Some military secrets need only be protected for a short time--the fact that an attack is about to occur in an hour probably means you only need to be able to protect it for an hour: a PDA with only that info that is compromised after the attack begins is not a problem, nor is an encryption key that cannot be broken in an hour. (Example: D-Day)

• Some intelligence secrets (“sources and methods”) need to be kept secret for many years. If an encrypted message is broadcast and picked up by the enemy, you need to protect against any key breaking capability they might have in the future (Example: Venona)

QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.

POSA Assets at Risk

• Who has assets at risk? The store The credit card holders The credit card companies But the store controls the design--why

worry about other assets?

QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.

Store Assets at Risk

• Value of purchase (for incorrect approval)• Loss of purchase profit (for incorrect

denial, POSA unavailability)• Loss of customer good will (for incorrect

denial, unavailability)• Store ability to process sales (if CFAC is

taken down by an attack through POSA)• Corporate reputation (for repeated

problems, publicized problems)• …

QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.Credit Card Holder Assets at Risk

• Credit card number/pin Time, ability to purchase (for incorrect denial,

unavailability due to cancelled card) $50 (for incorrect approval on a lost/stolen card) $50 (for use of a credit card number stolen through the

system) Time cost to correct problem & possible temporary loss

of credit (for use of a credit card number stolen through the system)

Temporary use of checking account (for use of a debit card number/pin stolen through the system)

• …

QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.Credit Card Company Assets at Risk

• Credit card number/pin Amount of purchase (for incorrect

approval) Credit limit of a card (for a credit card

number stolen through the system)

• …

QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.Risk Analysis Step II: Identify the Threats

• Who?• What is the motivation, and what are they after?• What are their capabilities?• Develop a “threat tree”

Work back from each asset though the source of a threat, building a tree of paths to the asset

This is really more of a “potential vulnerability” tree, but can be useful in deciding what kind of capabilities a threat would need to attack your asset

• Prioritize threats: Is the NSA really interested in your credit card number?

QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.

Who is a threat?

• The types of assets you have will help identify the kinds of threats you have Classified information: threats from foreign nations, terrorists, media

(?) Pure financial assets: threats from thieves, including insiders,

customers, and thieves outside the system Intellectual property: threats from people who can use the

information: competitors, foreign nations, potential customers (illegal music, movie copying)

A running business: threats from competitors (DoD attack), hackers/thrill seekers (DoS attack), disgruntled customers

Reputation: threats from hackers/thrill seekers, political opponents, social opponents (e. g., eco-cyber hackers)

Computing/networking resources: threats from people storing large files (movies), using your PC to attack others (trojans for DDoS, SPAM), using your networks to attack others to avoid traceback

QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.

Capabilities of Threats

• In order to select the right level of protection, you should understand the capabilities of the threats Intellectual capabilities

Skilled hackers “Script kiddies” Foreign government agencies

Computing resources (particularly for key breaking)

Access to systems (insiders)

QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.Dated Example of Capabilities Analysis

Time per KeyRecovered

Key Length (bits)

Type ofAttack

Budget Tool

40 56

Key Length Needed forProtection inLate 1995

(bits)

Tiny ScavengedComputerTime

1 week infeasible 45PedestrianHacker

$400 FPGA 5 hours 38 years 50

SmallBusiness $10,000 FPGA 12 min. 18 mon. 55

CorporateDepartment

$300K FPGA

ASIC

24 sec

.18 sec

19 days

3 hours

60

BigCompany

$10M FPGA

ASIC

.7 sec

.005 sec

13 hours

6 min70

IntelligenceAgency

$300M ASIC .0002sec

12 sec 75

Source: M. Blaze, W. Diffie, R. Rivest, B. Schneier, T. Shimomura, E.Thompson, and M.Weiner, “Minmal Key Length for Symmetric Ciphers toProvide Adequate Commercial Security,” January 1996,http://www.counterpane.com/keylength.html

Note: the data here is very dated (1996), but

the approach is still used

QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.

Example POSA Threat Analysis

• Who? Customers with fraudulent credit cards

Store cards Generic cards (MC, Visa, AMEX, etc.)

Insiders (clerks, programmers, sysadmins, people with access to the store…)

Malicious “customers” Hackers (are there any Internet links?)

QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.Example POSA Threat Analysis (Continued)

• What might they attack• Customers: present fraudulent card• Insiders

sniff CC numbers/PINs from networks Shoulder surf PIN numbers Inject false traffic into networks (approve fraudulent credit card

purchase for friend) Programs/configurations of system Denial of Service attack on POSA or CFAC …

• Hackers sniff CC numbers/PINs from networks Inject false traffic into networks (e. g. approve fraudulent credit card

for friend) Programs/configurations of system Denial of Service attack on POSA or CFAC

QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.Risk Analysis Step III: Identify the vulnerabilities

• What parts of the overall system might be attacked? Networks, processors, people (“social

engineering”)• Vulnerabilities will be system design dependent

Initially, identify the areas where vulnerabilities may be present

As the system design develops, specific vulnerabilities can be assessed

Risk assessment should be used to influence design in the system design process

QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.

Example POSA Vulnerable Areas

• Network System design dependent (wireless, dedicated wired

net, over corporate intranet, over Internet, etc.) Risk assessment should be used to influence design

• POSA terminal• POSA/register link• Register clerks (social engineering: can they be

talked into overriding a “no”, accepting false signature, etc.)

QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.Risk Analysis Step IV: Risk Management Approach

• Quantitative (objective) and Qualitative (subjective) approaches both used.

• Quantitative approach: Compute expected value of loss for all

“events” Compute the probability of each type of

expected loss Compute the overall expected Annual Loss

Expectancy (ALE) For each security measure compare the cost

of implementation to the reduction of ALE; if the cost is lower, implement the measure

QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.

Quantitative Approach

• Pro: Objective, independent process Solid basic for cost/benefit analysis of safeguards Credibility for audit, management This type of approach is useful for many kinds of

reliability related design questions (e. g., redundant servers, etc.), where threats and likelihood of “events” are easier to measure

• Con In most cases, it is difficult to enumerate all types of

events and get meaningful data on probability and cost Very time consuming, costly to do right Many unknowns may give a false sense of control

QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.

Quantitative Approach

• There are several systems that are available to automate a quantitative risk assessment

• One very useful one is OCTAVE® (Operationally Critical Threat,

Asset, and Vulnerability Evaluation) From CERT at CMU:

www.cert.org/octave They sell books, training, etc. Online documentation is available Sample level of effort: OCTAVE-S, for

organizations of ~100 people, uses a team of 3-5 for the analysis

QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.Qualitative Risk Management Approach

• Establish 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) Minor injury, significant injuries, loss of life, large scale

loss of life

• Establish classes of likelihood of compromise Low, medium, high

• Decide on a risk management approach to each combination of (class of loss, likelihood of loss)

• Focus effort on high loss items

QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.

Example of Qualitative Approach: PA e-Government Commerce

Standard

• Published standard used for all e-government systems

• Includes both risk analysis and policy (next section of this course)

• Loss if an “event” occurs (“Impact”): Low, Medium, High

• Likelihood of an “event” (they call it “Risk”): Low, Medium, High

• Risk assessment/policy is defined for all 9 combinations.

QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.PA e-Government Commerce “Impact” Categories

• Low-Impact:  If an unauthorized individual views this information [this type of information was compromised], the consequences to the Commonwealth would be minimal. Information in this category may already be accessible to the public, or it may be confidential, but not very harmful if released. Generally, this includes information that would result in financial harm of less than $50, would cause no major legal problems, and would not be of much interest to the press or the general public. Illustration: A hacker intercepts someone's telephone number.

• Medium-Impact:  If an unauthorized individual views this information [was compromised], the consequences to the Commonwealth could be significant. Information in this category is generally not accessible to the general public, and may cause harm to the protected individual if released. Generally, improper release of information in this category could cause financial harm of $50 to $10,000, would likely be noticed by the press, and could cause legal problems for the Commonwealth. Illustration: Someone's credit card information is compromised.

• High-Impact:  If an unauthorized individual views this information [if this category was compromised], the consequences to the Commonwealth would be extremely serious. This category includes information of a highly confidential nature that could cause significant hardship or embarrassment to the protected individual if improperly released. The compromise of information in this category could result in serious financial harm (greater than $10,000), considerable legal problems for the Commonwealth, and would significantly erode public trust in the integrity and security of information collected/managed by state agencies. Illustration: Someone's record of psychiatric treatment is made public, or a hacker downloads thousands of social security credit card numbers.

QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.PA e-Government Commerce “Risk” categories (likelihood of event)

• Low Risk.   Information in this category is of little interest/use to potential hackers, and even if an unauthorized individual viewed the information [the information were viewed by an unauthorized party], it would be of very little value. Illustration: Although John Doe may not want his age to be disclosed, few people would be interested in the age of a single individual.

• Medium Risk.  Information in this category may have value to hackers and could be a target for a privacy violation. Illustration: Intercepting someone's credit card information.

• High Risk:  Information could be extremely valuable to hackers. Illustration: Intercepting thousands of credit card numbers.

QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.PA e-Government Commerce Risk Analysis and Policy

• Level A: No special steps• Level B: Use 128 bit SSL• Level C: Work with state Office of Information Technology to define security approach

This is not an endorsement of this policy!

QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.Example POSA Risk Management Approaches

Customers with fraudulent credit cards Store cards

• Assume CFAC screens properly (risk transfer)• Assume clerks verify signature (risk acceptance)

Generic cards (MC, Visa, AMEX, etc.)• Generic card company screens properly (risk transfer)• Assume clerks verify signature (risk acceptance)

Insiders (clerks, programmers, sysadmins, people with access to the store…) Trust programmers, sysadmins (risk acceptance) Protect networks from sniffing (risk reduction)

• How to do this is a system design issue Protect POSA system from false injection of information

Hackers (are there any Internet links?) Do not allow POSA links to Internet (risk avoidance)

QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.

NIST Risk Process

QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.

NIST Risk Process (Continued)