Unusable, Unreadable, or Indecipherable? No Breach reporting required

Published: 2009-05-09
Last Updated: 2009-05-09 14:15:44 UTC
by Patrick Nolan (Version: 1)
1 comment(s)

Recent HIPAA legislation promised guidance identifying "the Technologies and Methodologies That Render Protected Health Information Unusable, Unreadable, or Indecipherable to Unauthorized Individuals for Purposes of the Breach Notification Requirements under Section 13402 of Title XIII (Health Information Technology for Economic and Clinical Health Act) of the American Recovery and Reinvestment Act of 2009" (ARRA). The guidance was issued (link below).

So if a covered entity loses the jewels and it's technoligies and methodologies are up to snuff, they do not have to report it.

At this point, the way TLS is referenced, it looks to me that the guidance points to TLS impacts on organizations and security vendors/service providers. YMMV.

There are a large number of high impact HIPAA changes written into ARRA, see;
The American Recovery and Reinvestment Act of 2009
For TITLE XIII-HEALTH INFORMATION TECHNOLOGY - see Page 112 of 407
For PART 1-IMPROVED PRIVACY PROVISIONS AND SECURITY PROVISIONS see Page 146 0f 407

The Guidance;
DEPARTMENT OF HEALTH AND HUMAN SERVICES
45 CFR PARTS 160 and 164
Guidance Specifying the Technologies and Methodologies That Render Protected Health Information Unusable, Unreadable, or Indecipherable to Unauthorized Individuals for Purposes of the Breach Notification Requirements under Section 13402 of Title XIII (Health Information Technology for Economic and Clinical Health Act) of the American Recovery and Reinvestment Act of 2009

**SNIPPETS**

B. Guidance Specifying the Technologies and Methodologies that Render Protected Health Information Unusable, Unreadable, or Indecipherable to Unauthorized Individuals

Protected health information (PHI) is rendered unusable, unreadable, or indecipherable to unauthorized individuals only if one or more of the following applies:

a)      Electronic PHI has been encrypted as specified in the HIPAA Security Rule by "the use of an algorithmic process to transform data into a form in which there is a low probability of assigning meaning without use of a confidential process or key"15 and such confidential process or key that might enable decryption has not been breached. Encryption processes identified below have been tested by the National Institute of Standards and Technology (NIST) and judged to meet this standard.

i)        Valid encryption processes for data at rest are consistent with NIST Special Publication 800-111, Guide to Storage Encryption Technologies for End User Devices.17

ii) Valid encryption processes for data in motion are those that comply with the requirements of 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.18

b)      The media on which the PHI is stored or recorded has been destroyed in one of the following ways:

i)                    Paper, film, or other hard copy media have been shredded or destroyed such that the PHI cannot be read or otherwise cannot be reconstructed.

ii)                  Electronic media have been cleared, purged, or destroyed consistent with NIST Special Publication 800-88, Guidelines for Media Sanitization,19 such that the PHI cannot be retrieved.

17
Guide to Storage Encryption for End User Devices


18
FIPS 140-2

NIST Special Publications 800-52 - Guidelines for the Selection and Use of Transport Layer Security


Guide to IPsec VPNs

Guide to SSL VPNs

19
Guidelines for Media Sanitization

1 comment(s)

Comments

I'm still not comfortable with the safety of data on these devices. If I steal a laptop and the data is encrypted at rest I still may be able to get at the data in the future. If a new vulnerability is discovered I could turn the system on, perform the exploit on the system and gain access to the data.

This also doesn't really cover exploiting a local account that has access to the sensitive data. If it is encrypted the user doesn't see it as encrypted so if I break in on the user's account (web exploit, etc) I have access to the data unencrypted.

Diary Archives