ActiveBlog

Massachusetts mandates data security sanity
by Troy Topnik

Troy Topnik, April 28, 2010

Don't panic. SQL Server magazine published “A New Law Could Change the Way You Build Database Applications” a few days ago which gives the initial impression that all of us in the industry have a lot of work to do to comply with Massachusetts’ new legislation on personal information security.

Commenters on Slashdot and reddit were quick to label the piece as FUD for peddling SQL Server, but I’ll give Brian Moran the benefit of the doubt and assume he didn’t knowingly misinform his readers. Here are some of the critical mistakes though:

What is “Personally Identifiable Information”?

…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…

STOP! That’s not what this law is about. It concerns the pairing of publicly available personal information (e.g. someone’s name, which might be available in the phone book), and sensitive information such as a Social Security number, a driver’s license number or a credit card number.

Storing data

Storing the name of a customer in SQL Server without the data being encrypted? No way, Jose.

Actually, go ahead Jose. As mentioned above, we’re not talking about a persons name, we’re talking about private information linked to that name. But futhermore, the law makes no requirement that you have to encrypt that information in your database as long it’s stored securely. If your database server is in a physically secure location, and you’ve taken reasonable (they use that word a lot in this law) efforts to restrict physical and electronic access, you’re square with this law.

The law does require encryption of such data on portable devices and public networks, which is a very, very good idea.

What-’o-the-WISP?

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.

There’s no mention in the law itself of having to file anything with the state of Massachusetts. The accompanying Compliance Checklist and Small Business Guide talk about what a WISP is and what it should include, but they don’t mention anything about submitting it anywhere.

Who should be concerned?

If I didn’t know better, I’d think the security czar of Massachusetts … 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.

Wow. I take it all back. This is definitely FUD.

As far as I can see the only people who should be nervous about this legislation are those who have been treating sensitive information carelessly up till now. I’m going to take a step further and say that this is good legislation. It’s only four pages, the legalese is not too thick, the regulations mirror industry best practices, and the penalties are reasonable (though some would say much too light) considering the kind of damage identity theft can cause.

It’s annoying that it has been implemented at a US state level (if all states enacted similar legislation, you’d have 50 different sets of rules to keep track of), but the law itself seems sane to me. As our sysadmin succinctly put it: “It looks like a sudden outbreak of common sense.”

If you are in the business of handling confidential personal information and don’t already have a “Written Information Security Plan”, you should probably look into drafting one. The Massachusetts Office of Consumer Affairs and Business Regulation has also done an pretty good job of providing supporting information to help people comply with the new regulations.

Aside: If you’re interested in encryption, Mike Ivanov has put together some great posts on Python cryptography.

Tags: , , , , ,

Subscribe to ActiveState Blogs by Email

Share this post:

About the Author: RSS

Troy Topnik is ActiveState's technical writer. After joining ActiveState in 2001 as a "Customer Relationship Representative" (AKA Tech Support), Troy went on to lead the PureMessage Enterprise Support team before moving on to a technical writing role in 2004. His talent for describing software for new users stems from his difficulty understanding things that developers find obvious. He has a Bachelor of Music from the University of Victoria.