On the Eve of PCI DSS 3.0: Scope Creep

Okay, it's coming tomorrow. We have been hearing about it for a very long time and the wait is almost over - PCI DSS version 3.0 will be released on November 7, 2013.

I have been on pins and needles about this for almost a year. And wondering about one part of it for over two years. When I started in my position at Michigan State University in 2011, I had many conversations about PCI scope with Walt Conway. One thing we discussed from time to time were documents from both MasterCard and Visa about the risks surrounding the use of hosted payment pages for e-commerce sites. The main point of these documents was that our usual understanding about what was in and what was out of scope for PCI compliance did not necessarily cover all the risks, and that merchants should do more than they were currently doing to protect cardholder data.

Yikes!

Like many colleges and universities back in the 00s, we listened to and followed the advice to reduce and limit our scope of PCI compliance by eliminating cardholder data wherever we could. We had a home-grown payment processing system that stored, processed, and transmitted cardholder data. Yikes! SAQ D!

We decided to turn that part of our e-commerce business over to a third-party payment processor. We invested in a system that would allow us to continue using our internally developed e-commerce applications, but we would now send our customers off to our service provider to handle the payment part of the application. When they clicked the Checkout button their browser would then display a page from our vendor, where the cardholder data would be entered and collected for processing. Boom! No more cardholder data on MSU servers.

Relief & Dark Clouds

It was glorious and we breathed a sigh of relief that we had made such a significant reduction in the effort needed to maintain PCI compliance at our university. And every unit on campus that had their own e-commerce shopping cart app could continue to use them without having to be concerned about PCI DSS, except in a very minimal, SAQ A kind of way.

But then I saw these documents from the card brands about the risks of hosted payment pages. MasterCard published their bulletin back in 2010, the year when PCI DSS version 2.0 was released. And MasterCard was saying, "Wait a minute here! You're not necessarily off the hook just because someone else is handling your cardholder data for you." They warned of the rise in what are called "man-in-the-middle attacks." The problem they were seeing was that servers that did not touch cardholder data at all, but were part of the e-commerce transaction, these servers were being compromised and the URL for the payment page was being changed. Customers were being re-directed to malicious web pages that would impersonate the real payment pages and steal the customer's cardholder data. And they might even complete the real payment for the customer, who would not suspect a thing. Oh. This is not good.

I started to wonder if these warnings might eventually show up in a future version of PCI DSS, and it looks like that is what has now happened. The first official clue was in the PCI DSS E-commerce Guidelines, submitted by the E-commerce Special Interest Group in January, 2013. Then the draft of PCI DSS v3.0 confirmed this where it defines "system components" as including "Systems that...may impact the security of (for example, name resolution or web redirection servers) the CDE." And the PCI council was very explicit about web redirection servers at the PCI SSC North American Community Meeting in Las Vegas this past September. Those servers are in scope.

Now What?

What will this mean? For our university, we will need to start to define controls that need to be applied to our e-commerce servers that we currently consider to be out of scope. But exactly which controls should those be? According to the E-commerce Guidelines, those would be the "Applicable PCI DSS requirements." What is applicable?

In a chart on page 22 of the E-commerce Guidelines, regarding hosted payment pages, we find this:

Merchant is responsible for:

• Managing website and servers (if self-hosted), including applicable PCI DSS requirements
• Applicable PCI DSS requirements for managing third parties, (e.g., Requirement 12.8)
• Having written agreements with any third parties and ensuring they protect cardholder data on behalf of the merchant, in accordance with PCI DSS.
• Securing the web page(s) containing the redirection code and/or function(s).

 Again, "applicable PCI DSS requirements" as well as "Securing the web page(s) containing the redirection code." But what, exactly, is applicable? What does "securing" entail? They may as well have said, "It depends." Those question were on the mind of many assessors in Las Vegas in September. As it stands now, I will have to go through every requirement and sub-requirement to decide if it is applicable. As much as I dislike PCI DSS being denigrated as "checkbox security," the fact is in this situation I want a checklist! If, goodness forbid, we had a data breach and had decided a particular PCI requirement didn't apply but the forensic investigator decided it did apply, we would have an even bigger problem than we thought we had.

But, surprisingly to me the Council told the community the very next morning that they listened to our concerns. They didn't make it a hard promise, but it sounds like they are going to create a new SAQ that covers "web redirection" servers such as I'm concerned about. For those situations where SAQ A just doesn't cut it any more. And they also talked about some additional guidance on PCI DSS scope. After all the hoopla about the Scope SIG that disappeared, they owe that to us.

PCI DSS version 3.0 will not be revolutionary, although it is still full of changes. This business about scope isn't even in one of the actual requirements. But version 3.0 looks like it will still say, as it said in version 2.0, "The first step of a PCI DSS assessment is to accurately determine the scope of the review." And scope will continue to be one of the most important things I need to consider when assessing compliance at my school.

We'll see what PCI DSS version 3.0 actually says tomorrow. Until then!