Preparing for the creation of a compliance baseline

This recipe provides information on activities that should be performed before creating a compliance baseline and installing Security Compliance Manager.

Getting ready

In order to create a meaningful and successful basic compliance program, it is essential that a clear understanding of your goals exists. As mentioned in Chapter 1, Starting the Compliance Process for Small Businesses, you have to define what you want to achieve with your compliance program. The creation of the compliance baseline using Security Compliance Manager will affect part of your company or all of your company's users and/or systems, as it is based on the domain policy. For example, if you introduce a stricter password policy, all the appropriate stakeholders must be involved.

How to do it...

To create a compliance baseline based on the Active Directory domain policy, the following areas have to be researched and/or prepared:

• Technical aspects:
  • Understand the Active Directory and Domain Policies; two very good sources are the TechNet sites http://technet.microsoft.com/en-us/library/hh147307%28v=ws.10%29.aspx and http://technet.microsoft.com/en-US/windowsserver/bb310732.aspx.
  • Create an Active Directory group that will include all users that require administrative access; this will be used to allow access to Security Compliance Manager to create baselines, edit baselines, run audits, and so on.
• Role and responsibility aspects:
  • Decide on the users that will form the administrator/operator group. Add them to the Active Directory group mentioned previously, and place this group in the local administrator group on the Security Compliance Manager system. No other user should have access to this system.
  • Your stakeholders must be involved in the process of creating baselines. These baselines will affect most or all of your company's users and, sometimes, systems. It is therefore essential for successful implementation that management is involved in the process. Earlier, we mentioned the password policy, but another example could be enforcing saving Microsoft Office documents to departmental shares by default or enforcing saving documents in a newer Office version. Not involving management may lead to questions and support incidents being raised. In addition, you should involve the application owner if your company has this role. Based on your results from Chapter 1, Starting the Compliance Process for Small Businesses, different baselines may be required for more sensitive data and/or systems including user accounts.

How it works...

Security Compliance Manager uses GPOs to implement settings such as user rights and define computer behavior and so on based on the configuration within your baseline. As certain users (groups) or computers (groups) have different requirements, different baselines may be required. In order to create a baseline to secure your environment, you should familiarize yourself with the following:

• OU design
• GPO design

OU design

An organizational Unit (OU) is a container within Active Directory Domain Services that allows you to structure objects, such as users, computers, groups, and printers. These objects are used to manage, secure, and potentially segregate the administration of your company environment. It is like the walls within your house creating separate rooms for different purposes. You might have users that are only working with very sensitive data, whereas other users don't. So, you might consider having stronger security requirements for the first group. To do this, you create a separate OU container for each set of users. When designing OUs, keep it as simple as possible and refer to best practices before starting. Microsoft provides a video containing best practices that can be viewed by visiting the following link:

http://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/WSV206

If you do not have an OU design yet, the following are the design considerations. The term level describes how deep we are within the AD structure. So, a possible approach could be the following:

• Level 1: OU for Computer contains all computers such as client systems.
• Level 1: OU for Server contains all server objects.
• Level 1: OU for User contains all users.
• Level 1: OU for Group contains all groups.

  Depending on your requirements, you might need more OUs on this level, for example, one for service accounts.

• Optional Level 2: Under Server, you can create additional OUs that define the server type, allowing further segregation, such as an OU for Hyper-V and an OU for Webserver. A reason to do this could be if you have requirements, for example, if you need to harden web servers, but not your other servers, you create the OUs below Server. This should only be done if you want to create baselines just for those server types.
• Optional Level 2: Under User you can create additional OUs for stricter security settings. For example, OU for Department XX could be created in case people have access to sensitive data and require a higher security level. As mentioned before, only create these OUs if you require them and want to create settings/rights that require an additional OU. Sometimes, sensitive user accounts do not belong to just one department. In this case, Security groups may be a better solution.
  

GPO design

GPOs are used to administer and enforce settings at domain or OU level. This allows you to ensure a consistent configuration across all users and computers within your company. Using GPOs is a good way to enforce compliance; by grouping objects together, you avoid the need to manually enforce settings on specific computers.

It is quite important to understand that there is an order of precedence for GPOs. It is possible to have more than one GPO for the same object. A local group policy object that is applied to a computer or user may not take effect if a domain-linked GPO targets the same object. This is because the later GPO overrides the local group policy. Further information can be found at http://technet.microsoft.com/en-us/library/cc785665(v=ws.10).aspx#feedback.

If your company does not have any GPO policies yet, the following are general considerations:

• Creating a Domain Policy: This one will affect your whole company, including all systems and users within your domain
• Creating a Server Policy: This will affect only your servers and could be used for basic settings, such as remote desktops or updates
• Creating a Client Policy: This will be for client computer systems
• Creating a Client User Policy: This will be for your users

  Tip

  Additional GPO policies can be created as required.

The following diagram shows where those policies could be applied within your OU design: