PCI DSS Blog Series – Requirement 6

The Payment Card Industry Data Security Standard (PCI DSS) consists of nearly 400 individual controls, and is a critical part of staying in business for any merchant, service provider, or subservice provider who is involved in handling cardholder data. We find that companies considering PCI are often caught off guard by how comprehensive the PCI DSS is. So, we thought we would help!

CompliancePoint’s PCI blog series will analyze each of the 12 Requirement families. We will outline common challenges our customers face with each requirement, answer some frequently asked questions, and finally, we will provide some pro tips on becoming PCI Certified.

This week we will address Requirement 6: Develop and maintain secure systems and applications

Requirement 6: Develop and maintain secure systems and applications

What does this requirement require at a high level?

At the base level, PCI Requirement 6 is all about keeping software and systems updated so that they are protected from malicious individuals and malicious software.

The requirement is broken into two groups; requirements that affect every organization and requirements that affect organizations who develop internal or external applications. An up-to-date system inventory (Control 2.4) is vital for both of these groups because it is difficult to protect systems if you are unaware of them.

Why is compliance with this requirement important (beyond getting certified)?

There are a variety of ways in which malicious software, or malware, can enter your network. Known malicious actors and malicious software are getting more advanced every day. It is vital to maintain a process to identify new vulnerabilities and assign a risk ranking to them. Software vendors regularly release patches to protect against “zero-day” or previously unknown vulnerabilities. If these critical patches are not applied to systems as quickly as possible, then there is a higher chance that these exploits can be used to attack a system or gain access to sensitive data. A defined Software Development Life Cycle (SDLC) helps to address many common mistakes and coding vulnerabilities.

Common Challenges & Tips for Success:

1. Maintain a vulnerability management plan (Control 6.1)
   • The first step to a vulnerability management plan is a complete inventory of the systems you are trying to protect. Knowing exactly what you’re trying to protect allows you to monitor reputable sources (i.e. vendor websites, industry newsgroups or mailing lists) for new vulnerabilities and patches that might affect your environment.
   • Rank the vulnerabilities by the risk they pose to your organization. An ASV scan or internal vulnerability scan that uses the CVSS scale is simply not enough. They may identify vulnerabilities that exist but without understanding the risk posed to your environment, will not give the best guidance for remediation. Classifying the risks as “high”, “medium”, or “low” gives staff the chance to prioritize patching tasks by risks that would have a greater impact.
2. Implement a change control process (Control 6.4)
   • Change control is not just for software or application development. A robust change control or change management process helps to keep all affected parties and owners on the same page and documents changes to the environment.
   • A change control process should include the following:
     • Documentation of Impact. The impact of the change should be documented so that all affected parties can plan appropriately for any processing changes.
     • Documented change approval by authorized parties. Approval by authorized parties indicates that the change is a legitimate and approved change sanctioned by the organization.
     • Functionality testing to verify that the change does not adversely impact the security of the system. Testing should validate that all existing security controls remain in place, are replaced with equally strong controls, or are strengthened after any change to the environment.
     • Back-out procedures. For each change, there should be documented back-out procedures in case the change fails or adversely affects the security of an application or system, to allow the system to be restored back to its previous state.
     • If a change adds a network segment, new application, or new type of component to the environment then PCI considers it a “Significant Change”. As part of the significant change, all PCI DSS requirements must be implemented and documentation updated as applicable. Basically, come up with a process to verify that all controls are being implemented correctly on new components within the in-scope systems. For example, update the network diagram and system inventory, verify that that configuration standards like minimum password requirements or deactivating unneeded services is in place, and making sure new devices are included in the quarterly vulnerability scanning process
3. Implement a defined software development process. (Control 6.3)
   • A software development process based on industry standards and best practices reduces the chance of some common development mistakes.
     • Remove test accounts and passwords before moving a system into production. These accounts commonly have more permissions than are needed for regular operation and gaining access to them might enable the release of sensitive information.
     • Code should be reviewed by someone other than the original author. An independent and objective review of code offers the chance to find and correct errors before the code is moved into production.
     • Implement appropriate corrections prior to release. Correcting errors before code is moved into production prevents secure systems from being exposed to potential exploits and reduces costs associated with trying to repair production environments.
     • Code review results should be approved by management prior to release. A formal review and sign off by management offers another check and balance to assure code had been developed in accordance with company policy and procedures.
4. Address common coding vulnerabilities as part of the software development process. (Control 6.5)
   • PCI requires that all developers receive training on secure coding techniques at least annually. The concern here is that the application layer provides a broad attack surface since it could face threats from both internal and external networks.
   • Requirement 6.5 points out several high priority vulnerabilities but also accepts that the current version of the DSS (v3.2.1) was released 2018 and encourages developers to follow industry best practices for vulnerability management. (i.e. the OWASP Guide, SANS CWE Top 25, CERT Secure Coding, etc.) Some of the common coding vulnerabilities specifically mentioned are:
     • Injection Flaws
     • Buffer Overflows
     • Insecure Cryptographic Storage
     • Insecure Communications
     • Improper Error Handling
     • Cross-site Scripting (XSS)
     • Improper Access Control
     • Cross-site Request Forgery (CSRF)
     • Broken Authentication and Session Management
5. Protect public-facing web applications. (Control 6.6)
   • Public-facing web applications are primary targets for attackers, and poorly coded web applications provide an easy path for attackers to gain access to sensitive data and systems. The DSS offer two options to mitigate the risk:
     • Install an automated technical solution that detects and prevents web-based attacks. (i.e. a web application firewall)
     • Review public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes.
   • We suggest you use both methods for all public and internal sites. Monitor errors that the WAF generates to learn how attackers are trying to probe your applications.

Common Questions:

1. Our organization does not develop software or applications; do we still have to have a change control process?
   • Yes, change control is not only for software or application development. A good change control process provides documentation for changes that happen within the environment so that staff knows exactly what changes were made and why. This is vital to make sure that security features are not being omitted during changes, but also to make sure systems are not brought down, and so there is documentation for future staff.
2. Do I really have to install a Web Application Firewall (WAF)?
   • No, requirement 6.6 does not specifically require a WAF. Organizations have the option to install and keep a WAF or submit to a large quantity “paperwork and legwork.” This “paperwork and legwork” stems from the fact that without the WAF you are required to conduct a vulnerability security assessment by an organization that specializes in application security after every change is made to the public facing website. Again, the WAF is strongly suggested even if you do internal reviews for ALL web applications and properties – even simple read-only websites.
3. What would I typically need to provide for Requirement 6 in a PCI assessment?
   • Requirement 6 is all about the paperwork and documentation. You need to have a documented procedure for assessing vulnerabilities using “reputable outside sources” that identifies new vulnerabilities and identifies all of those that are classified as “high risk” or “critical”. You need to submit your documented process and the assessor would interview staff to make sure they were aware of the process along with the fact that it is being followed. If you develop internal or external facing applications then you need to have a documented software development process that is based on industry standards, right along with this is the requirement for developers to receive up-to-date training on common vulnerabilities on at least an annual basis. To support these two portions, you would provide your documented software development process as well as an annual training log or certificates of completion for the developers. For a change control process, you would submit your policy that supports the change management process along with a sample selection of change control tickets. Requirement 6.2 requires that system components are updated and to support this process the systems are examined to verify that critical vendor-supplied security patches are applied within one month of release and that all other security patches are applied within a reasonable amount of time.

Conclusion

Keeping your system and software up-to-date is vital to the process of defending an organization and keeping sensitive information safe. Following PCI Requirement 6 gives your organization a base level of protection for systems and software that are in use from known vulnerabilities. Following defined processes and procedures helps reduce the blind spots that can happen in the development process and reduces the chances that known vulnerabilities will be introduced into home grown applications. Start thinking about the necessary documentation and verify it accurately reflects your organization’s IT Security controls and procedures.

Check Out Other Posts in this Series

• PCI DSS Requirement 1: Install and maintain a firewall configuration to protect cardholder data
• PCI DSS Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
• PCI DSS Requirement 3: Protect stored cardholder data
• PCI DSS Requirement 4: Encrypt transmission of cardholder data across open, public networks
• PCI DSS Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs
• PCI DSS Requirement 6: Develop and maintain secure systems and applications
• PCI DSS Requirement 7: Restrict access to cardholder data by business need to know
• PCI DSS Requirement 8: Identify and authenticate access to system components
• PCI DSS Requirement 9: Restrict physical access to cardholder data
• PCI DSS Requirement 10: Track and monitor all access to network resources and cardholder data
• PCI DSS Requirement 11: Regularly test security systems and processes
• PCI DSS Requirement 12: Maintain a policy that addresses information security for all personnel

CompliancePoint is a Qualified Security Assessor Company (QSAC). Our consultants have decades of experience as practitioners and auditors. Please reach out to us at connect@compliancepoint.com if you have any questions about this requirement or how CompliancePoint can assist your organization with preparing for your PCI DSS Certification.