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 securityinspections 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.