Anurag Shankar University Information Technology Services Indiana University

1. Implementing HPC HIPAA (& FISMA) Anurag Shankar University Information Technology Services Indiana University

2. Outline • Introduction • HIPAA • FISMA • Implementation • Conclusion

3. 1. Introduction

4. A Changing Landscape • As HPC shops, our heritage has been to serve physical scientists and engineers - the “usual suspects”. • Regulatory compliance is a concept foreign to these users. • While we’ve addressed security, compliance still remains an unexplored frontier, not only for HPC, but for Central IT in general.

5. The New Reality • Clinical research computing, traditionally confined to Med School cyberinfrastructures, increasingly requires HPC resources. •  Med School IT cannot keep pace; identifiable HIPAA data is leaking into Central IT/national HPC environments. • We have to weave compliance into the HPC fabric sooner or later.

6. New Motivations • A new HIPAA Omnibus Rule came out in 2013, with new requirements and mandates. • The government will initiaterandom HIPAA auditsin 2014. (They were triggered only in response to a breach earlier.) • Penalties have been raised to millions.

7. But the worst is being in the newspapers! The Corrective Action Plan (CAP) signed by Idaho State University  Breaches reported by universities

8. No Plausible Deniability • HIPAA applies if even a single clinical researcher has an accounton a system. • The govt. says you should have known that allowing clinical researchers on a system opens the possibility of sensitive health information on the system.)  An environment with clinical researchers must be secured, independently of what a researcher may or may not do.

9. FISMA • In addition to HIPAA, we now have FISMA to deal with. • It is slowly showing up in NIH grants and contracts. • It is the next regulatory frontier HPC will have to deal with. • Fortunately, it’s possible to tackle both HIPAA and FISMA using a single, unified approach.

10. The Scope • HIPAA & FISMA require end to end security.This means starting at the customer end (where data is generated)  the network  your end  data disposal. • Any and all dependencies and infrastructure pieces must also be included. • We must consider the entire research workflow.

11. Grant = Data Life Cycle A grant life cycle from an IT provider’s perspective is a data life cycle = Involves compliance • ✔

12. 2. HIPAA

13. A HIPAA Primer • Health Insurance Portability& AccountabilityAct. • Passed in 1996, became law in 2001. • Enforced by the Office for Civil Rights (OCR) in the US Dept. of Health & Human Services (HHS). • The Omnibus File Rule of 2013 includes provisions from the 2006 Health Information Technology for Economic & Clinical Health (HITECH) Act& the 2008 Genetic Information Nondiscrimination Act (GINA).

14. HITECH & GINA • HITECH was part of ARRA and enacted to promote the adoption of Health Information Technology, especially Electronic Health Records (EHR). • GINA prohibits insurers from using human genetic data to deny coverage based on genetic predisposition to future diseases.

15. Patient Privacy Protection • Addressed via the HIPAA Privacy Ruleand the HIPAA Security Rule. • The Privacy Rule defines who HIPAA applies to (covered entities) and what is protected (protected health informationor PHI*). • The Security Rule focuses exclusively on how to protect electronic PHI (ePHI) in any form – at rest, in transit, under analysis, etc. * PHI is identifiable patient data with one or more of 18 identifiers

16. HIPAA Security Rule • The Security Rule requires 1. administrative, 2. physical, and 3. technical safeguardsto • Ensure the confidentiality, integrity, andavailabilityof all ePHIcreated, received, maintained or transmitted; • Identify and protect against reasonably anticipated threatsto the securityorintegrityof the information; • Protect against reasonably anticipated, impermissible uses or disclosures; • Ensurecompliance by the workforce; and • Provide a means for managing risk in an ongoing fashion.

17. Security Rule Safeguards • Administrative– security organization, policies, training, responsibilities, incident response, etc. • Physical – data center access, equipment/media disposal, inventory control, etc. • Technical – firewalls, patching, auditing, scanning, monitoring, accounts, etc. + organizational/policies/documentation requirements

18. Required & Addressable • Each Security Rule safeguard is either “required” or “addressable”. • Required = what it says. • Addressable = should address, but ok if you describe why it is not in place or how you will otherwise address the risk. • A risk assessment (RA) identifies where to concentrate effort. RA can be internal or external.

19. Breach Notification • HIPAA requires that a breach of ePHI be reported ASAP: • To everyone whose ePHI has been compromised. • For a breach involving > 500 patients, to the media and the Secretary of HHS.

20. Business Associates • HIPAA requires a business associate agreement (BAA) with any external entity (= business associate) that touches your ePHI. • Your BAA must include a clause that the BA will protect your ePHI. So must their BAAs with their BAs. • Due diligence requires ensuring that the BA can actually protect your ePHI as per HIPAA.  Purchasing & HIPAA Compliance Office partnerships

21. Enforcement • HIPAA violations can result in civil monetary penalties (up to $1.5 million/violation) against a covered entity and/or individual criminal penalties (up to 10 yrs prison term). • The OCR has been funded via ARRA/HITECH to institute an audit program. They will start random HIPAA auditsin 2014.

22. Does HIPAA apply to All Identifiable Health Data? • No. Only healthcare providers, facilities, and insurers are subject to HIPAA. Identifiable health data outside a healthcare context is not (e.g. personal health data users upload to Google Health, Microsoft HealthVault). • Data, if properly de-identified, is not subject to HIPAA. If unsure, contact your HIPAA Compliance office

23. Who does HIPAA Cover at a University? • Employees, healthcare providers, trainees & volunteers at the medical school and affiliated healthcare sites or programs. • Employees who work with university health plans. • Employees who provide financial, legal, business, administrative, or IT support to the above.

24. Just Good Security? Q: So, the HIPAA Security Rule means we just need to provide good IT security for systems? A: NO. The Security Rule is about assessing & managing risk, and security is only PART of that process. HIPAA requires administrative controls, training, governance, policies, formal review, etc.

25. Information Security Risk Management • Identify, assess, prioritize, and mitigate risk to information security, on an ongoing basis. • Think in terms of managing risk, not just plugging security holes. Risk = {Threat/Vulnerability x Likelihood x Impact} • A big threat due to an existingvulnerability that is highly unlikely to be exploited/has little impact is low risk. You don’t kill yourself over it.

26. Risk Management Framework A mature RMF consists of: • Good governance = institutional security organization, policies, sanctions, enforcement • Risk management = assessment, mitigation through appropriate physical, administrative, technical controls, documentation • Review = regular monitoring, reviews, assessment, and mitigation • Awareness and training

27. HIPAA Security Rule Myths • Myth #1 – Security rule compliance is a boolean. • Truth: There is no thresholdwhere you suddenly become compliant. • Myth #2 – You can be certified HIPAA compliant. • Truth: Nocompany or federal agency is authorized to certify you as being HIPAA “compliant”. (The only way to know for sure is to survive a HIPAA audit, highly undesirable.) So you align with the HIPAA rules as best as you can and “self assert” compliance.

28. HIPAA Security Rule Myths • Myth #3 – Once compliant, you stay compliant. • Truth: No. Compliance is an ongoing process; once started, it never stops. • Myth #4 – You must use external third party for risk/security assessment. • Truth: No. You can do it internally, so long as you follow accepted practices and document it all.

29. 3. FISMA

30. FISMA • Federal Information Security Management Act of 2002. • Requires government agencies to secure their system as per NIST guidelines. • Subcontractors of the agencies (=you) must also comply. • Contracts are now seeing FISMA language. • You are likely to be involved.

31. The FISMA Process • Grants Administrators/Business Development • - Identify and notify the Office of Research Administration (ORA) if there are FISMA terms in the contract • - Make sure the budget includes FISMA costs • - Identify and document key IT security personnel • - Make sure all documents that are referenced are included • PI/Study Team • - Clearly describe the scope of work • - Identify all potential subcontractors and their scope of work • PI/Study Team and IT Support • - Clearly describe data flows • - In detail, describe all systems used to support the contract

32. The FISMA Information Security Process

33. Authority to Operate • The information security planis submitted to the agency. • An ATO letter is issued by the government agency to the business owner (and some authoritative information security unit like the ISO) authorizing operations of the system. • If remediation is not too serious, the agency will issue an Interim Authority To Operate (IATO). The IATO will have a defined end date. Therefore, the problems must be fixed by a certain date.

34. Plan of Action & Milestones • The POA&M describes remediation steps. • Even if a contractor receives an ATO, there still may be items for which the agency requires remediation. These weaknesses may not be significant enough to withhold an IATO/ATO, but they still must be corrected. • Someone at your institution (the ISO?) must track these items and ensure that they are completed.

35. 4. Implementing HIPAA Security

36. Research Computing at IU • Indiana University has a large central IT organization called the University Information Technology Services (UITS). • We provide advanced cyberinfrastructure - supercomputing, massive data storage, visualization, etc., as well as basic services. • Before 2000, IU research cyberinfrastructure was used mostly by the usual suspects.

37. HIPAA History • In 2000, a grant from the Lilly Endowmentrequired our cyberinfrastructure to support biomedical researchers at the IU School of Medicine. • We stored non-ePHI for IUSM for some years. • A decision was finally made to align our entire research cyberinfrastructure with HIPAA. • Accomplished in 2009after a year of effort.

38. IU’s Approach • A protected, walled garden will give you bullet-proof security. • This may work from low to moderate scales. • A separate walled garden HPC environment just for HIPAA is infeasible/impractical. • HIPAA does not require bullet-proof security. • At IU, we decided to focus on risk, not bullet-proofing.

39. HIPAA – Implementing the RMF

40. Assign Ownership • Dedicated resources commensurate with the scale. At IU, we spent around 1.5 FTE-year for the initial effort and 1.0 FTE on an ongoing basis. • Assigned someone to lead the project. • Empowered the leader.

41. Form Partnerships • Got to know IU and IU School of Medicine Compliance folks. • Formed an oversight committee; put all stakeholders on it – Compliance, Counsel, Information Security Office, Information Policy Office, School of Medicine CIO/Security Officer, staff/faculty, and UITS senior management.

42. Document Everything • Spent a lot of time on developing a documentation strategy/format. • Documented all current policies and procedures, physical, administrative, and technical controls. • Consulted with line managers & key staff. • Instituted a secure document management system (DMS).

43. Hire External Consultant • Asked IU Compliance folks for references. • Got referred to a consultant from DC, who also serves on national HIPAA committees, etc. • Consultant was given information about the organization, documentation, etc. • Consultant visited IU a couple times to do in-person interviews.

44. Perform Gap Analysis • Information security Gap Analysis (GA) measures gaps between actual security on the ground and what HIPAA requires. • Involved on-site interviews. • Consultant used the data to identify gaps. • We received the GA report.

45. Fill Gaps • Reviewed gap analysis report. • Filled as many holes as we could, especially the most serious ones. • Updated documentation. • Got ready for risk assessment.

46. Assess Risk • Everything we had went into the risk assessment exercise. • Submitted updated documentation and other information as requested to the external consultant. • On-site interviews followed. • Received a risk assessment report. • Report identified risks and scored them.

47. Follow Standards • We were measured against the NIST 800-53 security standard since it is often used for complying with HIPAA. This was fortuitous later for our FISMA work. • It put an “official seal” & added rigor to the process. • We also reviewed other NIST guidelines and standards such as ISO 27001, etc. and IT best practices.

48. Create a Risk Management Plan • Reviewed risk assessment report. • Addressed all risks and documented mitigation, reason for not mitigating, or alternatives. • Submitted the RM plan to the external consultant for review. • Modified RM plan using her recommendations.

49. Execute Risk Management Plan • Execution involved some short term actions that addressed many high/medium risk items immediately. • Instituted long term processes such as regular reviews, risk monitoring, risk avoidance strategies, etc. • Documented everything (again) …

50. Get Official Blessing & Advertize • Submitted everything to the oversight committee. • Received an official letter of approval from Compliance in January 2009. • Advertized internally and targeted only IUSM researchers to avoid unnecessary attention.