Halflings, Dragons, and DDoS Attacks

An all too common constraint on applications today is budget. Security budgets may be growing, yes, but not at a rate commensurate with the strategic approach of making yourself too expensive to hack.

This approach is akin to the Halfling-Dragon Principle which states:

If you find yourself in the company of a halfling and an ill-tempered dragon, remember that you do not have to outrun the dragon; you simply have to outrun the halfling.

The idea is to make your own environment cost too much to attack, forcing the dragon to turn its hungry eyes toward your competitor, the halfling, instead.

Now, without digressing into the ethical debate that should enflame, the notion of making your environment too expensive to hack is not a bad one.

The problem is that often means it’s too expensive for you to afford, too. That’s because generally speaking the advice on executing on such a strategy entails purchasing a whole bunch of solutions and throwing them up like some sort of medieval gauntlet, putting up new barriers and forcing attackers to run it to get to what they really want, your data. This makes it expensive for the attacker by forcing them to expend time, energy, and ultimately money as they attempt to spread out their attacks to avoid detection. That’s expensive not just for the attacker, but for the enterprise, too. Not just in terms of the solutions (capex) but operationally (opex) as each solution must be managed, updated, monitored, and, ultimately, scaled.

It’s also inside out. What attackers want is your data, and yet we tend to build our defenses and protections starting at the point furthest from the data, at the perimeter of the network.

So how do you make it too expensive for them to get what they want, without making it too expensive for you to implement?

There’s no silver (plated) bullet for this one, but there are some ways you can keep your costs down while increasing the costs to attack. 

1. Leverage Platforms

Platforms are based on the idea of sharing a common environment. They reduce costs the same way virtualization and containerization increase the efficiency of compute resources. An ADC, for example, can be extended with modules to support a wide variety of delivery functions, including security. Many organizations already use an ADC to ensure availability with load balancing that may be able to support deployment of WAF and other security-related functions. As an holistic solution, the right ADC can cost far less in total than the sum of its individual functions as point solutions.

Also worthy of exploration are capabilities of the load balancer itself. Unlike rudimentary load balancing, an ADC generally offers a number of knobs and levers related to security that can be employed to make attacks more difficult. SYN flood detection, cookie encryption, URL obfuscation, and IP/Port filtering are often available as part of a load balancing service. Increasing the protection closer to the app makes it more difficult for the attacker to access.

2. Operationalize

There is still, to the chagrin of some and delight of others, no known “god-box” that can single-handedly provide everything you need to secure and scale applications. You’re going to need multiple solutions (they key is to minimize how many using platforms, see above) and that means multiple consoles, management paradigms, and probably people. All of which will blow your budget.

Operationalization, enabling automation and orchestration, can keep a lid on the costs of the solutions you must have in place. Even capabilities like auto-scaling to take advantage of resources you (likely) already have to scale up and force an attacker to respond in kind can increase the costs to attack while keeping the costs to defend under control.

Operationalizing (DevOps, SDN, SDDC, SDx, private cloud, et al) also addresses sources of high risk: human error and lack of process. On the latter, you can’t automate a process (that’s orchestration, by the way) that doesn’t exist. And if you don’t have one, you should. It ensures that steps are taken that need to be to secure and scale apps when they move into production. The former, human error, is a huge risk as it can inadvertently open up holes in your security that let bad guys sneak in, either directly or under the wire during the distraction of a volumetric DDoS attack.

3. Cloud as Scale

And when you can’t auto-scale anymore, or your bandwidth is overwhelmed, there’s always the cloud. The cloud as scale (cloud bursting, if you prefer) is an excellent option for enabling you to defend efficiently while driving up the costs to attack. Switching DDoS scrubbing and protection to the cloud during an attack (or when it first starts) can immediately reduce the local impact to the business (in productivity and profit measures) which does, in fact, mean less expensive defense. Letting the cloud, with its (nearly) infinite scale and gobs of bandwidth absorb an attack will cost a lot less in the long run for you but not for the attacker.

4. Secure from the Inside Out

As previously noted, attackers generally want your data. That’s because your data == $$ on the open seedy market. So focus as much (if not more) on securing your data as you do on your perimeter. That means employing all the tricks and techniques you can to make it very expensive for an attacker to extricate value from their attacks (by grabbing data). You do that by constant vigilance, by protecting not only what goes into the app but what comes out. That’s request and response protection.

The majority (67%) of respondents in our State of Application Delivery 2016 who have a WAF deployed today  were confident in their organization’s ability to withstand an application layer (request-response) attack. Those are things like SQLi and XSS, but also WebSocket security and session hijacking prevention and a wealth of other capabilities that ensure it is very expensive for an attacker to succeed in getting at your data.

In fact, more consistent protection across all three attack surfaces (client, request, and response) correlated with a higher confidence in withstanding an application layer attack. That’s not an “edge” function; that’s an app-centric function. One that sits closer to the app than it does the edge of the network, and its goal is not to stop network attacks, but the attacks that actually extricate data. That’s the value attackers are looking for, and it’s the value you have to make so expensive that attackers will give up and go elsewhere.

There’s no way to make security cheap. There just isn’t. But there are ways to keep the costs down, to make it more expensive for the attacker than it is for you, without leaving you too broke to secure your apps. And if you do it well, and your defenses force attackers to consume too many of their own resources (and money), the dragon might just be too tired (broke) to go after that halfing. And that will give the halfling a chance to get a head start on their own defenses.