The Curious Tale of MS03-007

There's a tradeoff here between making a new feature secure by default (i.e., disabled) and making it easy for your customers to take advantage of it ("No configuration needed: It just works.")

How risky it is to have a feature enabled by default is a function of

a) The complexity of the feature.

b) The reliability of your development and testing process re: security.

and

c) The ultimate severity of any vulnerability.

At the time Windows 2000 was being developed (late '90s), Microsoft tended to systematically underestimate a) and c), while overestimating b). Then came an internal push for better security practices and billg's "Trustworthy Computing" memo. There's a good discussion of it and the consequent sea change here:

http://www.zdnet.com/article/10-years-since-the-bill-gates-s...

Enabling functionality by default makes it available to people on initial installation. From a convenience perspective, it seemed a plausible choice.

It took some effort to get people at Microsoft to start seeing things from a security perspective. The work Michael Howard (who wrote the "10 years since the BillG memo" article 'twoodfin linked to below), Jeannette Wing, and I did on measuring attack surfaces was part of this -- trying to quantify, even roughly, how big the attack surface was so that there could be explicit goals to reduce it. You're certainly right, though, OpenBSD was way ahead of their time here.

On a consumer OS if a feature is not enabled by default it might as well not exist at all. The vast majority of people won't discover it.

This is fine for OpenBSD, you are assumed to know what you are doing when you install it. But Windows gets installed for all sorts of people, many of whom will tell you to your face that they are "not computer people", and will be very annoyed when the OS doesn't magically do what they want.

Microsoft UK reps commented at a Win2k3 presentation that I went to that customers had complained NT4 didn't do enough out of the box. All sorts of features it was capable of required specific configuration and enabling. They made the point about security etc to their customers, but lots of customers still requested features to be turned on by default. The internet was still fairly nascent at the time, there hadn't been a major vulnerability through such mechanism etc. etc.

They listened to their customers. Which is often the right thing to do, but rarely when it comes to things with security implications, but it's fair to say that in general the tech industry was still fairly naive back then.

Win2k came with IIS enabled by default, etc. etc. etc. It was a security disaster. Microsoft decided from the next version on that convenience didn't trump security and went back to requiring you to consciously turn on services.

'Twas not just Microsoft.

Back then, "enabled by default" was the rule. I recall Linux distributions of that era also enabling a lot of network-facing stuff by default.

For Microsoft in particular, there's also some path dependence: they began with non-networked (or with local-only networking) desktop operating systems, where the drawbacks of default-enabling many useful services were not as severe.

It was a different, more innocent time. Your $500k Sun box shipped with broken tools, and horrifically buggy RPC on by default.

Military (or something in the whole war apparatus) was running networked Windows 2000 in some mission critical role and was worried about being compromised by a cyber counter-attack once they started offensive action.

Nah, the implication is just that once the shooting starts, there's no reason not to exploit whatever security holes you've found at the cost of being "provocative".

To be honest, WFP has existed since Win2000 too.