Windows is not without certain issues and flaws. Like any operating system it has been exposed to numerous vulnerabilities, both deliberate (viruses) and unintentional (exploitable holes in programs or processes)—so it’s essential that your company has a policy in place to help protect and secure your Windows machines.

This policy provides guidelines for securing Windows on company computers or computers used to conduct company business. It assumes administrative knowledge of Windows/Active Directory environments. Rather than serving as a full technical guide, it outlines the general details for securing systems.

From the policy:

Policy details
Designate responsible individuals/groups
Specific individuals or groups should be designated to analyze, modify (if necessary), enact, and otherwise be responsible for the details of this policy. Examples include IT staff, security, and stakeholders from other departments. These stakeholders may be VPs, managers, or technologically savvy individuals who can provide input on their respective needs.

Develop templates based on system/user roles
Security templates (which can be as simple as a list of recommended settings or as complex as actual configuration files that can be applied to a system) should be developed based upon system and user roles. However, you must first establish these roles to proceed.

You don’t have to document every single workstation, but rather the role of the workstation in the organization so you can then assess how to secure company workstations overall.

This process should identify critical systems versus non-critical systems (e.g., test servers), which will then help you develop the right mechanisms for protection. With these roles in mind, you can develop a list of security settings/features working from a “least access needed” mindset based on the system function and user(s) involved.

For instance, users should have access only to file shares they need to do their jobs, and this can be based by department. A Finance folder with access permitted only by finance department users will secure the contents from unauthorized individuals. The same applies to mailboxes; most users will need to access only their own, but in some cases shared mailboxes may apply.

Similarly, restricting access to a workstation so that only the user assigned to it can log in can also enhance security by ensuring only appropriate personnel can access that system.

As you develop the templates, be sure to devise security across the infrastructure. DNS servers may not seem particularly noteworthy, but severe damage can be inflicted if they are compromised (and they usually run on Domain Controllers as well).