Penetration Testing vs. Red Teaming: PCI Edition

There are numerous differences between penetration testing and red teaming (covered elsewhere), despite the fact that these practices share the same history and to the outsider may seem like the same thing. For the lay person, “penetration testing” as a term is easier to grasp and likely conjures an idea closer in definition to a red team exercise.

Somewhere back in time, our industry slowly put constraints on “penetration testing” as a practice and the definition warped. Now “pentesting” is a compliance and software lifecycle driven form of security testing, and the no-holds-barred approach to really discovering how an organization’s security posture will hold up under pressure is referred to as “red teaming.”

An organization will perform pentests to satisfy a compliance regulation, like PCI. However, it’s highly unlikely that ANY compliance regulation will ever really require “red teaming” (mostly because compliance regulations like to codify definitions and the real meaning of “red team” is to defy any preconceived notions or definitions).

Can a compliant organization become breached? Well, that’s a nuanced question I will simply avoid by waving my hands and saying “keep reading…”

I often say, “an organization performs pentests because they’re mandated, but an organization performs a red team assessment to learn about themselves,”and I suspect many organizations are not prepared to really learn about themselves on that level, but let’s stop waxing philosophic and get into specifics with PCI.

PCI is great at what it does. One thing it does is to mandate a litany of security controls on the environment where customers’ credit card data lives. These controls are very expensive, and an organization typically chooses to segment their network, so they only have to implement those controls on the least amount of networked assets possible. That segment is where customer credit card data lives, so that is where penetration tests are performed.

As a result, a typical retailer looks like the oversimplified drawing above, with the following characteristics:

· At least one internet connection

· A corporate network of workstations and servers

· A segmented network where credit card data lives

· Firewalls

Inside the PCI DMZ, pentests will be performed against the entirety of the environment, scoped to the definition of the “cardholder data environment,” i.e. the red box. The blue box will be out of scope. Items in the red box, such as routers, servers, workstations, and applications, will be tested periodically. Applications may be tested more frequently, e.g. upon significant code changes. All of this testing is putting that red box under a microscope — this is very important testing and most definitely should be performed.

However, consider the following scenario:

Assume an adversary gains access to the corporate network. This should not be considered impossible, especially since the organization deliberately chose to implement more security controls in its PCI zone — where its valuable assets (i.e. customers’ credit cards) live. This unauthorized access could be achieved through any one of the four method of initial unauthorized access. It happens. To pretend it won’t is foolish.

The organization may even perform penetration testing against the corporate network periodically. Perhaps the testers even gained some similar amount of initial access to the corporate network. Typically, even in this scenario, the tester’s scope is limited, and they are not allowed to pivot into different environments, such as PCI. Or, even if they’re allowed to do so, they will be limited to only a few days’ time to locate a pivot, while a determined adversary may see the payout of credit card data worth spending weeks or even months trying to gain that access.

The adversary now has an initial access foothold in the corporate network. As a result, there may be assumptions in the design of the security controls between the corporate and PCI network zones that fail to assume the first breach happens. Components in the PCI zone may trust or rely upon components in the corporate segment, and that trust can be abused.

Ask the question: are there corporate employees who need to access the PCI zone as part of their daily job requirements? If so, there must be a remote access mechanism. If the adversary can gain access to the systems the employee uses daily for work, the adversary can likely enter the PCI zone the same way — like an authorized user, which is typically more difficult to detect.

The security design flaw is that the PCI zone trusts components inside the corporate zone. While that’s a simple statement to make, it’s often more difficult to determine within the complexity of all the moving pieces.

To be fair, that abusable trust relationship is, at its core, a policy violation and likely an indicator of non-compliance if discovered by an assessor (or, worst case, post-breach). But when testing is performed at the micro-level, with the PCI zone placed under the microscope, details may be missed that make the environment appear compliant and even safe. Assessors and security architects may make assumptions about how the technical components function.

Or perhaps that trust relationship between the corporate and PCI zone is a known issue, documented in a “compensating controls worksheet” as an accepted risk. An adversary may not know your compensating controls but will likely appreciate the avenue of attack.

Lastly, a penetration test is likely performed from a documented and whitelisted vantage point on the network. Maybe that means from a dedicated IP address that has certain firewall rules granting it additional access, but hopefully not. Or maybe it simply means that detection events generated from the pentester’s system are ignored as part of the whitelisting. Assumptions may be made (and perhaps codified in that compensating controls worksheet) that detection controls would detect that trust relationship abuse. In a red team scenario, which focuses on hyper-realism, no whitelisting would be performed (nor any advanced notice to the environment administrators), so the detection/response capabilities will come under scrutiny for efficacy as well.

Overall, it boils down to scope, time, and objectives. Red Teams have larger scope, more time, and typically very focused objectives: model an adversary who wants a specific thing (in this case, credit cards) with the intention of testing all security controls (prevention, detection and response). Traditional penetration tests, as mandated by compliance regulations, often have small scope, very limited time windows, and typically only test the efficacy of prevention controls, excluding detection/response.

Do both.