PCI DSS Requirement 6.3: Secure Software Application Development

June 2, 2020 • Published Categories Best Practices Tags , ,

The Payment Card Industry Data Security Standard (PCI DSS) has 12 primary requirements, but within those it has a multitude of sub-requirements. While many of these are straightforward there are several that can leave even the technologically savvy person perplexed.

Secure software application development is one such requirement. I often find clients challenged with the specifics surrounding PCI DSS requirement 6.3, which is focused on the Software Development Life Cycle (SDLC) when a company is developing software that interacts with cardholder data.

Requirement 6.3 specifies:

Develop internal and external software applications (including web-based administrative access to applications) securely, as follows:

  • In accordance with PCI DSS (for example, secure authentication and logging).
  • Based on industry standards and/or best practices.
  • Incorporate information security throughout the software development life cycle.

Secure Software Development Under Requirement 6.3

While 6.3 is often one of the most overlooked of the requirements within the DSS, it can be leveraged to mature your software development efforts. Therefore, let’s break down this requirement bullet by bullet.

Bullet Point 1: [Develop software] in accordance with the PCI DSS.
The intention here is that when an application goes into production it can be placed into a fully hardened environment and function, as well as operate, in a PCI-compliant way. This means that all requirements that we find in PCI DSS 1 through 8—plus 10, where applicable—must be built into the software. Examples include the masking of cardholder data, encryption, authentication, logging, secure transmission, etc.

Bullet Point 2: [Develop software] based on industry standards and/or best practices.
The point of this bullet is that when developing software, the organization must have a directed security activity and be considerate of known vulnerabilities; security cannot be an afterthought or by happenstance.

It’s imperative that all developers understand the security framework they are trying to develop defensively against. The PCI DSS calls out OWASP; however, this focuses on top 10 Web-based application vulnerabilities only. Therefore, I also recommend having a look at the CWE Top 25 as a security framework.

Bullet Point 3: Incorporate information security throughout the software development life cycle.
I often hear, “We use OWASP as our SDLC”; however, it’s important to understand that the SDLC is a “Software Development Lifecycle” whereas the OWASP SKF is a security framework. While related, they are different. Most organizations will likely be using a development methodology based on AGILE, JAD/RAD, Waterfall or some variant of these.

The Phases of Secure Software Development

From the PCI DSS perspective, it doesn’t matter what methodology is used to develop software as long as there are these distinct development phases:

  • Requirements: In Agile, we often hear the requirements called “stories,” but these stories define the end state. In some cases, requirements are documented much as a policy would be (i.e., “the application must encrypt data at rest”). It doesn’t really matter what you call them, because they are all the same thing: Requirements define how the application is to function.In a mature development shop, we will see “user specification, technical specification requirements”; however, when looking at the specific requirements, we are going to want to see security requirements. This is reflective of both the first and second bullet points above. Also note that the requirements must cover the applicable PCI DSS requirements, as previously discussed.
  • Design: In the Design phase of an SDLC, we are looking to ensure the security requirements that were called out in the Requirements phase are being designed into the application. In addition, don’t forget to check that the design itself is based on secure practices (required in bullet points 1 and 2 above).When design is done, there generally should be a fork to the Testing phase as well as the Development phase. The testing team would be required to develop their test scripts and test cases. This takes time, so most organizations will start this as part of the design phase, as they are “designing the test cases” for the application.
  • Development: During this phase we want to make sure that coders have had secure code development training within the last year. I also recommend knowing enough about how to develop software to know when the responses being provided are sufficient. The tests for this are found in PCI DSS requirements 6.5.1 through 6.5.10.Where you provide annual secure code training to your staff, please make sure you retain evidence that the training took place and covered the necessary attributes to defend your developed applications against attack.
  • Test: There are two ways to know that the application is secure when it goes into production: 1) The testing team has reviewed the source code and/or performed appropriate empirical tests to demonstrate that the application is secure, and 2) Testing was executed against the requirements to ensure that the previously identified security requirements have been met and are implemented correctly.You should be prepared to present records of code review, automated or manual security assessments, security/regulation acceptance test cases, and results of each, demonstrating that the application is secure and free of vulnerabilities.
  • Stage: This phase of development is where we look to ensure that there is SOD (Segregation of Duties) between the production staff and development staff. We look to ensure that development staff cannot get into production and production staff cannot get into development. There are also different networks.This control is intended to ensure that code does not get promoted into production without the correct security controls defined by the SDLC. The counter argument to this is often, “We are a one-man shop, so we do not have SOD.” If you encounter this, I am happy to have a conversation about how to overcome this challenge.
  • End of Life (EOL): The last phase of an SDLC is EOL. In this phase we are looking for information to define how the application is decommissioned to ensure that any residual cardholder data is securely handled/deleted. The specifics here are somewhat captured in PCI DSS requirement 9.8.

Hopefully the tips I’ve provided here will help set you on the path to compliance with PCI DSS requirement 6.3. Click here for more information on secure software development and how your business could benefit from a PCI-certified Secure Software Lifecycle assessment.