TACKLING THE ENCRYPTION CONUNDRUM

Transcription

1 TACKLING THE ENCRYPTION CONUNDRUM Feisal Nanji DISCLAIMER: The views and opinions expressed in this presentation are those of the author and do not necessarily represent official policy or position of HIMSS.

2 Conflict of Interest Disclosure Feisal Nanji, CISSP Has no real or apparent conflicts of interest to report HIMSS 2

3 Learning Objectives 1. Recognize encryption challenges and requirements in Health Care 2. Describe the challenges of using encryption for all data at rest and in motion 3. Identify the strategies available for encrypting data without overwhelming an organization 4. Demonstrate how to achieve encryption effectively and at reasonable cost 3

4 What is encryption? Encryption is the conversion of data into a form, called a ciphertext, that cannot be easily understood by unauthorized people. In order to easily recover the contents of encrypted data, a correct decryption key is required. 4

5 5

6 Information: Two additional elements: cannot be viewed by people who do not have authority ( Data in motion and data at rest) is not tampered with (Typically this is data in motion) 6

7 Regulatory requirements for encryption: Four specific, interlocking mentions in health care regulation Can lead to confusion 7

8 Interlocking considerations: Dept of HHS Guidance Breach Notification HIPAA Meaningful Use 8

9 The Breach Notification Rule under section 45 CFR defines: "Unsecured protected health information means protected health information that is not rendered unusable, unreadable, or indecipherable to unauthorized individuals through the use of a technology or methodology specified by the Secretary in the guidance issued under section 13402(h)(2) of Public Law (American Recovery and Reinvestment Act of 2009 (ARRA) on the HHS Web site. SAFE HARBOR PROVISION!! 9

10 Department of HHS:. after consultation with stakeholders, issue (and annually update) guidance specifying the technologies and methodologies that render protected health information unusable, unreadable, or indecipherable to unauthorized individuals, including the use of standards developed under section 3002(b)(2)(B)(vi) of the Public Health Service Act, as added by section of this Act. 10

11 HIPAA (1996) states: "A covered entity must, in accordance with Implement a mechanism to encrypt and decrypt electronic protected health information." (45 CFR (a)(2)(iv)) But the HIPAA encryption standard specified in the security rule is deemed "addressable" meaning that the covered entity (CE) must either implement encryption or come up with a 'reasonable and appropriate' solution to meet the regulatory requirement. 11

12 Specific guidance under HIPAA: For "data at rest" (i.e., data that resides in databases, file systems and other structured methods), the approved encryption processes are those that are consistent with NIST Special Publication , "Guide to Storage Encryption Technologies for End User Devices. For "data in motion" (i.e., data that is moving through a network, including wireless transmission), the approved encryption processes are those that comply with the requirements of the Federal Information Processing Standards (FIPS) These include, as appropriate, standards described in NIST Special Publications , "Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations"; , "Guide to IPsec VPNs"; or , "Guide to SSL VPNs, and may include others which are FIPS validated 12

13 Encryption: Meaningful Use requirements and considerations Focused on how certified EHR technology is used by providers and patients for Stage 1, Stage 2 and Stage 3 13

14 Meaningful Use: Stage 1 Protect electronic health information created or maintained by certified EHR and conduct a security risk assessment 14

15 Meaningful Use: Stage 2 Secure messaging for ambulatory systems Not restricted to ; may include patient portal, PHR, or other messaging system Adopts encryption and hashing algorithm standards as baseline Encryption of data at rest 45 CFR (a)(iv) Electronic health information store on end-user devices is encrypted after use of EHR is stopped; or Ensure EHI never remains on end-user device after use of EHR is stopped Provide patients the ability to view online, download and transmit their health information to third parties 50% patients have access --- EPs within 4 business days Hospitals within 36 hours of discharge, >10% of patients view, download or transmit their records 15

16 Especially for stage 2: Your Portal & EHR Vendor needs to explain: How do they do encryption (storage, messaging)? What overhead does it generate? How to enable and disable encryption? How do they log encryption changes? 16

17 Meaningful Use: Stage 3 Still under discussion.but. Possible move from addressable to required? Ultimate Pandora s box encrypt everything!! 17

18 Where is Encryption potentially needed? Wherever Data is at rest Databases, browsers, client applications, Ipads, the Cloud! SaaS applications in particular are a very thorny area Wherever Data is in motion Internal and External networks, things that are shady or in between), and lets not forget Health Information Exchanges!! 18

19 Data at Rest Encryption choices 19

20 Data in Motion Encryption choices 20

21 Unfortunately this gives IT folks migraines Data in motion Encryption overhead for applications and networks (SSH, IPSEC, TLS) Key management complexity Hash function use Data at Rest Mobile Device management (BYOD) is a huge and problematic issue Back-up tapes often not encrypted Biomedical devices (Ultrasound, Bone density scanners, infusion pumps etc.) USB Keys DBMS (Access control, DBA, Key management issues) Logs critical for chain of custody File versus full disk encryption Rights management software ( Digital Rights Management, Watermarking for imaging applications etc.) Cost and technical complexity 21

22 So how do you move forward? Develop an appropriate governance structure (not so simple!!) Educate everyone on the difference between a data owner and data custodian Conduct data classification Educate everyone that encryption is not a panacea in today s world Begin your encryption management process 22

23 Key encryption process mgt. steps: Identify all areas where ephi is stored Create Tiers of risk Conduct data flow mapping Develop encryption controls strategy 23

24 STEP 1 Identify all the possible areas where ephi is stored or transmitted. This is a significant effort and will involve your application, network, biomedical teams and privacy officers A major impediment is that there may be a lot of shadow IT being used at providers. Use Data Loss Prevention (DLP) systems to track shadow IT and identify rogue repositories 24

25 STEP 2 Create Tiers of risk A risk based approach makes most sense and provides for appropriate cost allocation 25

26 STEP 3 Conduct data flow mapping How does your PHI flow? Who owns the data? 26

27 STEP 4 Consider what controls you need to apply.. The types of encryption controls available are myriad 27

28 Encryption no brainers! Full disk encryption for laptops and desktops Unlocked or easily accessible servers Mobile devices containing ephi Back-up tapes 28

29 FINAL POINTERS We can t encrypt everything Use a risk based approach Technical and non-technical people must be partners 29

30 Thank You!