Even though companies spend hundreds of thousands of dollars on DDoS protection solutions to secure websites and applications, many attacks still succeed in bringing down systems and causing outages.
Having provided emergency mitigation assistance to dozens of companies experiencing DDoS attacks, I have seen protection fail despite the existence of the appropriate mitigation technology. There are three key reasons, in my opinion, why DDoS protection fails.
No DDoS Testing/Simulation
Despite spending a fortune on mitigation technologies, many companies don’t test their mitigation measures to verify that even basic DDoS attacks, such as SYN flood or UDP flood, can be stopped. Often, the first time the DDoS protection software is put to the test is during an actual, live attack.
This is a bit odd since companies run pen-testing every year to validate the overall security of their IT infrastructure. Possibly, SOC teams have too many tasks on their hands, and simply installing the DDoS protection software seems enough to place a checkmark next to the DDoS item on their to-do list.
In reality, DDoS mitigation without testing is like deploying software without any QA. After running hundreds of DDoS tests, I’m convinced that you cannot trust a protection system until it has been tested. I have found both common and bizarre issues that have prevented mitigation. You need to simulate DDoS attacks to test your defense, identify configuration issues and train your teams.
Underutilized/Suboptimized Protection Technology
Once you run DDoS testing, you quickly discover that some attacks can be stopped while others cannot.
In most cases, it’s not that the protection technology isn’t good enough, but it’s lacking the proper setup and configuration. When our incident response team arrives to help companies under attack, we often find the DDOS protection technology still using factory settings.
While most DDoS solutions provide some out-of-the-box protection, many settings must be configured. To protect an API, you will need a different configuration and setup than to protect a commercial site. For example, a CDN web-protection component may have caching enabled for straightforward items such as static PDF or image files. Still, if you want to strengthen your system and reduce the attackable surface by caching HTML pages, you need to define the rules yourself.
For another example, assume you’re a gaming company in the Caribbean. Your DDoS protection settings will depend on your target customers. You might enable GEO protection if only residents can gamble on your site, but you’ll need a different setting if your customers are global.
Teams Are Not Trained
The human factor is another reason why DDoS protection fails. At most companies (including large organizations such as banks and insurance companies), security, network and SOC/NOC teams are not trained to deal with DDoS. This lack of knowledge translates to a less-effective response during an attack.
Security team members often don’t know which component or setting in their system should be used to mitigate a specific attack vector. Similarly, SOC/NOC teams and network administrators may lack the necessary knowledge to identify an attack and take the right action, such as promptly diverting traffic to the scrubbing center as soon as the attack starts. From a wider, cross-team point of view, companies often don’t have a set of procedures and a game plan for efficiently responding to a DDoS attack.
When a DDoS attack occurs and teams lack knowledge, the discussion is too basic. Time is wasted on questions such as “Why didn’t our [vendor name] stop the attack?” On the other hand, when teams are trained and skilled, the conversation is much more pragmatic, with questions such as “Should we reduce the SYN protection threshold” and “Our defense is mitigating well, but why are we getting false positives?”
In short, improved DDoS skills and knowledge translate into the effects of an attack being mitigated much more quickly.
