Remember These PCI Pen Testing Requirements
Things just got real for companies that need to comply with PCI requirements. Not only is PCI v3.2 mandated, the PCI Standards Security Council has issued guidance on using penetration testing as part of a vulnerability management program.
Why are they buckling down? Part of the reason was explained well in the recent Verizon PCI Compliance Report. Compared to 2015, the 12 key requirements improved across the board in achieving full compliance. Some notable highlights from the Verizon Report are that Requirement 7 (restricting access) is easiest for most to comply with than any other requirement with Requirement 5 being a close second (protecting against malicious software). Alternatively, on the low end of performances, Requirement 11 (test security) still remains at the bottom with Requirement 4 (protect data in transit) just slightly worse. However, as Requirement 11 remains difficult to complete, there’s an explanation.
Scanning Isn’t Testing
Requirement 11 is the juggernaut of PCI v3.2. It’s packed full of objectives involving network scanning (11.2) and penetration testing (11.3). Just because scanning and testing are lumped into the same PCI requirement, doesn’t mean they accomplish the same goals.
The PCI Standards Security Council is helping to clear the air with a couple of simple descriptions.
Vulnerability Scanning: Identifies, ranks, and reports on vulnerabilities that, if exploited, may result in an intentional or unintentional compromise of a system. Translation? It’s an automated process taking a short amount of time, with no verification and very high chance of false-positives.
Penetration Testing: Identifies ways to exploit vulnerabilities to circumvent or defeat the security features of system components. Translation? It’s a manual or automated testing process that uses vulnerability scanning results as a baseline, lasting days or weeks depending on the scope.
Testing Ain’t Easy
Whether you use a tool or a service, complying with PCI Requirement 11.3 is a formidable task taking a combination of resources, time and a little bit of planning. In its simplest form, Requirement 11.3 mandates internal and external penetration testing at least annually or after “any significant infrastructure or application upgrade or modification”. Considering the volume of iterations of common operating systems and applications, I’d say we can throw out the idea of only testing annually. So, how do you test regularly and stay agile?
- The right person or service: Take a look to see if any of your team members have pen testing experience. The great thing is that some penetration testing products, like Core Impact, have the option of using wizards to run various tests. This helps automate some of the more laborious tasks, while accomplishing the same goals in less time. As a supplement to this, try bringing on a more seasoned penetration tester or dedicated third-party security service.
- The right tool: Depending on your needs and overall requirements scope, the tool you require may differ. Whatever it is, you need to be able to test regularly as things change in your environment. So, if you have one person on your team who only uses an open-source command-line based pen testing tool, with no other options, this could leave you in a bit of a pickle if he or she leaves. Be sure to have a backup plan.
- The right methodology: Penetration testing doesn’t just happen and disappear. According to the new PCI Security Standards Council penetration testing guidelines, it requires a phased-approach involving pre-engagement, engagement, and post-engagement steps. These steps cover important topics such as timing, frequency, reporting, systems to target, success criteria etc. Preparing properly will help you stay on target, meet the PCI requirements, and not become overwhelmed. Well, not too overwhelmed at least.
Want to learn more about how to tackle Requirement 11 of PCI-DSS v3.2? Check out their resource as well as our penetration testing resources.