Last updated at Tue, 29 Aug 2017 23:30:39 GMT
This newsletter clarifies what is expected to comply with PCI DSS 11.3: Penetration testing.
Why is Pen-test needed?
In the same way that wellness checks support a doctor's diagnosis by determining what's wrong or not working as expected (a.k.a. an analysis) and establish the appropriate treatment (a.k.a. a remediation plan), penetration testing aims to:
- Determine and validate a diagnosis by determining the genuineness and severity of identified vulnerabilities
- Validate that defense mechanisms against external and internal attack vectors are working appropriately. In other words, checking to see that the security controls meant to detect and block security issues and alert the appropriate responsible actually work.
Why scanning is not enough?
Scanners are used to identify potential anomalies or deviations against a defined normality. They help answering to the question: “Is there something wrong?” The use of scanners is however not sufficient to determine if these anomalies comprise a real danger.
In this context, penetration testing is used to answer the next question: “So what?” It helps clarifying the level of danger an anomaly presents, or the level of exploitability of IT vulnerabilities. If scanners help uncover potential issues, penetration tests help validating the reality of these findings in term of risks for the entity and priorities in term of remediation.
Penetration testing for PCI compliance
Conduction of penetration testing is a pre-requisite for meeting compliance with PCI DSS V3 for type A-EP, D, S and C organisations (see Merchant types). They must:
- Have a documented, validated and applied methodology for penetration testing (DSS 11.3.1)
- Perform penetration testing at least annually and after any significant infrastructure or application upgrade or modification (DSS 11.3.1, 11.3.2, 11.3.4)
- Correct and validate correction of reported « exploitable » vulnerabilities. (DSS 11.3.3)
From which perspective?
Penetration tests must be performed through the following perspectives:
- From public networks forming the external perimeter of the CDE (Requirement: 11.3)
- From any non-CDE LAN that has access to the CDE perimeter (Requirement: 11.3.2)
- From any non-CDE LAN that is entirely segmented from the CDE (Requirement: 11.3.4). The intent of this assessment is to validate the scope-reduction controls between the non-CDE LANs and the CDE perimeter.
What happens during a pen test?
Penetration testers will try to get unauthorized access to components within the CDE, including security network devices, servers, databases and application written by or for the organization. Beside any critical systems outside of the CDE, boundaries that could affect the security of the CDE must also be targeted. Common examples of critical systems would be a DNS server, Active Directory Server, NTP server, and/or an Update server.
Who conducts the pen test?
Organizations subjected to penetration testing may use either internal resources or third party testers who must be qualified for such job. The term qualified being left to the QSA appreciation.
How do you prove compliance?
Make sure to have the following materials ready:
- Documented penetration methodology covering the various sections listed in the standard;
- Documented and validated scope of penetration tests and how it was determined;
- List of executed pen tests with the following information: Test date, Internal or External, Initial versus re-test, Pen tester Id, scope in terms of IP's, Number of exploitable vulnerabilities reported, link to reports;
- Last reports;
- Remediation plan (for identified issues) (Actions and planning);
- Documented evidences of the penetration testers qualifications.
Any ideas or recommendations to show compliance with 11.3?
What are the major impediments you got on your way and how you solved them?
Have you read our previous newsletter: PCI 30 seconds newsletter #36 - Control your privileged accounts - How to contain the “Keys to the kingdom” problem