PA-DSS Validation Clarification

On July 23, 2012 we received the following communication from James Barrow, Director of AQM Programs, with the PCI Security Standards Council.  I found it worthy of posting so that everyone understands the procedures their QSA needs to follow regarding applications that are supposedly PA-DSS validated.

The Council has recently received inquiries related to the Validation of Payment Applications process and there seems to be some confusion related to the PCI SSC listing of validated applications.  The Council’s website is the authoritative listing of applications that have been accepted by the Council.  This is the listing that should be checked by the assessors during each engagement with a merchant.  If the merchant’s application (both name and version number) are not on this list, it cannot be considered validated.

There are some instances where a merchant might provide you with a document (not issued by the Council) stating that the application has undergone some type of review and has been deemed compliant.  However, if the payment application is not listed on the PCI SSC website, it cannot be considered validated.  If such an instance of this arises during one of your engagements, you as the assessor must perform your due diligence in determining if the application is capable of meeting all of the DSS requirements.

For the PA-DSS community we realize that some applications are not applicable to the PA-DSS program.  The eligibility for the program is contained in the document entitled “Which Applications are Eligible for PA-DSS Validation?  A Guiding Checklist” available at the Council’s document library.  If an application is not eligible for the program, it does not preclude you from performing an assessment.  However, at the end of the assessment you cannot communicate to your client that per the assessment the application has been “validated”, nor can the client (vendor) expect the assessment to have any bearing on a merchant’s ability to achieve DSS compliance.

Following the above guidance should help to remove any miscommunication or misunderstanding in the payment ecosystem as to what applications are considered validated, and the steps that need to be taken should a non-validated application be identified in the field.

The key here is that if the version of your payment application is not on the PCI SSC’s PA-DSS list, it is not considered PA-DSS validated and your QSA must assess it accordingly.  I cannot tell you how many merchants we encounter where they have a different version of the application, yet the merchant insists that we treat it the same as the version that is PA-DSS validated.

We also run into software vendors that insist that the version the merchant is running is not significantly different from the version that is PA-DSS validated.  While this could be an accurate statement, the vendor needs to have submitted the version to a PA-QSA for validation of that fact.  The PA-DSS has a procedure that the PA-QSA can follow to determine that version changes have not affected cardholder data processing and the application’s PA-DSS validation.  Without that validation, as a QSA, our hands are tied and we must conduct a full assessment of the application under the PCI DSS.

Much to the chagrin of a lot of merchants, a PA-DSS validation does not imply that they are PCI DSS compliant.  There is also this mistaken belief by merchants that a PA-DSS validation implies that the QSA does not have to assess the application.  Under the PCI DSS, a QSA still must assess the application’s implementation and ensure that it was implemented per the vendor’s instructions to maintain its PA-DSS validation.  The trouble is that this implementation assessment may not save much, if any, time for the QSA.

Advertisement

Security Awareness Training

With the growth in social engineering used to breach organizations, there has been a growing chorus of security professionals that are pushing for more and better security awareness programs.  However, Dave Aitel of Immunity, Inc. recently published an article that basically states that employee security awareness training is worthless and should not be done.  While I understand Mr. Aitel’s frustration with employees’ being a security issue, to stop security awareness training is extremely foolish.

“The clients we typically consult with are large enterprises in financial services or manufacturing.  All of them have sophisticated employee awareness and security training programs in place – and yet even with these programs, they still have an average click-through rate on client-side attacks of at least 5 to 10 percent.”

As someone in a consulting firm that also does social engineering assessments, I can confirm Mr. Aitel’s observation of 5 to 10 percent.  However, I can also tell you that organizations we test that do not have a security awareness program or have limited security awareness training are averaging in the 20 to 30 percent failure rate.  Based on our work in social engineering and discussions with other professionals that do social engineering, the 5 to 10 percent click through rate is unfortunately about the best you will get out of people.  People are fallible, some more than others.  So to just drop security awareness training is not a good idea unless you think doubling or tripling your risk is a good idea.

“Because they’re going to do so anyway, so you might as well plan for it.”

This statement is why Forrester recommends the “Zero Trust” security approach and why I developed the Ultra Secure Network.  But while I whole heartedly agree with Mr. Aitel’s statement, I differ with Mr. Aitel on what that statement means.

Mr. Aitel implies that by improving all of your other security measures you can eliminate the potential that employees will screw up.  Mr. Aitel naively believes that by auditing your periphery, improving monitoring, isolating and protecting critical data, segmenting your network, auditing employee access, improving incident response and instituting strong security leadership, organizations can prevent network threats and limit their potential range.  As I always like to say, “In theory, theory works.”

Yes, there is no doubt that organizations need to improve their security posture.  But Mr. Aitel seems to forget that employees are part and parcel of that security posture.  Ultimately, employees, as well as contractors, business partners and others, need to interact with an organization’s information.  Even if you significantly improve all of your other security controls, people still need to access and interact with an organization’s information assets.  The bad news for Mr. Aitel is that people are fallible.  To ignore that fact is foolish and to bury your head in the sand in the belief that you can prevent every social engineering attack with your other controls is sheer folly.

Security awareness training has its place, but it is not a silver bullet nor is any other security control or approach.  The world is full of risks and a security professional’s job is to minimize those risks and manage the remaining residual risk.  Any security professional that believes they can eliminate risk and sells management on that fact is not going to have a career for very long.

The ugly fact of life is that every security control only minimizes security risk and sometimes you get very lucky and the risk is minimized to zero.  In the vast majority of cases there is some amount of residual risk even when a security control is in place.  If your organization is unwilling to accept the remaining residual risk, then the business function causing that risk needs to be not performed.  As I like to tell people that complain about the PCI DSS, “If you don’t want to comply with the PCI DSS and want to totally avoid a card breach, then don’t accept credit/debit cards for payment.”

So continue to conduct security awareness training, but do not mistakenly believe that it will stop people from creating an incident.  Security awareness training only minimizes the risk that people will make a mistake, not eliminate that risk.  This is why security is done in layers, so that when people make that mistake, your other security controls catch the mistake quickly and minimize the impact.

Unintended Consequences

Why reinvent the wheel?  This is from the June 2012 Assessor Update published by the PCI SSC.  It provides advice for those situations when people are foolish and transmit their cardholder data to your organization in ways you would prefer they do not use.  While focused on the merchant, these recommendations can be followed by all organizations that need to be PCI compliant.

What should a merchant do if cardholder data is accidentally received via an unintended channel?

Merchants sometimes find themselves in a situation where a customer provides their cardholder data unsolicited via an insecure communication channel that was not intended for the purpose of capturing sensitive data.

In this situation, the merchant can choose to either include the channel into the scope of their cardholder data environment (CDE) and secure it according to PCI DSS, or implement measures to prevent the channel from being used for cardholder data.

Some suggestions for merchants to prevent any further capture of cardholder data via unsecured methods include:

• Implementing controls to prevent acceptance of cardholder data via unsecured channels
• Responding to customers in a manner which does not propagate any further unsecured transmissions of cardholder data
• Implementing best practices and customer communications to proactively prevent customer use of unsecured channels for cardholder data

Cardholder data received via an unintended channel should be either immediately removed or secured according to PCI DSS and incorporated into the merchant’s CDE. If a merchant does not wish to bring a communication channel and its supporting systems into the scope of their CDE, controls should be in place to prevent the capture of cardholder data and/or to securely delete cardholder data from this channel before the data can be further stored, processed or transmitted.

If unsolicited cardholder data is received via an insecure method, the merchant should take immediate steps to minimize the security impact and prevent further exposure of that data. For example, if a merchant receives cardholder data in an email from a customer, the merchant’s personnel should be trained to not ‘reply’ using the same email that contains the cardholder data.
Instead, the merchant’s personnel should respond in a manner that does not further propagate the unsecured transmission of cardholder data.  This may be accomplished by removing all sensitive data from the email response before replying or by contacting the customer via an alternative communication channel to complete the transaction.

Merchants are encouraged to communicate with their customers on the risks of sending cardholder data through insecure channels, and to ensure their customers are aware of the merchant’s secure methods for submitting payment information. By proactively encouraging their customers to use only secure payment methods, merchants can reduce the amount of cardholder data received via unsolicited or insecure channels.