It has been a few days since the latest amendment and delay evisceration of 201 CMR 17.00 was announced and it is time to take another look and give it a fair review. Besides the raw documents I recently posted, I strongly urge you to head over to David Navetta's post at InfoSecCompliance.com, he makes some very good points and 
clears up several changes. While you're there, review their redlined PDF version of the regulations- I think you'll agree that red is appropriate given they way the 201CMR17.00 has been butchered over time.
There are several points which frustrate me in the updated version, but I will limit my comments to a few (I tried for a few, it appears several is a better description of the result). Note that emphasis in text excerpts is mine, added to highlight my points.
First, the definition of encryption has changed from:
"the transformation of data through the use of an algorithmic process, or an alternative method at least as secure, into a form in which meaning cannot be assigned without the use of a confidential process or key, unless further defined by regulation by the Office of Consumer Affairs and Business Regulation."
to
"the transformation of data into a form in which meaning cannot be assigned without the use of a confidential process or key."
"Confidential process" and "cryptography" is a pairing destined for failure, and a password is a key, right? You and I may understand the difference between "encrypted" and "password protected", but I assure you that this will lead to many people blurring the two and not encrypting their data when required, or doing it badly- and the state has provided them with a plausible excuse by this definition.
Second, the previous version stated in 17.03 (1)
"Every person that owns, licenses, stores or maintains personal information about a resident of the Commonwealth shall develop, implement, maintain and monitor a comprehensive, written information security program..."
It now states
"Every person that owns or licenses personal information about a resident of the Commonwealth shall develop, implement, and maintain a comprehensive information security program that is written..."
While the words "stores or maintains" are missing, I think those are covered adequately elsewhere- it is the loss of the word "monitor" which concerns me. Make a plan, print it out, and put it on the Shelf of Neglect with the others. Sure, the FAQ says you need to monitor your plan, but the regulation doesn't, and that's what counts.
The next one might not be that bad, 17.03 (3) 5. before:
"Preventing terminated employees from accessing records containing personal information by immediately terminating their physical and electronic access to such records, including deactivating their passwords and user names."
And after, 17.03 (2) (b) 3. (e)
"Preventing terminated employees from accessing records containing personal information."
Or, the removal of strong language might give the impression that "immediately" "physical and electronic" aren't that important. That would be bad.
Now for a series of outright attacks on security fundamentals and common sense guidelines, 17.03 (3) 7. stated
"Limiting the amount of personal information collected to that reasonably necessary to accomplish the legitimate purpose for which it is collected; limiting the time such information is retained to that reasonably necessary to accomplish such purpose; and limiting access to those persons who are reasonably required to know such information in order to accomplish such purpose or to comply with state or federal record retention requirements."
The corresponding section of the current regulations is
Missing
That's right, the common sense suggestion to only keep the data you need is gone. Forget the logic of "you can't lose what you don't have", go ahead and keep anything you want.
Also missing is the section corresponding to 17.03 (3) 8.
"Identifying paper, electronic and other records, computing systems, and storage media, including laptops and portable devices used to store personal information, to determine which records contain personal information, except where the comprehensive information security program provides for the handling of all records as if they all contained personal information."
This is an absolute fundamental tenet of any kind of security/protection program, and has always been- if you don't know what you have and where it is, you cannot protect it. Read through breach reports and you will find that data is routinely lost from places that weren't documented. Yes, a data inventory and classification project is likely to be painful, expensive and imperfect. That doesn't make it any less fundamental or necessary.
Section 17.03 (3) 9. went from
"Reasonable restrictions upon physical access to records containing personal information, including a written procedure that sets forth the manner in which physical access to such records is restricted; and storage of such records and data in locked facilities, storage areas or containers."
To this in 17.03 (2) (g)
"Reasonable restrictions upon physical access to records containing personal information,, and storage of such records and data in locked facilities, storage areas or containers."
Because the old political advice of "never write what you can say, and never say what you can wink" is the best way to handle policies, too. Or not.
Some of the items removed from 17.03 are listed in the computer security sections, 17.04- but that means those protections are not required for the physical world, only the digital.
As long as I am on a roll, let's poke at the FAQ, too. Besides confirming some of the above, the FAQ offers a few items I find especially problematic. First,
"Technically feasible” means that if there is a reasonable means through technology to accomplish a required result, then that reasonable means must be used."
Odd that a regulation which has been altered to "ease the burden" on businesses doesn't provide an economic escape clause- as written "technically feasible" includes solutions which may be prohibitively expensive. But don't worry, there are enough weasel words in this to allow an out somewhere.
Also from the FAQ, two truly horrifying things:
"Must I encrypt my email if it contains personal information?
If it is not technically feasible to do so, then no."
Per the previous definition of "technically feasible", email encryption is absolutely feasible. Also, this fails to address the simple solution of encrypting the sensitive information and attaching it to a message. Between the ubiquity of Microsoft Office and the free and cross-platform availability of OpenOffice, there is no excuse for not encrypting PII sent via email. Reality and intent aside, expect to see this used to shoot down email encryption proposals on a regular basis.
And this nonsense:
"Do all portable devices have to be encrypted?
No. Only those portable devices that contain personal information of customers or employees and only where technically feasible The "technical feasibility" language of the regulation is intended to recognize that at this period in the development of encryption technology, there is little, if any, generally accepted encryption technology for most portable devices, such as cell phones, blackberries, net books, iphones and similar devices. While it may not be possible to encrypt such portable devices, personal information should not be placed at risk in the use of such devices. There is, however, technology available to encrypt laptops."
It scares me to think someone in state government wrote this. Starting with the obvious targets- BlackBerries can be encrypted with minimal effort from the handset or via policy using a BlackBerry Enterprise Server. Nothing to it, really. Netbooks have BIOS and drives just like "real" computers- from the free and Open Source TrueCrypt through many commercial offerings, they are easy to encrypt. Other devices can get tricky, but Symbian-based phones support encryption. iPhones, well, Apple would tell us "there's an app for that", and even though we have learned that the built-in encryption for iPhone 3gs is nearly worthless, it probably still meets the requirements as currently written. Once again, reality notwithstanding, expect this blurb as a counterstrike to any suggestion of portable device encryption.
Maybe I need to look at it fresh, as if there had never been prior versions. Perhaps then it would look like a good start? Since the trigger for getting the parent law, 93H, passed was the TJX breach, would the current 201CMR17.00 have done anything to prevent that attack? No, it wouldn't. WEP is encryption, and this mess has enough wiggle room that I expect even the sadly broken WEP could stand up to 201's feeble scrutiny. What about other high-profile cases, such as Heartland? 201 doesn't require competent CEOs, web application code review, or web application firewalls; even the much-maligned PCI-DSS requires two of those three, and stopping simple SQL injection would have at least slowed down many recent attacks.
Now, for an immodest proposal, with no chance of passing (passing, as it would require a change in the law, 93H): forget all the prescriptive regulations and create specific and substantial penalties (financial and imprisonment) for failure, and make sure private lawsuits are expressly allowed. Let's put the RISK into this risk-based approach. (Yes, I understand that would drive some to try to keep their failures secret, but it will never happen anyway). I didn't suggest what I really want for 
punishment, though...
Jack
