Read to learn tips to reduce your current PCI scope, which may help you save money on managed services, decrease internal resources, and reduce your long-term workload.
This post contains the text from the White Paper: 5 Tips to Pay Less for PCI Compliance.
With past changes in the PCI DSS, many organizations have found that it’s more expensive and difficult to keep up with PCI compliance’s latest data security requirements. The most dramatic changes were the introduction of new Self-Assessment Questionnaire (SAQ) categories and extended PCI scope.
This white paper discusses tips to reduce your current PCI scope, which may help you save money on managed services, decrease internal resources, and reduce your long-term workload.
Scope deals with environment systems that must be tested and protected to become PCI compliant, while SAQ is simply a validation tool for merchants and service providers to self-evaluate compliance with PCI DSS.
Here’s a quick list of system components that are probably in scope in your environment:
The bottom line is: if the people, processes, technologies that store, process, or transmit card data (or is connected to systems that do), it’s considered in scope.
This category relates to all systems and networks that are directly involved in the CDE, meaning that the system component stores, processes, or transmits cardholder data. The system can also be on the same network segment as systems that deal with cardholder data.
These types of systems are all part of the CDE, and they need to follow all applicable PCI DSS requirements to protect cardholder data. Sample systems considered in-scope:
A cardholder data environment is comprised of people, processes, and technologies that store, process, or transmit cardholder data or sensitive authentication.
This category refers to all systems that are connected to the CDE, either directly or indirectly. Due to this connectivity, these systems can affect the security of the cardholder environment, and all applicable PCI DSS controls must be implemented to reduce the risk of a security breach through one of these connected systems.
Connected-to systems are system components that:
Other connected-to system examples include:
Previously, organizations commonly thought that if systems did not directly, store, process, or transmit cardholder data, they were considered out of scope and the majority of PCI DSS requirements did not have to be applied to them. However, the PCI Council has made it clear that connected-to systems are also considered in-scope, and all applicable PCI DSS requirements must be in place for any system connected to the CDE.
An out-of-scope system is a system component that:
To be considered out of scope, controls must be in place to provide reasonable assurance that the out-of-scope system cannot be used to compromise an in-scope system component. Here are some examples of controls you can use:
To be considered out of scope, a system component cannot have access to any system in the CDE.
Only if the system component meets all these requirements will it be considered out of scope. The problem many businesses have is determining whether something is out of scope.
Sample systems often considered out of scope, as long as they don’t have CDE access:
Out-of-scope systems can still pose a risk to the organization and possibly the CDE if they’re not properly secured. While not required, best practice is to implement PCI DSS controls on out-of-scope systems to prevent them from being used for malicious purposes.
Reducing scope means that you either outsource or change aspects of your PCI compliance. For example, you can outsource your management of firewalls, or you can change where you store primary account numbers (PAN) to your merchant’s system.
What does reducing PCI scope do for your organization? Reducing scope, particularly by removing or outsourcing PAN, can change which SAQ you qualify for (decreasing the number of SAQ questions you are required to follow). This means that you will have to spend less time and internal resources for PCI compliance.
Reducing scope means that you either outsource or change aspects of your PCI compliance.
To reduce scope, you must understand the actual method you use to process card data. Only then can you look at procedures that can be eliminated or outsourced.
Think through the different processes of how cardholder information is received and sent via your network. How does cardholder data enter in your environment? What devices are you using to collect cardholder data? Where do you send the data? How do you process this information?
Your answers to these and similar questions will help determine the exact breadth of your PCI scope.
Remember, even infrequent flows of cardholder data are still important and will affect your PCI scope, even if they only happen once a year.
Here are some specific examples to get you thinking of how cardholder data flows in your network:
How does card data come into your network?
What happens to the cardholder data inside your network?
Where do you send cardholder data after payment?
Keeping track of all cardholder data flows, what systems they interact with, and where card data is stored at your organization can be difficult. That’s where a card flow diagram comes in.
Requirement 1.1.3 requires you to have a current cardholder flow diagram for all card flows in your organization. A card flow diagram is simply a graphical representation of how card data moves at your organization.
To accurately craft your card flow diagram, ask yourself questions such as:
Think of your card flow diagrams as card processing spring-cleaning. Imagine you are doing a little spring-cleaning, and you find a storage box labeled “Christmas.” After opening it, you find Christmas lights but also gardening sheers inside.
Card flow diagrams are like that box. Often businesses believe their labeled boxes (or card flows) are set up a certain way, and contain certain things. In reality, they are much different than originally thought.
Mistakes in the flow of card data could have been made in a variety of ways. Perhaps a point of sale terminal was set-up incorrectly. Maybe an employee went in after the system was correctly set up and accidentally changed a process, much like accidentally placing gardening sheers in a Christmas storage box. There are many possible ways of making mistakes in how you process and store your card data.
Like relabeling storage boxes after a thorough spring-cleaning, card flow diagrams help you know which processes must be changed for better organization. They also show possible ways to reduce your scope, like condensing all gardening supplies from five boxes into one.
PAN (Primary Account Number): The digits on the front of a payment card. Also called a bankcard number. You are allowed to store full card details with the exception of track data, if properly encrypted.
When defining scope it is important to understand the impact of storing card numbers, especially if they are unencrypted.
If you electronically store the PAN on a credit or debit card, you automatically qualify for PCI SAQ D, which has over 329 requirements.
You are also required to make sure all stored PAN is encrypted. The problem is, many merchants don’t know they store unencrypted PANs. In the latest study by SecurityMetrics, 85% of PANscan users were found to store unencrypted PANs.
Do you have a refund process? If so, you may store PAN. For example, finance departments often receive bank statements with full cardholder numbers. Sometimes the finance team will get a notification of a disputed transaction via email and because they have data retention requirements, they’ll save that information without encryption..
Therefore, as you are defining your environment, it’s important to ask all organizations and departments whether they receive cardholder information or not. Then you need to define exactly how this changes 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. For example, does it automatically 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, you should regularly run a cardholder data discovery tool (such as PANscan). These tools help you find unencrypted PAN data and where it resides. Knowing where PAN data is stored helps you to confirm whether or not your CDE is what you think it is. It also helps you to identify which processes or flows might need to be fixed. 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.
Knowing where PAN data is stored helps you to confirm whether or not your CDE is what you think it is.
Emails are one of the most difficult aspects to secure and remain PCI compliant. If you do receive PAN over email, it needs to be encrypted. You should not accept any unencrypted PAN over email because once it enters the public domain of the Internet; it is almost impossible to protect. We recommend you find an alternative solution if it regularly happens in your environment.
In most cases, your customer is sending you an eFax and sending it by email, which needs to be encrypted (even if it is in PDF format). Yet if your customer is sending you a fax, the phone system is not in scope; you only need to make sure that the fax machine is in a secure area and that you monitor incoming faxes.
If the gift card you accept is not one of the five major brands’ (VISA, Mastercard, Amex, JCB, and Discover), then the gift card vendor sets the requirements to secure the credit card information. This means that gift cards are not required to be protected by PCI DSS regulations.
Now that you understand what scope is, and how to define it at your unique organization, how do you reduce your scope to decrease your workload? Reducing scope is done by either outsourcing or changing aspects of your PCI compliance, specifically processes dealing with PAN data. Reducing scope often changes the SAQ you qualify for and decreases the number of SAQ questions you are required to follow.
SAQs with bigger scopes require increased security measures and additional testing procedures, which expands your staff’s workload in order to fulfill an intensive SAQ. The more rigorous the SAQ, the more time consuming it can be for your staff to make sure the proper security measures are in place. It also can be so complicated that it requires assistance from expensive managed systems (particularly IT services).
The following are tips to help you reduce your PCI scope, so that you can decrease your workload and save you time and money.
Reducing scope often changes the SAQ you qualify for and decreases the number of SAQ questions you are required to follow.
Those that store PAN qualify for SAQ D, which is quite extensive when compared to other SAQs like SAQ A.
SAQ D includes requirements covering:
Qualifying for an SAQ D does not simplify PCI compliance.
You might think storing PAN makes life easier. For example, perhaps you process a lot of refunds. Or perhaps you store credit cards for frequent customers. That seems like a good decision at first because it increases sales by making transactions faster for your customers. The downside is you still store PAN and qualify for an SAQ D.
If you must store PAN, consider an alternate method. For example, 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, you potentially qualify for SAQ A, B, or C.)
Bottom line is: if you don’t have a compelling business need to store PAN, don’t store it!
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 have your staff spend more time on other job duties.
However, it is important to understand that outsourcing all aspects of PCI compliance does not necessarily take away all of your responsibilities. PCI requirements 12.8 and 12.9 require that you specify who is in charge of which PCI aspects. For example, you are required to provide a list of all third party service providers in use, all PCI requirements the service providers meet, and the PCI requirements you are required to meet.
Requirement 12.8 specifically requires a clear delineation of roles, with both parties signing an agreement acknowledging their responsibilities. You also need to maintain a program to monitor service providers’ PCI DSS compliance status at least annually.
Outsourcing is a great way to reduce your scope.
Another option for scope reduction is point-to-point encryption (P2PE). P2PE is defined by PCI DSS as a process “provided by a third party solution provider, and is a combination of secure devices, applications and processes that encrypt data from the point of interaction (for example, at the point of swipe or dip) until the data reaches the solution provider’s secure decryption environment.”
A POS terminal is the most common P2PE process.
The POS terminal process is as follows: first, the data is entered into the point of sale terminal; then before the data is stored or transmitted, it is transformed into unreadable code, and finally, only with a special key can the data become readable once again.
Because card data is immediately encrypted as the card is swiped, it prevents non-encrypted information from residing on the payment environment, even for one millisecond. Even if a hacker installed memory scraping software on the POS register, it would only pick up useless strings of encrypted card numbers with no way to decode them.
In a nutshell, if you properly implement a P2PE validation solution and have no access to unencrypted data or encryption keys or the system that controls the keys, you may qualify for a P2PE SAQ, with only 33 questions.
The most common P2PE process is a POS terminal, which should implement a P2PE validation solution and have no access to unencrypted data.
Tokenization is a process where a service provider takes the cardholder data and completely replaces the PAN in an environment with a surrogate value called a “token.” Usually service providers collect the PAN at the transaction, so that way you never have access to this information. Then anytime you want to run another transaction with that customer, you send that token and the transaction details to a third party provider. They put it back into PAN and send it out for authorization.
If you properly implement tokenization so that PAN is not retrievable from any system component, you can store tokens in your database with no security consequences. Tokens are not considered PAN, so storing tokens would not be in scope.
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 tokens. Anytime PAN is negated on an environment, scope is reduced.
Tokenization is an easy way to reduce your scope, possibly even changing your SAQ type.
Tokenization might not be properly implemented for call centers that use integrated voice response (IVR) systems, which allow customers to put in their number over the phone. The system will often store PAN from the transaction unless you outsource the collection process.
Tokenization might not be properly implemented in ecommerce environments. If you manually enter customer cardholder data via a website, PAN might be stored in your browser memory (If your website is configured to cache webpages and the encrypted pages in your browser).
Network segmentation is a method of separating environment systems that store, process, or transmit cardholder data from those that don’t.
Merchants’ systems are often set up with big flat networks, where everything inside the network can connect to everything else. They may have one firewall at the edge of their network, but that’s it.
Flat networks make securing your card data extremely difficult because if an attacker gets inside of the network, they have access to everything. As a result, your entire network is in scope for PCI.
That’s why network segmentation is such a great method to reduce scope. You simply don’t allow systems with PAN or other sensitive information to connect with other parts of your network.
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, or transmit cardholder data. If that interface doesn’t allow any other traffic into our 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 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.
If you properly segment networks, you aren’t required to implement PCI requirements for out-of-scope networks. Although PCI isn’t required, applying the PCI standard is good security practices for your business.
Network segmentation is one of the best ways to reduce the number of systems that store, process, or transmit card data (in turn, reducing your scope).
To reduce your PCI scope, you need to know the flows of cardholder data in your unique environment. Until you understand your flows, it’s impossible to understand exactly what must be secured.
Because of all the recent changes and new requirements, now is an ideal time to rethink your data security and reduce your PCI compliance workload. Reducing scope will help you to save money and free your staff to focus on other work responsibilities, saving you both time and resources.
We help customers close security and compliance gaps to avoid data breaches. Our forensic, penetration testing, and audit teams identify best security practices and simplify compliance mandates (PCI DSS, HIPAA, HITRUST, GDPR). As an Approved Scanning Vendor, Qualified Security Assessor, Certified Forensic Investigator, we have tested over 1 million systems for security.
.svg)
