How To Conduct PCI Penetration Tests for Security & Compliance

Posted on July 14, 2016 by lexi

If any requirement of the PCI DSS is confusing for organizations, it’s penetration testing.

It’s complicated, time intensive, and must be carried out by highly skilled and experienced personnel if it’s going to be done properly.

But on the other hand, penetration testing is widely understood to be an extremely high-value security process. After all, what better way to keep attackers out than by attacking on your own infrastructure and learning from the results?

We’ve said repeatedly during this series that aiming for PCI compliance isn’t enough. Unlike other areas of the PCI DSS, though, the penetration testing process described in requirement 11 is something a security conscious organization could be reasonably proud of.

Of course, we’d still recommend implementing regular penetration testing even if it wasn’t a requirement for compliance, and it does need to be backed up with a rigorous and consistent security program.

For now, though, let’s clear up a common misunderstanding.

 

Vulnerability Scanning Is NOT Penetration Testing

When version 3.0 of the PCI DSS requirements was made available in 2013, many organizations were concerned. Their formerly compliant penetration testing process would no longer make the grade, and instead, they’d have to either invest heavily in security resources or hire another firm to complete the necessary tests for them.

But what actually changed? Had a drastically new and improved method of penetration testing been invented?

Well… No. All that really changed was the wording.

Based on the wording from the original requirement, some companies were offering PCI penetration testing services that in reality were nothing more than vulnerability scans with a little extra reporting. But since July 2015, when real penetration testing became mandatory for both new and existing organizations to achieve compliance, the requirements are much more rigorous.

Unlike a vulnerability scan, which automatically compares a list of known vulnerabilities against your system architecture to identify areas of concern, a penetration test is a predominantly manual process. Skilled personnel try to identify ways to exploit vulnerabilities in your system architecture (whether known or otherwise) and to defeat your security features.

Unsurprisingly, unlike vulnerability scans which can usually be measured in minutes, penetration tests can take days or weeks depending on their scope and the size of the environment being tested.

 

The Compliance Checklist

Unlike other, much less prescriptive areas of the PCI DSS, requirement 11 is very clear about your responsibilities. Although you have some freedom to decide precisely how your penetration tests will be carried out, the parameters are very clear.

Under the new wording for requirement 11, you must:

  • Base your penetration testing processes on an industry-accepted approach (e.g. NIST SP800-115)
  • Test at least annually and on any significant change to your network or applications
  • Test the entire cardholder data environment (CDE), including your network, applications, critical systems, and network functions
  • Test from both inside and outside your network
  • Review any threats or vulnerabilities identified in the past year
  • Retain the results and records of all penetration tests and remediation activities

Clearly, this isn’t going to be a five minute job.

But whilst it’s true that any PCI compliant penetration test will be reasonably effective, we still wouldn’t suggest holding up compliance as a goal in itself. As usual, our recommendation is to design and implement a penetration testing process that genuinely enhances the security of your organization as a whole… and simultaneously ticks off the parameters of requirement 11.

 

Anatomy of a PCI Penetration Test

A well-constructed penetration test can loosely be divided into four sections: Planning, Discovery, Attack, and Reporting.

During the planning phase, approval for the penetration test is finalized and documented, tactics and techniques are agreed, and testing objectives are set. Although often skipped over, this phase adds essential scope and context to the testing process and should be carried out whether the penetration test is being conducted in-house or by a vendor.

The discovery phase is mainly about information gathering and usually involves studying network diagrams, reviewing the results of past vulnerability scans, penetration tests and self-assessment questionnaires, and checking security policies. If vulnerability management isn’t part of your standard security procedures, this would also be the time to complete a scan in order to compare your system architecture against vulnerability databases.

Now’s the time you’ve been waiting for. During the attack phase, you’ll aim to exploit identified vulnerabilities in order to gain access to the network. Of course, not all exploited vulnerabilities will grant direct access, so testers will also look for ways to gain information or privileges that could ultimately grant them the access they’re looking for. Ultimately, this work will inform configuration changes, patch installations, and other remediation activities designed to minimize the chances of an attacker gaining access to your network.

Finally, although reporting is listed as the final stage of penetration testing, it actually occurs alongside the first three phases. Essentially, logs are kept through the penetration test, and periodic reports are produced for system administrators and management. Once all testing and remediation activities have been completed, a final report is produced to detail exactly what has been done.

Sound a bit complex?

Well, to be honest, it is. That’s why we have…

 

The Outsourcing Conundrum

It’s important to remember that PCI DSS compliance is an ongoing issue. You’ll need to undergo a compliant penetration testing process at least once per year.

For most ongoing processes, the obvious solution is to develop an in-house capability. After all, the need isn’t going to go away, and hiring in vendors is often an expensive option. But penetration testing is complicated, and unless your organization boasts a truly world class security team you likely aren’t going to want to keep skilled personnel on hand year-round for relatively infrequent penetration testing projects.

Penetration testing, after all, is much more complex than most other security procedures.

Ultimately, most organizations decide to outsource, and their reasons are understandable. Although a significant expense, hiring vendors to complete the process has a number of obvious benefits, not least that their expert personnel are literally penetration testing all year round. A good vendor will also study all new PCI DSS guidance to ensure their processes are compliant and produce standardized reports that make evidencing your compliance a much simpler task.

 

Check out other posts in this series:

Post 1: PCI Compliance: What, Who, and How?

Post 2: How To Conduct a PCI DSS Risk Assessment (Even if You Have No Idea What You’re Doing)

Post 3: How To Manage Your PCI DSS Security Policy… And Why That Isn’t Enough

Post 4: Why Most PCI Training Programs Are Ineffective… And What To Do About It

 

SCHEDULE A FREE CONSULTATION

Penetration Testing Service

Want to evaluate the effectiveness of your existing security measures? TraceSecurity information security analysts can mimic a real-world cyber attack to uncover vulnerabilities that may exist on your organization’s internal and external network.

Schedule Now

Posted in Cybersecurity, IT Compliance and Regulatory Change Management