Data Security for Payment Card & Social Security Numbers?
Bills pending in the Michigan and Washington state legislatures would mandate that personal information stored in business computers be “encrypted.” Legislatures are unwise to engage in such mico-management.Pending Michigan Senate Bill (SB) 1022 would forbid a business from storing personally identifiable information in a database unless the information is encrypted. Similarly, in Washington State, pending House Bill (HB) 2574 would mandate that a business employ encryption when storing personal information on an Internet-connected computer server.
When a legislature specifies a technology like "encryption," it goes beyond stating a goal and requiring that the goal be met. The legislature selects the precise technical means for reaching the goal. In other words, when a legislature dictates technical measures like "encryption," it assumes the role of a professional engineer. But state legislatures are not qualified to provide professional engineering services!
Encryption is a powerful data security tool. But it is not necessarily always the best way to achieve a data security goal. The successful implementation of encryption in a specific setting involves many issues and tradeoffs. For example, a panel of security experts recently pointed out that the encryption of data in storage (as opposed to data in transit) raises vexing questions about the key infrastructure that underpins the encryption. When an enterprise encrypts lots of its stored data, a hacker has incentive to attack the encryption scheme's key infrastructure. If the hacker can defeat the key infrastructure, she can deny the enterprise access to its data. That means the hacker can put the enterprise out of business, or blackmail the enterprise. Thus, the indiscriminate use of encryption may increase the overall social risk associated with stored private data.
Data security is a complex field of engineering. State legislatures should steer clear of it.
In 1995 the Utah legislature adopted pioneering legislation to stimulate growth of public key infrastructure. The legislature received lots of detailed advice from experts. The legislature crafted legislation that was very technically specific. At the time, and for several years thereafter, some experts hailed the Utah legislation as a model and as a great catalyst for e-commerce. However, it is safe to say today that the Utah Digital Signature Act was an absolute bust. It achieved none of its goals. It was far too technically specific to be of any value to industry.
The Michigan and Washington legislatures should remember the Utah experience as they draft legislation. A wise legislature might require, for example, that businesses use "reasonable security procedures" (a general goal) rather than that they use "encryption" (a specific technology).
Update: Here's a simple example of why legislatures have no business legislating words like "encryption." In Indiana newly-enacted House Bill (HB) 1197 (aka Public Law 136) tries to define "Breach of the security of a system". One of the ways HB 1197 achieves its definition is by telling us what a breach of security is not. It says security has not been breached if data have been encrypted and the "encryption key" has not been compromised. Hmmm. Doesn't that sorta make sense? . . . But wait. Does it always make sense? What about a public key cryptosystem? Public key cryptosystems can be used effectively to encrypt data and keep it private. Sometimes in a public key system, it is not the protection of the encryption key that protects data privacy. Sometimes it is protection of the decryption key that protects privacy! For purposes of certain legitimate applications a public key cryptosystem, the drafter of HB 1197 seems to have missed the boat completely.
--Benjamin Wright
Mr. Wright is an advisor to Messaging Architects, a company with fresh thinking about electronic records management.
Update: See my analysis of a breach notification where data on a stolen laptop are encrypted.
[Footnote: In this post I mentioned the laws (or proposed laws) of some states. Please understand that when I blog about the law of a state like Indiana, I have not necessarily researched all the relevant regulations and rulings in that state. And whatever I say here could easily be out of date. So if you need a reliable legal opinion about the law of any state, you need to go some place else to get it. Also, the fact that this post does not mention any other state -- Florida, California, New Jersey, Illinois, Missouri, whatever -- means nothing. Other states may have encryption laws that I've not mentioned.]
Posts
11 comments:
Michigan SB 1022 and Washington HB 2574 appear to be unique to the extent that they require encryption of data at rest (data in storage). Earlier legislation, Nevada NRS 597.970, requires encryption of data in motion (data in transmission).
Note also that Michigan SB 1022 is similar to Minnesota's HF 1758. 1022 requires a merchant to reimburse the costs that banks incur when they replace credit cards in the wake of a data breach at the merchant.
It's not like the database owners are likely to have direct control over the data storage format. On purchased systems, they are at the mercy of what the database and application vendors support.
Also, language like "stored in a database" is pointing to only a section of the issue. While direct attacks on the database happen, a fair amount of the exposure incidents are theft of backup media. Many times database backups aren't mere images of the database files but extracts of one form or another. Depending on methods, an encrypted database may yield an unencrypted backup. There are solutions for that too but now your key handling kicks in.
Key storage isn't just and attractive target, it's complicated to manage. You can't store them on the servers being backed up (the equivalent of locking your keys in t he car). If you use offsite storage, you have to ensure some reasonable offsite storage and transportation to storage of the keys. No good to have encrypted tapes if the encryption keys are sitting on the tape or other media next to it.
As a state employee, I have no issue with encrypting data, both during the transfer and in the database. Yes it is important to properly secure and store your keys and that in itself can be challenging. I do not think it is too much to ask states to be responsible for the data they 'own'.
I agree to some extend. Regarding encyption of information in databases: Transparent encryption makes sense only in very rare cases. If data is stolen from the database, it's mostly due to vulnerabilities in applications like SQL injection. In this case encryption does not impede an attacker from copying the data at all.
Storing information like passwords as hashes that makes gaining the plaintext very hard is however badly recommendable.
It's important to find the right granularity for legislation to mandate encryption. Demanding things that do not make sense is rather harmful than wise.
"Data security is a complex field of engineering. State legislatures should steer clear of it." - agreed except maybe that it is not so much engineering job but a design job for business and infrastructure. Good key management is a magnitude more difficult than the encryption and other security issues. And unfortunately too often an afterthought. NIST has some very good recommendations and requirements (FIPS) on that.
Hi Ben,
(I want to apologize, I accidentally emailed you this message instead of posting on your blog -- you can disregard the email since I corrected typos on this one anyway.)
I can see where you are comming from, at least legally, though I don't agree with you. I would rather my data be lost than have someone else compromise it...
As someone who uses full disk encryption, (and not under Windows or Mac) I can tell you that if a company can't even be bothered to set up such a configuration, I would not be very at ease with them storing my information. (and I wouldn't be at all surprised if the majority of the websites that I store my information on have abysmal security) For that reason, I try to store as little information on third parties (and that includes non-internet services) as practically possible. Emphasis on the "practical" part.
Who knows how many unencrypted social security numbers of mine that are lying around? I can only wonder if for example, my university clears every sector at least once on their hard drives before throwing them away. I doubt it... At least if these drives were encrypted it wouldn't be an issue.
Encryption isn't that hard to set up, and while Windows implementations might not be up to par, (this is my argument with a post on Wired you responded to, and yes I had been thinking about that issue long prior to reading that article) I have difficulty trusting an organization that uses power management for a server, or something storing a database of critical user information.
I'm not saying that full disk encryption is for everyone, but I think that companies and the government really should be encrypting their data.
"A wise legislature might require, for example, that businesses use 'reasonable security procedures' (a general goal) rather than that they use 'encryption' (a specific technology)."
I completely agree with your statement for one specific reason. Information security is a process and not an event. Requiring businesses to use a specific technology solution such as encryption leads us down the path of "event" rather than process. Therefore I like the way you word it "reasonable security procedures" because this is more encompassing than a specific solution and leads us down the path of "process" rather than "event".
johndavidbaker.blogspot.com
The original data breach law stated: "Unauthorized acquisition of a portable electronic device on which personal information is stored, if access to the device is protected by a password that has not been disclosed." What you're telling me here, is that you think that this change is for the worse?
I'm sorry, despite the fact that the government should not try to define what a breach is not, anything was a heck of a lot better than a password protected device.
johndavid baker, I agree that information security is a process and not an event. I do not however believe that this in any way demonstrates that encryption should not be a specific requirement.
Encryption (like any other technology tool) comes with it's own risks and responsibilities but it is open source and s available at a wide number of levels and types. There is significant freedom of choice within encryption (which is the greatest risk reduction tool widely available) to leave companies and people in charge of their data despite any overall encryption requirement.
Fran Kavanagh
http://www.backupanytime.com/whitepaper.htm
Fran: Thank you for commenting thoughtfully. You said, "There is significant freedom of choice within encryption," but that is not true for purposes of satisfying Indiana's Public Law 136 (described in my post above). The Indiana legislature ignorantly dictates the the type of encryption that must be used (i.e., encryption that depends on protection of the encryption key) and acknowledges no other type of encryption. --Ben
Post a Comment