Welcome to the PCI Prioritization Approach

Thursday, October 27, 2011

David Sopata


When an organization is faced with the task of implementing PCI compliance for the first time, it can be very difficult to understand where to start.

In most cases organizations do not understand their scope or the options that they currently have to reduce their scope. Understanding this criteria can save time, money, and additional resources needed to meet PCI compliance.

This is where SecureState or another QSA company would come in to perform a PCI gap assessment to understand at a high-level how PCI would apply to current environment. After the gaps are identified, the organization is still stuck with the universal question of “how do we fix it?”

Putting the Cart before the Horse

I work with many organizations that have to deal with implementing PCI controls and the always go straight to writing the policies and procedures. I am really not sure what the reasoning is behind this.

It may be that writing policies and procedures is the most boring part to them and they want to get it over within. Maybe it is because they figure if they write the policy now they can build the rest of their PCI controls and hold to that policy.

What really happens is that the policies and procedures end up being changed and revised so many times that it would have been better to writing the policy last describing their environment and what they do.

Additionally, organizations will start implementing security controls on all of their systems throughout the company without really knowing what systems should be in scope or which systems should not be in scope for PCI. Hence, the PCI DSS Prioritization Document and Tool was developed.

Guidance from the PCI Council

The PCI SSC (the council) came up with this prioritization approach during the PCI DSS version 1.2 (now the 2.0 version available). It was meant to help organizations to set a starting point and milestones and provide a high-level roadmap.

Granted, even the PCI Council stipulates that this method may not fit within your given organization however all requirements must be met for compliance. Not only was the prioritization approach created to give organizations a place to start and milestones to follow but it was also developed to provide the fastest way to reduce PCI risk.

Just recently in May the PCI Council has updated the prioritization approach document and tool for PCI DSS 2.0.

So what are the six milestones that council came up with?

They are as follows:

1.       Remove sensitive authentication data and limit data retention.

2.       Protect the perimeter, internal, ad wireless networks.

3.       Secure payment card applications.

4.       Monitor and control access to your systems.

5.       Protect stored cardholder data.

6.       Finalize remaining compliance efforts, and ensure all controls are in place.

If You Don’t Need It Get Rid of It!

Looking at the order of the milestones they do make some logical sense. The first one starts with removal of sensitive authentication data and limit data retention. The goal of this milestone is to get rid of any type of prohibited authentication data such as the three (or four for American Express) CVV code or full magnetic track data from the credit cards.

It might even make sense to delete all cardholder data all together (tokenization anyone?). Maybe there is no need to store cardholder data (CHD) within your organization after an order or transaction has been processed.

This would also be the time where a discovery process may be performed to delete CHD from systems that should not have CHD such as employee desktops, applications or systems that really do not need to store CHD for any business process. After the unneeded CHD is removed and we can start identifying the systems that are in scope for PCI and start drawing the borders around them.

Segmentation and Drawing your Borders

The second milestone is about drawing the borders around your PCI environment and putting in proper segmentation around your systems. This is where the organization can reduce their PCI compliance even further by segmenting theses systems by using firewalls and router access controls lists (ACL).

These firewall and/or router ACLs should be very granular right down to IP address and TCP/UDP port level. This is how PCI allows organizations to reduce their PCI compliance efforts and making it a more manageable environment. This is also when it would be a good time to start performing security assessments such as vulnerability scans and penetration tests.

Making it harder for the Bad Guys

After segmenting the environment and reducing it to only include the systems that store, process, and/or transmit CHD we can start applying the security controls and hardening techniques to secure these systems. The third milestone is all about securing these systems.

This might include turning off unneeded services functions that are used by those systems and standardizing the systems to ensure they are all at some sort of security baseline. Additional vulnerabilities may have been found during the assessments performed during second milestone. These will have to addressed and fixed as well.

What is happening on my Network?

The fourth milestone is about implementing logging and monitoring of the systems. After the systems have been hardened, logging and monitoring must be put in place to alert and report on anomalies within the environment. Understanding what “unusual behavior,” is within the environment can be a very difficult task to undertake.

There are many solutions out there but not knowing what system are in scope, not having proper segmentation in place, and not turning on the proper logs for the systems could make this area costly and ineffective by wasting time, money, and resources.

Additionally, trying to control access can produce the same effects without knowing what systems are in scope and knowing the capabilities of each system.


After securing the systems and implementing logging and monitoring, it is time to than start securing the data that resides on the systems. This is what the fifth milestone is about, ensuring that the CHD that is required to be stored is also protected.

This includes implementing proper encryption and key management processes for the systems in scope. In many cases, key management tends to be the hardest area that most organizations struggle with when it comes to encryption.

Now it is Time to Document!

Now comes the final step. Documenting what you have done. The sixth milestone is about Policies and procedures and making sure that you have all them in place. In any methodology, there might have been a few road blocks were something had to be skipped to keep the project moving. This is where you would tie up any of those additional “loose-ends.”

Whether you are just about to implement PCI in an environment, or in the middle of a PCI implementation project it might be time to take a step back and ask “Am I following the right approach?”

Possibly Related Articles:
Information Security
Encryption PCI DSS Compliance QSA Network Security PCI SSC Guidelines
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.