Tackling the Encryption Conundrum

1. TACKLING THE ENCRYPTION CONUNDRUM
Feisal Nanji (feisal@techumen.com)

2. 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.
© 2013 HIMSS 2

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

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

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

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 13101 of this Act.”
10

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

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

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

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
1
• Create “Tiers” of risk
2
• Conduct data flow mapping
3
• Develop encryption controls strategy
4
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!
feisal@techumen.com