Back
Take the Pain Out of PCI – How to Define and Manage PCI Scope
Defining and managing PCI scope is arguably the most critical part of any PCI compliance program. An overly narrow scope can jeopardize cardholder data, and an overly broad scope can add unnecessary cost and time to any PCI program.
PCI compliance is an ongoing process and requires an annual assessment that can add up to a lot of time and expense each year. Minimizing both the size and complexity of the systems in PCI scope is key to PCI compliance and efficiency. Start managing PCI scope with these steps to accurately define and reduce the scope, and build a strong case to support your conclusions.
The Importance of Defining PCI Scope
The “PCI SSDC Quick Reference Guide” states, “The first step of a PCI DSS compliance effort is to determine the scope of the environment accurately. The scoping process includes identifying all system components that are located within or connected to the cardholder data environment.”
PCI scope is everything that could help a thief steal cardholder data and is the responsibility of the entity in question. An accurately-defined scope allows an organization to focus PCI controls on the required areas, and reduces the risk of scope redefinitions during assessments that can significantly delay compliance efforts.
Defining PCI Scope in Three Steps
Step 1: Define all hardware and software systems, processes, procedures, and networks that process, transmit or store cardholder data. These systems and those on the same network or in the same physical area are called the Cardholder Data Environment, or CDE. The CDE is network or area where PAN, PIN or CVV is located and PCI scope is everything that can affect the security of the CDE.
Step 2: Define all hardware and software systems, processes, procedures, and networks that “connect” to the CDE.
The term “connect” means that the system makes a network connection and that the system can be generally interpreted and can ‘affect’ the CDE. For example:
• An anti-virus update server that updates CDE hosts from outside the CDE.
• A PC that can view some software, even if unrelated to payments and transactions, but connects to software in the CDE.
• A processor or third-party processor that takes cardholder data from the entity in question.
• A host that connects to a jump-box that then connects to the CDE.
• NTP or DNS servers connected via TCP/IP
Step 3: Add steps one and two together to derive your total PCI scope.
Two Ways to Reduce PCI Scope
Even the best organizations struggle with compliance if their scope is too large. To reduce scope, determine what processes can be eliminated and how segmentation can help.
Process Reduction. Determine what processes are required. If a process brings many systems into scope, it is even more important to review. Ask, “Do we need to be doing this? Can we do this another way?”
Segmentation. After reducing all possible processes, and reducing the CDE down to the bare minimum, try to reduce the “connections” into the CDE.
The PCI SSC states, “When properly implemented, a segmented (out-of-scope) system component could not impact the security of the CDE, even if an attacker obtained administrative access on that out-of-scope system.”
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. In summary, think about protocol filtering, ACLs, monitoring software and physical access limitations to implement segmentation.
Generally, this is done with network and system segmentation. Segmentation can also be physical but generally focuses on network firewalls, routers, switches, with tight access control lists and system access control lists and other technology such as special host based software, or other protocol analysis-based filters that can stop unneeded systems from “connecting” into the CDE.
Some technologies that can be used to reduce scope with segmentation are:
1. Firewall, routers, switches, and any protocol filtering
2. Host HIDs and HIPs (intrusion detection and prevention)
3. Network IPS/IDS
4. Extra authentication layers
5. Physical isolation
6. Anomaly detection with disconnect capabilities
Support Scope
It is important for organizations to view their PCI compliance program from two viewpoints: inside and outside the company. You must step back and ask yourself if 90 percent of the PCI technical world would accept your reasoning; otherwise, you are open to many issues, from delays, to sudden scope changes, to liability.
After an initial scoping check, you must reconsider the “corner cases.” Those are the cases that make sense to you, but not to all QSAs or the PCI Council. You must consider all viewpoints and try to cover those as well. Perform a final “sanity check” of your assumptions before proceeding.
When in doubt, think twice. If you must implement a PCI scoping definition that is open to controversy, obtain written acceptance of this from your QSA. However, even if your QSA agrees, realize that someday you may change QSAs, so even a written acceptance does not guarantee long-term success for PCI DSS.
Always try to create the strongest case for your segmentation. Then document your scoping decisions. Record meeting notes, and write a simple scoping document. Above all, diagram your card data flows and PCI scope. If you do this, you can ensure that you and your QSA assessor agree. Additionally, if there ever is an issue, such as a breach, you will be in a much stronger legal position than if all you have to reference is what you thought was correct at some time in the past. Documenting your case is the final step to strongly supporting your scoping decisions.
At DirectDefense, we pride ourselves in providing practical and realistic security and compliance solutions that assist our clients in meeting their goals. If you’d like to hear more about how we can assist you, please contact sales@directdefense.com.
02.13.17