Why Diversity Is Mostly Bad

This post is intended entirely as a food-for-thought conversation starter. It hasn't been reviewed by my peers, my legal team, my mom, or myself. It was written by the gnomes I keep tied up in my closet, so don't quote me.

Within your web application environment, diversity is a bad thing.

First off, let me arbitrarily redefine words to support the points I'm going to make. I'm doing this at the beginning so you don't notice when I contradict myself later.

The "diversity" I'm talking about involves using a variety of platforms, programming languages, or frameworks for your web applications. I'm also talking about the applications themselves- more diverse applications are more feature-rich.

Here's what I mean by "application environment:" All the applications you're running and the systems that support them. Defining that environment is tricky, because frankly, there is no such thing. I've said it before, but web applications have no enforceable boundaries. Not your webmail, your internal CRM app, or your firewall's web interface. As long as our web browsers support cross-site communications, those sites can't be considered to operate in any environment other than the public "internet."

That said, you can still do some things to define your environment. Just like you segment a network, you can put different applications and different kinds of content on different servers, different domains (not just subdomains), and different networks. You could argue that this is adding diversity as well, but if you do, I'll ignore you and subscribe you to various spam mailing lists.

If anything can be considered "good diversity," it's the segmentation of an environment in an effort to define application boundaries. Most risk assessments take the size of an environment into account, but few consider the homogenicity (what? It's a real metric). In my incredibly well-considered opinion, diversity should be considered when assessing risk, even when no known vulnerabilities exist.

Diversity provides more surface area

Does it really need to be said? If you're trying to lock down an application, expose as little of it as possible. The more different features you have, the more the attacker can break. Sometimes you need features. Add them. If you don't, your marketing department will complain to management. When you add those features, add them knowing that you're increasing your exposure, and do something about it.

Vulnerabilities pop up around edge cases. Diverse application environments have lots of edges. Many people pay me to do vulnerability assessments on single applications, which I'm happy to do, but they're not getting the whole picture, and they overlook how other applications can affect them.

Do you have other apps on the same server? How does that affect the seriousness of a local file inclusion bug? Do you have other apps on other subdomains? How does that affect your cookie and session security? Does your crossdomain.xml policy allow *.akamai.com? Are you even considering these kinds of things? All those edges provide untested, potentially exploitable surface area to the attacker.

Diverse environments are hard to manage

You know this one too. It's hard to keep up to date on patches. It's harder when you have a variety of technologies in place. I don't have statistics on hand to back this up (if you do, please tell me I'm wrong), but a significant portion of the vulnerabilities I find in assessments are things that could be fixed with patches or configuration fixes. As much as I rail on the Web App Scanning industry, detecting outdated and misconfigured applications is something they are (or at least can be) really good at. The more diverse your environment, the more difficult this gets. To quote Mark Twain, "Put all your eggs in one basket and watch that basket!"

When it comes to custom code, it's the same thing. I did a recent assessment on an application and found that they had excellent XSS countermeasures in place, but they weren't in place on every form throughout the application. They've been working on manually adding those controls to every form in the app. I only had to find one place where it wasn't implemented, and all the work they'd done to date was for naught. If they'd been using a centralized library to implement those security controls, they'd be done already. If I did manage to find anything, it would only take a few lines of code to update everything.

In most organizations, the biggest problem isn't finding the holes, it's fixing them. While vulnerability assessments can be pricey, it's nothing compared with the cost of developing fixes for the vulnerabilities that are found. If I'm wrong about this, then somebody is paying me too much, and not paying their developers enough.

If it's not a cost issue, it's a time issue- when I start a penetration test, I generally have a feel for where the app is going to be vulnerable in the first few hours. I may spend weeks on finding and documenting vulns, but I've done enough assessments that I can almost immediately tell you where you need to focus your remediation efforts. And yet, when I report vulns (to clients or to unwilling victims of my research), they go unfixed for months, years, or forever.

I take a lot of pride in being very good at my job, but it's not the hardest job out there. I just poke web apps until they fall over. Hacking is easy, but fixing the holes I find is much more difficult. Fixing things becomes far easier when you have homogenous systems.

Boundaries are the key to security

Now, you may be thinking that I haven't said a thing you can disagree with, and you can chalk that up to my remarkable debating skills. Keep in mind that this goes against conventional wisdom- Most people think that variety in an environment will limit an attack. Wouldn't that have lessened the impact of the worms of the late 90s? Well, yes and no. Those worms hit systems that were homogenous, but they were also poorly controlled. Technological monoculture isn't such a bad thing if we can break it up by putting boundaries around things.

Want to keep your applications from affecting each other? Put them on different servers, different networks and different domains. Want to keep Facebook from sharing data with the websites you visit? Use different browsers. SQL injection? XSS? Stack overflows? Use tokenization to put boundaries between content, presentation and code. Web browsers are so good at blurring those lines that we often don't even realize it, but they do that at the expense of security.

Effective security controls aren't attack-specific. They simply define and enforce boundaries.