The right test for the right architecture.
This guide maps attack categories to the mitigation solutions designed to stop them. We use this knowledge to ensure every test we recommend produces actionable results, not just impressive traffic numbers.
Our Testing Philosophy
Not every test makes sense for every architecture.
A volumetric L3/4 flood against an on-premise firewall that was never designed to absorb multi-gigabit traffic will fail every time. That failure tells you nothing you didn't already know. Running an L7 Slowloris attack against a network-layer scrubbing center won't prove anything either, because application-layer connection behavior is not what network scrubbing is built to catch.
We guide every customer toward tests that are relevant to their actual mitigation stack. If a test wouldn't produce actionable insight, we'll say so and recommend what would. The goal is to find real gaps, not to generate impressive-looking traffic numbers that don't map to meaningful risk.
This is advisory, not restrictive. The platform will flag tests that are unlikely to produce useful results given your stated architecture, and it will explain why and suggest alternatives. But you always have final say. If you want to run a test we've flagged, you can.
Attack-to-Defense Mapping
Which defenses stop which attacks.
Each mitigation solution category has strengths, limitations, and attack vectors it was never designed to handle. Understanding these boundaries is the foundation of effective testing.
Cloud-Based DDoS Scrubbing
Upstream scrubbing centers, transit-based protection
Designed for
- Volumetric L3/4 floods (SYN, UDP, ICMP)
- Amplification and reflection attacks
- Protocol abuse and fragmentation
Strengths
- Massive absorption capacity (multi-Tbps)
- BGP or DNS-based traffic diversion
- Can handle multi-hundred-Gbps floods
Not designed for
- Application-layer attacks that mimic legitimate HTTP traffic
- Attacks that bypass the scrubbing path entirely (direct-to-origin)
CDN / Edge-Based DDoS Protection
CDN providers with integrated DDoS mitigation
Designed for
- L3/4 volumetric at the edge
- L7 HTTP floods, cache busting
- TLS exhaustion attacks
Strengths
- Global PoP distribution absorbs traffic near source
- Integrated WAF rules and challenge pages
- Bot detection and behavioral analysis
Not designed for
- Attacks against non-HTTP services
- Direct-to-origin attacks that bypass the CDN
- Infrastructure not proxied through the CDN
Web Application Firewalls (WAF)
Application-layer inspection and filtering
Designed for
- Slowloris, RUDY, low-and-slow attacks
- HTTP GET/POST floods, API abuse
- Credential stuffing under load
Strengths
- Deep packet inspection at the application layer
- Request-rate limiting and behavioral analysis
- Custom rule sets tuned to application logic
Not designed for
- Volumetric L3/4 floods (WAF is overwhelmed before it can inspect)
- Protocol-layer attacks below HTTP
On-Premise / Hardware DDoS Appliances
Inline or out-of-band hardware mitigation
Designed for
- L3/4 protocol anomalies
- Small-to-mid-scale volumetric floods within rated capacity
Strengths
- Low latency, full traffic visibility
- No dependency on third-party routing
- Complete control over mitigation behavior
Limitations
- Throughput capped by hardware and upstream link capacity
- Volumetric floods exceeding upstream bandwidth never reach the appliance
- Testing must be scoped to rated capacity for meaningful results
DNS-Specific DDoS Protection
Purpose-built for DNS infrastructure defense
Designed for
- DNS query floods
- NXDOMAIN and random-subdomain attacks
- DNS amplification targeting authoritative servers
Strengths
- Purpose-built for DNS traffic patterns
- Response rate limiting (RRL)
- Query filtering and classification
Not designed for
- Non-DNS attack vectors
- Only relevant when DNS infrastructure is the target
ISP / Transit Provider Filtering
Upstream network-level mitigation
Designed for
- Basic volumetric mitigation via ACLs
- Blackhole routing (RTBH), Flowspec rules
Strengths
- Stops traffic upstream before it reaches customer infrastructure
- Can absorb very large volumetric floods at the network edge
Limitations
- Coarse-grained: blackhole drops all traffic to the IP, not just attack traffic
- No application-layer awareness
- Useful as first/last resort, not a substitute for application-aware protection
How This Informs Our Recommendations
We use this to guide you, not to gatekeep.
During test configuration, the platform asks about your mitigation architecture and uses this mapping to recommend attack scenarios that will produce meaningful results. If you select a test that's unlikely to be useful given your setup, the platform explains why and suggests alternatives. But the final call is always yours.
Architecture-aware configuration
Tell the platform what mitigation you use, and it recommends tests that target the right layers
Mismatch flagging
If a selected test won't produce useful results for your architecture, you'll see a clear explanation
Contextualized reporting
Results are framed against the expected capabilities of the mitigation layer being tested
Customer has final say
Recommendations are advisory. You can override any suggestion and run the test you want.
Ready to test what your defenses actually stop?
We'll help you choose the right tests for your architecture and produce results that matter for your security program.