PCI Penetration Testing
The first version of the PCI DSS standard was released in 2004 for laying down the minimum security requirements when it comes to handling and managing customers’ card information. Over the years, different versions have been introduced, and at present, version 3.2.1 is the latest version released in May 2018. In this article, we will discuss the role of penetration testing in PCI DSS compliance.
Vulnerability Scan v. Penetration Test
PCI’s Information Supplement document on Penetration Testing Guidance differentiates between a vulnerability scan covered under requirement 11.2 and a penetration test covered under requirement 11.3. Both of these requirements are compulsory for PCI DSS compliance.
The difference between the two is simply – a vulnerability scan generally scans the existing vulnerabilities, and there is minimal verification of the discovered vulnerabilities as the scans are automated more often than not, while on the other hand, penetration test goes a step further by attempting to exploit vulnerabilities by using the manual as well as automated techniques. False positives are mostly removed, and an organization gets insights into the vulnerabilities which could be exploited by the attackers while targeting its technical infrastructure.
Tip: IF the PCI DSS standard applies to you and you have outsourced penetration testing, double-check that your PCI penetration testing vendors methodology includes manual testing, vulnerability verification, and removal of false positives, not just automated scans.
Scope of a Penetration Test
PCI DSS defines CDE (cardholder data environment) as
“the people, processes, and technology that store, process, or transmit cardholder data or sensitive authentication data.”
When you are conducting a penetration test as a requirement of PCI DSS compliance, the scope must include the perimeter of CDE and associated systems which could impact the security of your organization’s CDE, if compromised. Hence, you must implement network segmentation so that even if any other part of the network is affected, CDE remains segregated and unaffected. An added benefit of segregating CDE from the rest of the network is to reduce the compliance costs for an organization significantly.
Once your network is segmented, checks must be performed as per requirement 11.3.4, at least yearly, to confirm that the implemented segmentation controls are effective. These checks must be performed by an individual who is completely unrelated to the implementation and management of your organization’s CDE.
Penetration Test Results
From time to time, the results of penetration tests conducted on your CDE are bound to vary. However, vulnerabilities with high-risk must be addressed and resolve before your CDE is considered to be PCI DSS compliant. This can be done either via full mitigation of risk or implementation of appropriate controls to reduce the risk.
Here, your existing security controls and risk appetite may play a role in reducing the risk to a certain level. However, there are also chances that there are certain issues that are marked as low–risk issues in the penetration testing report, but they may contradict a different PCI DSS requirement. Such issues have to be remediated for achieving compliance. The penetration test report acts evidence for a Qualified Security Assessor (QSA) when he comes for assessment. It is a QSA’s call to decide whether or not an organization fulfills the compliance requirements given in the standard.
Collaborate, not Outsource
Instead of completely outsourcing penetration testing for your organization, take an approach such that your penetration testing provider is like an extension of your internal security team. While hiring the service of a PCI penetration testing Vendor, you must be transparent and share the relevant details about your technical infrastructure so that the test is better scoped, resulting in accurate results and reduced costs.
For example, if you provide a document containing cardholder flow data or certain services that must be available during the working hours, the penetration testing will be better able to contextualize the vulnerabilities and perform business logic testing. Since the attacker is familiar with the network, this is also referred to as white box testing.
PCI DSS is just the beginning
Just like many other security standards, PCI DSS also prescribes a minimum level of security controls that must be implemented. It only focusses on the cardholder data, not the organization at large. Even after complying with the PCI DSS standard, an organization is required to make sure that its entire technical infrastructure is adequately secured, not just the CDE.
Keeping these things in mind, an organization must take an approach where they plan to secure their systems as much as possible, and in doing so, they can show compliance and receive accreditation as side benefits, instead of only making changes to obtain compliance certification.
- Application Security Testing10
- AWS Penetration Testing5
- Cloud Penetration Testing5
- DAST-Dynamic Application Security Testing10
- network penetration test1
- OSINT Penetration Testing1
- PCI DSS Compliance5
- Penetration Testing as a Service10
- Phishing as a Service5
- Service Organization Control(SOC)1
- web application security10
Automated Retest for DAST29 Jun, 2020
Automated Retest for External Infrastructure26 Jun, 2020