Topics Covered in the PA-QSA Training Course

We've already seen how a Payment Application Qualified Security Assessor (PA-QSA) performs a valuable function by checking software applications for any PA-DSS oversights before the product reaches the market. It's an important job, and anyone who carries out this kind of inspection should have a high degree of relevant expertise. For this reason, the PCI Security Standards Council (PCI SSC) requires those who wish to become a qualified PA-QSA to take a PCI SSC approved class to instruct them on all essential aspects of assessing payment applications. PA-QSA coursework is comprised of the following six categories:

  • Overview of the payment card industry -- Students explore the world of payment processing, including current terminology, basic procedures, and the major players involved.
  • PCI and card brand requirements -- Students learn how "PCI compliance" relates to various entities, such as vendors, merchants, and software providers.  Students also learn the individual standards of the payment card brands (Visa, MasterCard, Discover, and American Express.) 
  • A detailed look at the PCI Data Security Standard -- Students are led through all aspects of the PCI DSS -- the rationale for its various regulations and how to comply with each individual requirement of the Standard.
  • PCI code reviews -- Students are taught how to carry out code reviews in payment applications, enabling them to spot PCI DSS violations.
  • PCI hardware review -- Students become familiar with the kinds of hardware and systems currently used in the industry, and the ways these devices perform essential verification and payment functions.   
  • PCI reports -- Students learn how to fill out and submit compliance reports in the aftermath of a completed assessment, as well as how to inform organizations of the results of a PA-QSA investigation.  


What Is a PA-QSA?

The Payment Card Industry Security Standards Council (PCI SSC) has devised a variety of professional certifications designed to highlight organizations and individuals capable of adequately assessing specific aspects of a payment processing environment. One of these certifications is Payment Application Qualified Security Assessor (PA-QSA). While a Qualified Security Assessor (QSA) is responsible for onsite inspections of a payment processing system, a PA-QSA is permitted to perform comparable assessments of payment applications, checking to ensure that these products are PCI compliant.  For software vendors that develop distributed software applications that handle cardholder data, a PA-QSA can provide invaluable aid in preparing an application for the marketplace.

The PCI SSC currently offers a rigorous training course for those organizations that wish to certify employees as PA-QSAs. To enroll for the course, the company that wishes to have its employees trained in the program first has to fill out and submit an application to the PCI SSC. The application should include all relevant certifications, business licenses, and insurance certificates, as well as a registration fee that will be credited against the enrollment fee. After this, the company employees will go through a course that covers the PCI DSS and proper assessment techniques. Upon successful completion of the course, the PCI SSC will issue certificates to the attendees; the individual employees will each get a Certificate of Qualification, while the company itself receives a Letter of Acceptance. The company and its qualified employees will then be listed on the Council's website of validated PA-QSAs, and they can begin offering professional assessment services to software vendors. 


Scope of a PA-DSS review

Because a distributed software application that handles cardholder data must comply with the Payment Application Data Security Standard (PA-DSS), it is important for software vendors to arrange to have their products properly inspected before releasing them to  customers. Fortunately, there are many Payment Application Qualified Security Assessor (PA-QSA) companies out there that have been certified by the  Payment Card Industry Security Standards Council (PCI SSC) to perform these inspections. It may be useful to know what a PA-QSA looks for when carrying out one of these reviews. According to the PCI SSC, a PA-DSS review should cover the following aspects of a product: 

  • The Assessor must ensure that the customer is given reasonable guidance on how to implement the product in a PCI compliant manner, as well as how to avoid settings and environments that may compromise the customer's ability to do this. In some cases, the vendor is required to provide guidance on PCI compliance, even in specific settings that the vendor cannot control. 
  • The PA-QSA will review all payment application functions, such as encryption, cardholder data flows, authentication mechanisms, connections to other files, authorization and settlement functions, and more.
  • During the PA-DSS review all specified platforms in which the application can be utilized will be examined. 
  • All payment application tools that can be utilized to access sensitive cardholder data will also be reviewed by the PA-QSA.
After passing a review, the product may be listed by the PCI SSC as an approved application. 


What Is a PA-DSS Implementation Guide?

ISVs must guarantee that if their distributed software application handles cardholder data, they are PCI compliant -- that is, these applications must conform to the Payment Application Data Security Standard (PA-DSS). This should be no surprise to anyone in the industry, as it is widely understood that all aspects of a payment processing environment must be compliant. ISVs are required to do more than simply develop a product; they must also do their part to ensure that their applications are implemented in a manner that adheres to PCI compliance requirements.  For this reason, software vendors, in scope of PA-DSS are charged with the responsibility of assembling a PA-DSS Implementation Guide to be included with the application itself.

To be compliant with  the PA-DSS, the content of the Guide must contain certain elements, including the following:  

  • Guidance to customers on implementing the application in a secure, PCI  compliant fashion 
  • Guidance to customers on configuring the application correctly 
  • A clear explanation of the respective responsibilities of the vendor, the reseller, and the customer as these relate to the handling and use of the application in a PCI compliant manner 
  • A clear explanation of the proper way to enable any relevant security settings
The PA-DSS Implementation Guide is intended to help the customer maintain a PCI  compliant payment processing environment. For customers, it simply isn't enough to purchase the right kind of software and equipment; these must be set up and utilized in the correct fashion.


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. 

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