Several months ago, Massachusetts passed a sweeping new data security law that will have a profound impact on the way the United States, and perhaps the rest of the world, manages and develops data-centric applications. Oddly, most people in the business and technical communities don’t seem to know about it.
I addressed this law a few months ago, but made a few errors in my reporting on the actual law, so we pulled the article from the SQL Mag website. I’ve addressed my original mistakes and added a number of new thoughts and perspectives as well. No need to worry about reading the old article; this piece stands on its own.
Google “Massachusetts data security law, 201 CMR 17.00” and you’ll find plenty of facts about the new law. I also encourage you to read Information Week’s "States' Rights Come to Security Forefront: Massachusetts' new data protection law reaches beyond its borders. Are you ready?" It’s one of the better summaries I’ve seen. However, even it falls short of helping you understand the profound affect this law could have. You can read the full law at www.mass.gov/Eoca/docs/idtheft/201CMR1700reg.pdf.
Key aspects of the law revolve around its definition of Personally Identifiable Information (PII) and situations in which the data needs to be protected through encryption. The law defines PII as “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 “and requires “Encryption of all transmitted records and files containing personal information that will travel across public networks, and encryption of all data containing personal information to be transmitted wirelessly.”
Many people read that statement and, at first glance, believe that the scope of data applications covered is perhaps small. I disagree. Why? First, let’s explore the core attributes of PII. Clearly almost any data set about a person will contain first and last name, so the attributes of social security number (SSN), driver’s license, and “financial account number” become the linchpins of whether a data set meets the definition of this law. Yeah, I know we’re supposed to protect SSN and it probably shouldn’t be embedded in customer data sets “just because.” But the fact remains that SSN is pretty ubiquitous as a primary key in many customer-centric applications. Do you know for sure which of your applications use it now or might in the future? Probably not, so you’ll need to err on the side of caution. But the financial account number reaches much further. No, many of you applications might not contain customers’ bank account numbers or anything that obvious, but most of your customer data sets will contain the person’s email address right? You might think that an email address isn’t a financial account number, but I’ve explored this topic with several knowledgeable people in the legal and policy space and many of them agree that an email address could very well be seen as a primary account number. For better or worse, it’s becoming more and more common to use an email address as the primary customer identifier, especially for online services. In many cases, compromising a person’s email address could indeed allow access to accounts that might contain financial information of one kind or another.
Now let’s consider “information that will travel across public networks, and encryption of all data containing personal information to be transmitted wirelessly.” Do you use public networks for most of your apps? Do you have executives who travel and hit applications behind your firewall from the airport or a hotel? Are most of your applications are transmitted over wireless networks? Do you have people who work from home? Do you think that most people know how to secure their wireless networks? If they did, Google wouldn’t be having the global issues it’s facing today over inadvertently capturing information from public and private wireless networks.
In my opinion the issues above will require you to assume that most of your applications are all ready subject to the law or will at some point in the future. Either way you should effectively plan on being compliant with the law. You might not have any customers or employees living in Massachusetts currently, but I believe the law will require most applications to be developed in a way that complies with the law even if you don’t currently have data about anyone in Massachusetts.
What are the consequences for failing to comply? You’ll be fined $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.
Perhaps just as much fun is the fact that to be compliant with the law your company will also need to maintain a Written Information Security Plan (WISP) and file it with the state of Massachusetts. The WISP must address and outline your business’s “technical, administrative, and physical safeguards” that are in place to protect the data. If you lost a laptop without a WISP being filed with Massachusetts, you’re potentially on the hook for a cool million dollars, even if the data was encrypted. If I didn’t know better, I’d think the security czar of Massachusetts (or whatever the title is of the person who wrote this law) was a SQL Server sales executive because the law could sell a heck of a lot of SQL Server 2008 Enterprise Edition upgrades to get Transparent Data Encryption and other useful Enterprise Edition–only features in the OS and database stack.
Is protecting data really such a bad thing? Of course not. The barrage of news stories highlighting customer account breaches makes it clear that customer data must be better protected. But here’s a bigger question: Should Massachusetts be the sole arbiter of the rules in the USA? Other states are talking about similar legislation. What if all 50 states had their own rules? Amazon and EBay might be able to keep up with the laws, but I’m guessing that the vast majority of companies that do business in the United States simply wouldn’t be able to keep up with a patchwork of overlapping, and perhaps conflicting, state mandates. Companies wouldn’t say, “I’m out of business.” Instead, it would be impossible for them to comply with the rules, or perhaps even know what the rules are, so they would be engaged in business at risk of substantial fines, penalties, and lawsuits. And since the companies would largely be ignoring the rules, customer data probably wouldn’t end up being protected any better.
In general, I’m in favor of states’ rights and limited government intervention in commerce. However, I feel this is truly a case in which the US federal government’s power to regulate interstate commerce should be invoked. Forcing business to deal with a patch work of rules and regulations that will affect almost every application they build in the future isn’t a pretty scenario. What do you think?
By the way, check out msdn.microsoft.com/en-us/library/cc278098.aspx for a nice review of SQL Server 2008 Enterprise Edition security features compared and contrasted to other ways to encrypt data on a Microsoft data stack.
