CyberInsecurity then takes its cue from a close relative, security by obscurity, by recommending security by complexity. Their premise is “If no one can understand more than a fraction of a complex system, then, no one can predict all the ways that system could be compromised by an attacker.” Of course, the authors do makea valid point. Organizations that rely solely on a single vendor are at far greater risk than those who choose to diversify. But do we need 16 pages of build-up to tell usthe same thing Grandma's been saying for generations:Don’t keep all your eggs in one basket.
Again pointing the blame finger, the authors hone in on integrated applications as being largely responsible for what they refer to as “code bloat”, thereby increasing the amount of code required and thus proportionately increasing the risk that the code is flawed in some way, i.e. susceptible to attack.
CyberInsecurity then swings round to the patching dilemma, noting that “Two different subsets of users effectively bow out of the patching game: the incapable-many (end-users who have limited understanding of – and limited desire to understand – the technology even when it is working correctly) and the critical-infrastructure-few (for whom reliability is such a vital requirement that casual patching is unthinkable).”
For theirexample, the authors rely on Slammer, an interesting choice considering it infected a nuclear plant which one would presume fit into the “critical-infrastructure-few"(Remember, these are the folks "for whom reliability is such a vital requirement that casual patching is unthinkable.”) Apparently, it is not that unthinkable. Indeed, speculation continues that the Northeast coast blackouts were further facilitated by infections of the Blaster worm, further illustrating that the “critical-infrastructure-few” are hardly model examples of proactive patching.
By page 18, the goal of the authors is clear: “Microsoft should be required to support a long list of applications (Microsoft Office, Internet Explorer, plus their server applications and development tools) on a long list of platforms. Microsoft should either be forbidden to release Office for any one platform, like Windows, until it releases Linux and Mac OS X versions of the same tools that are widely considered to have feature parity, compatibility, and so forth.”
Isn’t this a convoluted way of saying if we can’t force the end user to adopt inferior products, let’s force the manufacturer of the superior products to develop it when, where, and how we see fit? Further, isn’t it a form of reverse discrimination, i.e. forcing Microsoft to release products for competitive platforms prior to its releasing it for its native Windows OS? In any event, there already is a Microsoft Office product for Mac OS X and that fact certainly hasn’t caused organizations to dump Windows in favor of a Mac. And just what ramifications would this proposal, if adopted, have on third-party developers who code products that work alongside some of these Microsoft Windows-based applications?
