Technical Testing
Technical testing has a long-standing legacy in PCI DSS. Even from the days of the old CISP and SDP standards, technical testing has been a critical component of demonstrating compliance. Over the years, testing has evolved from simple external scans to full penetration testing that requires testers to prod all layers of the OSI model. In PCI DSS 3.0, the Standard requires that you use an industry-accepted penetration-testing methodology, which could lead to confusion. They do cite NIST SP 800-115 as an example methodology and the Penetration Testing Guidance (March 2015) by the Council, which at least gives you a place to start. Penetration testing is not something that you should take lightly, and not something you should treat as a slightly more difficult vulnerability scan. True penetration testing almost always leads to a successful intrusion, and should target people and process as diligently as it targets technology.
Keywords
PCI DSS 3.1; technical testing; penetration testing; web application firewall
Technical testing has a long-standing legacy in PCI DSS. Even from the days of the old CISP and SDP standards, technical testing has been a critical component of demonstrating compliance. Over the years, testing has evolved from simple external scans to full penetration testing that requires testers to prod all layers of the OSI model. In PCI DSS 3.0, the Standard requires that you use an industry-accepted penetration-testing methodology, which could lead to confusion. They do cite NIST SP 800-115 as an example methodology and the Penetration Testing Guidance (March 2015) by the Council, which at least gives you a place to start. Penetration testing is not something that you should take lightly, and not something you should treat as a slightly more difficult vulnerability scan. True penetration testing almost always leads to a successful intrusion, and should target people and process as diligently as it targets technology.
PCI DSS 3.1 provided some fairly critical updates to version 3.0 that help to clarify the intent of the new penetration-testing requirements. Specifically, they wanted to clarify how segmentation would be tested, what needs to be included for the testing, and how to ensure blocking and alerting technology works to the best of its ability.
Since technical testing is in a couple of different requirements, we’re going to be jumping around a bit. This section primarily focuses on updates to Requirement 11.3 and 6.6.
Requirement 11.3
This requirement evolved in two ways. First, the Council removed some language from the 11.3.2.a testing procedure. Next, they updated Requirement 11.3.4 to help clarify what systems must be tested for segmentation. Remember, as of PCI DSS 3.0, any declared “segmentation” in your environment must be validated as part of this process. As you are going through your preparation for your annual assessment, consider reviewing the 11.3 language very carefully. Your QSA is going to be asking a few more questions this time around, specifically around your methodology and ensuring the report from your test aligns with that methodology. You will need to take networks and applications through this process, and you will probably have many more findings this year. In addition, while you are required to make sure that you test for any vulnerability listed in Requirement 6.5, be sure your methodology includes a run through the latest OWASP Top 10 as well.
Requirement 6.6
This requirement seems to get more teeth with every iteration. When it was first introduced, it was effectively neutered by Requirement 11.3. Or Requirement 6.6 neutered Requirement 11.3. It’s all a matter of perspective. Essentially, companies could choose to (effectively) follow the penetration testing requirements from 11.3 for their web applications, or they could superfluously add a Web Application Firewall (WAF). WAFs have a place in your information security strategy, but it should not be hastily slapped in place based on Requirement 6.6. The current iteration in 3.1 is still a bit confusing. Here’s how you need to look at it. You must do one of these two things.
1. You must take any public facing application through Requirement 11.3, or
2. You must deploy a WAF in front of said public facing web application.
Am I oversimplifying things? Slightly. But the review of both requirements would be nearly identical (albeit with more specific guidance in 6.6).
If you choose to deploy a WAF, PCI DSS 3.1 closes another loophole with deployments that alert instead of block. The new update now requires that alerts are “immediately investigated.” The guidance uses weaker language and says that the response must be “timely.” You can guess that there will be interpretation variance on this. Here’s my guidance. If you are using a WAF, then you should tune it to be tied to an alerting system that is immediately followed up on. Or, better yet, set it to actively start blocking bad traffic. If you do either of these things poorly, I can assure you that it will be held over your head in the case of a breach.
You should probably use a combination. I would argue the better strategy is to take it through Requirement 11.3 and ensure you fully meet that requirement. Then, for added measure, drop the WAF in place in alert mode, and develop a risk-based strategy for responding to the alerts. Ultimately, this meets the requirement without the WAF, but putting additional detection technologies in place may help you detect more attacks before they get serious. Check with your security teams to see what kind of technologies they recommend!
Future proofing against technical testing is painful, but it’s absolutely possible. Essentially, it means that you are altering your testing methodology and techniques to keep up with current hacking trends—including specific attacks against the technology in use at your firm. For example, if you decide to take on a mobile payments offering, you need to adjust your methodology to include the apps, devices, and infrastructure you stand up that is dedicated to this function. Keeping up with general application vulnerabilities as well as vulnerabilities rooted in your platform is a must, and being able to react to those changes as they pop up is critical. If you have not embraced faster moving IT deployment methods such as DevOps, it’s probably time to consider moving in that direction. Keep in mind, PCI DSS doesn’t keep up with the bad guys, so if you want to stay safe, you need to.