In Depth

Lightening the PCI Load: Solutions to Reduce PCI Scope

Expert guidance on saving time and money by carefully scoping PCI validation efforts

By David Mundhenk and Ben Rothke

The question is: now what? In a previous article (on CSOonline sister site CIO.com) Guide To Practical PCI Compliance, we made several recommendations on what an organization can do, given the aforementioned scenario. Some of them were:

1. Turn to vendors who offer PCI compliant technology solutions
2. Appoint an internal PCI compliance Project Manager
3. Create a remediation Project Plan
4. Out-source some remediation tasks
5. Reduce PCI scope

Of all these recommendations, the one that could have the greatest impact on budgets, plans and programs both positively or negatively is reducing the scope or footprint of the PCI compliance validation requirements.

It is important to note the difference between compliance and validation. All entities that process credit card transactions must be compliant with the PCI DSS (currently in version 1.2). How that compliance is measured is called validation.

Validation requirements vary depending upon the number of transactions being processed, whether or not a business owner electronically stores credit card information on their premises and other factors. These factors determine whether the proper validation required is to fully complete a Report on Compliance (RoC) Audit Criteria document, or whether one can simply fill out the Self Assessment Questionnaire (SAQ).

Even though every aspect of PCI is Information Security 101, PCI DSS is only required for those environments that store, process, and/or transmit cardholder data. How then can PCI apply to IT systems and personnel that may have little or no interaction with cardholder information (CHI)? A good example of this is a retail location that has both PCI and non-PCI IT systems deployed across a flat network with no logical separation or security controls. In this instance PCI requirements apply to all systems and personnel interacting within this retail environment.

A real-world example is the PCI requirement for malware detection/prevention software. In a hybrid environment containing both PCI and non-PCI systems, antivirus-malware detection should be installed on all systems vulnerable to such, not just those that processes cardholder information. This is needed as the lack of anti-virus/malware detection on all vulnerable systems can put cardholder information at serious risk.

Many malware programs have been created solely for the purpose of finding and stealing sensitive, commerce related information including CHI. Such targeted malware infestations present a direct and fairly obvious risk to systems within a PCI environment that contain cardholder information. There is also an indirect, but measurable risk to be considered when PCI systems are inter-networked within the same environment as non-PCI systems.

Such malware is often specially crafted to try various means of propagation and communications to bypass traditional network segmentation techniques. Some even utilize standard network services not specifically protected by firewalls or IDS/IPS, such as HTTP (port 80), ssh (port 22) or SSL (port 443). These authorized network services can also be used for malware based reconnaissance in an attempt to locate and infect vulnerable systems and shared resources.

• Email
• Print
• Comments
• Digg This
• SlashDot

• PCI Application Security: Who's Guarding the Data Bank?
• A Tale of Two PCI Security Audits
• PCI's Post-Audit Pain Points
• Security at the Point of Sale
• All About the PCI Data Security Standard