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 [email protected]
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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
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!
Related Documents
