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.
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.
On the Security 360&nbsp;webcast that was on earlier today, the topic was on "browser hardening".&nbsp;...
"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."
That is all well and good as long as each system is capable of taking that responsibility and that systems enforce the access policies you set up.
Unfortunately, in an era of half a dozen security related defects a month that allow people to override all the planning and access controls that may have been put in place, people have had to put up additional barriers whose necessity is not always obvious. They're necessary because with today's defect ridden, complex products defense in depth is required to overcome failures in access control
And while "high" security is absolutely necessary to protect life and property, today's mega data disclosure of the week certainly doesn't lend confidence to our information infrastructure. Nobody is dying ( yet ) but of what value are privacy policies and disclosure laws in such an enviroment where accounts and identities are ravaged? Disclosure is the least of the problems. If the access to the data isn't being protected, how can its accurracy be trusted? How much confidence can be placed in automated business processes (commerce, health, governement) based on data and processes that have been compromised so often?
When the environment is made up of defective products that are too complicated to properly run safely in compatibility with resource requirements and business "needs" driving by marketing drivel, the grunts made responsible for security are left holding the bag of unpopular security recommendations because the vendors and decision makers are pulling the wool over all our, and their own, eyes.
Universal Identity management, SSO, and automated access controls are fine when they work. When they don't, or when they're compromised, all hell is going to break loose. They're business convenience drivers...not security products.
Gary? How many of these defects are in our applications? Shouldn't they too step up to the plate and join in the cause? Just today.. I saw two vuln notices about two security products (Trend PCCillian and Interscan no less) that had bad/weak ACLs/DACLs.
How have these identities been stolen? Unencrypted tape backups (hello folks computer rule 3 of physical access) for one. Improperly designed databases that were not properly protected from attacks for another.
I got a notification from Guidance software that a database that had my credit card number on it was broken in to.
1. Why were they storing my credit card number a year after I bought something from them?
2. Why was it not encrypted?
Guidance Software is a forensic investigation company..shouldn't they know better?
How many of these identity thefts were due to just not doing the right thing in the first place?
Remember I'm not the military... at the end of the day my business needs will always be one notch above security demands. Unlike the government...if I don't have business, there's nothing for me to worry about securing. So business needs have to come first, unfortunately.
And for many firms with hooks and add-ins into insecure applications like our accounting applications like ..say Quickbooks, you aren't just ripping out the beancounter program but your hook into the CRM app or the trouble ticket app... etc...etc... these days you are also ripping everything else that plugs into it.....add to that the marketing spin around software that once we finally deploy it, it never works as advertised because the firm never buys all the bells and whistles that was demo'd to him... and ...well...Vendors do not even know how their
product works. Only the users do and by the time you figure out it's not working... you are 3 million dollars into a Multilayer'd app implementation project and the Dev folks and the timekeeping app folks are telling you they can't get the information that you need and there's nothing they can do....the universe has these little bridger Excel spreadsheets all over the place because applications never quite do when they are supposed to do and Excel is the foundational tool to get things to work that the salesman assured you would work in the first place.
Migration sucks. That's the bottom line. Humans hate change.
It makes for great Quickbooks sales as well as everything else that we currently use. Because as much as we hate the programs ..they are good enough. It's not the pressure to buy it.. it's the pressure that it works.. and don't screw up what works.
Sometimes I can't 'not buy it'... I have to get them to fix it. I need the functionality they provide... They need to get security. I can't walk away. Bigger firms can help push by putting it into their RFPs. I can't do it alone. I just have to get really annoying so they get me to shut up and hope that the marketplace (and pressures of Vista's LUA) help.
Those who know me (and unfortunately who have to put up with me) know that sometimes only duct tape over port 25 gets me to shut up and to stop being annoying.
Unfortunately, it seems that people are getting the impression that I hate hardening guides.&nbsp;A few...