Based on the email comments of late, there are apparently a lot of you out there that really do not like the Open PCI Scoping Toolkit. I am not sure exactly what post where I mentioned the Toolkit got you all wound up, but I have definitely hit a nerve. From the comments in these messages, it is painfully obvious that the reason the SIG failed was that none of us are in agreement about how much risk we are willing to accept. And that is why no PCI assessment is ever the same because organizations and even QSAs from the same QSAC can have different levels of risk tolerance.
I, too, have to admit that I think the Toolkit needs some work, but it is the best framework we have to start a discussion on the topic. And that is the problem, the topic. Until the Toolkit appeared, scoping discussions had no real framework and everyone had their own definitions. And as I have pointed out before, while there are a lot of people out there that might not know the nuances of the PCI DSS, it seems that everyone “knows” what is in scope and what is out of scope.
As a result, QSAs have found out through the “School of Hard Knocks” that everyone has their own view of scope and there was no good guide to explain how or why to draw the line let alone discuss the topic civilly in some cases. I view the Toolkit as the bare minimum. If an organization wants to get even more restrictive and have more categories, great, that is their prerogative. However, if they want to go less than the Toolkit, in my very humble opinion, they can do it without me. The bottom line is, regardless of whether you are using the Toolkit or have your own approach, document the definitions of your categories and provide examples so that everyone can understand your rationale and then discuss the impacts on your organization’s PCI scope. Without such a document, we are not going to have productive discussions on scope. That is why I lean toward the Toolkit, it gives me a starting point to get a productive discussion started.
We seem to all be able to agree on the Category 1 and 3 systems, because those are clear and easy to identify. Category 1 systems are always in the cardholder data environment (CDE) because they directly process, store or transmit cardholder data or define the CDE and are therefore always in-scope. Category 3 systems never, ever process, store or transmit cardholder data and are therefore always out of scope.
It’s those pesky Category 2 systems (the ones that connect in some way to/from the CDE) that get everyone’s undies in a bunch. The group that developed the Toolkit did their best to break them out in ways that made sense but were still understandable and easy to use. The more that I have thought about it, the more I think they came up with the best compromise. In my opinion, if you start adding any more categories or sub-categories to the existing definitions you will lose almost everyone due to complexity, including security people. However, I also don’t believe that simplifying Category 2 is an answer either.
But if the discussion about Category 2 is tough, the fact that the Toolkit allows for Category 3 systems to exist on networks with Category 2 systems sends some security purists right over a cliff. Their rationale is that Category 3 systems could be easily attacked and therefore allows a beachhead to compromising Category 2 systems. While this is true, the idea of totally isolating Category 2 systems is not realistic for most organizations because of the ramifications of such a decision.
Why Isolation Is Not An Option
Security purists seem to think isolation of the CDE is the answer. From an outsourcing perspective, that would provide isolation. But in my experience, even outsourcing is not as isolated as one would think. Here is why I think that isolation does not work whether doing it internally or through outsourcing.
Isolation means physically and logically separate directory systems with no trust relationships between the isolated environment and normal production. I have seen all sorts of technical gymnastics to secure directory systems inside the CDE that can still leave too many holes in firewalls so that the trust relationship can exist. If you are truly serious about isolation, then you need to have true isolation and that means physically and logically separate directory systems. This also means duplication of credential management and introducing the possibility of errors when provisioning accounts.
The idea of leveraging your existing solutions for network and application management must be rethought as well. This means separate security event and information management (SEIM) solutions, separate network management and monitoring, separate application management and monitoring, etc. I think you get the idea.
Of course separate firewalls, routers, switches, intrusion detection/prevention, load balancers and other infrastructure are also going to be needed. If you use RADIUS or TACACS+ for authentication, you will have to have separate systems for authentication to the infrastructure as well. You will also need separate DNS and DHCP servers if you intend to provide those services inside the CDE. Of course all of this duplicated infrastructure adds to the likelihood that mistakes will be made in configuration changes that could result in a breach of that isolation.
There are no “out of band” or virtual terminal access into your pristine isolated environment. So you will need to provide separate PCs for operations and network personnel so that they have access to the isolated environment and then another physically separate system to your organization’s normal work environment. Internal users with access to cardholder data (CHD) will also be required to have physically separate PCs for accessing the CDE. This will also mean ensuring security of network switches inside the CDE by using MAC filtering or “sticky” MAC approaches to ensure that only the PCs that should have access to the CDE do have access. And of course wireless networking is totally out of the question.
But wait, you will also have to invest in some sort of portable media solution so that you can get data from the isolated environment to the “normal” production environment and vice versa. No connected databases or application integration because that will require holes into and out of the isolated environment. This is where outsourcing for isolation also comes up short. But without application and data integration, the economies of scale shrink almost exponentially as more and more data must be manually moved between environments. This drives the cost of isolation almost through the roof and typically makes isolation too expensive for most organizations.
Various government entities have all tried this approach with mixed results as far as breaches are concerned. So in practice, the isolation approach will still leave your organization with some amount of risk that must be managed.
So if isolation is not the answer what is the answer? In Part 2 I’ll discuss what I think works.