Using Encryption Garners Exemption For Data Breach Notification 101
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."
great (Score:4, Funny)
If the provider uses rot13, they can consider that good enough
Re:great (Score:5, Funny)
If the provider uses rot13, they can consider that good enough
But they're already using rot0. Isn't that good enough?
Re: (Score:3, Funny)
It's not rot0, it's rot26. And everybody knows that a higher number means it's better.
And next year, watch out for my new rot52 encryption method....
Re: (Score:1)
Re: (Score:3, Funny)
Re: (Score:3, Informative)
(IANANES, so I'm not sure just how good that is.)
I can hear people saying I must be new here but I only skimmed TFA.
Re: (Score:2)
According to the pdf it has to meet FIPS 140-2 [wikipedia.org], and implies ssl/tls level of encryption. (IANANES, so I'm not sure just how good that is.)
It's pretty good [nist.gov]. It also has requirements for user-level authentication (machine-to-machine is not good enough) and approved key-generation algorithms. It's also actively maintained by people who know what they are doing, which makes it a much better decision than trying to write your own security requirements spec.
Why that should get you out of reporting data loss is what I don't follow. When it might be someone sniffing the data at your ISP, you need to report it, but when you have a FIPS certificati
Re: (Score:2)
"Why that should get you out of reporting data loss is what I don't follow."
Remember yesterday's story about data breach due to an spyware e-mail (http://news.slashdot.org/story/09/09/18/0011218/Spyware-Prank-Exposes-Hospital-Medical-Records)?
I stated there that "the true point is that Hospitals don't want security [...] Pitifully I won't hold my breath waiting for a multimillion exemplary fine against the hospital so others will take the issue more seriously."
Well, there you have it. Not only these kinds
Re: (Score:2)
It's pretty good. It also has requirements for user-level authentication (machine-to-machine is not good enough) and approved key-generation algorithms. It's also actively maintained by people who know what they are doing, which makes it a much better decision than trying to write your own security requirements spec.
FIPS 140 only covers algorithm and implementation details, and a little bit about key management. There's nothing in there that says you can't use an all-zero key, or prepend the key to the data, or use your company name as the key. So you can still build rot-13 out of FIPS 140-certified products (and I've seen it done on numerous occasions). All this requirement is doing is making it less obvious that something's b0rken.
Re: (Score:2)
A cryptographic module may generate cryptographic keys internally. Cryptographic keys generated by the cryptographic module for use by an Approved algorithm or security function shall be generated using an Approved key generation method. Approved key generation methods are listed in Annex C to this standard. If an Approved key generation method requires input from a RNG, then an Approved RNG that meets the requirements specified in Section 4.7.1 shall be used.
Compromising the security of the key generation method (e.g., guessing the seed value to initialize the deterministic RNG) shall require as least as many operations as determining the value of the generated key.
If a seed key is entered during the key generation process, entry of the key shall meet the key entry requirements specified in Section 4.7.4. If intermediate key generation values are output from the cryptographic module, the values shall be output either 1) in encrypted form or 2) under split knowledge procedures.
Documentation shall specify each of the key generation methods (Approved and non-Approved) employed by a cryptographic module.
And the definition of a cryptographic module:
Cryptographic module: the set of hardware, software, and/or firmware that implements Approved security functions (including cryptographic algorithms and key generation) and is contained within the cryptographic boundary.
So, you might be able to abuse FIPS-certified components to build something that does ROT-13, but you shouldn't be able to get the resulting cryptographic module certified. Did any of the examples you have seen end up fulfilling U.S. government contracts that required a FIPS-140 certification?
Re: (Score:2)
So, you might be able to abuse FIPS-certified components to build something that does ROT-13, but you shouldn't be able to get the resulting cryptographic module certified.
You don't need to get the overall result certified, that's why you're building it using FIPS-certified crypto. So what you do is get some FIPS-140 certified crypto (for example the crypto built into any copy of Windows) and then abuse it to make it about as secure as rot13. The module is certified, but it's used in an insecure manner.
Did any of the examples you have seen end up fulfilling U.S. government contracts that required a FIPS-140 certification?
Yes, pretty much all of them, since getting USG contracts is the main reason for going with FIPS-140 certified crypto in the first place.
Re: (Score:2)
Re: (Score:2)
For extra security, use it twice. This post is encrypted with double rot13-encryption.
Re: (Score:1)
Jung qvq lbh fnl? V pbhyqa'g ernq vg guebhtu gur rapelcgvba
http://web.forret.com/tools/rot13.asp [forret.com]
Re: (Score:2)
Re: (Score:1)
XOR! (Score:5, Interesting)
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.
Re: (Score:2, Informative)
There are guidelines, as promulgated by the FTC / HHS. If anyone feels strongly about this, you should write the agencies to change the regulations.
Re: (Score:2)
Since when do congresscritters ever listen to Joe Schmoe more than corporate fatcat lobbyists?
Re: (Score:2)
I doubt fatcat lobbyists care whether they're using AES256 or ROT13.
Re:XOR! (Score:4, Insightful)
and I don't either. It's the key management that is the weak point. 10-to-1 the people who claim exemptions under this rule will lose a laptop in the same bag as the usb key that decrypts the whole mess...
Re: (Score:3, Insightful)
The keys alone won't do the trick. It's the password written on the Post-it note taped to the palm rest that's the bigger concern....
Re:XOR! (Score:4, Insightful)
Re: (Score:2)
Re: (Score:2)
Re:XOR! (Score:5, Interesting)
In any case, you need a key to decrypt your data. If the guy that broke in got the key along with the data, no amount of cryptography is going to help. Usually, from experience, the key is very often to close to the data.
In a company I worked for, we had to set up a bridge between two web apps. We chose an SSO-like solution who worked well on the paper, but the devil is on the details. The guys on the other application decided to encrypt the SSO key in JavaScript on the client.... So the key ended up in clear text in the source of the page!
Oh well....
Re: (Score:2)
The guys on the other application decided to encrypt the SSO key in JavaScript on the client.... So the key ended up in clear text in the source of the page!
So just put up a EULA that forbids people from looking at the web page source code [slashdot.org]. Geez, do I have to figure out everything for you? ;)
Slashdot Cynicism (Score:2)
Seems like the majority of the comments here deride this as a bad idea. But many (most?) of these same people rely on SSL and SSH to encrypt data, and purposefully send it out over a very public network, trusting the power of the encryption to protect them.
Logically, how is this really any different?
We've been using this technique for a long time, now. Our client-based application uses strong encryption to protect the files. Our encryption/decryption system embeds the password in as part of the encryption/d
Re: (Score:2)
The story is about not having to disclose data breach if you use cryptography. This is all well and good unless you consider that there are so many dumb setups out there that are just a joke. Not disclosing security breach for those seems like a stupid idea.
Now for sure, some setups are safe. We don't talk about these.
Re: (Score:2)
Wish you could edit posts!
Have you considered using one-time pads to minimize the risk of a key disclosure? Depending on your circumstances, you could actually allow full disclosure of the keys in a session and *still* have a very secure session!
Re:XOR! (Score:4, Funny)
1 -> 0
0 -> 1
Re:XOR! (Score:5, Funny)
Re: (Score:2)
What do you mean, the box-thingy on the floor is my computer?
Re: (Score:2)
Should have used a functional language like real men then. ;)
Re: (Score:1, Funny)
If I know people at all -- and I think I do -- all you'll end up with is a bunch of bytes that look like this: 111111111.
Re: (Score:2)
Too much coding. Just add "Note: apply this operation TWICE to recover data". Then we don't need to modify any code.
Re: (Score:1)
The only provable encryption scheme OTP works with XOR. The only drawback is the key length.
RC4 (Score:3, Informative)
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 [wikipedia.org]. An example of a well-known stream cipher is RC4 from RSA Security. Another is any block cipher in counter mode.
And message integrity (Score:2)
And message integrity. Since an MITM attacker can just xor his own fraudtext over the ciphertext.
The two drawbacks are key length and message integrity...
Re: (Score:1)
For message integrity you can just append a hash value or a mac.
Re: (Score:1)
Wouldn't he need to know either the plaintext or the key to put any useful data into that fraudtext result?
Re: (Score:2)
Oh, boy ... XOR is the best there is ...
(quite a few stream ciphers uses xor - for a reason: one-time-pad is XOR).
Yeah, I know what you meant.
Re: (Score:2)
Hey dipshit! if you actually read the law, or were in the industry affected by this, you might understand that they actually did specify a level of encryption required. I should know because I just spent the last month upgrading our product to conform to the law. From what I was told by our security experts, AES and 3DES are acceptable.
Cool New Software? (Score:1)
Or do we just need
Who is advising these guys? (Score:3, Informative)
Re: (Score:1)
Yes I can.
Re:Who is advising these guys? (Score:5, Funny)
No I can't.
Re: (Score:1)
What does "Ancay ouyay eadray isthay?" mean?
I read it a couple of times, but I can't make anything of it.
Re: (Score:1)
Think about the question, my answer (The details are important!), and how likely it is that I am actually that obtuse.
Re: (Score:2, Funny)
Once again we see an example of a comment on slashdot being made with apparently little knowledge or regard for the article.
Re: (Score:1)
Re: (Score:1)
Re: (Score:1)
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?
As technology has been "democratized" we have gained as a result a lot of what I call "magazine tech experts", they read something vague in a magazine or web page (usually not a publication specialized in technology or computer science) and go on from that.
Using Encryption Garner Exemption For Data Breach (Score:2)
Guess who wrote or helped write the law...
Those who would have to follow the law and regulations. That's a problem with regulations, the industry that is regulated writes those regulations. Which then helps cut their competition.
Falcon
Re: (Score:3, Interesting)
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 an
Re: (Score:2)
"I noted several times where the general ordering of the document was not terribly linear, they repeated themselves or used very confusing sentence structure."
Psst! Excuse me, Mr. Belthize? Please, trade me papers. You've got the encrypted copy, and that's "Top Sekritz". Thank you sir!!
Re: (Score:2)
It's certainly written in typical bureaucrat/lawyer speak but for individuals it's a clear improvement over the current state of affairs.
And guess who's bureaucrats and lawyers were involved. I would think the average or typical person could sit down and think, heck think while walking, that any breach of privacy by any entity would be liable for damages financial or otherwise caused by that breach as well as an amount X paid to those who suffered because of it. The disagreement I see is the amount of X.
A breach is a breach (Score:3, Informative)
Re: (Score:2, Insightful)
"The weakest link is usually not the computer engineering but social engineering anyway."
And that's why that exception is there - to protect the companies who have poor policies and weak personnel controls. How many doctors are walking around with their passwords on a sticky on the back of their ID badges? And how many even know policies against that exist, much less care about them?
It's like making the law.. (Score:3, Insightful)
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.
Re: (Score:1)
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 considerations I think were made regard more the protection of the "reputation" (if they have one to begin with) of the companies affected by shuch breaches. In my country they have made it illegal to publish anything about a bank if it can be denounced as a rumor, only to protect the "reputation" of those banks. Same principle applies for not reporting breaches.
Encryption methodology is defined (Score:5, Informative)
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.
Re:Encryption methodology is defined (Score:4, Informative)
There's an excellent overview by a law firm here:
http://www.faegre.com/showarticle.aspx?Show=8969
"Previously, covered entities were obligated to mitigate harm caused by unauthorized disclosures of protected health information, but not required to give notice to the individuals whose information was inappropriately disclosed. Going forward, covered entities and business associates will be required to notify individuals when security breaches occur with respect to "unsecured" information. Unsecured information means information not protected through technology or methods designated by the federal government. In addition, if the breach involves 500 or more individuals, notice to the federal Department of Health and Human Services and the media is also required."
Re: (Score:3, Interesting)
Quit trolling. If the access is to unencrypted data and that data is compromised, notification is required. The exemption for notification is only for "secured" data. Unencrypted data is not "secured"
Re: (Score:3, Insightful)
when the leak is an employee who has access to ALL of that data in its unencrypted form
Why would the system be giving an employee access to all the data in unsecured form? That'd be a mark of a very badly designed system. But if, "if" mind you, such a breach were to occur, the company wouldn't be eligible for getting out of notification.
Of course, the most likely weak-point is the legitimate end-users and their workstations. They have to have access (it's more important that they save the patient's life than keep their data secure) and you'll never persuade a large proportion of them to have
Re: (Score:2)
It's hard enough to convince them to have good actual hygiene...
Re: (Score:2)
Re: (Score:2)
We didn't give our end users the OPTION to ignore regula
Re: (Score:2)
The actual document (Score:5, Informative)
The actual document is here:
http://www.hhs.gov/ocr/privacy/hipaa/understanding/coveredentities/federalregisterbreachrfi.pdf [hhs.gov]
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.
Re:The actual document (Score:5, Insightful)
Congratulations, you're one of the few people that read the article or the document itself. My take on this is that if end-end encryption was used, meaning the actual files lost were still securely encrypted and the keys were not compromised, then the data owner does not have to report it as compromised data. Sounds reasonable to me.
The ACT is also a huge motivator for these agencies to implement encryption in a secure manner, thereby avoiding the whole mess that happens every time a laptop gets stolen and they don't know what files were actually on it.
Re: (Score:2)
Dream job (Score:2)
I want to be the guy that gets paid to make cool acronyms for the government. ARTEMIS and ATLAS could have been my words! EYE WIL GETT this JOB if it's the LAST thing EYE DO (I believe that had something to do with NASA...).
Re: (Score:2)
BOGUS = BOGUS Open Government for United States
Re:Dream job (Score:5, Funny)
Several thoughts... (Score:2)
2) Anyone who has worked in industries where encryption is "required" laughs scornfully at press releases like these. We'll see a rush of bandaid solutions to meet the mere minimum then, over time (say one year), even that minimum will be forgotten
Maybe I missed something (Score:2)
I'll admit I only scanned TFA, but it seems to me that the situation is this: If they use encryption, companies that failed to protect their data banks don't have to notify those most intimately concerned that the data has been illegally accessed. At the same time, the people who would steal data AND break the encryption are those who have a real intention of using it. It's a safe bet that the use they have in mind is not one the people most directly concerned would approve of.
So under this system, th
Encryption doesn't help (Score:3, Interesting)
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).
Re: (Score:2)
Thankfully all the data on the CDs was encrypted.
It was widely reported as "password protected". Whether that means the press (or the press office of HMRC) were dumbing it down for public consumption, or whether it was something considerably more fragile, who knows.
UK government agencies have become disproportionately paranoid about this kind of data loss now. On the upside, we now have mandatory examinations in data security. In our office, we have universal full-disk encryption and all writeable removable media is required to also be encrypted, enforced
It will apply to everyone (Score:2)
"More specifically (as explained here - PDF) only HIPAA-covered healthcare providers and health plans that omit the use of encryption or information destruction will be obliged to notify individuals about a breach of their personal health information."
I work for one of THE largest health insurance companies and I can say HIPPA is a FEDERAL law you don't have HIPPA covered and not HIPPA covered. If a provider is NOT abiding under HIPPA they are breaking the law. So in all actuality it will be anyone not empl
Re: (Score:2)
The commercial whole-disk encryption software we use works at the BIOS-level, rather than from within the OS. You can't mount the disks on a Linux system. Your statement that commercial encryption programs are for peace of mind rather than protection is a false generalization. Well-designed, well-implemented, *and* well-managed (must be all three) systems can provide excellent real protection of data.