Information%20Security%20Compliance%20System%20Owner%20Training

1
Information Security ComplianceSystem 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_at_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 SecurityA 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 Process
• 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

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 gt type of risk
• Likelihood Impact gt 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 SourcesSystem (technology) problems

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

21
Threat SourcesOther (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 gt Type of breach
• Likelihood Impact gt 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 lt 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 WorksheetRecommended 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)

53
Compliance Checklist Issues

• Assume you have a score lt 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!