Chapter 3 Why PCI Is Important

Introduction

Chances are if you picked up this book you already know something about the Payment Card Industry (PCI). This chapter covers everything from the conception of the cardholder protection programs by the individual card brands to the founding of the PCI Security Standards Council. Why? To make sure that you have not been misled and that you use the terminology in the right context. Also, many of the questions people ask have their origins in the history of the program, so it only makes sense that we start at the beginning.

What is PCI?

PCI is not a regulation. The term PCI stands for Payment Card Industry. What people are referring to when they say PCI is actually the PCI Data Security Standard (DSS), currently at version 1.1. However, to make things easy, we will continue to use the term PCI to identify the industry regulation.

Who Must Comply With the PCI?

In general, any company that stores, processes, or transmits cardholder data must comply with the PCI. In this book, we are primarily concerned with merchants and service providers. The merchants are pretty easy to identify—they are the companies that accept credit cards in exchange for goods or services. However, when it comes to service providers, things get a bit trickier. A service provider is any company that processes, stores, or transmits cardholder data, including companies that provide services to merchants or other service providers.

Figure 3.1 shows the relationship among the different parties.

There are different levels of merchants and service providers. Tables 3.1 and 3.2 show the breakdown.

Table 3.1 Merchant Levels

Merchant Level	Description
Level 1	Any merchant that processes more than 6 million Visa or MasterCard transactions annually. Any merchant that processes more than 2.5 million American Express transactions annually.
Level 2	Any merchant that processes between 1 million and 6 million Visa transactions annually. Any merchant that processes more than 150 thousand MasterCard e-commerce transactions annually. Any merchant that processes between 50 thousand and 2.5 million American Express transactions annually.
Level 3	Any merchant that processes between 20 thousand and 1 million Visa e-commerce transactions annually. Any merchant that processes more than 20 thousand MasterCard e-commerce transactions annually. Any merchant that processes less than 50 thousand American Express transactions annually.
Level 4	All other Visa and MasterCard merchants.

Table 3.2 Service Provider Levels

Level	MasterCard	Visa USA
Level 1	All third-party providers (TPPs) All data storage entities (DSEs) that store, process, or transmit cardholder data for Level 1 and Level 2 merchants	Any VisaNet processor All payment gateways
Level 2	All DSEs that store, process, or transmit cardholder data for Level 3 merchants	Any service provider that stores, processes, or transmits one million or more Visa accounts or transactions annually
Level 3	All other DSEs	Any service provider that stores, processes, or transmits less than one million Visa accounts or transactions annually

These levels exist mainly for ease of compliance validation. It is a common misconception that the compliance requirements vary among the different levels. Both merchants and service providers must comply with the entire DSS, regardless of the level. Only verification processes and reporting vary.

It is possible for a company to be a merchant and a service provider at the same time. If this is the case, the circumstances should be noted, and the compliance must be validated at the highest level. In other words, if a company is a Level 3 merchant and a Level 2 service provider, the compliance verification activities should adhere to the requirements for a Level 2 service provider.

Dates to Remember

When do I need to be compliant? Some of you recall receiving a letter from your company’s bank or a business partner that had a target compliance date. This date may or may not be aligned with the card brands’ official dates. This is because the card brands may not have a direct relationship with you, and are working through the business chain. When in doubt, always follow the guidance of your legal department that has reviewed your contracts.

Barring unusual circumstances, the effective compliance deadlines have long passed. Various predecessor versions of the PCI 1.1 standard had unique dates associated with them, so if your compliance efforts have not been aligned to the card brand programs, you are way behind the curve and will likely not get any sympathy from your bank.

Table 3.4 Compliance Dates for Service Providers

Level	MasterCard	Visa USA
Level 1	June 30, 2005	September 30, 2004
Level 2	June 30, 2005	September 30, 2004
Level 3	June 30, 2005	September 30, 2004

Compliance Process

Depending on your company’s merchant or service provider level, you will either need to go through an annual on-site PCI audit, or complete a Self-assessment Questionnaire (SAQ) to validate compliance. In addition to this, you will have to present the results of the quarterly network perimeter scans (which had to be performed by an approved scanning vendor), evidence of internal vulnerability scans, and evidence of application and network penetration tests. In other words, you have to prove to the card brands that your company practices sound patch management and vulnerability management processes.

For the penetration tests, you will need to test every external application that stores, processes, or transmits cardholder data, and test the external network segment, also known as the demilitarized zone (DMZ). Penetration tests are not vulnerability scans. They are much more involved, and are not automated. You cannot simply buy a tool and execute a command to run such tests. While PCI does not require penetration tests to be performed by a third party, the authors of this book recommend that you do, unless you have strong ethical hacking expertise in-house.

When submitting a SAQ, it will have to be signed by an officer of your company. At the present time, there is no court precedent for liability; however, industry speculation is that this person may be held accountable in a civil court, especially if he or she commits an act of perjury.

If you are planning on submitting a Report On Compliance (ROC) instead of the SAQ, you will need to follow the document template outlined in the PCI DSS Security Audit Procedures document. After the SAQ has been filled out or the ROC has been completed, it must be sent along with all of the necessary evidence and validation documentation to either the acquirer, the business partner, or to the card brand directly. It depends on who requested the compliance validation in the first place.

Roots of PCI

PCI DSS is the standard that has evolved from the efforts of several card brands. In the 1990’s, the card brands developed various standards to improve the security of sensitive information. In the case of Visa, different regions came up with different standards (i.e., European countries were subject to different standards than the US). In June 2001, Visa USA launched the Cardholder Information Security Program (CISP). The CISP Security Audit Procedures document version 1.0 was the grand-daddy of PCI DSS. These audit procedures went through several iterations, and made it to version 2.3 in March of 2004. At this time, Visa was already collaborating with MasterCard. Their agreement was that merchants and service providers would undergo annual compliance validation according to Visa’s CISP Security Audit Procedures, and would follow MasterCard’s rules for vulnerability scanning. Visa maintained the list of approved assessors and MasterCard maintained the list of approved scanning vendors.

This collaborative relationship had a number of problems. The lists of approved vendors were not well-maintained, and there was no clear way for security vendors to get added to the list. Also, the program was not endorsed by all card brand divisions. Other brands such as Discover, American Express, and JCB were running their own programs. The merchants and service providers in many cases had to undergo several audits just to prove compliance to each brand, which was clearly costing too much. For that and many other reasons, all card brands came together and created the PCI DSS 1.0, which gave us the concept of PCI compliance.

Unfortunately, the issue of ownership still was not addressed, and a year later the PCI Security Standards Council was founded (https://www.pcisecuritystandards.org). Comprised of American Express, Discover Financial Services, JCB, MasterCard Worldwide, and Visa International, PCI Co (as it came to be known) maintains the ownership of the DSS, most of the approved vendor lists, training programs, and so forth. There are still exceptions, as the list of approved payment application assessors at the time of this book’s publication is still maintained by Visa.

Each card brand/region maintains its own security program beyond PCI. These programs go beyond the data protection charter of PCI and include activities such as fraud prevention. The information on such programs can be found in Table 3.5. In certain cases, PCI ROC needs to be submitted to each card brand’s program office separately.

Table 3.7 Brand Security Programs

Card Brand	Additional Program Information
American Express	Web: www.americanexpress.com/datasecurity E-mail: [email protected]
Discover	Web: www.discovernetwork.com/resources/data/data_security.html E-mail: [email protected]
JCB	Web: www.jcb-global.com/english/pci/index.html E-mail: [email protected]
MasterCard	Web: www.mastercard.com/sdp E-mail: [email protected]
Visa USA	Web: www.visa.com/cisp E-mail: [email protected]
Visa Canada	Web: www.visa.ca/ais

More about PCI Co

PCI Cos charter provides oversight to the development of PCI security standards on a global basis. It formalizes many processes that existed informally within the card brands. PCI Co published the updated DSS, now at version 1.1, which is accepted by all brands and international regions, and it refreshed most of the supporting documentation.

PCI Co is technically an independent industry standards body, and its exact organizational chart is published on its Web site. Yet it remains a relatively small organization, primarily comprised of the employees of the brand members. In fact, the role of answering e-mails sent to [email protected] rotates every month among the representatives of the card brands.

The industry immediately felt the positive impact of PCI Co. The merchants and service providers can now play a more active role in the compliance program and the evolution of the standard, while the Qualified Security Assessor Companies (QSACs) and Approved Scanning Vendors find it much easier to train their personnel.

Approved Assessor and Scanner Companies

PCI Co now controls what companies are allowed to conduct on-site DSS compliance audits. These companies, known as Qualified Security Assessor Companies (QSACs), have gone through the application and qualification process, having had to demonstrate compliance with tough business, capability, and administrative requirements. QSACs also had to invest in personnel training and certification to build up a team of Qualified Security Assessors (QSAs).

QSACs have to recertify annually, and have to re-train their internal personnel. The exact qualification process and the requirements are outlined on PCI Co’s Web site, so we will not go into it in detail; however, of particular interest are the insurance requirements. QSACs are required to carry high coverage policies, much higher than typical policies for the professional services firms, which becomes important later.

To become an Approved Scanning Vendor (ASV), companies must undergo a process similar to QSAC qualification. The difference is that in the case of QSACs, the individual assessors attend classroom training on an annual basis, whereas ASVs submit a scan conducted against a test Web perimeter. An organization can choose to become both QSAC and ASV, which allows the merchants and service providers to select a single vendor for PCI compliance validation.

Qualified Security Assessors

QSA is a certification established by PCI Co. Individuals desiring this certification must first and foremost work for a QSAC or for a company in the process of applying to become a QSAC. Then, they must attend official training administered by PCI Co, and pass the test. They must also undergo annual requalification training to maintain their status. An individual may not be a QSA unless he or she is presently employed by a QSAC.

Overview of PCI Requirements

PCI DSS version 1.1 is comprised of six control objectives that contain one or more requirements:

• Build and Maintain a Secure Network
  • Requirement 1: Install and maintain a firewall configuration to protect cardholder data
  • Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
• Protect Cardholder Data
  • Requirement 3: Protect stored cardholder data
  • Requirement 4: Encrypt transmission of cardholder data across open, public networks
• Maintain a Vulnerability Management Program
  • Requirement 5: Use and regularly update anti-virus software
  • Requirement 6: Develop and maintain secure systems and applications
• Implement Strong Access Control Measures
  • Requirement 7: Restrict access to cardholder data by business need-to-know
  • Requirement 8: Assign a unique ID to each person with computer access
  • Requirement 9: Restrict physical access to cardholder data
• Regularly Monitor and Test Networks
  • Requirement 10: Track and monitor all access to network resources and cardholder data
  • Requirement 11: Regularly test security systems and processes
• Maintain an Information Security Policy
  • Requirement 12: Maintain a policy that addresses information security

As you can see, these 12 requirements cover the whole spectrum of information technology (IT) areas. Some requirements are very technical in nature (e.g., Requirement 1 calls for specific settings on the firewalls), and some are process oriented (e.g., Requirement 12).

PCI is the most tactical regulation, which has a significant benefit. It makes things easier for both the companies that have to comply with the standard, and the auditors. For example, when compared to the Sarbanes Oxley Act of 2002 (SOX), companies do not have to invent or pay for controls; they are already provided. Also, PCI is much less nebulous than the Health Insurance Portability and Accountability Act (HIPAA) Security Rule with its “required” and “addressable” requirements.

PCI compliance validation may affect more than what you consider the “cardholder environment.” According to PCI DSS 1.1, the scope can include the cardholder data environment only if adequate network segmentation is in place. In most cases, this implies the use of dedicated firewalls and non-routable virtual local area networks (VLANs). If you do not have such controls in place, the scope of PCI compliance validation will cover your entire network. Think about it: if you cannot ensure that your cardholder data is confined to a particular area, then you cannot focus on this area alone, and you have to look everywhere.

Point of sale (POS) systems also may change the scope of compliance validation. If POS system does not have any connections to the rest of the merchant’s network, it may be excluded from the validation process. The compliance of the POS system itself is determined by a Qualified Payment Application Security Company (QPASC) or the card brands. Contact the card brands to determine of your POS system has already been determined to be compliant.

If wireless technology is used within the cardholder data environment, or if the cardholder data environment is not adequately segmented, separate procedures will have to be used to validate compliance. PCI Co does not consider wireless technologies to be sufficiently mature; therefore, they are treated with extra caution.

For the benefit of consumers that may be more familiar with a brand name than a parent company, PCI compliance is validated for every brand name. Thus if a company has several divisions or “doing business as” (DBA) names, each entity has to be validated separately. For reporting simplicity, the ROCs and SAQs may note that they include validation of multiple brand names.

You may discover that sometimes it is necessary to bend the rules for a legitimate business need. For example, you may need to temporarily store cardholder data unencrypted for troubleshooting purposes. As long as you follow reasonable precautions, card brands understand this need. Another example may include recording certain call center conversations for customer service purposes. Again, card brands understand that these recordings may contain cardholder data, so accommodations are made accordingly.

In many cases, compensating controls have to be used to achieve compliance when your company cannot meet a given requirement exactly. The important thing to remember about compensating controls is that they have to go beyond the requirements of PCI to provide the same or higher assurance of cardholder data protection. When compensating controls are claimed, additional documentation must be completed. The Compensating Control Worksheet, which can be found in Appendix C of the PCI DSS Security Audit Procedures document, must be filled out for each situation.

Risks and Consequences

If you are a Chief Financial Officer (CFO) or a comptroller, you are probably asking the question: “Why would I need to spend the money on PCI?” Good question—there are fines! Unfortunately, the fine schedules are not well defined. Your company’s contract with the acquiring bank probably has a clause in it that any fines from the card brand will be “passed through” to you. With all compliance deadlines passed, the fines could start tomorrow. Visa USA has announced that it will start fining acquirers (which will pass on the costs to the merchant) between $5,000 and $25,000 per month if their Level 1 merchants have not demonstrated compliance by September 30, 2007, and Level 2 merchants have not demonstrated compliance by December 31, 2007. In addition, the fines of $10,000 per month may already be assessed today for prohibited data storage by Level 1 or Level 2 merchant (usa.visa.com/about_visa/press_resources/news/press_releases/nr367.html).

What is certain is that you will be fined up to $500,000 if non-compliant and compromised. Believe it or not, if compromised, this will be the least of your concerns. Civil liabilities will dwarf the fines from the card brands. Some estimates place the cost of compromise at $80 per account. Some companies that have been compromised have been forced to close their doors. According to PCI Co and the Ponemon Institute study, the per capita cost of a data breach has gone up more than 30 percent in the past year.

In addition to fines, after a compromise, assuming you are still in business, the company automatically gets Level 1 status for compliance verification and the audit process gets significantly more expensive. Consider the cost of data forensic services, increased frequency of reporting, and so forth. Not to mention that you will still have to comply with PCI eventually if you want to continue to be able to accept them, or be in the related line of business.

Let’s use TJX company, which operates stores like TJ Maxx, Marshalls, and so forth, as a case study. On January 17, 2007, TJX announced that they were compromised. Because they did not have robust monitoring capabilities such as those mandated by PCI, it took them a very long time to discover the compromise. The first breach actually occurred in July 2005. TJX also announced that 45.7 million credit card numbers were compromised. Conservative estimates put a five-year cost estimate to TJX at over one billion dollars. To date, over 20 separate law suits have already been filed against TJX.

Whether you believe your company to be the target or not, the fact is that if you have cardholder data, you are a target. Cardholder data is a valuable commodity that is traded and sold illegally. Organized crime units profit greatly from credit card fraud, so your company is definitely on their list. International, federal and state law enforcement agencies are working hard to bring perpetrators to justice and shut down the infrastructure used to aid in credit card related crimes; however, multiple forum sites, Internet chat channels, and news groups still exist where the buyers can meet the sellers. Data breaches like the one at TJX are not the work of simple hackers looking for glory. Well-run organizations from the Eastern European block and select Asian countries sponsor such activity.

Privacyrights.org maintains the history of the compromises and impacts. Since 2005, over 150 million personal records have been compromised. This includes companies of all sizes and lines of business. If the industry does not get this trend under control, the US Congress will give it a try. In February 2007, Congress has already debated a data retention bill. It is a safe bet that any legislation that is enacted into law will carry much stiffer penalties than the card brands assess today.

Today, according to the information security experts, the following constitute the greatest risk of a data breach:

• Wireless networks
• Lack of adequate network segmentation
• Application remote exploit
• Compromise by an employee with access

Last, but not least is the involvement by the Federal Trade Commission (FTC). Sometimes protection of credit card data also falls within the realm of the Gramm-Leach-Bliley Act (GLBA), a law that protects the consumers’ right to privacy. Disclosure of the credit card information can lead to identity theft. Remember the ChoicePoint incident? That company was fined $10 million by the FTC, and had to reimburse expenses to the victims of the identity theft.

Benefits of Compliance

One of benefits of PCI compliance is that your organization will not be fined in case of a compromise. If the post-mortem analysis shows that your company was still compliant at the time of the incident, no fines will be assessed, and you will be granted what is known as “safe harbor.” It is likely that your company will be taken to civil court regardless of your compliance status should a breach occur. However, a jury will be much more sympathetic to your company’s case if you can show that due diligence was practice by the virtue of PCI compliance.

More immediately, if your company is a Level 1 or Level 2 merchant, you may be eligible to receive a part of the $20 million in financial incentives from Visa. In December 2006, Visa USA announced their PCI Compliance Acceleration Program (CAP). Those merchants that demonstrate compliance by August 31, 2007, may receive a one-time payment incentive. The press release for this program can be found at http://usa.visa.com/about_visa/press_resources/news/press_releases/nr367.html.

Another form of incentive deals with transaction costs. As part of the CAP program, Visa USA announced that the interchange rates will not be discounted for acquirers that have not validated PCI compliance of their merchant clients. Come October 1, 2007, acquirers may start passing the increased costs to the merchants that have not reached compliance.

Whether it is avoiding fines or getting incentives, the greatest benefit of PCI compliance is the peace of mind that your IT infrastructure and business processes are secure. Again, if you are a CFO or a comptroller, think about the data breach cost avoidance. Crunch the ROI numbers as you read more and more about TJX’s plight.

Your marketing department may also appreciate the compliance status. The name of your company will be listed on each card brand’s Web site. You can also get certification logos from your QSAC, a must have for your Web site. A recent poll showed that 40 percent of consumers will not deal with a company they know has been breached, so by addressing your customers’ concerns you may get more business in the process.

Summary

PCI refers to the DSS established by the credit card brands. Any company that stores, processes, or transmits cardholder data has to comply with this data protection standard. Effectively, all of the target compliance dates have already passed, so if your company has not validated compliance you may be at risk of fines. PCI is composed of 12 requirements that cover a wide array of business areas. All companies, regardless of their respective level, have to comply with the entire standard as it is written. The actual mechanism for compliance validation varies based on the company classification. The cost of dealing with data breaches keeps rising, as does their number. Companies that do not take compliance efforts seriously may soon find themselves out of business. Yet the companies that are proactive about compliance may be able to capture additional business from the security-conscious consumers.

Solutions Fast Track

PCI

• PCI is used synonymously with PCI DSS.
• If you are not compliant already, you are late. Most compliance deadlines have already passed.
• PCI is not perfect, so be prepared for bumps in the road.
• PCI compliance cannot be a project—it is a process. Keep your project on a more manageable level, perhaps one for each DSS requirement.

Get an Advice From Someone Who Knows

• Seek the help of a trusted advisor who can help steer your compliance efforts.
• PCI DSS requirements are often misinterpreted. Validate what you believe to be true or what you are being told.
• When selecting a trusted advisor, look for the reputation and stability before you look at cost. The two of you might have to team up in the courtroom, so build a relationship.

Get the Facts

• Get an assessment by a QSAC. If your company is close to being compliant, it will take very little additional effort to turn an assessment report in to a ROC.
• Contract the services of the ASV for performing the quarterly perimeter scans and penetration tests.
• Consider using the same company for both assessments and scans. That way you have better communication.
• Deal directly with a QSAC, not with a middle man.

Start at the Top

• Get an endorsement from the company’s senior management and business stakeholders.
• Start your remediation efforts with higher level concepts: first the policy, then the process, then standards and procedures.
• Don’t forget to document everything!

Frequently Asked Questions

The following Frequently Asked Questions, answered by the authors of this book, are designed to both measure your understanding of the concepts presented in this chapter and to assist you with real-life implementation of these concepts. To have your questions about this chapter answered by the author, browse to www.syngress.com/solutions and click on the “Ask the Author” form.