Exercise 3: Why Public Information Still Needs Explicit Scope Coverage — Possible Solution ==================================================================== WHY "IT'S PUBLIC" DOESN'T AUTOMATICALLY MEAN "IN SCOPE" ------------------------------ Per this chapter's own warn-box, "most OSINT is passive and deals only with publicly available information — but pentest1-2's own scope-precision lesson still applies here directly." pentest1-2 established that authorization and scope have to be defined precisely, in writing, rather than assumed from general context — and specifically warned that vague descriptions ("our website") can lead to testing systems the client never actually intended to authorize. The same underlying problem exists for OSINT: the fact that information about employees is technically publicly accessible doesn't tell you whether the CLIENT actually wants that research conducted, or considers it part of the engagement they're paying for and have authorized. THE CONCRETE RISK ------------------------------ Per this chapter, "some organizations explicitly exclude social-engineering-relevant recon (like enumerating specific employees) from an engagement, or don't want personal social media research conducted on their staff at all, even using only public information." An organization might be entirely comfortable authorizing technical testing of their web application, network, or DNS infrastructure, while genuinely not wanting a tester compiling a dossier on named individual employees — a legitimate, foreseeable preference that has nothing to do with whether the information itself happens to be public. WHY THIS MIRRORS PENTEST1-2'S OWN LESSON EXACTLY ------------------------------ pentest1-2 taught that scope has to specify precise boundaries rather than relying on general descriptions or assumptions about what's "obviously" included. Applying that same discipline here: the written scope agreement needs to explicitly state whether OSINT covering named employees and their public social media presence is included, in the same way it needs to state precise IP ranges and domains for technical testing. Relying on "it's public, so it must be fine" is exactly the kind of unstated assumption pentest1-2 warned produces real authorization problems. WHY THIS WORKS AS AN ANSWER ------------------------------ It directly connects this chapter's own warn-box to pentest1-2's scope-precision principle, and explains specifically why "the information is public" is not equivalent to "the client authorized gathering it" — mirroring the exact reasoning pentest1-2 applied to vague technical scope descriptions.