Everybody seems to agree with the need for organizations to do a better job of protecting personal information. Every week the media brings us reports of more data breaches, and no organization is immune. Hospitals, universities, insurers, retailers, and state and federal agencies all have been the victims of breach events, often at significant costs. State privacy laws such as the new Massachusetts privacy statutes have placed the burden of protecting sensitive information squarely on the shoulders of the organizations that collect and use it. While some managers might view this as yet one more compliance hurdle to worry about, we feel it presents an excellent opportunity to evaluate existing practices and procedures. The good news is that there are some great solutions available today that can help organizations of all stripes address these requirements while at the same time tightening data security practices, streamlining operations, and improving governance.
Key Requirements of the Massachusetts Data Privacy Law
Massachusetts law 201 CMR 17.00 was enacted in response to growing concerns by the public about how businesses and other entities handle the personal information (PI) they collect and manage in the course of conducting business. Sometimes known more descriptively as the "Massachusetts Data Privacy Law," 201 CMR 17.00 applies to anyone who owns or licenses personal information about Massachusetts residents. The text of the law defines what constitutes PI, spells out responsibilities for protecting PI, and provides a minimal set of technology controls and computer security requirements for organizations entrusted with handling PI in the course of business. Massachusetts set March 1, 2010 as the deadline for organizations to be in full compliance with the law.
To help businesses in their effort to comply with 201 CMR 17.00, the Massachusetts Office of Consumer Affairs and Business Regulation compiled a checklist to help them address a key requirement of the law, a Comprehensive Written Information Security Program. Each question in the checklist was designed to highlight a key feature of the law. These questions illustrate the need for organizations to address four critical steps to compliance, which include:
- Identifying the computing systems containing PI
- Evaluating the risks to systems containing PI
- Dealing with third-party service providers with whom they share PI, and
- Limiting PI collection, retention, distribution, and access to business need to know
First, You Need to Find It: Locating the Sensitive Data
Identifying all computing systems containing PI is a first and necessary step to protecting it. Unfortunately, this is not always easy. Most organizations actually have multiple versions of production data dispersed throughout the enterprise supporting activities such as testing, development, Q/A, and business analysis. The database schemas supporting these applications can be quite complicated, and the problem of locating sensitive data such as PI is further compounded with third-party and legacy applications. In these situations, tools for automating sensitive data discovery can be invaluable. Such solutions can scan the contents of databases and examine metadata and application data to quickly identify what PI resides in the application and where it is stored. Automating these tasks can save many hours of manual inspection, producing more reliable results in the process.
Key Systems: You Can't Protect Them If You Don't Know They're There
Evaluating the potential risks to systems containing data is a key component of any information security program. 201 CMR 17.00 emphasizes that organizations need to consider data security risks to PI, especially confidentiality risk, from both internal and external threats. Answering these questions requires that organizations have a clear picture at all times of what systems they have deployed and where. Expect this problem to be compounded as virtualization and cloud computing become more popular. These innovations improve efficiency by facilitating rapid systems deployment almost anywhere on demand, in private or quasi-private computing environments. The ephemeral nature of systems in these environments makes knowing which systems need protection on a day-to-day basis a tough job. The ability to automatically scan all environments to identify database instances in these situations is invaluable. In this case, automated solutions for identifying what databases are deployed, and where, is crucial to identifying what steps organization will need to take to protect those systems.
Adhering to the Need to Know Policy: Can the Job Be Done With Masked Data?
Service providers pose a special complication in complying with 201 CMR 17.00. The law spells out responsibilities of organizations to ensure that the other organizations with which they exchange PI have sound information security policies, are implementing appropriate procedures to safeguard PI, and are operating consistently with applicable state and federal regulations. Assessing this may not be easy, especially when these third parties are small business partners, vendors, or offshore development partners. The truth is, in many cases, these third parties may not require access to actual PI but may only require enough data to complete functions such as development, software debugging or market analysis. In these instances, masking, or de-identification, provides a way to share production data without the risk of compromising PI. Data masking solutions can selectively scramble or change the data so that PI is completely protected, while at the same time preserving data and business rules that allow it to be useful for downstream applications. Data masking enables organizations to get the most leverage from their data without the need to take special precautions to protect additional systems to stay compliant.
Keeping It Clean: Stopping Sensitive Data From Spreading Internally
Finally, a major aspect of compliance with 201 CMR 17.00 hinges around limiting PI collection, retention, distribution, and access. PI can accumulate in an organization like rust in pipes, and old PI can be just as sensitive as new PI. (Think about it: When was the last time you changed your Social Security number?) Regular monitoring of the network environment is essential to ensure that organizations are not inadvertently putting PI at risk. Organizations should periodically scan their environments to identity systems and applications, search databases, and online file repositories to identify PI, and when necessary, remediate by securing systems, deleting, or moving data, or masking data to remove PI. Enterprise dashboards can help organizations track how frequently systems are being monitored, pinpointing potential problems, and ensuring that adequate data protection procedures are in place.
Controls Over PI Delivers Benefits Beyond Compliance With 201 CMR 17.00
For many organizations, the need to comply with data privacy laws such as 201 CMR 17.00 will cause much weeping and gnashing of teeth. However, for managers who take the positive view, these requirements are an opportunity to improve visibility and controls over not just PI, but all kinds of sensitive data maintained in their systems. Solutions available today to implement the essential steps can pay off by improving operational efficiency and general governance, risk management and compliance.
Michael P. Mesaros, CISSP, is the director of product management at dataguise Inc., Fremont, Calif.