Even though companies spend hundreds of thousands of dollars on DDoS protection tools to secure websites and applications, many DDoS attacks succeed in bringing down systems and causing outages.
The problem is not with the protection software tools themselves (at least not with the known brands). Rather, there are three key reasons that DDoS attacks succeed.
Despite spending a fortune on mitigation technologies, most companies don’t test their mitigation even once to verify which attacks will be stopped. Often, the first time the DDoS protection software is put to the test is during a real attack.
This is quite strange since companies do run pen-testing every year to evaluate the security of their IT infrastructure. Possibly, SOC teams have too many security issues to handle, and installing the DDoS protection software seems enough to place a checkmark next to the DDoS item on the list.
Yet the reality is that DDoS mitigation/protection without DDoS testing is like developing software without any QA. You must simulate DDoS attacks to test your defense, identify configuration and optimization issues, and train your teams.
When you do run DDoS testing, you quickly discover that some attacks are stopped and others are not.
In most cases, it’s not that the protection software isn’t good enough, but rather that it’s lacking the right setup and configuration. When our Incident Response team arrives at companies to help with an attack, we often find the DDOS protection technologies still with factory settings.
While most DDoS solutions provide some out-of-the-box protection, there are many settings that must be configured. To protect an API you need a different configuration and setup than if you need to protect an e-commerce site. A CDN web protection component may have caching enabled for straightforward items like static PDF or image files. But if you want to harden your system and reduce the attack surface by caching HTML pages, you need to define the rule yourself.
Or, yet 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.
These are simple examples. Some of the DDoS settings required to defend networks and resources are much more complex and require DDoS knowledge and expertise.
The human factor is another reason for failure. Security, network, and SOC/NOC teams are not trained for DDoS and the lack of knowledge translates to a less effective response during an attack.
The security team, which is the most critical, often lacks the DDoS skills as to which attack vectors will be stopped by which component, and what is the war game plan for different attack scenarios. Also, SOC/NOC teams and network administrators lack the necessary knowledge to identify an attack and take the right actions to divert traffic.
When a DDoS attack takes place and teams lack knowledge, the discussion is too basic. Time is wasted with questions like “why didn’t our vendor stop the attack?” When DDoS knowledge exists, the conversation is much more pragmatic with questions such as “should we reduce the SYN protection threshold”, or “our defense is working well, but why are we getting false positives?”
DDoS skills and knowledge translate into a much shorter outage time during an attack.