PCI Consultants Say: Reduce PCI DSS Scope
Scope reduction often implies work and cost reduction.
 |
| By: Matt Halbleib |
So, you want to reduce your PCI scope? Perhaps you’re looking to reduce workload. Or maybe you’re just ready for your PCI costs to decrease. Let me take you through the process of reducing your scope.
SEE ALSO: PCI DSS Supplemental Guide to Scope: Understanding PCI DSS Scope and Segmentation
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
- Firewalls
- Servers
- Switches
- Routers
- Computing devices
- Applications
SEE ALSO: Finding and Reducing PCI Scope: How to Make Compliance Easier
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.)
Let me provide some examples.
Examples of cardholder data inflows (How does card data come in?)
- POS system
- Mobile POS system
- Ecommerce website
- Mail order/telephone order systems
- Virtual terminals
- Outsourced processes processing under your merchant ID
Examples of cardholder data outflows (Where do you send cardholder data after payment?)
- Processor
- Back-of-house server
- 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 PAN (Primary Account Number)
- Outsourced management of your systems or infrastructure
For example:
- 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?
Make a card flow diagram
The latest version of the PCI DSS (PCI 3.1) 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 of 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?
An important note about PAN storage
If you electronically store the Primary Account Number on credit cards (also known as PAN), you automatically qualify for a PCI SAQ D. SAQ D has 335 requirements.Storing PANs is the #1 thing that increases your scope, and the problem is, many merchants don’t know they store unencrypted PANs. In the latest study by SecurityMetrics, 61% of merchants were found to store unencrypted PANs.
Let me give you an example of unknown card data storage. Finance often receives bank statements with full cardholder numbers. Do you have a refund process? Sometimes the finance team 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 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 (I recommend 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.
---Tips to reduce PCI scope---Don’t store PAN
TweetIf you don’t need PAN, don’t store it! Those that store PAN qualify for SAQ D, which has a whopping 335 requirements.
If you 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 the data
- Firewall
- Change control
- Internal/eternal scanning
- And…the whole PCI DSS standard
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. That seems like a good decision at first, because it increases sales by making it easier for your customer. The downside is, you’re electronically storing PAN.
If 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 only 14 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 3.0 recently clarified that there are 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, and other PCI 3.0 changes in mind as you reduce your scope and comply with 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 questions.
Consider tokenization
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 still not storing the 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 (in turn, reducing 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 PCI. Each system has the ability to talk to every other system.
 |
| Example of a flat network |
A way to properly segment a network without a firewall is through an air gap. Air gaps just 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.
Takeaways
- 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 helpfind 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 it.
- Not-in-scope doesn’t require PCI. PCI requirements are good security practices but aren’t required for network segments not in scope.
- Decide. Is reducing scope worth it to your organization?
