Thoughts on Diversity and False DiversityBy Rich
Mike Bailey highlights a key problem with web applications in his post on diversity. Having dealt with these issues as a web developer (a long time ago), I want to add a little color.
We tend to talk about diversity as being good, usually with biological models and discussions of monoculture. I think Dan Geer was the first to call out the dangers of using only a single computing platform, since one exploit then has the capability of taking down your entire organization.
But the heterogeneous/homogenous tradeoffs aren’t so simple. Diversity reduces the risk of a catastrophic single point of failure by increasing the attack surface and potential points of failure.
Limited diversity is good for something like desktop operating systems. A little platform diversity can keep you running when something very bad hits the primary platform and takes those systems down. The trade off is that you now have multiple profiles to protect, with a great number of total potential vulnerabilities. For example, the Air Force standardized their Windows platforms to reduce patching costs and time.
What we need, on the OS side, is limited diversity. A few standard platform profiles that strike the balance between reducing the risk that a single problem will take us completely down, while maintaining manageability through standardization.
But back to Mike’s post and web applications…
With web applications what we mostly see is false diversity. The application itself is a monolithic entity, but use of multiple frameworks and components only increases the potential attack surface.
With desktop operating systems, diversity means a hole in one won’t take them all down. With web applications, use of multiple languages/frameworks and even platforms increases the number of potential vulnerabilities, since exploitation of any one of those components can generally take down/expose the entire application.
When I used to develop apps, like every web developer at the time, I would often use a hodgepodge of different languages, components, widgets, etc. Security wasn’t the same problem then it is now, but early on I learned that the more different things I used, the harder it was to maintain my app over time. So I tended towards standardization as much as possible. We’re doing the same thing with our sooper sekret project here at Securosis – sticking to as few base components as we can, which we will then secure as well as we can.
What Mike really brings to the table is the concept of how to create real diversity within web applications, as opposed to false diversity. Read his post, which includes things like centralized security services and application boundaries. Since with web applications we don’t control the presentation layer (the web browser, which is a ‘standard’ client designed to accept input from nearly anything out there), new and interesting boundary issues are introduced – like XSS and CSRF.
Adrian and I talk about this when we advise clients to separate out encryption from both the application and the database, or use tokenization. Those architectures increase diversity and boundaries, but that’s very different than using 8 languages and widgets to build your web app.