An SMB’s Guide to PCI 3.0 Penetration Testing

By now, if you’re an IT professional and you’re in an organization that has the Payment Card Industry Data Security Standard in your scope — that is, you store, process or transmit credit card data — you probably already know that an update to the standard, Version 3.0, was released late last year.

With this update come a few changes to the technical measures that organizations handling credit card information must implement. One of the potentially most impactful has to do with how organizations test the security of the systems that store, process or transmit cardholder information — specifically, how they perform “penetration testing” exercises against the subset of their infrastructure within the Cardholder Data Environment, or CDE.

While this change can have a broad impact no matter the size of the organization, SMBs may feel the changes most acutely. Why? Because many SMBs don’t have the expertise to conduct this testing in-house, meaning they often rely on external consultants or service providers to conduct it on their behalf.

Because 3.0 changes the testing requirements, this change can impact everything from which vendor to pick to the scope (and therefore cost) of the testing, the tracking of findings, and any number of other testing parameters.

What’s Changed?

It’s important to mention right off the bat that the requirement to conduct a penetration test (requirement 11.3) isn’t new. Previous versions required it, and 3.0 continues to do so. However, 11.3 has become much more rigorous in the 3.0 version.

For example, under 2.0, the test needed to be performed annually or after significant changes, and it required both network and application level testing. By contrast, the updated version of the standard now requires that testing fulfill the following requirements:

• be based on industry-accepted approaches such as NIST SP800-115;
• include the entire CDE;
• include testing from inside and outside the network;
• validate segmentation controls or controls to reduce CDE scope;
• include both application-layer and network-layer testing;
• specifically include a review of threats and vulnerabilities from the past year; and
• retain results of testing and track remediation activities.

Because of the extent of these changes, penetration is a “best practice” until June 30, 2015, at which time it becomes required. That might sound like a long time to some, but that’s deceptive, and it’s probably best not to defer planning.

Version 3.0 entails changes to the scope of the test — i.e., values you have direct control over — but that’s not all it requires. Stock penetration testing services from vendors might not address all the points on the list. Some vendors, for example, might follow a proprietary testing methodology not based on any formal standards; others might address testing from outside but not inside.

The point is, while some vendors surely will adapt their services to remain competitive in the PCI community, others might be more resistant. Best case, you’ll need to have a discussion with your vendor to find out and document how it will address the updates — and track its progress to make sure that it meets those commitments. Worst case, you’ll need to change vendors. Since changing vendors requires budgetary approval, vendor negotiations, contract discussions, logistical planning, and pre-engagement vetting, it’s best to start planning ASAP.

Preparing for Post-3.0 Testing

What does that planning entail? The first step is understanding a bit about what the vendor does process-wise. Specifically, you’ll want to investigate which process the vendor follows to ensure that it meets the “industry-accepted” bar. PCI specifically references NIST SP800-115 (“Technical Guide to Information Security Testing and Assessment”), but there could be other standards that you might consider acceptable in meeting the spirit of the requirement.

For example, the Penetration Testing Execution Standard might fit the bill when it comes to technical execution, or the Open Web Application Security Project Application Testing Guide might be appropriate when it comes to the application portion specifically.

The testing vendor should be able to specify, in some degree of detail, enough about its process to give you a level of comfort. Evaluate its responses critically — and document both the vendor’s response and your evaluation of it.

Assuming it’s acceptable, you should next evaluate and document the vendor’s process for testing new threats and vulnerabilities — specifically those originating in the past year. Again, be critical about this — many QSAs (PCI assessors) are technical, but many are less so. If your vendor can’t explain it to you in a way that makes sense, then it’s not likely it will be able to explain it any clearer in its report, or in direct communications with your QSA.

Second, you’ll want to validate the scope of the test itself in light of the updated requirement. In addition to including the entirety of CDE, which it did before, it needs to originate from both inside and outside the network.

There’s a good reason for this: Network segmentation mechanisms — e.g., firewalls — potentially limit what an outside attacker sees. An attacker inside the network (for example a rogue employee or from another compromised system) wouldn’t necessarily be restricted. So, explicitly testing both just makes good sense.

You’ll want to specifically include in the testing scope those systems responsible for segmenting the CDE. Document that too. Though the testing results ideally will have a section on scope, it may not be easy for you — or a QSA — to correlate the documented scope to those specific bullet points under requirement 11.3.

Last, you may need to change how you retain and track remediation. Keeping an archive of the test results is the easy part — the hard part it is keeping track of what you do in response. You’ll want to track the recommendations made and the findings observed by the tester, as well as the action you take in response.