PA-DSS Guidelines for Testing Laboratories

Software vendors that develop distributed applications that handle cardholder data are aware of the necessity to comply with the Payment Application Data Security Standard (PA-DSS), a standard created to protect the global payment processing system by requiring all relevant applications to conform to strict guidelines.  A Payment Application Qualified Security Assessor (PA-QSA) is an important ally in promoting the dissemination of quality payment applications. This is a company that has been certified by the PCI SSC to perform analyses of payment applications to ensure PCI compliance.  In fact, a PA-QSA is the only entity authorized to perform these assessments.

The PCI SSC has developed a variety of rules that PA-QSAs must follow during these assessments -- including the use of a testing laboratory. Per these guidelines, the assessment can take place only in a lab controlled by the PA-QSA or the software vendor.  Either way, the site must allow the assessor to utilize the application in a way that appropriately simulates real-world conditions -- for example, the testing should involve valid test card numbers, rather than authentic PANs.

Ideally, the assessor should perform the analysis at its own site, but the PCI SSC allows the use of the vendor's lab, so long as it is necessary -- because, for instance, the vendor has equipment unavailable to the PA-QSA -- and the facility is adequate to the purpose.  To ensure that the environment has not been compromised, however, the PA-QSA in this case must ensure that the software vendor has not tampered with the lab environment. In addition, the lab must allow for a range of penetration test methodologies, including those that uncover forensic data and attempt-to-exploit vulnerabilities.

For further information on laboratory requirements, consult Appendix B of the Payment Application Data Security Standard Requirements and Security Assessment Procedures.


Upcoming Changes to the PCI Data Security Standard

Most of you have heard by now that an updated version of PCI Data Security Standard (PCI DSS) is due for publication in November. In fact, the impending release of Version 3.0 has occasioned a fair amount of hand-wringing among some merchants and other members of the payment processing community, as changes to the PCI DSS could conceivably force organizations to make substantial upgrades to their systems and increase the difficulty of staying PCI compliant.  Much of the mystery, however, was resolved at the recent seventh Annual North American PCI Community Meeting, attended by 1300 payment processing professionals from no less than 25 countries.  Among other attractions offered by the Meeting, the attendees were allowed a glimpse at Version 3.0.  Several participants have already reported on what they found in the new and improved PCI DSS. 

Keep in mind that the official publication date for Version 3.0 is still several weeks away, and at this point, it hasn't been finalized.  It's possible that a few more changes will be introduced in the intervening time.  Nonetheless, the Standard that was presented at PCI Community Meeting is almost certain to be substantially the same as the one that will be released in November.  The consensus seems to be that version 3.0 has been changed more than a little from the previous version, but less than a lot. 

Among the reported changes: 

  • Additional guidance on detecting compromised POS terminals. 
  • Additional responsibilities for third-party providers that maintain data protection services. 
  • Tweaks to Requirement 6, adding responsibilities for those in charge of PCI audits (e.g., Qualified Security Assessors). 
  • Tweaks to Requirement 11, providing additional guidance relating to penetration testing and similar procedures.
This is not a comprehensive list, but rather a preview.   The final word will come in November.


A Map to EMV

For decades, consumers in the U.S. have used magnetic stripe credit cards to make point-of-sale purchases.  Although convenient, these types of cards have long been known to pose data security weaknesses that criminals can exploit.  To reduce the incidence of credit card fraud, researchers devised a payment processing standard known as EMV, whose initials stand for the organizations—Europay, MasterCard, and Visa—responsible for backing its initial development in the 1980s.

Introduced in France back in 1984, EMV payment cards have gradually spread to markets in 130 countries across the globe, and they have proven to be highly effective in combating card-present fraud.  They are also known as “Chip & PIN” cards because they utilize microchips instead of magnetic stripes, and PIN entry for verification purposes in addition to that standard signature.  For the most part, an EMV transaction is very similar to a traditional credit card transaction.  EMV cards, however, utilize microchips that generate transaction-specific data through a process known as dynamic authentication.  This information, which differs with each use of the card, cannot be effectively utilized by identity thieves and other types of criminals.  Consequently, these payment cards are far more secure than old-fashioned credit cards.

The U.S. is the last EMV holdout among the major markets, but this will change in the near future.  The payment card brands have announced a schedule of “liability shifts” that will mark dates by which U.S. merchants must make the transition to EMV.  Current estimates predict that 60% of merchants will have EMV-capable devices in place by 2015. 

The following infographic, created by our team at Element Payment Services, gives a breakdown of what EMV is, how it works, presents the benefits of EMV and also gives a brief history of how EMV came to be.


A Map to EMV

Click below to embed this infographic into your website

<img src=http://blog.elementps.com/.a/6a010534b0dc03970c019affc1d8d0970b-800wi /> <br><a href=http://blog.elementps.com/old_one/2013/10/a-map-to-emv.html title="What is EMV?" width="550"> A Map to Element Payment Services</a>


Vote for Element in Business Solutions' Survey!

Element Payment Services is pleased to announce that it will be participating in this year's Best Channel Vendors Survey conducted by Business Solutions magazine.  This is an annual contest intended to publicize high-achieving companies in a variety of industries, and in past years Element has done quite well.  In fact, our company was named Best Channel Vendor in 2010, 2011, 2012, and 2013, as well as Best Channel Product in 2010 and 2011.  We at Element are hoping for a repeat performance in 2014, and with this in mind we invite you to vote for us in the latest survey.

Element has been nominated in the Payment Processing category of the survey.  To vote, simply follow these simple steps:

  1. Access the survey at http://www.surveymonkey.com/s/X2V7FKT
  2. Scroll down to the Point of Sale/Payment Processing category and rate Element!

To encourage participation, Business Solutions magazine has made the survey shorter than in previous years.  Completing the 2014 survey should take less than ten minutes, and all participants earn an entry into a drawing to win a $100 Visa gift card (three are available).  Voting ends on October 9, 2013.

Your vote will be kept confidential; only aggregate results will be posted.  Winners will be announced in the January 2014 issue of Business Solutions and also featured throughout the year on the magazine's online home, BSMinfo.com.  Recognition from Business Solutions is a huge honor for any company, so we hope that our supporters and colleagues will take the time to fill out the survey.


The PCI SSC’s Proposed Changes to the PCI Data Security Standard

The PCI SSC’s Proposed Changes to the PCI Data Security Standard

November of this year will see some significant changes in the payment processing world, as version 3.0 of the PCI Data Security Standard will be officially published.  This event marks the final stage in the three-year cycle of research and development that precedes each new version of the PCI DSS, and the updated requirements will begin going into effect on January 1st. 

The PCI Security Standards Council (PCI SSC) has  posted a document that highlights the changes that are expected to be included in version 3.0.  As version 3.0 will not be officially finalized until its publication in November, the changes mentioned should be considered provisional in nature, but collectively they should reliably indicate the general direction that the new version of the PCI DSS has taken.

So what should we see in PCI DSS v.3?  There are a handful of consistent themes that the new version will emphasize.  One of them is increased flexibility in complying with certain data security regulations; merchants will now have more options when conforming to requirements pertaining to password security, authentication methods, and malware defense.  Version 3 also emphasizes internal reporting procedures, such as maintaining current data flow diagrams and system component inventories, to help companies understand and keep track of their data security obligations. In sum, the updated PCI DSS is about clarifying existing guidelines and supplying further guidance.


An Overview of the Payment Brands' Merchant Levels

As we've already seen, all types of businesses have an obligation to verify their continued adherence to PCI requirements by annually completing an attestation of compliance. The nature of this reporting requirement depends on a given organization's "merchant level," which is usually calculated according to the business's annual volume of payment card transactions.  Furthermore, each payment brand has its own merchant level system.  All of this can be confusing, but the system of merchant levels is really much simpler than it seems.

In general -- there are exceptions that we'll explore below -- a business will be separately classified by each applicable payment brand as a Level 1, 2, 3, or 4 merchant.  Merchants in levels 2 through 4 are typically required to fill out a Self-Assessment Questionnaire (SAQ) once a year and go through a quarterly vulnerability scan every quarter by an Approved Scanning Vendor (ASV)   Matters become more complicated for level 1 merchants:  They're usually required to comply with an on-site inspection of the payment processing environment, which tends to be both relatively time-consuming and expensive.

What constitutes a Level 1 merchant?  This designation is categorized one of two ways:  (1) by being a high-volume merchant that processes more than a specified number of credit card transactions or (2) by having a history of data breaches.  This second factor,  provides yet another reason to maintain PCI compliance and protect your cardholder data

The various payment brands maintain different criteria for determining which companies will be classed as Level 1:

  • Visa -- The merchant handles over 6 million Visa transactions, across all channels, in a single year.
  • MasterCard -- The merchant handles over 6 million MasterCard transactions in a single year.  MasterCard will also designate a merchant as Level 1, if Visa has done so.
  • American Express -- The merchant handles over 2.5 American Express transactions in a single year.  Incidentally, American Express’ scale recognizes only Levels 1, 2, and 3.  
  • JCB -- The merchant handles over 1 million JCB transactions in a single year.  JCB's merchant scale recognizes only Levels 1 and 2.
  • Discover -- This payment brand does not assign merchant levels based on volume of payment card transactions.  Merchants are classified as Level 1, 2, or 3 according to Discover's own risk assessment of the company's payment services. 


How to Prepare for a Penetration Test

We have already explored penetration tests, their nature, and their usefulness for maintaining PCI compliance.  So how should a company prepare for one of its pen tests?  To begin, it’s important to understand that these tests come in two distinct varieties:  white box and black box.  In a black box test, the entity has no prior knowledge of the system that is to be examined, which means the tester is charged with the two-pronged task of locating the various components of a company’s data environment and attempting to exploit its weaknesses.  Conversely, a white box test is one where the tester is given relevant information about the system before conducting the probe.  Either type of test is acceptable for the purpose of fulfilling PCI Data Security Standard (PCI DSS) Requirement 11.3.

If your company opts for a white box test, then you should gather data and documentation that would aid the tester.  Fortunately, it is likely that you have already generated a fair amount of useful paperwork as part of your efforts to maintain PCI compliance, and these can be turned over to the tester for examination.  This documentation may include, but is not limited to, the following:

  • Network diagrams
  • Results from most recent penetration test
  • Results of vulnerability scans (mandated by Requirement 11.2)
  • Company security policies
  • Risk assessment reports
As the purpose of the pen test is to uncover any and all data security weaknesses in a company’s cardholder data environment, the company undergoing this procedure should be prepared to aid the tester by supplying all pertinent information.


What Are the Benefits of Providing an Integrated PCI-Compliant Payment Solution in Your Software?

Merchants need payment processing solutions that meet or surpass the requirements of the PCI Data Security Standard (PCI DSS).  Of course, this is hardly news to software providers that supply these types of solutions.  What may be news, however, is that offering a “fully integrated” payment solution can provide a variety of benefits that aren’t possible with so-called multi-integrated ones.  With the latter, a merchant may get stuck with an unwieldy patchwork of third-party software with varying upgrade requirements.  Consequently, the merchant must cope with the hassles of ensuring that all of these components remain up to date, which in turn could result in falling out of PCI compliance.  This is the sort of awkward arrangement that many businesses cope with, but it’s simply not good news for their bottom line.  One way to get around this problem is to go with a single company that has a fully integrated solution that can handle all facets of payment processing while reducing the scope of PCI compliance.

A fully integrated payment processing solution also allows merchants to eliminate the need for duplicate data entry.  Rather than entering the same data multiple times to accommodate dissimilar software, the operator can simply type in the information once.  As a result, the merchant saves time—which, as the old adage says, saves money—and also reduces the possibility of introducing errors into the process.  

Security and maintenance issues become vastly simplified when only one company is responsible for all aspects of your payment processing solution.  Furthermore, the benefits of this arrangement become maximized when the solution is designed to comply with the PCI DSS.  


What Are Visa's Four Merchant Levels?

Every business that accepts payment cards is required to follow the guidelines of the PCI Data Security Standard (PCI DSS).  This is true for organizations of all sizes, from large corporations that process millions of credit card transactions per year, to tiny storefront shops that handle only a few of them.  Even so, the major payment brands responsible for enforcing the PCI DSS recognize that businesses are not all alike, and for this reason a particular business' compliance requirements are customarily adjusted according to the volume of transactions that it handles on an annual basis.  Every business is classified as belonging to one of four possible merchant levels.  To maintain PCI compliance, it's important to know where your business stands in this arrangement. 

But first, you should keep in mind one important fact:  There is no standard merchant level hierarchy that is universally recognized by all payment brands.  Each of the major payment brands has its own scheme and associated reporting demands..  To simplify matters, we'll take a look at the Visa categories-- the one most commonly referenced in discussions on the subject.  The four merchant levels according to Visa run as follows:

  • Level 1 -- This level is for merchants that process more than 6 million Visa card transactions per year (across all payment card channels).  Merchants in this category are generally required to consent to an annual onsite inspection conducted by a Qualified Security Assessor (QSA), concluding with the filing of a Report on Compliance (ROC); in addition, they must arrange for a quarterly network scan by an Approved Scanning Vendor (ASV).  Visa can, at its discretion, classify a merchant as Level 1 even if the business does not process over six million payment cards per year; this often occurs in organizations with a history of data breaches, or one reasonably suspected of inadequate payment processing methods.
  • Level 2 -- This level is for merchants that process 1 million to 6 million Visa transactions per year (across all payment card channels).  Merchants are allowed to forego costly QSA inspections; instead, they satisfy this reporting requirement by filling out a Self-Assessment Questionnaire (SAQ).  They are also required to undergo quarterly network scans by an ASV.
  • Level 3 -- This level is for merchants that process 20,000 to 1 million Visa ecommerce transactions per year.  Businesses in this category fill out a SAQ and consent to quarterly ASV network scans.
  • Level 4 -- This level is for merchants that process fewer than 20,000 Visa ecommerce transactions per year, AND any others that process under 1 million Visa transactions of all kinds.  This category usually requires a SAQ and quarterly ASV network scans.  


Information Included in the Annual Attestation of Compliance Report on Compliance

Merchants of all sizes are required by the PCI Security Standards Council (PCI SSC) to complete an annual attestation of compliance to ensure that they continue to follow PCI requirements. Smaller businesses (Level 4 Merchants) can fulfill this requirement by completing a Self-Assessment Questionnaire (SAQ).  But Level 1 merchants -- that is, those that process at least 6 million Visa or MasterCard transactions per year -- must complete a comprehensive on-site inspection of their payment processing environment, usually carried out by a third-party entity known as a Qualified Security Assessor (QSA).  This process concludes when the inspector fills out a Report on Compliance (ROC) and sends it to the appropriate acquiring bank. 

Because the ROC applies only to large-volume merchants, it's likely that you may never have to deal with this particular element of PCI compliance, but it may be educational to take a look at this documentation. According to the PCI SSC, the Report on Compliance must follow a specific template; this is too elaborate to reproduce in full here, so we'll supply only the main points that it covers.  The ROC includes the following information:

  • Executive summary -- This is the assessor's general description (i.e., not simply copied from the company's website or other materials) of the business' payment card processes.  This section should include a diagram of the company's payment network.
  • Description of the assessor's investigatory approach -- This is a description of the assessor's procedures involved in the investigation -- the methods used as well as the systems and environments examined.  The assessor should note whether the payment card environment utilizes segmentation, whether sample procedures were employed (and, if so, on which environments), whether any wireless payment applications are present, and whether the company is affiliated with other business entities that may fall under PCI regulations.  
  • Details about the payment processing environment -- This is a description of the cardholder data environment, including a listing of all hardware, software, and third-party payment applications used, as well as any personnel interviewed and documentation consulted.
  • Contact information -- This section simply provides contact info for the assessor and the investigated entity.  It should also include the timeframe in which the assessment was conducted and the date of the report.
  • Quarterly scan results -- This is a summary of the four most recent vulnerability scans, as conducted by an Approved Scanning Vendor (ASV). 
  • Additional observations -- This is where the assessor includes any pertinent comments that do not fit into the other sections. 

Search Blog

Your email address:

Bookmark and Share


About PCI DSS Compliance Blog

Email Us

PCI Compliance Resources

Industry News on Twitter

Visit Element on