What is a PCI External Penetration Test?

Among the security testing that PCI DSS v3.2 requires is external penetration testing. External penetration testing is becoming a regular part of security practitioner’s vocabularies, with seemingly every security standard requiring it and any mature security program identifying its importance. The requirements surrounding a PCI external penetration test have some specific nuances that are worth discussing, as a misunderstanding of these requirements could result in your organization’s non-compliance. Additionally, since this is an activity that you’ll be required to undertake on at least a yearly basis (and after any “significant” change to your network architecture), having a strong grasp on the concepts as they are laid out by PCI could result in a more effective testing program, less resource expenditure surrounding successful testing, and the avoidance of non-compliance.

A PCI External Penetration Test is NOT a Vulnerability Scan

We’ve covered this topic previously, but it bears repeating as the PCI Council specifically calls this out in their penetration testing guidance. A PCI external penetration test must be a true penetration test and not simply a vulnerability scan. Whereas a vulnerability scan might identify, rank, and report vulnerabilities, a true penetration test will identify ways to exploit those vulnerabilities. This exploitation of vulnerabilities is a manual process that may make use of automated tools, but does not center around their use. The results of a real PCI external penetration test will also include realistic assessments of the associated risk of discovered vulnerabilities, taking into account any mitigating controls or circumstances. The PCI DSS calls out external vulnerability scanning as a completely separate activity, with different associated requirements.

Who Can Perform Testing?

Notably, while vulnerability scanning must be conducted by an Approved Scanning Vendor (ASV), penetration testing must be conducted by a qualified internal resource with organizational independence or a qualified third party. The PCI Penetration Testing guidance mentions that a mix of industry-recognized certifications and past experience are both vital in selecting penetration testers, but does not provide any specific requirements. We’ve seen that it’s also helpful to have penetration testers that are experienced with PCI-specific assessments, as they can help with the scoping process and can help convey risks that are specific to compliance.

Scope Matters

Armed with an appropriate definition of what it means to conduct a PCI external penetration test and who can perform this testing, another important piece of this puzzle is deciding what needs to be tested from a compliance perspective. The majority of mistakes that can affect compliance are made at this point, when trying to decide which assets to include in the testing scope and what kind of testing needs to be performed. As a baseline, the testing scope defined by the PCI Penetration Testing Guidance should include “the exposed external perimeter of the cardholder data environment (CDE) and critical systems connected or accessible to public network infrastructures.” Any systems that are in-scope for PCI and accessible from the Internet should be tested, including those involved in the transmission, processing, or storage of cardholder data or those that could affect the security of in-scope systems. PCI goes on to detail that even systems that utilize source IP address filtering to restrict access to only specific IPs should be tested. And finally, PCI also explains that application-level penetration testing (both authenticated and unauthenticated) should be paired with the network-level penetration testing performed when custom-written applications that are in-scope are available from the Internet.

Does Social Engineering Need to Be Included?

Social engineering involves the exploitation of employees in an attempt to gain sensitive information or introduce unauthorized software to an organization’s in-scope environment. PCI DSS does not require that this be a part of testing, but does specify that penetration testing should consider the threats and vulnerabilities experienced by an organization in the past 12 months, which may include social engineering. Indeed, if you are concerned about realistic security rather than “check-box” compliance requirements, it doesn’t make sense to ignore the primary attack vector being observed, with over 90% of all successful cyber attacks being attributed to phishing attacks. Social engineering assessments can also very effectively assess the risks associated with your end-users, the effectiveness of your security awareness training programs, and the posture of your documented policies and procedures.

Let us know if this was helpful or if we missed answering any questions you may have surrounding a PCI External Penetration Test!