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.To Continue Reading: Click Here --------------------------------------------- Source: sqlmag.com By: Brian Moran 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.

Read the full story originally posted by EDD Blog Online.