Slashdot Mirror
Microsoft to Ship New Malware Protection Utility
LadyDarth writes "Microsoft introduced on Thursday a new program called Client Protection that will help to combat viruses, maiware and spyware in the corporate environment. Paul Bryan, product management director in the enterprise security division at Microsoft, said in an interview with BetaNews Wednesday night that Client Protection's aim is to 'make sure people have fewer security products' to concern themselves with. Responding to concerns that it was stepping on its partners toes, Bryan admitted that Microsoft has 'knowledge and an understanding of the capabilities of the operating system' that its partners may not have. But he said that information would not be hidden."
Fair question, as long as it's not being used as a vehicle to express resentment toward "security experts" for a topic you can't be bothered to understand. That sort of sophistry is the refuge of the ignorant. And as the subject has received widespread attention, it's not as if your question hasn't been answered many times over.
But assuming that your question is genuine, here is a short, and by no means exhaustive, list of areas is where Microsoft falls down with respect to security:
Many of these factors are interrelated. When Microsoft engages in illegal monopoly practices, it has the effect of reducing the security of supply to the industry by limiting the number of competing products. It does so by deliberately breaking interoperability with competing products through a strategy which it calls "embrace and extend."
Another strategy, called "integrated innovation," likewise promotes the questionable virtues of integration at the expense of the fundamental virtue of modularity. Integration is fine for microprocessor chips, but software components are not transistors, and the software engineering problem, as Fred Brooks pointed out, is not about how to efficiently replicate such components. On the contrary, we often need to replace individual software components in order to repair security problems in their design or implementation. Modular systems are thus intrinsically more favorable to security than integrated, monolithic ones.
Independent of this effect, it's also possible to reason more effectively about security in a modular design than in a monolithic one. The analysis of security between communicating entities has been very well studied, and in a modular system this communication takes place in formally defined ways. The strongest demonstration of this capability lies, again, in how well a module interoperates with others. So when Microsoft attests in court that Internet Explorer can't be removed from Windows, it's acknowledging a basic failure to attend to modularity.
Security factors such as containment and least privilege are only possible where modularity is already well established and effectively managed. Usually these factors are what people think of as being characteristic of secure design, but they are in some sense derivative of more general security and design factors such as modularity. In any case, from all of the foregoing we can easily predict that problems will arise when bringing them late to a design, as Microsoft has characteristically tried to do.
Other critical design factors, like security by default and verifiability, require a further degree of commitment to security which Microsoft has a history of actively avoiding. I could cite many examples of these, but surely you can think of some on your own with modest effort.
Parity: What to do when the weekend comes.