The Payment Card Industry Data Security Standard (PCI DSS) was introduced to provide a minimum degree of security when it comes to handling customer card information. While the Standard has been around for over a decade, penetration testing has only recently been officially incorporated into the process. There’s a lot to cover in a PCI DSS engagement, and some aspects may fly under the radar as a result, especially considering the amount of information available and the various types of penetration testing.
Vulnerability Scan versus Penetration Test
The PCI DSS 3.2 document distinguishes between a vulnerability scan (requirement 11.2) and a penetration test (11.3), both of which are required for PCI DSS compliance. The difference between the two is simple: a vulnerability scan is typically entirely automated and provides minimal verification of discovered vulnerabilities, while a penetration test goes a step further and attempts to exploit vulnerabilities using manual techniques. Not only does this remove false positives from the automated scanning phase of the test but also demonstrates the real-world risk to the business and what a hacker could actually accomplish when targeting a company’s systems. Make sure the penetration testing provider includes manual testing and verification rather than just an automated scan.
The Scope of the Penetration Test
The test must include the perimeter of the Cardholder Data Environment (CDE) and any systems which, if compromised, could impact the security of the CDE. In order for a system to be out-of-scope for a penetration test, it must be completely segregated from the CDE, so that if the system were compromised, the integrity of the CDE would be unaffected. It’s possible to reduce the scope of the test by segregating your network, for example, via strict firewall rules. While this is not compulsory, it reduces the cost of the test (since there’s less to test) and has the added bonus of making your network inherently more secure in case of compromise. It should be noted that checks must be performed (requirement 11.3.4) to confirm the segmentation controls are effective on at least an annual basis (or six-monthly if you’re a service provider) and 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 test can vary; however, all high-risk vulnerabilities (and higher) must be addressed at a minimum before the system can be considered compliant, either through full mitigation or with compensating controls. The risk ratings are dependent on multiple factors, including impact, likelihood, ease of exploit, and an industry score (such as CVSS). In addition, existing compensating controls will have an effect in reducing the risk level. Some issues, although rated as low risk in the penetration test report, may impact a separate PCI DSS requirement and will, therefore, require remediation before compliance can be achieved. The test report should be considered as evidence in the same way as all other documentation presented to the Qualified Security Assessor (QSA). The additional evidence which is submitted alongside the report may, in some cases, be sufficient to mitigate a discovered vulnerability without the need for making additional infrastructure or code changes. Ultimately, the final decision rests with the QSA as to whether or not a company should be certified, and it is their job to determine whether there are sufficient defenses in place to mitigate a vulnerability.
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 can be given to the penetration tester, the more value can be obtained from the test. Not only will the test be better scoped, which may result in reduced cost, but the results will be even more accurate. Providing documentation on systems or cardholder data flow, or a list of expected services that should be available, allows the testing team to contextualize vulnerabilities and focus on areas where significant issues may exist. This approach is more commonly referred to as ‘white-box testing’ and replaces the traditional ‘black-box’ concept where the attacker has no knowledge of the systems to be targeted. This method also ensures that the key areas are checked thoroughly, and nothing important is missed within the time-limited testing window.
PCI DSS is only the beginning
PCI DSS should be considered a minimum level of security, which doesn’t encompass all aspects of cyber security. It primarily focuses on securing cardholder data and, therefore, doesn’t cover unrelated attack vectors, which could still be used to cause reputational and financial damage or to hack your company. For example, PCI DSS testing doesn’t mandate that every server you own must be tested, only those related to cardholder data. If the remaining servers are untested, this could introduce a security vulnerability into your network. 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.
About the Author: Alec Auer has been a penetration tester with First Base Technologies for several years and conducts various types of penetration and compliance testing, including web application and internal infrastructure, email phishing and Cyber Essentials. He has also achieved the Offensive Security Certified Professional (OSCP) qualification and is a CREST Registered Tester. Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.
