6: Develop and Maintain Secure Systems and Software

Requirement 6.2.1

• Based on industry standards and/or best practices for secure development.
• In accordance with PCI DSS (for example, secure authentication and logging).
• Incorporating consideration of information security issues during each stage of the software development lifecycle.

IBM® Safer Payments meets this requirement. The internal software development guidelines of IBM Safer Payments reflect PCI DSS. 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.

Requirement 6.2.2

• On software security relevant to their job function and development languages.
• Including secure software design and secure coding techniques.
• Including, if security testing tools are used, how to use the tools for detecting vulnerabilities in software.

IBM Safer Payments meets this requirement. The internal software development guidelines of IBM Safer Payments reflect PCI DSS. 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.

Requirement 6.2.3

• Code reviews ensure code is developed according to secure coding guidelines.
• Code reviews look for both existing and emerging software vulnerabilities.
• Appropriate corrections are 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).

Requirement 6.2.4

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.

Injection attacks, including SQL, LDAP, XPath, or other command, parameter, object, fault, or injection-type 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.

Attacks on data and data structures, including attempts to manipulate buffers, pointers, input data, or shared data.

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.

Attacks on cryptography usage, including attempts to exploit weak, insecure, or inappropriate cryptographic implementations, algorithms, cipher suites, or modes of operation.

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.

Attacks on business logic, including attempts to abuse or bypass application features and functionalities through the manipulation of APIs, communication protocols and channels, client-side functionality, or other system/application functions and resources. This includes cross-site scripting (XSS) and cross-site request forgery (CSRF).

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.

Attacks on access control mechanisms, including attempts to bypass or abuse identification, authentication, or authorization mechanisms, or attempts to exploit weaknesses in the implementation of such mechanisms.

Error messages do not deliver passwords or transaction data values.

Attacks via any “high-risk” vulnerabilities identified in the vulnerability identification process, as defined in Requirement 6.3.1.

For more information, see Requirement 6.3.1.

Attacks on business logic, including attempts to abuse or bypass application features and functionalities through the manipulation of APIs, communication protocols and channels, client-side functionality, or other system/application functions and resources. This includes cross-site scripting (XSS) and cross-site request forgery (CSRF).

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 6.3.1

New security vulnerabilities are identified using industry-recognized sources for security vulnerability information, including alerts from international and national computer emergency response teams (Certs).

Organizational procedures are implemented to keep this information current.

Vulnerabilities are assigned a risk ranking based on industry best practices and consideration of potential impact.

On our intranet, we maintain a section that collects common security vulnerabilities as well a risk assessment regarding the IBM Safer Payments software product.

Requirement 6.3.3

All system components are protected from known vulnerabilities by installing applicable security patches/updates as follows:

• Critical or high-security patches/updates (identified according to the risk ranking process at Requirement 6.3.1) are installed within one month of release.
• All other applicable security patches/updates are installed within an appropriate time frame as determined by the entity (for example, within three months of release).

A process for the development and deployment of patches and upgrades is established. The same process is used whether the root cause is a security-related issue or just a technical/functional related issue.

Patches are delivered through Fixcentral. Software is delivered using a secure web server (https protocol). Installation media is protected by SHA256 hash that is provided via the Release Notes in the IBM Support Portal. Any patches and updates are integrity tested before delivery. Before the installation, the customer must manually test the integrity via the checksum as described in Downloading the installation image.

Where to find more information provides a link to the IBM Support Portal and Fixcentral where Technotes, patches, and updates can be securely downloaded.

Requirement 6.5.1

Changes to all system components in the production environment are made according to established procedures that include:

• Reason for, and description of, the change.
• For bespoke and custom software changes, all updates are tested for compliance with Requirement 6.2.4 before being deployed into production.

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

Documentation of security impact.

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

Documented change approval by 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.

Testing to verify that the change does not adversely impact system security.

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.

Procedures to address failures and return to a secure state.

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 6.4.2.03 to IBM Safer Payments 6.4.2.00, for example, you first back-out one instance after another to IBM Safer Payments 6.4.2.02, then to IBM Safer Payments 6.4.2.01.

For more information, see Installing a fix pack update.

Requirement 6.5.5

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.

Requirement 6.5.6

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.