On-Sale Under Fire: Volumetric, Bot, and Checkout Friction
An online ticketing platform expects 180,000 concurrent users for a concert on-sale in 72 hours. Last year a 400 Gbps UDP flood and a 1.2M-request-per-minute credential-stuffing wave disrupted checkout for 40 minutes. The WAF is in blocking mode with 38 custom rules; bot management is in monitor mode for the mobile app, whose API clients use certificate pinning and cannot run JavaScript challenges. A marketing promotion allows coupon codes containing apostrophes and hyphens, and the WAF's SQLi signature set has produced 6,000 false positives on coupon redemption in the last month. The mobile team refuses a forced app update before the sale. Operations has 2 BIG-IP platforms: one on-prem with 40 Gbps links and one scrubbing provider with a 300 Gbps capacity. The CEO wants 'no blocking of real fans' and the fraud team wants 'all automated traffic blocked'.
1. Rank and sequence the controls you would change in the next 72 hours across DDoS, WAF, bot management, and account takeover. Justify what you would not do.
Read the worked answer
Separate the problems because the controls and failure modes differ.
- Volumetric: confirm every public prefix is diverted to the 300 Gbps scrubbing provider, with on-prem 40 Gbps links for clean traffic and a tested direct-to-origin path. Pre-position flowspec or RTBH only for clearly spoofed UDP, and ensure health checks do not mark the site down. Do not rely on the BIG-IP alone for 400 Gbps.
- Application-layer DDoS: enable rate limits and slow-client protections for login, search, and checkout; use a virtual waiting room for the on-sale if available. Protect the origin from cache-busting with CDN rules.
- WAF: before adding bot blocking, remove the 6,000 coupon false positives. Do not disable the SQLi signature set or exclude the whole endpoint. Create parameter-specific validation for the coupon field (length, allowed characters, server-side lookup) and a narrow exclusion only for the verified benign pattern. Keep the rest of the signature set in blocking. Replay a corpus of malicious and benign requests.
- Bot and ATO: mobile clients cannot do JavaScript challenges, so use channel-appropriate signals: per-session and per-account rate limits, device and behavioral signals, breached-credential checks, progressive MFA on risky logins, and blocking only high-confidence signatures such as known bad ASNs or impossible velocity. Do not globally block all automation; that breaks monitoring, accessibility tools, and partner integrations. Keep bot management in monitor for the mobile API except for a narrow high-confidence deny list, and review hourly.
The CEO's 'no blocking of real fans' and fraud's 'block all automation' are reconciled by risk tiers: allow, challenge or step-up, throttle, block. Only the block tier is narrow and evidence-based.
2. How do you reduce coupon false positives without weakening SQLi protection, and how do you validate before the sale?
Read the worked answer
First locate the false positives precisely: which rule IDs, which URI, which parameter, and which payloads. A coupon containing an apostrophe should not look like SQL injection if the application validates it; the WAF is compensating for weak input validation. Build a positive validation rule for the coupon parameter: maximum length, allowed character class, and a server-side check that the code exists. Then add a narrow exclusion that applies only to that parameter and only to the benign pattern, not to the whole endpoint or the SQLi signature category. Keep a virtual patch for any actual injection pattern.
Validation: assemble a test corpus with the 100 most common benign coupon values, including apostrophes and hyphens, plus SQLi, XSS, and encoded variants. Run it in staging with the proposed policy and compare block/allow decisions against expected labels. Then run in production in monitor mode for a few hours during low traffic, review every block, and only then enforce. Monitor false-positive rate per rule, checkout conversion, 403/406 rates, and support tickets. Rollback is disabling the narrow exclusion, not the WAF.
Do not solve this by lowering paranoia level globally or turning off SQLi signatures; that trades a visible conversion problem for an invisible injection exposure. Fix the application validation after the event so the WAF exception can be removed.
3. Define the bot-versus-human decision policy and rollback triggers for the event, including metrics and ownership.
Read the worked answer
Decision policy: tier 0 known-good (authenticated, consistent device, normal velocity) allow; tier 1 suspicious (new device, datacenter ASN, elevated velocity) challenge with low-friction proof or step-up MFA; tier 2 high-confidence automated (known bot signature, many accounts per device, credential-stuffing pattern) throttle or block; tier 3 manual review for ambiguous high-value cases. Every block needs an accessible path to human support, and accessibility and partner traffic must be explicitly allowlisted.
Metrics and rollback triggers: checkout completion rate versus baseline; WAF false-positive rate by rule; challenge solve rate; login success after challenge; ATO rate and account lockouts; origin latency and 5xx; queue depth. Roll back bot blocking if false-positive rate exceeds an agreed threshold such as 0.5% of checkout sessions, conversion drops more than 2% for 10 minutes, challenge solve rate falls below 90%, or support queues spike. Roll back WAF changes if any benign coupon is blocked in the canary.
Ownership: security owns WAF and bot policy, operations owns traffic and capacity, fraud owns ATO thresholds, and one incident commander can override. Publish a one-page runbook with named approvers and a 15-minute review cadence during the sale. Post-event, compare blocked versus allowed traffic and convert emergency rules into tested, parameter-specific policies.