Footprint Left Behind
Consider, too, the footprint these practices have left behind. There’s that one data set squirreled away because it had the best test data and everybody used it. It’s been copied and shared repeatedly through the years. No one person could possibly locate and identify all the copies.
The problem isn’t exclusive to developers. Other employees, as part of their daily responsibilities, perform database queries or generate reports and store the results in their own personal, non-production, data sets.
These are just a few sources of the unknown unknowns. The mainframe has been an upwardly compatible platform for 40 years, so there are up to 40 years of accumulated data. This data may reside on primary or migrated storage and often on tape. How many of these data sets contain sensitive information and how can the data security team properly protect them if they don’t know they exist? What about the data that’s been assimilated by mergers and acquisitions and generated by a whole different staff?
As an example, at one installation, data assimilated as a result of a bank acquisition several years ago was searched to determine if access permissions were appropriate. The result of this project showed that more than 2 million access permissions were inappropriate.
There are two primary areas of concern:
• Production data sets and database tables where the contents contain a different category of sensitive data than the security control definitions assume
• Other data sets and database tables not considered part of the production environment for which the data security administrators don’t have appropriate categorization information and are therefore improperly protected.
This isn’t just a matter of maintaining best practices and minimizing risk. There are many laws governing disclosure of certain kinds of information, which vary from country to country. In the U.S., they include The Health Insurance Portability and Accountability Act (HIPAA), The Health Information Technology for Economic and Clinical Health Act (HITECH), and the Sarbanes-Oxley Act (SOX). Data breaches, which can cause violations of these laws, often have severe repercussions, yet the HIPAA, HITECH, and SOX laws offer little to no guidance on methods for identifying and protecting sensitive data. The European Union has a set of new data privacy rules that are expected to become law by the end of 2013 and carry penalties of up to 2 percent of a company’s annual turnover for a breach.
The PCI Standard
Fortunately, the Payment Card Industry (PCI) has well-defined standards in the PCI Data Security Standards (PCI DSS 2.0). While not law, PCI DSS 2.0 has significant penalties for failure to comply. For example, a company can be considered out-of-compliance if it doesn’t meet the standards during a regular audit; no data breach is required. This standard is quickly becoming a best practice—one that most believe will eventually be the basis for protecting other types of sensitive data such as intellectual property or new product plans.
The first step of a PCI Data Security Standard assessment (PCI DSS) states: “The assessed entity identifies and documents the existence of all cardholder data in their environment” (see https://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf).
This means the first step in achieving PCI compliance, and therefore best practices for any other kind of compliance, is to determine the locations of all the sensitive data. This is reinforced by two statements in the 2008 Verizon Data Breach Report (see www.verizonbusiness.com/resources/security/databreachreport.pdf):