Myth 3: The More Tweaks, the Better

Security guides contain a lot of settings, and why not, there are a lot to choose from. Windows Server 2003 contains 140 security settings in the Group Policy interface, and that does not count ACLs, service configuration, encrypting file system (EFS) policies, IPsec policies, and so on. The "best" configuration for these for every environment is nebulous at best. Therefore, a number of people take the approach that if you only make more changes you will be more secure. We distinctly remember a very memorable headline from late summer 2003 (in the northern hemisphere). It read "Dell Will Sell Systems That Are Secure by Default." Dell had just announced they would start selling Windows 2000 systems configured with the CIS Level 1 benchmark direct from the factory. The article went on to point out that this guide applies "over 50 security changes ... significantly improving the default security of Windows 2000."

Well, there were a couple of problems with that statement. First, the benchmark only made 33 changes, not "over 50." Second, only three of them had any impact on security at all. And third, although Dell may have configured some security settings on the system, it was being sold without the latest service pack slipstreamed, which would seem, at least to us, to be a basic requirement for security. Do not get us wrong, it is encouraging to see vendors that step back and look at older operating systems and evaluate whether they can be made more secure than what was considered prudent several years ago when they were first released. The problem, however, is that first this was presented as a way to get a "secure" system, when there is obviously no such thing. Second, the vendor had missed many of the basic requirements for a protected system.

Many settings people make have no real impact on security. Consider, for instance, the "Restrict floppy access to locally logged on user only" setting. It ensures that remote users cannot access any floppy disks via the network. However, this setting works if and only if (IFF) a user is currently logged on to the system hosting the floppy (otherwise, the setting does not take effect), and a share has been created for the floppy disk (not done by default), and the ACL on the share specifies that the remote user can get to it, and the system has a floppy drive in the first place, and there is a disk in it. Most systems sold today do not even have a floppy disk drive, not to mention how unlikely the other requirements are to occur together. We are inclined to say that this setting has no impact on security whatsoever.

We are also very fond of the NetworkHideSharePasswords and NetworkNoDialIn settings that several of the guides have advocated for years. The former is designed to ensure that when you set a share password it is obscured in the user interface dialog; if you are running Windows 95. The setting has not worked since then. (Windows NT, including Windows 2000, Windows XP, and Windows Server 2003, has never supported share passwords.) Of course, even on Windows 95, the setting would have been much more effective had it been spelled correctly (network\hidesharepasswords). The latter setting, also misspelled, controlled modem dial-in permissions, also on Windows 95. In spite of the fact that these settings have never worked on any Windows NT-based operating system, there are still "security auditors" running around explaining to management that the security guys are not doing their job unless these two settings are configuredon Windows 2000 and even Windows XP. Far too often, the guides we see are taken directly from obsolete and technically inaccurate documents for other, obsolete, operating systems. Then they are made a requirement by people who do not understand security or the operating system they are trying to protect. Actually designing security to a threat model seems to be a luxury when it is so much easier to just charge exorbitant consulting fees for parroting back what someone else, who also did not understand the product, claimed was correct.

There are some basic ground rules:

• Requiring settings that are already set by default do not improve security.
• Settings that only modify behavior already blocked elsewhere do not improve security (although in some cases defense in depth is appropriate so long as you do not break required functionality in the process).
• Settings that destabilize the system do not improve security.
• Misspelled settings do not improve security.
• Settings that do not work on the relevant product do not improve security.

If you are one of the unfortunate people who get evaluated based on the number of settings you make, go ahead and make a bunch of these meaningless changes. Heck, invent a few of your own (everyone else seems to). Here are a few you could use without breaking anything:

• HKLM\Software\Microsoft\Windows NT\CurrentVersion\DisableHackers=1 (REG_DWORD)
• HKLM\Wetware\Users\SocialEngineering\Enabled=no (REG_SZ)
• HKCU\Wetware\Users\CurrentUser\PickGoodPassword=1 (REG_BINARY)
• HKLM\Hardware\CurrentSystem\FullyPatched=yes (REG_SZ)
• HKLM\Software\AllowBufferOverflows=no (REG_SZ)

Make sure you set proper ACLs on them, too. This way you can show that you are actually doing much more than anyone else. If you also create a pie chart showing how much you are improving return on investment (ROI) with your careful management of security, your promotion into useless management overhead (UMO) is a virtual certainty!

Meanwhile, the rest of us will focus on actually improving security through designing security measures to a threat model.