While DDoS mitigation management can seem like a bit of a black art, it actually follows standard incident handling procedures. Preparation and process execution are key. You want to confirm that you have a good plan in place before the worst occurs. You also want to ensure that you have a good post mortem process so that you are constantly improving. In this three part series, I’ll walk you through the DDoS mitigation management framework.
As mentioned, DDoS mitigation management follows standard incident handling procedures. This includes a number of required steps, which help bring our network back into normal operation. These steps include:
These steps are shown in Figure 1. Note that this is a reciprocal process. In order to achieve continuous improvement, we assess each mitigation cycle in order to refine and revise the process.
It cannot be stressed enough how important preparation is to DDoS mitigation. It cannot be stressed enough how important preparation is to DDoS mitigation. Consciously or not, this step comes down to performing a risk assessment. We evaluate the potential attack vectors that can be used against us, and make a choice as to how much to invent in mitigating those vectors. I say “consciously or not,” because many organizations choose to ignore the problem until the worst occurs. This ensures that the DDoS attack will have maximum impact. We obviously need to weigh the risk of a DDoS attack against the other risks to the business. However it is better to make conscious choices than it is to simply ignore the potential problem.
Unfortunately, there are many variations of DDoS attacks seen in the wild.
Attackers have become extremely creative in identifying methods to flood our network with bogus traffic. Attackers have become extremely creative in identifying methods to flood our network with bogus traffic. The full spectrum of how these attacks can be executed is too extensive to cover here. However, for the purposes of defending our network, we can place DDoS attacks into one of two categories, out-of-protocol and in-protocol.
Out-of-protocol attacks are when the attacker sends a traffic pattern at your network that is not normally consumed by the target system. For example, a current popular vector is to bounce and amplify traffic off of exposed connectionless LDAP servers. This results in inbound UDP traffic with a source port of 389 and a destination port of a random upper port number. Out-of-protocol attacks are the easiest to identify and mitigate because they do not look like a normal traffic patterns.
In-protocol attacks are attacks against our systems that can, on the surface, look like regular traffic patterns. For example, some attackers have built extremely large botnets. One possible attack vector is to simply have a large bot army start generating connections to a target’s Web server. These look like normal inbound requests for data. However, the intent is to get the Web server so busy that it is unable to respond to legitimate data requests.
Another possible vector is to combine in-protocol traffic with services that are vulnerable to amplification. For example, NTP is used by servers to synchronize time. An attacker can leverage reflection techniques to send a flood of NTP traffic at a target network. This can make it difficult to determine which NTP traffic is legitimate and which is part of the flood. DNS is another common service that is used by everyone. Attackers can leverage reflection to send a large amount of DNS traffic to your DNS servers. Again, it can be difficult to distinguish which traffic is legitimate and which is not.
In-protocol attacks are far more difficult to identify and mitigate than out-of-protocol attacks. Because they target services you are supporting, you typically need a way to deeply analyze the traffic to identify which traffic is illegitimate. Mitigation also becomes more difficult, because the unique patterns that permit you to identify the attack traffic may be embedded in the data payload.
Now that you understand how a DDoS attack can be used against your network, you need to identify the risk this imposes a threat to your business. “Risk” is a product of two factors, probability and magnitude. Probability can be evaluated by looking at your business model. Are you in a high risk vertical like gambling, games or education? Are you a small business that no one has heard of or a large organization with global visibility? Has your organization or one of its leaders expressed political, sociological or economic opinions that could draw ire from certain demographics, cultures or beliefs? Has controversial information been published regarding your organization? All of these criteria factors into your probability of being targeted by a DDoS attack.
The other component of risk is magnitude. In other words, what would be the impact to the business if a DDoS attack was to occur? You first need to look at your points of connection with the Internet. Are servers located on-site, in an external data center with a separate Internet connection or in a public cloud? If your servers are onsite, a single attack could bring all inbound and outbound services. If your servers are external, an attack may bring down your customer facing services, your corporate connection to the Internet, but not necessarily both at the same time.
Next, you need to create an inventory of both inbound and outbound services. Examples of inbound services may be:
Outbound examples may be:
Finally, we need to evaluate how the loss of each of these services would impact your business model. For example, what is the impact if sales cannot reach out to prospects? Do we have SLAs with financial implications if customers cannot access our portal? Which of these services have backup or alternate solutions to fall back on? For example, let’s say your finance team uses an external SaaS service for tracking income and expenditures. Is there some other process they can fall back on if the SaaS service becomes unavailable due to a sustained DDoS attack? It is worth noting that DDoS attacks are becoming more frequent. When they do occur, it is not uncommon to see them last a day or more. In the past year, we have seen DDoS attacks that have lasted up to 12 days. So when assessing impact, you need to evaluate effect over time.
Now that we have a handle on probability and magnitude, it is time to translate this into potential financial losses. Don’t forget to factor in potential customer churn into the financials. While your services have been offline, your customers have been frustrated by the impact to their own business model. It is not uncommon to see competitors leverage this opportunity to go after your more lucrative customers. So while we are adding up the direct cost of the attack to our business model, we also need to factor in potential revenue loss over the near future. Clearly DDoS attack mitigation seems expensive until you evaluate the full scope of potential losses that can occur.
As we move through the additional DDoS mitigation management steps, keep in mind that they are all rooted in preparation. For example, as we talk about identification and containment, keep in mind that acquiring the proper tools and developing the appropriate techniques needs to begin in the preparation phase, before any attack actually occurs. We also want to ensure that preparation includes proper training and simulation drills so that everyone is clear on techniques and procedures.
It should be clear that much of DDoS mitigation management comes down to proper preparation. It is vital that you understand the business risks so that a proper mitigation strategy can be implemented. In part 2 of this article, I’ll go through the identification and containment steps so that you have a clear understanding of how to initially respond to a DDoS attack.