HIPAA Security Rule

1. HIPAA Security Rule Effective HIPAA Security Assessments

2. 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. 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. Administrative Safeguards (9 standards) - People and process Security Management Process Risk Analysis Risk Management Sanction Policy Information System Activity Review Assigned Security Responsibility Appointment of a Security Official Contingency Plans Data Backup Disaster Recovery Plan Emergency Mode Operation Business Associate Contracts Written Agreements with outside entities that handle PHI Physical Safeguards (4 standards) - Locks, access, controls Facility Access Controls Facility Security Plan Access Control and Validation Procedures Workstation Security Device and Media Controls Media Disposal Media Re-use Technical Safeguards (5 standards) - Technology Access Control Unique User Identification Automatic Logoff Encryption and decryption Person or Entity Authentication Transmission Security Integrity ControlsAdministrative Safeguards (9 standards) - People and process Security Management Process Risk Analysis Risk Management Sanction Policy Information System Activity Review Assigned Security Responsibility Appointment of a Security Official Contingency Plans Data Backup Disaster Recovery Plan Emergency Mode Operation Business Associate Contracts Written Agreements with outside entities that handle PHI Physical Safeguards (4 standards) - Locks, access, controls Facility Access Controls Facility Security Plan Access Control and Validation Procedures Workstation Security Device and Media Controls Media Disposal Media Re-use Technical Safeguards (5 standards) - Technology Access Control Unique User Identification Automatic Logoff Encryption and decryption Person or Entity Authentication Transmission Security Integrity Controls

4. 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. 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: [t]he required risk analysis is a tool to allow flexibility for entities in meeting the requirements security Audit the organization�s existing security policies, if any practices and technologies

6. 6 In-house or Consultant In-house knows enterprise May result in blind spots or �turf� protection Outside consultant doesn�t 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. 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. 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. 9 Required Implementation Specifications �164.306(d) says required implementation specifications must be met. Key Point: the covered entity must meet the standard.

10. 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. 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. 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. 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. 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. 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. 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. 17 Know the Risks to Mitigate�and 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, don�t bother with mitigation.

18. 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. 19 No, you�re 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. 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 We are using HIPAA as a �front� to raise security across the whole enterprise. We concluded that it is more work and makes less sense to have a HIPAA and a non-HIPAA security profile.We are using HIPAA as a �front� to raise security across the whole enterprise. We concluded that it is more work and makes less sense to have a HIPAA and a non-HIPAA security profile.

21. 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 Be aware that you have a dynamic enterprise. That dynamic quality means that you have to keep aware of what is going on in the enterprise during your compliance effort. Your assessment will address only what existed at the time of the review. In our case we have 16 months of changes and evolution to track during compliance effortBe aware that you have a dynamic enterprise. That dynamic quality means that you have to keep aware of what is going on in the enterprise during your compliance effort. Your assessment will address only what existed at the time of the review. In our case we have 16 months of changes and evolution to track during compliance effort

22. 22 Contact Information: Richard H. Busby Multnomah County Information Systems Security Officer email: Richard.h.busby@co.multnomah.or.us Phone: 503-988-5564 Fax: 503-988-5009 Thanks for allowing me to present our experience to you. We are all in the same rowboat here, we might as well paddle together rather than working alone. I would be glad to confer with any of you to give what ever assistance I can offer. Thanks.Thanks for allowing me to present our experience to you. We are all in the same rowboat here, we might as well paddle together rather than working alone. I would be glad to confer with any of you to give what ever assistance I can offer. Thanks.

23. 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. 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. 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. 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. 27 Risk Likelihood Determination Three factors should be considered: Threat motivation and capability, Type of vulnerability, Existence and effectiveness of security controls.

28. 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. 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. 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. 31

32. 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.