This piece is a result of an article I read in blogosphere somewhere today. It was something about Visa giving a great thrust to Software security through the PA-DSS program. Visa has indicated that Visa acquirers in all regions of the world must ensure that the merchants they newly sign must use PA-DSS Compliant Applications in their environments by the July 2010 and existing merchants should be transitioned to PA-DSS compliant Applications by the July 2012. I would see that as a welcome step in software/application security, and something that will be helpful to a huge extent in the application security quest. This is why:
What is the PA-DSS?
The PA-DSS is not as famous as its mother standard, which we all lovingly know as the PCI-DSS also known simply, as PCI. The PA-DSS is the Payment Application Data Security Standard. It is meant for commercial applications which come in contact with cardholder information either during the authorization or settlement function of the card payment transaction. PA-DSS is entirely meant for an application and consists of 14 requirements encompassing all aspects of security which a payment application will have to adhere to. This includes secure storage of cardholder information, logging, authentication&authorization, secure development and deployment, etc. The PA-DSS is a sub-set of the PCI-DSS, with the core focus on the application as opposed to the cardholder data environment in PCI-DSS. This is better explained with an example. For instance, a application developer "A" has developed an E-Commerce application which is to be sold to several merchants. Merchants all over the world are either thinking about, undergoing or have undergone PCI Compliance. If 'A' has to support his prospective customer's PCI Compliance effort, then it imperative that the application be validated as per the PA-DSS requirements. The PA-DSS is a certification for the application and not for the environment. So, if 'A' gets his application validated PA-DSS, then the application is readily designed to support the PCI requirements and merchant's PCI compliance effort wouldn't be hindered. The PA-DSS has been designed to ensure that the payment applications deployed in PCI environment must support PCI compliance, which is why the PA-DSS has come to be.
Why PA-DSS?
One of the greatest impediments for security are the applications. I have seen several environments, where the entire process of security compliance or practices comes to grinding halt because of applications being unsupportive of security requirements. Applications are the lifeblood of any entity in business today. An e-commerce merchant cannot do business without the e-commerce application and its related components. A payment processor will find it impossible to process millions of transactions a day without the financial switch and its related applications. Customers are wedded to the applications they purchase and any change is resented and sometimes not recommended as a 24x7 scenario is the need of the hour. Most of these applications fall short of basic and advanced security needs by a long shot. Several financial switch applications log the entire magnetic stripe information, including the Card number, CVV and other track elements in CLEAR TEXT, a strict no-no from the PCI standpoint as well as from a general security standpoint. Several E-commerce applications purchased and deployed by customers don't support hashing of passwords, encryption of cardholder information and not to mention web application security practices like input validation. Point of Sale applications used by merchants log the entire card number in the transaction logs and several of them dont support anything more than a 4 char password. This is a huge impediment in adhering to security requirements. Merchants and processors often struggle with security implementation because of the applications and even after the best workarounds, the risk of data being stolen, modified or destroyed still remains amply. The aim of the PA-DSS is to correct this situation by ensuring that application vendors creating commercial payment applications to be sold, must get their applications validated against the PA-DSS requirements.
Why not just PCI? Doesn't it cover Application Security?
Yes, PCI does cover application security in its requirements. In fact Requirement 6 is dedicated largely to application security practices and web application security practices, including a great deal of wisdom from the OWASP knowledge base, providing a much-needed boost to AppSec, but PCI addresses the applications which are custom developed or developed in-house. The focus of the PA-DSS is for payment applications which are to be sold, distributed or licensed to third parties. So the loop is pretty simple
if (inHouseApplication() || customCode()) {
validateAsPerPCIDSS();
} else {
validateAsPerPADSS();
}
Well, you do not. The PA-DSS is only applicable for applications which are part of the payment authorization and settlement cycle. So if you are a log management application, WAF, or any other application which is looking for a marketing boost from the PCI fever, you will not able to go the PA-DSS route as it is specifically for Payment Applications.
