Security Feature Team Guide

Figure 2 illustrates the primary activities that occur during the Planning Phase. While the other teams are developing images, project plans, and the like, the Security feature team is focusing on the existing production environment from a security perspective; the team determines whether changes should be made in the workstation images to reduce the risk of new or different security threats to the organization and, if so, how best to incorporate them.

Figure 2. Activities during the Planning Phase
See full-sized image

On This Page

	Roles and Responsibilities
	Desktop Security Planning Considerations
	Infrastructure and Deployment Security
	Milestone: Migration Plan Accepted

Roles and Responsibilities

All six role clusters from the MSF Team Model play a role in the Planning Phase of the initiative. Table 1 lists those roles and defines the focus areas for each of the different role clusters relative to the deployment process in the Planning Phase.

For more information about MSF Team Model role clusters, see the MSF home page at http://www.microsoft.com/technet/itsolutions/msf/.     

Table 1. Roles and Responsibilities During the Planning Phase

Top of page

Desktop Security Planning Considerations

During the Planning Phase, the Security feature team analyzes desktop security risks and determines the most cost-effective way to mitigate significant vulnerabilities. Many high-level and low-level decisions need to be made about how security will be applied to the new workstation images. The issues are outlined in Figure 3.

Figure 3. Decision tree for security strategy
See full-sized image

After the Security feature team has made these decisions, it must then consider security requirements that vary from the standard Group Policy objects (GPOs) provided with the Solution Accelerator for BDD and make the necessary changes to the client image security settings. Then, it must consider application security and choose an update methodology that Operations will maintain.

Risk Analysis for Desktop Security

Too often, an organization’s security architecture is determined casually, rather than analytically. For example, administrators might be assigned to identify security settings for new workstations. When using Windows XP with Service Pack 2, this approach probably will not result in significant vulnerabilities because the platform is designed to be secure by default. However, it is entirely possible for well-meaning and knowledgeable engineers to deploy desktop security settings that are too restrictive. Overly restrictive settings can negatively affect user productivity, increase application deployment costs, and ultimately be extremely costly to an organization. Fortunately, you can use the security risk management process to identify the most efficient way to improve an organization’s security.

The Security Risk Management Process

The security risk management process, described in detail in the Security Risk Management Guide at http://www.microsoft.com/technet/security/guidance/
complianceandpolicies/secrisk/default.mspx, is a proactive, structured approach for determining which security settings and countermeasures will benefit an organization and which security settings and countermeasures will be unjustifiably costly. The Microsoft security risk management process has four phases:

These four phases are illustrated in Figure 4.

Figure 4. The Microsoft security risk management process
See full-sized image

Many organizations already have a security risk management process in place, and it may differ from the Microsoft security risk management process. Regardless of the specific process used, it is important to integrate desktop deployment into a structured risk analysis that includes weighing both the costs and benefits of security decisions. Even if you ultimately decide to accept default security settings, the security risk management process benefits you by requiring that several levels of management acknowledge that not all vulnerabilities can be eliminated. By acknowledging that some level of security risk is acceptable, management shares responsibility for security decisions.

Client Risk Management Considerations

At a high level, the most fundamental security decision you will make is to choose between the default level of security or enhanced security. By choosing the default level, you decide that your security requirements are typical of Microsoft customers. Although Windows XP with SP2 is designed to be secure by default, you can choose to implement more secure settings. Accepting default security settings requires you to accept more security risks than if you chose to implement enhanced security. Although accepting these risks has a cost, the benefits of using the default security settings are significant:

Successful security compromises always have a cost. Depending on the type of compromise, the cost can be minimal and can even go unnoticed. Serious compromises can cost organizations millions of dollars. If, during the security risk management process, you determine that the costs of a possible security compromise outweigh the costs of imposing more restrictive desktop security, then you should implement enhanced desktop security. The benefits of using enhanced security are also significant:

Ultimately, you may choose to implement both types of security settings for different desktop roles within your organization. For example, you might decide to use enhanced security for computers used by temporary staff because their computers might be more likely to attack other computers or to be compromised by malware. On the other hand, a development team may require default security so that the team can more easily perform administrative tasks on its own computers. Each different role you create adds cost, however. You will need to design and manage multiple sets of security settings, and you may need to manage separate images for each role.

If you choose to implement enhanced security, you will often need to weigh security risk against user functionality, convenience, and ease of use. Typically, as the level of security increases, the level of user functionality decreases. For example, a default feature of the Windows XP operating system, Autoplay, is to automatically launch the default program on a CD-ROM when the CD is placed into the CD-ROM drive. This value-added functionality means that the user does not need to search the CD for the appropriate application and then manually run it. But this feature can be a liability if the CD contains inappropriate or malicious software that could harm the computer. In this example, companies need to decide between the ease of use of the Autoplay feature and the security risk associated with the possibility of malicious contents on the CD.

Client Security in the BDD

Hundreds of available features can be reviewed and adjusted based on tradeoffs similar to the Autoplay example. For convenience in the planning cycle, the Solution Accelerator for BDD has grouped these decisions into four options:

The Solution Accelerator for BDD includes the scripts and configuration files for the first three security options in a legacy environment by using local Group Policy objects (LGPOs); but because of the variety of custom configurations possible, it does not include scripts or configuration files for them. By default, the Solution Accelerator for BDD enables the default configuration. Subsequent sections of this guide provide information to enable the other supplied configuration options. The process for defining your own custom security configuration files to meet any unique needs of your organization is outside the scope of this document. For information about obtaining the files to apply Group Policy settings in a Microsoft Active Directory® environment, refer to the Windows XP Security Guide at http://www.microsoft.com/technet/security/prodtech/
winclnt/secwinxp/xpsgch05.mspx.

The Security feature team has the responsibility for analyzing the security requirements for the organization and recommending to the Project Management team which options should be applied. The final decisions will be included in the functional specification document.

Risk analysis includes an ongoing component, too. During the Planning Phase and throughout the entire project, the Security feature team participates in all review meetings and performs an ongoing threat analysis and awareness program to ensure that appropriate team roles are aware of existing or potential security issues in their areas of responsibility.

Note   A threat that the Security feature team might not readily identify is the user state migration data that the Solution Accelerator for BDD stores on network shares. When the Microsoft Windows User State Migration Tool (USMT) stores state data locally, the solution removes the data after migration is complete. When the USMT stores state data remotely, the solution does not remove state data automatically. Thus, the Security, Deployment, and User State Migration teams must create a process to remove or secure remote user state data after migration is complete. Additionally, when the ZeroTouchInstallation.vbs script is configured with /debug:true, a flag file is created on the local disk and signals the Operating System Deployment (OSD) Feature Pack not to delete files as it normally would. Use of the /debug command-line option is intended for lab testing only and should not be used in production environments.

Planning Client Security Settings

The security of client computers is determined by the collection of thousands of different settings that directly or indirectly affect the security of the operating system and applications. Determining these configuration settings can be a daunting task. Instead of considering each security setting individually, you should start with one of the previously described options included with the Solution Accelerator for BDD. None of these options may exactly meet your organization’s security requirements, however. To fine-tune these settings, consider the security requirements that might be unique for your organization in the following categories:

The sections that follow provide conceptual information about each of these categories. If, while reviewing each of these sections, you think of exceptional security requirements that your organization may have for the category, you should investigate specific settings in more detail. For detailed information about specific security settings, refer to the Windows XP Security Guide at http://go.microsoft.com/fwlink/?LinkId=14839.

Note   In addition to the considerations described in this section, you must consider confidentiality when redeploying previously used computers. Tools such as Cipher.exe, available at Windows 2000 Security Tool: New Cipher.exe Tool, http://www.microsoft.com/downloads/details.aspx?FamilyID=89E5A2F2-E2A6-418F-90BB-345E95C89806, enable you to permanently delete all data on a hard disk.

Active Directory

The first decision to consider is whether the workstations being deployed will be part of an Active Directory domain or whether an alternative approach will be used. If the workstations will be joining an Active Directory domain—that is, either a Microsoft Windows 2000 domain or Microsoft Windows Server™ 2003 domain—then the Security feature team can make use of GPOs included with Active Directory to centrally define, distribute, and manage the security settings for the Windows XP workstations.

Being able to take advantage of GPOs for security can dramatically reduce ongoing security costs. Even if you deploy desktops with hardened settings that meet your organization’s security requirements, those settings can degrade over time. For example, a new administrator troubleshooting an application problem might add a standard user to the local Administrators group. Without GPOs or another form of security configuration management, the user will continue to have elevated privileges indefinitely and will be more vulnerable to attacks from worms and viruses. In an environment that uses GPOs, restricted groups can be used to ensure that users do not receive elevated permissions, thereby enforcing the security settings determined during the security risk management process throughout the lifetime of the desktop. Woodgrove uses Active Directory for single sign-on (SSO) and configuration management.

If the workstations will be joining a Microsoft Windows NT® Workstation 4.0–based domain or if they will be participating in a standalone workgroup instead of a domain, then these workstations are considered to be joining a legacy computing environment. In the case of a legacy computing environment, the security settings can still be applied, but they must be applied locally on each workstation by using local Group Policy settings, which are a subset of the policies available in Active Directory GPOs. Additionally, without centralized control, these settings are more likely to degrade into a less-secure state over time.

User Accounts

By default, the Windows XP operating system includes several default user accounts. The most significant of these are the Guest and Administrator accounts. By default, the Guest account is disabled, and it should always remain that way. In addition to this, Woodgrove has renamed the former Administrator account and created a new account named Administrator with user-level privileges. Windows XP might use other accounts for optional components such as Microsoft Internet Information Services (IIS). In environments that use the Active Directory directory service, user accounts should almost always be stored within Active Directory. No additional local user accounts are usually necessary, and adding accounts increases security risks.

Group Memberships and Protected User Accounts

Most user privileges are assigned to groups, and users are made members of groups to grant them permissions. Windows XP has several built-in groups, but the most significant are:

Many of the most critical desktop security decisions involve deciding which users will be made members of these groups. The single most critical decision involves whether to add end users to the Administrators, Power Users, or Users groups. The Administrators group offers users complete control over their local computers, and, as a result, they will never have permissions-related problems when installing applications, running software, or configuring their computers. This increases security risks, however, because unrestricted permissions cannot stop viruses, worms, spyware, and other types of malware from infecting the computers. Additionally, users might install software such as games that can reduce their productivity or decrease the reliability of their computers.

On the other hand, adding end users to only the Power Users or Users groups reduces security risks by providing an extra layer of protection against malware. Additionally, it is much more difficult for users in these groups to install unwanted applications that might reduce their productivity or affect the reliability of their computers. The disadvantage of limiting user privileges is increased engineering time: The Information Technology (IT) department will need to spend more time testing applications to ensure they run properly with restricted permissions. This is particularly challenging with legacy applications, which were typically designed to be run by members of the Administrators group.

Figure 5 illustrates the relationship between group memberships, management costs, and security risks.

Figure 5. Changing costs and risks associated with different end-user group memberships

To provide a compromise between full Administrator rights and limited User privileges, you can have users log on to their computers as members of the Users group and then selectively elevate their privileges as required by various applications. In Active Directory environments, you can also use software restrictions to reduce the risk of users' running unapproved software. Woodgrove has decided that granting end users administrative privileges to their local computers is too risky and that the costs of restricting user permissions are justified by the reduced security risks.

In Active Directory environments, local groups are also used to assign privileges to Active Directory groups. For example, the Active Directory Domain Admins group is automatically added to the local Administrators group when a computer running Windows XP joins a domain. You should carefully grant domain groups, such as support center operators and backup operators, permissions to local computers by adding them to the appropriate local groups. To help enforce these group memberships, use Group Policy restricted groups in Active Directory environments. For more information about restricted groups, read the Knowledge Base article 279301, “Description of Group Policy Restricted Groups,” at http://support.microsoft.com/Default.aspx?kbid=279301.

The Application Compatibility Toolkit is a valuable resource for preparing applications to be used by protected user accounts. To download the Application Compatibility Toolkit, visit "Using the Application Compatibility Tool Kit," at http://www.microsoft.com/windowsserver2003/
compatible/appcompat.mspx.

For more detailed information about running applications within protected user accounts, refer to the Application Compatibility Feature Team Guide.

Password Settings

Although Windows XP and the Active Directory infrastructure support flexible authentication methods, such as smart cards and biometrics, passwords are the default authentication mechanism. All user accounts must have passwords, including local user and domain accounts. Although the default Windows Server 2003 Active Directory password settings provide an excellent compromise between security and usability, you may need to modify one or more of the password requirement properties:

In Windows Server 2003 Active Directory environments, the default password settings are sufficient for most environments, including Woodgrove.

File Permissions

File and folder permissions enable users to restrict access to content stored on NTFS file system volumes. You can grant access to open, edit, or delete files and folders. Files and folders also have the concept of ownership: the user who creates a file or folder is the owner of that object and, by default, has the ability to specify other users’ level of access to the file or folder.

File and folder permissions are the most important way to protect confidential data and system integrity. Users often store confidential documents on their computers, and you must ensure that the default file permissions assigned to new documents (most likely located in the My Documents folder) are restrictive enough so that other users cannot access them across the network. You should also use file and folder permissions to prevent users from modifying important system and application files. By granting a user only Read access to system files, you effectively prevent him or her from applying unapproved updates or installing many types of malicious software.

It is important to understand that file and folder permissions have a significant weakness: They are only effective when the operating system is running. Particularly with mobile computers, you must assess the risk of an attacker's gaining physical access to a computer. With physical access, an attacker can directly access a computer’s hard disk and bypass file permissions, regardless of whether the attacker has valid user credentials. To protect against this type of offline attack, use physical security and Encrypting File System (EFS).

Registry Permissions

The registry is primarily used to store configuration information for the operating system and applications. Although the registry is rarely used to store confidential data, restricting registry permissions is important for protecting the integrity of the system. Attackers who modify specific registry keys might be able to capture user passwords, gain elevated privileges, or render a computer inoperable.

The registry is also the only way to configure several important client security settings. For example, the DeadGWDetectDefault registry entry (located within HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\) is set to 1 by default for Windows XP clients. This enables clients to automatically switch to a working router if the default router fails. However, there is a theoretical risk that a very sophisticated hacker could abuse this feature to redirect a computer’s network traffic. Therefore, you may want to change this value to 0.

For a complete discussion of registry settings, refer to the Threats and Countermeasures Guide at http://www.microsoft.com/technet/security/guidance/
Serversecurity/tcg/tcgch00.mspx and the Windows XP Security Guide v2 at http://go.microsoft.com/fwlink/?linkid=14840.

Service Permissions

Services run in the background to perform operating-system tasks. Often, services use the Local System account and have unlimited access to system resources. Unfortunately, attackers have historically targeted services to gain elevated privileges on a computer. You can reduce that risk by configuring services to log on with restricted user accounts, as shown in Figure 6. However, this requires extensive testing to ensure the configured user account has sufficient permissions to enable the service to function correctly.

Figure 6. Configuring service permissions
See full-sized image

You can also use Group Policy settings to control which users and groups have permission to start, stop, and pause services. Most environments do not need to edit the default service permissions, including Woodgrove.

Event Log and Auditing Settings

Operations groups often use security auditing and event logs to help maintain security after deployment. When enabled, security auditing adds events to the local event log whenever a user successfully or unsuccessfully attempts to perform the following types of actions:

Theoretically, this information can be used to track successful and unsuccessful attacks. In practice, the vast majority of security events are not related to security attacks, which reduces the usefulness of the audit logs. Organizations that require auditing can build on the security auditing built into Windows XP to fulfill this requirement. However, the most practical way to identify and trace attacks is to use third-party intrusion detection software. Most environments do not need to edit the default event log and auditing settings, including Woodgrove.

User Rights Settings

User rights control what actions specific users and groups can perform on a computer. Examples of frequently configured user rights are:

By default, different groups (such as the local Administrators, Power Users, and Users) have different user rights. For example, Administrators, Backup Operators, Power Users, and Users all have the Shut Down the System user right. However, only members of the Administrators group have the Debug Programs user right because it can be exploited to gain elevated privileges.

If you grant end users limited privileges by not adding them to the Administrators group, you may need to grant additional user rights to enable specific applications to run or to enable users to perform specific tasks. For example, developers almost always need the Debug Programs user right. You will identify additional user rights requirements when testing applications on your desktop platform. After deployment, users may complain of problems using nonstandard applications, and administrators may need to adjust user rights on a user-by-user basis to enable these applications to run properly.

Security Options

Security options are a wide range of settings that do not fit into other categories. For example, the following are security options in Windows XP:

Firewall Settings

Firewalls filter network traffic and can be used to substantially reduce the risk of network attacks. Most organizations use a perimeter firewall, which is a type of network firewall that filters traffic coming into the internal network from the Internet. Windows XP also includes a host-based firewall. Host-based firewalls run as software on a client computer and protect the computer from attacks originating on the local network. Host-based firewalls are recommended for all computers, but they are critical for mobile computers, which may connect to unprotected networks.

Windows XP clients that do not have Service Pack 2 installed have Internet Connection Firewall (ICF) available, but it is not enabled by default. After SP2 is installed, ICF is upgraded to Windows Firewall, which provides substantially more flexibility and can be managed by using Group Policy settings.

Woodgrove decided to disable ICF for clients with Windows XP and Service Pack 1 (SP1) because it caused application-compatibility problems and could not be configured by GPOs. Woodgrove can enable Windows Firewall with SP2, however, because it provides greater flexibility and can be configured by using GPOs. Enabling Windows Firewall will provide significant security enhancements. Unfortunately, computers in the Johannesburg Regional site cannot use SP2 because of an application-compatibility requirement and therefore must do without a host-based firewall.

Planning Application Security

Applications add capabilities to an operating system, but they can also add vulnerabilities. For example, many viruses have penetrated internal networks by exploiting weaknesses in e-mail clients and Web browsers. When designing a client platform to meet security requirements, you must consider the applications that will run on that platform and evaluate the security strengths and weaknesses of competing applications. Specifically, consider the following factors:

Non-Microsoft Security Applications

Even environments with minimal security requirements will need to add non-Microsoft software to their client computers. You must address the following security needs that may be lacking in Windows clients:

Woodgrove has opted to use Computer Associates’ eTrust Antivirus Version 7.1.

Choosing an Update Methodology

You must plan to update every network component that uses software. Of these network components, client computers will be the most challenging to update because enterprises have them in large numbers, because they run a variety of applications that require updating, and because they are frequently disconnected from the network. To keep your systems up to date, follow this process:

The sections that follow discuss three common update deployment technologies: Windows Update, Windows Server Update Services (WSUS), and SMS. Additionally, you may wish to investigate PolicyMaker Software Update by DesktopStandard (http://www.desktopstandard.com/PolicyMakerSoftwareUpdate.aspx), a non-Microsoft update management tool.

Windows Update

Windows Update is a free Microsoft service for keeping computers running the Windows operating systems up to date with the latest Microsoft operating system and application updates. Windows Update is made up of three components: the Windows Update Web site, the Automatic Update client, and the Windows Update Catalog. Millions of people use the Windows Update Web site (http://windowsupdate.microsoft.com) each week as a way to keep their Windows-based systems current. When a user connects to the Windows Update site, Windows Update evaluates the user’s computer to check which software updates and updated device drivers should be applied to keep the system secure and reliable. Windows Update is not recommended for enterprises, however, and Woodgrove has specifically removed the Windows Update icon from the desktop.

The Windows Update Web site includes a catalog of all software update installation packages for downloading by administrators. These software update installation packages can then be stored on a CD, distributed, and installed through other means, such as SMS or non-Microsoft software distribution tools, or they can be used when installing new computers.

Windows Server Update Services

Windows Server Update Services (WSUS) is a simplified version of Windows Update that you can host on your private network for critical updates and security updates. WSUS connects to the Windows Update site, downloads critical updates, security updates, and service packs, and adds them to a list of updates that require administrative approval. WSUS then notifies administrators by e-mail that new updates are available. After an administrator has approved and prioritized these updates, WSUS automatically makes them available to any computer running Automatic Updates. Automatic Updates (when properly configured) then checks the WSUS server and automatically downloads and installs updates as configured by the administrators. As shown in Figure 7, WSUS can be distributed across multiple servers and locations to scale to enterprise needs. WSUS meets the needs of medium-sized organizations and many enterprises.

Figure 7. Typical enterprise WSUS architecture
See full-sized image

For more information about update management with WSUS, refer to Patch Management Using Microsoft® Software Update Services (SUS) at http://www.microsoft.com/technet/itsolutions/cits/
mo/swdist/pmsus/pmsus251.mspx. SUS is the previous version of WSUS, but most of the content is still applicable.

Systems Management Server

Systems Management Server (SMS) provides a variety of tools to help you deploy updates to an enterprise. With the software distribution feature of SMS, you can automatically update all SMS client computers in your organization with a new update. You can allow your users to run the update installation whenever they like, or you can schedule the update installation to run at a specific time. You can also schedule it to run on SMS client computers at a time when your users are not logged on. Woodgrove uses SMS because it is a critical component of systems management in an enterprise. For more information about SMS, visit Update Your Dell Servers with New SMS Tool at http://www.microsoft.com/smserver/.
For information about using SMS for update management, refer to Patch Management Using Systems Management Server 2003 at http://www.microsoft.com/downloads/details.aspx?FamilyId=E9EAB1BD-13E7-4E25-85C5-CE2D191C3D63&displaylang=en.

Service Pack 2 and Windows Firewall

Windows XP SP2 contains the latest collection of updates for Windows XP. These updates help improve the security, reliability, and compatibility of the operating system by introducing a set of security technologies that will help increase Windows XP-based computers' abilities to withstand malicious attacks from viruses and worms. These technologies include network protection, memory protection, improved e-mail security, safer browsing, and improved computer maintenance.

SP2 includes numerous improvements that are related to the manageability of security services. These improvements allow administrators to implement more specific security settings across user accounts and computers.

A major change in SP2 is the shift to being more secure by default. Most security changes are implemented by default and do not require configuration changes. Although many of these improvements result in compatibility challenges, the overall improvement in operating system security usually makes up for any such challenges.

The following list describes decisions related to SP2 that the Security feature team must make for the Solution Accelerator for BDD project:

Top of page

Infrastructure and Deployment Security

Although this document focuses on deploying desktops with the best possible security configurations, the security of the deployment infrastructure itself must also be considered. The sections that follow do not attempt to provide comprehensive coverage for protecting the deployment infrastructure. Instead, these sections are intended to enlighten you to possible security risks so that you can mitigate them as part of the security risk management process.

Protecting Deployment Staging Areas

Staging areas where images are created, updated, and maintained pose a significant potential vulnerability. First, because computers in the staging area (including computers that haven’t been updated and would not meet your organization’s security requirements) are likely to run with varying degrees of security, there is an elevated risk of the computers' being compromised. In particular, you must protect those computers from worms and viruses by placing them on an isolated network segment.

Using a perimeter firewall alone is not sufficient: Computers in the deployment staging area must be on a separate network that cannot be reached by your production computers. If computers on your internal network can route traffic to your deployment staging area, there is a high risk that deployment staging servers will be infected with a worm. Worms are common on internal networks because mobile computers may become infected while connected to untrusted networks.

Second, because these images form the basis for all new computers in your organization, a compromised image can have a widespread effect and a very high cost. Use the security risk management process (discussed earlier in this document) to evaluate this risk and assign resources to mitigate any vulnerabilities.

Third, staging areas often contain credentials (usernames and passwords) used to automatically authenticate computers during the setup process. Protect these credentials to reduce the risk of an attacker's abusing them. For more information about protecting servers that host images and other infrastructure components in the staging area, refer to the Windows Server 2003 Security Guide at http://www.microsoft.com/technet/security/prodtech/
windowsserver2003/W2003HG/SGCH00.mspx.

You cannot completely eliminate the risk of a security compromise. Therefore, you must plan to identify and track attacks. Security auditing, built into all recent versions of the Windows operating system, is a useful tool for recording user actions. For more information, read, “Auditing Security Events Best Practices” at http://www.microsoft.com/technet/prodtechnol/windowsserver2003/
library/ServerHelp/5658fae8-985f-48cc-b1bf-bd47dc210916.mspx  in the Windows Server 2003 Help and Support Center.

Additionally, you may need a third-party intrusion-detection system to meet your security requirements. For information about how Microsoft uses Microsoft Operations Manager (MOM) and third-party tools for auditing, read the white paper Incident Response: Managing Security at Microsoft at http://www.microsoft.com/technet/itsolutions/
msit/security/msirsec.mspx.

Protecting Production Deployment Servers

Deployment servers must be protected as well. Like the servers in the staging environment, deployment servers typically store configuration files, which might include user credentials. Protect these servers with physical controls: Only authorized personnel should have physical access to production or development deployment servers, and even then it is better to forbid a single user to have access to the server and instead always require collusion.

Reduce the attack surface of the server by limiting the services that are running. For example, although you probably need the File Server role, you should definitely not install the Application Server role on a deployment server. For the roles you do install, including the File Server role, identify security guides, such as the Windows Server 2003 Security Guide at http://www.microsoft.com/technet/security/prodtech/
windowsserver2003/W2003HG/SGCH00.mspx that will enable you to harden the deployment server to meet your security requirements.

If possible, disallow remote log-on entirely. If that is not possible, then you should restrict remote access to the deployment server to a small group of trusted staff. Use network filtering (such as that included in Windows Firewall) to restrict network connections to those originating from clients on your local area networks (LANs).

Again, consider reducing the risk of a single administrator's making malicious changes or installing malicious software in operating-system images by requiring collaboration. One easy way to require collaboration is to configure deployment servers to allow only a handful of special user accounts to change images. For each of those user accounts, have two different administrators each type half of the user account’s password. To successfully authenticate and change an image, two administrators will need to work together. This significantly reduces the risk of a single disgruntled employee compromising your servers.

To reduce the risk of password-cracking attacks, consider implementing multifactor authentication by requiring a password to be used in conjunction with a smartcard or biometric authentication (such as a fingerprint scanner). You do not necessarily need to deploy multifactor authentication to an entire enterprise; you can require multifactor authentication only for the most critical computers on your network, such as staging and production deployment servers.

At a minimum, use the Microsoft Baseline Security Analyzer (MBSA) to audit the security configuration of your deployment servers. You can download MBSA at http://www.microsoft.com/technet/security/tools/mbsahome.mspx. The Microsoft Office Visio 2003 Connector for the MBSA, available at http://www.microsoft.com/technet/security/tools/mbsavisio.mspx, can help you visualize the results of the audit.

Protecting Windows PE and Client Deployment Scripts

Most organizations use Microsoft Windows Preinstallation Environment (Windows PE) during the client deployment process. Like any software, Windows PE has the potential to contain vulnerabilities. As a result, you need to have plans to keep Windows PE updated with the latest security updates. Additionally, you should use network security to protect Windows PE during the deployment process when clients are connected to the network. Windows PE 1.5 and later includes Windows Firewall to further reduce the risk of network attacks. If possible, in light touch scenarios start Windows PE when clients are connected to a network segment that has extremely limited access.

Consider security when developing scripts that will run within Windows PE. Whenever possible, avoid adding user credentials in clear text directly to the script. If you must store credentials in a script, store them with reversible encryption to prevent a casual observer from identifying the username and password for an account. Additionally, you must protect the scripts from unauthorized access by using file and share permissions. Finally, use code reviews for Windows PE scripts just as you would for a custom application. Code reviews can prevent a single staff member from adding malicious code to a script.

For more information about Windows PE, visit the Microsoft Web page called Tools: Microsoft Windows Preinstallation Environment at http://www.microsoft.com/licensing/programs/sa/support/winpe.mspx.

Other Infrastructure Security Considerations

Some of these considerations are:

Top of page

Milestone: Migration Plan Accepted

Milestones are synchronization points for the overall solution. Refer to the Plan, Build, and Deploy Guide for the Solution Accelerator for BDD. At this milestone, the Security feature team has chosen a strategy for policies and a security level for the organization. This milestone requires the deliverables listed in Table 2.

Table 2. Migration Plan Accepted Milestone Deliverables

Top of page

4 of 7