I know.. I know..  now that it is here it feels like summer is over, but don’t despair, I am sure something new will be mandated by someone, around something, very soon. As a matter of fact we have another ruling, the final report from HHS is due by February of next year… So we got that going for us.. which is good.

As we cover this a bit, remember, this is not a replacement for HIPAA but really meant to cover entities that were not anticipated in the HIPAA rules. We aren’t talking health care providers and insurance companies but other entities who work with health care records, such as web based businesses and those who support them.

From the FTC:

“The rule applies to both vendors of personal health records – which provide online repositories that people can use to keep track of their health information – and entities that offer third-party applications for personal health records. These applications could include, for example, devices such as blood pressure cuffs or pedometers whose readings consumers can upload into their personal health records.

…

the FTC’s Rule does not apply to businesses or organizations covered by the Health Insurance Portability & Accountability Act (HIPAA). In case of a security breach, entities covered by HIPAA must comply with HHS’ breach notification rule.”

There are plenty of great bloggers putting together information on what this all means, but I want to bring out a few points to those who find this in any way interesting:

1) “limited data sets” are not excluded from the ruling. The FTC feels the risk of re-identification of limited data sets is too great for a blanket exclusion. There is some interesting research on the likelihood of re-identifying limited data sets, and it turns out it is easier than it seems (links below). De-identified data sets are excluded.

2) Unsecured data which is breached is subject to notification, “unsecured” is defined as information “not protected
through the use of a technology or methodology specified by the Secretary of Health and Human Services in the guidance issued under section 13402(h)(2) of the American Recovery and Reinvestment Act of 2009.” So, we are talking:

• De-identification,
• Destruction, or
• Encryption

3) If a breach occurs entities have three notification requirements:

• The individuals impacted must be notified within 60 calendar days. Law enforcement can supersede this.
• The FTC must be notified, via this form, with 10 business days for breaches over 500 records or 60 calendar days after the end of the year for beaches of less than 500 records.
• For breaches of over 500 individuals of a particular state or jurisdiction (think smaller than a state), the media in that jurisdiction must be notified, so if 1000 records are lost but only 200 from each state, no media notification is needed (big sigh, until someone shows their cousin the news producer your letter).

4) Looking at the notification form, the first type of breach they ask about is “Lost or stolen laptop, computer, flash drive, disk, etc.”. This is a strong argument for encryption, or minimally DLP so that data can be tracked.

5) Interesting little side note (and this is not entered here as a “WOW LOOK ANOTHER JURISDICTIONAL LAND GRAB”… if you want to yell that feel free but I think it is a good idea to apply this more broadly rather than less) just because an entity was not under the jurisdiction of the FTC before, does not mean they are not held to there requirements. From the doc:

“In its NPRM, the Commission noted that the proposed rule applied to entities
beyond the FTC’s traditional jurisdiction under section 5 of the FTC Act, such as nonprofits
(e.g., educational institutions, charities, and 501(c)(3) organizations), because the
Recovery Act does not limit the FTC’s enforcement authority to its enforcement”

Links:

FTC Publications and Guidance

http://www.ftc.gov/healthbreach

http://www.ftc.gov/opa/2009/08/hbn.shtm

http://www.ftc.gov/os/2009/08/R911002hbn.pdf

Re-identifying data (and some other interesting stuff)

http://privacy.cs.cmu.edu/people/sweeney/cv.html#publications

Companies are wise to adopt centralized encryption technologies to ensure compliance, simplify management and offer attainable services to internal users but please don’t confuse integrated key management of an enterprise product with enterprise key management.

In my experience, large enterprises are falling short when it comes to enterprise key management strategies both in policy and execution. Companies still lack strategy and comprehensive EKM policy. It simply isn’t enough to take the NIST KM doc and attach your name to it. I can’t tell you how many otherwise excellent policy (functional or otherwise) and standards libraries I have seen that have unenforceable and unsuitable statements in KM documents.

Vendors are claiming to have EKM solutions but wide spread integration with third-party products just isn’t there. Until there is a more interoperability there will be no true EKM unless the `E` decides to do some serious, and potentially limiting, standardization. OASIS is considering KMIP, which seems as good as others.

For now, think strategically, speak to vendors about roadmaps and consider the enterprise not the vendor’s marketing tag.

and remember….

"Key management is the hardest part of cryptography and often the Achilles’ heel of an otherwise secure system." — Bruce Schneier,  Preface to Applied Cryptography, Second Edition

Good links to explore:

Some good links: http://xml.coverpages.org/keyManagement.html

Oasis: http://www.oasis-open.org/home/index.php

The story: http://tinyurl.com/l9akol