5 min read

Understanding "Connected-to" - Is The Internet In Scope For PCI DSS?

Picture of David Gamey David Gamey : Dec 7, 2017 10:07:00 PM

pci internet

PCI DSS is all about scope. Getting scope right or wrong is perhaps the single most critical factor determining the ultimate success or failure of an organization's compliance.

While determining scope is the responsibility of the assessed, validating scope is the responsibility of the assessor. What that means is that an organization can't arbitrarily choose their scope or exclude things, their decisions must be credible and consistent within the framework of the DSS.

Any organization being assessed that uses inconsistent approaches to scoping, can expect potential disagreements in scoping methodology leading to unpleasant surprises and experiences. Organizations having to secure new found scope will often require the investment of significant expense and effort to achieve timely remediation.

Clearly, it is critically important to understand the current scoping rules of PCI DSS. We emphasized the word current because the interpretation and rules around DSS scoping have been clarified and evolved as the standard matured. Unfortunately, this evolution can lead to confusion if not everyone is on the same page.

How Scoping Has Evolved

Before we get into the current rules, it may be useful to understand some of this evolution and clarification from the early DSS until today:

Systems and applications that stored, processed, or transmitted cardholder data
Inclusion of all systems on the same network as cardholder data systems
Extension of scope to people, processes, and technology
Inclusion of security systems
Clarification on e-commerce redirection methods

It's also important to understand that these changes eased into PCI, initially being understood as best practices or the intent of the standard, and only later being codified.

There have been several efforts to provide better scoping guidance over the years. The PCI council set up a working group to look at scoping in 2010 which produced some draft documents. In 2012, the Open PCI Scoping Toolkit (OPST) was published by third parties. While not officially endorsed by the council, the toolkit was clearly similar to the approach taken by the previous SIG. The OPST is quite well structured but could lead to disagreements over risk. Later, the council published their own guidance on Scoping and Segmentation in 2016 and updated it in 2017.

The language of PCI also reflects this evolution. The terms "Connected-to" and "Security-impacting" being just two of the PCI-isms that you will hear in scoping discussions. In particular, the meaning of "Connected-to" has evolved. It originally was used to focus on the connections of same network systems or what we sometimes refer to as Big Flat Network issues. Today, "Connected-to", literally means a connection that is agnostic to media (e.g. cable, wireless), protocols, and network access controls (e.g. firewalls).

Scoping Today

The PCI council scoping guidance is published in the PCI Document Library on their web site (see Learn More below). One of the key artifacts here is an info-graphic showing PCI DSS scoping considerations and criteria.

PCI Scoping Figure

This info-graphic is clearly covers the issues. There isn't a lot that we would recommend changing or clarifying. Nonetheless, we still see people getting confused about scope and question specific wording rather than focusing on intent.

We've seen all kinds of debates on scope, some examples:

"The word-smith" : "the systems on the second site LAN extension aren't in scope because it is a different (unfirewalled) segment"
"Living in a Non-security Silo" : "but the source code control system for our payment application isn't security impacting"
"The confused": "But the XYZ system connects to ABC company and to customers on the Internet so they must be in scope too?"

While we see all kinds of debates on scope, the numbers of people that get confused about the rules suggests that the message isn't getting through clearly. We wondered, why this might be? And if there is a better way to explain it?

Scope vs. Compliance Footprints

We think part of the problem is that people are confusing the being "in-scope" for PCI DSS with the applicability of the requirements. This is something we refer to as a "Compliance Footprint" and have written about before (see Learn More below).

The first thing we noted in Figure 1 was the top two boxes in the "Connected-to" or "Security-Impacting Systems" group: "System components directly connected to the CDE" and "System components indirectly connected to the CDE". Examples of the first group could be things like a pin pad on a serial cable, a USB printer, a Bluetooth device, or every system at another location on the WAN. The second group could be connections through firewalls and/or proxies. This is often where people get a bit far afield.

Consider that many companies have business partners that connect to their systems. Q: Are they "in-scope"? A: "Yes". But the real money question is "How are they in scope?" Some common ways include:

A service provider that has validated their compliance for the services provided (Covered in DSS 12.8 and 12.9)
A service provider that has not validated their compliance and will need to have applicable services validated as part of your assessment
Another third party connection that can be demonstrated to pose no risk to the PCI environment (e.g. retrieves reports of truncated card data from your reporting system)

The last case can confuse people, they naturally want to argue that the third party system is out of scope. It helps to understand that "in-scope for DSS" is another example of PCI jargon. Scope doesn't mean exactly what people think it means. What has really happened, is that your organization assessed the risk of that connection and concluded that no PCI DSS requirements applied because your architecture treated it as untrusted and implemented appropriate security measures. Basically both ends of the connection are in scope, but one end doesn't matter.

Shrinking Footprints

This leads us to our last piece of PCI jargon "in-scope for all applicable requirements". When something is in scope for PCI DSS it doesn't necessarily follow that all DSS requirements apply. There is specific guidance that makes it clear that not all requirement apply in all cases (see Learn More below). The various SAQ forms are evidence that there are examples of use cases where only subsets of the requirements apply.

This leads us to an interesting conclusion and one that sounds very strange, it is possible to have systems in-scope for PCI DSS with zero applicable requirements! What this means is the connection is in scope, the connecting system is untrusted by design, and the system was designed and verified to deal with that untrusted system.

By this point, you are likely to think that this is merely an academic statement of no practical value. If you think that, you are mistaken. Not only is this possible, it is actually common. The following examples illustrate this.

In P2PE solutions, merchants deploy encrypting terminals connected to POS systems and networks. In these deployments the terminals are in scope for a small number of requirements (see SAQ P2PE) and the connected POS system and network have no applicable DSS requirements.
The example, used previously, on a non-PCI report (e.g. truncated settlement reports) is another example.

While most people will naturally see a system with zero applicable requirements as being "out-of-scope" on a practical level, it is important to understand how you get there in order to deal with other types of connected systems.

You could even use this approach to explain away e-commerce customers. Again, the central point of the argument would be that the e-commerce server was designed to work with untrusted client systems. So even if they were not out of scope by definition, it could be argued that they don't matter because there are no applicable requirements.

Scope Is About Connections!

The takeaways from this are that scope is not just about systems and networks, and that a large scope doesn't always mean a large footprint. Scope is inherently about connections. Footprint size is about the associated risk of those connections.

Applying This In Practice

If you want to apply these ideas in practice, you need to document your position.

Don't shy away from a scope because it's large or drags in many connected-to systems
Do show you understand the connections in your environment
Do show you understand the risks of each connection/application/protocol
Do validate (i.e. test) to ensure your low/no risk connections are in fact no/low risk

Remember, it’s wrong to think of PCI as just securing systems and networks. It secures connections and by definition it secures applications.