So I just had a PCI Gap Assessment done and I still do not know where to start..
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 their current environment. After the gaps are identified, the organization is still stuck with the universal question of “How do we fix it?”
I work with many organizations that have to deal with implementing PCI controls and they 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 with right away. 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 write the policy last and describe 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.
The PCI SSC (the council) came up with this pci prioritization approach during the PCI DSS version 1.2. It was meant to help organizations set a starting point, 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:
- Remove sensitive authentication data and limit data retention.
- Protect the perimeter, internal, and wireless networks.
- Secure payment card applications.
- Monitor and control access to your systems.
- Protect stored cardholder data.
- Finalize remaining compliance efforts, and ensure all controls are in place.
While looking at the order of the milestones, they do make some logical sense. The first one starts with the 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 when 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, we can start identifying the systems that are in scope for PCI and start drawing the borders around them.
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 an IP address and TCP/UDP port level. This is how PCI allows organizations to reduce their PCI compliance efforts and make 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.
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 the second milestone. These will have to be addressed and fixed as well.
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 systems 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 then 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 comes the final step, documenting what you have done. The sixth milestone is about Policies and Procedures and making sure that you have all of them in place. Additionally, like any methodology, there might have been a few road blocks where 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?”