I Really Do Not Hate Hardening Guides

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.

Comments

• Anonymous
  May 17, 2006
  Sadly, the "myths" series is constantly myth-interpreted.
  When you say "A always helps" is a myth, what you are saying is "sometimes, A may not help at all, or may not help enough to be worth doing".  You're not saying "A never helps".
  This is the sort of thing that trade journals love to report on, of course - you say "changing passwords frequently" is a myth, they say "Microsoft representative says not to change your passwords".
  Good luck reminding people that the myths articles should be interpreted as a warning to re-investigate those assumptions that are situational, but which we've trained ourselves to believe are global axioms.
• Anonymous
  May 17, 2006
  As a "financial auditor" who also looks at systems controls... if you look up the word "auditor" in the dictionary you will probably find "checklist filler-outer".
  
  We don't think.  We don't look.  We tick boxes.
  
  We say things like "Oh that's not in compliance with such and such" and to every industry person I say to them.. ask that auditor to "prove it" with the code section from the SEC, Department of Heath,etc that says in black and white where SOX or Hipaa or any of these regulations specifically state what they want.  The reality is that many of these laws were put in place to be purposely vague.
  
  Oh and the next thing we do ... the field auditors are typically young, green and haven't a clue.  The folks in industry train the consultants and not the other way around.
  
  Yes, I know that's stereotyping, but we're not thinking... we're just ticking boxes because it's easy to tick boxes.
  
  There was a Center for Internet Security project that attempted to put forth the minimum security needed to protect sensitive data and the initial steps used the Visa PCI standards.  As one person put in on the threads "did the Hardware vendors make these rules up?".  It was obvious that because each sized firm's risk model was so different, that it was near impossible to do a one size fits all minimum.  
  
  Even the California law AB1950 that states I must take reasonable measures does not define what those measures are.
  
  As SBS var/vaps are getting into the "managed services" field, they too are asking for 'checklists" and the ones who have paved the way say things like "you know, we have this memory jogger like form...but we really don't like to use a checklist".
  
  Listen.
  Think.
  Then do.
• Anonymous
  May 17, 2006
  Hi,
  
  I was wondering if the "Security Myths" presentation from the Microsoft's Federal Security Summit was available for download on the internet?
  
  cheerz,
  
  Tom
• Anonymous
  May 18, 2006
  Susan, you said it, I didn't. :-)
  
  It is really sad, actually, that what at the core is a really noble profession of auditing, has been twisted into checkbox filling by some of its practitioners.
  
  Oh, and Tom, there is a taped version of the Security Myths in the Listening Room at the Protect Your Windows Network site: http://www.protectyourwindowsnetwork.com/listening_room.htm
• Anonymous
  May 19, 2006
  I agree with many of your views, particularly on how a good security auditor should work.
  
  Are many of the comments on these blogs written by Microsoft colleagues?
  
  I have read postings on a few Microsoft blogs. Some names seem to appear frequently. The way some of the comments are written it sounds like the authors are Microsoft employees (or close partners).
• Anonymous
  May 21, 2006
  Anette, some of the people that comment are MS employees, but I think most are not. I think the ones that appear more frequently are either friends or folks that just spend too much time online. :-)
  
  Actually, I see no current MS people commenting on this particular topic. Maybe there is a reason for that?
• Anonymous
  May 22, 2006
  Thanks so much for your presentation last night at BIG - great to hear from someone who is willing to do some of the thinking that is required that prompts all IT security people to realise that some of the things they do isn't actually helping...
  
  I agree with your comments on hardening guides and auditors. Too much blind faith is put in these (and "consultants") to ensure we are 'securing' our networks, when really a little bit of lateral and even logical thinking would help us no end. That, and the willingness to alert the business to the need to educate staff to WHAT security is in the context of computers/PDA's/etc, etc, etc. Give me one educated (and as you mentioned last night, paranoid) staff member over 30 techno-phobes any day.
• Anonymous
  May 27, 2006
  Hi,
  
  I understand the (some of) the pain of people suggesting things that you don't support.  At the same time, I've spent way too much time on security guides, and have no idea what the "correct" channel for suggesting useful tweaks is.  (I tend to email friends, but that's variable in the response, usually driven by their workload on a given day.)
  
  Many of these unsupported changes, on a variety of operating systems, have saved my employers from a great deal of pain.