Lightening the PCI Load: Solutions to Reduce PCI Scope

In today’s turbulent economic environment, every organization is doing its best to limit losses and manage costs. In a similar vein, when it comes to achieving and maintaining PCI compliance, one way to manage costs is to limit or reduce the scope of PCI requirements.

Doing so can help to significantly reduce the overall costs and resources required to successfully negotiate a compliant PCI audit. This article will help show how this can be done.

Getting it done

It happens to many businesses that process credit cards for payments. They get that dreaded, unanticipated letter—be it from their acquiring bank, card brand, other financial institution or payment processor—stating or even mandating that the business become compliant with the PCI Data Security Standard (DSS).

Suddenly, all of those years of ignoring information security quickly comes back to haunt them. For many of these businesses, 60 Minutes is not a news show; rather it’s the amount of time they dedicate to information security on a monthly basis.

After these organizations have been served proper notification and given an expected target date for PCI compliance, they hear that compliance clock ticking. (Editor’s note: See A Tale of Two PCI Audits.)Unfortunately, they soon realize that they do not have the in-house talent to properly identify and remediate their PCI compliance gaps. There also may be other planned and capitalized IT projects in the works that have stringent timeline requirements. How is it possible to add a major compliance remediation effort to an already filled IT plans and programs dance card?

If a business is processing credit card payments for goods or services, then PCI DSS becomes a mandatory industry requirement. In this instance management can do the right thing by rallying internal staff and pulling relevant management and technical personnel into a special project team to address these new requirements. The team concludes it would be best to hire a PCI Qualified Security Assessor (QSA) from an authorized firm to assess their business and IT environment.

Once the QSA (can be one or more assessors depending on the project scope) arrives on-site, they conduct interviews with key organizational personnel, conduct physical security inspections and personally review a representative sample of PCI system and network configurations. Following the on-site visit, the QSA will produce a report articulating the nature of the measured gaps with respect to the environment and all PCI requirements.

The team will then convene a post engagement meeting to review the results of the gap assessment. Generally this is done as a collective review, with concerns and anxieties shared by all the appropriate stake-holders. Often the client cannot believe there are so many PCI compliance issues to address. Every gap that is listed must be remediated in some fashion. All of those years of ignoring, or short-sheeting Information Security now becomes a major issue, along with the realization that this is going to be an expensive endeavor, likely impacting existing projects and putting a strain on existing staff.

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.

In some instances the network traffic generated by such malware infected systems can be so intensive as to effectively reduce or even completely consume all available network bandwidth. The net result can be the impaired performance of all production systems including those processing credit card payments. Having the appropriate anti-virus/malware protection implemented in both PCI and non-PCI environments protects both and offers measurably enhanced protection for CHI systems.

Consider another similar example with a Point of Sale (POS) system. A customer swipes their credit card through a card reader integrated within a POS system. The cardholder information is supposedly encrypted at the swipe via a PCI compliant encryption scheme, and the information is sent to the gateway for a payment processor and not decrypted until it reaches the processor network. The $64,000 question is this: is the POS system out-of-scope for PCI?

Many people, even including some POS vendors, would say “Of course not”. The truth is that they are absolutely in-scope for PCI, because it is processing cardholder data. It does matter that it is encrypted; however, the fact that the data is encrypted does not absolve the POS system from PCI compliance requirements. It is incumbent upon the merchant and especially any QSA reviewing such an implementation to validate that the data resulting from the card swipe is properly encrypted. They should ensure that there is no data leakage in the process.

If the POS system is Windows-based, then an appropriate anti-virus product should be installed as a part of the POS image. The POS image should also be appropriately updated with relevant operating system security patches in a timely fashion. If this is not possible (often due to POS resource consumption constraints) then some other malware vulnerability controls must be implemented.

The fact that anti-virus software is inadequate for POS implementations or other resource constrained systems is not a new problem. Two years ago, articles such as The decline of antivirus and the rise of Whitelisting started appearing. Some firms propose using application white-listing as a possible substitute for anti-virus/malware prevention and this solution has been given serious consideration by both QSAs and the PCI SSC (Security Standards Council).

Also, if the POS is IP-based and is networked, then it should also be scanned for possible vulnerabilities. Once again, in this instance the PCI scope has been reduced since the cardholder data is encrypted as a part of the card swipe process, however, the POS system is still very much in scope for PCI compliance requirements. Nonetheless, in such a scenario one cannot simply remove the POS device(s) from PCI scope consideration simply because the CHI is encrypted at the reader and the POS does not have the resources to support malware detection capabilities. The cumulative effect of requiring that all systems, personnel, and business processes become compliant with all relevant PCI requirements, namely regarding the storing and/or processing of cardholder data, is considered to be the scope’ of PCI compliance and validation.

Why is this important? What does this have to do with the overall costs and impacts of PCI compliance? Or even their potential impact to existing or future projects? Let’s take another look at what was written in the authors’ article, A Guide to Practical PCI Compliance.

“Some merchants have constructed their POS applications and associated infrastructure with an aggressive eye toward reducing costs at every turn. Often, this infrastructure has evolved and co-mingled with non-PCI systems that may have been designed with little or no thought given to protecting sensitive information. If there is little or no separation between the PCI and non-PCI systems then the DSS requirements will apply to all of the systems within this environment.”

Many clients are bewildered to find out that their payment-processing environment contains both PCI and non-PCI systems. What is worse is that often there are very few if any of the required security controls in place. What this means is that all of PCI DSS requirements and quite possibly all of the PCI Report on Compliance (RoC) audit criteria may apply to the entire network / IT environment? That means they would have to implement firewalls, IDS, authentication mechanisms, system hardening, logging, monitoring, auditing and alerting resources for total environment.

In truth, that would be a great thing. From a security perspective, what’s good for a PCI network is good for a non-PCI network. The previous scenario would mean that PCI would apply to everything in the environment. Also the lack of segregation between the two increases the potential time and cost of a PCI assessment.

The issue is that in an environment where there is inadequate separation and protections between PCI systems and non-PCI systems, the PCI requirements apply to all systems, personnel and processes in that environment. Addressing PCI requirements for all systems in an environment, even those that have nothing to do with PCI, would be extremely cost prohibitive and could bankrupt an organization. So what is the next step? How can this be properly remediated? Once again, from A Guide to Practical PCI Compliance:

“Reducing the scope of a PCI assessment is often advocated when the recommended changes to the environment have become cost prohibitive or will adversely impact the business or organizational mission. In such instances, it’s reasonable to consider moving the PCI systems into their own dedicated environment and limiting their interaction with non-PCI technology. This helps reduce the number of critical systems to be reshaped into compliance and will enhance security by placing them in a controlled and monitored environment.”

So it is technically feasible to consider re-architecting a given business, organizational structure, and IT environment to reduce the scope, impact, and overhead of PCI compliance requirements. Doing this does not conflict with the spirit and principles of the PCI DSS and in fact should be emphatically encouraged. Let’s now review this further.

In scope vs. Out of scope

So what does it mean to be in or out of scope with respect to PCI compliance? This concept is perhaps one of the most confusing in PCI to some and is even marginally understood by many others. It is often stated that simply not storing or processing cardholder data on a given system will render it out-of-scope for PCI compliance. The authors have heard this assertion time and time again, even from people who should know better.

Consider this question: if a system is involved in the processing and transmission of cardholder information, but simply stores the transaction information in RAM temporarily until the authorization process is completed, does this mean that the system is considered to be out-of scope for PCI? The answer is absolutely not.

The system should still have been constructed from a standardized, hardened build. It should still have anti-virus and malware protection implemented with logging if vulnerable to such, should have its user and group accounts managed properly, provide authentication with proper protections and mechanisms including robust passwords, log all administrative system access, and ensure that any cardholder information is purged from within log files, trace files, history files, application files, etc.

These are all requirements for systems processing cardholder information, regardless of whether or not it is storing cardholder information on a hard drive or temporarily within RAM. Not storing cardholder data on a hard drive reduces the overall scope for PCI compliance, but does not exempt systems from being compliant with other relevant PCI requirements. This may sound intuitively obvious to the reader, however, this particular misnomer surfaces often.

Principles of reducing scope

The quickest and easiest way companies can limit the scope of their PCI requirements is to segment their networks so that cardholder data and those systems that process it are isolated. Another method is to outsource cardholder data processing and storage as described within Gartner’s Limiting the Scope of Payment Card Industry Audits and Liability.

In general, some of the core principles of reducing the scope of PCI compliance are as follows:

• Outsourcing Data Storage—While it is great to do it yourself, companies should consider, where possible, the outsourcing of their PCI transaction processing to PCI-compliant service providers that can securely manage their payment processing and record keeping needs. Keep in mind that outsourcing payment processing and data storage does not absolve an entity from the responsibility to process payments on behalf of the business in a PCI compliant fashion. The merchant or business still owns and is responsible for meeting this requirement; irrespective of whether or not these processes are outsourced.
• Segmentation—Network segmentation is perhaps the best way to limit scope. The challenge with this approach is that until recently the PCI SSC has not provided a clear and concise definition of network segmentation. The PCI SSC has provided enhanced clarification in PCI Requirements and Security Assessment Procedures version 1.2, but ultimately defers to the QSA to render judgment on such distinctions. Different PCI QSA’s interpret this differently, adding to the challenge of PCI compliance. At a minimum, segregation should entail logical separation between networks via router and switch ACL’s, as well as involve the separation provided by a stateful firewall. The optimal solution is to provide physical separation between networks.
• Economies of scale—For many companies credit card payments are a small part of their overall operations. If they can minimize where card data is stored they can measurably decrease the risk of a breach. This in turn helps to reduce their PCI scope. Another example of this concept is to build all servers and other systems based upon hardened operating system images. This helps to reduce subtle variations across platforms and can enhance recovery times for systems that need to be re-configured. Doing so also reduces maintenance costs, potential system downtime and the overall complexities of managing a heterogeneous environment.
• Securing the isolation—Deep inspection firewalls, user access management and content monitoring and filtering should be deployed to isolate systems that store or process card data. We also recommend vulnerability scans and penetration tests after every significant change to the environment.

Gartner notes that brick-and-mortar merchants that outsource electronic data storage must still encrypt or otherwise protect data transmitted from POS terminals to outsourced service providers. This can be difficult to achieve with legacy and proprietary equipment. They also note that where possible, merchants should outsource electronic data storage to PCI-compliant service providers that manage payment processing and record keeping for them.

Another good example of reducing PCI scope is a retail business that has multiple locations containing numerous POS systems. At the end of the business day they send the aggregated results of all daily transactions (including credit cards) back to a corporate HQ server across dedicated private network connections. PCI DSS requires implementation of intrusion detection systems (IDS) and firewalls to protect cardholder data being stored, processed or transmitted.

While the business has deployed stateful firewalls at each retail location, it may be cost prohibitive for the business to deploy IDS at every location. An effective, optimized solution to help meet this requirement includes routing-VLAN configurations and controls that restrict access between the retail store PCI locations. In essence all data flows are restricted to originate from the retail locations directly back to the corporate PCI compliant data center environment.

Both firewall-based segmentation and IDS is then implemented at that single communication aggregation point into the corporate network infrastructure. In this scenario, PCI-based event logging requirements would still apply for all PCI systems at their corporate and retail locations; the costs of implementing the required Intrusion Detection capabilities, however, would be significantly less.

Conclusions

At its heart, PCI is Information Security 101. Within the framework of Information Security 101, the objective is to reduce the overall risk to business assets and to protect the privacy of employees and customers. This article attempted to provide some additional clarification surrounding this often very contentious topic.

Reducing the scope of an organization’s PCI environment, especially with the appropriate network segmentation, provides the necessary security controls and reduces the potential risk to critical business assets including cardholder information.

Most importantly and when possible, reducing the scope of the applicable PCI requirements also reduces potential resource enhancement implications and their associated expenses. This can be achieved all while preserving the overall security of critical business assets including cardholder information. ##

David Mundhenk, CISSP, PCI-DSS & PA-DSS QSA, QPASP (stratamund@sbcglobal.net) is a Security Consultant with a major professional services firm.