Security Penetration Testing for PCI DSS: What You Need To Know

The PCI Security Standards Council releases new versions of its Data Security Standards every three years. This year it came as a surprise when PCI DSS version 3.1 was released just two years after the release of 3.0 in November 2013. PCI DSS 3.1 formally replaced 3.0 on 30 June 2015.

Why the sudden release? The main reason was believed to be major security flaws such as BEAST and POODLE in the Secure Sockets Layer protocol and the early version of its successor, Transport Layer Security (TLS).

With the release of 3.1, SSL and early versions of TLS have been duly prohibited and security penetration testing is now not an option, it’s mandatory!

Requirement 11.3 of 3.1 relates to security penetration testing.

11.3 Implement a methodology for penetration testing that includes the following:

• Is based on industry-accepted penetration testing approaches (for example, NIST SP800-115)
• Includes coverage for the entire CDE perimeter and critical systems
• Includes testing from both inside and outside the network.
• Includes testing to validate any segmentation and scope-reduction controls
• Defines application-layer penetration tests to include, at a minimum, the vulnerabilities listed in Requirement 6.5
• Defines network-layer penetration tests to include components that support network functions as well as operating systems
• Includes review and consideration of threats and vulnerabilities experienced in the last 12 months
• Specifies retention of penetration testing results and remediation activities results.

New requirements relating to penetration testing that were considered as “best practices” in earlier versions are now compulsory. In simple words, without meeting these requirements, you cannot achieve PCI compliance.

Although penetration testing has always been a part of PCI DSS, what is different in version 3.1 is how it has been mandated. PCI DSS 3.1 directs the inclusion of some key provisions to penetration testing, but does not specifically define what to do and how to meet those provisions.

The bottom line of this requirement is that your penetration testing methodology should be in a written form and you must hire a qualified internal resource or a penetration testing firm to carry out the tests according to the methodology and requirements of PCI DSS. The requirement also states that penetration testing should not only be internal and external but should also establish network segmentation for reducing scope and provide entire coverage of your cardholder data environment.

1. Adopting a methodology

So what’s the best way to comply with this requirement? PCI DSS 3.0 does not specify which particular methodology you should use but it’s obvious that it wants a robust methodology. You can use NIST SP 800-15 which is used by PCI Security Standards Council as a reference to get an idea of what is really required. You can also try publications by SANS, for instance, “Conducting a Penetration Test on an Organization”. That being said, when choosing a penetration testing firm to carry out the penetration test for you, choose a firm that has developed its own methodology and a reliable one too. You should make sure that whichever methodology for penetration testing you adopt, it must be detailed, easily examinable and justified.

What makes an effective penetration testing methodology?

Penetration testing done for PCI clients is often low budget and a bare-minimum process, mostly done as a vulnerability scan. For instance, if a compromise is detected in a missing patch, it is not the missing patch that is the vulnerability, but rather the process that failed to apply the patch to the target. The focus of the penetration testing process should be to discover faults in processes and procedures, and find the missing links with evidence to prove your findings.

As a general rule, a good methodology should include:

1. A clearly defined goal or purpose of the test
2. Simulation of threats and agents
3. Attestation of security defence measures like alerts, IDS/IPS and responses
4. Knowledge of attack vectors and their destinations
5. Documentation of attempted attacks and their failure or success results
6. Presentation of results in a planned and actionable way.

2. Segmenting the data

Segmentation of data within the cardholder data environment must also be a part of security penetration testing. In other words, penetration testing should test that the “ring fencing” that is supposed to be in place is actually in place. This is important because you actually test that the segmentation controls are working, rather than only assuming that they are!

It’s necessary to test access to cardholder data from each network that comes under the umbrella of the merchant. This is to prove to the Qualified Security Assessor (QSA) that each control is in place and functioning correctly. It helps ensure that cardholder data is safe from not only external threats but internal ones as well. Another segmentation area that is quite often overlooked is penetration testing within the CDE; this needs to be taken care of too.

3. Reality-based testing

All businesses must consider and review the threats and vulnerabilities encountered during the last twelve months. This will require penetration testers to consider often-ignored threats like social engineering – such as password hacking or phishing scams – that have a high rate of success. The goal of this requirement is to provide a real-life scenario and test the system against it. This helps you analyse your security measures and flaw detection capability in case of a real attack.

Small merchants are not excluded

If you’re a small merchant and thinking this probably does not apply to you, you’re wrong. Small merchants relying on Self-Assessment Questionnaires (SAQ) to validate PCI DSS compliance also need to comply with requirement 11.3. No matter what type of SAQ a small merchant is qualified to complete, whether SAQ A-EP, SAQ C, or SAQ D, they are all required to carry out security penetration tests.

All in all, we think it’s a good thing, and hope that this mandatory requirement of security penetration testing and implementation of a methodology for penetration testing will result in fewer cardholder data compromises, more secure networks and fewer breaches and frauds.

Is your business looking to get PCI DSS compliant? StickmanCyber's PCI DSS compliance service deploys a 5-step methodology to help you build trust with your customers and guarantee secure transactions with PCI DSS Compliance.