How to Address PCI DSS Requirement 6.6 — A Two-For-One Solution From Threat Stack

The current version of the PCI DSS is 3.2.1, published in May 2018. Requirement 6 states that you must “Develop and maintain secure systems and applications.”  Sure, no problem. That’s totally clear and straightforward — at least for anyone who’s never tried to develop and maintain secure systems and applications! For the rest of us, that’s a tall order. 

But the document goes on to list a number of fairly straightforward requirements — things that are already components of most secure software development lifecycles. You should establish a process to identify security vulnerabilities, address known vulnerabilities, employ best practices in coding, securely separate development & test environments and accounts from production, do code reviews, have a change control process, train developers in secure coding techniques, and so forth. All pretty reasonable. 

A bit deeper under that top-level requirement — in Requirement 6.5 — a number of specific vulnerabilities are listed against which applications should be protected. These are a sort of “greatest hits” from OWASP TOP 10, SANS CWE Top 25, CERT Secure Coding, etc., and are what you would expect — SQL Injection, weak cryptography, XSS, buffer overflows, and the like. Again, reasonable. Attackers reliably target these types of vulnerabilities as an initial point of attack. 

Then, in Requirement 6.6, the biggie: “For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks.” Which attacks? It answers, “at a minimum, all vulnerabilities in Requirement 6.5.” Think about that for a moment. This single requirement — 6.6 — buried deep in the document on page 64 has a major impact on how we build and operate software! How do they propose meeting this requirement? The answer has two parts:

• By reviewing apps annually and after any changes — using “either manual or automated vulnerability security assessment tools or methods”
• By using “an automated technical solution that detects and prevents web-based attacks” 

So this impacts both the build-time and runtime for web applications and really involves two completely different activities:

1. Reviewing applications to proactively find the presence of vulnerabilities (and then making sure that they get corrected)

– And – 

2. Detecting and blocking attacks in real time

It’s not a bad requirement at all. As the guidance states, “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.” I couldn’t agree more. The challenge comes in the practical implementation of the requirement. 

There’s not much guidance given for how to accomplish the first part — reviewing apps. Apps should be reviewed “using either manual or automated vulnerability security assessment tools or methods.“ That’s pretty broad. 

The second part has a slightly more specific recommendation. You should install “an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) in front of public-facing web applications, to continually check all traffic.” This was a boon to WAF vendors who suddenly found themselves a “check-box” purchase for teams looking to satisfy Requirement 6.6. But a WAF doesn’t help with the first part of the requirement. A WAF isn’t a security assessment tool: It has no idea what an application does or how. It only understands what’s being sent into an application — not what the application may (or may not) do with that information.

All this leaves many teams struggling with addressing the totality of 6.6. In this one small requirement are two significant and quite different needs. Most will try to satisfy the second part with a WAF, and assemble a number of other techniques to address the first (manual code reviews, automated source code analysis, etc.). 

But there is an alternative that can satisfy Requirement 6.6 with a single solution. You’ll notice that the PCI standard includes the phrase “for example” when mentioning WAF. This is significant (and it wasn’t included in earlier versions of the standard). It acknowledges that other technologies exist that can protect applications as long as they are “configured to either block web-based attacks, or generate an alert that is immediately investigated.”  Application Security Monitoring — the unified application security solution that Threat Stack has added to its Cloud Security Platform® at no extra cost — addresses both the build-time and runtime aspects of Requirement 6.6. One solution to these two big challenges. 

At build time, you add the Threat Stack microagent to your applications just like any other third-party code library. Developers find it very similar to instrumenting their applications with an APM solution. Once the microagent is added, the application is assessed every time it runs — whether that is through local manual testing, automated testing in a nightly build, user acceptance testing, and so on. PCI specifies that the app must be reviewed “at least annually and after any changes.” Threat Stack goes far beyond that to identify security vulnerabilities on a continual basis — all without the developer needing to do any extra work. There are no tests to write or servers to administer.

Once a vulnerability is identified, Requirement 6.6 also directs that it must be addressed. You must ensure “that all vulnerabilities are corrected and that the application is re-evaluated after the corrections.” Threat Stack AppSec Monitoring gives developers actionable guidance on any risks detected — explaining the risk, presenting sample code on how to fix it, and directing the developer to the exact module and method name and file location and line number where it was found. Once the developer corrects the vulnerability, there’s no need to do anything special to “re-evaluate” — the application will be assessed automatically the next time it’s run. 

At runtime, the requirement is to “continually check all traffic” to protect the application against known attacks. The same Threat Stack microagent does this as well. As the application is deployed from dev to production, the microagent goes with it (it’s baked into the application as a dependency). From there, it analyzes all web payloads that are sent to the application to watch for signs of attack. If a payload is determined to be malicious, the request can be stopped immediately. Teams are notified about the attack via the Threat Stack portal or in Slack or other ChatOps channels. This squarely addresses the PCI requirement to “either block web-based attacks, or generate an alert that is immediately investigated.”

PCI 6.6 is big. The mandate to “address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks” covers two separate phases of the software development lifecycle (dev and prod) and involves two separate tasks (proactive vulnerability assessment and real-time attack detection and prevention). Both are complex, and they typically involve different teams. But you don’t need two separate tools to address them. Application Security Monitoring from Threat Stack addresses both requirements with a single solution that won’t slow developers down. Try it today!   

If you’re interested in learning more or want to take Application Security Monitoring for a test drive, sign up for a demo of the Threat Stack Cloud Security Platform. Our compliance and security experts will be happy to discuss your specific requirements.