Slashdot Mirror
Using Encryption Garners Exemption For Data Breach Notification
Combat Wombat writes with this excerpt from the Register: "New data breach rules for US healthcare providers have come under criticism from a security firm that specialises in encryption. As part of the Health Information Technology for Economic and Clinical Health (HITECH) Act, which comes into effect from 23 September, health organisations in the US that use encryption will no longer be obliged to notify clients of breaches."
If the provider uses rot13, they can consider that good enough
So all they have to do is 'encrypt' it? XOR here we come!
Seriously - is there any guide to what TYPES of encryption are covered under this? Otherwise its inane.
Once again we see an example of public policy on technology being made with apparently little knowledge or regard for technology. The word "encryption" guarantees nothing. Suppose we just use Pig Latin? Ancay ouyay eadray isthay?
whether it's encrypted or not. With encryption it is (in principle) harder. The weakest link is usually not the computer engineering but social engineering anyway.
The only possible interpretation of any research whatever in the 'social sciences' is: some do, some don't
If you wear your seatbelt, you don't have to buy auto-insurance, or report a crash you are involved with.
Because if everyone was wearing their seatbelt, it's impossible for anyone to have gotten hurt.
Basically the same logic behind not reporting a data breach, if encryption was used.
*Not even considering how secure the keys are, and whether the intruder might be able to have gotten some usable data.
Businesses that use encryption for communications rarely encrypt everything.
The method of encryption is defined in the law, adopts the standards set forth by the NIST, and there is a mechanism to update what is acceptable annually through published Guidances. This law is an improvement over what was previously in place. Read the HIPAA Security and Privacy rules as last updated in 2005, and then look at the major steps forward HITECH makes.
That future Guidances can update standards without having to send a law through Congress is also going to allow for future improvements in security, too. HITECH was part of the economic recovery act (ARRA), which shows how difficult it was for HIPAA to get updates - this had to be tacked onto an unrelated must-pass bill.
This article is from an encryption vendor who is stating that most encryption products are what he calls "point-to-point" encryption I bet he considers his own product to not be, thus it is superior, and thus HIPAA should require all companies to buy his products.
For those of you who think "encryption" is left up to the governed:
The HHS Guidance identifies four situations where paper or electronic data may be vulnerable to a breach, and suggests appropriate safeguards to secure the PHI:
- "Data at Rest". This is data that resides in databases, file systems, and other structured storage methods. The HHS Guidance points to the National Institute of Standards and Technology Special Publication 800-111, Guide to Storage Encryption Technologies for End User Devices as the approved methodology.
- "Data in Motion". This is data that is moving through a network, including wireless transmission. The HHS Guidance points to specific requirements in Federal Information Processing Standards (FIPS) 140-2 which 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.
- "Data Disposed". This is discarded paper records or recycled electronic media. The electronic media must have been cleared, purged, or destroyed consistent with NIST Special Publication 800-88, Guidelines for Media Sanitization, such that the PHI cannot be retrieved. For discarded paper records, PHI would need to be shredded or destroyed in a manner that precludes reconstruction.
- "Data in Useâ. This is data in the process of being created, retrieved, updated or deleted. The encryption and destruction processes described above, along with the general HIPAA safeguards, will apply to all data in use.
The actual document is here:
http://www.hhs.gov/ocr/privacy/hipaa/understanding/coveredentities/federalregisterbreachrfi.pdf
I started to post several derogatory comments as I read through it but eventually I came to the conclusion that while nearly unfathomable to most readers it doesn't completely suck.
In several cases they specifically ask for comment from the public where they think there may be valid concern and I think they accurately identified the weak links where they requested comment. If you have an opinion you might consider posting it there rather than (or in addition to) here.
They do actually address reporting breaches of encrypted data where that encryption could arguably have been broken or circumvented.
I don't quite understand the logic of not simply reporting any breach but it's hardly the disaster it's being made out to be.
Having just read through the document and as some other folks have posted further down it's not nearly as bad as you're implying and is *less* friendly to health agencies where reporting rules are concerned.
It's certainly written in typical bureaucrat/lawyer speak but for individuals it's a clear improvement over the current state of affairs.
In terms of the form of these documents, I wonder if an collaborative re-write type project would fly. Get volunteers to re-write the document such that the intent and legality doesn't change but the readability is greatly increased. I noted several times where the general ordering of the document was not terribly linear, they repeated themselves or used very confusing sentence structure.
I just know I don't want to be in charge of the Fully User Capable Key Encryption Device program.
Our founding fathers removed the guys in charge. Be American. Vote incumbents out.
The only provable encryption scheme OTP works with XOR. The only drawback is the key length.
Which is why you use a pseudorandom number generator to make a message-specific key stream as long as the message. As long as you never reuse a key, and your PRNG doesn't suck, you have what they call a synchronous stream cipher. An example of a well-known stream cipher is RC4 from RSA Security. Another is any block cipher in counter mode.
I seem to recall a case from the UK, where two CDs filled with tax information from about 10 million people were left on a train or bus.
Thankfully all the data on the CDs was encrypted.
Typically the password(s) were written on the CDs.
So, no, encryption does nothing but add a layer of security theatre for data breaches. Notification should still be required.
Add the following requirements:
Probably a few more requirements as well. That way those who really want to know can be told, and those who don't care will just throw the letter away anyway.
Also add very very steep fines for not disclosing data breaches. If the chance of it being known that a breach has occurred are 1%, make the fines 200x the cost of notification and expected loss of business. Hell, add mandatory non-suspendable jail time for the responsible managers (including board members).