My company’s trying to comply with the Payment Card Industry (PCI) Data Security Standard (DSS). This means we can’t store any Track II credit card data at all. It also means we have to encrypt the primary account data that we do store. The problem is – we’ve been storing some of that information for years. How can I ensure that all sensitive data has been discovered and eliminated or properly encrypted?
First, congratulations to any organization taking the time to ask, “Where is unstructured or unaccounted for data lurking on our network and hosts?” While many organizations are thinking about this question in the wake of PCI preparations, it goes well beyond credit card data. Any organization that stores sensitive information, whether it’s financial account data, personal information such as birthdates or social security numbers, or protected intellectual property, should be asking the same question.
Of course, asking the question is not the same as answering it. In fact, discovering and documenting all instances of a type of data can prove difficult indeed. Going back to our PCI example, some data elements associated with credit cards are fairly easy to recognize. Primary account numbers (PANs) follow a specific schema that is relatively unique. Discovery tools can be configured to search for the specific PAN-like string and seek out these numbers, whether they’re stored on servers, in databases, or on hosts in files such as Word or Excel documents.
Data with a less recognizable signature is harder to differentiate during discovery. A Personal Information Number (PIN) is usually a four to six digit number. Under the rules of the PCI DSS, PINs are not allowed to be stored. But a four to six digit number is not distinct enough to be identified with a high level of assurance as a PIN. A four to six digit number could be a personal identifier number, an amount of inventory, a sales projection value or any number of other non-PIN related things. Using a discovery tool to seek out four digit numbers, without any qualifying search help, would result in a high level of false positive responses.
So what can be done? In the short term, tuning discovery tools to look for incidents of data that are near other indicators can help reduce false positives. For example, if a spreadsheet is labeled “card data”, a four digit number is worth investigating. If a database table is titled, “widget inventory list”, the four digit number is less likely to be a PIN. Tuning discovery tools to look for likely connections that indicate the type of data being discovered won’t eliminate false positives, but they can certainly help provide pointers on where to look first.
Long term, it’s time to think about data classification and meta-data tagging. Data elements can be created with tags that indicate what type of data it is and then policies related to how that data is handled (i.e. stored, deleted, stored with encryption only, etc.) can be applied. When data elements carry their own identification “cards” (meta-data tags) with them, they’re a lot easier to root out from dark, hidden corners of laptops and servers.
Kelley is a senior analyst at the Burton Group. Have a question about securing your data? Ask us.
