PCI Compliance & Network Segmentation | Reciprocity

Written by
PCI Compliance & Network Segmentation

Network segmentation acts as the starting point for determining the scope of your Payment Card Industry Data Security Standard (PCI DSS) compliance journey. Segmentation means creating controls focused on the data’s security needs. To appropriately meet the PCI network segmentation requirements, you need to understand the standard’s purpose and objectives.

PCI DSS Network Segmentation

What is the cardholder data environment (CDE)?

PCI DSS defines cardholder data (CHD) as personally identifiable data associated with someone’s credit or debit card. This definition includes the primary account number (PAN) in conjunction with either cardholder name, expiration date, service code, or sensitive authentication card data.

In short, CDH constitutes any information that could be used to steal an identity or make fraudulent charges to someone’s card.

The cardholder data environment constitutes any computer or networked system that processes, stores, or transmits this information. The CDH includes system components such as network devices, servers, computing devices, and applications. These can be security services, virtual components, network components, server types, applications, or anything connected to CDE.

If employees or systems can access CHD on something, then that needs to be set off separately from all other areas of your company.

What does PCI DSS mean by network segmentation?

Network segmentation requires looking at the way information travels on your systems. Think of your CDE as a river and the CHD as a kayak navigating the rapids. Just like rivers have multiple access points for boats, networks have various data access points. Networks act like rivers with tributaries that are connected to them. If your CHD can float down a path on your network, you need to either protect that tributary or build a dam.

For example, PCI DSS defines connectivity as physical, wireless, and virtualized. At any point on that river, CHD can enter. Physical connectivity may be a USB drive. Wireless connectivity includes Wireless LANs and Bluetooth connections. Virtualized connectivity incorporates shred resources such as virtual firewalls or virtual machines. Each of these data access points needs to be secured.

How do companies scope systems?

PCI DSS scoping requires critically evaluating all the different data access points and tributaries on your CDE river.

A PCI DSS assessment starts with cataloging how and where you receive CHD. Walking up and down the banks of your CDE, you need to find all payment channels and methods for accepting CHD and then follow the information’s journey from collected through destruction, disposal, or transfer.

Next, locate and document the places throughout your CDE where you store, process, or transmit data. This identification means understanding how not only who handles data, the processes and technologies that touch the data as it flows through your networks.

After you’ve tracked the information’s flow through your organization’s networks, you want to make sure that you’ve incorporated all processes, system components, and people who influence the CDE. This step differs from the last because it requires you to look outside of those that interact with the information and focus on those who drive the environment.

Once you’ve reviewed your data river, you need to create controls to protect the information. In the same way that some rivers have landings to help protect boaters accessing certain points, you need to have controls. You also need to determine how to limit where the information can go and who can access it. To do this, you want to put up the data security version of dams, including firewalls and encryption methods.

After you’ve established control, you need to make sure that you apply them to all in-scope system components, processes, and personnel.

Finally, and most importantly, you need to monitor controls and make sure to make changes as your CDE evolves.

Are there any out-of-scope systems?

The Payment Card Industry Security Standard Council (PCI SSC) defines out of scope systems as those with no access to any CDE system. Increasingly, finding out-of-scope systems is difficult.

The PCI SSC requires that the system component must not store, process, or transmit CHD AND must not be connected to any network segment that touches CHD AND must not connect to any system in the CDE AND cannot gain access to or impact a security control of the CDE AND doesn’t meet any previously discussed criteria.

Going back to the river analogy, even the trees in the neighboring forest might be in scope if they can access the same water table as your river. Therefore, before declaring a system out-of-scope, you need to think very carefully about it.

Can organizations transfer their risk using third party service providers?

Third parties and service providers also fall within the scope of your PCI security standards compliance.

Third parties and service providers are the forest rangers for your river. These business partners, entities providing remote support services, or other service providers may engage with your environment and therefore can place it at risk. Just as a forest ranger may move a branch that topples a kayak, so your third parties can impact your PCI DSS compliance. Therefore, you need to engage in third-party monitoring and manage your vendor ecosystem.

If you use a third-party service provider, you need to assess their services carefully. The contract should delineate the parts of the PCI-DSS requirements covered by you and the services provider.

The service provider needs to prove its compliance.
Vendors can either provide an annual assessment done by a qualified security assessor (QSA) or allow clients to request on-demand assessments. If the service provider chooses to provide a QSA assessment, you need to make sure that it covers your compliance needs and is part of the contract.

How ZenGRC can ease the burden of PCI DSS compliance

With ZenGRC, organizations can rapidly deploy a governance system that provides easy-to-read insights. For example, our PCI DSS compliance dashboard allows organizations to review control health at a glance while also listing critical issues facing the organization.

ZenGRC’s ongoing monitoring abilities provide updated, in-the-moment insights enabling organizations to continually respond to changing threats and vulnerabilities in a continuously evolving threat environment. Moreover, organizations can store their penetration test and audit findings on the ZenGRC platform to help enable better cross-enterprise outcomes.

To read about how scoping your PCI DSS compliance can help you better manage your compliance needs, download our ebook, PCI-DSS: Steps to Successful Scoping.