Windows DevCenter    
 Published on Windows DevCenter (http://www.windowsdevcenter.com/)
 See this if you're having trouble printing code examples


Security Myths: 392 Steps to a Hardened Server

by Mitch Tulloch
09/13/2005

"I'm a pedestrian sort of copper. I plod along and sometimes I find the truth, and sometimes not."

That line struck me when I heard John Thaw say it in an episode of Inspector Morse, one of my favorite old British TV shows. I liked it because that's the kind of person I tend to be also--slow, methodical, taking one step at a time, a stickler for detail, and an aesthetic appreciation for logical progression. Not too much deep pondering, please, since thinking hurts. I like it nice and easy, all laid out so I can see the end from the beginning.

That's why I like security guides so much. A good example is Microsoft's Windows Server 2003 Security Guide, which I reviewed in my weblog earlier this year. The guide gives advice on hardening Windows servers in various roles ranging from a baseline (i.e. roll-less) member server to domain controllers, infrastructure servers, file servers, print servers, and so on. Give me a step-by-step guide that tells me how to secure my servers and I'm happy. All I need to do is perform the 392 steps indicated and I'll have a secure network, and then I can sleep at night with no worries.

Well maybe I shouldn't close my eyes just yet. Microsoft has dozens of guides like this available. Just go to the Microsoft Download Center and search for "security guide" and you'll see. Other organizations have developed such guides as well. For example, the NSA has a whole slew of guides on hardening operating systems, applications, routers, and so on. NIST has a bunch of guides available on its Computer Security Resource Center (CSRC) website. So if you take all the steps on all the guides you can find for a particular server role and apply them, will that make your server completely secure? Actually, it'll more likely make it unstable and completely unusable!

What's wrong then with security guides? Why do they often disagree about which steps you need to perform to secure your server? Actually the problem is much deeper than lack of agreement between various guides. The problem is in the nature of the goal these guides set out to achieve, namely, to make your network secure. Why is such a goal unreasonable? Several reasons.

Related Reading

Windows Server Hacks
100 Industrial-Strength Tips & Tools
By Mitch Tulloch

First, security isn't a destination; it's a journey. So it's just plain silly to think that by performing a series of standard steps you can make a server secure against every form of attack. We don't even know what new kinds of attacks the bad guys will come up with in the future, nor do we know what hidden vulnerabilities will come to light when they probe the underlying code looking for weaknesses to exploit. So a security guide that says on page 1 that, "If you follow these 392 steps, you'll have a highly secure server," should be suspect right from the start.

And who needs a "highly secure" server anyways? The degree of hardening you apply to a server should depend on several things, including the threats your machine is likely to face and the environment it's running in (e.g. military, government, commercial, and so on). A server that's hardened to military-grade level is unsuitable for a small mom-and-pop business running a website to sell insoles for running shoes. Why? Because the more you harden something, the harder it is to use. In other words, there's a tradeoff between security and manageability (or usability).

So is a guide that recommends 392 security tweaks better than one that offers only 287? Not really. Imagine what might happen if you applied all 392 tweaks, or all 287, or even several dozen. A legacy application might fail. Users might have trouble logging on to the network. Performance might grind to a halt under certain circumstances. Even applying one tweak to harden your server is something you shouldn't do lightly. You need to try that tweak out in a test environment first and see how it affects the availability and reliability of your server, and the applications running on it. Then if you decide to apply that tweak, you need to clearly document the configuration change you made so you can go back and undo it if problems arise later on. And before you apply even that one tweak to your server, you need to decide whether the tweak addresses a realistic security concern or just a "what if" scenario that is highly unlikely to ever occur. In other words, more is often less when it comes to tweaking your server's configuration.

If you really only need to perform a few of the 392 or so tweaks a guide recommends, then is it enough just to perform these tweaks, kick back, and read a comic book since your server is now secure? Nope! Tweaking a server's configuration is only a small part (and maybe the smallest part) of hardening your network from attack. The things you need to do to secure your network, roughly in order of importance, are as follows:

  1. Design your network to be secure from the start using network segmentation, zones, and so on.
  2. Design your applications to be secure also (buying and reading Writing Secure Code is a good place to start).
  3. Ensure the physical security of all your critical machines (without physical security there is no security).
  4. Disable any network services your servers don't need to have running.
  5. Deploy patches as soon as you have the opportunity of testing them, or even sooner if they represent a critical vulnerability and a real risk to your business.

Then, finally, make the few remaining tweaks that can help mitigate real threats your network might face. These might be registry tweaks, changes to ACLs, changes to service accounts, and so on. Just do only the ones you really need.

Conclusion

To sum up, here's what I think a good security guide (used properly) should enable you to do:

Mitch Tulloch is the author of Windows 2000 Administration in a Nutshell, Windows Server 2003 in a Nutshell, and Windows Server Hacks.


Return to the Windows DevCenter.

Copyright © 2009 O'Reilly Media, Inc.