For years security folks have grumbled about the role compliance has assumed in driving investment and resource allocation in security. It has all been about mandates and regulatory oversight, which drive a focus on protection, ostensibly to prevent data breaches. We have spent years in the proverbial wilderness focused entirely on the “C” (Confidentiality) and “I” (Integrity) aspects of the CIA triad, mostly neglecting the “A” (Availability). But that hasn’t worked out too well.

Regulators pretty much only care whether data leaks out. They don’t care about the availability of systems – data can’t leak if the system is down, right? Without a clear compliance-driven mandate to address availability (due to security exposure), many customers haven’t and won’t do anything. Of course attackers know this. So they have adapted their tactics to fill the vacuum created by compliance spending. They increasingly leverage availability-impacting attacks to both cause downtime (costing site owners money), and use availability issues to mask other kinds of attacks. Yes, these availability-impacting attacks are better known as Denial of Service (DoS) attacks.

To be clear, most security professionals are very familiar with DoS attacks. It may be hard to remember back over a decade ago, but in the heyday of the Internet bubble we saw many old-fashioned Distributed DoS (DDoS) attacks targeting high profile web properties (think Yahoo and E*Trade, back in the day), with attackers like Mafiaboy doing the damage more for notoriety than to cause real economic damage. Over the past decade attackers have reoriented toward financially motivated attacks, which has meant increasingly application-centric attacks designed to evade detection and exfiltrate lucrative data.

Obviously knocking down a target interferes with efforts to rob it electronically. But DDoS never really went away – it became a supplementary extortion tactic. In this scenario, attackers would communicate with a company and promise to knock down their site unless they received a ransom. It’s a simple shakedown move, and many targets were simply unable to survive a significant outage. They paid up rather than fight. We didn’t hear about many of these attacks – nobody wants to publicize that they are vulnerable to shakedowns.

But that is all changing now. It’s like Back to the Future a bit – the rise of hacktivism has brought the Denial of Service back into a prominent position in the nightmares of security folks. Facilitated by the availability of open source tools such as LOIC and the availability of bot networks to launch attacks, a DoS renaissance is underway – which means availability has once again become a major factor in security architecture and control design.

We try to do forward-looking research at Securosis. So we have started poking around, talking to practitioners about their plans, but we still see a knowledge gap around the kinds of Denial of Service attacks in use today and the defenses needed to maintain availability. So today we launch a new series: Defending Against Denial of Service Attacks, which will (unsurprisingly) provide guidance on the DoS attacks in use today, defensive tactics, and the basic process required for any chance to defend your organization. Let’s start by understanding the major kinds of DoS attacks.

Flooding the Pipes versus Filling the Servers

We’ll dig into specific attack tactics in much more depth in the next post, but to understand Denial of Service we need to draw a clear distinction between network-based attacks and application-based attacks. Both have the same objective: to impair availability – but they go about it in fundamentally different ways.

Network-based attacks overwhelm the network equipment and/or totally consume network capacity by throwing everything including the kitchen sink at a site. This prevents legitimate traffic from getting to the site. This volumetric type of attack tends to be what most folks consider Denial of Service, because it is the most visible type. If your adversary has a big enough cannon it’s very hard to defend against these attacks, and you will quickly be reminded that bandwidth may be plentiful, but it’s certainly not free.

Application-based attacks are different – they target weaknesses in web application components to consume all the resources of a web, application, or database server to effectively disable it. These kinds of attacks can target either vulnerabilities or ‘features’ of an application stack to overwhelm servers and prevent legitimate traffic from accessing web pages or completing transactions.

The beginning of a network-based attack is fairly obvious. But application-based DoS attacks are less obvious – you are unlikely to discover the attack is underway until servers inexplicably start falling over – so they require more sophisticated defenses. That said, much of DoS defense is about properly leveraging existing controls, and of course compliance mandates haven’t gone away, so still have those required controls. Since you are already robbing Peter to pay Paul to address audit deficiencies, for DoS protection you need to focus your defenses on the attacks you are most likely to see. Which brings us to our next concept: studying your adversaries.

Adversary Analysis

A new tactic increasingly leveraged by security practitioners is adversary analysis. It’s not enough to just understand attacks and build defenses based on attacks – there is simply too much attack surface, and too many attack vectors. Your security success depends on your ability to prioritize your efforts, as we hammered home in the Vulnerability Management Evolution paper. This involves making strategic bets about who is most likely to attack you and what tactics they tend to use. This will enable you to build control sets with the right initial focus, based on what’s likely to happen. Of course you will be wrong – attackers evolve tactics over time – but in the universe of things you can do, this approach helps narrow your options into something (mostly) manageable.

So let’s coarsely group the kinds of adversaries who use DoS attacks.

• Protection Racketeers: These criminals use a DoS threat to demand ransom money. Attackers hold a site hostage by threatening to knock it down, and sometimes follow through. They get paid. They move on to the next target. The only thing missing is the Goodfellas theme music.
• Hacktivists: DoS has become a favored approach of hacktivists seeking to make a statement and shine the spotlight on their cause, whatever it is. Hacktivists care less about the target than about their cause. The target is usually collateral damage, though if they can hit two birds with one stone by attacking an organization that opposes to their cause they will. You can’t negotiate with these folks, and discussion furthers their goals.
• Exfiltrators: These folks use DoS to divert attention from the real attack – an attempt to stealing data. This could be an intellectual property theft or a financial attack – stealing credit cards. Either way, they figure if they blow in your front door you will be too distracted to notice your TV scooting out through the garage.
• Competitors: They say all’s fair in love and business. Some folks take that one a bit too far, and actively knock down competitor sites for their own advantage. Maybe it’s during the holiday season. Maybe it happens if the competitor resists an acquisition/merger advance. Regardless of the reason, don’t assume the attacker is a nameless, faceless crime syndicate in a remote nation. It could be the dude down the street trying to get any advantage he can – legalities be damned.
• Success: Sometimes a promotion or outside activity creates an innocent DoS situation. Like when a new iPhone is available for order, and the carrier’s network can’t handle the traffic. And once the carrier figures it out, pre-ordering applications fail under the load. It’s basically friendly fire. Some would say this is a good problem to have, but it is still a problem. Customers can’t complete transactions, which causes dissatisfaction and grumpiness. So part of network and application architecture has to be handling peak traffic situations – catastrophic success – which can look an awful lot like a DoS attack.

Elasticity Enables Economic Denial of Service

The adversaries we described above tend to utilize network-based and application-based attacks. But the cloud complicates things further, creating a new kind of DoS attack. For those of you not familiar with how cloud computing works, one of its key aspects is elasticity – the cloud infrastructure can be expanded and contracted as needed, as dictated by business conditions. During peak traffic the system expands – typically automatically, based on utilization levels – to meet demand by provisioning new compute, adding storage, etc. When the peak passes, the system can deprovision devices and return to normal size. Sounds great, right?

Elasticity can be awesome. But let’s consider another essential characteristics of cloud computing, measured service: you pay for what you use. So if an adversary figures out how to consume your resources (via traditional DoS tactics), forcing extra devices to be provisioned, they can run up your credit card to the limit (cloud services generally require credit card billing) and take you offline. The cloud may scale up to meet the computing demand, but your credit card can’t expand to meet the financial demand. This attack is becoming known as an “Economic Denial of Service” – the technology works fine, but the target may run out of money to keep their systems up and running in the cloud. It’s actually a refinement on an old attack – it was quite possible to run up a high bandwidth bill on a pre-cloud site, but bandwidth rates were low enough (and hard enough to scale up) that this was much less of a threat to corporations than individuals.

Understanding Attacks and Designing Defenses

With the sordid history of Denial of Service attacks, and the classes of adversaries who leverage DoS attacks, we have set the stage for the rest of this series. We will start by going much deeper into the tactics behind these attacks. Understanding the attacks then leads into a discussion of the different tactics and techniques for defending against each type. Finally we will wrap up by tying together that knowledge to create a process for taking action when under DoS attack. The process is built from our incident response framework, tuned to handle the unique issues presented by DoS attacks.

As always, we will write this series using our Totally Transparent Research methodology, building the series independently and incrementally via the blog, and inviting peer review throughout the process. We have lined up Arbor Networks, Corero and Radware to license the paper when we’re done, but they don’t have any more influence on our research than you do. So provide some comments and help keep us honest.