> I think Andrew misses the point of the Geer, et. al. paper. The fact > that many sites can limit the damage caused by an exploit through the > use of third party solutions and/or good hygiene does not really solve > the problem...Even though it is possible for > clueful people to limit damage to their own sites, there is evidence > that many sites do not and the fact that these sites largely represent > a monoculture makes them an attractive target for worm and virus > writers. Let's break down Geer's (et al) premises: 1. A monoculture exists. 2. This monoculture has risks. 3. The monoculture is bad and should be changed. The first point is sound. Yes, a monoculture exists. No debate there. The second point is partially correct. In a vacuum, yes, the monoculture has risks. But this monoculture does not exist in a vacuum. It must interpolate with thousands of different systems. So those risks are not a grave as the paper suggests. The third point is absurd. It flies in the face of decades of security reasoning that says, when you have risks - mitigate them. Rather than focus on the risks, Geer focuses on the environment where those risks exist. And rather than talk about mitigating the risks, the paper suggests that we need to fundamentally alter the environment (i.e. bust up Microsoft.) This premise totally ignores the numerous 3rd party products that are NOT dependent on that monoculture that can secure it. So, while the monoculture might have risks, they are easily mitigated risks. Hence, this premise is flawed. It ignores one of the most salient concepts in security: risk mitigation. What is funny, is that many of the co-authors of Geer's paper, have written other material that champions the concepts of risk mitigation and building security processes. For example, in Secrets and Lies, Bruce Schneier writes extensively about how security is a process and that real-world security must practice defense in depth. Apparently, those good ideas never made it into this paper. The simple fact is, whatever risks the monoculture has, can be easily mitigated with the use of a diverse array of technologies that help secure Windows. This paper totally, utterly ignores those mitigating technologies as well as risk-mitigation as a concept. As such, I consider the paper's conclusions as flawed. They're not based on real-world analysis, but theories that happen to fit an agenda. Furthermore, if the real problem is that many systems in this monoculture are left unpatched or unsecured, then clearly the problem isn't the systems or the company that makes the OS - it's the people and organizations that use them. When somebody fails to act responsible with a car and hurts another person, we don't shut down the car manufacturer. We put the irresponsible person in jail. If you use a computer and connect to a public space, you have a responsibility to secure those systems. If you don't, then you will pay the consequences as will others in that public space. Thus the reasonable and rational conclusion to Geer's initial concept of the monoculture is: 1. A monoculture exists. 2. Unfortunately, a monoculture has risks. 3. Those risks need mitigation and/or elimination. 4. Fortunately, there are technologies and practices that can mitigate and eliminate the risks of a monoculture reasonably easily. (i.e. use firewalls, IPS, AV, compartmentalize systems, etc.) 5. People and organizations need to take responsibility for their systems and secure them to ensure the risks of the monoculture are minimized. That is a sound argument. Rational and practical. > For a possible approach that preserves the M**t functionality that we > all love (or hate) you might take a look at the current BAA 03-44 > (research announcement) from DARPA. > Among other things, this seeks ways to create large numbers of variants > of functionally equivalent programs. Suppose that there were 1000 > different versions of, say, IIS, each requiring a different buffer > overflow exploit, but appearing identical in function and performance > to the user. I didn't read the announcement in detail, but it sounds like a ridiculously complex answer to security problems. And that would defeat the concepts of "simplicity." ___________________________________ Andrew Plato, CISSP President/Principal Consultant Anitian Enterprise Security 503-644-5656 Office 503-644-8574 Fax 503-201-0821 Mobile www.anitian.com ___________________________________
This archive was generated by hypermail 2b30 : Wed Oct 08 2003 - 09:42:19 PDT