HIPAA Security Rule

1
HIPAA Security Rule

• Effective HIPAA Security Assessments

Richard Busby, JD Multnomah County Information
Systems Security Officer
2
Overview

• HIPA Security Rule (HSR) applies only to storage
  or transmission of electronic Protected Health
  Information (e-PHI)
• HSR standards establish a minimum level of
  security to be met by covered entities.
• HSR is technology neutral
• 3 Areas of focus
• Administrative
• Physical
• Technical

3
Understand the requirements

• "Security Management Process" is listed first
  under the "Administrative safeguards" section
• Risk Assessment (164.308(e)(1) is listed first
  under that Subsection.
• The Risk Assessment forms the foundation on
  which all of the other implementation
  specifications depend.

4
The Risk Assessment

• 164.308(a)(1)(ii) requires the risk assessment
  to be a thorough and accurate assessment
• Of the potential risks and vulnerabilities
• To the confidentiality, integrity, and
  availability
• Of e-PHI held by the CE

5
Assess Your Vulnerability

• To understand the risk level in your organization
  and what those risks entail, a risk assessment is
  the First thing to accomplish
• HSR states the required risk analysis is a
  tool to allow flexibility for entities in meeting
  the requirements security
• Audit the organizations
• existing security policies, if any
• practices and technologies

6
In-house or Consultant

• In-house knows enterprise
• May result in blind spots or turf protection
• Outside consultant doesnt know the enterprise as
  well may miss some areas
• Brings fresh perspective to assessment process
• Either way use a known methodology understand
  what you are trying to accomplish
• Best may be to use both in conjunction

7
Risk Assessment Approach

• Use a standards-based methodology it gives you
  credibility in later audit.
• Operationally Critical Threat, Asset, and
  Vulnerability Evaluation (OCTAVE)
• Developed by Carnegie Mellon University
• Automated Security Self-assessment tool (ASSET)
• Developed by National Institute of Standards and
  Technology
• Track to the Implementation specifications of
  Rule

8
Risk Assessment Areas for investigation

• E-PHI boundary definition
• Threat identification
• Vulnerability identification
• Security control analysis
• Risk likelihood determination
• Impact analysis
• Risk determination
• Security control recommendations

9
Required Implementation Specifications

• 164.306(d) says required implementation
  specifications must be met.
• Key Point the covered entity must meet the
  standard.

10
Addressable Implementation Specifications

• Under 164.306(d)(3) must assess whether an
  addressable implementation specification is
• reasonable and appropriate safeguard
• in its environment.
• Addressable does not mean Optional

11
Addressable Implementation Specifications

• Factors to consider include under 164.306(a)(2)
• The size, complexity and capabilities of the
  organization
• The technical infrastructure, hardware and
  software security capabilities
• The costs of security measures
• The probability and criticality of potential
  risks to e-PHI

12
Alternatives for Addressable Implementation
Specifications

• Implement one (or more)
• addressable implementation specifications
• alternative security measures
• a combination of both or
• Decide to not implement either an addressable
  implementation specification or an alternative
  security measure.
• Reasons for your choice must be documented
  164.306(c)(ii)(B)(1) and (2)

13
Get And Keep HSR Compliance On The Radar Screen

• Executive buy-in is essential - regardless of
  size of organization
• If you are a payer or clearing house you may
  already be late! (Oregon admin rules)
• Develop a communication plan
• Increase employee awareness
• Keep fear of the unknown to a minimum

14
Who will be responsible for implementation?

• Assigned Security Responsibility under
  164.308(a)(2) requires appointment of a person
  or team to be responsible
• Where do we locate this position?
• Security is the identification and management of
  risk
• Don't assume that security oversight belongs in
  IT
• If not IT, where?
• Consider placing security responsibility in Risk
  Management
• Consistent with the model of splitting
  operational and oversight responsibilities
• In smaller CE a designation of a person who has
  time and energy to task is important

15
Role Based Access Control

• Many commentators believe that RBAC is the key
  to successful implementation of HIPAA.
• Defines access by the role that a person has in
  the organization.
• May be the most cost-effective way of meeting the
  requirement that data is available only on an
  as-needed basis.
• RBAC is not mandated by HIPAA but eases
  administration of changes.

16
Other issues bearing on your Data

• Understand the intrinsic value of your data
• Social Security numbers vs. identity theft
• Audit data that HIPAA requires you to collect
  save.
• Make analysis of logged information automated, if
  possible.
• If you are a smaller CE - at least save your
  logs.
• Consider having a periodic spot check by
  consultant if you have no on-staff persons.

17
Know the Risks to Mitigateand How

• After the analysis is conducted conduct a risk
  analysis
• Weigh the likelihood and possible resulting
  damage of each potential risk
• Determine the likelihood a certain threat will
  attempt to exploit a specific vulnerability
• Determine the level of damage should the threat
  successfully exploit the vulnerability
• The adequacy of planned or existing security
  controls
• Rank the risks relative to each other and to the
  entire enterprise.
• If the cost to mitigate a risk is greater than
  the cost of the potential breach, dont bother
  with mitigation.

18
Forge ahead

• Consider confronting administrative and physical
  security policies and procedures first
• policies will drive the implementation of
  solutions
• Consider finishing this part of the process by
  mid-year 2004
• Place highest priority tasks, risks and security
  holes atop of your HIPAA compliance project list.

19
No, youre not done

• HSR compliance deadline is April 22, 2005.
• AFTER this date is when HIPAA Security Rule takes
  effect
• HSR requires periodic reevaluations of
  organization security

20
Tips from Multnomah County Experience

• Use HIPAA Security Rule Communication plans
• To raise security awareness and preparedness
  across the enterprise
• To get your employees thinking in a
  security-aware mode.
• (Yes, it IS their job.)
• To start to establish a uniform, standards-based,
  best practices approach to Security across the
  entire enterprise
• To continue to raise security awareness and
  preparedness with each succeeding required
  reexamination

21
Key Point

• A continuing review of enterprise security is
  necessary, even during the HIPAA compliance
  effort.
• Any change to applications or work process may
  ripple through the enterprise and have security
  impacts that are unforeseen
• SQL Security, SAP and Access,
• Vendor maintained applications

22
Contact Information

• Richard H. Busby
• Multnomah County
• Information Systems Security Officer
• email Richard.h.busby_at_co.multnomah.or.us
• Phone [phone]
• Fax [phone]

23
e-PHI Boundary Definition

• Conduct a detailed inventory of e-PHI and
  information systems that contain e-PHI.
• Use questionnaires, on-site interviews and
  inspections, document review, and automated
  scanning tools
• Review and identify
• Information system hardware and software details
• Internal and external interfaces of information
  systems
• Primary users of the information systems and
  e-PHI
• Basic function and purpose of the e-PHI and
  information system
• Technical (e.g., hardware or software access
  control mechanisms, encryption) and non technical
  controls (e.g., security policies, employee
  training)

24
Threat Identification

• Identify all potential threats to its e-PHI and
  related information systems.
• A threat is defined as "something or someone that
  can intentionally or accidentally exploit a
  vulnerability."
• In general, there are three types of threats to
  e-PHI
• Natural Floods, earthquakes, tornados, etc.
• Human Unintentional (incorrect data entry or
  accidental deletion of data) and intentional
  (denial of service attack,installing malicious
  software)
• Environmental Power failures, hazardous material
  spill, etc.

25
Vulnerability Identification

• Identify the vulnerabilities of e-PHI and related
  information systems.
• A vulnerability is a flaw or weakness in system
  security procedures, design, implementation, or
  internal controls that can be exploited by a
  threat and result in misuse or abuse of e-PHI.
• Identify vulnerabilities by
• reviewing vulnerability sources
• performing security assessments.

26
Security Control Analysis

• Analyze the preventive and detective security
  controls that have been implemented or will be
  implemented to protect e-PHI.
• Preventive controls are designed to prevent or
  restrict the exploitation of vulnerabilities
  (e.g., access control, authentication).
• Detective controls detect and report violations
  (e.g., audit trail, alarm).
• Analysis should clearly define
• What security controls are being used to protect
  specific e-PHI
• How they're being used
• Any gaps between how they're being used and
  supposed to be used.

27
Risk Likelihood Determination

• Three factors should be considered
• Threat motivation and capability,
• Type of vulnerability,
• Existence and effectiveness of security
  controls.

28
Risk Likelihood Determination

• High Threat - highly capable, motivated, or
  likely. Current security controls are ineffective
• Medium Threat - capable, motivated or likely.
  Security controls in place that may prevent
  exploitation of specific vulnerabilities
• Low Threat - not capable, motivated or likely.
  Current security controls will likely prevent
  exploitation of specific vulnerabilities

29
Impact Analysis

• Determine the impact that would result if a
  threat were to successfully exploit a
  vulnerability.
• Interview Information system and e-PHI owners to
  determine the impact in the following areas
• Confidentiality e-PHI is disclosed or accessed
  in an unauthorized manner
• Integrity e-PHI is improperly modified
• Availability e-PHI is unavailable to authorized
  users
• Define the impacts as high, medium or low.

30
Risk Determination

• For each vulnerability and threat, make a risk
  determination based on
• The likelihood a certain threat will attempt to
  exploit a specific vulnerability
• The level of impact should the threat
  successfully exploit the vulnerability
• The adequacy of planned or existing security
  controls

31
(No Transcript)
32
Security Control Recommendations

• Propose security controls that can mitigate or
  eliminate unacceptable risks to e-PHI.
• Proposed controls would be evaluated when the CE
  moves into risk mitigation.