The basic skill in securing your environment is to understand the big picture. In other words, not only how to secure your computers and networks, but also what your limitations might be. We've all heard of the principle of least privilege. If an application or user has privileges beyond what they really require to perform their tasks, then the potential exists for an attacker to take advantage of that fact to compromise your environment. In the past, many domain administrators only had one account that they used for everything - reading email, administering the domain, writing documentation etc. So if that administrator's account was somehow used to launch an attack, the attack was carried out with all of the domain administrator's privileges - often to devastating effect. Many environments now separate the accounts based on the work being done. For reading email etc, a domain administrator would have a normal user account. However they would have a second account that they would use for administrative tasks. By separating the roles, the you reduce the risks of widespread compromise.
Another key phrase that we're used to hearing is "Defense in Depth". What does this mean? If you use the analogy of the onion, then each layer that you peel away gets you closer to your critical asset(s). At each layer you should protect your assets as if that was the outermost layer. The net result is an aggregated security model. The most common example of this is when dealing with email - incoming mail is filtered by the server for spam and malware, as well as on the client when email attachments are scanned before they are opened.
We mentioned the "Attack Surface" in the first paragraph. What exactly does that mean? If you think about it, an attacker only needs to know about a single vulnerability in your environment. As the administrator, you have to know about all of your potential weaknesses - your attack surface. The smaller the attack surface, the fewer potential targets for an attacker to exploit. Reducing the attack surfaces takes a number of forms, such as limiting access to a machine, not installing unnecessary software, and disabling unneeded services. One of the offerings in the Windows Server 2008 family, Server Core, dramatically reduces the attack surfaces by providing a minimal environment to run specific server roles. We discussed this in an earlier post, called " Getting Started with Server Core ."
One of the keys to security in an environment is the design. Security should be an integral component of network and infrastructure design - the old adage, "an ounce of prevention is worth a pound of cure" is perhaps the best way to express this. Beyond the initial design however, the actual deployment and ongoing maintenance of the environment have a major impact on security. One example of where you may run into problems is if you attempt to secure a database application after it is implemented. The very real risk in this scenario is that the application may not work after you secure it - and oftentimes, the pressure to maintain the application availability will trump the need to secure the application - or at least push the task of securing the application lower on the priority list.
So before we wrap up, there are a couple of very good articles to refer you to that discuss some of the principles we've talked about above. Both of them were written by Scott Culp of the Microsoft Security Response Center. The first article discusses " The 10 Immutable Laws of Security ". Very briefly, the 10 laws are:
Scott's other article is titled " The 10 Immutable Laws of Security Administration " - and is a listing of ten basic laws regarding the nature of security.
Well, that's it for this post. This was a little departure from what we normally cover, but hopefully you found this information useful! Until next time ...
|Share this post :|
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.