What the PCI standard explicitly mandates about penetration testing is illustrated in Requirement 11.3, requiring organizations to perform annual penetration tests that would mainly:
- Evaluate both the network and application layers
- Include both internal and external testing
While the composition of the network layer tests is left to the discretion of the tester, the standard specifies that as a minimum the following elements must be included in the application layer tests:
- Injection flaws, particularly SQL injection
- Buffer overflow vulnerabilities
- Insecure cryptographic storage
- Insecure communications
- Improper error handling
- Cross-site scripting (XSS)
- Improper access control
- Cross-site request forgery (XSRF, CSRF)
- Broken authentication and session management
- Other vulnerabilities identified as high risk during the risk assessment
The above list is composed of the most common accepted secure coding practices at the time that version 3.0 of the PCI DSS was published. As industry-accepted secure coding practices change (for example, the OWASP guide, SANS CWE Top 25, CERT Secure Coding, etc.), organizational coding practices are expected to be updated accordingly.
However, the examples of secure coding resources provided (SANS, CERT, OWASP) are just suggested sources of reference, and have been included by the Council for guidance only. An organization would always be required to incorporate the relevant secure coding practices as applicable to the particular technology in their environment.
No further guidelines or regulations are specifically provided other than what was discussed above. Wrapping up, any well-structured approach to penetration testing would be acceptable, as long as the above items are addressed and any other effort keeps revolving around cardholder data.
In general, an advised approach would be to always assess all of the core areas of impact in application security, such as:
- Application Logic (client-side controls, logic flaws, etc.)
- Access Handling (authentication, session management, access control)
- Input Handling (parameter fuzzing)
- Application Hosting (shared hosting issues, web server security)
- Other miscellaneous checks (local privacy issues, generic info leakage, SSL/TLS weaknesses, etc.)
When appropriately approached, testing against those areas would be enough to encompass all the required elements, possibly going beyond the intended goals of PCI DSS.
PCI penetration test infrastructure level
With regard to the infrastructure segment of a PCI penetration test (e.g. the one that covers firewalls, routers, systems, web servers, databases, application servers, and whatever component or device which is relied upon to provide the overall service), there’s no clear stance from the Council, as said above. At any rate, whatever the approach chosen here, the same basic principles should be kept in mind:
- Go in as much depth and breadth as possible
- Always be mindful of card data
In general, this area covers one of the most common types of tests and involves finding targets on the network, looking for openings in their under- lying operating systems and available network services, and then exploiting them remotely. It seems indeed reasonable to limit the range of the internal assessment to a network-level rather than a local perspective, meaning that focus should be specifically pointed at finding issues on remotely visible ports/services. Indeed, in most cases, delving into a compromised host’s file system or DB tables, to search for card data, wouldn’t represent any added value to the whole PCI DSS audit, as that would be part of a QSA’s responsibilities.
Network level penetration test
A network-level penetration test should then concentrate all efforts in uncovering (and eventually exploiting) possible flaws affecting the targets’ network services, from the perspective of a host located on the very same network segment/subnet. Some of these network service tests happen remotely across the Internet, targeting the organization’s perimeter networks. Others are launched locally, from the organization’s own facilities, to evaluate the security of their internal network and/or DMZ from within, seeing what kinds of vulnerabilities an internal user could discover.
To such an aim, the tester’s assessing host is usually required to be any-any allowed on any perimeter Firewalls. It is not however needed to whitelist the tester’s host in case of possible host FWs active on target hosts.
While a security penetration test can be quite extensive and complicated, the requirements for a QSA conducting a test in a PSI DSS environment are not very extensive. QSAs therefore need to be as thorough as possible for a penetration test to be effective.
