You can go exploited for long periods of time, yet continue to do business in a state of ignorance, as Swiss Ruag did for years. But with Distributed Denial of Service attacks the case is entirely different. Your service comes to a halt within minutes and panic breaks out. You will notice, your boss will notice and the CEO will be informed immediately. Given the relative rarity of the event, most security teams will be hit them unprepared. Running after exploited clients and digging into logfiles may be standard business, but fighting for the survival of your online presence drives people to their limits and some tend to freak out in such situations.
All capacity is limited – but it helps to know the max capacity (photo “People” by Diego Torres Silvestre, licensed under CC)
In fact, DDoS is special in many regards. I do not want to iterate the dangers of IoT botnets coming after you or the unbelievably high network bandwidths used in such attacks these days. But many business boost their 1 Gbit/s or 10 Gbit/s internet connections when the attackers seem to be capable to send a hundred times this during an attack. So this is very, very dangerous and everybody outside of the biggest dozen players struggle under these attacks.
The more businesses go online with their services and the more they depend on the internet for communication with their customers and for their back office processes, the more affected they are by network and application outages.
But fatalism is the wrong answer. You must seek preparedness instead.
A DDoS Incident Handbook is a way to prepare yourself and give a plan into the hands of your organization. It is important that everybody is on the same page when under attack and you do not want to struggle to find the necessary documentation in such a situation. Pre-assemble it in an incident handbook and pull it out the drawer when you are hit.
I have been commissioned with writing DDoS Incident Handbooks for various organizations and services. What is the typical structure of such a document, or what makes the table of contents?
1 – A detailed description of the infrastructure
2 – Possible attack scenarios
3 – The means of defense
4 – Guidelines for communication
5 – A simple decision making process
(1) You really need to know your infrastructure in detail. Maximum throughput and bandwidth rates are vital as are the connections between components. Responsibilities need to be clear and you want to have their phone numbers ready. The contact to the network team of your ISP is vital too as the ISP will not be very tolerant to you being under attack. In fact they will kick you out when their other customers start to suffer from collateral damage. You better know the details of his policy in advance. It forms part of the description of your infrastructure.
(2) Who could attack you and why? Is your industry known for attacking the competition? Could you become a secondary target in a political controversy? Are you exposed in a way that would make you an attractive target for organized crime? Did you lay off IT personnel and they are now holding a grudge against you? Correlated to these questions are the questions about the means of the attackers. Traditionally, DDoS attacks were network attacks. But there has been a steady trend towards application level attacks. The dominance of encrypted HTTP traffic complicates the defense and gives attackers an edge. Search forms are notorious CPU killers, file upload functionality can be a soft spot to your site and stupid account blocking policies could allow an attacker to block 80% of your teams from accessing the servers. Still, most attacks are using NTP and DNS reflection to bury your network devices under an avalanche of packets that overwhelms their capacity.
(3) Knowing the functionality of all the useful buttons determines the speed with which you recover from a DDoS attack. In fact there are quite a few of these buttons. Timeouts can be lowered, thread numbers raised, predefined ACLs activated, dedicated DDoS defense devices can be enabled inline and perhaps most importantly, non-essential functionality can be switched off to streamline your service and to reduce the attack surface. But you need to predetermine the breaking points and you need to know the functionality that you can leverage. It is always surprising what we dig up in existing organizations during DDoS defense workshops. This chapter is meant to cover this from A to Z.
(4) In my experience, standard communication lines break down during DDoS. Or management unfamiliar with the problem at hand behaves erratically. You can lessen the problems by re-iterating the communication lines and establishing forms of reporting that spread the essential information to he right people during the attack.
(5) Defending against DDoS involves painful decisions. You will have incomplete information in a situation of great fear and anxiety. But you must not become paralyzed as this will cost you time, money and reputation. Taking the decisions to abandon certain services during the course of the attack, locking out certain users and compromising in terms of privacy and security (!) can be the only way out. So you have to establish a ladder of authorities and assign the foreseeable decisions to the various people on various echelons of the ladder.
Necessarily, there is a lot of redundancy in such a handbook. In fact it assembles information that is spread over your organization in forms of various documents and many smart brains. The function of the DDoS Incident Handbook is to bring it all together into a single document, so you do not have to search for the scrambled bit of information when time is precious.
The description of the infrastructure and the attack scenarios will also help you identify weak spots in your architecture or system setup. All combined there is nothing like a DDoS Incident Handbook to prepare your business for an attack type that will knock you off your feet if you have not done your homework.
Christian Folini Follow @ChrFolini Tweet