Information Security Compliance System Owner Training Module 3

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

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 2

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 3

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 4

Unacceptable Risk vs. Unnecessary Cost 5

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 6

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

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

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

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

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 1 1

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 ➲ 1 2

Step 4. 0: Identify and Analyze Potential Issues Deliverable: Risk Analysis Worksheet ➲ 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) 1 3

Step 5. 0: Develop Security Plan Deliverable: Security Plan Summary ➲ 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 1 4

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) 1 5

Risk Analysis Concepts ➲ Defining Risk ● ● ➲ Measuring Risk ● ● ➲ Threats Vulnerabilities Likelihood Impact Managing Risk ● Security Controls (Safeguards) 1 6

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 1 7

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

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

Threat Sources: System (technology) problems Hardware failures ➲ Software failures ➲ Failures of related systems ➲ Malicious code ➲ 2 0

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

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

Technical Vulnerabilities ➲ Flaws in ● ● ● ➲ Design Implementation Configuration Of: ● ● Hardware Software 2 3

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

Physical and Environmental Insufficient physical access controls ➲ Poor siting of equipment ➲ Inadequate temp/humidity controls ➲ Inadequate power conditioning ➲ 2 5

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 ➲ 2 6

Business continuity and compliance Inadequate, inappropriate management of business risks ➲ Inadequate business continuity planning ➲ Inadequate monitoring for compliance with governing policies and regulations ➲ 2 7

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 ➲ 2 8

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? ) 2 9

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

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. 3 1

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. 3 2

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

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

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

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? 3 6

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 3 7

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) 3 8

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 3 9

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

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

Risk Analysis Example (cont'd) ➲ Impact ● On individuals? ● ● On MUSC assets? ● ● Let's assume not life-threatening, but still “serious”. 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”. 4 2

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

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

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 ➲ 4 5

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

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

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

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? 4 9

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

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

Risk Analysis Worksheet: Columns ➲ Security Issue ● T-V Pair, or Compliance Issue Likelihood* ➲ Impact* ➲ Risk Level ➲ Recommended Security Control(s) ➲ Control Priorit(ies) ➲ 5 2

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

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? ➲ 5 4

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

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? 5 6

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

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 ➲ 5 8

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

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

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

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

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