Because of the expense and effort required in achieving and validating compliance, many merchants and service providers have sought to limit their scope of PCI DSS compliance by restricting the degree to which they actually store, process or transmit cardholder data in-house. Strategies like handing cardholder data off directly to acquirers (thereby minimizing the degree to which the data is handled in the merchant environment) or leveraging tokenization technology (replacing the primary account number or "PAN" with a sanitized value) help keep cardholder data out of the network environment. This limits the scope of controls needed and also reduces the audit surface for firms that are required to conduct annual audits.By far the most common scenario involves personnel: individual employees unknowingly introducing cardholder data into the network environment.
That's the theory, anyway.
But just like the oft-cited theory that bumble bees are aerodynamically incapable of flight, sometimes what's true in theory and what's true in practice don't entirely synch up. With PCI DSS, this gap can put enterprises at risk; all too often PCI DSS assessments turn up card data residing unsecured on the network. Needless to say, card data on a network that isn't documented or properly secured is not good, not only for the organization, but also for the network security team. In this tip, we'll discuss why this happens and provide a simplified PCI compliance network testing checklist of sorts to easily identify rogue card data.
Murphy's Law: What can go wrong will
In practice, the operational "hiccups" that can cause cardholder data to be leaked unknowingly onto the network are legion: They can occur because employees fail to adhere to defined business processes, because of "under-the-radar" situations unaddressed by a compliance strategy, and because of errors in the technical components that handle payment transactions.
By far the most common scenario involves personnel: individual employees unknowingly introducing cardholder data into the network environment. Individuals on the front lines of handling customer payments (for example, customer service staff assisting customers) may not even know what the PCI DSS is, let alone understand the importance of limiting PCI DSS scope by reducing/eliminating cardholder data from the environment. When one such worker receives a request from a customer that might not be status quo -- for example, asking to dispute an erroneous charge or looking to spread a charge across multiple cards -- the individual might handle the request in a way that violates a policy meant to limit scope. Maybe someone jots down the card number, expiration date or CVV, and later on enters those values into an email to a supervisor, or adds them to the notes field of a call log application.
Another situation could occur through accidentally overlooking one or more payment "channels" within the organization. For example, consider a large online retailer: the organization may have spent millions implementing tokenization to limit the data submitted by customers (by far their biggest exposure), but what about the cafeteria or parking deck? Something that might seem like "small potatoes" could slip under the radar, either because it's through a different relationship with another acquirer and processor, or because it just wasn't factored in to the original plan.
Lastly, technical issues can cause data to migrate into the environment as well. Debug and error logs -- potentially left on by accident when investigating an operational issue -- can oftentimes record live PANs or other cardholder data.
Send in the cleanup crew
So, realizing that there are situations where practical operational considerations can get the jump on our best-laid plans to prevent card data from traversing the network, what can be done?
The first step is cross-organizational awareness among compliance and security teams about these types of issues. Having situations like these on the radar in the compliance process helps individual stakeholders, like network security managers, stay vigilant for these things. But there are also some strategies to find and eliminate these situations to keep the compliance surface small.
First and foremost, it's helpful to consider the use of automated data discovery tools. Even if you don't anticipate that you'll find much, it's worth spending some time validating that theory, rather than be surprised by unexpected data later. If your enterprise has already implemented a data leak prevention (DLP) product, you're a step ahead: Simply enable the discovery feature of the product to locate cardholder data. If you don't have a tool like this one, consider using a free tool such as the open source ccsrch to find it. In the (likely) case that you find one or more areas of concern, remediate the issue and conduct a root cause analysis so it doesn't keep happening.
Also for those of us on the network side of the house, it's useful to maintain a special-purpose list or inventory of systems and processes where you expect to find cardholder data -- stored, processed or transmitted. Start by documenting all the systems and processes that perform these functions today. As you decommission systems, take them off the list to keep it current. As you go through the data discovery process, add what you find to your inventory. The PCI DSS requirements require you to maintain this list anyway along with documentation of your data flows, so you can streamline your audit or self-assessment process. But as you build it out, you also get the benefit of having a central repository of knowledge about the real scope of the CDE and not just what you think the scope should be in theory.
Limiting the data you collect and process within the confines of your network environment is a first step -- and a good theoretical approach -- to limiting your compliance scope, but remember that it takes solid follow-through and vigilance to take that theory and keep it working in practice.
About the author:
Ed Moyle is currently a manager with CTG's Information Security Solutions practice, providing strategy, consulting, and solutions to clients worldwide as well as a founding partner of SecurityCurve.
This was first published in September 2010