1. 1 Information Security Compliance System Owner Training Module 3 Risk Analysis and Security Plan Richard Gadsden Information Security Office Office of the CIO – Information Services +1-843-792-8307 gadsden@musc.edu

2. 2 Overview ➲ Quick Review ● Information Security Fundamentals ● MUSC Policies and Compliance Process ➲ Risk Analysis Concepts ➲ Risk Analysis Worksheet ● Compliance issues ● Other information security risk issues ➲ Security Plan Summary

3. 3 Information Security Process ➲ Security is a process... ● Not a product ● Not “set it and forget it” ➲ Goal: protection of information assets from threats to their... ● Availability ● Integrity ● Confidentiality

4. 4 Information Security: A Risk Management Process ➲ Risk management process ● the process for making security decisions ● caveat: zero risk is not attainable ➲ Steps in the process ● identify significant risks ● evaluate possible controls (safeguards) ● implement the most cost-effective set of controls that will keep risks within acceptable levels ● evaluate the results and repeat

5. 5 Unacceptable Risk vs. Unnecessary Cost

6. 6 Reasonable and Appropriate? ➲ How to achieve? ● The risk management process ● Assessment of risk ● Evaluation and selection of controls ● Approval, funding, implementation, operation ➲ How to verify? ● The compliance process ● Documentation ● Audits and other reviews

7. 7 Risk Management Team ➲ System Owner ➲ System Administrator ● other key members of IS support team ➲ Risk Assessment Team ● knowledge of the system (functional & technical) ● ability to analyze and select controls ● communicate findings with management ➲ Management ● unacceptable risk vs. unnecessary cost

8. 8 Information Assurance (Compliance Process) ➲ Document level of assurance ● Are all security responsibilities clearly defined and understood? ● Is a sound (risk-based and cost-conscious) decision-making process being followed? ● Are security procedures documented? ● Are procedures being followed? ● Are controls working as intended?

9. 9 Compliance Process ➲ Existing Systems: 6-step Process 1.Review policies, standards, guidelines 2.Document current system environment 3.Document current procedures & other controls 4.Identify & analyze potential issues 5.Develop security plan 6.Execute security plan ➲ Repeat process when conditions warrant ➲ New Systems: see Guidelines

10. 1010 Step 1.0: Review MUSC Policies, Standards and Guidelines ➲ URL: http://www.musc.edu/securityhttp://www.musc.edu/security ➲ Policies ● high-level principles, goals, responsibilities ➲ Standards ● performance standards (min. requirements) ➲ Guidelines ● “how to” ● recommended approaches

11. 1 Step 2.0: Document Current System Environment and Personnel ➲ Deliverable: Security Documentation, Section 2 (System Identification) ● System Name ● Key System Personnel ● Functional Description ● Key Components ● System Boundaries ● Relationships with other systems ● interfaces, dependencies

12. 1212 Step 3.0: Document Current System-Specific Security Procedures and Other Controls ➲ Deliverable: Security Documentation, Section 3 (Current System Procedures) ➲ Use the MUSC Information Security Policy Compliance Checklist for System Owners as a guide ➲ http://www.musc.edu/security/tools http://www.musc.edu/security/tools

13. 1313 Step 4.0: Identify and Analyze Potential Issues ➲ Deliverable: Risk Analysis Worksheet ➲ http://www.musc.edu/security/tools http://www.musc.edu/security/tools ➲ Priorities ● Address policy compliance gaps ● Identify using the Policy Compliance Checklist ● Address any other security issues (risks) ● Identified from first principles (threats, vulnerabilities)

14. 1414 Step 5.0: Develop Security Plan ➲ Deliverable: Security Plan Summary ➲ http://www.musc.edu/security/tools http://www.musc.edu/security/tools ➲ Document your plan for addressing all of your System's security compliance gaps ➲ Don't develop your security plan in isolation ● coordinate solutions with OCIO ● consult published guidelines ● contact ISO if additional guidance needed

15. 1515 Step 6.0: Execute Security Plan ➲ Deliverables ● Document changes made to system procedures and other controls (Section 3, Current System Procedures) ● Maintain a history (log) of all changes ● Progress and status reports as required by your Entity's Information Assurance Compliance Officer (IACO)

16. 1616 Risk Analysis Concepts ➲ Defining Risk ● Threats ● Vulnerabilities ➲ Measuring Risk ● Likelihood ● Impact ➲ Managing Risk ● Security Controls (Safeguards)

17. 1717 Risk ➲ Information Security Risk ● Can arise from any issue or potential event that would threaten the availability, integrity or confidentiality of information ➲ Risks are a function of: ● Threats & Vulnerabilities => type of risk ● Likelihood & Impact => magnitude of risk

18. 1818 Threats ➲ Potential for a threat-source to intentionally exploit or accidentally trigger a vulnerability ➲ Threat-sources ● People ● Accidental actions ● Deliberate actions ● System (technology) problems ● Other (environmental) problems

19. 1919 Threat Sources: People ➲ activists ➲ consultants ➲ crackers/hackers ➲ customers ➲ deranged people ➲ extortionists ➲ hoodlums ➲ insiders ➲ maintenance people ➲ organized crime ➲ private investigators ➲ professional thieves ➲ terrorists ➲ vandals

20. 2020 Threat Sources: System (technology) problems ➲ Hardware failures ➲ Software failures ➲ Failures of related systems ➲ Malicious code

21. 2121 Threat Sources: Other (environmental) problems ➲ Power outages ➲ Natural disasters ➲ Building environment control problems ➲ Water damage from man-made sources

22. 2 Vulnerabilities ➲ Def: A weakness or a flaw ➲ Categories ● Technical ● Human resource ● Physical and environmental ● Operational ● Business continuity and compliance

23. 2323 Technical Vulnerabilities ➲ Flaws in ● Design ● Implementation ● Configuration ➲ Of: ● Hardware ● Software

24. 2424 Human Resource Vulnerabilities ➲ Key person dependency ➲ Gaps in pre-employment screening ➲ Gaps in awareness and training ➲ Gaps in discipline ➲ Improper termination of access

25. 2525 Physical and Environmental ➲ Insufficient physical access controls ➲ Poor siting of equipment ➲ Inadequate temp/humidity controls ➲ Inadequate power conditioning

26. 2626 Operational Vulnerabilities ➲ Inadequate separation of duties ➲ Lack of control over: ● installation of hardware, software (new, changed) ● system communication ● access control, and supporting procedures ➲ Inadequate recording, review of activity ➲ Inadequate handling of incidents ➲ Inadequate monitoring of control effectiveness

27. 2727 Business continuity and compliance ➲ Inadequate, inappropriate management of business risks ➲ Inadequate business continuity planning ➲ Inadequate monitoring for compliance with governing policies and regulations

28. 2828 Risk Issue (Security Breach) ➲ Threat-Vulnerability Pairs define Risks ● Type of risk := Type of potential security breach ➲ Both threat and vulnerability are required for a breach to occur. ➲ To manage the risk posed by the potential breach, we have to recognize and understand both the threat and the vulnerability. ➲ Security Issue = Threat + Vulnerability

29. 2929 Security Issue: Example 1 ➲ Potential breach: ● An intruder gains control of the system by exploiting an operating system vulnerability. ● Threat: Intruders. ● Vulnerability: Flaw in the design, implementation, and/or configuration of the operating system software. This has both a technical aspect (the flaw itself), and an operational / compliance aspect. (Why wasn't the flaw corrected or patched?)

30. 3030 Security Issue: Example 3 ➲ Potential breach: ● A laptop or PDA or thumb drive containing sensitive system information is stolen from a faculty member's car, and the sensitive data was not encrypted. ● Threat: Thieves. ● Vulnerability: Inadequate access control procedures (the device should not have been left in a car, and the data stored on the device should have been encrypted).

31. 3131 Security Issue: Example 3 ➲ Potential breach: ● A disgruntled employee who believes he was wrongly terminated is able to sabotage the system because his access to his account was not promptly disabled. ● Threat: Insider (saboteur). ● Vulnerability: Improper termination of access.

32. 3232 Security Issue: Example 4 ➲ Potential breach: ● A critical system is down for an extended period due to equipment damage caused by a natural disaster such as an earthquake or severe hurricane. ● Threat: Natural disaster. ● Vulnerability: Inadequate business continuity / contingency planning.

33. 3 Likelihood ➲ Recall: ● Threat & Vulnerability => Type of breach ● Likelihood & Impact => Magnitude of the risk ➲ Likelihood of a breach ● Expected frequency of occurrence ➲ Frequency of security breaches can be: ● Hard to measure (accurately, objectively) ● Hard to predict (with any confidence)

34. 3434 Estimating Likelihood ➲ Sources of information: ● Historical frequency (e.g., natural disasters) ● Reported frequency (e.g. attacks, incidents) ● Public sources ● industry surveys (e.g. FBI Cybercrime Survey) ● news reports (major incidents that are disclosed) ● Problems? ● public sources are not statistically useful ● complete & accurate incident data is not public

35. 3535 Likelihood, Qualitatively ➲ Assessment approaches ● Quantitative ● Qualitative ➲ Recommended qualitative scale for assessing likelihood (frequency): ● Low: < 1 time per year ● High: 12+ times per year ● Moderate: anything in between

36. 3636 Impact: Effects on Confidentiality, Integrity, Availability ➲ A security breach can involve: ● Disclosure or unauthorized viewing of confidential information ● Unauthorized modification of sensitive information ● Loss or destruction of important information ● Interruption in availability or service ➲ Actual impact of these effects?

37. 3737 Impact on MUSC, Individuals ➲ A security breach can affect: ● Life, health, well-being of ● MUSC student(s) ● MUSC patient(s) ● MUSC customer(s)/stakeholder(s) ● MUSC faculty and/or employee(s) ● Damage to MUSC's reputation ● Interference with MUSC's ability to function ● Criminal/civil penalties, fines, damages, settlements, and other legal costs

38. 3838 Impact: Quantitative vs. Qualitative ➲ Quantitative ● The estimated overall impact of a potential breach is the total expected cost of all of these potential effects ➲ Qualitative ● The rated impact of a potential breach is the high-water mark of its potential effects across all of these areas (individuals, operations, assets)

39. 3939 Impact of a Breach: FIPS 199 ➲ FIPS 199 ● Qualitative approach to assessing impact ● Low = “limited” adverse effects ● Moderate = “serious” adverse effects ● High = “catastrophic” adverse effects ● Must consider effects on: ● Individuals ● MUSC operations ● MUSC assets

40. 4040 Risk Level (Magnitude) ➲ Risk = Likelihood x Impact ➲ Quantitative ● Annualized Loss Expectancy (ALE) ➲ Qualitative ● Scale: Low, Moderate, High ● “Multiply” Likelihood and Impact Ratings

41. 4141 Risk Analysis: Example ➲ Security Issue (potential security breach) ● Laptop containing unencrypted sensitive patient information is stolen. ● Threat: Laptop thieves. ● Vulnerability: Inadequate access control. ➲ Likelihood ● Ask Public Safety if they have any data. ● Assume about 10 MUSC laptops / year stolen. ● Likelihood Rating = Moderate.

42. 4242 Risk Analysis Example (cont'd) ➲ Impact ● On individuals? ● Let's assume not life-threatening, but still “serious”. ● On MUSC assets? ● How much reputation damage? How much civil liability? How much loss of revenue? Let's assume the worst of the effects on assets is “serious”. ● On MUSC operations? ● Was the data critical? Was it backed up? Let's assume the overall effect on operations is “limited”.

43. 4343 Risk Analysis Example (cont'd) ➲ High-water mark across effects: “serious” ➲ Impact Rating = Moderate. ➲ Risk ● Risk = Likelihood x Impact ● Moderate x Moderate = Moderate ➲ Risk Rating = Moderate.

44. 4 Security Controls ➲ Three basic control strategies: ● Prevention ● Detection ● Recovery

45. 4545 Selecting Controls ➲ Selecting controls requires a broad range of knowledge, skills, experience ● Technical ● Operational ● Management / Organizational ➲ Risk assessment team should discuss options ➲ Cost-benefit analysis may be needed to help the team make rational selections

46. 4646 Evaluating Controls - Principles ➲ Think prevention first. ➲ Detection is required for recovery. ➲ Timeliness matters. ➲ Integration of controls is essential. ➲ Defense in depth is highly desirable.

47. 4747 Integration Principle ➲ Your System's internal controls should complement each other ➲ Same applies, across the MUSC enterprise ➲ Don't choose your controls in isolation ➲ Do: ● coordinate your security plan with MUSC OCIO ● consult published MUSC guidelines ● leverage known (or planned) enterprise solutions ● contact ISO if additional guidance needed

48. 4848 Re-cap: Risk Management Process ➲ Steps in the process ● Identify significant risks (issues) ● Evaluate possible controls (safeguards) ● Select the most cost-effective set of controls that will keep risks within acceptable levels ● Develop a plan to implement the controls ● Execute the plan (implement the controls) ● Evaluate the results and repeat

49. 4949 Special Case: Compliance Issues ➲ Two distinct types of security issues ● Potential security breaches ● From first principles ● Due to reasonably anticipated threats, combined with known or suspected vulnerabilities ● Control priority: depends on risk (likelihood x impact) ● Compliance issues ● Gaps in current procedures / other controls, with respect to policy and/or regulatory requirements ● Control priority?

50. 5050 Risk Analysis Worksheet ➲ Use to document both types of issues ● Potential breaches (threat-vulnerability pairs) ● Compliance issues ➲ Goal is the same for both types ● Evaluate corrective / protective controls ● Select and prioritize controls ➲ Compliance issues are logical starting point ● Risk Level := High

51. 5151 Risk Analysis Worksheet: Recommended Approach ➲ First: ● Document all compliance issues ● Taken straight from your Policy Compliance Checklist ● Evaluate controls (preliminary) ➲ Next: ● Document other risk issues (T-V Pairs) ● Assess Likelihood, Impact, Risk Level for each ➲ Finally: ● Evaluate and select recommended controls

52. 5252 Risk Analysis Worksheet: Columns ➲ Security Issue ● T-V Pair, or Compliance Issue ➲ Likelihood* ➲ Impact* ➲ Risk Level ➲ Recommended Security Control(s) ➲ Control Priorit(ies) * Compliance Issues: leave these two columns blank, and assign a “High” risk level to these issues.

53. 5353 Compliance Checklist Issues ➲ Assume you have a score < 3 for one or more compliance checklist requirements. ➲ These are compliance issue ● The first type of Security Issue you should analyze, using your Risk Analysis Worksheet ➲ See supplementary material: Analysis of Policy Compliance Checklist Issues

54. 5454 Other Security Issues? ➲ Will the security controls recommended by your risk assessment team, just to address the “obvious” compliance issues, be sufficient to protect against all reasonably anticipated threats? ➲ If you haven't tried to anticipate threats, and you haven't assessed vulnerabilities, how can you answer that question?

55. 5 Identifying Other Security Issues ➲ Review system diagrams ● Entry points are where the action is ➲ Walk through operational procedures ➲ Review management practices ➲ Review physical security, environment ➲ Assess technical vulnerabilities ● Automated tools a starting point ➲ ISO can help with vulnerability assessments

56. 5656 Risk Analysis Worksheet: Wrap-Up ➲ Has your Risk Assessment Team... ● Documented all compliance issues and the recommended controls? ● Documented any other known risk issues and the recommended controls? ● Involved the right people in evaluating and selecting the recommended controls? ● Reviewed the recommendations with the appropriate management?

57. 5757 Security Plan Summary ➲ Use this spreadsheet to help document and communicate your plan. ➲ Document who will implement each of the security controls recommended in your risk analysis worksheet, and when, and what the on-going requirements will be. ➲ Depending on the size and scope of your security plan, you may need to develop and maintain a more detailed project plan.

58. 5858 Security Plan Summary: Columns ➲ Security Control (from the Risk Analysis Worksheet) ➲ Implementation Priority (also from the Risk Analysis Worksheet) ➲ Responsible Party ➲ Start Date ➲ End Date ➲ Operational or Maintenance Requirements

59. 5959 Security Plan Summary ➲ Review your System's security plan with appropriate level(s) of management, at appropriate stage(s) in its development. ➲ Ensure appropriate involvement: ● OCIO ● anyone affected by the plan ● anyone expected to be involved in its implementation

60. 6060 Executing the Plan ➲ Security Plan Summary ● Use it as a living document ● Revise it when (not if!) security plan changes ● As the plan's implementation proceeds, update your System's security documentation ● Maintain history of all changes

61. 6161 More Information ➲ MUSC Information Security Guidelines: Risk Management ● http://www.musc.edu/security/guidelines http://www.musc.edu/security/guidelines ➲ NIST Computer Security Resource Center ● http://csrc.nist.gov http://csrc.nist.gov

62. 6262 Compliance Documentation ➲ System Identification ● Document System & its management team ➲ Current Procedures & Other Controls ● Document System's current safeguards ➲ Security Plan Summary ● Document System's planned safeguards ➲ Risk Analysis Worksheet ● Document why your System's specific safeguards have been selected

63. 6363 Are We Done Yet? ➲ Security is never finished ➲ Repeat the risk management cycle as warranted by conditions ● respond to environmental, operational, policy, and/or regulatory changes ➲ Evaluate the effectiveness of your System's security measures ● until your System is retired ➲ Set it and forget it? Not an option!