1

Information Security ComplianceSystem Owner Training

Module 3Risk Analysis and Security Plan

Richard Gadsden

Information Security Office

Office of the CIO – Information Services

+1-843-792-8307

gadsden@musc.edu

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

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

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

Unacceptable Risk vs. Unnecessary Cost

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

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

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

Compliance Process

➲ Existing Systems: 6-step Process1. 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

Step 1.0: Review MUSC Policies, Standards and

Guidelines

➲ URL: http://www.musc.edu/security➲ Policies

● high-level principles, goals, responsibilities➲ Standards

● performance standards (min. requirements)➲ Guidelines

● “how to”● recommended approaches

11

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

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

13

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)

14

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

15

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

Risk Analysis Concepts

➲ Defining Risk● Threats● Vulnerabilities

➲ Measuring Risk● Likelihood● Impact

➲ Managing Risk● Security Controls (Safeguards)

17

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

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

Threat Sources: People

➲ activists➲ consultants➲ crackers/hackers➲ customers➲ deranged people➲ extortionists➲ hoodlums

➲ insiders➲ maintenance people➲ organized crime➲ private investigators➲ professional thieves➲ terrorists➲ vandals

20

Threat Sources:System (technology) problems

➲ Hardware failures➲ Software failures➲ Failures of related systems➲ Malicious code

21

Threat Sources:Other (environmental) problems

➲ Power outages➲ Natural disasters➲ Building environment control problems➲ Water damage from man-made sources

22

Vulnerabilities

➲ Def: A weakness or a flaw➲ Categories

● Technical● Human resource● Physical and environmental● Operational● Business continuity and compliance

23

Technical Vulnerabilities

➲ Flaws in● Design● Implementation● Configuration

➲ Of:● Hardware● Software

24

Human Resource Vulnerabilities

➲ Key person dependency➲ Gaps in pre-employment screening➲ Gaps in awareness and training➲ Gaps in discipline➲ Improper termination of access

25

Physical and Environmental

➲ Insufficient physical access controls➲ Poor siting of equipment➲ Inadequate temp/humidity controls➲ Inadequate power conditioning

26

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

Business continuity and compliance

➲ Inadequate, inappropriate management of business risks

➲ Inadequate business continuity planning➲ Inadequate monitoring for compliance with

governing policies and regulations

28

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

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

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

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

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

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

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

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

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

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

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

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

Risk Level (Magnitude)

➲ Risk = Likelihood x Impact➲ Quantitative

● Annualized Loss Expectancy (ALE)➲ Qualitative

● Scale: Low, Moderate, High● “Multiply” Likelihood and Impact Ratings

41

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

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

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

Security Controls

➲ Three basic control strategies:● Prevention● Detection● Recovery

45

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

More Information

➲ MUSC Information Security Guidelines: Risk

Management

● http://www.musc.edu/security/guidelines

➲ NIST Computer Security Resource Center

● http://csrc.nist.gov

62

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

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!