PCI Requirement 6.6 – Address New Threats and Vulnerabilities on an Ongoing Basis for Public-Facing Web Applications
by Randy Bartels / October 13th, 2017
Address New Threats and Vulnerabilities for Web Applications
PCI Requirement 6.6 states, “For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks.” You can comply with PCI Requirement 6.6 through two methods: by reviewing public-facing web applications via manual or automated application vulnerability security assessment, at least annually and after any changes, or by installing an automated technical solution that detects and prevents web-based attacks in front of public-facing web applications to continually check all traffic.
A web application security assessment is not a penetration test or a vulnerability scan; it’s a much more specific, directed assessment. During this assessment someone who is qualified, knowledgeable, and independent of the development process must identify and address new threats and vulnerabilities for web applications. All common coding vulnerabilities from PCI Requirement 6.5 should be addressed in this assessment. After a new threat or vulnerability is identified, the vulnerability must be corrected and re-evaluated. This assessment should take place annually or whenever a significant change occurs in your environment or to the application.
A technical solution to address new threats and vulnerabilities for web applications is to install a firewall in front of public-facing web applications, in order to detect and prevent web-based attacks. The PCI DSS describes this method as, “Web-application firewalls filter and block non-essential traffic at the application layer. Used in conjunction with a network-based firewall, a properly configured web-application firewall prevents application-layer attacks if applications are improperly coded or configured.” This firewall needs to be actively running and updated, generate audit logs, and be configured to blog web-based attacks or alert the organization of a new threat.
The intent behind PCI Requirement 6.6 is to create a continuous cycle of security. We want to make sure that before an application goes into production, there’s a process in place to ensure it will not be left vulnerable in the future.
Where your organization has a public-facing web application, PCI Requirement 6.6 would apply. This requirement is really intended to establish controls to protect applications that might later become vulnerable, or where your team might have developed an application with a vulnerability, however, they missed it. That does happen from time to time.
There’s two ways to meet this particular requirement. The first is that you have an application layer firewall that resides in front of your web application. Where this is the case, you need to have this web application firewall actively scanning, kept up-to-date and managed, and blocking. If it is not blocking these applications, what’s happening is your team is notified and alerts are immediately acted upon.
The second way to meet this requirement is, on an annual basis, you do a web application security assessment. A lot of organizations get this part wrong. Understand a web application security assessment is a very directed, very specific assessment. It’s not a pen testing, it’s not a vulnerability scan. However, those activities might occur as part of this assessment. In a web application security assessment, we expect that people will look at the source code, looking at the back-end, really trying to identify all issues that might exist within the application where there might be a vulnerability, as opposed to just scanning the application. Understand that a web application security assessment is a much more thorough activity than your normal quarterly scan. This web application security assessment would need to be done by somebody that qualified, somebody that’s competent, somebody that’s independent, or specializes in it. It needs to be done after any significant changes to these applications and at least annually. If you have somebody within your organization that’s specific to testing the vulnerabilities and testing applications, that are not developing applications, it’s okay to have them do this test for you. But, if this particular individual or team answers to your development department, there needs to be some type of organizational independence. We need to make sure that when the application goes into production, it’s not going to be left vulnerable.
