Preface. Author s Biography

(1)

(2)

© 2010 – ProPay Inc. All rights reserved. Reproduction, adaptation, or translation of this document 2 without ProPay, Inc.’s prior written permission is prohibited, except as allowed under copyright laws.

Preface

Whitepapers are often written from the third-person perspective. This projects objectivity and neutrality into the topic. The topic of this particular paper however, is so hotly debated that I felt it appropriate to deviate from the normal format and write from the first person perspective. I feel that the first person perspective will allow me to explain the concepts more clearly and provide more relevant examples for the readers.

Before going too far into the content I feel it is important to establish my credibility on this subject. For this reason, I am going to describe my background first. If, after reading my biography, you are still not convinced of my expertise then you have not wasted time reading the rest of the document.

Author’s Biography

My name is Chris Mark and I am ProPay’s Executive Vice President; Data Security & Compliance. I am a Payment Card Industry Data Security Standard (PCI DSS) expert. In 2001 I became involved with the PCI DSS’ predecessor when I worked with Visa USA on the original development of the Cardholder Information Security Program (CISP) and the development of the PCI DSS’s predecessor, the CISP requirements. I conducted one of the first (if not the first) CISP assessments before there were such things as Qualified Data Security Professionals (QSA predecessor) and QSAs. I founded one of the industry’s first Qualified Security Assessment (QSA) firms and conducted over 100 onsite PCI DSS assessments for merchants, service providers, and banks. After my company was acquired I then took employment at MasterCard Worldwide. At MasterCard I served as a member of their Site Data Protection (SDP) team and was one of the founding members of the Payment Card Industry Security Standards Council (PCI SSC) where I was MasterCard’s representative on the Technical Working Group.

The TWG published the first PCI DSS standard in 2006. After departing MasterCard, I was contracted by Visa to conduct PCI DSS related training for their merchants, banks, and service providers. My company, The Aegenis Group, was selected as the sole worldwide trainer for Qualified Security Assessors (QSA).

From 2007 – 2009 I trained over 10,000 people on PCI DSS related topics and trained over 1,500 QSAs in numerous countries including Thailand, Japan, Australia, Argentina, and the UK. Finally, my company developed the industry’s first and only payment card security certification programs the CPISM and CPISA and I have certified over 500 people on the topic of payment card security.

(4)

I am a frequent industry speaker and have presented at numerous events including the Electronic Transaction Association (ETA) annual convention (5 times), NACSTech, ACI Customer Event, PCIPortal South Africa, Utah Technology Counsel, Akamai’s Customer Security Event, CSI Executive Meeting, and have published scores of articles on payment card security and risk.

Executive Summary

For many companies required to comply with the PCI DSS, the mere mention of the standard brings groans of frustration and angst. Companies are frustrated, angry, and (insert your own emotion here) at the idea of having to comply with the standard. These feelings are often exacerbated by well meaning, although occasionally misguided individuals within the industry that espouse incorrect or irrelevant information as being accurate and truthful. The end result is a confusing, misguided approach to PCI DSS compliance. When pursuing the PCI DSS, there are a few steps one can take to make the process easier. Understanding the component parts of the PCI DSS, the differences between compliance and validation, and the applicability of the Standard can make the process much easier to understand.

Finally, applying these ideas to understand what this paper calls the “Compliance Spectrum” will help companies move through PCI DSS much more efficiently and cost effectively. More importantly it will enable organizations to make educated, informed decisions regarding the outsourcing of their payment card acceptance and processing.

The Payment Card Industry Data Security Standard

The Payment Card Industry Data Security Standard (PCI DSS) was developed originally as Visa’s Cardholder Information Security Program (CISP) in 2001 and later adopted by all of the major card brands in 2006 as an international standard. The PCI DSS consists of 12 high-level requirements and approximately 220 sub-requirements. The stated objective of the PCI DSS is to “...encourage and enhance cardholder data security...” It is not, nor was it ever intended to provide, an absolute statement on security. As stated on page 2 of the Preface section of PCI DSS v1.2.1:

“The Payment Card Industry (PCI) Data Security Standard (DSS) was developed to encourage and enhance cardholder data security and facilitate the broad adoption of consistent data security measures globally.”¹

1 PCI DSS; https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml

(5)

Applicability of the PCI DSS

The PCI DSS applies to any organization that stores, transmits or processes Cardholder Data. Version 1.2.1 of the standard further clarified the statement to state specifically:

“PCI DSS requirements are applicable if a Primary Account Number (PAN) is stored, processed, or transmitted. If a PAN is not stored, processed, or transmitted, PCI DSS requirements do not apply.”

As can be seen from the language in the PCI DSS, the determining factor as to whether or not the requirements apply is whether Primary Account Numbers (PANs) are stored, transmitted or processed.

It is unfortunate that this very apparent statement has been overlooked by a number of vendors and QSAs. Recently, I was listening to a webinar published by a major industry organization and a QSA stated something to the effect of: “Just because you don’t have any data does not mean you don’t have to comply with the PCI DSS.” As a former QSA, QSA trainer, and one of the original authors of the PCI DSS, I can state definitively that this statement is misleading at best, and incorrect at worst.

Notice that the PCI DSS talks about the applicability of the requirements and not the applicability of the program. Any organization that possesses a merchant ID is defined as a merchant by the card brand regulations known as Operating Regulations. Any and all merchants must comply with all card brand operating regulations. One of the OpRegs states that: “…all members (banks) must comply and ensure their merchants comply with the PCI DSS.” This operating regulation states that merchants must comply with the program. Whether or not the requirements apply is dictated by whether or not the merchant stores, transmits, or processes PANs. What does this mean in a practical sense? You may have to comply with the PCI DSS program and have few if any requirements to apply to your organization. We will discuss this in greater depth in the following sections.

Compliance vs. Validation

One of the other areas that creates some confusion is the difference between the need to comply with the PCI DSS requirements and the need to validate compliance. Compliance can be most easily defined as a “state of being,” while validation is proving to a third party that you are in a particular “state of being”. An example I use frequently to describe the difference is that of automobile insurance. In most states it is a law to have insurance if you own an automobile.

(6)

Simply having the insurance means you are in compliance with the law. If you are pulled over by a police officer for speeding, they will ask you to provide proof of insurance. Providing this proof is validation of your compliance with the law.

All companies that store, transmit, or process Cardholder Data (PANs) must comply with the PCI DSS.

Some of those companies may be required to validate their compliance through an onsite assessment conducted by a Qualified Security Assessor (QSA), completion of a Self Assessment Questionnaire (SAQ) or completion of a network security scan. Some companies may not be required to validate compliance.

This however does not excuse them from their obligation to comply with the PCI DSS.

Defining Cardholder Data

Cardholder Data is defined by the PCI DSS as the Primary Account Number (PAN) alone. Storing, transmitting or processing a single PAN obligates a company to comply with the PCI DSS requirements.

Cardholder name, expiration date, and service code are also considered Cardholder Data IF they are stored, transmitted or processed in conjunction with the PAN. Consider the example of a spreadsheet.

If in the first column you have the PAN and the second you have the Cardholder Name then both elements are considered Cardholder Data and thus subject to the PCI DSS. If however you only have a PAN in one spreadsheet and you maintain the Cardholder name on a CDRom locked in a safe, the PAN is considered Cardholder Data while the cardholder name is not because it is not stored with the PAN.

Understanding the Cardholder Data Environment (CDE)

It is paramount for anyone required to comply with the PCI DSS that they understand the definition of Cardholder Data Environment or what is commonly called the CDE. The Cardholder Data Environment is defined by the PCI DSS as:

“The cardholder data environment is that part of the network that possesses cardholder data or sensitive authentication data.”

The PCI DSS applies to the Cardholder Data Environment or CDE. Additionally, the PCI DSS applies to system components that are ‘connected to’ the CDE. To summarize, the PCI DSS requirements apply only to the Cardholder Data Environment and “connected systems”. Systems in this case include applications, devices, and servers or other computers.

(7)

Understanding that the PCI DSS applies to the CDE, it is logical then to try to minimize the footprint of the CDE. If, for example, a company could consolidate all of their Cardholder Data onto a single system that is completely isolated from the rest of the corporate network, then the CDE would consist only of that single system. The company then would only need to ensure that the single system is compliant with the PCI DSS. This is supported in the PCI DSS where it states:

“Network segmentation of, or isolating (segmenting), the cardholder data environment from the remainder of the corporate network is not a PCI DSS requirement. However, it is recommended as a method that may reduce:

The scope of the PCI DSS assessment The cost of the PCI DSS assessment

The cost and difficulty of implementing and maintaining PCI DSS controls The risk to an organization (reduced by consolidating cardholder data into fewer, more controlled locations)

Without adequate network segmentation (sometimes called a "flat network") the entire network is in scope of the PCI DSS assessment. Network segmentation can be achieved through internal network firewalls, routers with strong access control lists or other technology that restricts access to a particular segment of a network.”

Now that we have a clear understanding of which companies must comply with the PCI DSS (those that store, transmit, and process CHD), to what part of the environment the PCI DSS applies (Cardholder Data Environment) and that the PCI DSS requirements only apply of PAN is stored, transmitted or processed we can now delve into which requirements apply to a given environment.

The Compliance Spectrum

As seen in by the QSA’s previously referenced comments it is apparent, though unfortunate, that many in the industry have a very binary view of the PCI DSS programs and its requirements. There is almost ubiquitous belief that if a company must comply with the PCI DSS requirements then they must implement all 240+ sub-requirements to comply. This is an incorrect assumption. Before I go too much further let me state that I was a part of the team that created the Self Assessment Questionnaires (SAQ) that are used by companies validating compliance. As evidenced in the design of the SAQs it is recognized by the PCI SSC that not every requirement applies to every company, in every circumstance.

(8)

This is why SAQ A asks Card Not Present merchants that meet the criteria to only comply with Requirements 9 and 12. It is understood that the other requirements are addressed by the third party used by the merchant. Specifically, SAQ A states that it applies to:

“Merchant does not store, process, or transmit any cardholder data on merchant premises but relies entirely on third party service provider(s) to handle these functions;”

The PCI DSS acknowledges that appropriate segmentation can reduce the scope of the environment to which the PCI DSS requirements apply.

As stated, once the CDE has been properly defined and minimized, now the only real question left to answer is “what requirements apply to my company’s CDE?” Anyone who has attended a training event that I taught has likely heard me repeat the following seemingly ridiculous, circuitous statement numerous times:

“The PCI DSS requirements are applicable to the extent they apply to your environment.”

While the statement may appear ridiculous at first blush, it is accurate and can help when evaluating which requirements apply. As can be seen in the PCI SSC’s own documentation related to the Self Assessment Questionnaires, the Council does not consider every requirement to be applicable in every circumstance. In fact the applicability of requirements can most easily be viewed as a spectrum or sliding scale. Considering the following situation:

Company X receives Cardholder Data from their merchant clients and transmits the data to a processor without storing or otherwise processing the data. In essence, Service Provider X acts as a basic switch that only transmits data.

Would it be logical to expect Service Provider X to comply with requirement 3.4 of the PCI DSS that requires protection of stored data by encryption or other methods? The answer is a clear and definitive

‘No’. Why? There is no Cardholder Data being stored electronically therefore the requirement simply does not apply in this situation. It should be noted that this is a simple example used for demonstration purposes.

(9)

When considering the PCI DSS requirements to which your company must comply it is important to answer the following questions:

1. Does your organization store, transmit, or process Cardholder Data?

If the answer is ‘Yes’ then the PCI DSS requirements apply. Now it is important to understand which requirements.

2. Does your organization store Cardholder Data?

No; then the requirements related to storage don’t apply. This includes 3.4, 3.5 and 3.6 and other requirements.

Yes; then the requirements related to storage do apply. This includes 3.4, 3.5 and 3.6 among others.

3. What technology is employed in your organization?

As an example, if your company does not employ wireless technology then the requirement related to using WPA2 would not be applicable. If your company does not develop applications internally than Requirement 6.5, which applies to secure development, would not apply.

While brevity prevents us from outlining every possible variable for the PCI DSS, it is enough to

understand that all requirements do not apply at all times. It is more important to understand that the easiest method to comply is to not store, transmit, or process data. For merchants that outsource all aspects of their storage, processing, and transmission of Cardholder Data, an abbreviated set of requirements apply to that merchant.

Consider the following example:

Merchant X accepts transactions by use of an imprint machine. While the merchant certainly stores Cardholder Data on receipts, the data is never transmitted, stored, or processed electronically.

In this scenario, the Cardholder Data Environment would consist of the imprint machine and the box used to store receipts. Why would anyone care whether Merchant X used WPA2 for wireless or deployed Anti-Virus on their systems? The answer is that while the PCI DSS applies, it is a limited sub- set of requirements that apply to a very limited CDE. It is this concept that we begin to define as the PCI DSS Compliance Spectrum.

(10)

The Compliance Spectrum can be best understood by looking at a graphic like the one below. On the left hand side of the spectrum a company would not have to comply with any PCI DSS requirements.

This situation likely exists in theory only, but for the sake of argument it provides a good starting point.

For a company that had a merchant account but did not use it at all to accept transactions, it could be argued that while they have an obligation to comply with the PCI DSS under the card brand operating regulations (see first section), in practice no actual requirements would apply as they would not be storing, transmitting, and/or processing Cardholder Data.

For a company that outsources all aspects of storage, transmission, and processing of Cardholder Data still has a requirement to comply with the PCI DSS and the requirements do apply. At a minimum the company would need to ensure that they have contracts in place with their outsourced service provider verifying their security controls and that any physical receipts are protected appropriately. This particular company would need to ensure that they comply with PCI DSS requirement 12.8 and possibly sections of PCI DSS requirement 9. As the company begins to handle more data in more ways and employs more technology, the number of requirements that would be applicable to their particular environment would increase thereby moving the merchant toward the right hand side of the spectrum.

It is possible that, in some instances, the merchant would need to comply with all of the PCI DSS requirements within their Cardholder Data Environment.

By ensuring that there is a firm understanding of the nuances of the PCI DSS and the applicability of the standard before embarking on a PCI DSS compliance project, companies can save time and money on their projects while simultaneously reducing the risk to their data.

ProPay’s ProtectPay® and the Compliance Spectrum

ProPay’s ProtectPay solution allows merchants to accept payments without storing, transmitting, or processing Cardholder Data within the merchant’s own environment. As discussed in this and other documents, without storing, transmitting, or processing Cardholder Data the PCI DSS requirements don’t apply.

(11)

It is important to understand that compliance with the PCI DSS program is required under the card brand rules however. By offloading the data to a third party and ensuring that the merchant never stores, transmits or processes their own data they have met compliance through the use of a PCI validated third party. In this case that third party is ProPay.

I have heard the one argument a number of times and feel it is important to address in this document.

Question: My company has a business need to access our client’s cardholder data and

as you have told us the PCI DSS now applies to my company. If this is the case what value would a solution like Protect Pay provide?

This is an interesting question and certainly is important to discuss. As this document explains, there may very well be requirements that apply to your organization. If your organization has a need to view data, this can be accomplished securely through terminal services, a Citrix session, or similar technologies. Would this potentially result in the organization needing to comply with additional requirements? Certainly it would. Looking at the compliance spectrum it is possible that additional requirements around system configurations and other aspects may apply. Even if it increased the need to comply with an additional 24 requirements (10% of the total number of sub-requirements) and the company had requirement to comply with all of Requirement 12.8 and some of Requirement 9 already (another 10%) reducing the compliance burden by 80% appears to be a very solid investment. More importantly, removing the data from the merchant environment reduces the risk associated with compromise of payment data significantly.

Summary

PCI DSS compliance can be a complex and confusing project for companies to undertake. Further confusing the process are well-intentioned yet misinformed individuals that either mistakenly or less frequently intentionally confuse the issues. Companies that are required to comply with the PCI DSS should invest in understanding the specific language and requirements of both the card brand security programs such as the CISP, SDP or DSOP as well as the PCI DSS standard. With this understanding companies can begin to approach PCI DSS using the Compliance Spectrum approach. This approach allows companies to address fewer requirements by outsourcing the storage and/or processing of their cardholder data.

(12)

Companies such as ProPay and their ProtectPay solution can not only alleviate a number of PCI DSS challenges for organizations but can also significantly reduce the risk to which companies are exposed by removing and housing their data in a secure environment.

About ProPay

ProPay leads the market in providing simple, safe and affordable credit card processing and electronic payment services for businesses ranging from the small, home-based entrepreneur to multi-billion- dollar corporations and enterprises. Whether you’re a small business or a large corporation, ProPay provides simple, safe and affordable merchant services and can help secure your payment data through robust encryption and tokenization. Call us today at (888) 227-9856 or email us at [email protected].

Corporate Headquarters:

3400 Ashton Boulevard, Suite 200 Lehi, UT 84043

(888) 227-9856

www.propay.com [email protected]

The information contained in this document represents the current view of ProPay, Inc. on the issues discussed herein as of the date of publication. It should not be interpreted as a commitment on the part of ProPay, Inc. and ProPay, Inc. cannot guarantee the accuracy of the information presented after the date of publication.

Specifications and content are subject to change without notice. This document is for informational purposes only.

PROPAY, INC. MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

ProPay is a trademark of ProPay, Inc. Other product or company names mentioned herein may be the trademarks of their respective owners.