Mass. Data Security Law Says "Thou Shalt Encrypt" 510
emeraldd writes with this snippet from SQL Magazine summarizing what he calls a "rather scary" new data protection law from Massachusetts: "Here are the basics of the new law. If you have personally identifiable information (PII) about a Massachusetts resident, such as a first and last name, then you have to encrypt that data on the wire and as it's persisted. Sending PII over HTTP instead of HTTPS? That's a big no-no. Storing the name of a customer in SQL Server without the data being encrypted? No way, Jose. You'll get a fine of $5,000 per breach or lost record. If you have a database that contains 1,000 names of Massachusetts residents and lose it without the data being encrypted, that's $5,000,000. Yikes.'"
Doesn't sound so bad (Score:5, Insightful)
That's pretty much already corporate policy at the last two major places I've worked for a few years now. It would be nice if the government starts treating that data the same way.
In fact, it would also be nice to mandate encryption and signatures for email so there will be no more unsolicited spam. And finally it would be great if no one was allowed to open up a line of credit without my cryptographic signature so I wouldn't have to protect my SSN, birthdate, and mother's maiden name like it was some sort of safety deposit box combination.
About fucking time. (Score:5, Insightful)
Now maybe if they actually enforce it businesses will get the idea that they should protect the data.
What's so scary about this? (Score:5, Insightful)
What is so scary about this?
With a high cost of PII, there is now an economic incentive for companies to actually give a rats ass. It's the same kind of incentive that is used to make sure companies don't just dump toxic chemicals in kindergarten sandboxes.
A pain to implement, but.. (Score:4, Insightful)
This seens pretty sensible. Given how many people are hurt by these things, this seems like a reasonable standard for future industry practice, and the fines hammer home the idea to the companies that "oops, sorry!" isn't the level of seriousness these things should be given. I imagine most of the time these breaches are against the privacy promises the companies make anyhow.
The only downside is that the fine is kind of daunting for people who would like to enter a relevant market, although .. perhaps it's analogous to car manufacturers being liable for poor design of their products - when they fail, it can be a big deal.
It's about time (Score:4, Insightful)
Re:What's so scary about this? (Score:4, Insightful)
I understand the need of encrypting credit card numbers, etc, but too much is too much.
In Sweden it is illegal to publish any information about who the owner of a vehicle is, for example. Yet, it is perfectly legal to send a SMS to the traffic authorities to get the same info. Go figure.
Scarier not to (Score:5, Insightful)
On the other hand, it's not clear what to do about the classic perimeter problem. Sooner or later, somewhere, the encrypted data has to be processed or presented in plaintext. The key and the data have to be brought together. Now we've converted the problem of securing the data to the problem of securing the key - probably many keys in practice - and the systems on which those keys reside - probably many systems.
Re:Doesn't sound so bad (Score:3, Insightful)
There are free encryption tools out there. The "headache" would probably be for IT, because Encryption means if you didnt back it up you lost it. If you forgot the PW, you lost it, if that person leaves and doesnt give you the PW, you can sue them, but you lost it.
One thing I have noted in my "small business" IT jobs, if you dont take IT seriously and stick them in a windowless room in the basement like you would a janitor, you will not succeed in your business. A small business treated me like I was a lost revenue instead of like a member of the company, they lost me and they regret it to this day. But this company is a medical billing business, where HIPAA was a daily worry. I figured it out.
Kind of went off on a tangent there, but the point is small businesses have it better than large companies. Its not hard to encrypt, its hard to keep track and train how to use.
Re:Doesn't sound so bad (Score:2, Insightful)
Yeah, it's way less damaging when your personal information is stolen from a small business.
Interestate Commerce (Score:2, Insightful)
~Article I, section 8, clause 3, United States Constitution.
THIS IS A FARCE (Score:5, Insightful)
Encryption in transit is great. Encryption of backup tapes is great. Encryption of end-user systems which store the data is great.
But encryption of live servers and databases is a farce. Encryption without key management is itself a farce, and a servers which require keys to operate necessarily lack key management. Furthermore, server encryption is absurd because it can only protects against physical theft of the servers, not against hacking.
The only case in which server encryption would do a bit of good is if the datacenter has no physical security, and every time a system boots, someone has to walk over to it and type a 20+ character random password.
Yes, I work in IT security. Yes, I think encryption is great, but NOT ON SERVERS.
Re:Doesn't sound so bad (Score:3, Insightful)
It seems like they really do mean just about everyone. Within a year we'll start seeing stories about how part-time small business people doing exactly what you described are the new source of major data breaches, because their Excel files and whatnot are being stolen via trojans and viruses
What is a neighborhood dry cleaner doing storing my credit card information and/or social security number in an Excel file anyway?
Personal Information Definition (Score:3, Insightful)
From the law, personal information is defined as:
Personal information, a Massachusetts resident's first name and last name or first initial and last name in combination with any one or more of the following data elements that relate to such resident: (a) Social Security number; (b) driver's license number or state-issued identification card number; or (c) financial account number, or credit or debit card number, with or without any required security code, access code, personal identification number or password, that would permit access to a resident’s financial account; provided, however, that “Personal information” shall not include information that is lawfully obtained from publicly available information, or from federal, state or local government records lawfully made available to the general public.
So just a first+last name isn't enough to incur the wrath of the law. It has to be that, plus SSN, Lic Number, or financial account number.
But from how I read that, it has to be the First name, Last name, Plus one of those. Does that mean I can store a list of social security numbers plus last names completely unencrypted and be off free? Odd
Re:THIS IS A FARCE (Score:2, Insightful)
Simple solution. Encrypt the sensitive information before storing it in the database. Leave all of the other information unencrypted. You don't need to search by the sensitive fields anyway, so the inability to index them doesn't matter.
Use filesystem/os level support for locking down the key on the system that needs to be able to decrypt it so that only the account/application authorized to access it can. That limits the vulnerabilities a single system. Even once on that system it is limited to "root" and the actual application.
Now you may safely let any number of insecure systems query your database. You can use trivial database backup schemes with no additional encryption. You don't need to worry about the physical security of those backups. Since you only need to backup the key when you first generate it, there is never any danger of the key and backup data being lost together in transit.
There is no speed penalty anywhere in the system except the sensitive parts.
Re:Not really (Score:1, Insightful)
Typical slashdot. Have to find the buried comment to find the truth.
Re:THIS IS A FARCE (Score:5, Insightful)
No, it also protects the rest of us against idiots who sell old hard drives on ebay.
Re:THIS IS A FARCE (Score:3, Insightful)
It's not even possible. The example the article gave of a thousand users is cute, as in, "awwwww that's so cute". I am pretty sure a lot of people in the real world are dealing with databases with +2 million records. Personally, I have dealt with over 250 million records.
One of the biggest failures people make just starting out is not planning to scale. That's why some low end database products grind to a halt getting above even 50k records.
There is simply no way with our current resources we could encrypt data in the individual fields in databases and maintain any level of performance with indexes, primary keys, constraints, etc. You might as well throw the ability to search out the window.
You are quite right about the hacking. Even if all of your data is encrypted that hardly protects you against an SQL injection attack.
Re:THIS IS A FARCE (Score:5, Insightful)
Encryption in transit is great. Encryption of backup tapes is great. Encryption of end-user systems which store the data is great.
But encryption of live servers and databases is a farce. Encryption without key management is itself a farce, and a servers which require keys to operate necessarily lack key management. Furthermore, server encryption is absurd because it can only protects against physical theft of the servers, not against hacking.
The only case in which server encryption would do a bit of good is if the datacenter has no physical security, and every time a system boots, someone has to walk over to it and type a 20+ character random password.
Yes, I work in IT security. Yes, I think encryption is great, but NOT ON SERVERS.
Agreed. I'm a MySQL guru (among other things), and I can't see keeping names and email addresses encrypted in the database on the server. Credit card numbers and other sensitive foreign account numbers? Absolutely. But what they are asking for is a joke. And what? The entire world would have to change how it stores things on its servers just to appease Massachusetts? Gee, if every territory starts lubbing its own rules about how the world should handle data of its residents/citizens, you can just kiss the Internet good-bye.
What this all means though is that the small startup/merchant/mom-and-pop Internet operations will find it more and more expensive to swim in these waters infested with little fiefdoms everywhere with delusions of hegemony.
Then again, it's always dangerous when politicians -- especially local ones -- try to legislate anything on the global Internet. Some years back some idiot New Hampshire legislature tried to impose a tax on -- are you sitting down? -- email. Can you believe it?
I'd like to see them help out (Score:2, Insightful)
Re:THIS IS A FARCE (Score:2, Insightful)
Sounds to me like the fines only apply if the data is actually compromised. The obvious answer would be: Don't let that data get compromised!
Re:THIS IS A FARCE (Score:5, Insightful)
I agree 100% with you. Encrypting is very important, but more important is UNDERSTANDING what encryption is. This guys think if you magically apply DSA/Elgamal over your data, then it's secure. It's the same kind of delusion that development companies have with DRM. They added an if() somewhere on their code that checks a stupid key, and they believe that keeps them safe. It doesn't matter how much you encrypt your data, if you are going to access it eventually in an automated way, that is not going to protect you in any way. Encrypting the data and hardcoding the key on your app means nothing.
Also, keeping certain information encrypted on the DB is just crazy. Doing a complex JOIN with multiple tables and a few LIKEs when you have a table with 200 million records is complex and resource intensive enough, adding encryption in every motherfucking field to that is only adding insult to injury.
I manage a pretty complex setup of distributed asterisk servers, with replicating SQL DBs across 3 countries. CC data is only stored on the US server, and the key to decrypt them is not on the server, it's stored securely on another workstation, encrypted with yet another 4096 DSA/Elgamal key that I only have on yet another location. I only enter it once a month for billing purposes, and it only stays in RAM as long as the server is processing the monthly payments. I am a conscious coders, and I take privacy and security very seriously, but this law is just ridiculous.
Re:THIS IS A FARCE (Score:3, Insightful)
What this all means though is that the small startup/merchant/mom-and-pop Internet operations will find it more and more expensive to swim in these waters infested with little fiefdoms everywhere with delusions of hegemony.
What, you thought this law was passed for some purpose other than that? Laws like this serve two purposes: One, to be able to put a sound bite into ads and two is to help big companies keep small competitors out of the field.
Re:THIS IS A FARCE (Score:1, Insightful)
Ten seconds in a microwave destroys every piece of information on the platter with barely a harmful effect to the environment and at a minimal amount of power required!
Every office in America, if not the world, has a microwave.
It's what I do when I toss out ANY hard disk.
I couldn't disagree more (Score:5, Insightful)
I'm sorry, but I strongly disagree with your position on almost every count.
Firstly, your point about different territories with different rules is fundamentally flawed. Many places — all of Europe, for example — already have stronger data protection laws than most of the US. This causes no earth-shattering problem with compliance. Large companies keep the data they can't legally export within their European offices. Smaller companies just outsource things like payment collection to services that guarantee any personal data will be processed securely and not transferred outside of EU borders. They were going to outsource it anyway, so the only people who lose out are services that want to handle sensitive information but can't make the same guarantees as others about security, whose flawed business model just became obsolete.
Secondly, I think you (and several other DB admins and such in this Slashdot discussion) are far, far too casual about this subject. In my country, we have had a string of mismanagement or outright leaks of sensitive personal data in recent months. The number of people who have wound up losing money or suffering long-term hassle just to set their records straight is absurd, and rising every day. A $5,000 fine per leak is nothing compared to the hassle and indirect costs of someone suffering identity theft, even if they get everything put right in the end and recover their direct losses. To one side, it's several months of hell to get your identity back. To the other, it's a mere business expense, a footnote on page 172 of the annual financial statement.
In my not so humble opinion, both business and governments need to learn this lesson, and I have absolutely nothing against sending a business to the wall if it collects personal information but fails to secure it properly. We have allowed more-or-less unrestricted collection of personal data for a few years, easily long enough for the industry to gets its act together. The result has just been organisations hoarding personal information about people for reasons that are entirely self-serving, pretty much all of whom could just die and make the world a better place anyway, and the string of screw-ups I mentioned before from many organisations that do have a legitimate reason to hold that sort of data.
It is time for organisations that think this is OK to be taught otherwise, and frankly these fines are on the light side. I would have preferred an additional statutory duty of care with unlimited liability to cover the cost of putting right any damage done to an individual following a leak. Go ahead and reevaluate your security protocols and whether it is really impossible to do these things or just inconvenient/expensive, when the other side of the inequality you're testing looks like an 8 on its side instead of a $10 per person class action settlement.
Re:THIS IS A FARCE (Score:3, Insightful)
Re:THIS IS A FARCE (Score:2, Insightful)
Complexity such as that actually reduces security. Since managers and developers believe the 'compartmentalization' will save them, they are less concerned about writing secure code, due to risk compensation, they wind up with something less secure than if they had not encrypted DB data.
Compartmentalization of that nature is just one of those things that sounds cool but has not been shown to actually tangibly improve security in reality.
Increased complexity and poorer review of DB schema and database contents, that results from the additional complexity, can lead to poorer app performance, and more DB-related security issues slipping through the cracks.
In other words compartmentalization has a chance of improving security slightly in some cases, but in many cases it is very likely to have a negative impact on overall security, resulting in a less secure situation (although you will definitely feel more secure, even though you aren't, since you have shrouded your internal DB with an added layer of security --- which by the way, will make it hard even for the company themselves to analyze their own database and detect certain types of attack attempts).
Re:THIS IS A FARCE (Score:3, Insightful)
1) corporations typically don't resell old hard drives that were once in servers. Many of them get returned at lease end, the rest are of little value as used components having run constantly for 4-8 years under load.
2) Most server HDDs don't go in computers. We use almost exclusively FC and SCSI disks, and a lot of SAS now as well. These drives are 10K or 15K, make a shit load of noise, and
3) RAID controllers obfuscate the data. You'd need a near complete RAID set to be able to reconstitute the data after buying or finding a used disk drive. If the disks were in a SAN chassis, it;s even worse as deduplication, horizontal and vertical striping, and thin provisioning make it virtually impossible to rebuild the system from a collection of disks unless you had the entire SAN system (which are never resold, they're almost always on lease, or are bought out and used as back-end systems for low priority data or copies of data.
4) Under HIPAA, SOx, DOD STIGs, and more standards, HDDs that contained PHI, PCI, or other sensitive data must be scrubbed to government standards before being disposed of. For us, that means full electronic erasure using an approved government tool, followed by drilling not less than 3 holes in the platters!
This standard makes sense for laptops and other portable systems and databases. It also makes sense for backups, which are mostly linear data and easy to decipher with the right drive and software. You'll also notice the law if written to fine people for BREACH, LOSS, and EXPOSURE, but says nothing about fining corporations that simply do not "comply" with the standards. The data actualyl has to be lost in order to be fined. We DO use secure authentication systems (dual factor for most PHI data access) and regardless of whether or not the SQL, DB2 or Oracle systems were encrypted, if the user authenticates, the server will happily decrypt and access the data.
What would have made a lot more sense for MA in this case was simply to demand stict data access (physical) requirements, background screenings, corporate policy for drive and tape and serer disposal and scrubbing, but then, they'd not be doing anything the federal government did not already require for those of use hosting medical, credit card, or other private and secure data... We're already bound by these standards...