Desktop Deployment

Design More Secure Desktop Deployments

Shelly Bird

At a Glance:

• Defining a baseline desktop configuration
• Common security challenges
• Assembling items to include in the image
• Automating installation and configuration

Windows XP

BDD Solution Accelerator

Group Policy Management Console

These days, when system administrators contemplate a major new deployment of desktops, laptops, or Tablet PCs, they often have security in mind. Far too often, it is believed that a new operating

system, in and of itself, will enhance security. This, however, won’t happen unless security is built in at the very start of the desktop design and remains top priority throughout the deployment phases.

Embedding security into your desktop design and deployment consists of three steps: developing a single standard for a desktop baseline configuration, incorporating the standard configuration into an image that can be deployed rapidly, and developing a single standard for desktop baseline security settings. In this article I’ll deal with negotiating and achieving a single standard configuration. Future articles will explore how to embed the standard in as few images as possible and the specific security settings that overlay the baseline configuration.

This discussion is focused on Windows® XP Service Pack 2 (SP2) deployments and assumes Active Directory® is used in your enterprise.

Baseline Configuration

A baseline configuration defines the lowest common denominator of what is needed for all the systems in your organization—meaning what applications, updates, settings, and so on must be in place for every user. The baseline must be extremely easy to deploy with a rapid installation method so that both users and administrators will use it without complaint.

Exceptions for special applications and settings required by particular sub-groups are a separate issue and should not confuse the efforts to achieve the baseline. These special applications and settings must be dealt with in separate follow-up routines, and are not part of this discussion. In this article, I will be focusing only on the baseline configuration.

A properly deployed baseline configuration lets you control what’s normal—the baseline—on your systems, making it easier to detect what’s not normal. The baseline setup can help you, for example, track down where an additional account came from, determine if constant slowdowns are due to a denial-of-service attack, or find out whether a new security update really works in your enterprise.

It’s also important that an established baseline configuration not be written in stone. To stay current and valid, you should regularly evaluate and refresh your baseline standard, adding new software, revisions, and updates as necessary. This includes addressing any emerging security technologies or threats that may require across-the-board revisions to the security settings. This reevaluation of the baseline configuration is often done on a monthly or quarterly basis. In short, the baseline is not just an image; it is also the set of specifications that define that image, the scripts that build that image, and the upgrade paths that bring existing systems into line with the current image.

Classic deployments center on a complete image, sometimes referred to as a "wipe and load" solution because it completely replaces all preexisting information on the system. The image is often provided to the computer manufacturer and installed on all new machines at the factory. It is then used in the field for disaster recovery situations when the system has to be completely rebuilt. But this image is just one necessary component of the deployment.

As a new baseline image is issued, the builders must issue an upgrade pack along with it so that organizations with previous versions can bring their baseline up to the new, current standard. After all, they will also need all the updates and security enhancements, as well. In this manner, all boats rise with the tide.

Common Challenges

Those charged with developing a security policy tend to focus upon a relatively small area of desktop security: enforcing Group Policy to the most restrictive levels. These policy makers often follow recommendations issued by security standards bodies such as the National Security Agency (NSA), the National Institute of Standards and Technology (NIST), or the Center for Internet Security (CIS). Military agencies look to the Defense Information Systems Agency (DISA) for guidance.

But if you simply adopt the highest security settings wholesale you actually ignore the strong warnings given by agencies like the NSA, NIST, DISA, CIS, and others. The published guidelines are just that—guidelines. These are not settings that should be lifted and carried into any customer’s environment without thorough testing and understanding of the potential impact. As valuable as these guidelines are, they need to be carefully vetted for suitability. This means testing before deploying and considering the potential result of each security decision.

A second problem is that these security settings represent only one component of what makes a desktop secure. There are dozens of policy settings beyond those contained in the Security Settings node of Group Policy (see Figure 1). For example, many settings under Administrative Templates affect Microsoft® Office and Microsoft Internet Explorer and, in turn, can have a profound impact on the security of an organization. You can control the configuration of Windows Firewall or turn on more verbose application logging to assist in nailing down the source of an attack. Some applications will "phone home," revealing potentially damaging information to the outside, and these apps may need to be reconfigured to block such communication.

Figure 1** Group Policy Settings **

Yet another problem arises from the fact that the groups charged with developing and enforcing security policy may be isolated from the technicians who actually build and maintain the desktop image. Windows administration expertise is not necessarily the norm for security consultants. An organization’s security experts frequently come from router or firewall backgrounds, and are more inclined to worry about perimeter and server security, rather than focusing on hardening desktops. These experts are deeply skilled—just not necessarily in the Windows arena.

Conversely, security may not be a top concern for the technicians who build the baseline desktop or the operations personnel responsible for supporting desktops. Simply keeping users happy is challenging enough. Support personnel often fear that security lockdowns will make users unhappy and, if not done properly, cause a lot of headaches. As a result, when settings appear too restrictive or application-compatibility testing becomes an uphill battle, security configurations are often tossed aside in the interest of returning users to being productive as quickly as possible. New settings that are adopted in haste make Windows less secure than the default configuration.

But it doesn’t have to be so hard.

Defining Desktop Solutions

The best solution is to have both operations and security personnel in your organization work together, taking a more holistic look at the desktop-build process as it relates to security. People shy away from this approach, thinking it will complicate the process. But, in fact, the opposite is true. By dealing with these details up front, you eliminate the last-minute redesigns, the painful arguments, and the stops and starts so common in many deployments.

For starters, collaborate. Get representatives of both the operations and security teams in the same room and have them collaborate to define the desktop configuration end-to-end. Recognize that each party brings something essential to the table, and use their natural opposition and conflicts as a way to drive more balanced decisions. See the sidebar "Setting System Prerequisites" for basic topics you should all agree upon.

A testing period will be necessary. Establish regular cycles of security decision reviews so operations personnel have a chance to present and address any unexpected impacts of past security decisions. Security evolves, and so should the baseline. Recognizing this is very important to promoting adoption and ensuring people are comfortable with their choices.

A side benefit to this holistic approach is that the very act of establishing a standard desktop forces much closer collaboration between security policy makers, the domain administrators responsible for Active Directory, and system builders. These groups don’t traditionally communicate very well, largely contributing to the difficulties in achieving better desktop security.

Setting System Prerequisites

Everyone with input toward the baseline configuration has to agree on some ground rules. Otherwise, the effort to increase security at the desktop is a waste of time. Here are a few basic rules that can smooth out the decision-making process:

Users Must Not Run as Administrators It makes no sense to express concern about security and spend weeks hashing out security settings, only to let users run as local administrators. You might just as well give hackers admin rights.

Users Need a Software Delivery System Non-administrators may have trouble installing software or drivers, and may not be able to change some settings on their systems. Support technicians must be prepared to push packages, as needed, to users who request them. Microsoft Systems Management Server (SMS) is one example of suitable technology to handle this. Use of the Software Policy in Group Policy is another solution. Note that logon scripts to deliver software won’t work because these always run under the user’s context.

Users Need to Receive Security Updates As with software delivery, you’ll also need a way to distribute things like system and application updates or new virus definitions. There are a number of options for doing this. You can implement a pull method for updates through Systems Management Server 2003 with the latest ITMU Agent on clients. Alternatively, you can employ a push method such as Windows Server Update Services (WSUS).

Develop an Apps List

You need to create a list of applications that everyone in your enterprise requires. This is a baseline and should include only the apps that every single computer absolutely needs. Do not include applications that only a subset of users will need; you should use the software delivery system to augment the baseline image with those applications later on. Specify the version, publisher, and any updates that are required for a basic installation. Don’t forget to include such things as crucial add-ins and plug-ins. For instance, it’s a good idea to identify frequently used sites in your enterprise, so you can include any necessary ActiveX® controls and plug-ins. Log in with User permissions and surf those sites. See which controls and plug-ins can be loaded by users with limited privileges and which are blocked by the system. The latter will need to be pre-loaded in your baseline image.

A typical baseline set of applications includes Microsoft Office, antivirus software, plug-ins for Internet Explorer, and any necessary internal line-of-business applications. Getting your organization to standardize on a single application and version for things like word processors, spreadsheets, antivirus, and so on is critical to achieving a useful baseline configuration. And the usual rules apply when it comes to keeping an eye on security: starting with the latest versions and updates for each product is likely to help keep your desktops more secure.

Security Settings

Your security team should have already performed a security threat analysis and be ready to propose settings in a checklist format. Operations technicians can then evaluate those theoretical security decisions in the context of real-world user expectations and requirements. Between these two points of view, your team should be able to reach a compromise that makes the organization hardened to attack yet still productive for users.

The Microsoft Security Solutions (MSS) Windows XP Security Guide provides a good starting point. Another important reference is Threats and Countermeasures: Security Settings in Windows Server™ 2003 and Windows XP. These documents are critical to use as benchmarks since they include a lot of information on the known effects of certain restrictive settings. The latest MSS Windows XP Security Guide (Version 2.1, updated October 20, 2005) is approved for use by the top security standards organizations mentioned earlier in this article. Each organization can issue addendums that expand or correct the MSS Windows XP Security Guide. Be sure to document every decision made during your security discussions. This information will form the basis of your security configuration.

Building the Image

Once decisions are made, you implement these decisions by creating a single baseline system configuration. This configuration is then packaged into an image that can be installed over the network in anywhere from 5 to 20 minutes. The same image can be provided to computer manufacturers to load at the factory, to help desk and operations personnel to perform disaster recovery or rebuild older computers.

There are several products that can be used to create bit-copy images of an existing file system. With multicasting, such images can be blasted simultaneously to multiple machines, usually in ten minutes or less. The SMS OS Deployment Feature Pack offers another benefit: data can be captured and restored locally with the User State Migration Tool (USMT) without having to move that data across the network. In my experience, this has more than made up for the slightly longer time required to bring the image down over the wire. See Adam Gordon’s article on the OS Deployment Feature Pack in this issue for more coverage.

Regardless of which technology is used to capture your image, be sure to do two things. First, automate the build process that produces the final image as much as possible. Why? There is no better way to reconstruct the original image, making this a key component of security. Second, run the System Preparation tool (sysprep) just prior to capturing the image. Most people run sysprep without any additional customization to the sysprep answer file (sysprep.inf), and without adding additional files and routines through the \i386\$OEM$ directory and the cmdlines.txt file that can be stored there. Make sure to take advantage of this extremely powerful capability. Doing so can limit the number of images and post-installation steps needed during deployment—this is essential for both security and efficiency. See "Imaging: Overview" for more information on imaging and the sysprep tool.

Figure 2** Custom Installation Wizard **

Build Automation

One great way to put together an automated installation is to use Zero Touch Install (ZTI) scripts that are provided with the Solution Accelerator for Business Desktop Deployment (BDD) Enterprise Edition ("Microsoft Solution Accelerator for Business Desktop Deployment"). These scripts help to build an end-to-end automated installation of the applications that form your baseline image. The package also includes guidance for achieving a successful touchless installation.

Of course, if your baseline builders are accustomed to using other tools—even simple batch files—those will work too. The important thing is that you develop a straightforward installation that can be completed in as few steps as possible. And make sure to document what went into the installation you build. Scripts not only simplify the documentation, they make later audits of what went into the build and repetition of the build much easier—another security benefit. (Note that end users never see these scripts; this is strictly a backroom operation.) Making sure your builders are comfortable with the process is important to ensure continuity. Remember that your image will have to be rebuilt repeatedly through the year to keep current with the latest security updates and service packs.

Regardless of which tools or methods are used, it is always handy to know the most common ways to quickly achieve a non-interactive installation and configuration of software. Most software vendors provide a way to automate the installation process for their products. But here are some tips that can be helpful.

Custom Installation Wizard (CIW) This tool is available from the Office 2003 Editions Resource Kit Tools. Copy the Office source files to the installation directory—do not use the administrative setup, as this will bar you from using some features, such as Local Installation Cache.

Use the CIW to walk through installation choices for Office (see Figure 2). You’ll end up with a Transform (MST) file to use in your installation batch.

Go easy on establishing configuration settings that Group Policy can handle more flexibly and effectively through Active Directory. Embedding anything beyond the standard you’ve established for the entire enterprise might cause some unpleasant surprises later on if you have to roll back the Group Policy Objects (GPOs).

To launch your automated installation with the MST file, where setup will not prompt the user for information, use the following command:

start /wait %source%\office2003\setuppro.exe 
TRANSFORMS=%source%\Office2003\customer.
MST /qb+

Setup will display progress indicators and a completion message. You can use the /qb- flag to eliminate progress bars and the completion message.

Check the Office Deployment Guide for all the setuppro.exe command line options. These options can make on-the-fly changes easier to perform when trying to execute smaller setup changes without having to rerun CIW. Also check out the Office Profile Wizard—this generates OPS files to capture and restore user preferences.

Internet Explorer Administration Kit (IEAK) Customized versions of Internet Explorer, Windows Media® Player, and even common plug-ins, such as Macromedia Flash, can be built and installed silently by creating a custom flat file installation with IEAK. The Office CIW includes IEAK, but occasionally it can be useful to use IEAK on its own for generating additional answer files. You can use those files separately for particular group requirements.

MSI Silent Installation If a manufacturer has constructed a Microsoft Installer (MSI) package, you can use various command-line options to control silent and unattended installations. A complete list of msiexec.exe command line options is available at Msiexec (command-line options).

The following command will initiate a complete, silent MSI installation by choosing all default choices:

msiexec /i filename.msi /qn

InstallShield Silent Installation InstallShield recently added an option to write all setup choices to a response file, which can then be used on other systems for a customized, unattended installation. To create this setup response file, you run through the installation once and select the settings you want to be used during silent setup. Start the InstallShield-based setup program as follows:

setup.exe /s

Use of the /r option causes the installer to save all choices made during installation into %systemroot%\setup.iss. At the end of the installation, copy the setup.iss file to the directory in which the original setup.exe file exists.

In your baseline build, use the following command to run the InstallShield setup program in silent mode using the setup.iss response file you created: To specify a response file in a different location, use the /f1 option, as shown here:

setup.exe /s /f1"C:\temp\setup.iss"

Microsoft Service Packs and Updates Service packs for Windows and most Microsoft products can be installed using command-line parameters. Some common parameters are listed in Figure 3.

Figure 3 Update Parameters

Updates can be queued up and installed without a reboot between each one. (The QChain.exe utility used to be required, but this is no longer so with Windows XP.) This requires just one shutdown and reboot. For more on the Package Installer for Windows Updates, see "The Package Installer (Formerly Called Update.exe) for Microsoft Windows Operating Systems and Windows Components".

Keyboard Scripting Utilities As a last ditch method, if no silent installation method can be found for a particular product, consider using a keyboard script utility. Microsoft ScriptIt, for example, may be old and unsupported, but it’s also free and relatively easy to use. For details see "The MS ScriptIt Utility". It can also be found in the BDD Solution Accelerator. Remember that you should not touch the keyboard when ScriptIt is running a script; any interim keystrokes will throw the script off. Since only the baseline builders—not users—will be watching the build, this is not a severe limitation.

Figure 4** Group Policy Security Settings **

Applying Security Policy

There are three sets of tools and methods that help to establish and maintain local and Active Directory Group Policy. The first two strategies—the Security Configuration Editor (Secedit) and Local Group Policy files—are used when applying local Group Policy, without the use of GPOs. By far the most effective way to apply and maintain policy, however, is through the Group Policy Management Console (GPMC).

Security Configuration Editor Secedit allows an administrator to combine security databases (SDB files) containing baseline configurations and security templates (INF files) containing additional security customizations that can be used to analyze or configure a target workstation. In addition an administrator can use Secedit to capture existing security settings on a stand-alone or domain-based reference computer for creation of a security template. Use the Secedit tool (provided with Windows) to configure the settings defined in Computer Configuration | Windows Settings | Security Settings. You can create the custom .inf file by using the Microsoft Management Console (MMC) Security Template snap-in. See Microsoft Windows Server TechCener: Secedit for more information on Secedit.

Local Group Policy Files These are located in hidden folders under %windir%\system32 GroupPolicy. Note that you will not see these folders until you run the local Group Policy snap-in (gpedit.msc) at least once while logged in as a local administrator.

The Group Policy Management Console There are dozens of advantages to using GPMC, but the primary reason from a builder’s perspective is the ability to create a single GPO that contains all the security and policy settings for the baseline configuration (see Figure 4). You can back up these settings, then restore this backup file to another domain as needed. GPMC can be downloaded from Group Policy Management Console with Service Pack 1.

Shelly Bird is a Senior Consultant II with Microsoft Consulting Services Public Sector. For over ten years she has assisted government, military, and state agencies in mass deployments of desktops and servers, with security as the focus.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.