Caught Between a ROC and a Hard Place

Meeting compliance while increasing security

It’s important to understand the perspective of both the business and the security leader. Merchants invest heavily in PCI compliance and it’s money well spent. However, they continue to struggle with prioritizing, implementing and supporting vital payment security programs. The business perspective is that PCI compliance is a necessary evil, both because non-compliance risks increase credit card transaction fees from the acquirer, and because it’s perceived to be one of those “have to” regulatory requirements such as the Sarbanes-Oxley Act (SOX), Health Information Technology for Economic and Clinical Health Act (HITECH), or Federal Information Security Management Act (FISMA) (even though, frankly, it’s not). Regardless, to a business stakeholder, PCI falls into the category of “we just have to do it.” In the end, we need an annual Report on Compliance (ROC). This is what we’re after—a report. 

To a security professional, however, PCI is quite the opposite. The PCI standard has emerged as a primary driver in security spending precisely because the standard has widespread adoption and has teeth in the sense that non-compliance can lead to increased credit card transaction fees, which have a real impact on the bottom line. Therefore, in the cyber security industry we’ve used this standard to drive our budgets and, often “do what’s right” outside of the PCI standard. But, at the end of the day, we need an annual ROC. 

Here’s where practice and reality have collided: Annual PCI assessment services and penetration tests are the cyber equivalent to a root canal, they’re necessary pain. However, they don’t provide the PCI assessor (QSA) with anything other than more work as an outcome. In fact, they often expose both our own failures and the progress that the bad guys have made since our last assessment. As a result, and by necessity, we’ve become adept at getting a ROC as quickly and cheaply as possible. How do we do this? We shrink the scope of PCI services to the smallest footprint possible, and this is precisely how we’ve gotten ourselves into trouble. Much of our conversations around PCI are around reduction of scope versus the application of security controls. This is especially true when we are negotiating with the QSA on cost and duration of the assessment activities. 

How did this happen? As security professionals, we leveraged technology such as network segmentation, domain trusts, point to point encryption (P2PE) and administrative jump stations to segment our payment card network with the goal of making it as small as possible. This was done so that when the QSA came knocking for the annual assessment, the cardholder data environment was as modest as possible, and he was unable to see the rest of our “world.” 

This is no different than the phenomenon that used to occur in states and counties that had (or still have) personal property taxes. Rich folks would pack up all their expensive belongings and move them into storage (or out into the woods) when the assessor came by to take inventory, and move the good stuff back into the house after the assessor left.   

We’ve done the same thing in pursuing PCI compliance—we reduce the scope as much as we can so when the assessor comes to the door it’s as quick and painless as possible. We want the cheapest, easiest ROC we can get. But, we also want to protect our organizations from breach. By virtue of our own actions, we’ve gotten ourselves caught between a ROC and a hard place. 

Adding to this conundrum, we had the liability shift of October 2015 that caused an interesting phenomenon with merchants. Acquiring banks (with much forewarning) informed merchants that if they did not elevate their level of technology compliance to include such things as recognition of ‘chip’ cards (the EMV standard), they themselves would be liable for fraudulent transactions. This requirement, almost immediately, created a ‘chargeback’ problem for merchants whereby seemingly legitimate charges that were contested by cardholders were immediately accepted by banks and the merchant was left holding the bag. We cannot underestimate how much loss this has cost the retail sector, even in cases when contested charges were actually fraudulent actors who understood how to work the system. Any retail, hospitality, or travel CISO will share stories about answering questions regarding this phenomenon to their leadership team or board. 

The merchant holds a much more complex and difficult task in the evolution of payment security. One cannot underestimate the number of ways merchants can benefit from a meaningful and secure transaction with a consumer—or the impact fraud, theft and breach can have without one. PCI compliance becomes easier and better when it is an intrinsic outcome of security. 

In the white paper, Building a Secure Payment Lifecycle, Optiv expands upon the 12 Payment Card Industry Data Security Standard (PCI DSS) requirements, and it describes additional considerations that influence merchants’ ability to attain not only compliance but also solve top payment security challenges.