Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Perimeter

6/8/2010
11:49 AM
Adrian Lane
Adrian Lane
Commentary
50%
50%

Massachusetts Data Privacy Standard: Comply Or Not?

In my previous position at a database security vendor, I was often asked by marketing to explain the applicability of technology to problems: how you could use assessment for PCI compliance, or why database activity monitoring was applicable to privacy laws, for example.

In my previous position at a database security vendor, I was often asked by marketing to explain the applicability of technology to problems: how you could use assessment for PCI compliance, or why database activity monitoring was applicable to privacy laws, for example.Invariably, the papers I wrote mirrored what every vendor does: create a logical explanation of how bits and parts of the security product addresses compliance challenges. But however logical, this misses the real-world issue of motivation.

A given security widget may genuinely address a regulation. It may even be the best method to meet compliance, but that is irrelevant if the customer does not view compliance as mandatory. Why would they spend money on a product to address a problem they don't acknowledge?

It is for these reasons that I make fun of myself when reading my older white papers, as I now ridicule all vendor justification papers: The grand philosophical arguments are trumped by business realities.

I got to thinking about this when the Massachusetts data privacy standard 201 CMR 17.00 was put into effect in March. Every vendor rolled out its perspective on how it addresses the "challenges" of this new regulatory requirement. Customer questions about the importance of this regulation -- how they might comply with the law, and how they estimate what they are willing to pay for solutions -- are still very much up in the air.

I use Sarbanes-Oxley as an example to illustrate what I mean. In 2005, I learned directly from a dozen Fortune 500 CEOs that they had no intention of complying with SOX: They would first wait to see whether the law would be repealed. If it was not repealed, then they would wait to see whether the regulation was going to be enforced. If it was enforced, then they'd weigh the fines versus the additional auditing costs. Would it be cheaper to legally challenge the law? They would re-evaluate two years down the road, and if they found they needed to comply, then they would throw up their hands, say "mea culpa," and provide their remediation plans.

There were layers of business risk analysis that occurred long before they dug into understanding and reporting financial accounting risks. HIPAA was no different. I am betting Massachusetts data privacy standard 201 CMR 17.00 falls into the same category of "wait and see."

Companies will wait for a while before starting a compliance program. Once a business conducts the evaluation of its security risks to sensitive data, it's somewhat compelled to act if it finds something bad. It's one thing to claim you were not sure if there was a risk or did not think the law applied to you. But it looks really bad in court, after a breach has occurred, if you were aware of the risks and did nothing. So the mindset is that it is best to remain ignorant altogether.

The logical part of my brain loves that the Massachusetts privacy law tasks companies with understanding their data security risks. Risk is something they understand. The regulation specified that you will build a security plan around challenges specific to your organization's risk, looking at both the data and systems that manage data. There is no encryption loophole for companies to excuse sloppy security. They will have a tough time blaming data theft on product vendors if they select the wrong product or scapegoat IT if they do not respond to discovered risks. I think this law makes meaningful advancements in data security requirements, and I like to think that companies that make money from personal information should have some custodial responsibilities to the safety and security of other people's information.

So I was thinking, "Great, I'll write a justification piece for database security." In practice, social security numbers, driver's license numbers, passwords, and other personal information are being stored in relational databases. 201 CMR 17.00, HIPAA, and many of the regulations don't call out database security specifically, but relational databases are the primary storage management system for this data. My intention when starting this blog post was to outline a plan to understand risk, and outline how auditing, assessment, DAM, encryption, access controls, and application programming can be applied to meet different threat types. I may still do that, but the question remains whether companies will actually take action to understand the risks. Is this law actually a business driver?

If you want to see a security program outline for meeting Massachusetts data privacy standard 201 CMR 17.00, then I would be happy to post here on the blog. (Let me know via the "Comments" box below).

But I think a discussion about whether this law will be taken seriously needs to happen before we decide how to comply.

Adrian Lane is an analyst/CTO with Securosis LLC, an independent security consulting practice. Special to Dark Reading. Adrian Lane is a Security Strategist and brings over 25 years of industry experience to the Securosis team, much of it at the executive level. Adrian specializes in database security, data security, and secure software development. With experience at Ingres, Oracle, and ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Data Leak Week: Billions of Sensitive Files Exposed Online
Kelly Jackson Higgins, Executive Editor at Dark Reading,  12/10/2019
Intel Issues Fix for 'Plundervolt' SGX Flaw
Kelly Jackson Higgins, Executive Editor at Dark Reading,  12/11/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
The Year in Security: 2019
This Tech Digest provides a wrap up and overview of the year's top cybersecurity news stories. It was a year of new twists on old threats, with fears of another WannaCry-type worm and of a possible botnet army of Wi-Fi routers. But 2019 also underscored the risk of firmware and trusted security tools harboring dangerous holes that cybercriminals and nation-state hackers could readily abuse. Read more.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-5252
PUBLISHED: 2019-12-14
There is an improper authentication vulnerability in Huawei smartphones (Y9, Honor 8X, Honor 9 Lite, Honor 9i, Y6 Pro). The applock does not perform a sufficient authentication in a rare condition. Successful exploit could allow the attacker to use the application locked by applock in an instant.
CVE-2019-5235
PUBLISHED: 2019-12-14
Some Huawei smart phones have a null pointer dereference vulnerability. An attacker crafts specific packets and sends to the affected product to exploit this vulnerability. Successful exploitation may cause the affected phone to be abnormal.
CVE-2019-5264
PUBLISHED: 2019-12-13
There is an information disclosure vulnerability in certain Huawei smartphones (Mate 10;Mate 10 Pro;Honor V10;Changxiang 7S;P-smart;Changxiang 8 Plus;Y9 2018;Honor 9 Lite;Honor 9i;Mate 9). The software does not properly handle certain information of applications locked by applock in a rare condition...
CVE-2019-5277
PUBLISHED: 2019-12-13
Huawei CloudUSM-EUA V600R006C10;V600R019C00 have an information leak vulnerability. Due to improper configuration, the attacker may cause information leak by successful exploitation.
CVE-2019-5254
PUBLISHED: 2019-12-13
Certain Huawei products (AP2000;IPS Module;NGFW Module;NIP6300;NIP6600;NIP6800;S5700;SVN5600;SVN5800;SVN5800-C;SeMG9811;Secospace AntiDDoS8000;Secospace USG6300;Secospace USG6500;Secospace USG6600;USG6000V;eSpace U1981) have an out-of-bounds read vulnerability. An attacker who logs in to the board m...