Some organizations put too much emphasis on hardening guidance
I have been working on hardening guidance for almost 10 years. The first few I worked on were essentially lists of settings that we thought you should turn on. Basically, if something sounded like it might have to do with security then it must be turned on. To say that it was basic and naive approach to security is an understatement.
Eventually, I learned that to really do hardening effectively you have to put a lot of thought into it and consider the threats that the system is subject to. That lead to the list of scenarios that you see in the Windows 2000 Security Hardening Guide. The natural progression from there was to split the guidance into threat levels, which is what you see in the Windows Server 2003 Security Guide. However, all that time, it nagged me that I could still break into a system with all that guidance turned on because either there were missing patches, or some operational practice let me in, or some third-party software was installed and was insecure. In fact, much of the "hardening" that was in those two guides really did not help your aggregate security posture much. By contrast, the most secure system I have ever built had only four or five tweaks on it.
The fact is that hardening is still done in fairly outdated ways. Everyone wants the big blue "secure-me-now" button, but security is far more complicated than that. The frank answer is that there is no single button or switch you can throw that makes you secure. What makes you protected (as opposed to the finite state of secure) is to take a reasonable approach to risk. You have to first understand what risks you are facing and then decide which you want to mitigate. Then you have to understand how to mitigate them, and that is so seldom possible by throwing switches. Generally, the switches that are available are designed for very specific scenarios and fit a relatively old view of security because that is what a portion of the market place demands. They are made to counter threats that were realistic and serious 20 years ago, but that are largely not the issue any longer. Many of them are also on by default now, or are superseded by more modern functionality.
Moreover, throwing bunches of switches typically produces an unsupportable and unstable system that may not perform the tasks you need it to perform - all to mitigate a threat you have not enumerated yet. If you start by actually analyzing the threats you find that the things that really make a difference are not anonymous restrictions on listing account names and whole-sale access control list changes. Rather, what makes a difference is analyzing whether your system should be providing a particular service, if so to whom, and then enforcing that. What makes a difference is ensuring that only those systems and users who absolutely need to communicate with you are allowed to do so. What makes a difference is ensuring that all applications and users run with the least possible privilege. In short, what makes a difference is taking a sensible approach to security and doing the difficult analysis so that you can allow each system to take responsibility for its own security.
This is why the modern approach to security is exemplified by things like Domain and Server Isolation, the Security Configuration Wizard (SCW) in Windows Server 2003 Service Pack 1, and the Configure E-Mail and Internet Connection Wizard (CEICW) in Windows Small Business server 2003. These tools walk you through the process of understanding the scenarios you have to support and then help you lock down your system while actually doing that. Granted, they are not the panacea we all want, and they are more complicated than the big blue secure-me-now button, but they give you much better security than any of the guides and they produce a supportable configuration that actually does the tasks you purchased the software for.
What this all means is that we cannot rely on other entitites or simple tweaks to provide our security any longer. Each asset must be capable of defending itself because concepts like perimeter and internal network are so close to meaningless today. The fact is that the vast majority of "internal networks" today are at best semi-hostile. We need to understand that and take appropriate steps, not apply knee-jerk hardening guidance.
This post was precipitated by a guest on a web cast this morning that recommended to small business users to go to the Department of Homeland Security and download a hardening guide for Internet Explorer. Why should we expect a government agency that is charged with protecting the military and national security establishment to provide sensible guidance on how to secure a web browser in a small business? That is a perfect example of the outdated mode of thinking with respect to security: "it is issued by a three-letter agency, therefore it must be high security and that's what I want." This is inappropriate. It is particularly inappropriate because most of the establishments that require those types of guides and that fund their production cannot run with them since they have so much legacy in their environment.
High security is not for everyone, in fact, it is usually not even possible in environments that should consider using it. High security is not an end goal toward which we should all strive. It is a specialized configuration for systems where people will die if the system is compromised. If that fits your risk profile and threat model, then by all means, use high security. If not, then you should use something lower than that. More than likely, any of the tweaks you can throw are already set to appropriate levels since they are set to a more moderate risk profile by default. The default state, at least of Microsoft products today, is at a level that provides a reasonable trade-off between security and usability/usefulness/performance. As far as traditional hardening goes, it is typically done for you. Now you need to consider other security means. A good place to start would be the TechNet Security Center.
Comments
- Anonymous
January 01, 2003
Unfortunately, it seems that people are getting the impression that I hate hardening guides. A few... - Anonymous
January 01, 2003
On the Security 360 webcast that was on earlier today, the topic was on "browser hardening". ... - Anonymous
March 21, 2006
Security as a "yes" / "no" question always (for practical purposes) gives the answer "no, this is not secure".
Security in real life, in business or at home, is always a risk-management effort. There's cost and benefit, and a guessed probability as to which side of that divide you land on.
It sounds like what you're describing in this article is a Service Oriented Architecture for security. Security provides services and has customers to provide those services to. Security is an enabler of desired activity, not a stop sign.
Once security is seen as an enabling force, people stop trying to subvert it in order to do their jobs, and realise that their jobs are helped by your security measures.
Good luck with that. - Anonymous
March 22, 2006
The comment has been removed - Anonymous
March 22, 2006
The comment has been removed