Security consulting company @Stake has drawn further attention to an unfavourable study on Microsoft's impact on global computer security by firing one of the authors. Dan Geer was CTO of @Stake until the publication of "CyberInsecurity: the Cost of Monopoly" then, pow, he wasn't.

@Stake said that Geer hadn't had permission for his involvment in the study, and that the views expressed in the document were not in line with the views of the company. @Stake does do consultancy for Microsoft, but Microsoft protests that it was in no way involved in Geer's sudden, unfortunate encounter with the precipice. And we believe them - The Beast is no stranger to baby-knifing, but surely even the merest imbecile in there must understand the horrendous consequences that would ensue from picking up the phone and suggesting the continued presence of a particular employee might be contract-threatening.

If we at The Register have faults, then we accept they may include an over-readiness to assign high IQs to industry participants. But we don't think we're wrong this time. So why did @Stake do it? The company would surely have understood the conclusions people would leap to, and the effect close identification with Microsoft in the rumour-mill might have on its business. Here we go recklessly assigning high IQs again, but think about it - if your company does not agree that the Microsoft monoculture is a "clear and present danger" to global computer security (we know, but just pretend for a second, OK?), then would it not be an inconvenience to employ a high-level exec who did? It's perfectly possible the company went ahead and did it, knowing the consequences, because it felt it was the right thing to do.

Whatever, Dan Geer's pay-check is no doubt important to Dan Geer, but of less consequence to the world in general; what about the study itself?

We have trouble with the headline thesis that monoculture is of itself bad for security, and also - particularly - with the pitch that the security problems of Microsoft software largely stem from illegal but successful attempts to monopolise, e.g. (from the intro):

"Microsoft's efforts to design its software in evermore complex ways so as to illegally shut out efforts by others to interoperate or compete with their products has succeeded. The monopoly product we all now rely on is thus both used by nearly everyone and riddled with flaws. ... a software monoculture that each day becomes more susceptible to computer viruses, Trojan Horses and other digital pathogens."

A little too purple for our tastes. Both arguments are possible, but in this context we think they're counter-productive, because they'll tend to get the document dismissed in some circles as purely anti-Microsoft propaganda, whereas much of the argument under the headlines strikes us as material that thinking Microsoft techies would at the very least give a hearing to.

From the security perspective monoculture is not of necessity bad; the problems (as indeed the document argues) lie in the flawed nature of the design of the base product, magnified many times by the ubiquity of that product, and again by the complexities introduced under the banner of integration and automation. So in theory at least, it seems to us, you could have a monoculture whose fundamental design premise was not fatally flawed, and whose security issues would therefore not be magnified by "cascade failure" across the network. Sure you could still argue it was lining the pockets of a bunch of greedheads who were stifling diversity, but that's a different argument.

Did somebody at Microsoft think linking stuff together so it could do other stuff without asking you would be cool, or was it a fiendish plan to lock rival products out and lock users in all along? This is a chicken and egg argument that we don't need to deal with here. But for the record, although we accept that Microsoft has used integration as a monopolisation tool, we think they approached it first from the perpective that automation was cool, and that this was always a very stupid and reckless thing to think.

Which still gets us into similar territory to the document's authors. Tight integration, they say, is "a principal driver of dominance and of insecurity... [it] violates the core teaching of software engineering, namely that loosely-coupled interfaces make maintenance easier and life-cycle costs lower."

Microsoft itself accepts that it has a security problem, and while you might reckon it only does so because it's not possible to deny it, clearly the company has to do something about it, indeed is doing something about it. So next we need to ask ourselves whether we think we'll like what that something turns out to be, whether it will be effective, and in what ways it might be effective (because we might not like all of these effects).

The document again: "Efforts by Microsoft to improve security will fail if their side effect is to increase user-level lock-in. Microsoft must not be allowed to impose new restrictions on its customers - imposed in the way only a monopoly can do - and then claim that such exercise of monopoly power is somehow a solution to the security problems inherent in its products. The prevalence of security flaw in Microsoft's products is an effect of monopoly power; it must not be allowed to become a reinforcer."

Basically, how much do you trust Microsoft to fix security in Microsoft products without doing so via further lock-in, with purely monopoly-motivated aspects being introduced under the banner of 'it's good for you, we know best'?

We've said here several times that we think that there are many smart and honest people working on Microsoft's software and its security, but that we doubt their ability to overcome the monopolisation desires of the marketing droids, when it finally comes down to it. So our answer to that last question is, 'not a lot', and that also appears to be the conclusion the authors come to. The susceptibility of networks to attack "cannot be mitigated without addressing the issue of monoculture. Risk diversification is a primary defense against aggregated risk when that risk cannot otherwise be addressed." (our emphasis)

That is, if you don't believe the monoculture is capable of reforming and fixing itself, then you must tackle it by eroding it, by deploying other platforms yourself, by placing restrictions on the extent of monoculture in key sectors, and by legislating to force diversification within the monoculture itself.

Got that? To summarise, monoculture itself is not of necessity bad for security, nor in theory is Microsoft monoculture, provided Microsoft is prepared and able to reform itself. If however it is not, then the Microsoft monoculture is a clear and present danger to global IT security, and it must be reformed via external means.

That is the document's argument, and it's a perfectly sustainable one, albeit not entirely susceptible to being boiled down into a headline soundbite.

What, presuming The Beast fails to rise to its reponsibilities, do you do about it, specifically? The authors argue that governments should accept that "competition is entangled with security policy", which if you accept their reasoning it is, and that "If governments are going to be responsible for the survivability of our technological infrastructure, then whatever governments do will have to take Microsoft's dominance into consideration."

So they should keep a watching brief on Palladium/TCPA, as "there can be no more critical duty of government and governments than to ensure that a spread of trusted computers does not blithely create yet more opportunities for lock-in." (There can, really, but you know what they mean) As regards current products they should note that for many organisations "the only thing keeping them with Microsoft in the front office is Office. If Microsoft were forced to interoperate, innovators and innovation could not be locked-out because users could not be locked-in."

So they propose forcing multi-platform versions of Office, for Windows, Mac and Linux, and perhaps insisting that these ship at the same time. They also suggest forcing Office to be split into components, although from where we're sitting it looks like Microsoft might be doing this anyway, and we don't expect that to make a great deal of difference.

Microsoft Exchange protocols should be standardised and opened up, and "governments must not permit critical or infrastructural sectors of their economy to implement the monoculture path". No operating system should have more than a 50 per cent installed base within key infrastructures, in both the public and private sectors. It's worth noting that they don't think Microsoft should be broken up into OS and apps companies, as they feel that would simply result in two monopolies. And maybe we shouldn't place too much emphasis on the specific measures they put forward - overall, what they're saying is that if you think something's not in the public interest and it won't reform itself, you have to whack it from the outside.

It is possible that governments might accept promises of reform, rather than coming to the conclusion that this isn't possible without their intervention. In this case: "If governments do not dismantle the monopoly but choose instead to modify the practices of the monopoly they must concede that that route will, like freedom, require eternal vigilance." Effectively, this is the difference between structural and conduct remedies. If you don't go for structural, then the conduct remedies have to be sufficiently stringent to make a difference, and you've got to make sure they're rigorously adhered to.

In this area, they lob in one intriguing possibility that we reckon might just play. Given that security failures cost customers a great deal of money, could not a more consumerist view of product liability be taken by the law? They argue that security failures could be deemed "per se offences" resulting in fines, jail or whatever for the vendor of the offending product. Now, what they mean is that when Sobig or whatever hits Microsoft could be busted into the next galaxy, but look at it in a more general way. Are software licensing "agreements" that say that by using this product you agree that it's all your fault, that it's only broken to the extent that it ships 'as is' and therefore if you think it's broken you accepted that this was the case when you bought it, and anyway you agreed it wasn't and you didn't buy it anyway, because it's still ours..."

Er, where were we? But you know what we mean. Software licensing agreements are an outrage and it's high time the law made vendors face up to their responsibilities and told them to shove their licences up the appropriate end. That'd play with the public, and would help concentrate Microsoft's mind on the security issue as collateral.

You can get the whole study here, and we recommend you do - its arguments are stronger and more complex than the headlines might suggest. ®