Thursday, November 7, 2013

PCI DSS Version 3.0 Has Arrived

Here are the links on the PCI Security Standards Council web site for the new version of the Payment Card Industry Data Security Standard, PCI DSS.

Press release:


The Standard:

Summary of Changes:


Version 3.0 of the Payment Application Data Security Standard, PA-DSS, has also been released today. Go to the PCI Council's web site for more information:

Wednesday, November 6, 2013

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.


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!

On the Eve of PCI DSS v3.0 - About

Here is a summary of information about the new standard, which will be released tomorrow.

What do we know about PCI DSS v3.0?

  • Release date is November 7, 2013
  • Becomes effective on January 1, 2014
  • Version 2.0 remains in effect until December 31, 2014 to provide a transition period
  • Version 3.0 introduces more changes than Version 2.0
  • There will be several new sub-requirements
  • Some of the sub-requirements will become effective on July 1, 2015. They will be best practices until then
  • Not all documents will be released on November 7. These will be available in 2014:
    • Revised SAQs
    • New SAQ for web-redirection payment environments
      • Announced at the North American Community Meeting
    • ROC reporting template
    • ROC reporting instructions
    • New AOCs
    • Prioritized Approach to PCI DSS Compliance

What factors have influenced the changes in PCI DSS v3.0?

  • Criminals are still targeting cardholder data
  • Many security breaches are tied to:
    • Lack of payment security awareness and education
    • Malware
    • Weak passwords and authentication
    • Slow self-detection
    • Poor implementation of the PCI Standards
    • Security issues with third-party providers
    • Lack of maintenance to ensure compliance between assessments
    • Inconsistent assessments

What will PCI DSS v3.0 do?

  • Focus more on higher risk areas
  • Clarify many of the requirements
  • Help to improve understanding of the intent of the requirements
  • Add flexibility to implementation
  • Help improve consistency of assessments with more stringent assessment procedures
  • Evolve with changing best practices, as well as risks and threats

What are the major themes in PCI DSS v3.0?

  • Encourage proactive approaches that focus on security rather than compliance
  • Make PCI DSS “business-as-usual”.
  • Increase awareness and education
  • Increase flexibility to allow better security
  • Security as a shared responsibility

What kinds of changes are included in PCI DSS v3.0?

  • Clarification – Concise wording to ensure that each requirement matches the desired intent
  • Additional Guidance – To increase understanding
  • Evolving Requirement – Keep standards up-to-date with market changes and emerging threats