Recipe for trouble, 2001-09-16
Did too many cooks spoil Windows XP security?
“
The first users of XP will be those at home, and I think this is cause for some concern.
”
Of course, the common element of all of these products, the "stock" if you will, is the operating system. While previous MS operating systems were all different animals, we find now that the XP/Whistler OS's are really just different cuts from the same beast. It seems to be an effort to get all the cooks into the same kitchen, select the best parts of each recipe, and present a culinary feast suitable for every palette while keeping the "Whine List" to a minimum.
My concern is the fat content. Will this lead to a product line resulting from careful selection of the finest ingredients, or will each chef walk up with a bowl-full of "Knows Best" and just dump it into the pot?
For example: SQL Server 2000 introduced "super sockets" support for data access via a DLL called "dbnetlib." It provides multi-protocol connectivity, encryption, and authentication; kind of a "roll up" of the different implementations of these technologies in past versions of the product. A system would only have this DLL if SQL Server 2000, the client administration tools, MSDE, or a vendor-specific solution was installed on the box.
However, with XP this DLL is part of the default installation-- even on the home edition. One has to wonder how a component goes from "installed only in specialized machines on a particular platform" to "installed by default on all flavors of the OS." What other components are now automatically installed that we don't know about?
The concern here is security. We have all been trained to separate the roles of our systems: Don't make your Internet web server a domain controller, don't run SQL on the Exchange server, and don't read email on your ISA server. This practice isolates potentially dangerous operations from processes that are prone to compromise.
So you can see why I get a little nervous when I see different components of these services getting installed by default at the OS level.
When I was a kid, I refused to eat peas. But my mother felt like I should have them, so she would try to hide them in my mashed potatoes to see if she could sneak them into my system. That was fine, as it was obvious they were there, and they were easy to pick out. It was not until she ground them up and directly integrated them into my potatoes that I began to protest. Not only were green potatoes entirely unappealing, but it was impossible to tell what was what.
One could argue that Microsoft might be doing the same thing when they include so many components, some unnecessarily, into their new OS.
There are two schools of thought here, and there are aspects of each that I can actually agree with. On the one hand, we can postulate that an enterprise purely composed of XP/Whister workstation and server products would be easier to secure as a whole given the wide application and portability of individual components. Hardening techniques, user and computer policies, and specific post-release add-ons (such as the current IISLockdown and URLScan) will be almost universal in their application across the enterprise.
On the other hand, there is real concern of a "single point of failure," in that Microsoft's new model moves us into the realm of having all systems share some of the same core components, with specific versions of the OS selected based on system role. This could dramatically increase the area of the "vulnerability landscape" when new exploits are discovered.
Consider the impact that Code RGB has had, given a minority target of Win2k boxes running IIS5; what would happen if a vulnerability was exploited against a target-rich environment where literally millions of systems could be involved? It is certainly something to consider.
Though XP will have many new security features, they will only be effective if they are properly used. In contrast to the rollout of Win2k, the first users of XP will be those at home, and I think this is cause for some concern. The more services and features that are available to an operating system, the more a mind must be set upon security if it is to be secure. It is a concept that most home users do not grasp, if they even consider it in the first place.
When Code Red found its way into the wild, many of us stood fast knowing that our "properly configured" systems were not at risk. Conversely, there were about 250,000 boxes found to be in a different state altogether. Without getting into the politics of who is responsible for what, we cannot ignore the fact these systems, deployed for business use, were either not patched, not configured properly, or both. What are we honestly expecting of the average home user?
My intent here is not to stir up any more hype surrounding the perceived evils of XP. In fact, it is no secret that I am a big fan of the product. However, I think that we must all change the way our security model is structured when we consider the migration that is to come. Because at some point, it may not be so easy to tell the potatoes from the peas.
