PCI Requirement 6 – Develop and Maintain Secure Systems and Applications
by Randy Bartels / October 13th, 2017
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.
