Why Remove Test Data Before Production?

PCI Requirement 6 says that software applications should be developed in a secure way, which requires that your organization go through many phases to ensure information security is incorporated throughout the application. PCI Requirement 6.3.1 picks up during the development phase and testing phases. PCI Requirement 6.3.1 states, “Remove development, test and/or custom application accounts, user IDs, and passwords before applications become active or are released to customers.”

During the development and testing phases, it’s likely your organization will use test data. This might be test accounts, IDs, passwords, or test data from a database of mock data. When your applications go from development and testing into production, the PCI DSS requires that all of this development data and testing information be removed from the application before it gets put into production. If this data is not removed before the application becomes active, the data could compromise the application.

During a PCI assessment, an auditor will examine the software development policies and procedures and interview the person responsible for removing test data from the application before production.

During your development phase, it’s likely your organization is going to be using test data. This might be test accounts or you might have actual test data from a database full of mock data. When those applications get pushed from development into production, we want to make sure that all of that development environment and development information is removed from the production application before it gets put into production.

Often when we run a pen test, the first account that I’ll use to try to get into an account is “Test Test” or “Test 123” or various test accounts like that. One of the things that an assessor will do is find out how you’re authenticating, if you’re authenticating. We’re going to find out how you’re storing or interacting with that database. However you do that, whatever the data is, however it might reside, wherever it might reside, we want to make sure that data is not pushed into production. Your assessor should be looking at that process, interviewing your developers, and actually looking at that data set as part of the onsite portion of the assessment.

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.

Ensure All Systems and Software are Protected from Known Vulnerabilities

In PCI Requirement 6.1, you learned how to establish a process to identify security vulnerabilities. Now, in PCI Requirement 6.2, we’ll discuss patch management programs. PCI Requirement 6.2 states, “Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches. Install critical security patches within one month of release.”

In today’s threat landscape, there’s a constant stream of attacks. PCI Requirement 6.2 exists to reinforce the fact that if the most recent security patches are not implemented on systems and applications as soon as possible, an attacker could use these exploits to attack, disable, or gain access to a system containing sensitive cardholder data.

The PCI DSS states, “Prioritizing patches for critical infrastructure ensures that high-priority systems and devices are protected from vulnerabilities as soon as possible after a patch is released. Consider prioritizing patch installations such that security patches for critical or at-risk systems are installed within 30 days, and other lower-risk patches are installed within 2-3 months. This requirement applies to applicable patches for all installed software, including payment applications.”

What You Need to Know about Patch Management for PCI DSS

Security patches for critical or high risk security vulnerabilities should deployed within a month of their release. If not, your assessor will question this.

If a security patch is released but the vulnerability is considered low, the PCI DSS says these types of patches need to be deployed within an appropriate amount of time. What’s considered an “appropriate” amount of time? We recommend within two to three months of the release.

PCI Requirement 6.2 requires that an assessor examine your policies and procedures to verify that there is an established process for patch management, which helps to ensure all systems and software are protected from known vulnerabilities. An assessor will also compare the list of security patches installed on each system to the most recent manufacturer-supplied security patch list, to verify that critical security patches are installed within one month of release and non-critical security patches are installed within an appropriate time frame.

For more security vulnerabilities and patch management programs, check out our Hardening and System Patches webinar. Learn more about how we approach PCI DSS compliance at Kirkpatrick Price.

Where PCI DSS Requirement 6.1 focused on identifying vulnerabilities and performing a risk ranking around them, Requirement 6.2 requires that you have a patching program. Where your risk ranking program has identified a risk as being high or urgent, we look to see that those particular patches are deployed in an appropriate amount of time. There’s really two call-outs within the PCI DSS. We have the critical or urgent that needs to be deployed within one month of their release, but secondary to that, there’s the all-other-security-related patches. The Council says these need to be deployed within an appropriate amount of time. Once again, these nebulous timeframes are really up to you to define. What is an appropriate amount of time? The PCI DSS recommends basically within three months. As an assessor, that’s kind of where we look. We understand that you have maintenance windows, but running a year without installing those patches is typically a pretty uncomfortable conversation to have.

What is PCI Requirement 6.1?

PCI Requirement 6.1 states, “Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking to newly discovered security vulnerabilities.” The purpose of PCI Requirement 6.1 is to ensure that your organization is up to date with new security vulnerabilities that could impact your environment. Assessors will look to see that you have a formal, established process in place to identify security vulnerabilities. When considering how to establish a process to identify security vulnerabilities, we recommend taking it in three steps: notification of security vulnerabilities, risk ranking security vulnerabilities and security patches, and then implement security patches.

1. Notification of Security Vulnerabilities

We recommend that you subscribe to a third party for notifications of security vulnerabilities. The PCI DSS states, “Sources for vulnerability information should be trustworthy and often include vendor websites, industry news groups, mailing lists, or RSS feeds.” When using something like Microsoft, Oracle, or Linux, it’s important to note that they do not publicly disclose security vulnerabilities within their application until there’s a security patch. If you use something like Secunia, you could be notified of new security vulnerabilities earlier and have an opportunity to fix them, instead of leaving your system vulnerable.

2. Risk Ranking Security Vulnerabilities and Security Patches

Once you’ve identified a security vulnerability or a manufacturer’s patch, you need to rank that risk. The PCI DSS explains, “Classifying the risks as ‘high,’ ‘medium,’ or ‘low’ allows organizations to identify, prioritize, and address the highest risk items more quickly and reduce the likelihood that vulnerabilities posing the greatest risk will be exploited.” We recommend the Common Vulnerability Scoring System (CVSS). Vulnerabilities and patches, once identified, are given a score between 1 and 10, 1 being “informational” and 10 being “needs to be addressed immediately”. Most of the vulnerabilities in today’s world are published with a CVSS score. Risk ranking is incredibly important because it gives your organization the chance to consider how a security vulnerability or security patch would affect your environment. If the manufacturer says it’s a critical or urgent security vulnerability, it’s absolutely appropriate to accept that and immediately patch for those things. However, there might be situations where a manufacturer considers a vulnerability or patch low risk, but once you’ve ranked that risk within your unique environment, you might realize it’s actually urgent or high. Risk ranking security vulnerabilities and patches can help your organization from believing common misconceptions, like:

• Just because there is an available security patch doesn’t mean that I have to install it immediately.
• If a vendor says an update is medium risk, then it’s not critical to my environment.
• If Microsoft, Oracle, or Linux doesn’t report a security vulnerability, my organization is immune from attack.
• Keeping my system patched will keep it free from all vulnerabilities.

3. Implement Security Patches

The PCI DSS requires that when you have identified a critical or urgent security patch, it needs to be implemented within 30 days. An assessor will need to examine your vulnerability program, your policies and procedures, the sources that notify you of security patches, the security patches on your system and applications, then compare all of that to your current patch level to discover if any additional patches need to be installed.

For more information on security vulnerabilities and security patching, check out our Hardening and System Patches webinar.

Starting off in Requirement 6, we have 6.1. 6.1 says that you have a program or process in place where you look to identify vulnerabilities within your applications. There’s several testing requirements around this, but effectively what we’re looking for is that you have third parties that you subscribe to help notify you of when there’s an issue. One of the things that I would generally recommend is, of course, using the Microsoft, the Linux, the Oracle, and other branded sites, but also try to find third parties that do this as a profession, like Secunia, for instance. The reason why I recommend that is because Microsoft will not publicly disclose that there’s a vulnerability within their application until they release the patch. There might be situations where your applications are left vulnerable for a period of time, but you might have had the opportunity to fix that, had you subscribed to these other third parties.

Once you’ve identified that there’s vulnerability, secondary to that is the manufacturers release a patch. You need to take that patch and vulnerability and you need to perform risk ranking within your environment. Most of the vulnerabilities in today’s world are published with a CVSS score. As part of that, the CVSS score (Common Vulnerability Scoring System) is really a starting point. You can accept that. If the manufacturer says it’s critical or urgent, it’s absolutely appropriate to accept that and go ahead and patch for those things. However, there might already be situations where an organization delivers a patch and they might say it’s low. When you risk rank that vulnerability within your environment, you might come to realize that’s urgent or high vulnerability and that patch might need to be deployed soon than later.

The PCI DSS requires that when we have a critical or urgent patch identified, that patch needs to be deployed within 30 days. From an assessment perspective, what the assessor is going to do is we’re going to look at your vulnerability program, look at your procedures, look at the fact that you are subscribing to third parties or outside sources for that information. We’re then going to pull a list of all of the patches for your applications, servers, really everything in your environment and compare that to patches that need to be installed or the patch level of your current infrastructure. What we’re looking for is that anything that highly critical or urgent has been deployed within 30 days.

PCI Requirement 6 pairs with PCI Requirement 5 to satisfy vulnerability management program expectations. PCI Requirement 6 states, “Develop and maintain secure systems and applications.” The purpose of this requirement is to build a process for securely managing the software within your environment.

Develop and Maintain Secure Systems and Applications in Your Environment

PCI Requirement 6 helps your organization develop and maintain secure systems and applications. Attackers often use security vulnerabilities to gain entry to systems in the targeted environment. While there are security patches to fix security vulnerabilities and prohibit attackers from exploiting them, there’s one problem: the entities that manage the system are responsible for installing the security patches. Many common security vulnerabilities could be fixed with vendor-provided security patches, but those patches are often installed too late or not at all. The PCI DSS calls for all systems and applications to have all appropriate security patches implemented within an appropriate period of time in order to protect the cardholder data environment. This requirement is directed towards all applications in your environment, not just applications you’ve bought commercially or ones that you’ve developed.

Wondering what the PCI DSS considers “appropriate” security patches? Appropriate security patches are ones that have been “evaluated and tested sufficiently to determine that the patches do not conflict with existing security configurations. For in-house developed applications, numerous vulnerabilities can be avoided by using standard system development processes and secure coding techniques.” Adhering to PCI DSS standards for security patches can help your organization develop and maintain secure systems and applications.

PCI Requirement 6 Overview

Our PCI Requirement 6 videos will provide you with an overview of these sub-requirements:

6.1: Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking to newly discovered security vulnerabilities.

6.2: Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches. Install critical security patches within one month of release.

6.3: Develop internal and external software applications (including web-based administrative access to applications) securely.

6.3.1: Remove development, test and/or custom application accounts, user IDs, and passwords before applications become active or are released to customers.

6.3.2: Review custom code prior to release to production or customers in order to identify any potential coding vulnerability.

6.4: Follow change control processes and procedures for all changes to system components.

6.5: Address common coding vulnerabilities in software-development processes.

6.5.1: Protected from injection flaws, particularly SQL injection. Also consider OS Command Injection, LDAP and XPath injection flaws as well as other injection flaws.

6.5.2: Protection from buffer overflows.

6.5.3: Do not allow insecure cryptographic storage.

6.5.4: Do not allow insecure communications.

6.5.5: Protect applications from improper error handling.

6.5.6: Manage all “high risk” vulnerabilities identified in the vulnerability identification process.

6.5.7: Protect all web applications and application interfaces from cross-site scripting (XSS).

6.5.8:  Do not allow improper access control, such as insecure direct object references, failure to restrict URL access, directory traversal, and failure to restrict user access to functions.

6.5.9: Do not allow cross-site request forgery (CSRF).

6.6:  For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks.

6.7: Ensure that security policies and operational procedures for developing and maintaining secure systems and applications are documented, in use, and known to all affected parties.

We’ve come to Requirement 6. The purpose of Requirement 6 is to ensure you have a process in place to manage the software within your environment. Understand that the purpose and intent behind this requirement is not just applications that you might purchase commercially off of a shelf or the applications that you develop. Requirement 6 is really about all applications in your environment.