feisal nanji himss 13 -- finalfinalfinal
DESCRIPTION
Tackling the Encryption ConundrumTRANSCRIPT
Conflict of Interest Disclosure Feisal Nanji, CISSP
Has no real or apparent
conflicts of interest to report.
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 © 2013 HIMSS
Learning Objectives
1. 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
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
Two additional elements:
• Information:
– 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
Regulatory requirements for encryption:
• Four specific, interlocking mentions in health care regulation
• Can lead to confusion
7
Breach Notification
Dept of HHS Guidance
HIPAA Meaningful Use
Interlockingconsiderations:
8
The Breach Notification Rule under section 45 CFR 164.402 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 111-5 (American Recovery and Reinvestment Act of 2009 (ARRA) on the HHS Web site.“
• SAFE HARBOR PROVISION!!
9
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 13101 of this Act.”
10
HIPAA (1996) states:
• "A covered entity must, in accordance with §164.306… Implement a mechanism to encrypt and decrypt electronic protected health information." (45 CFR § 164.312(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
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 800-111, "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) 140-2. These include, as appropriate, standards described in NIST Special Publications 800-52, "Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations"; 800-77, "Guide to IPsec VPNs"; or 800-113, "Guide to SSL VPNs,“ and may include others which are FIPS 140-2 validated
12
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
Meaningful Use: Stage 1
• Protect electronic health information created or maintained by certified EHR and conduct a security risk assessment
14
Meaningful Use: Stage 2
• Secure messaging for ambulatory systems– Not restricted to email; may include patient portal, PHR, or other messaging
system– Adopts encryption and hashing algorithm standards as baseline
• Encryption of data at rest– 45 CFR 164.312(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
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
Meaningful Use: Stage 3
• Still under discussion….but….
– Possible move from addressable to required?– Ultimate Pandora’s box – encrypt everything!!
17
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
20
Data in Motion – Encryption choices
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 complexity21
• 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
So how do you move forward?
22
23
1• Identify all areas where ePHI is stored
2• Create “Tiers” of risk
3• Conduct data flow mapping
4• Develop encryption controls strategy
Key encryption process mgt. steps:
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
STEP 2
• Create “Tiers” of risk…
– A risk based approach makes most sense and provides for appropriate cost allocation
25
STEP 3
• Conduct data flow mapping
– How does your PHI flow? Who owns the data?
26
STEP 4
• Consider what controls you need to apply..
– The types of encryption controls available are myriad
27
Encryption no brainers!
• Full disk encryption for laptops and desktops• Unlocked or easily accessible servers • Mobile devices containing ePHI• Back-up tapes
28
FINAL POINTERS
• We can’t encrypt everything• Use a risk based approach• Technical and non-technical people must be
partners
29
