Read to learn about the basics of the scoping supplement and how to properly scope your own environment.
This post contains the text from the White Paper: PCI DSS Scoping Updates.
In December 2016, the PCI Security Standards Council (SCC) 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 in-scope systems.
The PCI SSC also hopes this supplement can help organizations protect their data from indirect threats, such as pivot attacks, in which an attacker targets a system with fewer security controls in place and then uses that access to breach higher security systems.
In this white paper, you will learn about the basics of the scoping supplement, how to properly scope your own environment, and segmentation principles.
The supplement’s recommendations can be used by both large and small entities to evaluate which system components are covered by PCI DSS requirements. The following groups will find this guide particularly useful:
The PCI Council’s release of the Information Supplement on scoping and network segmentation did not change existing PCI DSS requirements, but it has provided clarification on what systems these requirements must be applied to. For example, here are a few things the supplement discusses:
Basically, the supplement stresses that organizations need to understand and document their environment, especially what systems are included and how those systems interact with sensitive data. Understanding your environment is important because you are required to apply PCI DSS security requirements to all system components included in or connected to the CDE, which is “comprised of people, processes, and technologies that store, process, or transmit cardholder data (CHD) or sensitive authentication data.”
Within this supplement, the different categories of scoping are defined and clarified as such:
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:
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.
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, a system component cannot have access to any system in the CDE.
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:
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.
Now that you understand scoping terminology, you need to determine your own scope. The first step to accurately scope your environment is to understand where card data comes into, what happens to card data while it’s there, and where it is sent.
You should also determine what connectivity the device has to any connected-to system and if the device could use a connected-to system to gain access to the CDE. If a system has no better attack vector to the CDE than a system on the public access Internet, it can safely be determined as out of scope.
Remember, you need to confirm the accuracy of your PCI DSS scope at least annually and prior to the annual assessment, making sure to “identify all locations and flows of CHD, and identify all systems that are connected to or, if compromised, could impact the CDE to ensure they are included in PCI DSS scope.”
With any updates and clarification to PCI DSS requirements, you should always consult with a security professional, such as PCI DSS Qualified Security Assessors (QSAs). They should be able to help you accurately scope your environment and let you know if and how certain requirements apply to your evolving environment and business.
When scoping your environment, start with the assumption that everything is in scope until you verify that proper segmentation and all necessary controls are in place and provide effective segmentation.
Start by creating and documenting a current card data flow diagram for all card data flows in your organization. A card data flow diagram is a graphical representation of how card data moves through an organization. As you define your environment, it’s important to ask all organizations and departments if they receive cardholder information, and then define how their answers may change card data flows.
Knowing where cardholder data is stored helps you to confirm whether or not your CDE is what you think it is.
To accurately craft your card data flow diagram, ask yourself:
You need to know where primary account number (PAN) data is stored because it helps you identify which processes or flows might need to be fixed.
Instead of manually spending time in search of payment card data on computer systems, regularly run a cardholder data discovery tool (such as PANscan®). These tools help identify the location of unencrypted PAN data.
For example, in 2018, SecurityMetrics sampled PANscan results from scans conducted on more than 3,600 computers and 7,011,170GBs, finding over 88 million unencrypted payment cards. In this study, 85% of PANscan users stored unencrypted PANs and 5% stored track data (i.e., data inside magnetic stripe) on their network.
Once you identify new processes, you can begin to determine how to either fix the process or add it into your normal environment flow. For instance, it allows you to securely delete or encrypt the located unencrypted data.
In the latest study by SecurityMetrics, 85% of PANscan users found unencrypted PANs on their network.
Network segmentation is a method of separating networks, especially separating environment systems that store, process, or transmit cardholder data from those that don’t. Without adequate network segmentation, your entire network would be in scope for PCI DSS requirements.
For example, merchants often set up large, flat networks (i.e., the entire network is protected only by a perimeter firewall, with no internal segmentation). Organizations 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, this entire network would be in scope for PCI.
Initial intrusion in many of recent investigated data breaches began in areas of the merchant’s network that shouldn’t have given the attacker access to the CDE. For example, since the merchant’s network was configured as a flat network, it was not difficult for the attacker to migrate from the point of entry (e.g., employee laptop or work station) to the card data or other sensitive systems.
Segmentation prevents out-of-scope systems from communicating with systems in the CDE or impact the security of the CDE. Although network segmentation of the CDE from the remainder of your network is not required, segmentation may reduce:
PCI DSS segmentation is not automatically created by the existence of separate network segments; make sure to “include purpose-built controls that specifically create and enforce separation and prevent compromises originating from the out-of-scope network(s) from reaching sensitive data.”
For example, firewalls can be used to implement segmentation within an organization’s network. When merchants create a secure payment zone firewalled off from the rest of the day-to-day business traffic, they can better ensure their CDE only communicates with known and trusted sources. This limits the size of the CDE and potentially reduces PCI scope.
For example, 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/transmit cardholder data. If that interface doesn’t allow any other traffic in or out of any other zones, this is proper network segmentation.
For further network scoping and segmentation clarification, check out our webinar
Understanding the New PCI DSS Scoping Supplement.
Since February 1, 2018, service providers who use segmentation are required to perform penetration testing on segmentation controls (e.g., segmentation check) at least every six months and after any changes to segmentation controls/methods.
The objective of a segmentation check is to identify whether there is access into a secure network because of a misconfigured firewall. Basically, segmentation checks confirm if segmentation was set up properly and doesn’t have any security holes. Commonly-identified security issues include:
The remediation of commonly-identified security issues is the same:
This segmentation check should be performed by a qualified internal resource or third party and, if applicable, the tester should have organizational independence (though they aren’t required to be a QSA or ASV).
To discover your own PCI scope and what must be included for your PCI compliance, you need to identify anything that processes, stores, or transmits cardholder data, and evaluate what people and systems are communicating with your systems.
In my experience performing PCI audits, entities often overlook the same types of systems when doing their own PCI scoping. For instance, call centers usually pay little attention to QA systems, which often store cardholder data in the form of call recordings. Those systems are in scope for all PCI requirements!
Some simple questions can help you begin the scoping process. For example, ask yourself:
There are always processes you might not know about. For example, if you’re a retail store that swipes cards, do you ever take card numbers over the phone or receive emails with card information? Are any paper orders received? Organizations often have finance, treasury, or risk groups that have post-transaction processes involving cardholder data. It is important to include these processes when determining scope.
Don’t forget power outage procedures in which card data is manually taken down. For example, in most call centers, agents aren’t trained that card data should never be written. When the application they use for recording cardholder data freezes, they tend to resort to typing or writing it down in a temporary location and retrieving it later for entry. These temporary locations are rarely considered in an organization’s PCI compliance efforts, but can lead to increased risk and need to be included in PCI scope.
Often, paper trails of hand-written information or photocopied payment card data can sometimes fill multiple rooms. Even if card data is 10 years old, it is still in PCI scope.
If you access a web page for data entry, there’s a decent chance card data can be found in temporary browser cache files. In addition, it’s the website developer’s responsibility to make sure websites don’t generate cookies or temporary log files with sensitive data. However, you don’t always have full control of your website, which is why it’s important to evaluate all systems for cardholder data, even where you don’t expect it to reside.
You might think your databases are set up to encrypt all cardholder data. However, servers you consider out of scope will often hold temporary files, log files, or back-ups with unencrypted data. System administrator folders on file servers are also common culprits, as they often back up failing servers in a rush to prevent data loss without considering the PCI implications.
Don’t panic if you do find data where it doesn’t belong. Usually organizations can find ways to fix their process and delete this data rather than add servers to their scope. A simplified way to find unencrypted card data is by running a card discovery tool such as SecurityMetrics PANscan®.
For organizations with web portals, if someone mistypes card data into an address or phone number field, it is still considered in PCI scope. Organizations need to have methods to detect these mistakes and prevent or delete them. Some use a data loss prevention (DLP) solution to help them with this process.
The next step in determining your PCI scope is to find everything that can communicate with the devices you have identified. This is often the hardest part about scoping because you may not understand what can communicate to your systems. Ask yourself:
If you have a server that handles cardholder data, you must always consider what else talks to that server. Do you have a database server in some other zone you consider out of scope, but is reaching that web server to pull reports and save data? Anything that can initiate a connection to an in-scope server that handles cardholder data will be in scope for compliance. Furthermore, if your system in the CDE initiates a communication out to a server in another zone, that server will also be in your PCI scope. There are very few exceptions to this.
-TREVOR HANSEN
QSA | CISSP | CISA | CDCDP
The PCI Security Standards Council’s guidance on scoping and network segmentation clarifies how merchants and service providers can improve network security.
Specifically, you need to regularly and properly scope your environment. Start by assuming that everything in your network is in scope and needs to follow the PCI DSS.
You’ll then need to know the flows of cardholder data in your network, verifying your CDE. Then you can determine whether system components are out of scope or not. You can do this by making sure that controls are in place that provide assurance that out-of-scope systems cannot have access to or be used to compromise in-scope system components. While not required, the best practice is to implement PCI DSS controls for all out-of-scope systems/networks.
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)
