PCI DSS version 3.0: The five most important changes for merchants

Area 1: Penetration testing

Perhaps the most visible change to the existing requirements has to do with updates to penetration testing requirements (11.3), including the requirement (11.3.4) to verify methods used to segment the cardholder data environment (CDE) from other areas. The full scope of this change has been discussed in other coverage, but one portion of the update that's likely to be particularly challenging for merchants to meet is the requirement that penetration testing activities (internal and external) now follow an "industry-accepted penetration testing methodology," such as the specifically referenced NIST SP 800-115, Technical Guide to Information Security Testing and Assessment.

Merchants must be extra-diligent in their selection of penetration testing services.

The good news is that the 11.3 update is a best practice until June 30, 2015, giving merchants a few extra months to adapt to the change. The bad news is that this requirement is likely to be difficult for many merchants to comply with -- at least initially. Why is it challenging? Primarily because penetration testing is a specialized discipline, and many merchants (particularly smaller ones) don't have in-house staff capable of performing an effective pen test. Merchants typically leverage external services providers to meet the penetration testing requirement; many of those service providers (not naming names) don't currently base their offerings on any formalized methodology. There are, of course, service providers that do leverage process-focused frameworks like SP 800-115, which details specific processes to follow during testing, or that draw on execution-focused technical standards like the Penetration Testing Execution Standard or (for applications) the OWASP Testing Guide (that offers technical guidance); but generally speaking, this isn't the normative case.

Because of this, merchants must be extra-diligent in their selection of penetration testing services to make sure that the processes followed by the vendor(s) they select adhere to an industry-accepted methodology. As the first order of business, any merchant preparing its PCI DSS 3.0 compliance plan should start by adding the language, adherence to a methodology (wordsmithed as your organization sees fit) into penetration testing requests for proposals.

Area 2: Inventorying system components

Though less talked about so far in the industry press, another area of potentially huge impact from a practical standpoint relates to the new requirement (2.4) to "maintain an inventory of system components that are in scope for PCI DSS." A system component in this context is detailed on page 10 of the standard (Scope of PCI DSS Requirements), but essentially it refers to all hardware (virtual or physical hosts and network devices), as well as software components (custom or commercial, off-the-shelf applications, whether internal or external) within the cardholder data environment.

The testing procedure for this specifically requires that assessors "verify that a list of hardware and software components is maintained and includes a description of function/use for each"; so, not only do merchants need to document all the components in the CDE, but they also need to document what those components do and why. Requirement 11.1.1 (which I'd argue is related) now requires that merchants "maintain an inventory of authorized wireless access points including a documented business justification."

As you might imagine, keeping inventories current isn't easy to do. Historically, existing requirements for merchants to maintain inventories (including cardholder data locations, personnel with access to cryptographic keys and cardholder data, and firewall rules and justifications) have been difficult to accomplish. Why? Because they change often and frequently require manual effort in order to keep them reflective of the environment as it actually exists. So, maintaining a reliable inventory of both hardware and software components (as anyone who has ever actually tried to maintain one will testify to) is nigh-on to impossible in a large or complicated environment without automation -- and even then it isn't easy.

This complexity is compounded when virtualization is thrown into the mix (because a system component includes virtual images too) or when the environment sprawls out in multiple geographic locations, as most distributed retail locations are likely to do. Likewise, complexity also arises when proprietary, vendor-supplied systems are maintained by outside personnel (for example, application vendors or system integrators). These factors present a veritable recipe for one difficult-to-meet requirement. There's no getting around the reality that merchants' IT and compliance teams will have to spend a lot more time developing and honing ways to create and manage these inventories.

Area 3: Vendor relationships

Requirements 12.8.5 and 12.9 now call for explicit documentation about which PCI DSS requirements are managed by vendors vs. which are managed by the organization itself. For example, if an organization uses a hosted data center vendor, the physical access restrictions of that data center might be managed by the vendor, while the administrative side of providing access to those locations might be managed by the customer organization. In this scenario, PCI DSS 3.0 requires that merchants explicitly agree to and document this segregation of duties with the vendors or service providers in question.

The requirement for documentation means that now it's necessary not only to maintain a list of the vendors (this was a requirement before 3.0) and to track their compliance status when that service intersects your CDE (also a requirement before 3.0), but also to maintain a matrix of the PCI DSS requirements with a corresponding responsibility assignment matrix for each applicable vendor that the vendor must sign off on.

Obtaining and administering these various matrices will likely prove challenging in practice. Why? Two reasons: First, it involves examining all the vendors that intersect the CDE (ideally, merchants have this list because they're already supposed to be tracking vendors' PCI compliance status); and second, it involves analyzing exactly how each specific vendor is used. In practice, merchants must now know exactly what the vendor or service provider does (to determine what its scope is), where responsibility should lie for controls, and how to create a document that describes those things. Then comes the fun part: getting the service providers in question to agree (word of caution: They might not see things the same way you do) and to enter into a formal, written agreement about it. As anybody who's been involved in vendor negotiations in the past can tell you, negotiating these points (particularly after a contract with a service provider is already in place) will be time-consuming and may be (depending on the service provider) contentious.

Area 4: Antimalware

Requirement 5.1.2 now requires merchants to: "identify and evaluate evolving malware threats" for "systems considered to be not commonly affected by malicious software." That means that if you use a system that isn't usually affected by malware (think mainframes or Unix servers), you'll need to have a process to make sure that this continues to be the case and that, should some malware emerge for those platforms, you'll know about it. Likewise, Requirement 5.3 now mandates specific authorization from management to disable or alter the operation of antivirus mechanisms, as well as that the disabling be time-limited.

Depending on the organization, these requirements can have some impact, particularly the second one. Under PCI DSS 2.0, the standard specified only that there be antivirus software in place, that it be operational, that it be updated or current, and that it have the ability to generate logs. These properties were fairly likely to be present, no matter who installed the tool, how it was installed or (within reason, provided it didn't impact the above) how it was configured. Not so anymore. Now, the antimalware system must be capable of locking out the user from disabling it (this will probably require specific configuration) and be configured to make use of that capability. This may require both a higher measure of technical planning to accomplish (since it could impact both the antimalware tool and the OS configuration) and a rollout strategy to verify this capability throughout the entire CDE. No doubt most merchants will be pushing more paperwork to meet this requirement, but the change won't be as arduous to deal with as the others mentioned above.

Area 5: Physical access and point of sale

Requirement 9.3 now requires that merchants control physical access for on-site personnel, that access be authorized and based on individual job function and that access be revoked immediately upon termination. Requirement 9.9 now requires that merchants "protect devices that capture payment card data … from tampering and substitution." Most merchants are probably already doing what's required to meet 9.3, but if there are any merchants still using the server closet at a retail location to also store the paper towels, now might be a good time to stop.

Compliance with 9.9, though, is probably a little trickier. Why? Consider where it's most likely to be applicable from a merchant standpoint: retail locations, restaurants, doctors' offices, food trucks, taxi cabs and other unique retail environments. Are those retailers accustomed to "periodically inspecting" point-of-sale (PoS) devices -- for example, checking the serial numbers to ensure that devices haven't been swapped? Not likely. Imagine what would be required to get something like that rolled out across a number of geographically distributed retail locations. Likewise, the testing procedures for this requirement specifically refer to verifying that policy/procedures include "maintaining a list of devices." How many merchants right now have an inventory of their PoS devices? While it's certainly a good practice, the reality is that surprisingly few do. All this is likely to be a new concept for site administrators or retail location managers, and may require quite a bit of socialization, preparation and staff training to fully roll out.

Conclusion

As you can tell, some merchants will have their work cut out for them when it comes to these new and updated requirements. Note that these aren't the only changes -- and of course, the specific usage context and culture of the organization will matter in terms of how they will be felt in a particular enterprise. However, these are the PCI DSS 3.0 changes that merchants are likely to feel most keenly, at least during the transition period. In some cases, the effect is obvious (e.g., penetration testing), while it won't become apparent to others until someone sits down at the keyboard to do the implementation (e.g., inventorying system components). Regardless, merchants must start planning now to make sure that they're ready to address the changes. Otherwise, that first PCI DSS 3.0 assessment in 2014 or 2015 likely won't be a pleasant experience.

About the author:
Ed Moyle is director of emerging business and technology at ISACA. He previously worked as senior security strategist at Savvis Inc. and as senior manager at CTG. Prior to that, he served as vice president and information security officer at Merrill Lynch Investment Managers.