1. Stephen S. Yau CSE465-591, Fall 2006 1 Risk Management

2. Stephen S. Yau CSE465-591, Fall 2006 2 What is a risk? Information System At Risk Threat (attacker) Vulnerability 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

3. Stephen S. Yau CSE465-591, Fall 2006 3 Threat Category Unauthorized access threats Information compromise threats Information corruption threats Denial of service threats Software corruption threats Hardware corruption threats Hardware/software distribution threats Network-based threats

4. Stephen S. Yau CSE465-591, Fall 2006 4 Vulnerability Category Probabilistic vulnerabilities –Caused by hardware failures, human actions and information problems in the operational environment Algorithmic vulnerabilities –Caused by design and implementation errors, which are introduced during system development [including both software and hardware]

5. Stephen S. Yau CSE465-591, Fall 2006 5 Identify Possible Risks What is at risk? –Product design documents –Customer information –Company’s 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 (access confidential data, change data, deface…) –Capabilities (intellect, equipment, money) What vulnerabilities can be exploited? –Technology –Process –Network –People

6. Stephen S. Yau CSE465-591, Fall 2006 6 Cost/Benefit Analysis After identifying possible risks, cost/benefit analysis needs to be performed for the following reasons:  Infeasible or sometimes impossible to implement a perfect secure systems  Cost/benefit analysis helps identify risks which will most likely occur, and which will cause severe damages if occur  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 cost/benefit analysis can help allocate limited system resources to most needed areas

7. Stephen S. Yau CSE465-591, Fall 2006 7 Risk Analysis A process to systematically identify assets, threats, and (potential) vulnerabilities in a system, and address the following: –What to be protected –What are threatening the system –Time, effort, and money willing to be spent 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

8. Stephen S. Yau CSE465-591, Fall 2006 8 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 occurs. –Control: risk-reducing measure that acts to detect, prevent, or minimize loss associated with occurrence of a specified threat or category of threats.

9. Stephen S. Yau CSE465-591, Fall 2006 9 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), where threats and likelihood of “events” can be easily measured

10. Stephen S. Yau CSE465-591, Fall 2006 10 Quantitative Risk Analysis (cont.) Cons: –Problems associated with unreliability and inaccuracy of data –Probability can rarely be precise and, in some cases, promote complacency –Very time consuming, and costly to do correctly

11. Stephen S. Yau CSE465-591, Fall 2006 11 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) –Insignificant, minor, moderate, major, catastrophic –Under $10K, between $10K and $100K, between $100K and $1M, between $1M and $50M, over $50M –Type of loss (e. g. compromise of credit card #, compromise of SSN, compromise of highly personal data)

12. Stephen S. Yau CSE465-591, Fall 2006 12 Qualitative Risk Analysis (cont.) Establishing classes of likelihood of compromise –Almost certain, likely, moderate, unlikely, rare Levels of risks –Extreme –High –Moderate –Low Focusing effort on high loss items

13. Stephen S. Yau CSE465-591, Fall 2006 13 Determine Risk Levels LikelihoodImpact InsignificantMinorModerateMajorCatastrophic Almost Certain HighHighExtremeExtremeExtreme LikelyModerateHighHighExtremeExtreme ModerateLowModerateHighExtremeExtreme UnlikelyLowLowModerateHighExtreme RareLowLowModerateHighExtreme

14. Stephen S. Yau CSE465-591, Fall 2006 14 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

15. Stephen S. Yau CSE465-591, Fall 2006 15 Controls Countermeasures for vulnerabilities –Deterrent controls reduce likelihood of 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 from security violations

16. Stephen S. Yau CSE465-591, Fall 2006 16 A Model of Risk Analysis Process ATTACK Threat Deterrent Control Detective Control Preventative Control Impact Vulnerability Corrective Control Reduce likelihood of Discovers TriggersProtects Reduces Results in Decreases Creates Exploits

17. Stephen S. Yau CSE465-591, Fall 2006 17 Risk Management Concerned with preventing risks from becoming problems How to 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

18. Stephen S. Yau CSE465-591, Fall 2006 18 Risk Management (cont.) Choices for each risk –Risk acceptance: tolerate those risks with low impact or rare occurrence –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

19. Stephen S. Yau CSE465-591, Fall 2006 19 Examples Choices for risk Car theft risk Hacker break-in risk Risk acceptance Deductibles on car insurance Minimal security (delete all the spam emails) Risk reduction Locks, alarms, GPS locator Strong security mechanisms (firewall, encryption, etc.) Risk transfer Car insurance covering theft Rely on Internet Service Provider (ISP) to provide security guarantees

20. Stephen S. Yau CSE465-591, Fall 2006 20 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

21. Stephen S. Yau CSE465-591, Fall 2006 21 Risk Management Process (cont.) 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: evaluation results of current and planned controls

22. Stephen S. Yau CSE465-591, Fall 2006 22 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

23. Stephen S. Yau CSE465-591, Fall 2006 23 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, suggested control list, etc. –A well documented risk management process at one phase, which is also the starting point for the analysis at the next phase

24. Stephen S. Yau CSE465-591, Fall 2006 24 Risk Management Process (cont.) Step 10: System monitoring: –Whether system configuration has changed: new hardware installed, software updates, mission goal changed, etc. –Performance of controls: how many possible attacks have been prevented by controls; any failures or unwanted outcome, etc. Restart the whole process from Step 1 again: –Periodically as part of system maintenance procedure –When system configuration changed, it may generate some new risks not been covered during the last risk management process –When some controls fail to prevent the risk from turning into attacks

25. Stephen S. Yau CSE465-591, Fall 2006 25 Risk Management Process (Cont.) 1. System Characterization 2. Threat Identification 4. Control Analysis 8. Control Recommendation 6. Impact Analysis 3. Vulnerability Identification 9. Results Documentation 10. System Monitoring 7. Risk Determination 5. Likelihood Determination

26. Stephen S. Yau CSE465-591, Fall 2006 26 Reference M. Merkow, J. Breithaupt, Information Security: Principles and Practices, Prentice Hall, August 2005, 448 pages, ISBN 0131547291 J. G. Boyce, D. W. Jennings, Information Assurance: Managing Organizational IT Security Risks. Butterworth Heineman, 2002, ISBN 0-7506-7327-3 Risk Management Guide for Information Technology Systems, July 2002. Available at: http://csrc.nist.gov/publications/nistpubs/800- 30/sp800-30.pdf http://csrc.nist.gov/publications/nistpubs/800- 30/sp800-30.pdf