Ensuring a Secured Managed Configuration

Most desktop management strategies have some form of security assessment and implementation involved. There are two typical areas of security; one is patch management, and the other is general desktop security policies. As an organization implements desktop management policies and practices, security planning and implementation should be reviewed and determined if they need to be applied at the time of policy rollout.

Decreasing Vulnerabilities Through Security Patches

Before Software Update Service (SUS) 1.0 there was Windows Update service, which was ultimately managed by the end- user and required elevated rights to run. To avoid this scenario most administrators chose to disable Windows Update Service and create, then re-create, images that include the latest patches as they came out. As most of you know or could guess this takes a lot of time and energy.

With the introduction of SUS there is now a free patch management solution provided by Microsoft. Using the Automatic Update client installed with Windows XP Service Pack 1 or later (also installed with Windows 2000 SP3 or later), the automatic update client allows redirection to the SUS server. There are two ways that the redirection can be applied, either the hard way by specifically modifying the desktop Registry, or the easy way, through the use of an Active Directory group policy.

Some of the best practice recommendations in the use of the Software Update Server include the following:

• Configure Group Policy so that it points clients to SUS server

• Configure IIS on the SUS server to log client connections

Requires IE5.5 or Later

The SUS administration page requires IE5.5 or later, however because IE5.5 is not available through Windows Update, most organizations use IE6 or later. Local Admin rights to SUS server is required to view SUS admin page.

Maximizing Security on the Desktop

Most organizations have groups or individual network clients who work with or require access to highly confidential data. Such users can be found working in the Human Resources or Payroll departments of the company. Executives in the company also fall under this category. Because these users are privileged to very sensitive information, it is important for you to secure the network accounts used to access this information as well as the means by which this data is accessed.

Because there is probably sensitive data stored on servers that are, in turn , accessed by privileged network clients, you should secure that data as it passes from server to client. Most data is not protected when it travels across the network, so employees , supporting staff members , or visitors might be able to plug into the network and copy data for later analysis. They can also mount network-level attacks against other computers. Windows Internet Protocol Security (IPSec) is a key component in securing data as it travels between two computers. IPSec is a powerful defense against internal, private network, and external attacks because it encrypts data packets as they travel on the wire.

You can create and modify IPSec policies using the IP Security Policy Management snap-in available in the Microsoft Management Console. IPSec policies can then be assigned to the Group Policy Object of a site, domain, or organizational unit. If sensitive data is located on a server, assign the predefined Secure Server policy to the server so that it always requires secure communication. Then assign the predefined Client (Respond Only) policy to the network clients that will communicate with the secure server. This policy ensures that when the network client is communicating with the secure server, the communication is always encrypted. The network client can communicate normally (unsecured) with other network servers.

To assign the Client (Respond Only) IPSec policy in the Group Policy Object, perform the following steps:

1. Navigate to IP Security Policies on Active Directory under Computer Configuration/Windows Settings/Security Settings.

2. In the Details pane, click Client (Respond Only).

3. Select Action, Assign.

Though it might be okay for high-security network clients to communicate normally (unsecured) with other servers within the organization that do not contain sensitive data, there might be a need to limit that client's ability to communicate outside the organization. There are many settings available within Group Policy to prevent a user from modifying or creating new network connections. For example, a Group Policy setting can be applied to prohibit connecting a remote access connection.

To enable Group Policy settings related to network connections in the Group Policy Editor, navigate to User Configuration/Administrative Templates/Network/Network Connections. Figure 7.4 displays the settings one can enable in this category.

Figure 7.4. Group Policy settings to restrict network connections.

If the secure network clients save sensitive data to their local workstations, additional security can be provided to this data through the Encrypting File System (EFS). Because EFS is integrated with the file system, it is easy to manage and difficult to attack. Moreover, after a user has specified that a file be encrypted, the actual process of data encryption and decryption is completely transparent to the user.

To encrypt a file or folder, follow these steps:

1. In Windows Explorer, right-click the file or folder that you want to encrypt and then click Properties.

2. On the General tab, click Advanced.

3. Check the Encrypt Contents to Secure Data box.

To encrypt and decrypt files, a user must have a file encryption certificate. If the file encryption certificate is lost or damaged, access to the files is lost. Data recovery is possible through the use of a recovery agent. A user account of a trusted individual can be designated as a recovery agent so that a business can retrieve files in the event of a lost or damaged file encryption certificate or to recover data from an employee who has left the company.

One of the many advantages of using Windows Server 2003 domains is that you can configure a domain EFS recovery policy. In a default Windows Server 2003 installation, when the first domain controller (DC) is set up, the domain administrator is the specified recovery agent for the domain. The domain administrator can log on to the first DC in the domain and then change the recovery policy for the domain.

To create additional recovery agents , the user accounts must have a file recovery certificate. If available, a certificate can be requested from an enterprise Certificate Authority (CA) that can provide certificates for your domain. However, EFS does not require a CA to issue certificates, and EFS can generate its own certificates to users and to default recovery agent accounts.

To create an EFS recovery policy for a domain, follow these steps:

1. In Active Directory Users and Computers, right-click the domain whose policy you want to change and then click Properties.

2. Click the Group Policy tab.

3. Right-click the default domain policy and then click Edit.

4. Navigate to the Encrypting File System under Computer Configuration/Windows Settings/Security Settings/Public Key Policies.

5. Right-click Encrypting File System and then click Create Data Recovery Agent to create a certificate to use as the EFS recovery certificate.