Developing

Figure 7 shows the development activities that occur during the Developing Phase. Most of these activities involve reviewing the specific settings in the security files, implementing them in builds, and analyzing the results.

Figure 7. Activities during the Developing Phase

On This Page

Roles and Responsibilities
Developing Security Settings
Defining Security Settings
Configuring Windows Firewall
Internet Explorer Security Customization and Installation
Milestone: Deployment Environment Initiated

Roles and Responsibilities

In addition to the tasks defined in the process description that follows, note the following responsibilities that are allocated to the role clusters. Table 4 defines these focus areas for the different role clusters during this phase.

Table 4. Roles and Responsibilities During the Developing Phase

Developing Security Settings

The Security feature team may discover problems with security settings in the Developing Phase that the team did not anticipate in the Planning Phase. First, it is entirely possible that important security settings were overlooked, which could lead to vulnerabilities. Second, permissions are often too restrictive to allow applications to run properly. The sections that follow provide techniques for identifying vulnerabilities that were not identified or addressed in the Planning Phase and for resolving problems with applications that fail to run properly because of missing user privileges.

Identifying Potential Vulnerabilities

Organizations that carefully analyze client security may evaluate hundreds of different configuration settings. Because of human error, it is extremely likely that one or more of the settings specified in the Planning Phase will be lost when test client computers are deployed in the Developing Phase. Fortunately, automated security scanning tools can identify settings that may have been overlooked in either the Planning or Developing Phases.

One such scanning tool is the MBSA, which is available at no charge from Microsoft at https://www.microsoft.com/technet/security/tools/mbsahome.mspx. As shown in Figure 8, the MBSA can scan client and server computers for potential vulnerabilities and missing security updates.

Figure 8. The MBSA scanning for vulnerabilities

In addition to scanning the base client operating system, MBSA 2.0 scans the following optional components and client applications for potentially vulnerable configurations:

• IIS

• Microsoft SQL Server™

• Internet Explorer 5.01 or later

• Microsoft Office 2003, Office XP, and Office 2000

• Microsoft Data Access Components (MDAC)

• Microsoft VM

• Microsoft Extensible Markup Language (MSXML)

Scanned computers must be running the Remote Registry and the Server services. If the Security feature team has disabled these services to reduce the computer’s attack surface or if a firewall blocks their network communications, the MBSA will fail. Team members must either scan computers locally or identify a different technique for identifying vulnerabilities. For more information about the MBSA, go to https://www.microsoft.com/technet/security/tools/mbsahome.mspx.

Resolving Problems with Overly Restrictive Permissions

Environments that limit user permissions often experience problems running some applications, especially legacy applications. Often, these problems occur because application developers only test their applications while logged on as members of the Administrators group. Typically, users do not require full administrator permissions. Instead, they generally require only a handful of file permissions, registry permissions, and user rights in addition to those typically granted members of the Users group.

To identify which permissions users need to run a specific application, enable security auditing, and then examine the Security event log. Follow the process shown in Figure 9 to identify and work around permissions problems when using limited user accounts.

Figure 9. Application permissions troubleshooting process

If Security feature team members are forced to modify user privileges to resolve a problem with overly restrictive permissions, they must assess whether the adjusted privileges still meet the organization’s security requirements. If necessary, identify an alternative way to mitigate the risk that originally required implementing the restrictive privilege.

Defining Security Settings

When implementing security settings chosen during the Planning Phase, typically start with the operating systems default settings in the image file, and then apply one of the security templates included with the operating system. Team members can apply these settings directly to the image using local Group Policy, or they can import the security templates into GPOs linked to the Active Directory.

Team members cannot use security templates to configure every security setting must be specified on client platforms, however. Augment the settings in security templates with Group Policy settings. Additionally, team members may have to further configure operating system image files using registry settings. Applications may also have unique configuration requirements. For example, applications are typically configured based on the Microsoft .NET Framework by editing .xml files. Discuss the best way to configure individual applications with the software vendor or the application developer.

For general information about:

• Security templates, see Security Templates Overview at https://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/sag_scewhatis.mspx.

• Applying security settings with scripts, see Scripting for Security at https://www.microsoft.com/technet/scriptcenter/hubs/security.mspx.

• Group Policy settings, see Group Policy at https://www.microsoft.com/windowsserver2003/technologies/management/grouppolicy/default.mspx.

Configuring Windows Firewall

Group Policy is the preferred method for configuring Windows Firewall. However, there are situations for which this method is not possible or is not used. When Group Policy cannot be used or is not used, the following options are available for configuring Windows Firewall settings:

• Use the Unattend.xml (in Windows Vista) or the Unattend.txt (in Windows XP) file to configure Windows Firewall settings. The Unattend file has options to configure Windows Firewall settings when running an unattended setup of Windows. The Computer Imaging System Feature Team Guide describes the BDD 2007 project’s Unattend.xml or Unattend.txt file.

• Use the Netfw.inf file to configure Windows Firewall settings in Windows XP. The Netfw.inf file for Windows XP can configure Windows Firewall by specifying a set of registry settings equivalent to the options available from the Windows Firewall component in Control Panel and through Windows Firewall Group Policy settings when a user is performing an interactive setup of Windows XP.

• Run a script file that contains Netsh commands to configure Windows Firewall settings. To configure computers running Windows after deploying the operating system, have users run a script file, such as a batch file (*.bat) or a command file (*.cmd), that contains the series of Netsh commands to configure the Windows Firewall operational mode, allowed programs, and allowed ports.

For detailed instructions on configuring Windows Firewall, read “Appendix B. Configuring Windows Firewall Settings for Windows XP” or “Appendix C. Configuring Windows Firewall Settings for Windows Vista.”

Internet Explorer Security Customization and Installation

Corporate administrators can centrally administer Internet Explorer installations by using the Internet Explorer Customization Wizard, the IEAK, or Active Directory Group Policy. When running the Internet Explorer Customization Wizard to create custom browser packages, administrators can determine how Internet Explorer is installed, how the browsing software and Internet Explorer components are customized, and what browser and messaging options are available to your users.

If the needs of the organization change after Internet Explorer is installed, administrators can use the IEAK Profile Manager to update browser settings. Then, they can use the automatic configuration feature in Internet Explorer to deploy the updated settings to users’ desktops without leaving their office. They can also set policies and restrictions for the browser, including security, messaging, and desktop settings. These policies and restrictions can help manage the organization’s resources and bandwidth. Does the accounting department have different needs than the marketing department? Create different profiles that contain settings and restrictions tailored to each department.

For more information about using the IEAK Profile Manager or the Internet Explorer Customization Wizard to pre-configure security settings, see the Internet Explorer Web site at https://www.microsoft.com/ie.

Milestone: Deployment Environment Initiated

Milestones are synchronization points for the overall solution. See the Plan, Build, and Deploy Guide.

At this milestone, the Security feature team has created and added security configuration files to the image. This milestone requires the deliverables listed in Table 5.

Table 5. Deployment Environment Initiated Milestone Deliverables

Download

Get the Microsoft Solution Accelerator for Business Desktop Deployment 2007

Update Notifications

Sign up to learn about updates and new releases

Feedback

Send us your comments or suggestions