Scope is a topic that never gets old, has endless discussions with different points of view, makes you confused and can quite often make you want to bang your head against a wall. But it is arguably PCI’s most fundamental element: afterall, it’s the scope that determines your cardholder data environment.

What do people do?

People tend to limit the scope by applying segmentation and segregation techniques, such as partitioning the underlying network. This typically involves, VLANs, firewalls, and IP/port restrictions in addition to access control policies and procedures. Sometimes the whole CDE is zoned, though this can involve redesigning the boundaries of the environment. Even though segmentation is not strictly a PCI requirement, it is a great shortcut to cutting down your scope and thus lessening the expense. Last week I read Verizon’s 2015 PCI compliance report and I was surprised to find that three-quarters of breached companies had not properly architected, tuned or maintained their firewalls. My interpretation of this is that people tend to mix compliance with security. At the time of the audit everyone tries to desperately tick the box, but fails to keep up and follow ongoing procedures.

Tools of the trade

Three years ago, a great free scoping toolkit was released by the Open PCI Framework Group. This toolkit is the greatest start you can ask for on how to define your cardholder data environment (CDE) and on how to get a grasp on scoping in general. It’s not a silver bullet approach, but it does give you a head start. If you see the big picture of segmentation, not only does it reduce the scope for your PCI compliance, but it also reduces the attack vector if a system gets compromised. The systems that comprise the CDE are categorised as follows:

Category 1
All system components that store, process or transmit cardholder data.

Before doing anything, grab a pen and draw the flow of all your cardholder data to identify all business processes involved. The systems that are directly involved in transmitting, processing or storing cardholder data are Category 1 components. Run through your asset list and check that you haven’t missed any assets. If you don’t have an asset list, then you must start by creating one.

Category 2
System components that have controlled access to a Category 1 system component.
Any system that provides a service to in-scope systems can potentially cause an impact: thus it becomes part of the scope. This category has different sub-categories that aim to capture all underlying grey areas. This is my favourite category because it raises lots of different opinions. People often forget a fundamental thing in information security: risk. As mentioned in a previous blog, PCI gives the flexibility to follow and make decisions based on your preferred risk assessment approach. PCI, at the end of a day, is just a framework to make you mitigate the risk from getting your cardholder data compromised. Nothing is black and white, but your risk assessment will indicate every decision that you will make to strengthen your environment.

Category 2a
System components which, through controlled access, provide security services (e.g., authentication) to a Category 1 device.
Think about your Active Directory or LDAP server(s), or your web application’s payment encryption function. What could someone do to your CDE if they can get the keys to your digital kingdom? What if someone changed the time on the NTP server? That would be catastrophic. Things like this are sometimes incorrectly seen as having nothing to do with your CDE, but the truth is your CDE relies upon them to be secure.

Category 2b
System components which, through controlled access, can initiate an inbound connection to a Category 1 device.

Category 2c
System components which, through controlled access, can only receive a connection from a Category 1 device (i.e. they cannot initiate a connection).
In regards to the above two categories, we have talked previously about and minimising the attack vectors. Starting from the fundamentals to give you an example, every system must have at-least an anti-virus installed. It can be argued that Linux machines do not need one, but you see how the threat landscape is evolving? Linux-affecting viruses are on the horizon. Besides which, an inbound rule will be needed from your anti-virus server to update the signatures to your systems. Does that mean your anti-virus server is in scope? The answer is obvious: yes.

Category 2x
System components which, through indirect and controlled access, have the ability to administrate Category 1 devices.
Because every organisation is different, many categories can be created if the systems in question have no direct access to and from Category 1 systems. As a recommendation, keeping it simple is the way to go: minimise different groups and aim to capture all direct or indirect interactions to Category 1 systems.

Category 3
System components that are isolated from all Category 1 system components.
This category is self-explanatory. It refers to system components that have no direct or indirect involvement with storing, processing or transmitting cardholder data, are segregated and do not provide any sort of service to any Category 1 system.

Parting advice

What I often do is create a scope definition document that explains why a system is in scope and how segmentation is achieved for those things that are not in-scope. Based on my experience, segmentation can be very subjective. Try not to re-invent the wheel but do think hard about what needs to be segmented and seperated. You should carefully strengthen your network architecture, apply strict access control measures, conform to your policies and procedures and always assess the risk. Of course this must be an ongoing process: technology is evolving rapidly so there’s no guarantee your risk assessments and your solutions will be the next year...