Are you ready for PA-DSS 3.0?

January 20, 2014, Dan Fritsche, Practice Director, Coalfire Labs

There’s been a lot of chatter about PA-DSS 3.0 among several early-adopter application vendors. As of January 1, 2014 it’s permissible to validate against 3.0 in place of a 2.0 validation. Longevity of the 3.0 validation and the desire to be validated first on a new standard seem to be driving the move to 3.0. The expiration date of a 3.0 validation is October 28, 2019 vs. October 28, 2016 for a 2.0 validation.

However, you should pause and ask yourself if you’re ready for a 3.0 validation. It’s important to note that the PCI Council made several significant changes and additions to PA-DSS 3.0 that are necessary to meet ongoing risk management activities and evolving security best practices.

A document titled “PA-DSS Summary of Changes V2.0 to V3.0” , on the PCI SSC web site, contains valuable information for application vendors regarding the changes of the standard.  For your convenience, here are the highlights of the impactful changes and additions to PA-DSS 3.0.

Changes to PA-DSS 3.0

Changes to existing requirements that could potentially impact your PA-DSS validation include:

  • Requirement 2.1: Clarification to include secure deletion of cardholder data stored by the application, including data stored on underlying software or systems (such as OS, databases, etc.).

  • Requirement 2.2.a: Clarification to include details of all instances where PAN is displayed and confirmation that the payment application masks PAN by default on all displays.

  • Requirement 2.2.c:  Instructions on how to configure the payment application so that only personnel with legitimate business need can see full PAN must be documented in the Implementation Guide.

  • Requirement 2.3:  Instructions on how to configure each method for all locations where PAN is stored must be documented in the Implementation Guide as a list of all output mechanisms for PAN and instructions to merchants that they are responsible for protection and secure deletion of PAN. 

  • Requirement 3.3.2: Significant change that passwords be secured by strong, one-way cryptographic algorithm with a unique input variable that is concatenated with the password prior to the application of the cryptographic algorithm. Storage of passwords using encryption is no longer acceptable in PA-DSS 3.0; all passwords must be salted and hashed using strong cryptographic methods.

  • Requirement 4.2.5: Clarification to logging requirement for Identification and Authentication Mechanisms should include creation of new accounts, elevation of privileges, and all changes, additions, deletions to application accounts with administrative privileges

  • Requirement 5.1: Clarification that your SDLC should include security reviews conducted prior to the release of an application or application update.

  • Requirement 5.1.7: Clarification that training provided to application developers include: Secure Application Design; Secure Coding techniques; managing sensitive data in memory; code reviews; security testing; and risk assessment techniques. In addition, records must be maintained for developer training as they will be reviewed as part of your application assessment.
    We recommend that you partner with a third party to address these training areas. Coalfire’s Secure Development Training is a program you can leverage to meet your training needs in these areas.

  • Requirement 7.1: Clarification that resources that are monitored for vulnerabilities are “reputable”.

New Requirements for PA-DSS 3.0

Highlights of the new requirements that could potentially impact your PA-DSS validation include:

  • Requirement 3.4.x: New requirement for applications to limit access to required functions/resources and enforce least privilege for built-in application accounts.

  • Requirement 5.1.5: New requirement for payment application developers to verify integrity of source code during the development process.

  • Requirement 5.1.6: New requirement for payment applications to be developed according to industry best practices for secure coding techniques, including:

    • Developing with least privilege for the environment.

    • Developing with fail-safe defaults—i.e., all execution is by default denied unless specified within initial design.

    • Developing for all access-point considerations, including input variances such as multi-channel input to the application.

    • Documentation of how PAN and/or SAD are handled in memory.

  • Requirement 5.2.10: New requirement to address “Broken authentication and session management.”

  • Requirement 5.4: New requirements for the payment application vendor to define and implement a versioning methodology in accordance with PA-DSS Program Guide.   A.K.A WILDCARDS!!           

  • Requirement 5.5: New requirement for payment application vendors to incorporate risk assessment techniques into their software development process.

  • Requirement 5.6: New requirement for payment application vendors to implement a formal authorization process prior to final release.

  • Requirement 7.3: New requirement for the application vendor to provide release notes for all application updates.

  • Requirement 10.2.2: New requirement for vendors who provide support/maintenance services to customers to maintain unique authentication credentials for each customer.

  • Requirement 14.1 - New requirement for providing information security and PA-DSS training for vendor personnel with PA-DSS responsibility at least annually.

  • Requirement 14.2 - New requirement for assignment of PA-DSS responsibilities to vendor personnel.

Clients often ask us if they should seek a 3.0 validation or continue with a 2.0 validation. For 2014 you can do either because it’s an overlap year. We recommend that you review the changes and additions to the PA-DSS 3.0 standard, “pre-assess” your application and development environment, and then make a decision based on whether or not you can complete the validation.

Best practices include a readiness program and pre-assessment activities that are tailored to your application with a PA-DSS 3.0 gap analysis. This includes evaluating your application in light of PA-DSS 3.0 changes and then providing a list of areas (broken into three categories: documentation, operational, and technical changes) that need improvement with best-practice guidance on how to meet the intent of each of the requirements. Coalfire is here to help.

Dan Fritsche

Author

Dan Fritsche — Practice Director, Coalfire Labs

Recent Posts

Post Topics

Archives

Tags