PA-DSS 3.0 – What to Expect

The PCI Council has just released PA-DSS version 3.0. They have added new requirements, removed one, and changed a few. How this affects your application really depends on how you implemented security.

What’s Been Added

Req. 3.4 Payment application must limit access to required functions/resources and enforce least privilege for built-in accounts:

• By default, all application/service accounts have access to only those functions/resources specifically needed for purpose of the application/service account.
• By default, all application/service accounts have minimum level of privilege assigned for each function/resource as needed for the application/service account.

Your application setup needs to make sure that it is using or setting the privileges needed to do the work and not grant excessive permissions. This is intended for built-in accounts as well as service accounts.

Make sure you have documented the permissions needed by any default or service accounts. The auditor will need to verify documentation against what was implemented.

Req. 5.1.5 –Payment application developers to verify integrity of source code during the development process

You need to make sure that any source control tools (i.e. Visual SourceSafe, etc.) is configured so that only the people that do development can make changes to the code. This does not preclude giving other users read access, but you need to minimize who has write access.

Req. 5.1.6 – Payment applications to be developed according to industry best practices for secure coding techniques.

You must develop the application with least privilege to ensure insecure assumptions are not introduced into the application. To prevent an attacker from obtaining sensitive information about an application failure including fail-safe defaults that could then be used to create subsequent attacks. You must also ensure that security is applied to all accesses and inputs into the application to avoid an input channel being left open to compromise.

This includes how the sensitive data and the PAN is handled in memory, the PCI Council it trying to prevent capture of this data by screen scrapping. Try to encrypt this data in memory and keep it there only for a short period of time.

Req. 5.2.10 – Broken authentication and session management

You need to make sure, in your web application, that:

• Any session cookies are marked as secure.
• The session is never to be passed on the URL. This would allow them to be logged in the web server.
• The web application must time out the session after a certain number of minutes. Once timed out, the user must re-authenticate to get access to the application.
• The session id must change when there is a change in permissions. For example, a session id is set when an anonymous user accesses the login page and after successful authentication, the session id must change to a different value.
• If a user logs out of the application, you need to delete the session on both the client and the server.

Req. 5.4 – Payment application vendors to incorporate versioning methodology for each payment application.

This is not a change in the way you write your code but a process change and, like so many other requirements, has to be documented both internally and in the Implementation Guide. Many companies already do this but make sure you have a defined method of changing the version numbers.

• Details of how the elements of the version-numbering scheme are in accordance with requirements specified in the PA-DSS Program Guide.
• The format of the version-numbering scheme is specified and includes details of number of elements, separators, character set, etc. (e.g., 1.1.1.N, consisting of alphabetic, numeric, and/or alphanumeric characters).
• A definition of what each element represents in the version-numbering scheme (e.g., type of change, major, minor, or maintenance release, wildcard, etc.)
• Definition of elements that indicate use of wildcards (if used). For example, a version number of 1.1.x would cover specific versions 1.1.2 and 1.1.3, etc.
• If an internal version mapping to published versioning scheme is used, the versioning methodology must include mapping of internal versions to the external versions
• You must have a process in place to review application updates for conformity with the versioning methodology prior to release.

Req. 5.5 – Risk assessment techniques (for example, application threat modeling) are used to identify potential application security design flaws and vulnerabilities during the software-development process. Risk assessment processes include the following:

• Coverage of all functions of the payment application, including but not limited to, security-impacting features and features that cross trust-boundaries.
• Assessment of application decision points, process flows, data flows, data storage, and trust boundaries.
• Identification of all areas within the payment application that interact with PAN and/or SAD or the cardholder data environment (CDE), as well as any process-oriented outcomes that could lead to the exposure of cardholder data.
• A list of potential threats and vulnerabilities resulting from cardholder data flow analyses and assign risk ratings (for example, high, medium, or low priority) to each.
• Implementation of appropriate corrections and countermeasures during the development process.
• Documentation of risk assessment results for management review and approval.

What the PCI Council wants is to make sure that risks in your application are assessed appropriately and that the process covers all aspects of your application including any third party tools (DLLs, etc.).

You will need to document the threat modeling you have done against your application. If you have never done one or are unsure how to do it, Microsoft has a good process and provides a free tool. The out this page for more information: https://msdn.microsoft.com/en-us/library/ff648644.aspx

Req. 5.6 Software vendor must implement a process to document and authorize the final release of the application and any application updates. Documentation includes:

• Signature by an authorized party to formally approve release of the application or application update
• Confirmation that secure development processes were followed by the vendor.

Make sure to record the approval of the release of the software and patches. This is to confirm that your secure development processes were followed.

Req. 7.3 – Include release notes for all application updates, including details and impact of the update, and how the version number was changed to reflect the application update.

Make sure you are publishing your release notes and that they include the customer impact.

Req. 10.2.2 – If vendors or integrators/resellers can access customers’ payment applications remotely, a unique authentication credential (such as a password/phrase) must be used for each customer environment.

This one is simple enough; your support people cannot use the same password to access different customers. Avoid the use of repeatable formulas to generate passwords that are easily guessed. These credentials become known over time and can be used by unauthorized individuals to compromise the vendor’s customers.

Req. 13.1.1 – Provides relevant information specific to the application for customers, resellers, and integrators to use.

The Implementation Guide must state the name and version for the software it is intended for. It must also include the application dependencies (i.e. SLQ Server, PCCharge, etc.)

Req. 14.1 – Provide information security and PA-DSS training for vendor personnel with PA-DSS responsibility at least annually

These training materials are for your personnel involved in the development and support of your application. The materials must be about PA-DSS and information security.

Req. 14.2 – Assign roles and responsibilities to vendor personnel including the following:

• Overall accountability for meeting all the requirements in PA-DSS
• Keeping up-to-date within any changes in the PCI SSC PA-DSS Program Guide
• Ensuring secure coding practices are followed
• Ensuring integrators/resellers receive training and supporting materials
• Ensuring all vendor personnel with PA-DSS responsibilities, including developers, receive training

You must assign one or more people to be responsible for meeting the requirement in PA-DSS. This person must keep up to date on the changes in PA-DSS as well as make sure the requirements are met.

Ensure that each person or persons’ responsibilities are documented.

What’s Been Removed

Req. 2.4 – If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed independently of native operating system access control mechanisms (for example, by not using local user account databases). Decryption keys must not be tied to user accounts.

All of the PA vendors I worked with did not do disk encryption but use file, table/column encryption. It makes sense to remove this requirement. In addition, disk encryption is only effective at preventing data loss due to physical theft, which is not a significant concern in the majority of datacenters.

What’s Been Significantly Changed

Req. 3.3.2 – Use a strong, one-way cryptographic algorithm, based on approved standards to render all payment application passwords unreadable during storage. Each password must have a unique input variable that is concatenated with the password before the cryptographic algorithm is applied.

It appears that encrypting the password is no longer acceptable. In your application, you must use a strong, one-way cryptographic algorithm (hash) as well as a salt value. Review your application storage to make sure that you are using a hashing algorithm with a salt. They do note that the salt does not have to be unpredictable or a secret.

Req. 4.2.5 – Use of, and changes to the application’s identification and authentication mechanisms (including but not limited to creation of new accounts, elevation of privileges, etc.), and all changes, additions, deletions to application accounts with root or administrative privileges.

Any changes to accounts in the application must be audited.

Steve Kerns