Missing the PCI boat
Whether big box, mom and pop, online or brick and mortar, there isn't a retailer that wants to be the next TJX. So why isn't the Payment Card Industry (PCI) Data Security Standard (DSS) the lifesaver that many envisioned? Some suggest PCI compliance is much more difficult to accomplish than a quick read of the requirements would imply and that it will take retailers years to make it happen. Others suggest that the projected cost of PCI compliance is so high that retailers would rather take their chances with fines or penalties than invest in compliance. The retail professionals I know wouldn't agree with the latter — they have every intention of complying with PCI. So what's the hold up?
PCI is a complicated regulation, but pretty well thought out compared to many other data-related regulations. There are a dozen main requirements that a retailer must address in order to achieve PCI compliance. Merchants need to ensure that they have firewalls, intrusion prevention systems, identity and password authentication and data security — which could come in the form of data auditing/monitoring and data encryption. They also need to have provisions for data removal. Most retailers have some of these systems implemented, but very few have all. With the risk landscape now considerably more complicated, it makes sense that retailers need to revisit their data security strategies.
Adrift on a sea of misconception?
There are a number of misconceptions about both PCI and data security. One popular misconception is that perimeter security and encryption are all that is needed to secure sensitive data. They are important, but they still leave holes big enough for a mass data breach to walk through. Another misconception has to do with where the biggest data loss risk lies. For example, many companies believe that email constitutes the biggest data security risk; when in reality less than five percent of data loss happens by email. Databases actually account for 50 percent of data loss; yet core data servers are the last thing that merchants concentrate on when it comes to PCI compliance.
PCI misconceptions include assuming that adding more of the same data security technology already in place and adding encryption will result in PCI compliance. Beefing up existing security isn't the answer and encryption can be complicated or impractical to implement, especially since users with the right credentials can decrypt. Merchants also need to know where cardholder data is located and how it is being accessed and used before it can be encrypted. Most merchants, most companies for that matter, don't know where critical data is located in the enterprise.
The complicated nature of the PCI standard and misconceptions about PCI and data security give some insight into why adoption has been slow. In addition, the retail industry operates on tight margins and may be reluctant to engage technology without a clear ROI attached. Systems such as point-of-sale systems are critical to the day-to-day operation of stores; so with a limited technology budget, a merchant might be forced to choose between security and operations.
So which comes first, PCI or data security?
I'm often asked, “Does PCI compliance constitute good data security?” This is a difficult question to answer because if you follow strict compliance when it comes to PCI, you will have good data security. But merchants don't have to follow PCI's every detail to pass their compliance assessment. So the answer is: If you have really good data security in place, chances are that you're already PCI compliant. If you are PCI compliant, you are on the road to good data security.
In my experience, most retailers start with PCI. Why? Because a critical business partner is holding their feet to the fire (I'm referring to the credit card companies, soon to be joined by banks that are tired of paying for the losses). This is not all bad, since the PCI requirements provide a fairly straightforward compass that can point us toward data security. But where do you start? And what do you do if budget won't allow you to follow PCI to the letter?
Charting the best PCI course for your budget
Let's look at the main technology areas central to PCI. From there, we can chart our PCI course by what is typically referred to as “security defense layers.”
Figure 1: Security defense layers
Figure 1 represents the gold standard of PCI data security compliance. It includes encryption (all layers including database and application level, as well as web-facing), IAM, passwords and authentication, vulnerability assessment (all layers, including network, application and database levels), firewalls, IPS, audit logging (all layers, including data-level, as well as network and applications). The reality is that most merchants fall short of this standard. They are mostly spending their time with firewalls and vulnerability assessment -- and saying that they are compliant. Note the mention of data discovery on the left side of Figure 1. This is a big hole in PCI DSS. It doesn't recommend or require formally that merchants get a handle on where the cardholder data is and this is a critical step before you can take appropriate action. Data discovery, particularly within databases, is really the starting point of reducing the scope of the PCI project to where the risk is the highest -- the databases that contain majority of the cardholder information.
What do you do if you don't have the budget to achieve the gold standard in PCI cardholder protection? Use a risk management approach to decide what stays and what does not. Let's say that you have one quarter of the budget required. Then I suggest you focus on the cardholder systems -- the databases that hold majority of your credit card data. Of all the gold-standard technologies mentioned above, you should retain data discovery, data-layer vulnerability assessment and database-level audit logging. This way you will have sufficient data compliance controls in place to know if anything bad happens to the cardholder databases. You will know where your cardholder data is, how it is being used and you'll have an actionable audit trail. Also, data-level audit logging will give you a lightweight compensating control against database encryption.
What if you have one half of the gold standard budget? In addition to database-level audit logging, you can add SIM-type network & app-level logging. This gives you visibility into the perimeter and the edge of the your network that leads to card holder databases. In addition to database-level vulnerabilities, you can add network-level and application-level assessments. Also, explore doing database-level encryption in selective cardholder databases. (This is usually an expensive and long-drawn out investment, so step it into carefully.)
Even if you are not in a position to reach for the gold, with this strategy you'll be going beyond check-box PCI to focus on the biggest risk and the most important aspects of the PCI data security challenge.
Why PCI will help data security in the long term -- the SOX story
In the long run, PCI may accomplish what other, once unpopular, regulations like Sarbanes Oxley (SOX) accomplished. Because of the light that SOX shone on financial practices and systems, this regulation is now viewed quite differently by many enterprises. Businesses found that the insight, efficiencies and good data governance practices resulting from SOX compliance initiatives had unexpected but positive effects on business -- including renewed customer trust and competitive advantage.
Be proactive and, if possible, implement PCI controls from a data security best-practices standpoint. While you can never guarantee complete protection, done correctly and with the right spirit, PCI compliance can reduce data risk and in the long term, help your business.
Prat Moghe is founder and CTO of Maynard, MA-based Tizor Systems where he drives market strategy, product vision and technology thought leadership. Moghe is vice-chair of the PCI Security Vendor Alliance and authors the first data auditing blog at http://blog.tizor.com. Call Tizor at 800-231-8224.