Website Monocultures and Polycultures

Way back in 2003 a group of highly respected security pros released a controversial yet landmark paper, “CyberInsecurity: The Cost of Monopoly.” The text offered two lessons: software monocultures are dangerous and Microsoft, the largest of monocultures, is the most dangerous. At the time this conclusion sparked an industry firestorm. More recently Bruce Schneier and Marcus Ranum faced-off on the monoculture debate, which got me thinking if these ideas apply equally to website security. You see monoculture and polyculture theories are generally based upon commonly understood network and host layer security behaviors, behaviors very different from website security.

Before diving in let’s first establish a baseline on the fundamental assumptions about software monocultures and polycultures. Monocultures, meaning all systems are identical, are at elevated risk to systemic widespread compromise because all nodes are vulnerable to the same attack. For example, one zero-day exploit (not necessarily required) has the capability of ripping through the entire ecosystem. The benefit of a monoculture however is the consistency of all the connected nodes allow for easier management by IT. Manageability makes keeping patches up-to-date less difficult and by extension raises the bar against targeted attacks and random opportunistic worms.

In polycultures exactly the opposite is true. In the event of a worm outbreak, again possibly leveraging a zero-day vulnerability, a polyculture would be more resilient (survivable) by virtue of the diversity in the ecosystem. All nodes are not vulnerable to the same issue. The downside of course is the increased difficulty and cost of IT managing a polyculture, including keeping security patches up-to-date. Therefore targeted attacks and random opportunistic worms are more likely to succeed in a polyculture environment, but to a limited extent.

Depending on tolerance for risk and the threat agent one is most concerned about, targeted or random opportunistic, it dictates if a monoculture or polyculture environment is preferable. We see where the authors of the aforementioned paper fell. And in 2003, the era of extremely large worm infections including SQL Slammer, Blaster, Nimda, Code Red, and so on it is not hard to see why. Today I hazard to guess that most people in the infosec industry would still agree with their conclusion -- monocultures as dangerous, polycultures are more survivable. So when thinking in terms of networks comprised of Windows, Linux, BSD, OS X, and so on all this sounds reasonable, but when the context is switched to websites things get trickier.

First of all, it doesn't matter what OS is underlying when SQL Injection, CSRF, XSS, AuthN, and AuthZ attacks are employed against a target site. Second, save for mass SQL Injection worms that take advantage of one-off Web application flaws, websites compromises are primarily targeted. That is the attacker is to some degree sentient. Lastly, and this is where the monoculture vs polyculture question comes in, in networks the attack surface consists of its many hosts while in a website its really the collection of discreet Web applications (or inputs to those applications). Applications written in one or more programmings languages.

I’m suggesting that a “website monoculture” is one where all the Web applications are written in a single programming language and development framework. Pick Python, Perl, PHP, .Net, Java, Ruby, etc. But one and only one. Conversely, a “website polyculture,” is where there’s some mix of languages and frameworks. Of course the manageability aspects of multi-language website mirrors a multi-OS network. Sites using a single consistent language are easier for an organization to code securely and keep secure. Here’s where it gets interesting, I’m not sure how common a website monoculture really is on the Web.

Any website worth hacking is NOT a static network or host component, but a mass of Web applications that are updated with some frequency over years -- daily, week, monthly, etc. The functionality may be merged or migrated with other websites, built by different teams developers, and whose section of the code is created using whatever programming language is popular at the time. A website is not AN application, but many hyperlinked together. That's why you’ll often see websites using some ASP classic and .NET, Java mixed in with Cold Fusion, perhaps Perl intermingled with PHP, and many other combos. Case in point, the WhiteHat Security 9th Website Security Statistics Report showed that websites exhibiting extensions from one language often had a substantial number of vulnerabilities with extensions in another.

Also important to point out that when one host is compromised on a network the attacker may attempt to exploit another flaw in another host and leapfrog across. A quite common scenario because the first compromised machine is usually not enough to achieve their end goal. Websites on the other hand are different. One exploited bug in a website tends to give the attacker exactly what they wanted, server-side data or end-user compromise. It is rather uncommon to find it necessary to exploit one Web application flaw to then exploit another to achieve the goal. Just one XSS allows someone to hack all users. One SQL Injection pilfers all of the data. So no real compartmentalization exists on a website and therefore there’s nothing to be gained security wise that I can see in a polyculture website.

So if website attacks are generally targeted, again except for SQLi worms, and it's easier to secure code written all in the same language, then we should be advocating monoculture websites. Right? Which is exactly the opposite of how the community seems to want to treat networks. I just found that to be really interesting. What I’m working on now inside WhiteHat is trying to find statistical evidence in real terms how the security posture of the average monoculture and polyculture compare. I’m guessing monoculture websites are noticebley more secure, that is, less vulnerabilities. But what would your theory be?