Most people that come to us for PA-DSS validation come in and expect to get the validation completed in 10 days flat. Preparation is key when you are looking at getting your app(s) validated. And it is wise to start early. The following are some of the thing that I have seen that have upended efforts to get applications validated.
Note: This article assumes that you know what PA-DSS is. If you are not sure, I suggest you go to the PCI Security Standards Council and check out the information. My other post “Does PA-DSS apply to you?” may also be useful.
The first thing to remember is that you are going to need documentation. And lots of it. The QSA (and the PCI-SSC) needs proof that you have secure development methodologies, sound information security practices, etc. The only way to prove this is to establish a history of your operations with documentation.
When you make a change to your application, be it functional enhancements or bug fixes, do your developers arbitrarily pull up code and make changes on the fly or do you have a standardized process of analyzing the requested change, approving it, implementing it and then testing it to make sure that everything works as it should? Do you do code reviews, do you have an information security policy, incident response plan, key management policy and procedures, etc.
Documentation that will be required can be classified into two types. Documents that define process/procedure and documents that provide evidence of process/procedures being followed. For example, there should be a document that describes how a change (network/app/etc) should happen and for every change made, there should be documentation that shows what was done specifically for that change.
From my experience, this is the biggest stumbling block for getting the validation done. This goes for PCI-DSS compliance too.
The Implementation Guide (IG) is the most important document for a PA-DSS validation. Even though this is part of the documentation, the IG deserves separate mention. The assessment procedures that the PA-QSA needs to follow to document the validation procedure contain a lot of points that refer to the IG. Again, most people that call us for validation have no clue about the IG.
The IG should contain instructions on how to set up the underlying platform, install the application, configure it, list of call locations where cardholder data is stored, how to securely delete data, etc. In addition, it should also flag settings that might result in non-compliance. For example, if only the last 4 digits of the PAN (Primary Account Number or card number) is stored in logs by default, but full number logging can be turned on for debugging purposes, that has to be flagged. It should mention that turning on full number logging can result in non-compliance with PCI-DSS requirements.
The most common misconception with the IG is that it does not need to address topics that is not applicable to a particular application. For example, if the application does not store sensitive data anywhere, it cannot just avoid mentioning securely erasing the data. It still has to say that secure erase is not applicable and why it is not applicable.
The QSA has to use the IG to start from a clean platform and install the application, run a few transactions and conduct forensic examination of the test environment to look for readable PAN and other information. So, it has to be very detailed. I would suggest reading the Assessment Procedures part of the PA-DSS Assessment Procedures document to understand what level of detail needs to be provided.
Updates and Patches
The second most common thing that trips up most payment application vendors is the updates process. The application is supposed to have an automatic process for verifying the authenticity of updates and patches that are deployed.
This means that when updates and patches are released, the application has to be able to verify that they are authentic and have not been modified maliciously. For instance, a vendor might make the application files, patches and updates available on their website and have clients download them.
Most people think that just providing a HMAC of the file is enough to meet the requirement. If someone is clever enough to replace the installation files on your web server, they will surely replace the file containing the HMAC also. The head of QA for the PA-DSS program at the Security Standards Council told me, “If a vendor cannot provide an automated way of authenticating the files, they should leave payment applications alone and write game software”.
If you have not thought about this before you start your PA-DSS validation, you are going to waste time implementing this at the last minute.
There is another post, Chain of trust for installation and update files that talks about this topic.
Processes and Procedures
One of the requirements of PA-DSS (and PCI-DSS) is that organizations and application vendors use secure application development practices and procedures. There are specific requirements that talk about verifying that the vendor is following industry standard development guidelines for their specific platform.
This is there for a reason. In all my years of performing penetration tests, I have observed that organizations with documented policies, procedures and processes have a significant advantage in terms of their security posture. Their apps have lesser number of vulnerabilities.
A standardized process means that everyone in the organization does things the same way in a tested and proven way. There is consistency in their approach. That is what the requirements are trying to encourage. A lot of times, I have seen clients that have no existing processes for development. That is fine as long as they incorporate standardized processes.
The QSA, in that case, needs to verify that the processes are going to be followed in the future, which is not a sure thing. The better way is to have them in place for the QSA to verify during the validation. It becomes a lot easier on the application vendor as well as the QSA.
PA-DSS Facilitates PCI-DSS
Clients usually point out to me that that I am asking for documents that are part of PCI-DSS validation and it is not applicable to their application since they are trying to get the app validated against PA-DSS. The purpose of PA-DSS is to end up with secure payment applications that facilitate PCI-DSS compliance.
If the application vendor sells an application to one of their clients, and the application stores unencrypted PAN, that is in violation of the clients PCI-DSS requirements and will have consequences for the client. PA and PCI DSS cannot be looked at separately.
Patience is a Virtue
A lot of prospects call me and say that they would like their validation done in 10 days or 15 days. Or they ask me “How long will this take if we started tomorrow?”. It is a difficult thing to say at the outset. It all depends on what documentation you have and processes you have. These are the time killers. If you noticed, I have not spent any time talking about testing the application or writing up the RoV. The effort required for these activities are nothing compared to the documentation and the processes.
You have to be patient and meet all the requirements before your application can be validated.