Designing DDoS Mitigation Solutions for Simplicity and Speed

By Nikhil Taneja

A customer recently experienced a DDoS attack. Well, sort of. They thought they were under attack and were about to invoke the DDoS mitigation service, but instead waited because they were not 100% sure it was an attack; it could have been an outage.

Sounds familiar? If so, you are not alone. There are many DDoS mitigation solutions available in the marketplace, and most of them offer a dizzying array of choices. From on-premise to cloud, from in-line to out-of-path, from specialized point solutions to all-in-one integrated solutions, self-managed to fully managed, from single threaded to redundant with bypass, there are more permutations available than most customers can get their head around.

Navigating what is best for your infrastructure could be a seemingly endless exercise because your CISO might have different priorities than your security architect (who obviously thinks differently than your SOC manager does, who in turn cares about different things than the procurement person does). Building consensus can be tricky. And your vendor does not make it easy with six different price proposals which all look similar but have ever so slight variations, just enough to confuse you and your colleagues. You start thinking maybe you are best off living with whatever you already have in place from your current DDoS mitigation vendor, even though it does not really work.

Customers often over-design their DDoS mitigation solutions but an important question remains unaddressed- will it actually work for the organization? It would surely look good on paper – but does the company have the operational resources to pull it off?”

Most complex is not always the best

Usually, the more options you have in your design, the more complex your solution is going to be to operate. So that redundant on-premise box, that automatic threat feed, or that high capacity cloud scrubbing option you have all come with added complexity.

Conventional wisdom is that if you add automation or a fully managed element from your vendor, it becomes simpler. However, you are simply transferring the complexity to someone else who may or may not be equipped to make decisions for you, come crunch time. Unfortunately, no one in the market has both simplicity and completeness in the attack coverage, so you must decide what works best for your needs.

I am not saying complexity is bad, just that a complex DDoS mitigation solution is like a fighter jet, and you need well trained fighter pilots to operate it. Do not expect it to fly itself.

Dual Vendor Option might not be worth it

If you are a bank or a large financial institution, you likely have a dual vendor policy. What could go wrong here?! You have two DDoS mitigation vendors, so if one can’t stop an attack the other one should be able to… right?

Let’s just say that folks who came up with the dual vendor policy have never actually worked in the emergency department at a hospital. When you are under a DDoS attack, it is akin to having a heart attack and needing an emergency hospital visit. You want one hospital, one front desk, one team of doctors and nurses. Time and availability of a medical team is more critical than the equipment at hand. Similarly, you don’t buy two different medical insurance policies thinking in case you have a heart attack, one of them will come to your rescue. You must pick one policy, one primary care doctor and one hospital.

A DDoS mitigation solution is an emergency service and a single vendor solution is much more likely to detect, mitigate and handhold you through a DDoS attack.

Redundancy is Good, but covering all scenarios may be unnecessary

One of the key design aspects for DDoS mitigation is redundancy. Most customers are used to buying two on-premise DDoS mitigation appliances for their data center. Some also buy a bypass switch in case the devices fail. On top of this, some customers have a hybrid solution where they have the option of invoking the cloud DDoS service if the attack is a high volume one.

Given the key aspect of DDoS mitigation is accurate detection and fast mitigation, in some scenarios over designing the solution can lead to a lot of confusion when you are actually under attack. There is no one-size-fits-all, but if you have a lot of redundancy built in, you need to have accurate, handy documentation to go along with it. Otherwise, your team won’t really know which knobs to operate when you are under attack.

Report only vs. In-line Blocking

Some DDoS mitigation solutions come with the option of report only mode or out-of-path mode. The idea is that you get alerted when there is an attack, but you have the option to act on it after you have analyzed the attack.

This sounds great on paper, but I have never actually seen this concept work in action. Most of the time, if you are in report only mode, you don’t even come to know there was an attack. While there is some risk of false positives, you are better off being in blocking (or in-line) mode. Otherwise, what is the point of having a DDoS mitigation solution? It is like having access to a hospital in report only mode – yeah, just let me know if I had a heart attack.

Number of Security Policies

Whether it is an on-premise DDoS mitigation appliance, or a cloud-based service, you have a choice of designing your security policy in a manner as simple or as complex as you want it to be. Again, just because there are 100 doctors to choose from at the hospital, it doesn’t mean you want all of them at your disposal at the same time.

As a rule of thumb, it is best to have some sort of global security policy which is used as a catch-all, and 10-20 individual policies, each corresponding to a similar set of applications. This gives you the right balance between segregating your applications and keeping an intelligible set of policies which one can understand.

(The author is Managing Director-India, SAARC & Middle East, Radware and the views expressed in this article are his own)