The Payment Card Industry Security Standards Council recently released their updated Information Supplement: Penetration Testing Guidance. The guidance document was last published in 2008 under the heading ‘Requirement 11.3 Penetration Testing’
The updated document marks a major difference in the approach taken by the PCI Council to clarify and educate stakeholders about the standard’s requirements for penetration testing.
The new supplement focuses on the:
- Scope of testing
- Capability of the penetration tester
- Methodology of testing
- Reporting guidelines
Scope
Scoping a penetration testing as per the requirements of the PCI DSS standards has been one of the most confusing aspects. The brief supplement provided in 2008 did not make matters easier. The newly released document delves deep into what should be included in the scope of a penetration test and how it is different from a vulnerability assessment. Below are the critical points highlighted in the document:
- The scope of the PT is divided into two primary components:
1. External PT: Externally exposed CDE (Card Holder Environment) interfaces and critical systems should be scanned at the application and network layer. VPN and Dial-up connectivity should also be included in scope of the PT
2. Internal PT: The perimeter of the CDE should be scanned from out-of-scope LAN networks for application and network level vulnerabilities - PCI Council also requires that the effectiveness of network segmentation between CDE and non-CDE should be validated. Since this can become impractical in very large organizations with different levels of segmentation (Firewall, VLAN ACLs etc.), the Council requires the tester to plan, examine and sample each segmentation technology such that they can assured that all instances of the segmentation technology are effective.
- Additional recommendations suggest that the PT may include systems which are not directly related to card-data, but were they to get compromised this would have a direct impact on the CDE.
- Testing from within the CDE is not required. However, pentesters are encouraged to explore the depth that can be reached if the CDE is compromised from outside. Data-loss prevention controls should prevent the pentester from ex-filtrating data from the CDE
- With relation to application level testing, the PCI council does not require testing of PA-DSS certified applications or COTS applications. These applications should only be tested at the implementation level (OS security and network security).
- All applications with multi-level user roles should be tested with all levels of privileges
- Including Social engineering assessments as part of the penetration testing scope is recommended by the Council as it helps determine the effectiveness of the security awareness program. Although SE is not mandatory, organizations may be required to provide documented reasons if they don’t go in for it – especially if they have faced SE attacks in the previous 12 months.
Capability of the penetration tester
PCI Council permits qualified internal resources or competent external 3rd party resources to execute the PT (as long as they are not involved in the administration and maintenance of the target systems/applications)
Certain guidelines should be considered while selecting the pen testers:
- Certification of the tester which can be considered as an indication towards the skill and capability of the tester
- Past experience of the tester is vital to ensure that the tester is well versed with the requirements of the PCI DSS standard and has experience testing similar environments and organizations
- Quality assurance and training practices of the organization conducting the penetration test
Methodology of testing
PCI DSS council recommends either white-box or grey-box testing methodologies for conducting a penetration test.
Detailed recommendations have been provided in the supplement on the methodology for conducting a PT such as:
- Who will define the scope
- What documents should be shared with the tester
- What would be the rules of engagement
- What precautions need to be taken in case the infrastructure is hosted in the cloud or with a 3rd party
- What can be defined as the success criteria for the penetration test
- Reviewing past threats and vulnerabilities
- Avoiding scan interference by perimeter security devices like IPS and WAF
- What to do if card holder data is found during testing
- Remediate steps for organizations
- Revalidation assessment of the identified vulnerabilities
Reporting Guidelines
The final outcome of a penetration test should be in the form of a well-documented report which highlights:
- Scope of the test
- Limitations to the test scope
- Details about each tests and vulnerabilities
- Results of the segmentation validation
- Tools used
- Actions required to clean up environment
- Final outcome of the tests
- Revalidation status along with evidence
For the benefit of the organizations, the authors have included 3 detailed case studies of scoping examples.
The document does fall short in some areas to ensure a comprehensive approach towards testing. For example, Social engineering attacks are prominent in today’s world. Giving an organization an option to opt out of such a requirement reduces its importance.
Secondly, web applications have been broadly classified under COTS and in-house developed applications. Only requiring comprehensive application security assessment of the latter provides organizations an exit route for testing framework-based COTS (like Weblogic, Websphere, ERP solutions etc.). It could possibly also be used by organizations in the context of applications based on open-source frameworks.
Lastly, in the scope section of the supplement, the authors have left it to the prerogative of the organization to decide if they wish to include certain systems or controls in the scope of the PT.
For example, the statement “The penetration test may include systems not directly related to the processing, transmission or storage of cardholder data to ensure these assets, if compromised, could not impact the security of the CDE.” could potentially include the entire environment into the scope of PT so that assurance is can be derived.
Overall, the supplement has undergone a major uplift from its 2008 version. It includes a lot of guidance on scoping the penetration test, deciding the methodology and documenting the findings and evidences. It is definitely a must-read for security assessment firms conducting penetration tests for PCI-compliant entities.
