Myth 1 . Total capacity indicates available mitigation resources
A simple network capacity number leaves out important details . Questions that need to be answered include : How much network capacity is dedicated for consuming attack traffic ? How many of the mitigation system ’ s resources are dedicated to stopping attacks ? How many of the network and system resources are available to deliver clean traffic to all customer origins on that platform ?
And capacity isn ’ t just limited to technology . At some point , if technologies are not working effectively or optimizing mitigation , what dedicated human capacity can be leveraged for escalations , handling incident response and finetuning mitigation ?
Tip : Look deeper into differences between a provider ’ s total network capacity and platform stability , capacity available for attack mitigation , and clean traffic delivery utilization .
Myth 2 . All time-to-mitigate SLAs are created equal
Time to mitigate should mean how quickly malicious traffic is stopped or blocked , without impacting legitimate traffic and users . It turns out that there ’ s a lot of room for interpretation . For example , one vendor might not consider a surge in traffic a DDoS attack until it has lasted at least five minutes . So the SLA timer may not start until you ’ re already five minutes into the attack . That means an advertised 10-second time to mitigate could really be five minutes or more . Other vendors define time to mitigate as how quickly a mitigation rule can be deployed . At the end of the day , what you care about is the time to get internet-facing assets back up and running . Be sure to carefully read the fine print for your vendor ’ s SLA .
Tip : Dig into the details of time to mitigate listed in an SLA . It should represent the equation : Time to Detect Attack + Time to Apply Mitigation Controls + Time to Block Attack + Quality of Mitigation = The Real Time to Stop the Attack . x