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
News
Inside the Ransomware Campaigns Targeting Exchange Servers
Kelly Sheridan, Staff Editor, Dark Reading,  4/2/2021
Commentary
Beyond MITRE ATT&CK: The Case for a New Cyber Kill Chain
Rik Turner, Principal Analyst, Infrastructure Solutions, Omdia,  3/30/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-31414
PUBLISHED: 2021-04-16
The unofficial vscode-rpm-spec extension before 0.3.2 for Visual Studio Code allows remote code execution via a crafted workspace configuration.
CVE-2021-26073
PUBLISHED: 2021-04-16
Broken Authentication in Atlassian Connect Express (ACE) from version 3.0.2 before version 6.6.0: Atlassian Connect Express is a Node.js package for building Atlassian Connect apps. Authentication between Atlassian products and the Atlassian Connect Express app occurs with a server-to-server JWT or ...
CVE-2021-26074
PUBLISHED: 2021-04-16
Broken Authentication in Atlassian Connect Spring Boot (ACSB) from version 1.1.0 before version 2.1.3: Atlassian Connect Spring Boot is a Java Spring Boot package for building Atlassian Connect apps. Authentication between Atlassian products and the Atlassian Connect Spring Boot app occurs with a se...
CVE-2018-19942
PUBLISHED: 2021-04-16
A cross-site scripting (XSS) vulnerability has been reported to affect earlier versions of File Station. If exploited, this vulnerability allows remote attackers to inject malicious code. We have already fixed this vulnerability in the following versions: QTS 4.5.2.1566 build 20210202 (and later) QT...
CVE-2021-27691
PUBLISHED: 2021-04-16
Command Injection in Tenda G0 routers with firmware versions v15.11.0.6(9039)_CN and v15.11.0.5(5876)_CN , and Tenda G1 and G3 routers with firmware versions v15.11.0.17(9502)_CN or v15.11.0.16(9024)_CN allows remote attackers to execute arbitrary OS commands via a crafted action/setDebugCfg request...