Exercise 3: Least Privilege as Damage Limitation in the Capital One Breach — Possible Solution
====================================================================

In the real 2019 Capital One breach, the attacker exploited a
misconfigured web application firewall to gain access to data at
scale -- the entry point itself was the WAF misconfiguration, which
least privilege on its own would not have prevented. The relevant
question is what happened AFTER that initial access was gained: how
much could the compromised web application's own permissions actually
reach.

If the compromised application had been granted only the specific,
narrow permissions it genuinely needed for its real job -- rather
than broad, standing access to far more data than that one
application actually required -- then even a successful exploit of
the WAF would have given the attacker access to only that narrow
slice, not to the very large, real dataset that was actually exposed.

ANSWER: Least privilege would not have prevented the initial WAF
misconfiguration from being exploited, but it would have directly
limited the real BLAST RADIUS once that exploit succeeded -- the
compromised application's own permissions define the ceiling on what
an attacker who gets in through it can actually reach, and a tightly
scoped ceiling means a real breach of this kind would have exposed far
less data, even with the exact same initial vulnerability.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly separates two distinct real security questions --
"how did the attacker get in" (the WAF misconfiguration, not fixed by
IAM) versus "how much could they reach once in" (directly shaped by
IAM permissions and least privilege) -- rather than claiming least
privilege alone would have prevented the breach outright, which the
chapter's own real, documented account does not support.