Exercise 3: Why Scan Intensity and Timing Belong in Written Scope — Possible Solution
====================================================================

THE CHAPTER'S OWN WARN-BOX
------------------------------
Per this chapter, "a fast, aggressive scan isn't just 'loud' in a
logging sense — against fragile or legacy systems (older embedded
devices, industrial control systems, some IoT hardware), an
aggressive scan has genuinely crashed real production equipment in
documented real-world cases."

THE CONCRETE EXAMPLE OF WHAT COULD GO WRONG
------------------------------
Imagine a Network-scoped engagement (per pentest1-2's own scope
categories) that includes a corporate network segment where, unknown
to the tester, an older industrial control system or a legacy piece
of embedded hardware is also present — perhaps a building's HVAC
controller, or a piece of manufacturing equipment with an embedded
network interface never designed with modern scanning tools in mind.
If the tester runs a fast, aggressive port scan across the full IP
range without any restriction on intensity, that fragile device could
genuinely crash or become unresponsive — not because of any
deliberate exploitation attempt, but purely from the volume and speed
of scan traffic hitting a system that was never built to handle it.
If that device controls something physically important (climate
control, manufacturing equipment, safety systems), a scan-induced
crash could cause real operational harm — a direct violation of the
"no real damage" principle this course's own Ch.1 material implies
and Ch.7 will formalize.

WHY THIS BELONGS IN WRITTEN SCOPE SPECIFICALLY
------------------------------
This is exactly why pentest1-2 required scope to be precise and
written rather than assumed. It's not enough to say a network range
is "in scope" — the written agreement should also specify, where
relevant, acceptable scan intensity, timing windows, and any known
fragile systems the client wants tested more carefully or excluded
entirely. Without that detail spelled out in advance, a technically
authorized scan (the IP range itself was in scope) could still cause
real, unintended harm the client never anticipated when they granted
authorization.

WHY THIS WORKS AS AN ANSWER
------------------------------
It builds a concrete, plausible scenario directly from the chapter's
own named risk categories (industrial control systems, embedded
devices), explains the real potential consequence, and ties the
solution back to pentest1-2's own written-scope-precision principle
rather than treating this as a purely technical concern.