Exercise 3: What Written Authorization Does and Doesn't Cover — Possible Solution ==================================================================== WHY AUTHORIZATION ISN'T A BLANKET PERMISSION ------------------------------ Per this chapter's own warn-box, "even with written authorization from pentest1-1, causing unnecessary damage beyond what's needed to prove a vulnerability can still expose a tester to real liability." pentest1-1 established that written authorization is the single non-negotiable precondition before any testing can happen at all — but this chapter clarifies that authorization has its own internal scope, just as pentest1-2 required written SCOPE to specify precise systems rather than vague descriptions. Authorization for "testing" does not automatically extend to cover every possible action a tester could technically perform once inside a system. WHAT AUTHORIZATION TYPICALLY COVERS ------------------------------ Per this chapter, "a Rules of Engagement document typically authorizes testing." This means the RoE grants permission to actively probe for, and demonstrate the existence of, vulnerabilities within the agreed scope (per pentest1-2) — including proof-of-concept-level exploitation sufficient to confirm a candidate is real, per this chapter's own described PoC standard. WHAT AUTHORIZATION TYPICALLY DOES NOT COVER ------------------------------ Per this chapter, an RoE is not authorization for "unrestricted destruction, data exfiltration, or service disruption," and "often explicitly limits what's permitted (no data destruction, no denial-of-service, no touching real customer data beyond a single proof record)." In other words, the fact that a system was in scope for testing doesn't mean every possible action against that system — deleting data, taking a service offline, exfiltrating an entire database — was authorized. Those actions go beyond "testing" into causing real, avoidable harm, which is precisely the line this chapter's own Proof-of-Concept vs. Full Exploitation section draws. THE PRACTICAL CONSEQUENCE ------------------------------ A tester who technically stayed within the SCOPE (the right systems, per pentest1-2) but went beyond what the authorization actually covers (causing unnecessary damage, per this chapter) can still be exposed to liability — being "in scope" and being "authorized to do this specific thing" are not the same question, and a tester needs to respect both. WHY THIS WORKS AS AN ANSWER ------------------------------ It distinguishes what the RoE grants (testing, including PoC-level exploitation) from what it withholds (unrestricted damage), using the chapter's own explicit wording, and explains why staying in scope alone isn't sufficient if the specific ACTION taken exceeds what "testing" was ever meant to authorize.