Oct 1 ’06
Compliance Options: Protecting Sensitive Data
Back when I was teaching college English classes, I loved the lesson that centered around achieving clarity of thought and expression. “Rule Number One,” I’d tell my students, “is to eschew obfuscation.”
This directive would prompt some students to reach into their backpacks for their paperback dictionaries. Others would rise to the bait, raise their hands, and join in a lively discussion on clarity. The point they would make—and I’d readily agree with—is that most people don’t carry around dictionaries. And, many people wouldn’t use one if they had it available. They’d rather guess at meanings.
So what does this have to do with managing information and compliance? Plenty! Several laws and regulations require us to protect “sensitive” data.
For instance, Gramm-Leach-Bliley (GLB) includes “The Safeguards Rule,” which requires all financial institutions to design, implement, and maintain safeguards to protect customer information. The Health Insurance Portability and Accountability Act of 1996 (HIPAA) requires groups that work with Protected Health Information (PH I) to ensure its confidentiality, integrity, and availability and to protect the information against threats and disclosures. It includes nine security standards and restricts access to data, including limiting employee access to a need-to-know basis.
Sounds simple and unambiguous, my essay-writing students might have concluded. To be in compliance, first define “sensitive information.” Then, find it and protect this information, following clearly defined steps.
What are these steps? A clear (and brief) set of requirements can be found in the Payment Card Industry (PCI) Data Security Standard. Developed by Visa and MasterCard, it was endorsed by other payment vendors, including American Express, Diner’s Club, and Discover. Even if your organization isn’t required to adhere to this standard, you no doubt intend to meet security goals similar to those called out by the standard:
- Build and maintain a secure network
- Protect stored data
- Maintain a vulnerability management program
- Implement strong access control measures
- Regularly monitor and test networks.
The PCI standard includes a full page of detailed requirements for how to protect stored data. The prescribed steps could (and generally should) be employed to protect not merely cardholder data, but also other types of sensitive information. These steps are clearly written, just the type of unambiguous instructions needed to support goals that require the aligned efforts of cross-functional teams with representatives from business, IT, data administration, security, compliance, privacy, access management, and data governance.
So where’s the gotcha? One exists, of course. Whether your data protection teams are meeting the necessary compliance requirements, they’re going to ask: “Where is our sensitive data?”
This is a reasonable question—after all, you can’t protect what you can’t find. You’d think it would be easy to locate sensitive data, but that often isn’t the case. Sometimes the naming conventions of our systems’ files, tables, and data elements leave much to be desired. Deciding whether a field named Demo_12 contains demographic information or demonstration data might send your data protection teams in search of a dictionary—a data dictionary, that is.
But what if your data dictionary isn’t up-to-date? What if your metadata repository contains only “some” of your data? These aren’t valid excuses for non-compliance. And what about sensitive data that can’t be found using traditional, metadata-based identification methods?
What about seemingly innocuous fields that actually contain sensitive data, such as the H&R Block 47-digit tracking number that included the customer’s Social Security Number? When H&R Block printed this information on packing labels in December 2005, they did more than incur compliance problems. They earned a spot on the Privacy Rights Clearinghouse list of Data Breaches, a lot of negative publicity, and the cost of rectifying the situation and re-earning the trust of their customers.
How do we protect “hidden” sensitive data? What is needed, of course, is a new generation of tools that can find sensitive data, regardless of how it is named or described in our dictionaries. I’ve seen a demo of DataMapper, by Exeros (www.Exeros.com), where it was used this way. Are you aware of other automated solutions? If so, be sure to let me know.
For more information about Data Governance and sensitive data, visit http://www.datagovernance.com.