Engagement Types & Scoping

Penetration Testing Methodology

Chapter 2 · Engagement Types & Scoping

pentest1-1 established that written authorization has to exist before anything else happens. This chapter covers what that authorization actually has to specify: what kind of test is being run, and — with real, sobering stakes — exactly what is and isn't in bounds.

Black Box, White Box, and Gray Box Testing

How much internal knowledge the tester starts with is itself a deliberate, negotiated choice:

	Starting knowledge	Realism	Thoroughness in a fixed timeframe
Black Box	None — no source, no architecture, no credentials	Highest — matches a real outside attacker	Lower — significant time spent just on recon
White Box	Full — source code, architecture docs, often credentials	Lowest — real attackers rarely start this informed	Highest — depth possible in the same time window
Gray Box	Partial — e.g. a standard user account, no source/admin access	Moderate — a genuinely common real starting position (a leaked credential, an insider)	Moderate-to-high — the most common practical compromise

Gray Box is often the practical default for real engagements — it balances realism against making efficient use of a genuinely limited testing budget and timeframe.

Internal vs. External Engagements

External engagements test from outside the organization's own network, simulating an internet-based attacker — this is the threat model most of this site's own web-application-focused courses (xss1, csrf1, sqli1) already assume. Internal engagements test from inside the network instead, simulating a compromised internal machine, a phishing victim's own foothold, or a malicious insider — a genuinely different threat model, and a direct real-world instance of dbsec1-1's own insider-threat material: someone who already has legitimate network access, tested from that exact starting position.

Scope Categories — What's Actually Being Tested

Network — infrastructure-level testing: servers, firewalls, network segmentation.
Web Application — the specific vulnerability classes this site already teaches in depth (xss1, csrf1, sqli1, bc1) — the direct technical grounding pentest1-6 formally names as this course's own "toolkit."
Wireless — Wi-Fi security testing, a genuinely distinct technical domain this course names but doesn't cover in depth.
Social Engineering — phishing simulations, pretexting: testing people, not systems — a fundamentally different attack surface than anything else in this list.
Physical — testing whether someone can physically walk into a facility or server room — easy to overlook, and a real, named category in almost every professional methodology.

Why Scope Must Be Precise, in Writing

Vague scope isn't just an inefficiency — it's a real legal risk, directly extending pentest1-1's own authorization material.

Shared infrastructure can quietly break authorization entirely

A client can genuinely, sincerely authorize testing of "our website" without realizing that website sits on shared hosting, behind a third-party CDN, or inside a cloud environment where other systems — belonging to other organizations entirely — share the same infrastructure. Testing that goes even slightly beyond what the client actually owns and controls can mean the tester has unknowingly committed genuinely unauthorized access against a completely different organization, even though the client believed, in good faith, that they were authorizing it. This is exactly why scope has to specify precise IP ranges, exact domains, and explicit exclusions ("the payment processing system, though reachable from the same network, is out of scope") — not general descriptions like "our website" or "our network."

Web Application scope is where this course reconnects with the rest of the site

pentest1-6 comes back to the Web Application scope category specifically, naming the site's own existing XSS/CSRF/SQLi/Auth courses as the concrete vulnerability-class knowledge a real web-app-scoped engagement actually draws on.

Hands-On Exercises

Exercise 1

A client wants the most realistic possible simulation of an external attacker and has a generous multi-week testing window. Using this chapter's own comparison table, which of Black Box, White Box, or Gray Box best fits, and why?

📄 View solution

Exercise 2

Explain the real difference between an external and an internal engagement, and explain specifically how an internal engagement connects to dbsec1-1's own insider-threat material.

📄 View solution

Exercise 3

Using this chapter's own warn-box, explain how a client sincerely authorizing "testing of our website" could still result in genuinely unauthorized access to a different organization's systems, and explain what specific scoping detail would have prevented it.

📄 View solution

Chapter 2 Quick Reference

Black Box — no starting knowledge, most realistic, least thorough per unit time · White Box — full knowledge, most thorough, least realistic · Gray Box — partial knowledge, the common practical compromise
External — tested from outside the network, matching xss1/csrf1/sqli1's own threat model · Internal — tested from inside, a real instance of dbsec1-1's own insider-threat material
Five scope categories: Network, Web Application, Wireless, Social Engineering, Physical — testing infrastructure, code, radio, people, and buildings respectively
Vague scope is a real legal risk, not just an inefficiency — shared/third-party infrastructure can turn sincerely-authorized testing into genuinely unauthorized access
Scope must specify precise IP ranges, exact domains, and explicit exclusions — not general descriptions
Next chapter: Standard Methodology Frameworks — PTES, the OWASP Testing Guide, and NIST SP 800-115