Skip navigation

Dispelling 4 Security Myths

Security configuration changes and guides have been around for about 10 years in the Windows world, longer in other areas. The original Windows NT 4.0 guides that were published by the U.S. National Security Agency and the SANS Institute were basically just lists of changes, with a little bit of rationale behind each setting but no overall cohesiveness. They were a response to a demand for what we call the "big blue 'secure-me-now' button." The problem is that such a button does not exist. If it did, the vendor would ship it.

There is a lot at stake in security configuration guidance. First, it is easy to understand why people are clamoring for it. Everyone can see the benefit in turning on some setting and blocking an attack. In some environments, doing so is not even an option. A system must be configured in accordance with some security configuration or hardening guide to be compliant with security policy. In other environments, security configuration guidance is strongly encouraged. Before you start making security tweaks, however, we feel that it is very important that you understand some of the fundamental problems with them. These are what we call the myths.

To avoid sounding like we hate security guides (which we do not), we want to point out that we have taken part in authoring, co-authoring, or editing almost all the commonly available guides for Windows in the past 10 years. Guides that are done right are valuable, but to do them right you must understand what they cannot do. That is why the myths are important.

This section is somewhat (OK, very) cynical. Take it with a grain of salt and laugh at some of the examples we give. Do not lose sight, however, of the message we are trying to get across: These are myths. If you are careful to avoid falling into the trap of believing them, you will be able to focus your efforts on the things that make a real difference instead of being lured like so many others into staring at a single tree and failing to see the security forest.

Myth 1: Security Guides Make Your System Secure
Hang on, why is this a myth? Isn't the basic purpose of a security guide to make you secure? Yes. That is the general idea. However, the term "secure" connotes an end-state that we will never actually reach. Security is a process, to be evaluated constantly. There is nothing that will put you into a "state of security." Unfortunately, many people (surely none of you readers, though) seem to believe that simply applying some hardening guide to a system will make it secure. This is a fallacy for several reasons.

First, consider any of the recent worms, Sasser, Slammer, Blaster, Nimda, Code Red, ILOVEYOU, and Friends, etc., ad nauseam. Because all of them exploited unpatched vulnerabilities, not one of them would have been stopped by any security settings. While most of the guides tell you that you need the patches applied, we have seen many systems whose owners felt the patch was not important because the guides were applied. If you're unsure of which patches to install, the proper answer is "all of them." Ideally, though, you should have more of a process around patch management. Few settings can prevent your network from getting attacked through unpatched vulnerabilities.

Second, settings rarely stop real attacks. There are a few things that are harder to do, but in general, networks do not get attacked through settings that can be turned off. There are a few exceptions. For instance, a security guide might turn off storage of LM Hashes to make cracking passwords much harder. A guide might also make anonymous enumeration harder, but attackers almost always have access to some account that can be used instead of anonymous connections.

This is largely because security guides are meant to be simplistic, while sophisticated attacks are complex. Security guides provide a great starting point, but to really improve your security you need to do a lot more. Generally, you would need to resort to complex measures to stop complex attacks, and complex measures do not package well in the form of a security template.

A security guide does not make your system secure. At best it provides an additional bit of security over the other things you have already done, or will already do, to the system, as explained in other chapters. At worst it will compromise your security. For instance, a guide may very well compromise the availability portion of the Confidentiality-Integrity-Availability triad by destabilizing the system.

Myth 2: If We Hide It the Bad Guys Won't Find It
If we had a dime for every time we had seen someone try to hide their system… Hiding the system so rarely helps. Some examples are in order. For instance, some people advocate turning off SSID broadcast in wireless networks. Not only will you now have a network that is not compliant with the standard, but your clients will also prefer a rogue network with the same name over the legitimate one. Oh, and it takes a few minutes to actually find the network anyway, given the proper tools. Another example is changing the banners on your Web site so the bad guys will not know it is running IIS. First, it is relatively simple to figure out what the Web site is running. Second, most of the bad guys are not smart enough to do that, so they just try all the exploits, including the IIS ones. Yet another one is renaming the Administrator account. It is a matter of a couple of API calls to find the real name. Our favorite is when administrators use Group Policy to rename the Administrator account. They now have an account called "Janitor3;" with a comment of "Built in account for administering the computer/domain." This is not really likely to fool anyone.

Generally speaking, renaming or hiding things is much more likely to break applications than it is to actually stop an attack. Competent attackers know that administrators rename things, and go look for the real name first. Poorly written applications assume that the Program Files directory, for instance, is in a particular place, that the Administrator account has a particular name depending on region, and so on. Those applications will now break. Arguably, they were already broken, but the result is that they no longer function.

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 access control lists (ACL), 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 make more changes you will be more secure.

We distinctly remember a headline from late summer (in the northern hemisphere) 2003. It read "Dell Will Sell Systems That Are Secure by Default." Dell had just announced it would start selling Windows 2000 systems configured with the CIS Level 1 benchmark direct from the factory. The article pointed out that this guide applies "over 50 security changes … significantly improving the default security of Windows 2000."

It turns out that there were a few problems with that statement. First, the benchmark only made 33 changes, not "over 50." Second, only three of them had any impact on security. Lastly, while Dell may have configured some security settings on the system, it was being sold without the latest service pack slipstreamed, which seems to us would be a basic security requirement. Don't 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. But it was presented as a way to get a "secure" system, when there is obviously no such thing. In addition, 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 through the network; 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, not to mention how unlikely the other requirements are to occur together. We would be 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 advocated for years. The former is designed to ensure that when you set a share password it is obscured in the user interface dialog; on Windows 95. The setting has not worked since then (Windows NT, Windows 2000, Windows XP, and Windows Server 2003 have 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 configured on 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 understand neither security nor 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 does not improve security.

  • Settings that only modify behavior already blocked elsewhere do not improve security (although in some cases defense in depth is appropriate as 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). The following 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.

    Myth 4: Tweaks Are Necessary
    Some people claim that you cannot have a secure (read "protected") system without making a bunch of tweaks. This is an oversimplification. Tweaks block things you cannot block elsewhere. For instance, if you have two systems on a home network behind a firewall or you have a corporate system that has IPsec policies that only allow it to request and receive information from a few well-managed servers, those systems will probably be safe without making any additional tweaks.

    Even on highly exposed systems, most of the tweaks are not necessary. In eWeek's Open Hack IV competition in 2002 (see, we built what was probably the most protected network we have ever built. In all, we made only four registry tweaks, a couple of ACL changes, and set a password policy. The rest of the protection for those systems was based on proper network segmentation, a solid understanding of the threats, turning off unneeded services, hardening Web apps (see Writing Secure Code, 2nd edition, by Howard and LeBlanc \[Redmond, WA: Microsoft Press, 2003\]), and properly protecting Web servers and the computer running SQL Server. Of course, this was a specialized system with very limited functionality, but it still shows that less is often more.

    Proper understanding of the threats and realistic mitigation of those threats through a solid network architecture is much more important than most of the security tweaks we turn on in the name of security.

    Hide comments


    • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

    Plain text

    • No HTML tags allowed.
    • Web page addresses and e-mail addresses turn into links automatically.
    • Lines and paragraphs break automatically.