The Payment Card Industry (PCI) Data Security Standard requires that merchants and service providers who store, process or transmit credit and/or debit card data comply with a set of 12 requirements designed to safeguard this highly sensitive information. Most security professionals agree that these requirements -- often referred to colloquially as the "dirty dozen" -- represent current information security best practices, and offer...
a reasonable set of controls for dealing with extremely sensitive data.
While they may be appropriate for protecting credit card information, the PCI Data Security Standard requirements are probably too rigorous and costly to be applicable to the bulk of the data your enterprise handles on a daily basis. For example, consider the case of a large college or university network that grants broad public access to large portions of the network. In all likelihood, only a miniscule fraction of the thousands of systems on the network may be involved in card-processing activities, hence it would simply be impractical to implement all 12 PCI Data Security Standard requirements across the entire network.
"The cardholder data environment is that part of the network that possesses cardholder data or sensitive authentication data. Adequate network segmentation, which isolates systems that store, process, or transmit cardholder data from those that do not, may reduce the scope of the cardholder data environment."
These two sentences came as a great relief for organizations that handle payment card information as a small part of their business. At the same time, it raises more questions for those seeking to implement an isolation strategy. What constitutes "adequate network segmentation?"
A number of merchants are choosing to comply with the PCI Data Security Standard through a network isolation strategy. Their goal is to implement a completely isolated "network within a network" that houses all systems involved in payment card processing. The only connection to the enterprise network is on the outside interface of a firewall, as shown in the illustration above.
This link is as rigidly protected as one would protect the organization's connection to the Internet. Therefore, the card-processing network treats the rest of the enterprise network as nothing more than an ISP. Any transmission of cardholder data or administrative control that crosses the enterprise network must be encrypted, just as it would be across the Internet.
The challenge with a conservative approach such as this lies in providing routine services such as DNS/directory services, time synchronization, intrusion detection, backup and file integrity monitoring to systems within the cardholder data environment. The "ISP model" requires that dedicated systems provide these services to the environment, while still complying with the "one primary function per server" rule stated in section 2.2.1 of PCI DSS. These costs can mount quickly though, considering all of the ancillary services necessary to support a stand-alone network.
In addition to minimizing the scope of the systems in your cardholder data environment, the ISP model also may allow you to completely eliminate sections of the PCI Data Security Standard from your compliance program. For example, many organizations may have no need for wireless networking within the cardholder environment. If you simply don't connect your existing wireless network to the isolated card processing network, you may be able to avoid the burdens of PCI DSS sections 1.3.8, 2.1.1, 4.1.1, 9.1.3 and 10.5.4.
The decision whether to implement this approach depends upon your organizational risk tolerance. If you have a large network or other compliance challenges, the costs of implementing an isolated stand-alone network may pale in comparison to bringing your entire network into PCI Data Security Standard compliance. Yet it does provide the peace of mind inherent in knowing that payment card data is firmly isolated, minimizing the risk of seeing your organization's name in the news headlines as the next high-profile security breach.
About the author:
Mike Chapple, CISA, CISSP is an IT Security Professional with the University of Notre Dame. He previously served as an information security researcher with the National Security Agency and the U.S. Air Force. Mike is a frequent contributor to SearchSecurity, a technical editor for Information Security magazine and the author of several information security titles, including the CISSP Prep Guide and Information Security Illuminated.