When it comes to pen testing, it can always be roughly broken down in to two core phases: scanning and exploiting. Simply put: know what you’re dealing with; then you may push the red “fire” button and unleash hell.
The scanning phase
This of course applies to any PCI-related pentest being carried out against the infrastructure layer of an entity under assessment. The main goal of the scanning phase is, indeed, to learn more about the target environment and find openings by directly interacting with any detected target system and/or network component. As a positive side-effect, scanning might lead to identifying further items that were not included in the PCI scope of the target environment.
Several types of scans are performed during this phase, including but not limited to:
- Network sweeping: aims at identifying which hosts that are actually live by sending packets to all network addresses in a specific target range
- Port scanning: once live hosts have been detected, this phase discerns potential openings in all target machines by looking for listening TCP and/or UDP ports
- OS fingerprinting: aims at determining the target operating system type based on network behavior
- Service detection: attempts to determine both the version and type of service which is presumably bound to the listening port
- Vulnerability scanning: a crucial part of the scanning process, since it measures whether, based on the above, the target machines COULD be affected by one of the thousands potential vulnerabilities, including but not limited to misconfigurations or unpatched services
The exploitation phase
The main aim of the exploitation phase is to demonstrate the actual presence of exploitable vulnerabilities as detected in the previous core phase, with special focus on the ones that could expose card data that can be compromised. During this phase the tester tries to actively gain access by circumventing security measures that are in place, expand access and elevate the level of privilege obtained. This is normally achieved through:
- Searching for proof of concept code in the tester’s repository
- Searching for exploit code from publicly available sources
- Development of own tools/scripts
- Using tools, scripts, exploit and/or proof of concept code against the target to gain as many points of unauthorized access as possible
A successful exploitation phase eventually offers proof that vulnerabilities are actually there to harm, helping to identify the relevant threat scenarios that may directly or indirectly affect cardholder data and, thus, PCI compliance.
Regarding PCI compliance specifically, it is important to point out that, out of the total set of issues that would result from the whole testing campaign, only a specific sub-set will most likely have an impact on compliance. This is a very important aspect in PCI related penetration testing and, as such, it deserves some further explanation.
As highlighted several times in this and previous articles, PCI DSS is all about securing cardholder data. This means that, regardless of how critical an issue might be, any relevant findings are subject to further “filtering” criteria where only possible direct and indirect impacts on card data confidentiality is considered relevant for compliance. So, if you manage to find a way to remotely switch off or erase the main back-end database without being able to get in touch with its content, it would not necessarily imply a “PCI Fail” condition. Even if all mission-critical data is lost. Basically, unless Confidentiality of cardholder data is directly or indirectly in jeopardy, Availability and Integrity generally don’t determine any impact on compliance on their own.
A compliance checkmark is not a shield against evil
This is only one of the many possible examples leading to the very important conclusion that PCI DSS compliance alone is not necessarily synonymous with good overall security. Many organizations today unfortunately still tend to overlook this aspect and continue to be exposed to considerable business losses, since they somewhat pretend that the “compliant checkmark” is a shield against all evil. Well, in a way it is, but it is way too small of a defense.
The Standard in fact “only” defines a security baseline for any organization that processes, transmits, or stores cardholder data. Being compliant only involves satisfying the requirements; it does not AT ALL mean that the organization’s business is exhaustively and thoroughly secure and all related security objectives are met. Keep this well in mind when it comes to choosing your own approach to security testing for PCI DSS requirement 11.3. At least, if you want penetration testing to bring actual value added to the organization from an overall security standpoint.
To summarize
The bottom line is, when you undergo your next annual pentest, don’t just look at the “PCI Fail” findings: carefully read through the list of findings and fix ALL that would actually put your business at risk.
