Types of penetration tests and when to choose which

The axes are independent and combine. An internal gray-box infrastructure test and an external black-box application test are both legitimate briefs; they just answer different questions. The easiest mix-up is between the subject of the test and the tester’s position, that is, what is tested versus where you start from.

At least one of these axes doesn’t rest on our experience alone. The split into external and internal testing has its own chapter in the Technical Guide to Information Security Testing and Assessment, NIST SP 800-115 from 2008, and the publication defines it the same way we use it: external testing is conducted from outside the security perimeter, internal testing from inside. The document doesn’t sort by subject or by the tester’s knowledge; it sorts techniques by what they do. The publication has been neither withdrawn nor superseded, but it is 18 years old and it shows: the appendix on tools rests on the live distributions BackTrack and Knoppix STD, which stopped being developed long ago.

Of the three axes, the subject is the most visible. It determines what expertise the tester needs: an application test rests on knowledge of web technologies and authorization, a network test on knowledge of operating systems, directory services, and network devices.

• Web applications and their APIs, that is, applications and interfaces reachable from a browser.
• Infrastructure, that is, the environment the applications run on.
• Cloud environments, that is, accounts, roles, and configuration at the provider.
• People and how they react to a fraudulent message or phone call.
• Physical premises, access systems, and who the security guards let in.

In the last two categories the subject is behavior, not technology. Tests aimed at people work with scenarios aimed at people, not servers; the physical layer checks premises, doors, and the people at reception.

Beyond these, mobile applications, Wi-Fi networks, and industrial control systems (OT/ICS) are disciplines of their own, which we run as a separate mobile application test, a separate Wi-Fi test, and a separate OT/ICS test. Each has its own tools and its own methodology, so there is no point ordering them as an add-on to a web test. Desktop applications are a discipline of their own too. We don’t offer them, so it’s worth asking a vendor whether they do them at all.

An external test simulates an attacker on the internet who knows nothing about the company and starts from the domain. An internal test simulates an attacker who is already inside, typically through an employee who opened an attachment. They answer two different questions, and the result of one says nothing about the other.

If you’ve never had a test done, there is a reason to start with the external perimeter. It’s cheaper, the findings get fixed faster, and the result is easy to explain to management. The internal test is the less comfortable one, because it answers what happens after a single compromised workstation, and there it comes down to privileges in the domain. Starting from an already compromised position has its own name: assume breach.

Black box means the tester gets nothing but the target address; gray box means they get accounts and a basic description of the environment; white box means they also get the source code or the configuration. The difference isn’t in the tester’s skill but in how much time goes to reconnaissance instead of finding flaws.

For a network, moreover, the words mean something different than for an application, because it’s about knowledge of the topology, not source code. What each of the three variants reveals and what it wastes is covered in detail in a separate entry.

Red teaming isn’t a type of penetration test; it’s a different discipline. A penetration test looks for as many vulnerabilities as possible within a defined scope, and the defenders know about it. A red team goes after one agreed objective, runs covertly, and measures whether anyone notices. Who is who in an exercise like that is described by the roles of the attacking and defending teams.

It’s easy to confuse the two, because both end with a report on how far the attacker got. The difference in objective, duration, scope, and what the company gets out of it is covered in our comparison of red teaming with a classic penetration test.

The table is a shortcut, not a decision. Once you pick a row, the choice of position and level of knowledge is still ahead of you, because only the three together determine the scope and therefore the price.

Types can be combined, and for companies just starting out it pays to go step by step. The usual sequence is the external perimeter, then the application with sensitive data, then the internal network. Each step makes the next one cheaper, because flaws that would otherwise eat the tester’s time get fixed.

Combining everything at once makes sense only where there is a firm deadline, typically before certification or before launching a new service. An overview of what a penetration test means in general helps more when you’re writing an inquiry than a list of types does.