PCI DSS Compliance Blog

Many Payment Applications Will Lose Validation in October 2013

It’s a date that will probably not live in infamy, but it represents a deadline that may cause trouble for many payment application vendors.  Software applications that were validated under PA-DSS v. 1.2 are set to expire on October 28, 2013.   What does this mean for software vendors and their customers?

Software vendors, with upcoming expiration validation dates, will need to have their applications reevaluated under PA-DSS v. 2.0 in order to continue to sell their solution to new customers.  As per the PCI SSC, it is acceptable for existing customers to continue to use software that was validated under PA-DSS v. 1.2.

Software vendors and merchants should check their software against the PCI SSC’s list of Validated Payment Applications.  Some products have already been revalidated, but merchants must be wary if they use applications that are set to lose validation on October 28, 2013.  They may wish to contact the vendor to see if revalidation is in the future—if it isn’t, it’s probably wise for merchants to upgrade their applications to one validated to comply with PA-DSS v. 2.0.  Software vendors with expiring PA-DSS validations may consider  implementing alternative solutions that completely remove their applications from PCI Compliance scope, such as point-to-point encryption or Hosted Payments, rather than undergoing revalidation.

How Is a Device’s Attack Potential Calculated?

“Attack potential” is a term that appears often in the documentation published by the PCI Security Standards Council (PCI SSC).  It is a numeric value that refers to the security vulnerability of a given piece of equipment.    The higher the number, the more secure the device.   This score is calculated by considering a handful of factors relating to the device:

• Attack time – This is the amount of time necessary to identify or exploit a vulnerability.
• Expertise – The skill level required to carry out a successful attack.  Three categories are recognized (in ascending order):  Laymen, Proficient, and Expert.
• Knowledge of the device – The type of knowledge pertaining to the specific device that is required to execute a successful attack.  This is classified in one of three categories:  Public (accessible to everyone), Restricted (accessible upon request or in official documentation), and Sensitive (hard-to-obtain “secret” information).
• Access to the device – The kinds of equipment that can be obtained to identify or exploit a device’s vulnerability.  There are three categories:  mechanical samples, functional samples without working keys, and functional samples with working keys.
• Equipment – The type of equipment necessary to identify or exploit a vulnerability.  These are categorized as follows (in ascending order):  Standard, Specialized, Bespoke, and Chip-level. 
• Parts – The type of parts that must be used to hide an attack or replace material damaged in an attack (in ascending order):  Standard, Specialized, or Bespoke.

Data Breach Strikes Arizona Grocery Store Chain

Another high-profile data breach has made the news.  This time the target was the Arizona-based grocery store chain Bashas', which has reported that cybercriminals stole sensitive customer data in an attack on the company’s databases that, although only recently discovered, apparently originated in mid-2012.  As a result of this breach, payment cards associated with hundreds of Bashas’ customers have been used illegally in several states and even overseas—and the list of victims could easily expand in the future.

Patrons of the Bashas' family of stores, a chain of over 130 establishments that include Food City and AJ’s Fine Foods, are being urged to monitor their debit and credit accounts for fraudulent activity.   An official statement from Bashas’ reveals that its databases were compromised by a “highly sophisticated piece of malware that has never been seen before in the industry.”  This episode underscores the need for retailers to ensure that their data security measures can keep pace with the ever-increasing resourcefulness of hackers.  As criminals become more sophisticated, so too must the tools that are utilized to combat them.  For that reason, Element Payment Services remains committed to supplying our merchant clients with up-to-date PCI-compliant payment processing solutions.

Responsibilities of a PA-QSA

A Qualified Security Assessor (QSA) performs on-site inspections for companies that wish to ensure compliance with the PCI Data Security Standard (PCI DSS).  A Payment Application Qualified Security Assessor (PA-QSA) carries out a related function; this is a QSA that has received additional training to perform inspections of point-of-sale (POS) equipment and similar payment applications.  It’s worth pointing out that a PA-QSA must possess QSA certification as a prerequisite, but not every QSA will hold PA-QSA certification.  To maintain their certification, a PA-QSA must fulfill the following responsibilities:

• Perform payment application inspections in a manner compliant with the PA-DSS Security Assessment Procedures and the PA-QSA Validation Requirements.
• Advise whether a particular application follows PA-DSS specifications.
• Complete the Report on Validation correctly.
• Send the Report on Validation, Attestation of Validation, and the application’s PA-DSS Implementation Guide to the PCI Security Standards Council.
• Maintain proper quality assurance controls as a PA-QSA.
• Keep track of current PCI SSC regulations and payment card industry practices.
• Comply with ongoing recertification requirements, including any and all tests and training programs.

A list of PA-QSA companies can be found on the PCI SSC’s official website.

PCI SSC Participation Activities for 2013

Merchants and software providers across the land have had good reason to become well acquainted with the PCI Data Security Standard (PCI DSS).,The organization in charge also promotes a host of formal events throughout the year that relate to payment processing.  Recently the PCI Security Standards Council (PCI SSC) announced several 2013 participation opportunities intended for the payment card community.

• 2013-2015 PCI Board of Advisors Nominations

The PCI SSC has already kicked off the nomination process for the 2013-2015 PCI Board of Directors.  This 21-person board will be responsible for advising the PCI SSC leadership in the coming years.  The nomination period will last through February 25, voting will occur from March 7-April 5, and in May the board will begin serving its two-year term.  Participating Organizations are invited to nominate a representative from their company.

• 2013 Annual PCI Community Meetings

The PCI SSC will hold three Community Meetings in 2013.  These meetings draw payment card professionals from around the globe to share knowledge and discuss ongoing developments in the industry.

1. North America
   September 24-26, 2013
   Mandalay Bay Convention Center
   Las Vegas, NV, USA
2. Europe
   October 29-31, 2013
   Nice Acropolis
   Nice, France
3. Asia-Pacific
   November 20, 2013
   Kuala Lumpur, Malaysia
   
   

• 2013 PCI Special Interest Groups

PCI Special Interest Groups (SIGs) have already begun meeting to discuss the topics of “Third Party Security Assurance” and “Best Practices for Maintaining PCI DSS Compliance.”

How the PCI SSC Compiles Its List of Validated Payment Applications

Today, the vast majority of merchants operate payment card acceptance technology for the convenience of their customers.  It goes without saying that this technology must perform at an adequate level, as well as comply with the PCI Data Security Standard (PCI DSS).  But how can a merchant be sure that their payment applications meet these requirements?  The PCI Security Standards Council (PCI SSC) maintains a list of Validated Payment Applications; this includes various POS devices/applications, online shopping carts, middleware, and related items that meet the Council’s specifications.  To become included on this list, a payment application must go through the following process:

• A PA-QSA (Payment Application Qualified Security Assessor) must inspect the application to ensure that it falls within the specifications of the PA-DSS.
• The PCI SSC must receive the Report on Validation from the PA-QSA responsible for inspecting the application; the Council examines the report to ensure that all guidelines and reporting procedures have been followed properly.
• The Council must receive the PA-DSS Payment Application Acceptance Fee and all relevant documentation.

The payment application is then posted on the publicly accessible list found on the PCI SSC website.

What Is SRED Compliance?

Those of you who have searched through the extensive documentation available on PCI regulations may have stumbled onto guidelines relating to “SRED compliance.”  What might this be?  SRED is an acronym for Secure Reading and Exchange of Data, and it refers to the Point of Interaction (POI) security standard as outlined in the PIN Transaction Security (PTS) requirements, version 3.1.  

The POI is the initial point where credit cardholder data is captured. The SRED module of the PTS protocols lists a variety of requirements to ensure that all POI devices used to process payment cards conform to an acceptable level of security. 

For example, these devices must encrypt account numbers immediately upon entry or provide a sufficiently secure plain-text environment.  This guarantees that all cardholder data is well protected at the POI.  It must be noted, however, that a SRED-compliant device does not in itself provide an overall,comprehensive point-to-point encryption (P2PE) solution, but, it must function adequately as the initial point of any such solution.  

SRED Requirements for Point-of-Interaction Devices

The PCI Security Standards Council (PCI SSC) has set down guidelines governing virtually every aspect of payment card processing; among these requirements is the SRED (Secure Reading and Exchange of Data) module of the PIN Transaction Security (PTS) document.  These requirements are too numerous to discuss in full here, but below we’ll list some of them to provide a brief overview:

• The device must be adequately protected against attempts to reveal its cryptographic keys used for data encryption.
• Data must be encrypted with ANSI X9 or ISO-approved encryption algorithms.
• The device allows for data origin authentication.
• The device’s secret and private keys are unique.
• All administrative remote access attempts must be authenticated cryptographically.
• All firmware updates must be authenticated cryptographically.
• The device should not retain sensitive data longer than necessary for business purposes.

In brief, the SRED module dictates security parameters for point-of-interaction (POI) devices used to process customer payment card data.  

Dealing with Legacy Cardholder Data

While striving to upgrade their payment processing systems, some merchants forget about the threats posed by legacy data.  This refers to old sensitive data—often for recurring billing or customer loyalty programs—that many businesses tend to leave on unsecured devices, such as personal laptops, or even printed on paper copies.  Because this old data tends to be stored in an unsecure manner, it can be exposed to unauthorized persons—and cause a host of problems.  For this reason, the PCI Data Security Standard (PCI DSS) requires that merchants purge their systems of sensitive data that isn’t necessary for business functions. 

 You should do a thorough search to ensure that this old data is either deleted or properly stored.  Remember that stored primary account numbers (PANs) must be encrypted, truncated, or otherwise rendered unreadable; under no circumstances should merchants retain, full card numbers, PINs or card verification data.  

Element Payment Services is committed to helping merchants reach full PCI compliance, we’ve developed an assortment of products and services to enable them to secure their data according to the most up-to-date industry standards.  With a little foresight and research, it’s not difficult to secure cardholder information in an effective manner. 

Using Epoxy to Secure a POI (Point-of-Interaction) Device

The recent PIN pad hacking controversy that befell book vendor Barnes & Noble has exposed the vulnerability of these devices.  In this particular case, thieves manually tampered with dozens of B&N in-store PIN pads, which allowed the perpetrators to steal payment card data.  This serves as yet another reminder that it’s essential to maintain the physical security of payment processing devices. Firewalls and anti-virus programs can’t block a sneaky criminal from tinkering with a POI (point-of-interaction) device when no one’s looking.  To aid companies in their endeavors to secure these types of units, the PCI SSC has released guidelines regulating the types of epoxy that may be used to seal a POI device.  Any epoxy used for this purpose must demonstrate these characteristics:

1. Opaqueness – The epoxy must be opaque—that is, it obstructs light and cannot be seen through.
2. Hardness – The epoxy must be hard enough to resist a sharp object.
3. Tamper Evidence – The epoxy must show evidence of attempted tampering if a sharp object is used to penetrate it.
4. Adhesion – The epoxy must be strong enough to resist attempts to open the device, so that doing so would result in damage extensive enough to render the equipment inoperable.