If you are struggling with understanding the “Scope” of your cardholder data environment (CDE), refer to the PCI SSC scoping guidance document (https://www.pcisecuritystandards.org/documents/Guidance-PCI-DSS-Scoping-and-Segmentation_v1.pdf). This is to help entities appropriately scope their cardholder data environment for PCI DSS.
Why publish?
Many entities still struggle with determining the scope for various factors, which may include:
- Many interpretations of adequate segmentation.
- Motivations for reducing scope.
Why scope is important?
Scoping is still a hot topic. Improper scoping may result in not identifying cardholder data (CHD) or intended/accidental cardholder data leakage. An unidentified cardholder data area is a desirable area for hackers and may lead to a breach.
The scope for PCI DSS includes systems within the cardholder data environment (CDE) that process, store or transmit CHD, connect to the CDE, or impact the security of the CDE.
Conversely, bad interpretations can lead to over scoping which is unnecessary and results in ineffective use of resources.
The first stage is to identify the critical people, processes and technology in-scope. Only then can you apply the relevant PCI DSS requirements. Believe me, this is never ever a trivial exercise and again we emphasise the need for good interpretation.
What is in-scope for PCI DSS?
We can be here for a long time, so I’m just going to summarise the document:
- CDE system: The system processes, stores or transmits cardholder data (CHD); OR a system is in the same network (e.g. VLAN) as systems that store, process or transmit CHD.
- Connected-System OR a security-impacting system: Something that connects inside to the CDE, or could impact the security of the CDE.
Sometimes the above may be too generic to apply security controls. Here is a possible category method of what in-scope for your PCI DSS assessment by categorising them:
- Type 1a (Systems that process, store or transmit CHD): This should be self-explanatory. These are systems whereby cardholder data is present and could be stolen.
- Type 1b (Systems inside the CDE): These systems are in the same network segments as Type 1 systems and can be used as an attack vector to steal cardholder data.
- Type 2a (Connected To): Systems directly accesses the CDE via controlled access boundary systems (e.g. firewalls, routers etc.). These systems establish a connection into the CDE or receive communication from the CDE.
- Type 2b (Connected To): Systems that indirectly accesses the CDE via controlled access boundary systems (e.g. an administrator workstation that indirectly uses a jump server).
- Type 2c (Impacts Security of CDE): Any system that could impact the CDE, such as systems that control access, segmentation, patch distribution, logging and monitoring tools.
Controlled access
Controlled access from say “zone A” into the CDE does not mean the network is fully segmented. However, this also does not mean every single system component in zone A is in scope! It means that these communications are more secure than uncontrolled systems. These restricted communications should be considered in-scope.
Any segmentation controls to fully restrict access must be penetration tested at least annually as per PCI DSS requirement 11.3.4 to ensure segmentation is still effective.
The following statement is interesting:
“It is important to understand the risks and impacts if connected-to system components are excluded or overlooked from PCI DSS scope.”
The way I read this is if a connected-to system is excluded from PCI DSS scope, the risk and impact should be determined first. Let’s consider this scenario:
- A large bank whereby there are 15,000+ user workstations all connecting into a virtualised environment.
- The virtualised environment supports the core banking system (that may process CHD) and non-CHD processing systems.
- A smaller proportion of 2,000 only access the core banking system via secured applications or secured browser (HTTPS), presented on their desktop via role-based access virtualised system.
The virtualised environment is in-scope as it supports the core banking system and card-processing applications. Does the 15,000+ workstations connecting into the virtualised environment mean all 15,000+ workstations are in scope? Maybe “yes” as each workstation is accessing the virtualised environment hosting the CDE, but maybe “no” as controls may be in place to restrict the presentation of access and applications on the desktop where the user role requires it.
Shared services
There are some systems components that may provide a service to the corporate network and CDE. I consider these “management systems”, which provide management or security functions such as:
- Directory and authentication (Active Directory, LDAP, AAA etc.)
- SMTP
- Anti-virus
- Logging and monitoring
- Bastion Host/Jumpbox
For this reason, you do not want the full corporate network being able to communicate with these management systems – these management systems / shared services should be in their own management zone:
- Only those components within the management zone can then connect into the CDE.
- Corporate LAN can connect to the management zone / shared services.
Administrator workstations are categorised as a “Connected To” device, perhaps see Type 2b above and are in-scope for PCI DSS review.
Who is responsible for determining scope?
We must reminds ourselves that the assessor is independent. The responsibility for determining the scope is the entity being assessed. The entity should confirm the people, process and technology in scope and retain documentation how this was determined. The assessed entity is responsible for annually determining the scope.
The assessor trusts, but verifies this to confirm the scope is defined and documented properly. However, should the scope not be correct, the assessor must work with the entity to determine the correct scope prior to the assessment to determine boundaries and applicable requirements.
Conclusions
Scoping will always be down to interpretation and the scoping guidelines published from the PCI SSC will help. Therefore, the opinions in this document are mine alone. You need to work with your assessor to determine their interpretation of the standard and scoping. Please see key findings below:
- Connected-to systems has more clarity of what is in-scope. Any systems to be excluded for scope and must be evaluated and risk assessed.
- Administrator workstations connecting directly or indirectly to the CDE are always in-scope.
- Important to note no solution eliminates all PCI DSS requirements. The applicability of requirements depends on the system function.
- Review the types/categories of systems in scope and review third party access against this.
- All segmentation controls must be penetration tested at least annually.
Finally, even if your environment may in principle seem a typical environment, your scope is likely to be different because of different people, processes and technology. What is your scope? I will put on my QSA hat on and say “It depends”!
Did you find this post useful? Feel free to share and link to this article.