Unfortunately, it seems that people are getting the impression that I hate hardening guides. A few people told me that after I delivered the "Security Myths" presentation at Microsoft's Federal Security Summit West last week. It is really not the case.
I do not hate hardening (or security) guides. In fact, I really like them - properly used. As it turns out, I have had a hand in writing, architecting, testing, or at the very least, commenting, on just about every major security guide for the Windows family of operating systems over the past 10 years or so, with only one major exception. Properly used, a good security guide can be a powerful tool in the Infosec manager's or risk management consultant's arsenal. There are several very good security guides for Windows out there, such as the Windows 2000 Security Hardening Guide (which I wrote), the Windows Server 2003 Security Guide (which I designed much of the architecture for and helped develop), the Windows XP Security Guide (which was based on the Windows Server 2003 Security Guide and used the same basic architecture). I also worked on getting the National Security Agency (NSA) endorsement for the Windows Server 2003 Guide.
That all being said, the Security Myths presentation may seem highly critical of security guides, and with some intent actually to be so. You see, the problem, as I see it, with security guides is the fact that far too many people put blind faith in them, and use them as a substitute for proper risk management. The Security Myths presentation is designed specifically to make people question the common wisdom about security guides, thereby being able to put them to better use. There is this perception that if we simply apply a security guide we are done with security, or at the very least, we have done our "due diligence." I do not believe that either is true. If the organization has analyzed the risks they are facing, have determined their threat profile, have worked on developing a set of countermeasures to those risks, and it turns out that their risk profile can be mitigated at least to some extent with a security guide, then that is a proper use of the guide. However, what far too many people do is they start out by saying "Right, we need a security guide for these systems before we can deploy them, because otherwise they are insecure." That statement carries no understanding of the risks the systems are facing, no concept of what defense in depth means to that organization, and no real analysis of whether the guide really mitigates any of the threats they find interesting. In many cases it leads to staying with a much less secure system, in favor of a much better one, because there is a security guide for the older, insecure one, and there is not yet a guide for the new one - the one that is developed against a modern threat model. That type of decision is likely to decrease security, not increase it.
This can be taken to extremes. One of the topics covered in the Security Myths presentation is non-existent settings. Believe it or not, but we find them on a regular basis in various security guides. My personal record is a guide from a defense agency in Europe that had six required settings that do not exist in the platform the guide applied to (four of those did not exist in any platform I know about). This may sound like something you can just shake off; however, the problem runs deeper than that. After one of the major security guides required two non-existent settings about four years ago we started seeing many security auditors require those settings to be made on all systems, otherwise they claim those systems cannot possibly be compliant with HIPAA, SOX, GLB, or whatever other buzzword the auditors claim to prove compliance with. Don't get me wrong, doing what is required to be compliant with all those regulations is very important - but applying non-existent security settings to your system will do nothing to get you there.
Unfortunately, applying existing, but improper, security settings will not get you there either. Many guides require tweaks that simply are not supported by Microsoft, such as modifying Access Control Lists on system files. Other settings are supported, but not widely tested, or simply inappropriate for many systems. For example, turning on SMB Message Signing, prior to Windows XP Service Pack 2 and Server 2003 Service Pack 1, mitigates a very important attack, but it may also incur an overhead of up to 40% on file transfers. In some environments those settings may still prove valuable and proper, but that is completely environmentally dependent. What some of the people using these guides fail to do is analyze whether the systems they are analyzing really need those settings or not, and whether the business needs of those systems permit their use. Instead, some auditor comes in and runs am automated tool against whichever security guide they have chosen to use, and then point out all the discrepancies. A good auditor would never just hand over a print out of the findings from a vulnerability assessment tool. A good auditor would work with the organization to analyze those findings in relation to the business needs, the risk management strategy, and help the organization determine what their actual unacceptable exposure is.
Finally, security guides, as I mentioned earlier, are not a substitute for all the other parts of risk management. There is a common misnomer that a security guide, by itself, makes your system secure. That is unfortunately not true. Together with other methods, such as server and domain isolation, and proper threat modeling and dependency mitigation, it is a highly valuable tool, but if the security guide is all you use, your system is probably only marginally more secure than it was to start with. In fact, in the most recent version of the "How To Get Your Network Hacked in 10 Easy Steps" presentation, the one developed in August of 2005, I actually perform the attack on systems hardened essentially to the military guidelines. There is a taped version of the presentation in the Listening Room at the Protect Your Windows Network site, in case you were not at TechEd Australia, or one of the other events last fall (spring down under) where I delivered it.