PCI Requirement 6.3 – Develop Secure Software Applications
by Randy Bartels / October 13th, 2017
Secure Software Application Defined
PCI Requirement 6.3 focuses on the software development lifecycle, or SDLC. PCI Requirement 6.3 states that all internal and external software applications must be securely developed, in accordance with the PCI DSS, industry best practices, and with information security incorporated.
A securely developed software application should have several capabilities. It should be able to function in a hardened application or operating system. The application must encrypt sensitive data in storage and in transmission. It should operate on a system that supports antivirus. Securely developed software supports authentication controls. It should also have the ability to be patched and continuously updated.
How to Develop Secure Software Applications
Secure software applications need to be developed in accordance with industry best practices. There’s several development methodologies to work with (Waterfall, Scrum), but according to the PCI DSS, the best way to ensure you securely develop software applications is to incorporate information security into several phases of your development process: requirement gathering, design, development, and testing.
1. Requirement Gathering – Your organization should spend time identifying the functional and technical specification requirements that an application needs to operate on.
2. Design – Your organization’s method for designing an application should ensure that it’s developed according to the requirement specifications called out in the previous phase.
3. Development – Developers must develop secure codes. Your organization should train your staff, at least annually, on how to develop secure code.
4. Testing – This phase ensures that an application is fully hardened before it’s pushed into production. An assessor will gather your test cases to verify that the requirement specifications, design functions, and security functions incorporated are secure.
If information security is not incorporated into each of these phases, security vulnerabilities could be unintentionally or maliciously introduced into the production environment. In production, the PCI DSS requires separation of duties to further secure the software application. The development environment should be separate from production, just as the developers should be separate from the managers of production.
The focus of PCI Requirement 6 is to maintain a secure environment around your applications. As part of this, where 6.1 and 6.2 are identifying your vulnerabilities and then patching your systems, we get to Requirement 6.3. 6.3 focuses on maintaining a software development lifecycle. The SDLC, or software development lifecycle, needs to be developed in accordance with the PCI DSS. I don’t think many people really understand what this means within this environment or within the scope of PCI, and I’ll talk about that in a moment. Your SDLC needs to be based on an industry best practice, and I’ll talk about that as well. We need to make sure security is incorporated throughout that lifecycle.
Let’s start off by talking about how the PCI DSS can be a part of your SDLC and what that means. We need to make sure that when an application is developed, that application can be put into production, it can be fully hardened, and fully support all the requirements around the PCI DSS. Typically, the guidance that I give to clients when I’m working with them is: it needs to function in a fully functioning, hardened application or operating system. It needs to encrypt the data in storage and transmission. It needs to operate on a system that supports antivirus. We need to be able to patch it and update it. It needs to support authentication controls. As we go through the PCI DSS, each one of these controls has some aspect of managing the credit card environment. We want to make sure that the applications you’re developing support that secure, hardened environment.
The next thing the PCI DSS talks about is the applications need to be developed according to best practices. That’s easy enough. Google search SDLC and there’s Waterfall, Scrum, and numerous other development methodologies that you can use. Effectively, what we’re looking for is several phases, from an assessment perspective.
The first phase is the requirement gathering. What we’re looking for is that your organization has spent time with the business units to identify what the functional and technical specification requirements that this application needs to operate on. Where we find most organizations fail is in the fact that they never really spent the time to gather the security requirements. So, we have the requirements phase.
Next is design. We then look for the method and means that you’ve used to design this application to ensure that this application is going to be developed according to the specifications that you’ve required. We have design considerations around encryption, authentication (how you might authenticate). We also have all the password requirements; are you going to allow the application to authenticate natively, or are you going to connect it to your authentication server? There’s a lot of things that we look for in terms of the design phase, but what we’re looking for is that you’ve designed to meet the security specifications that have been called out from your requirements phase.
So we have requirements, we have design, and now we go into development. In the development phase of your SDLC, we want to make sure that your developers are developing secure codes. How do we do that? We look at your training program. One requirement is that you train your staff, at least annually, on how to develop secure code. We’ll talk about that requirement shortly.
After that application is developed, we move into a test phase. From an assessment perspective, we ask for your test cases, showing me that all of the security requirements and all of the design and security functions that you’ve designed into it are done securely and that it actually met all of those requirements. Once again, the intent is that after the application has been developed and pushed into production, that this application is fully hardened.
We go from requirements, design, development, test, and now we move into production. As part of your SDLC, we look for the methods and means of how you push that application into production in a secure way. Requirement 6 requires that we have a separation of duties. There’s a couple of places where it talks about separation of duties, but it specifically calls out that we have a separate place for development environments from production, and separate people developing than are used for management or production.
Lastly, as part of an SDLC, we have the end of life. As an assessor, we don’t really call into question what you’re doing during those phases. We might want to make sure that you’re covering all the necessary security attributes, and that those security attributes meet all those security requirements that are called out by the PCI DSS. Even if you develop the application, these applications need to be developed in such a way that are secure when they are put into production and void of any vulnerability.
