Scope reduction often leads to work and cost reduction
WEBINAR: Reduce your PCI Scope
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 reducing your PCI DSS scope and highlights guidance from the PCI council as well as the factors you need to consider.
What is PCI scope?
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:
- Networking devices
- Computing devices
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.
PCI Council: how to reduce PCI DSS 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.
First, understand the flow of cardholder data
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.)
Examples of cardholder data inflows (How does card data come in?)
Mobile POS system
Mail order/telephone order systems
Outsourced processes processing under your merchant ID
Examples of cardholder data outflows (Where do you send cardholder data after payment?)
Backup server (Do you do backups on your system? Are they encrypted? Is your backup server at a different data center?)
Third party that stores or handles Primary Account Number (PAN)
Outsourced management of your systems or infrastructure
Now that you understand what happens around the black box, what happens inside? Consider these questions:
Is your website hosted at your location or through a third party?
Does your system batch at the end of the day?
How does your terminal connect? (Internet, cellular, analog, etc.)
Does card data go into a storage database?
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.
How to create a card flow diagram
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.
How is your network constructed?
Is there one firewall at the edge of your card processing environment?
Is your network segmented internally?
Does your environment have a multi-interface firewall?
Do you have multiple firewalls?
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.
An important note about PAN storage
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.
How to get rid of PAN in your environment
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.
Don’t store PAN
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:
File integrity monitoring (FIM)
Intrusion detection or intrusion prevention (via IDS/IPS)
Annual penetration testing (internal and external)
Physical security with the systems that store sensitive data
In addition to the entire PCI DSS standard
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!
Make sure you comply with PCI
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.
Outsource PCI aspects
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.
Consider P2PE implementation
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.
Start network segmentation
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.
Know your inflows and outflows. Until you know your flows, you don’t know what to secure.
Use a card data discovery tool. This tool will help find the caches of card data in your environment. Once you identify them and identify the process that created the cache, decide if you really need to continue these processes.
Not-in-scope systems don’t require PCI. PCI requirements are best security practices but aren’t necessarily required for network segments not in scope.
Decide. Is reducing scope worth it to your organization?