2. Information System Security Engineering and Management INFORMATION SECURITY RISK MANAGEMENT Dr. William Hery hery@isis.poly.edu

3. Risk Concept Information Asset At 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.

4. 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

5. 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

6. 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

7. 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)

8. 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

9. Rick 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

10. Examples of Approaches to Risk Management

11. 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

12. 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

13. 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.

14. POSA Functional Diagram POSA CFAC USER 1 Sale information 7 Complete Trans. Register 5 Y/N 4 Sale & user information 8 Complete transaction 3 User CC information 6 Y/N 2 Display Sale Info

15. 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

16. 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

17. 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.)

18. 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)

19. 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?

20. 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) …

21. 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) …

22. 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) …

23. 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?

24. 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

25. 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)

26. Dated Example of Capabilities Analysis Note: the data here is very dated (1996), but the approach is still used

27. 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?)

28. 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

29. 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

30. 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.)

31. 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

32. 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

33. 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 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

34. 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

35. 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.

36. 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.

37. 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.

38. 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!

39. 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)

40. NIST Risk Process

41. NIST Risk Process (Continued)