At last year’s Community Meeting, there were a couple of instances where members of the PCI SSC reminded organizations that it is up to them to set the parameters of their PCI assessment. A lot of people in attendance took those comments to mean it is up to merchants and service providers to define the scope of their assessment, but it goes further than that.
For years organizations have complained that they receive varying advice from different QSAs even when the QSAs are from the same firm. Obviously this situation is frustrating for not only merchants and service providers, but for the QSAs as well.
To address this situation, the Council is telling all PCI stakeholders that it is up to the organizations being assessed to define the rules of the assessment. Not just the scope, but also what level of risk that the organization is willing to accept. So what does that mean? I intend to clarify that in this post.
And to be extra clear, this is not some excuse to create a set of rules that allow you to skate by. You must show your work and document your rationale. If your QSA has honest concerns about your work, then expect some push back and bringing your acquiring bank into the discussion. If your acquiring bank agrees with your rules, then you need to get that in writing from them and everyone should move on. But if your acquiring bank agrees with your QSA, then expect to make changes to your rules.
Scoping
Scoping is the responsibility of the organization being assessed, not your bank’s or your QSA’s responsibility. This requirement is even explicitly called out in the PCI DSS on page 10, second paragraph, second sentence.
“At least annually and prior to the annual assessment, the assessed entity should confirm the accuracy of their PCI DSS scope by identifying all locations and flows of cardholder data and ensuring they are included in the PCI DSS scope.”
The first step in defining scope is to define the rules of how to scope. This is the toughest part of scoping.
Complain about it all you want, but the Open PCI Scoping Toolkit is a good framework to start the discussion about how to scope a PCI assessment based on the risk presented by devices. My first recommendation is that I would highly recommend that you stick with the three categories. In my experience, organizations that create more categories just end up creating more confusion and consternation. However, there is no way to go with fewer categories without putting your entire network in-scope.
Categories 1 and 3 are not the ones in question. My personal opinion is that having two sub-categories in category 1 seems silly to me. Devices and systems that directly process, store or transmit cardholder data (CHD) or are in use within or define the cardholder data environment (CDE) are category 1 regardless. Category 3 devices/systems are those that never, ever come into contact with the CDE. In my opinion, these two categories are clear cut and pretty straight forward.
Where the arguments occur or will occur most often is over the category 2 devices and systems. You can accept the four sub-categories that are defined in the toolkit or come up with your own. If you are going to define your own sub-categories for category 2, the key point to remember is that category 2 devices/systems have direct or indirect influence over the category 1 devices/systems because they have access in some way to the CDE. The sub-categories are used to define the level or risk or threat these category 2 devices/systems represent to the category 1 devices/systems based on the type of access the category 2 devices/systems have to the CDE.
The difficulty with setting the category 2 sub-categories is that everyone has their own risk tolerance. It is those differences in tolerance that create the problems. Security personnel tend to be more conservative because it is their butt on the line if something bad happens. The further people get away from security, the more risk tolerant people seem to get because they do not have a complete understanding/appreciation of the minutiae.
Experience says that whatever and however you define category 2 devices/systems do it as simply and clearly as possible. I would highly recommend you keep the number of sub-categories to a minimum and that you use examples for each sub-category so that readers understand where devices/systems fall under your sub-categories. The key outcome of this effort is a formal document, similar to the Open PCI Scoping Toolkit that; defines your categories, the rationale for those categories, provides examples for each category and is approved by executive management.
Once you have defined your scoping categorization rules, then it becomes an exercise in categorizing your inventory of networks, devices and systems based on your criteria. Do not be surprised if during this process networks, devices and systems you thought were out of scope suddenly come into scope. This is not unusual because prior to this point you were just taking a scientific wild ass guess (SWAG) as to what was in-scope.
Risk Assessment
Once you have your scoping categories set, you need to roll that methodology into your risk assessment so that you can properly assess your risk. By doing so most organizations find that their risk assessment shows more devices/systems at higher risk because they are now in-scope for PCI compliance.
Take your scoping categories and convert them to weights for evaluating risks. For example, category 1 devices/systems would carry the highest risk weighting available. Category 3 devices/systems would carry the lowest risk weighting allowed. Category 2 systems would carry risk weights somewhere between the highest and the lowest based on how you have defined your category 2 sub-categories.
Define Your Terminology
This is very straight forward, but is usually missed by most organizations. Organizations need to define their terminology. In particular, what the organization means by ‘significant change’, ‘period’ and ‘periodically’. I wrote a post on this very topic a while back so I will not bore you here with that discussion. These are very important definitions that must be set.
However there are likely other terms that should be defined for your QSA and anyone else without intimate knowledge of your technology environment. My personnel pet peeve is the lack of definitions of acronyms that are commonly used by your organization but that might be easily misunderstood by anyone else. It never ceases to amaze me when people inadvertently treat an outsider as an “idiot” when they speak in acronyms and the outsider has no clue as to what was said because they are not insiders.
My favorite example of this was a person that kept referring to the ‘HSM’ during our interview. Given this was a PCI assessment, my assumption was that they were referring to a hardware security module, however the way they used ‘HSM’ in our interview seemed to be in the wrong context. So I asked them and they confirmed my suspicion, they had been referring to a custom application called high-level system messaging. Had it been in a mainframe environment, HSM could have been a reference to hierarchical storage management. This is why a glossary of terms and acronyms is a good thing to build, not just for PCI but for any newcomer to your environment.
Discuss This With Your QSA
Finally, do not keep your QSA in the dark as you work through this process. As you create your documentation and classify your devices and systems, run this all by your QSA to get their buy in before they start your assessment. Most organizations will not run into too much push back from their QSA unless they are trying to set the bar too low in a vain attempt to make the PCI compliance process too easy, i.e., checking a box. The last thing you should do is spring this on your QSA the day they start your assessment. And that includes if you update or change your rules between assessments.
All of this effort should result in a much more straight forward assessment because you have defined the rules and criteria to which you are to be assessed.
PCI Guru 
Does segment from CDE mean the CDE is completely isolated with no ports exposed? Just wondering if it is allowable to have a port open other than rdp or ssh to a machine in the CDE. I am taking a strict interpretation but there are others that think some services might be allowed.
This all comes down to how much risk is you and your organization are willing to accept.
Based on how you phrased your question, you would appear to be leaning more toward the security “purists” that believe isolation is the only way to construct the CDE. I tend to sit more in the middle where some ports need to be open, but those ports need to be justified as to why they need to be open and then those ports need to be monitored. In today’s connected world, I just do not see pure isolation as feasible – see this post https://pciguru.wordpress.com/2014/07/27/the-dilemma-of-pci-scoping-part-1/
To minimize ports that need to be open, a lot of organizations implement the out-of-band (OOB) or “jump” box approach. The jump box is a remote access portal that provides access to the CDE but only allows RDP/SSH/etc. remote access. Jump boxes also usually have software to record all session actions so that, in the event of an incident, the entire session can be replayed to determine what exactly was done. Jump boxes are typically a bastion configured virtual desktop (VDI) solution such as with VMware or Citrix, but can be physical or logical servers using RDP.
I agree with what you said. It is certainly not feasible for the majority of organizations to create a purely isolated environment.
There are some that want to limit the scope to a narrow set of servers while leaving poorly secured applications, practices and servers outside of the CDE untouched. Then they want to apply all the rules for PCI DSS to only those hosts in that environment. I am trying to determine if there is any wiggle room in the spec for this interpretation.
I want to do what I would consider to be reasonable segmentation of the machines in the CDE. Access would be through a jump box to those authorized. This would be the only network segment where we would record actions taken on the servers but I would apply most of the other DSS recommendations to the rest of the network.
Systems that have connectivity to the cardholder data environment (CDE) are still in-scope regardless of how minimal that connectivity might be. As a result, those poorly secured applications and servers still need to be assessed and addressed. There will always be some amount of connectivity between the CDE systems outside the CDE, so all you can do is minimize the number of connected systems. The approach you outline seems reasonable, but it is all in the execution. So I cannot say if your actual implementation will be PCI compliant.
This is very helpful. I’ve been having this exact argument with a company I’m currenlty assessing. I’ve referred the stakeholders to this article. I’m actually pleased to see that your article exactly describes my personal process for assessing organizations. Often times, it seems we’re all alone in this when we go onsite, by ourselves and struggle with the assessed company to understand scope. I actually wrote a document, based off your article, on the meaning of significant change. Significant change can be summed up simply as anything that affects the security of the CDE.
This is the problem with PCI assessments and similar efforts. If you do not specify the rules, then you get the rules of the individual assessor/auditor, not the organization’s rules.