Is Your DDoS Cloud Signaling Just Blowing Smoke?

Many DDoS mitigation service providers claim to have cloud ‘signaling’ capabilities between on-prem detection and cloud scrubbing centers. In practice, many of these marketing claims only pay a lip-service to true hybrid signaling. These three questions will help you assess whether your cloud signaling is just blowing smoke.

More and more organizations today are adopting a hybrid DDoS mitigation approach which combines both on-prem DDoS appliances with cloud DDoS mitigation capabilities. A hybrid DDoS approach takes a best-of-both worlds approach, combining the immediate response times of premise-based devices, with the capacity and flexibility of cloud services.

One of the key ingredients of an effective hybrid DDoS strategy is seamless messaging between on-prem and cloud defenses, to effectively communicate when an attack occurs and smoothly hand off mitigation to the cloud, before pipe saturation occurs.

Many DDoS mitigation vendors advertise their cloud signaling, which they claim integrate different layers of DDoS protection. However, all-too-frequently, these ‘signaling’ capabilities provide only a rudimentary interface, which does not provide effective protection.

So what should you look for in order to distinguish cloud ‘smoke signaling’ from true hybrid messaging?

[You might also like: Protecting the Multi-CDN Part I: The Security Challenge of Multi-CDN]

Three questions to ask from your cloud DDoS provider:

1. Does it include non-volumetric attack detection?

The first question customers should ask of their DDoS protection providers is does their cloud signaling support non-volumetric detection, or is detection based merely on volumetric traffic rates?

Most DDoS protection vendors detect volumetric attacks using NetFlow forwarding or SNMP traps, based on preset, manually defined traffic thresholds. Once traffic levels hit a certain level (usually defined according to Packets-Per-Second), they trigger their cloud ‘signaling’ to notify cloud scrubbing centers of the attack, and initiate diversion to the cloud using BGP redirection.

However, this approach provides only partial coverage, as it leaves customers exposed to attacks which initially begin as non-volumetric in nature:

• One class of such attacks is Low-&-Slow attacks, which – as their name implies – begin by “flying under the radar” and then quickly overwhelming server resources.
• A second class of attacks is application-layer attacks such as HTTP floods, SSL-based DDoS attacks, or DNS floods, which can come in very quickly before the NetFlow statistics have time to adjust.
• A third class of such attacks is zero-day DDoS attacks, which do not conform to known attack signatures. If no signature exists, then DDoS cloud services will not know how to mitigate the attack.

In order to protect against such exposure, customers must make sure that detection is based not just on volumetric traffic thresholds, but also on behavior-based DDoS attack detection using behavior-based traffic analysis. This will not only identify attacks and pre-empt diversion before server resources are overwhelmed or pipe saturation occurs, but will also provide protection in case of zero-day DDoS attacks, which do not have a known signature.

2. Does it transfer attack footprints?

The second question for customers to ask, is once mitigation to the cloud is complete – what happens next? Does their cloud signaling transmit attack footprint information, or will mitigation have to restart once the cloud scrubbing centers kick in?

True hybrid messaging requires that attack footprints be transmitted from premise-based detection to cloud scrubbing centers. Attack footprint details include traffic baseline information (i.e., what traffic looks like when there is no attack) and attack footprint information such as attack sources, pattern signatures, and statistical traffic analysis.

Effective hybrid messaging enables mitigation to be handed-off seamlessly from premise-based device to the cloud. This way, once diversion to the cloud is complete, the scrubbing centers will automatically receive all relevant detection information, and can begin mitigation without interruption.

However, cloud ‘smoke’ signaling does none of that. Rather, it just alerts cloud scrubbing centers that an attack is going on, and initiates diversion. As a result, once diversion is complete, the detection and mitigation process must start all over again, delaying mitigation and leaving customers exposed in the interim.

In order to minimize exposure windows, customers should insist that their cloud messaging include transmission of detailed attack information, so that cloud mitigation can kick in immediately and without delay.

3. What are the SLA commitments?

Finally, an effective way of telling how confident your vendor is in their own ‘signaling’ technology is to ask what they are willing to commit to in the SLA.

Most cloud DDoS vendors provide Time-to-Mitigate SLAs. However, the key question to ask in this case is mitigation starting when?

Effective hybrid signaling should include commitments to two key SLA metrics to minimize exposure windows: Time-to-Detect and Time-to-Divert.

• Time-to-Detect SLAs commit to the time period to detect DDoS attacks. This is particularly important in the case of non-volumetric attack detection (which haven’t yet reached the volumetric threshold to begin diversion) and in the case of zero-day DDoS attacks, for which no known signature exists. The Time-to-Detect SLA ensures vendor commitment to timely DDoS attack detection even when pipe saturation is yet to occur, as well as in case of zero-day attacks.
• Time-to-Divert SLAs commit to the time period it takes to initiate diversion once an attack has been detected. Again, initiating timely diversion is crucial in-order to quickly hand off mitigation to the cloud before pipe saturation occurs.

[You might also like: Protecting the Multi-CDN Part II: Approaches for Securing the Multi-CDN]

In addition, you should enquire whether your SLA commitments are provided in bulk (i.e., as a single number, end-to-end), or whether your vendor is willing to commit to each SLA promise individually.

If your DDoS provider is not willing to provide those SLA commitments, that is a highly telling sign about your vendor’s lack of confidence in their own product, and what you might be exposed to as a result.

Asking your vendor about it

Implementing a hybrid DDoS attack prevention strategy is not a one-and-done endeavor. Rather, it is a consistent effort to make sure that premise-based and cloud-based defensive layers are aligned and synchronized so as to prevent any cracks in defense and minimize exposure windows.

Use these questions above to ascertain whether your DDoS mitigation vendor is willing to commit to this level of effort, or are they just blowing smoke.