If you don’t have a compelling business need to store PAN, don’t store it!
So, you want to reduce your PCI scope? Perhaps you’re looking to reduce workload. Or maybe you need to reduce your compliance-related costs. This post will take you through the process of how to reduce PCI DSS scope and will highlight guidance from the PCI council as well as the factors you need to consider.
Before we discuss how to reduce PCI scope, we must first define what it is. The PCI DSS defines scope as “the PCI DSS security requirements [that] apply to all system components included in or connected to the cardholder data environment.”
A cardholder data environment is comprised of people, processes, and technologies that store, process, or transmit cardholder data or sensitive authentication.
Here’s a quick list of system components that are probably in scope in your environment:
The bottom line is: if the people, process, technology, or component stores processes or transmits cardholder data, or is connected to systems that do, or can impact the security of cardholder data, it’s considered in scope.
In December, 2016, the PCI Security Standards Council (SSC) released a supplemental guide for scoping and network segmentation.
The purpose of this guidance is to help organizations identify the systems that need to be considered in scope for PCI DSS and understand how segmentation can reduce the number of those systems.
See also: PCI DSS Supplemental Guide to Scope: Understanding PCI DSS Scope and Segmentation
See also: SecurityMetrics PCI Guide
Think of your whole environment as a black box. Right now, don’t think about what’s in the box. Instead, think only of the inflows and outflows of cardholder data into and out of the box.
How does cardholder data enter in your environment and to whom do you send it? Remember, even infrequent flows are still in scope for PCI. (Yes, even if it only happens every quarter or once a year.)
Take a good look at your systems where the flows actually touch and anything connected to those systems. This will help you understand which systems are in scope for PCI.
See also: Finding and Reducing PCI Scope: How to Make Compliance Easier
PCI DSS requirement 1.1.3, requires merchants to have a current cardholder data flow diagram. Once you know your flows and know what systems they interact with, you can easily create a card flow diagram, which details how card data moves within your environment.
Note that a card flow diagram is required for each data flow in your organization.
Examine the actual network and decide how it fits into your card flow diagram.
For this part of the scope reduction process, you must understand the actual components that make up your network. Only then can you can overlay the card flows onto the systems in the network environment, and diagram and understand which systems store, process, or transmit cardholder data. Those will be the ones in scope for PCI.
If you electronically store Primary Account Numbers of credit cards , you automatically qualify for a PCI SAQ D.
Storing PAN data is the largest factor in increases your scope, and the problem is, many merchants don’t know they store unencrypted PAN data. In the latest study by SecurityMetrics, 61% of organizations were found to store unencrypted PANs.
Let me give you an example of unknown card data storage: Finance departments often receive bank statements with full cardholder numbers. Do you have a refund process? Sometimes finance teams will get a notification of a disputed transaction via email and because they have data retention requirements, they’ll print that information and keep it on file.
The point is, as you are defining your environment, it’s important to ask all organizations and departments if they receive cardholder information, and then define exactly what that means to your card flows.
To avoid being in the dark about your own PAN storage, make sure you ask your vendor exactly how your POS system works. Does it store cardholder data? Does it write cardholder data to a database and keep a transaction record for 30 days to easily process refunds?
In addition, I always ask my clients to run a cardholder data discovery tool (such as PANscan®). These tools help you find PANs, processes, and flows you didn’t know existed. Once you identify new processes, you can begin to determine what you can do to either fix the process or add it into your normal environment processes.
If you don’t need PAN, don’t store it! Those that store PAN qualify for SAQ D.
If you do store PAN, you are required to do:
Qualifying for an SAQ D definitely does not reduce your scope.
I know you might think storing PAN makes life easier. Perhaps you process a lot of refunds. Perhaps you store credit cards for recurring customers. Storage might seem like a good decision at first because it increases sales by making it easier for your customer. The downside is, you’re storing PAN.
If you must store PAN, consider an alternate method. Can your bank store the card numbers, and then provide you access through a portal when doing refunds? Can you outsource the entirety of your payment page to a third party? (If so, that qualifies you for SAQ A, with significantly less requirements.)
Bottom line is: If you don’t have a compelling business need to store PAN, don’t store it!
PCI also requires compliance for secondary systems in scope for PCI (such as log servers) and some that reside outside of the typical card data environment (such as DNS.) Keep these systems and PCI changes in mind as you reduce your scope and comply with the PCI DSS.
When correctly arranged, outsourcing is a great way to reduce your scope. Could service providers take on some of your more daunting PCI requirements, such as firewall management, log collection/monitoring, or systems hosting?
If you don’t have to hire personnel to manage outsourced devices, you can free up internal resources.
Another option for scope reduction is point-to-point encryption or P2PE. In a nutshell, if you properly implement a P2PE validation solution and have no access to unencrypted data or encryption keys, you may qualify for a P2PE SAQ (with only 35 requirements).
Tokenization completely replaces the PAN in your environment so you can store tokens in your database.
Just make sure that if you implement tokenization, you’re not still collecting PAN or storing old caches of PAN in your environment. Make sure you run data discovery tools to find all PAN caches so you can replace them with a token.
Anytime PAN is removed from an environment, risk is reduced.
Network segmentation is one of the best ways to reduce the systems that store, process, or transmit card data, and in turn, segmentation reduces your scope. Network segmentation is a method of separating systems that store, process, or transmit cardholder data from those that don’t.
Oftentimes when interacting with customer networks, we find merchants have big flat networks with a firewall at the edge, but that’s it. Everything inside the network can talk to everything else. Flat networks make securing your card data extremely difficult because your entire network is in scope for the PCI DSS. Each system has the ability to talk to every other system.
Here’s a great example of network segmentation via a firewall. Say you install and configure a multi-interface firewall at the edge of your network. From there, you create one interface on the firewall dedicated just to the systems that store, process, and transmit cardholder data. If this interface doesn’t allow any other traffic into or out of any other zones, that’s proper network segmentation.
A way to properly segment a network without a firewall is through an air gap. Air gaps mean having truly separate network environments for card data environments. Specifically, the actual network equipment that runs the card data environment is totally separate from your office environment.
.svg)
