"
Listen, I ran Debian with that faulty SSH that was patched, but I didn't apply that patch for months, simply because I didn't *know*. You would move that into "faulty system config".
"
- Before patch availability, it's a software fault and the developer is responsible for the time until patch release

- After patch availability, it's an administrator fault and since we're talking Debian:
-- Before the patch; http://lists.debian.org/debian-security-announce/
-- After the patch; http://www.debian.org/security/

Same for any other platform, keep up to date with the bug reports and security patch announcements.

"
But the same things generally apply to Win32 exploits. They don't stay open for months, days, or years, once discovered
"

- The currently known and unpatched SSL vulnerability
- CIFS continuing to use a cleartext protocol
- autorun.inf finally getting patched last week after being known since Conficker got publicity
- how long was IIS wide open before they finally fixed that little joy

Microsoft is not the only company to ignore bug reports unless they embarrass the company enough to address them. Apple's "there is no fault in our TCP/IP stack and NIC driver" followed by a TCP/IP stack and NIC driver patch some six months later is another great example. It becomes more important to provide good GR images rather than admit to the bug and patch it quickly.

"
(and an undiscovered vulnerability on Win32 is the same risk as an undiscovered vulnerability on *nix... exploitable until discovered and fixed).
"

No one is suggesting blame for unknown vulnerabilities. The clock starts from the moment it's discovered and ends when a patch is available. The clock shifts to the admin once the patch is available. The clock stops when the server is no longer vulnerable.

It seems that breaches on windows systems tend to be through a vulnerability in the software. Bad configurations happen also but exploited bugs and design decisions behold the admin's configurable control make up a noticeable amount. Can I simply configure CIFS to use encrypted protcols? Was there a configuration that plugged the buffer overflows in IIS?

With *nix like systems, the breaches reported seem to more frequently be configuration related; poor admin passwords, lack of firewall rules, PHP config rules left active returning too much information, development only settings left enabled leading to cross site scripting. Software vulnerabilities happen but they don't seem to be left open as long.

In the case of the article which start this whole thing; FTP was used unencrypted and weak passwords where used (blank admin password I think actually) - that's not a fault in the administrator?

It's more a matter of all three categories; social, software, config. Social applies to all. Software is heavier on the windows side. Config is heavier on the *nix side. The difference is that administrators can learn to harden a config but they can't learn to compile a patch into a proprietary binary. Because of that, I consider software flaws to be worse than config flaws and patch times more critical a metric to look at.

"
"software code faults" (of a notoriously buggy OS code base) doesn't seem to make that much of a difference - other than it allows you to go, "if it happens to Linux, it isn't Linux, it is idiots using Linux".
"

Just encase it's not clear; it depends on where the fault is found. Was it in the software, was it third party software, was it the system admin's failing? Attacks against the notoriously buggy platform have been successful due to administrator controlable settings; config. I see the daily bug reports in the rest of the code base but the exploitable one's don't seem to remain usable long enough to gain widespread use. Thus, config is the larger threat to security on these systems.

If Linux based systems are of issue then we can look at security over the BSD side. Again, config errors are a larger threat than remote exploit bugs in the software. OpenBSD would be a heck of a baseline to measure the other platforms against for security purposes.

I admit that I can't agree on the obscurity angle. I'd rather put mechanisms in place and keep obscurity as an icing sugar dusting on top. What do I do when the obscurity advantage, being horrendously short lived, is gone. Great, so now they know I'm using MAC filtering on my wifi, what mechanism actually prevents them from connecting?

I'm actually very curious to see what distributions continue to hold up as they gain popularity. What distributions will continue short patch turn around. What distributions default config will hold up under the pounding. These are not limitations imposed by a third party (cough.. hardware..) so they are good metrics to look at.

I also wouldn't claim your a fanboy but at what point does constant criticism start to be come suspect? How long could one engage every Windows or osX focused discussion with only criticism before it no longer appears as if they are being constructive?