For the last three years, I’ve attended the Linux Security Summit (though it’s not solely about Linux, actually), and that’s where I am for the first two days of this week – the next three days are taken up with the Open Source Summit. This year, both are being run both in North America and in Europe – and there was a version of the Open Source Summit in Asia, too. This is all good, of course: the more people, and the more diversity we have in the community, the stronger we’ll be.
The question of diversity came up at the Linux Security Summit today, but not in the way you might necessarily expect. As with most of the industry, this very technical conference (there’s a very strong Linux kernel developer bias) is very under-represented by women, ethnic minorities and people with disabilities. It’s a pity, and something we need to address, but when a question came up after someone’s talk, it wasn’t diversity of people’s background that was being questioned, but of the systems we deploy around the world.
The question was asked of a panel who were talking about open firmware and how making it open source will (hopefully) increase the security of the system. We’d already heard how most systems – laptops, servers, desktops and beyond – come with a range of different pieces of firmware from a variety of different vendors. And when we talk about a variety, this can easily hit over 100 different pieces of firmware per system. How are you supposed to trust a system with some many different pieces? And, as one of the panel members pointed out, many of the vendors are quite open about the fact that they don’t see themselves as security experts, and are actually asking the members of open source projects to design APIs, make recommendations about design, etc..
This self-knowledge is clearly a good thing, and the main focus of the panel’s efforts has been to try to define a small core of well-understood and better designed elements that can be deployed in a more trusted manner. The question that was asked from the audience was in response to this effort, and seemed to me to be a very fair one. It was (to paraphrase slightly): “Can it really be good for security to have such a small number of systems out there?” The argument – and it’s a good one in general – is that if you have a small number of designs which are deployed across the vast majority of installations, then there is a real danger that a small number of vulnerabilities can impact on a large percentage of that install base.
It’s a similar problem in the natural world: a population with a restricted genetic pool is at risk from a successful attacker: a virus or fungus, for instance, which can attack many individuals due to their similar genetic make-up.
In principle, I would love to see more diversity of design within computing, and particular security, but there are two issues with this:
- management: there is a real cost to managing multiple different implementations and products, so organisations prefer to have a smaller number of designs, reducing the number of the tools to manage them, and the number of people required to be trained.
- scarcity of resources: there is a scarcity of resources within IT security. There just aren’t enough security experts around to design good security into systems, to support them and then to respond to attacks as vulnerabilities are found and exploited.
To the first issue, I don’t see many easy answers, but to the second, there are three responses:
- find ways to scale the impact of your resources: if you open source your code, then the number of expert resources available to work on it expands enormously. I wrote about this a couple of years ago in Disbelieving the many eyes hypothesis. If your code is proprietary, then the number of experts you can leverage is small: if it is open source, you have access to almost the entire worldwide pool of experts.
- be able to respond quickly: if attacks on systems are found, and vulnerabilities identified, then the ability to move quickly to remedy them allows you to mitigate significantly the impact on the installation base.
- design in defence in depth: rather than relying on one defence to an attack or type of attack, try to design your deployment in such a way that you have layers of defence. This means that you have some time to fix a problem that arises before catastrophic failure affects your deployment.
I’m hesitant to overplay the biological analogy, but the second and third of these seem quite similar to defences we see in nature. The equivalent to quick response is to have multiple generations in a short time, giving a species the opportunity to develop immunity to a particular attack, and defence in depth is a typical defence mechanism in nature – think of human’s ability to recognise bad meat by its smell, taste its “off-ness” and then vomit it up if swallowed. I’m not quite sure how this particular analogy would map to the world of IT security (though some of the practices you see in the industry can turn your stomach), but while we wait to have a bigger – and more diverse pool of security experts, let’s keep being open source, let’s keep responding quickly, and let’s make sure that we design for defence in depth.
Alice, Eve and Bob - a security blog 
One thought on “Is homogeneity bad for security?”