PCI DSS 3.0 – The Devil is in the Details

In recent webcast (recording available here), the first of three in our compliance series on PCI DSS 3.0, we provided some insights on the notable requirements and clarifications that have been introduced with PCI DSS 3.0, and provided some practical suggestions of what you may want to start considering how to successfully navigate your audit preparations for v3.0.

Our subject matter expert for the session was Jeff Hall, a senior security consultant and qualified security assessor (QSA) with FishNet Security who has over 30 years of information technology and security experience, and is also the QSA behind the popular PCI Guru blog.

With several hundred attendees participating in the webinar, it was impossible to address all of the pertinent questions about the changes to PCI DSS with the release of v3.0, and Hall was gracious enough to set aside some extra time to provide some additional details on specific issues of interest.

PA-DSS Certified Applications

An attendee asked about how existing PA-DSS certified applications will be affected by PCI DSS v3.0, and whether or not they will have to be re-certified to be compliant.

Hall assures that are no concerns with the PA-DSS changes relating to existing applications already certified to PA-DSS requirements, but he does note that there are different versions of the PA-DSS, so merchants will need to look up applications on the PCI SSC Web site to determine the status of the PA-DSS certification for the version of the application they wish to implement.

Hall points out that there are two types of PA-DSS certified applications: Those acceptable for new deployments, and those acceptable for pre-existing deployments. The new deployment applications are those that can be purchased and deployed with revalidation of these applications will occur annually until their certification expiration date.

“Pre-existing applications are those where the merchant has already purchased and deployed the application prior to the listed expiration date and it is acceptable to continue using it. The application vendor may elect to no longer sell and/or support this product,” Hall said. “The key to the pre-existing category is that an organization can continue to use these applications at existing and new locations.”

However, for new locations, Hall says that the application needs to come from internal sources. The merchant cannot simply buy the solution from outside parties, so they would have to establish a closed a location first, and then proceed to put that location’s application in the new location.

In addition to these categories, Hall says there are a number of PA-DSS standards involved as well as Visa’s PABP which preceded the PA-DSS. Even though PA-DSS v3.0 has been released, the guidance for how applications are to be assessed under that standard have not been made available yet, so v3.0 is still “in the wings” and the current standard is PA-DSS v2.0.

“Applications certified under the PABP and those certified under the PA-DSS prior to version 2.0 fall into the pre-existing category,” Hall explained. “That said, there are some applications that were certified under PA-DSS v2.0 that also fall in the pre-existing category.”

“It is important to look up the application at the PCI SSC Web site to determine its certification status before you purchase and/or implement it,” Hall continued. “You should also ensure that your purchase agreement with the vendor contractually obligates the vendor to providing a PA-DSS certified solution that is current on its certification.”

eCommerce Application Developers and PCI DSS v3.0

Another attendee, a software provider for eCommerce, asked about what compliance responsibilities they need be concerned about, given that they employ SSL encryption on all billing and shipping pages, the credit card data is hashed, and they monitor logs so that they know who is accessing the pages, among other precautions.

Hall replied that regardless of those precautions, if the applications process, store or transmit sensitive authentication data (SAD) and they are offered for sale to customers, then those applications have to be certified to the PA-DSS standard.

“If you are not selling your applications then they do not need to be certified; however, as a best practice, you should still follow the PA-DSS requirements to ensure that your applications securely process, store or transmit SAD,” Hall said. “That is because your customers’ QSAs will need to individually assess them to the PCI DSS standard. By following the PA-DSS, the PCI DSS assessment will go much easier.”

Web-Only Merchants and Penetration Testing Requirements

The addition of penetration testing has been one of the more interesting elements of v3.0, and one attendee inquired about whether web-only merchants will be subject to the new requirements.

Hall says the simple answer is a resounding yes, penetration testing is required for all Web-only merchants if they are processing, storing or transmitting sensitive authentication data through those sites.

“The reason for that answer is that I suspect that each merchant has differences in their Web sites, as subtle as they may be, and therefore each needs to be penetration tested,” Hall said. “Even if all of those sites are supposedly ‘cookie cutters’ of each other, they still need to be individually tested.”

Hall says that as a service provider, you have two choices, the first is having customers do their own penetration testing of their Web sites, “but the downside to this approach is that your technical people can end up overwhelmed unless you schedule them all appropriately,” Hall says.

The second option would be to conduct the penetration testing on all of your customers’ Web sites yourself, and then issue the reports back to each customer for their particular sites, which may be a more manageable strategy.

PCI DSS v3.0 and Encryption

One attendee explained that their organization, a healthcare provider with six distinct service centers, had decided to dedicate a virtualized environment to their payment card applications in order to segregated them from their other systems, and they also opted to engage cloud-based payment card providers to eliminate issues with cardholder data storage requirements.

Even with a a virtualized environment in place and managed service providers handling the payment card data, they are still concerned about their networks’ compliance status because of their large size and their geographic distribution. Hall says that try as they might, many organizations are still struggling with cardholder data traversing their networks and how to eliminate the need.

“Point-to-point encryption (P2PE), also known as end-to-end encryption (E2EE), can accomplish that to a certain extent,” Hall responded. “However, the endpoint devices are still in-scope, which is a shock to some because of the way sales people can describe their P2PE solutions, and since those endpoints come into contact with cardholder data, they are totally in-scope for PCI compliance. So, while your scope shrinks, it does not totally go away.”

PCI DSS 3.0 and the Cloud

Another question Hall fielded was in regards to wireless requirements and how they apply to running infrastructure in the cloud, such as with Amazon Web Services (AWS).

Hall says that since AWS is not going to allow wireless equipment in their cloud, so you should not be concerned about this matter, but the question brings up an important issue: There is nothing to prevent having wireless networks that have access to servers and applications in the cloud.

“Such a configuration would be treated no different than wireless access to internal resources in regards to complying with the relevant PCI requirements,” Hall said.

PCI DSS 3.0 and Continuous Compliance

One attendee bluntly stated that PCI DSS compliance is somewhat draconian in nature, with so many requirements that are difficult to implement and maintain, and so it would seem that no one is ever really compliant at all.

“As I like to point out to everyone, security is not perfect, and continuous compliance means that people and processes function perfectly 24x7x365 – and that just does not happen when people are involved,” Hall said.

In light of this fact, Hall says that the PCI standards are specifically structured to provide multiple opportunities to detect when controls are not operating properly.

“The trouble is that a lot of organizations have too many controls not functioning properly and are not able to follow up and correct all of the issues. As a result, over time, the control deficiencies become larger and more prevalent eventually resulting in a breach.”

Thus, PCI DSS v3.0 may address many of the concerns that have been regularly voiced over the last few years about v2.0, but it will not necessarily make the process of compliance any simpler for those whose operations are in-scope.

In Part Two of this series, Jeff Hall answers several more specific questions regarding PCI DSS v3.0 as it relates to smart cards, tokenization, PoS monitoring, Wi-Fi issues and more… Stay tuned!