In this article, we are looking at 5 things you should know about PCI DSS Penetration Testing. We asked our CEO and PCI-DSS expert, Peter Bassill, to talk us through 5 things every online merchant should know.
A little background
The Payment Card Industry Data Security Standard, commonly shortened to PCI-DSS, provides a minimum degree of security when it comes to handling customer card information. While the standard has been around for more than a decade, specific requirements surrounding the penetration testing have only recently been officially incorporated into the process.
VULNERABILITY SCAN VERSUS PENETRATION TEST
The PCI-DSS distinguishes between a vulnerability scan (requirement 11.2) and a penetration test (11.3). Both Penetration Testing and Vulnerability Scanning are required for PCI DSS compliance.
The difference between the two is simple. A vulnerability scan is an automated process. It provides no human verification of discovered vulnerabilities and only alerts on known knowns. That is, it only alerts on the presence of vulnerabilities it knows about.
A penetration test is a much larger piece of work. A penetration test attempts to exploit known vulnerabilities using manual techniques. It then takes the process further by looking for unknown vulnerabilities.
Penetration Testing removes false positives from the entire process and demonstrates the real-world risk to the business and what a hacker could actually accomplish.
When booking your penetration test, make sure the penetration testing provider includes manual testing and verification rather than just an automated scan. Also check that the testers performing the test are at least OSCP qualified.
THE SCOPE OF THE PENETRATION TEST
The scope of a penetration test is possibly one of the hardest parts of the entire process. As a professional tester I have had no end of scoping calls where potential clients want to reduce the scope to save on cost. This is a false economy. There have been numerous PCI-DSS audits where the merchant has failed for not having performed a satisfactory penetration test.
The penetration test must include the perimeter of the Cardholder Data Environment (CDE). This must include any systems which, if compromised, could impact the security of, or grant access to, the CDE. A system is out-of-scope for a penetration test when segregated from the CDE. This way the security of the CDE is unaffected when it is compromised.
It’s possible to reduce the scope of the test by segregating your network by segmentation. Segmentation is achieved by using very strict firewall rules or using separate networks. If you have implemented segmentation, you must control both inbound and outbound ports. Do not allow ANY. While segmentation is not compulsory, it reduces the duration and therefore the cost of the test. This also has the added bonus of making your network inherently more secure in case of compromise.
Checks must be performed annually to confirm the effectiveness of segmentation controls. If you are a service provider it is six-monthly. This is requirement 11.3.4. These must be conducted by an individual who is completely separate from the implementation or management of the CDE.
UNDERSTANDING THE RESULTS
The results of a penetration test vary. Critical and high-risk vulnerabilities must be addressed before any system is compliant. The risk ratings are dependent on multiple factors. These include impact, likelihood, ease of exploit, and an industry score (such as CVSS).
Any existing compensating controls will have an effect in reducing the risk level. It is important to discuss these with your penetration tester. If the tester was not aware of these then you could be receiving a higher risk score. It is possible that low risk issues can impact a separate PCI DSS requirement. If this is going to happen the should be clearly documented in the report.
Your penetration test report is evidence of your security controls. Any additional evidence submitted alongside the report may be sufficient to mitigate a discovered vulnerability without the need for making additional infrastructure or code changes. Ultimately that decision rests with the QSA.
USE A COLLABORATIVE APPROACH
Make the penetration testing provider an extension of your own team rather than an outside third-party. The more detail that you give to the tester the better the results.
Providing documentation on systems or cardholder data flow helps. A list of expected services should also be provided. This allows the testing team to contextualise vulnerabilities and focus on areas where significant issues may exist.
PCI DSS IS ONLY THE BEGINNING
PCI DSS is a minimum level of security. It does not encompass all aspects of cyber security.
PCI-DSS focuses on securing cardholder data. It does not look at other attack vectors. For full coverage, speak to your tester about expanding the test and providing a PCI-DSS report as a separate report.
You should, therefore, change your approach from simply attempting to obtain PCI DSS accreditation, to securing systems as much as reasonably possible, and then achieving compliance as a by-product.