SG/Sentinel Tabletop Simulation Part 2: Blocking Malicious Activity
Summary
The attack half: an obvious-bad probe, a WordPress scan, a brute-force on a valid login endpoint, a fast-tracked user turning malicious, a slow patient probe from rotating IPs, and an in-profile exploit — fourteen gaps, seven major. The consequential cluster: fast-track must never skip authorisation (9.1/9.2, the fundamental redesign); per-IP is insufficient against distributed attacks (8.2/10.3, multi-dimensional evidence keying); Sentinel is blind to auth outcomes without a reverse coupling from the app (8.3); and no-invalid-request is necessary but not sufficient — in-profile exploits need content rules and, ultimately, a secure application (11.1/11.2, the honest limit).
Key concepts
- Fast-track redesigned — the gap that changed the architecture — told in full on the research page
- Per-IP insufficiency — residential proxies defeat per-source limits; key per target too
- The honest limit — defence in depth, not sole defence — stated as a design output, not a caveat
Key ideas
- The one positive finding: no-invalid-request beats slow distributed probing by construction — every out-of-profile request is blocked individually, regardless of rate or rotation.
- "Drop silently" is not a thing HTTP can do — block actions needed concrete HTTP-level definitions (GAP 6.1 → drop_403 / deflect_404).
- The gaps were found on paper, not in production — the entire value of the exercise.
On this site
Second half of the tabletop section; GAP 6.1's HTTP-level actions ship in the MVP as the action enum.