How to Write a Penetration Testing Methodology for PCI

The PCI DSS requires that all assessed entities develop and maintain a penetration testing methodology. Many organizations struggle with this requirement and try to rely on a third party, mainly because it’s unclear what is needed. The methodology is meant to ensure a third party performing penetration testing is testing to the specifications that PCI requires. Therefore, it is necessary for the entity to understand the requirements, communicate them to the third party prior to the testing, and ensure they are fulfilled. Let’s walk through the requirements… it’s not as daunting as it seems.

PCI DSS requires that external and internal penetration tests of all PCI in-scope system components be performed annually, including security-impacting components. In addition to this annual requirement, a penetration test must be performed after any significant change. This test would only include those system components affected by the change. Let’s break that down a bit.

Internal testing is the testing of the internal perimeter of the CDE from the perspective of any out-of-scope LAN segment. External testing includes the exposed perimeter of the CDE and critical systems connected or accessible to public network infrastructures. This would include remote access methods into the CDE and cloud-based in-scope assets.

The testing itself will vary depending on what vulnerabilities are found. Experienced pen testers will know the routine and next steps. For those just getting started in penetration testing or wanting to become more familiar, NIST SP 800-115 or the PCI Council’s Information Supplement: Penetration Testing Guidance can be used as references. If hiring a third-party penetration tester, be sure to inquire about what industry standard was used to base their testing efforts.

Penetration testing services may be performed by in-house personnel or outsourced to a third party. The person performing the penetration test must have adequate certifications and experience and be completely independent from the systems being tested (segregation of duties). This means the penetration tester does not perform administration of the components or report to the same person that has responsibility for these components. Determining the level of adequate experience is the most difficult part. There are many industry certifications available and while they may be one indicator of an individual’s capabilities, just because someone doesn’t have a given certification does not mean they are not a competent penetration tester.  Consideration should also be given to the number of years performing penetration testing, the number of tests completed, and whether the tester is familiar with the PCI Council’s penetration testing requirements.

When performing the penetration test, many tasks have to be considered. Each test must include:

• Segmentation controls – this would include any controls that are used to create the CDE (cardholder data environment).
• Scope reduction controls – anything used to reduce the scope of the assessment.
• Network layer tests – network layer tests include components that support network functions. They also include operating systems. 
• Application layer tests challenge the actual applications. These tests look for the OWASP (Open Web Application Security Project) top 10 vulnerabilities, as well as the required tests in PCI DSS 3.2.1 6.5 / PCI DSS 4.0 6.2.4. Application layer tests should be performed for any software for which the entity is responsible for the source code (developed in-house or developed specifically for the entity). If the application is PA-DSS certified or assessed for compliance with the PCI Secure Software Standard, the source code does not need to be tested, but rather the implementation of the application needs to be tested. Testing should be completed using various roles within the application.
• Testing from both inside and outside the network – changing the vantage point of the test creates significantly different results. That is why the PCI DSS requires both internal and external penetration tests.
• Review and consideration of threats and vulnerabilities experienced in the last 12 months as well as newly discovered vulnerabilities within the industry. Each pen tester may evaluate the vulnerabilities that were discovered on the in-scope network in the last 12 months before beginning the testing. These previous vulnerabilities can help identify practices and processes that might be weak that will allow the pen tester to identify new vulnerabilities. Additionally, the pen tester will consider newly discovered vulnerabilities in the industry and determine if the in-scope environment is susceptible to these vulnerabilities.

To determine the scope of each test, several documents will be reviewed internally. These docs may also be shared with the pen tester to confirm scope. The docs may include:

• Network diagram
• List of network segments (both in-scope and out-of-scope)
• Data flow diagrams
• List of components that make up the perimeter of the CDE
• Details of how users access the CDE

With all of this information in hand, the test will begin. 

But, a bit more about penetration tests. Each penetration test has 4 phases: Planning, Discovery, Attack and Reporting. Let’s look at each phase.

Planning – as mentioned earlier, the scope must be defined by the assessed entity. Once the scope is defined, the Rules of Engagement (ROE) must be documented, agreed upon, and signed by both parties before testing begins. This includes start and end dates. The ROE are to ensure the pen tester only looks where they are supposed to look and do not enter areas that are out-of-scope. The ROE will inevitably come with a few concerns. This might include known systems that are sensitive to testing, communication methods for after-hours communication, and escalation methods if a system is rendered unresponsive as part of testing. These concerns must be addressed before testing begins.

During the planning phase, it will also be necessary to consider any security controls that would interfere or detect testing efforts. This is called scan interference. For a pen test to be of value, these security controls would need to be disabled just for the pen tester (not as a whole during the testing period). It’s not beneficial for a pen test to be detected and shut down; or blocked by security controls. That defeats the purpose of the test.

Discovery – In this phase, the test has begun. The pen tester understands the scope. During Discovery, the pen tester is looking for every asset within the scope to determine which assets are responding and on which ports they are responding. During Discovery, a pen tester may find assets not declared during the scoping exercise. These discrepancies have to be worked out to ensure the test is scoped correctly and the ROE still apply. 

Attack – The next phase is Attack. It won’t be evident on the network when one phase has ended and the next phase begins. During this phase, the pen tester is using everything they learned from past reports and the discovery phase to find ways to penetrate an asset. This is simulating the behavior of a would-be attacker. Creativity is key here. Thinking outside the box often allows access in ways that were not planned.

Reporting – When the testing window closes, the test is over. A report will be generated that includes all identified exploitable vulnerabilities, a risk ranking for that vulnerability, as well as suggested remediation steps. The test is now considered complete but there is still work remaining for the assessed entity.

The vulnerabilities identified must be remediated based on the risk ranking defined in PCI DSS 3.2.1 6.1/PCI DSS 4.0 6.3.1. Once remediation is believed to be complete, another pen test must be performed to ensure the remediation was successful. This penetration test takes the same phases as before, except the scope is greatly reduced. The re-test includes only those devices that were impacted by the remediation efforts. The pen tester repeats the testing cycle until all identified vulnerabilities are corrected and no longer vulnerable.

When the test is complete, the assessed entity must retain all penetration tests in a secure location for twelve (12) months. This would include the report, the scoping exercise prior to the test, and the rules of engagement. The assessed entity will also have some clean-up after the test. Accounts that were created for testing should be deleted. Additionally, if any controls were bypassed to allow for testing, those bypasses should be removed.

Note: At this time, PCI DSS does not require social engineering. It is acceptable to include social engineering as a requirement within your methodology (and I would strongly recommend it), but it is not a requirement for compliance. 

Penetration testing is a necessary evil. The “bad guys” are doing it and they do not have any rules of engagement … anything goes. The network has to be ready for their attempts to ensure vulnerabilities are corrected. A strong network will make the “bad guys” go looking for an easier target. By following this guidance, a strong penetration methodology can be written to ensure your penetration tests achieve the best possible results.