Requirement 5: Develop secure payment applications

Details about how requirement 5 and subrequirements 5.1, 5.2, 5.3, 5.4, 5.5, and 5.6 are fulfilled.

Requirement 5.1

The software vendor has defined and implemented a formal process for secure development of payment applications, which includes:

Payment applications are developed in accordance with PCI DSS and PA-DSS (for example, secure authentication and logging).
Development processes are based on industry standards and/or best practices.
Information security is incorporated throughout the software development life cycle.
Security reviews are performed prior to release of an application or application update.

IBM® Safer Payments meets this requirement. The internal software development guidelines of IBM Safer Payments reflect on PCI DSS and PA-DSS requirements. A regular IT security training program is established. It is mandatory for the developers of IBM Safer Payments to follow the OWASP guidelines for secure software development and operations.

5.1.1 Live PANs are not used for testing or development.

IBM Safer Payments meets this requirement. IBM Safer Payments uses artificially generated data for testing, or data that is anonymized using a secure hashing method, such as SHA256 with salt.

5.1.2 Test data and accounts are removed before release to customer.

IBM Safer Payments meets this requirement. Test data and accounts are only added to the software in the test harnesses, never to the installation media. Thus test data and accounts can never find their way to the delivered installation archives.

5.1.3 Custom payment application accounts, user IDs, and passwords are removed before payment applications are released to customers

5.1.4. Payment application code is reviewed prior to release to customers after any significant change, to identify any potential coding vulnerability.

Code changes are reviewed by individuals other than the originating code author, and by individuals who are knowledgeable in code-review techniques and secure coding practices.
Code reviews ensure code is developed according to secure coding guidelines. (See PA-DSS Requirement 5.2.)
Appropriate corrections are implemented prior to release.
Code-review results are reviewed and approved by management prior to release.
Documented code-review results include management approval, code author, and code reviewer, and what corrections were implemented prior to release.

IBM Safer Payments uses a revision policy, in which feature development occurs only in the development branch, and never in the release branches. Code changes to release branches are committed individually by issue ticket of the issue tracking system to the source code revision control system. Development managers can review them individually before they are committed to a new branch release (patch release).

5.1.5 Secure source-control practices are implemented to verify integrity of source code during the development process.

IBM Safer Payments uses Git as a source code management system. In our intranet, we maintain a section that provides information on how to use it and how it is configured.

5.1.6 Payment applications are developed according to industry best practices for secure coding techniques, including:

Developing with least privilege for the application environment.
Developing with fail-safe defaults (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.

The developers of IBM Safer Payments are provided with training materials about secure coding technologies and how to use them. Each IBM Safer Payments developer must undergo secure coding training at least annually.

5.1.7 Provide up-to-date training in secure development practices for application developers at least annually, as applicable for the developer’s job function and technology used, for example:

Secure application design
Secure coding techniques to avoid common coding vulnerabilities (for example, vendor guidelines, OWASP Top 10, SANS CWE Top 25, CERT Secure Coding, etc.)
Managing sensitive data in memory
Code reviews
Security testing (for example, penetration-testing techniques)

Requirement 5.2

Develop all payment applications to prevent common coding vulnerabilities in software-development processes.

The Agile approach that is used by IBM Safer Payments development meets this requirement. In addition, mandatory code reviews by trained reviewers prevent common coding vulnerabilities.

5.2.1 Injection flaws, particularly SQL injection. Also consider OS Command Injection, LDAP and XPath injection flaws as well as other injection flaws.: SQL injection in IBM Safer Payments is impossible as there is no SQL engine in IBM Safer Payments. In general, every entry to IBM Safer Payments is read by an anticipatory parser that does not open any door for code injection.
5.2.2 Buffer Overflow: All buffers that are used for external input are protected against overflowing. All internal buffers do not provide external access and thus cannot be used to attack the software.
5.2.3 Insecure cryptographic storage: IBM Safer Payments meets this requirement. IBM Safer Payments uses industry standard AES-256 and SHA256 crypto-libraries that it keeps in source code form.
5.2.4 Insecure communications: To comply with this requirement, all sensitive and authenticated IP communication must be encrypted. This can be achieved with the internal SSL encryption functions of IBM Safer Payments. For more information, see Configuring SSL encryption.
Note: For performance reasons, the internal SSL encryption of IBM Safer Payments does not apply for all internal communication between IBM Safer Payments instances. Instead, only keys and passwords are encrypted during transmission, as well as any encrypted attribute values, including the PAN.
5.2.5 Improper error handling: Error messages do not deliver passwords or transaction data values.
5.2.6 All “High” vulnerabilities as identified in the vulnerability identification process at PA-DSS Requirement 7.1: For more information, see Requirement 7: Test payment applications to address vulnerabilities and maintain payment application updates.
5.2.7 Cross-site scripting (XSS): For injecting JS code or any other browser executable code, IBM Safer Payments provides save escaping routines, as described in the online help system of IBM Safer Payments.

Requirement 5.3

Software vendor must follow change-control procedures for all application changes. Change-control procedures must follow the same software development processes as new releases (as defined in PA-DSS Requirement 5.1), and include the following:

IBM Safer Payments uses a standard revision control system and an issue tracking system. The combination of these tools satisfies this requirement.

5.3.1 Documentation of impact

This requirement is met by SIBM Safer Payments development operational procedures in combination with the software development that are used by IBM Safer Payments.

5.3.2 Documented approval of change by appropriate authorized parties

This requirement is met by IBM Safer Payments development operational procedures in combination with the software development tools that are used by IBM Safer Payments.

More precisely, each issue that potentially causes code changes in a released branch must be described (by customer or employees) in a ticket that is entered into the issue tracking system. From there, only development managers review the tickets, and if they authorize them for a code change, they forward the ticket to the respective developer or developer team. This ensures that any code change in a released branch occurs only after it has been approved by authorized parties. The entire process is fully documented by the IBM Safer Payments issue tracking system.

5.3.3 Functionality testing to verify that the change does not adversely impact the security of the system.

This is done by using the automated factory test suite of IBM Safer Payments. The IBM Safer Payments software development handbook mandates that at least full factory tests are run on each branch release.

5.3.4 Back-out or product de-installation procedures

IBM Safer Payments enables back-out after the application of a patch in full flight. Similar to the IBM Safer Payments update process, you update one instance at a time. In a redundant (clustered) setup, the other instances assume the computation load and automatically provide the missed data to the updated instance. Back-out is the same process, only in reverse.

The key prerequisite is that you can back-out only one patch level at a time. If you want to back-out from IBM Safer Payments 5.3.1.8 to IBM Safer Payments 5.3.1.4, for instance, you first back-out one instance after another to IBM Safer Payments 5.3.1.7, then toIBM Safer Payments 5.3.1.6.

For more information, see Installing a fix pack update.

Requirement 5.4

The payment application vendor must document and follow a software-versioning methodology as part of their system development lifecycle. The methodology must follow the procedures in the PA-DSS Program Guide for changes to payment applications.

The IBM Safer Payments revision policy is documented in Versioning method.

Requirement 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.

On our intranet, a section describes the risk assessment techniques of IBM Safer Payments.

Requirement 5.6

Software vendor must implement a process to document and authorize the final release of the application and any application updates.

This requirement is met by IBM Safer Payments development operational procedures. A factory staging process mandates that every patch or upgrade release is authorized by the respective person.