1: Reduce the attack surface whenever possible
One of the first steps you should take when hardening a machine is to reduce its attack surface. The more code that’s running on a machine, the greater the chance that the code will be exploitable. You should therefore uninstall any unnecessary operating system components and applications.
2: Use only reputable applications
Given the current economic climate, it might be tempting to use freeware, deeply discounted, or open source applications. While I will be the first to admit that I use a handful of such applications in my own organization, it is critically important to do a little bit of research before adopting such an application. Some free or low cost applications are designed to serve ads to users; others are designed to steal personal information from users or track their Internet browsing habits.
3: Use a normal user account when you can
As a best practice, administrators should use normal user accounts when they can. If a malware infection occurs, the malware generally has the same rights as the person who is logged in. So of course that malware could be far more damaging if the person who is logged in has administrative permissions.
4: Create multiple Administrator accounts
In the previous section, I discussed the importance of using a regular user account whenever possible and using an Administrative account only when you need to perform an action that requires administrative permissions. However, this does not mean that you should be using the domain Administrator account.
If you have multiple administrators in your organization, you should create a personalized administrator account for each of them. That way, when an administrative action is performed, it is possible to tell who did it. For example, if you have an Administrator named John Doe, you should create two accounts for that user. One will be the normal account for day-to-day use, and the other will be an administrative account to be used only when necessary. The accounts might be named JohnDoe and Admin-JohnDoe.
5: Don’t go overboard with audit logging
Although it may be tempting to create audit policies that track every possible event, there is such a thing as too much of a good thing. When you perform excessive auditing, the audit logs grow to massive sizes. It can be nearly impossible to find the log entries you’re looking for. Rather than audit every possible event, it is better to focus on auditing only the events that matter the most.
6: Make use of local security policies
Using Active Directory based group policy settings does not nullify the need for local security policy settings. Remember that group policy settings are enforced only if someone logs in using a domain account. They do nothing if someone logs into a machine using a local account. Local security policies can help to protect your machines against local account usage.
7: Review your firewall configuration
You should use a firewall at the network perimeter and on each machine on your network, but that alone isn’t enough. You should also review your firewall’s port exceptions list to ensure that only the essential ports are open.
A lot of emphasis is typically placed on the ports that are used by the Windows operating system, but you should also be on the lookout for any firewall rules that open ports 1433 and 1434. These ports are used for monitoring and remotely connecting to SQL server and have become a favorite target for hackers.
8: Practice isolation of services
Whenever possible, you should configure your servers so that they perform one specific task. That way, if a server is compromised, the hacker will gain access to only a specific set of services. I realize that financial constraints often force organizations to run multiple roles on their servers. In these types of situations, you may be able to improve security without increasing costs by using virtualization. In certain virtualized environments, Microsoft allows you to deploy multiple virtual machines running Windows Server 2008 R2 for the cost of a single server license.
9: Apply security patches in a timely manner
You should always test patches before applying them to your production servers. However, some organizations really go overboard with the testing process. While I certainly do not deny the importance of ensuring server stability, you have to balance the need for adequate testing with the need for adequate security.
When Microsoft releases a security patch, the patch is designed to address a well-documented vulnerability. This means that hackers already know about the vulnerability and will be specifically looking for deployments in which the patch that corrects that vulnerability has not yet been applied.
10: Make use of the Security Configuration Wizard
The Security Configuration Wizard allows you to create XML-based security policies, which can then be applied to your servers. These policies can be used to enable services, configure settings, and set firewall rules. Keep in mind that the policies created by the Security Configuration Wizard are different from security templates (which use .INF files) Furthermore, you can’t use group policies to deploy Security Configuration Wizard policies.