4 Tips for Defining PCI Scope for Your Environment
One of the biggest challenges for companies that must follow the PCI DSS standard is to properly map the PCI scope of systems and environments that should stick to the hundreds of controls required by the payment card industry.
In one of its introductory chapters, the PCI DSS standard details that:
at least annually and prior to the annual assessment, the assessed entity must confirm the accuracy of its PCI scope by identifying all cardholder data locations and flows, as well as identifying all systems connected to it or that could impact the Cardholder Data Environment (CDE– for example, authentication servers) to ensure that they are included in the PCI scope.
This quote already gives us a dimension of what will be part of the scope, but it is important to explore what it is and go into detail so that this mapping is correct and that there are no unpleasant surprises when your Qualified Security Assessor (QSA) is validating the scope in its annual evaluation.
Initially, it is worth emphasizing that PCI DSS states who should confirm the PCI scope accuracy is the assessed entity. So, it will be up to the QSA to validate that only the documentation of the scope is created and maintained by those who are evaluated.
Here are a few recommendations when carrying out the PCI assessment:
1. Thoroughly analyze all business processes that involve the storage, processing or transmission of card data and systems involved.
This first step is the most important because it will help you understand the full flow of cardholder data and will impact the next steps. The company must thoroughly analyze and document all the paths traveled by the card data, including automated and manual processes, which can be identified through three questions:
- Where does the card data come in?
- Where is it transmitted?
- Where is it stored?
Responses should generate a type of documentation, which can be represented through a flow of card data, which in turn is one of the requirements of PCI DSS (1.1.3).
Do not forget that card data can also be present in physical media, whether in capture, through manual registration processes or the like, or in storage, by tape backup processes or internal movement of physical media such as HDDs and external devices of storage.
2. Create a list of all assets that store, process, or transmit card data.
The second step is to comply with PCI requirement 2.4, which requires the maintenance of a list of all the assets that are part of its scope. The list of assets that store, process or transmit card data will kick-start the fulfillment of this requirement. However, other assets should be documented in this control, which will be detailed below.
3. Understand segmentation controls, if any, and include all assets in the scope when there is no segmentation.
Segmentation is often a feature applied by many companies to narrow the scope of PCI controls. Segmentation, physical or logical, isolates all assets that store, process or transmit card data from those who do not have any need to deal with this data. However, it is important to note that within this segment all the assets contained in it will be part of the scope. In this way, if there is a database in the same network segment containing card data, and another one that does not have it and there is no control to segment them, everything will become a scope.
All these segments where the card data passes will be called Cardholder Data Environment (English Cardholder Data Environment – CDE), and all assets contained in it should include inventory created in the previous item.
4. Map all extended scope assets.
The extended scope refers to any asset that has some type of trust relationship with CDE assets but is not in the same segment. Although this is not an official term described in the PCI standard, the extended scope is widely used in the market for understanding the assets that, by having some kind of connectivity to the card data environment, end up becoming the scope of the evaluations. The extended-scoped asset mapping step should be quite thorough, since it will identify several services that the company uses to manage its CDE assets – access management, log synchronization, malware protection, and so on. These can be used as gateways to CDE because of their trust.
It is important to note that these systems must be segmented from the CDE. Otherwise, they will make all other systems connected to it also become scoped. An example is the Domain Controller which, if it is within the CDE will make all the users that connect to it become scoped. On the contrary, if you are outside the CDE, it will not affect the other assets. This is a widely used concept, known as scoping contamination.
Finally, the extended scope will encompass all assets used to segment environments such as firewalls and switches, as well as systems that are responsible for providing security to environments such as antivirus, IDS / IPS, FIM, SIEM, etc.
An additional point that should not be overlooked is the use of third party services. Note that mapping these assets following the steps outlined above will help you to fully understand their scope, but it is important that this exercise be performed also in your service provider’s environment if they are not PCI DSS certified companies.
Correct mapping of your environment and centralized PCI scope documentation will help you maintain effective control over maintaining compliance with all applicable requirements for your environment. So, it’s worth the investment in its creation and annual review that, in addition to being mandatory, will bring many benefits to your company.
Eduardo Justo de Oliveira is PCI-QSA of CIPHER’s GRC team.