Any thoracic surgeon will tell you that implanting a pacemaker is never complete before its settings have been thoroughly validated. A patient is only discharged from hospital once the pacemaker’s configurations have been optimized for the patient’s comfort and physical security.
Discharging a patient without validating the pacemaker’s settings is unthinkable.
In the Cyber Security world, however, the DDoS mitigation equivalent to discharging patients without validating optimal device configuration is common practice. Companies invest heavily in DDoS mitigation devices that are installed without vendors fully testing that their settings are optimized, at least on a basic level.
One could argue this analogy is somewhat artificial, but the bottom line in both cases is similar: potential cardiac arrest for the patient, and system failure or “downtime” for the network.
We are seeing it all the time.
Having completed hundreds of controlled DDoS tests designed to simulate DDoS attacks in the wild – we seldom come across companies with well configured DDoS mitigation systems. An overwhelming majority of companies fail our BaseLine DDoS test, which is a test that any properly configured DDoS mitigation device should sustain without any manual intervention.
Instead networks are falling like flies.
We see that whether we are testing major e-Commerce companies or Fortune 50 financial institutions, which in some cases have extensive (and expensive) DDoS mitigation apparatus deployed, they are often still vulnerable with a very low threshold. Most of the failure reasons during testing are due to mis-configured perimeter devices, misguided assumptions of their ISP’s or scrubbing center protection or some other technical assumption with a combination of the two.
Most of the companies we work with have extensive DDoS mitigation systems in place and in most cases the technology is sufficient however for whatever reason it was not configured/deployed correctly.
CIOs & CISOs are finding out the hard way that the DDoS mitigation devices they fought for, are as leaky as a sieve because they were never optimally configured to meet their network’s particular characteristics.
To understand why DDoS mitigation isn’t ‘plug and play’ have a look at what a typical DDoS mitigation posture may look like in Figure 1.
Figure 1: Example of Typical DDoS Mitigation Posture
While some devices are able to provide certain levels of protection against DDoS such as WAFs, Routers & Firewalls, they were never intended to be DDoS mitigation systems. A dedicated DDoS mitigation is needed and is broadly divided into two main groups:
(i) Cloud Based: such as a Scrubbing Center with or without a Content Distribution Network (CDN), and
(ii) Customer-Premises Equipment (CPE): Internally installed network devices.
DDoS attacks aim to saturate a networks’ capacity by bombarding it with data packets that belong to a number of “Attack Layers”. For example: Network Layer 3 attacks use ICMP packets, Transport Layer 4 attacks use UDP packets or infamous SYN Floods and Application Layer 7 attacks use HTTP, FTP & SMTP packets such as LOIC (Low Orbit Iron Cannon).
Looking back at the network environment depicted in Figure 1, when installing DDoS mitigation devices vendors must take into consideration the entire chain of devices installed both up-stream from the device (towards the cloud) and down-stream (towards the networks servers) and fine tune the DDoS mitigation device accordingly. For example a vendor installing the DDoS mitigation device in the environment depicted in Figure 1 can assume that Layer 4 DDoS traffic will be mitigated by the scrubbing center thus optimizing the device for Layer 7 attacks. I.e. relying on the cloud for volumetric based attacks and mitigating Layer 7 attacks with CPE.
“OK, Ok, we get it!” You say,
“But what should a typical DDoS test look like? and… how often should we test?”
Because DDoS tests can (and usually do) impact the tested environment they are usually performed in maintenance windows and are therefore limited to a few hours each. Given the pace with which DDoS attacks are evolving both in terms of attack types and ‘DDoS for higher’ services now available to cybercriminals a DDoS test will try to simulate as many different DDoS attacks as possible in the time available, which is usually between 5-20 different simulated attacks, depending on how well the environment can hold up with the testing.
Together with networks’ organic growth and change, it is wise to test your DDoS mitigation posture at least once a quarter.
With the average cost of an hour’s down time estimated around $40,000, on the one hand, and the significant DDoS related investment CIOs and CISOs are commanding, on the other – it makes good sense these days to be better safe than sorry.
