One typical question NetSPI receives from IT managers is “What does PA-DSS entail?” Hopefully, this will give you some answers.

PA-DSS

PA-DSS is a set of security practices and requirements developed by the PCI Security Standards Council to “…enhance payment account data security by driving education and awareness of the PCI Security Standards.[1]” The goal of PA-DSS is to help software vendors and others develop secure payment applications that do not store prohibited data, such as full magnetic stripe, CVV2 or PIN data, and ensure their payment applications support compliance with the PCI DSS. Payment applications that are sold, distributed or licensed to third parties are subject to the PA-DSS requirements.[2] By ensuring the compliance of your application with PA-DSS requirements, your company   helps facilitate its customers’ PCI DSS compliance.

NetSPI’s Answer

NetSPI has developed a program guide to assist your company in getting payment applications validated. This guide prepares a company to get ready for the audit and allows them to better understand the requirements of the different pieces of the audit. These include the documentation requirements for the implementation guide, troubleshooting procedures, SDLC documentation including change control, vulnerability and software patching procedures and the training materials that are required.  It also goes into the topic of the interviews that will occur as well as the testing of the application. What the program guide does not do is tell the different people in the company what is expected of them before the audit, during audit and after the audit.  This validation process can be simple and easy or it can be long and tedious. Work with your auditor to get through the process, they have the experience to get you through the process.

Before the Audit

As a manager, there are processes that have to be planned for and started before the auditors come into your office to start the audit process. The application has to meet the PCI requirements, which include:

  • Do not retain full magnetic stripe, card validation code or value (CAV2, CID, CVC2, CVV2), or PIN block data
  • Protect stored cardholder data
  • Provide secure authentication features
  • Log payment application activity
  • Develop secure payment applications
  • Protect wireless transmissions
  • Test payment applications to address vulnerabilities
  • Facilitate secure network implementation
  • Cardholder data must never be stored on a server connected to the Internet
  • Facilitate secure remote software updates
  • Facilitate secure remote access to payment application
  • Encrypt sensitive traffic over public networks
  • Encrypt all non-console administrative access
  • Maintain instructional documentation and training programs for customers, resellers, and integrators

In addition to the application requirements, the documentation has to also be ready.The list of documentation includes:

  • Implementation guide – The most important document without which testing cannot start
  • Typical network deployment diagram and data flow diagram
  • SDLC documentation (coding standards, code review process, software testing procedures)
  • Development and test job descriptions
  • Change control procedures
  • Test/QA procedures
  • List of all custom application accounts (if applicable)
  • Web application testing procedures (if web-based application or web-based components)
  • Wireless configuration guidelines (if applicable)
  • Remote access documentation (if applicable)
  • Encryption methodology (key management, generation, storage, distribution)
  • Update process documentation
  • Documentation of remote transmission of cardholder data, such as IPSec, TLS, SSL
  • New security vulnerabilities identification process/policy documentation

In many instances, use of specific language within policies is required.  For example, the implementation guide requirements include required language, such as “Historical data (magnetic stripe data, card validation codes, PINs, or PIN blocks) MUST be removed for PCI compliance.” This wording is required by the PCI Council and if not included, can provide sufficient grounds for the rejection of the Report on Validation (ROV). NetSPI’s PA-DSS Program Guide has been developed expressly with intent of showing such working requirements. As shown in the list above, documentation requirements are not limited to the implementation guide and need to be completed before a ROV can be filed. It’s not enough to have processes in place, such as the security coding standards; they need to be formally documented. Make sure to review the documentation requirements to make sure they are up to date. The last but far from the least important part of the pre-audit process is to educate your employees on the PCI Council’s requirements for a payment application. They need to know that these requirements are not an optional part of the application and that they may be interviewed during the course of the audit. All team members should be familiar with established standards such as the SDLC documentation as well as be aware of the troubleshooting requirements as described in the process documentation.

Next Steps

The next blog entry will talk about what to expect during and after the audit.


[1] https://www.pcisecuritystandards.org/index.shtml [2] https://www.pcisecuritystandards.org/security_standards/pa_dss.shtml