Mitigating Application Compatibility

On This Page

Introduction
Applying Mitigation Fixes
Removing Mitigation Fixes
Summary

Introduction

Now that you have finished testing applications and identifying any compatibility issues, your next step is to overcome these incompatibilities. The best approach is to redevelop or upgrade the incompatible software to make it compliant with the better security baseline provided by Windows XP SP2. A short term fix, however, is often required until a more permanent solution can be implemented. This short term approach allows the applications to operate by selectively reducing the security settings that Windows XP SP2 implements.

This chapter describes mitigation techniques that use a combination of the UI, scripts, and Active Directory Group Policy. Mitigation includes implementing a compatibility timeline to track the deployment of mitigation fixes. Once full application compatibility has been achieved through rewriting or upgrading applications, the reduced security settings can be removed.

For more information on changes and enhancements to Group Policy settings for Windows XP SP2, see the Microsoft Web site at

https://go.microsoft.com/fwlink/?linkid=22031

Applying Mitigation Fixes

Applying mitigation fixes to computers running Windows XP SP2 requires a cautious approach with full awareness of the implications of making any changes. Changes to security settings in Windows XP SP2 should be carried out only in response to specific application compatibility issues and should weaken security only to the extent required to maintain application functionality.

Internet Explorer

Internet Explorer has the largest number of improvements in Windows XP SP2. Because Internet Explorer is a popular front end for Web applications, these new features are likely to affect application functionality. This section contains mitigation techniques for the following Internet Explorer features:

• Feature control

• UrlAction security

• Binary behaviors

• Local machine lockdown

• MIME handling

• Object caching protection

• Windows restrictions

• Zone elevation blocks

• Information Bar

• Pop-up management

• Add-on management

Feature Control

Feature Control settings specify which processes – including Internet Explorer – are affected by many of the security features in Windows XP SP2. If the Feature Control setting is enabled, security features can be controlled using Windows XP SP2 functionality, such as the security settings in Internet Explorer.

Feature Control does not directly configure the security setting for the individual features, but allows the configuration to take effect. It is possible to use Feature Control to enable individual applications to opt in or out of implementing security settings. This flexibility allows administrators to lessen security in specific areas that may cause incompatibility and provides a simple switch for security configurations.

Note: If the Feature Control setting is disabled, Internet Explorer behavior reverts to that in Windows XP Service Pack 1 (SP1).

There are several ways to configure Feature Control in Windows XP SP2. These are:

• Using the Security Settings dialog box.

• Creating and executing a RegFile.

• Running a script.

• Implementing Active Directory Group Policy.

These options give you the ability to select the most appropriate method for your environment.

Using the Security Settings Dialog Box

You can configure the features within the UI, through Internet Options in Control Panel, using the Security tab in the Internet Options dialog box. The Custom Level button displays the Security Settings dialog box shown in Figure 3.1.

Figure 3.1 Internet Explorer Security Settings dialog box

On the same tab, you can configure zone membership by selecting the relevant zone and clicking the Sites button. Figure 3.2 shows the Restricted sites dialog box used for adding sites to this security zone.

Figure 3.2 Restricted Sites configuration interface

The combination of these interfaces enables manual configuration of security zones and the features in each zone.

Using Registry Editor

You can configure security features directly using Regedit, the Windows XP Registry Editor, although, using Regedit is not a recommended method of configuration. Use a script or .reg file to make the necessary changes once the required registry locations are identified. Start Regedit and then navigate to the following key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
\Internet Explorer\Main\FeatureControl

This key contains a child key for each feature. Figure 3.3 shows the contents of the Feature Control registry key.

Figure 3.3 Feature Control Registry Key and Subkeys

Each feature-specific key contains values for individual settings. Entering a value of 1 enables the Windows XP SP2 security configuration for the relevant feature. A value of 2 configures the feature to behave as with Windows XP SP1. The “*” value provides a default configuration for all processes that are not specifically defined.

The values for each individual feature key are similar to the ones shown in Figure 3.4.

Figure 3.4 Feature specific registry key values showing configuration for individual processes

NOTE: All corresponding settings in HKEY_COMPUTER_USER override the settings in HKEY_LOCAL_MACHINE. Additionally, settings made via Group Policy override the corresponding settings in either HKEY_CURRENT_USER or HKEY_LOCAL_MACHINE.

Creating and Executing a RegFile

You can use Regedit to export a specific feature key to a .reg file. This file can be edited using any text editor and then imported to the registry on the target computer by executing the .reg file. Figure 3.5 shows the contents of a typical registry export file.

Figure 3.5 The contents of a .reg file exported from the Feature Behaviors registry key

A good method of creating the .reg file is for an administrator to configure a test computer before exporting the relevant keys.

Running a Script

Alternatively, you can write a script to edit the registry and implement the required configuration. The following listing provides an example of a suitable script.

Note: Some of the lines in the following code have been displayed on multiple lines for better readability.

Set WshShell = CreateObject("Wscript.Shell")
   WshShell.RegWrite "HKEY_LOCAL_MACHINE\SOFTWARE
   \Microsoft\Internet 
Explorer\Main\FeatureControl\FEATURE_BEHAVIORS
\MyApp.exe", "1", "REG_DWORD"

Implementing Active Directory Group Policy

Active Directory Group Policy provides an easy way for administrators to roll out security settings to multiple computers. The Feature Control settings for Internet Explorer are in both Computer and User configurations under the following path:

Administrative Templates\Windows Components
\Internet Explorer\Security Features

Figure 3.6 shows the Feature Control settings in Group Policy.

Figure 3.6 Active Directory Group Policy settings for Feature Control

Here, you can specify whether Windows XP SP2 secure configuration applies to specific processes for each feature. Group Policy provides additional feature-specific configurations for some features. For example, binary behaviors allow a list of behaviors that are approved by the administrator, Add-on Management provides a specific add-on list, and the Network Protocol Lockdown can be configured for each Internet Explorer security zone.

To view additional information regarding this technology in this guide, click the following links:

Introduction to Feature Control

Application Compatibility Testing for Feature Control

UrlActions

A number of features that this guide covers are configured using UrlAction security. Prior to Windows XP SP2, these features were configurable on a zone-by-zone basis, but required the Internet Explorer Administration Kit (IEAK) to deliver configuration settings to multiple systems as part of a security policy. In Windows XP SP2, this functionality is now included in the Group Policy Management Console (GPMC), though configuration is still possible through the UI, using scripts or by importing .reg files.

Like the Feature Control settings, you can configure UrlActions from the Security tab in the Internet Options interface. Figure 3.7 shows the Internet Explorer Security Settings dialog box for a specific security zone.

Figure 3.7Internet Explorer security zone settings

From this interface, it is possible to enable or disable different UrlActions in each zone. Using the Security Settings and the Sites dialog boxes, you can organize UrlActions and site memberships to provide fewer compatibility issues.

You can also configure UrlActions by directly accessing the registry using scripts or .reg files. The registry defines each security zone at the following key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
\CurrentVersion\Internet Settings\Zones

The Zones key has 5 child keys, numbered 0 to 4 that contain the configuration for each security zone:

0 – Local Machine

1 – Intranet

2 – Trusted Sites

3 – Internet

4 – Restricted Sites

You can use the following registry key to configure Local Machine Lockdown:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
\CurrentVersion\Internet Settings\Lockdown-Zones\0

Each zone key contains every configurable action for that zone. Figure 3.8 shows the registry keys and values that store security zone configuration.

Figure 3.8 Security zone configuration stored in the registry

UrlActions are represented by a numerical value in the registry. Table 3.1 links the UrlAction name with the numbers displayed in the registry.

Table 3.1 UrlActions and Associated Numeric Identifier

UrlAction Flag Name	Security Settings UI	Numeric Identifier
URLACTION_DOWNLOAD_SIGNED_ACTIVEX	Download signed ActiveX controls	1001
URLACTION_DOWNLOAD_UNSIGNED_ACTIVEX	Download unsigned ActiveX controls	1004
URLACTION_ACTIVEX_RUN	Initialize and script ActiveX controls not marked as safe	1200
URLACTION_ACTIVEX_OVERRIDE_OBJECT_SAFETY	Run ActiveX controls and plug-ins	1201
URLACTION_SCRIPT_RUN	Active scripting	1400
URLACTION_SCRIPT_JAVA_USE	Scripting of Java applets	1402
URLACTION_SCRIPT_SAFE_ACTIVEX	Script ActiveX controls marked safe for scripting	1405
URLACTION_CROSS_DOMAIN_DATA	Access data sources across domains	1406
URLACTION_SCRIPT_PASTE	Allow paste operations via script	1407
URLACTION_HTML_SUBMIT_FORMS	Submit non-encrypted form data	1601
URLACTION_HTML_FONT_DOWNLOAD	Font download	1604
URLACTION_HTML_USERDATA_SAVE	Userdata persistence	1606
URLACTION_HTML_SUBFRAME_NAVIGATE	Navigate sub-frames across different domains	1607
URLACTION_HTML_META_REFRESH	Allow META REFRESH	1608
URLACTION_HTML_MIXED_CONTENT	Display mixed content	1609
URLACTION_SHELL_INSTALL_DTITEMS	Installation of desktop items	1800
URLACTION_SHELL_MOVE_OR_COPY	Drag and drop or copy and paste files	1802
URLACTION_SHELL_FILE_DOWNLOAD	File download	1803
URLACTION_SHELL_VERB	Launching applications and files in an IFRAME	1804
URLACTION_SHELL_POPUPMGR	Use Pop-up Blocker	1809
URLACTION_NETWORK_MIN	Logon	1A00
URLACTION_CLIENT_CERT_PROMPT	Do not prompt for client certificate selection when no certificates or only one certificate exists	1A04
URLACTION_JAVA_PERMISSIONS	Java permissions	1C00
URLACTION_CHANNEL_SOFTDIST_PERMISSIONS	Software channel permissions	1E05
URLACTION_BEHAVIOR_RUN	Script and binary behaviors	2000
URLACTION_MANAGED_SIGNED	Run .NET Framework-reliant components signed with Authenticode	2001
URLACTION_MANAGED_UNSIGNED	Run .NET Framework-reliant components not signed with Authenticode	2004
URLACTION_FEATURE_MIME_SNIFFING	Open files based on content, not file extension	2100
URLACTION_FEATURE_ZONE_ELEVATION	Web sites in less privileged Web content zones can navigate into this zone	2101
URLACTION_FEATURE_WINDOW_RESTRICTIONS	Allow script-initiated windows without size or position constraints	2102
URLACTION_AUTOMATIC_DOWNLOAD_UI	Automatic prompting for file downloads	2200
URLACTION_AUTOMATIC_ACTIVEX_UI	Automatic prompting for ActiveX controls	2201
URLACTION_ALLOW_RESTRICTEDPROTOCOLS	Allow active content over restricted protocols to access my computer	2300

Table 3.2 combines the UrlAction numeric identifiers with possible configuration values.

Table 3.2 UrlAction Number Names and Configuration Options

Name	UrlAction Policy Setting Options
1001	"Enable"=0x00000000 "Disable"=0x00000003 "Prompt"=0x00000001
1004	"Enable"=0x00000000 "Disable"=0x00000003 "Prompt"=0x00000001
1200	"Administrator approved"=0x00010000 "Enable"=0x00000000 "Disable"=0x00000003 "Prompt"=0x00000001
1201	"Enable"=0x00000000 "Disable"=0x00000003 "Prompt"=0x00000001
1400	"Enable"=0x00000000 "Disable"=0x00000003 "Prompt"=0x00000001
1402	"Enable"=0x00000000 "Disable"=0x00000003 "Prompt"=0x00000001
1405	"Enable"=0x00000000 "Disable"=0x00000003 "Prompt"=0x00000001
1406	"Enable"=0x00000000 "Disable"=0x00000003 "Prompt"=0x00000001
1407	"Enable"=0x00000000 "Disable"=0x00000003 "Prompt"=0x00000001
1601	"Enable"=0x00000000 "Disable"=0x00000003 "Prompt"=0x00000001
1604	"Enable"=0x00000000 "Disable"=0x00000003 "Prompt"=0x00000001
1606	"Enable"=0x00000000 "Disable"=0x00000003
1607	"Enable"=0x00000000 "Disable"=0x00000003 "Prompt"=0x00000001
1608	"Enable"=0x00000000 "Disable"=0x00000003
1609	"Enable"=0x00000000 "Disable"=0x00000003 "Prompt"=0x00000001
1800	"Enable"=0x00000000 "Disable"=0x00000003 "Prompt"=0x00000001
1802	"Enable"=0x00000000 "Disable"=0x00000003 "Prompt"=0x00000001
1803	"Enable"=0x00000000 "Disable"=0x00000003
1804	"Enable"=0x00000000 "Disable"=0x00000003 "Prompt"=0x00000001
1809	"Enable"=0x00000000 "Disable"=0x00000003
1A00	"Anonymous logon"=0x00030000 "Automatic logon only in Intranet zone"=0x00020000 "Automatic logon with current user name and password"=0x00000000 "Prompt for user name and password"=0x00010000
1A04	"Enable"=0x00000000 "Disable"=0x00000003
1C00	"High safety"=0x00010000 "Medium safety"=0x00020000 "Low safety"=0x00030000 "Custom"=0x00800000 "Disable Java"=0x00000000
1E05	"High Safety"=0x00010000 "Medium Safety"=0x00020000 "Low Safety"=0x00030000
2000	"Enable"=0x00000000 "Administrator approved"=0x00010000 "Disable"=0x00000003
2001	"Enable"=0x00000000 "Disable"=0x00000003 "Prompt"=0x00000001
2004	"Enable"=0x00000000 "Disable"=0x00000003 "Prompt"=0x00000001
2100	"Enable"=0x00000000 "Disable"=0x00000003
2101	"Enable"=0x00000000 "Disable"=0x00000003 "Prompt"=0x00000001
2102	"Enable"=0x00000000 "Disable"=0x00000003
2200	"Enable"=0x00000000 "Disable"=0x00000003
2201	"Enable"=0x00000000 "Disable"=0x00000003
2300	"Enable"=0x00000000 "Disable"=0x00000003 "Prompt"=0x00000001

To configure security zones, use a .reg file from an exported zone key and edit as necessary or use a script to edit the registry directly as shown previously.

For more information about How to Add, Modify, or Delete Registry Subkeys and Values by Using a Registration Entries (.reg) File, see the Microsoft Web site at

https://support.microsoft.com/default.aspx?kbid=310516

You can also use Group Policy to edit the configuration of UrlActions on a zone-by-zone basis. The UrlAction settings for Internet Explorer are in both Computer and User configurations under the following path:

Administrative Templates\Windows Components
\Internet Explorer\Internet Control Panel\Security Page

Figure 3.9 shows the security zones configuration in the Group Policy console.

Figure 3.9 Security zone configurations in Group Policy

Zone templates can also be configured through the registry or by using Group Policy. These templates allow standard configurations to be applied easily to groups of computers. You can apply the template through the Internet Explorer Security Settings dialog box by clicking the setting you want to apply and then clicking the Reset button.

Figure 3.10 shows where to apply a security zone template.

Figure 3.10 Applying a security zone template using the UI

The registry holds the template settings in the following key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
\CurrentVersion\Internet Settings\TemplatePolicies

Again, you can make configuration changes using a .reg file or script. Alternatively, use Active Directory Group Policy to configure zone templates at:

Administrative Templates\Windows Components
\Internet Explorer\Internet Control Panel\Security Page

Table 3.3 lists the configurable numerical values for these templates.

Table 3.3 Configurable Values for Security Zone Settings

Value	DWord	Setting
0	0x00000000	enable
1	0x00000001	prompt
3	0x00000003	disable
65536	0x00010000	high safety
131072	0x00020000	medium safety
196608	0x00030000	low safety

Table 3.4 shows the default configuration for each security zone.

Table 3.4 Default Security Zone Settings

UrlAction Numeric Name	High Security Template Restricted Zone	Medium Security Template Internet Zone	Medium-Low Security Template Intranet Zone	Low Security Template Trusted Zone	Local Machine Zone (LMZ)	Locked-down LMZ *
1001	3	1	1	0	0
1004	3	3	3	1	1	3
1200	3	0	0	0	0	3
1201	3	3	3	1	1	3
1400	3	0	0	0	0	3
1402	3	0	0	0	0
1405	3	0	0	0	0
1406	3	3	1	0	0
1407	3	0	0	0	0
1601	1	1	0	0	0
1604	1	0	0	0	0
1606	3	0	0	0	0
1607	3	0	0	0	0
1608	3	0	0	0	0
1609	1	1	1	1	1
1800	3	1	1	0	0
1802	1	0	0	0	0
1803	3	0	0	0	0
1804	3	1	1	0	0
1809	0	0	3	3	3
1A00	65536	131072	131072	0	0
1A04	3	3	0	0	0	3
1C00	0	65536	131072	196608	196608	0
1E05	65536	131072	131072	196608	196608
2000	3	0	0	0	0	65536
2001	3	0	0	0	3	3
2004	3	0	0	0	3	3
2100	3	0	0	0	0	3
2101	0	0	0	1	3	3
2102	3	3	0	0	0	3
2200	3	3	0	0	0	3
2201	3	3	0	0	0	3
2300	3	1	1	1	1	N/A

Use Feature Control and UrlActions together to configure security settings in Internet Explorer security zones. If you experience compatibility issues with applications, try changing security settings for the specific zone without softening security for the computer as a whole. If necessary, use Feature Control to disable or enable a security feature for specific processes only.

To view additional information regarding this technology in this guide, click the following links:

Introduction to UrlActions

Application Compatibility Testing for UrlActions

Binary Behaviors

Binary behaviors can either be enabled or disabled using Feature Control and UrlAction security, as described earlier in this guide.

To view additional information regarding this technology in this guide, refer the following sections:

“Feature Control” subsection of the “Mitigation Application Compatibility” section.

“UrlActions” subsection of the “Mitigation Application Compatibility” section.

In addition to allowing binary behaviors in specific zones, it is possible to configure a list of specific behaviors approved by the administrator using the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
\CurrentVersion\Internet Settings\Allowed Behaviors
\#%Namespace%#%Behavior%=DWORD:00000001

Replace the Namespace and Behavior variables as appropriate. It is then possible to use the setting approved by the administrator rather than to enable or disable all binary behaviors.

To view additional information regarding this technology in this guide, click the following links:

Introduction to Binary Behaviors

Application Compatibility Testing for Binary Behaviors

Local Machine Lockdown

Applications that host local HTML files in Internet Explorer are likely to be affected by local machine security. Local Machine Lockdown can be configured using Feature Control and UrlAction security as explained earlier in this guide.

To view additional information regarding this technology in this guide, refer the following sections:

“Feature Control” subsection of the “Mitigation Application Compatibility” section.

“UrlActions” subsection of the “Mitigation Application Compatibility” section.

For Internet Explorer, the Local Machine Lockdown feature is enabled by default. You can use Active Directory Group Policy to allow active content from CDs to run without being prompted.

Figure 3.11 shows the location of the setting in Group Policy.

Figure 3.11Using Group Policy to allow active content from CD

Developers may previously have expected to be able to use the Local Machine zone to run active content, such as scripts and ActiveX controls. With Windows XP SP2, this approach may now fail. Use the following mitigation techniques to allow the application to continue to function.

Because the Local Machine zone is now more restrictive than other zones, applications can use the "mark of the Web" comment in HTML files. This feature of Internet Explorer allows HTML files to be forced into a security zone other than the Local Machine zone, so that scripts or ActiveX components can run based on a different security policy. This setting works on Internet Explorer 4 and later.

To identify HTML as downloaded from a specific domain (and therefore have the security settings of the zone containing the domain applied to it), add the following comment with the relevant domain name:

<!--saved from url=(0022)http://www.microsoft.com-->

The number in parentheses relates to the length of the URL.

To ensure that the page is always treated as part of a specific zone, add the following comment with the relevant zone name:

<!--saved from url=(0013)about:internet-->

To view additional information regarding this technology in this guide, click the following links:

Introduction to Local Machine Lockdown

Application Compatibility Testing for Local Machine Lockdown

MIME Handling

To work with the new MIME handling security, Web servers must define consistent content-type headers and file name extensions. An alternative to this is to add the Content-disposition=attachment: HTTP header. This element sends the file directly to its extension handler rather than to the MIME handler. If an application uses Internet Explorer to execute files that the MIME handler rejects, you can change this behavior programmatically so that the MIME handler is capable of handling the file.

If this approach is not possible, you can make Internet Explorer ignore the MIME handler in the event of a MIME/Extension mismatch, by adding the ProgID of the MIME handler to the following area of the registry

HKEY_CLASSES_ROOT\PROG_ID_OF_MIMEHANDLER_TO_IGNORE
\PreferExecuteOnMisMatch=DWORD:00000001

If the ProgID of the MIME handler and the extension handler are mismatched, a developer can remove the ProgID registration of the MIME handlers. In this event, if the MIME handler and the extension handler come from the same CLSID, even if the MIME handler rejects the file, Internet Explorer allows the file to execute in the extension handler.

To prevent additional file download prompts due to the MIME handler being associated with a file in the AssocIsDangerous list, register the relevant MIME handler as secure at:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows
\CurrentVersion\InternetSettings\Secure_MIME_Handlers

This key should contain a value where the value name is the ProgID of the MIME handler and value data of 00000001 and type DWORD.

If MIME sniffing causes use of inappropriate file type handlers, turn the feature off for the relevant zone, if possible, as described earlier in this guide.

MIME sniffing is controlled using the Open files based on content not file extension setting.

To view additional information regarding this technology in this guide, click the following links:

Introduction to MIME Handling

Application Compatibility Testing for MIME Handling

Object Caching Protection

The more restrictive object caching model can cause application compatibility issues In this case, you can use Feature Control to disable the Windows XP SP2 configuration of this feature or use UrlAction security to configure object caching protection on a zone-by-zone basis, as described in earlier sections in this guide.

Alternatively, the developer can rewrite the application code to re-cache the object before the object is accessed.

To view additional information regarding this technology in this guide, click the following links:

Introduction to Object Caching

Application Compatibility Testing for Object Caching

Window Restrictions

If the restriction on script-initiated windows causes application compatibility issues, you can use Feature Control to disable the Windows XP SP2 configuration of this feature, or use UrlAction security to configure Windows Restrictions on a zone-by-zone basis, as described in earlier sections in this guide.

To view additional information regarding this technology in this guide, click the following links:

Introduction to Window Restrictions

Application Compatibility Testing for Window Restrictions

Zone Elevation Blocks

If zone elevation blocks cause application compatibility issues in trusted Web pages, you can use Feature Control to disable the Windows XP SP2 configuration for the feature, or use UrlAction security to disable the feature on a zone-by-zone basis, (or site by site), as described in earlier sections in this guide.

To view additional information regarding this technology in this guide, click the following links:

Introduction to Zone Elevation Blocks

Application Compatibility Testing for Zone Elevation Blocks

Information Bar

The Information Bar displays information relating to a number of events. The following sections cover these different types of information.

Add-on Install Prompt

Many Web pages or applications rely on users installing code to function correctly. If the Information Bar causes users to miss installation options, developers should ensure that the page to which the users are redirected provides the installation ActiveX control. Table 3.5 summarizes the information that the add-on install prompt provides.

Table 3.5 Information Provided by the Add-on Install Prompt

Information Bar Element	Message Text
Information Bar Text	To help protect your security, Internet Explorer stopped this site from installing software on your computer. Click here for more options...
Short Text	Software Install Blocked
Menu Options	Install Software... What is the risk?

Pop-up Blocked Notification

This feature identifies any blocked pop-up windows in the Information Bar. Table 3.6 summarizes the notification options for pop-up blocking.

Table 3.6 Pop-up Blocking Options for the Information Bar

Information Bar Element	Message Text
Information Bar Text	Pop-up blocked. To see this pop-up or additional options, click here...
Short Text	Pop-up Blocked
Menu Options	Show Last Pop-up Allow Pop-ups for this Site Allow Pop-ups Show Information Bar for Blocked Pop-ups(Checked) Pop-up Window Options...

Automatic Download Prompts

Notifications of automatic downloads that commence without user interaction now appear in the Information Bar rather than in a pop-up dialog box. Web pages should include a link, ideally specifying the URL for the content, for users to initiate the file download process. If a script is used to navigate to the resource, this script should run synchronously within the context of the OnClick event handler. Table 3.7 summarizes the notification options for automatic downloads.

Table 3.7 Automatic Download Options for the Information Bar

Information Bar Element	Message Text
Information Bar Text	To help protect your security, Internet Explorer blocked this site from downloading files to your computer. Click here for more options...
Friendly Notification Text	File Download Blocked
Menu Options	Download Software What’s the Risk?

Active Content Blocked

Windows XP SP2 may block some active content that is required for applications to function. If this occurs, an explanation appears in the Information Bar. Table 3.8 summarizes the notification options for blocking active content.

Table 3.8 Active Content Blocked Options for the Information Bar

Information Bar Element	Message Text
Information Bar Text	To help protect your security, Internet Explorer has restricted this file from showing active content that could access your computer. Click here for options...
Short Text	Active Content Blocked
Menu Options	Allow Blocked Content What’s the Risk?

ActiveX Components Blocked Due to Security Settings

With Windows XP SP2, any information that relates to blocked ActiveX components now shows in the Information Bar. Table 3.9 summarizes the notification options for blocking ActiveX components.

Table 3.9 ActiveX Component Blocking Options for the Information Bar

Information Bar Element	Message Text
Information Bar Text	Your security settings do not allow ActiveX controls to run on this page. This page may not display correctly. Click here for more options...
Short Text	Software Blocked
Menu Options	Allow this site to run ActiveX controls What’s the risk?

Web pages should provide file download prompts for the user to click. Any pages to which a user is redirected should also display information on installing required add-ons. If an upgrade to an add-on is published, the upgrade should have the same Globally Unique Identifier (GUID) as the original file to prevent the reinstall generating a prompt in the Information Bar.

If any compatibility issues arise, you can configure the Information Bar using Feature Control as described earlier in this guide.

To view additional information regarding this technology in this guide, click the following links:

Introduction to the Information Bar

Application Compatibility Testing for the Information Bar

Pop-up Management

Pop-up Blocker can be configured in the UI by clicking the Pop-up Blocker option of the Tools menu in Internet Explorer. Figure 3.12 shows the Pop-up Blocker menu in Internet Explorer.

Figure 3.12 Pop-up Blocker menu in Internet Explorer

Clicking Pop-up Blocker Settings... displays the Pop-up Blocker Settings dialog box, as shown in Figure 3.13. This dialog box enables a user to allow pop-ups for specified Web sites.

Figure 3.13 Pop-up Blocker settings UI

Note: Pop-ups can be allowed on a temporary basis by holding down the ALT key when clicking a link to the Web page.

Pop-up Blocker can be enabled or disabled on a zone-by-zone basis using methods described earlier in this guide in the section on UrlAction security.

To view additional information regarding this technology in this guide, refer to the following section:

“UrlActions” subsection of the “Mitigation Application Compatibility” section.

You can use Active Directory Group Policy to configure a list of sites that are allowed to use pop-ups even when blocking is enabled using the settings in:

Administrative Templates\Windows Components
\Internet Explorer\ Pop-up Allow List

To view additional information regarding this technology in this guide, click the following links:

Introduction to Pop-up Management

Application Compatibility Testing for Pop-up Management

Add-on Management

You can identify any installed Internet Explorer add-ons using the Manage Add-ons... menu in Internet Explorer. Figure 3.14 shows this menu and the Manage Add-ons dialog box.

Figure 3.14 Manage Add-ons interface

From the Manage Add-ons interface, it is possible to enable or disable add-ons or update ActiveX controls. An administrator can configure the following three modes for Add-on Management:

• Normal mode (default). The user has full control of add-ons that are enabled or disabled.

• AllowList mode. The administrator specifies allowed add-ons. All others are disallowed and the user cannot change allowed add-ons.

• DenyList mode. The administrator specifies disallowed add-ons, but all other add-ons can be controlled by the user.

Configuration of these modes can take place through the registry using the following registry key:

Management Mode
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
\CurrentVersion\Policies\Ext\ManagementMode:DWORD

0 – Normal

1 – AllowList

2 – DenyList

AllowList

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
\CurrentVersion\Policies\Ext\AllowList

AllowList contains sub keys containing the CLSID of the allowed add-ons.

DenyList

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
\CurrentVersion\Policies\Ext\DenyList

DenyList contains sub keys containing the CLSID of denied add-ons.

Alternatively, you can configure add-ons through Active Directory Group Policy using the following path:

Administrative Templates\Windows Components
\Internet Explorer\Security Features

To view additional information regarding this technology in this guide, click the following links:

Introduction to Add-on Management

Application Compatibility Testing for Add-on Management

Windows Firewall

Windows XP SP2 enables Windows Firewall by default. To allow incoming communication, you must open a specific port or place a program in the exception list. If a service or application attempts to listen on a particular port, a dialog box informs the user of this action. If the user has administrative rights, the dialog box also provides the option of opening the port.

Global Configuration

You can configure Windows Firewall for all connections from the Properties of any network connection. The Advanced tab provides access to the Settings button. Figure 3.15 shows the Windows Firewall dialog box.

Figure 3.15 Windows Firewall configuration interface

The Windows Firewall dialog box provides several configuration options. On the General tab, the firewall can be turned off (not recommended) or put into the Don’t allow exceptions mode where the exception list is ignored.

The Exceptions tab allows access for a program or to a port on the following basis:

• Program. The necessary ports open dynamically when required by the application and close when the application terminates.

• Port. The TCP or UDP port remains open while the Windows Firewall or ICF service is running.

When a program or port is placed in the exceptions list, the scope of access can be defined by clicking the Change Scope button and selecting one of the following:

• Any computer (including those on the Internet)

• My network (Subnet) only

• Custom list (a list of IP addresses and subnet mask)

Interface Specific Configuration

To configure settings for individual network interfaces, click the Advanced tab, select the required interface, and click the Settings button. Figure 3.16 shows the interface-specific configurations for Windows Firewall.

Figure 3.16 Windows Firewall interface specific configuration

To configure Windows Firewall from the command line or scripts, use the Netsh Firewall command.

You can configure Windows Firewall settings in Active Directory Group Policy using the settings in the following path:

Administrative Templates\Network
\Network Connections\Windows Firewall

Group Policy allows the configuration of the following two profiles, for computers that are members of a domain:

• Domain Policy. This policy takes effect when the computer is logged onto the domain.

• Standard Policy. This policy takes effect when the computer is not logged onto the domain.

The Standard Policy is useful for mobile workers.

If Windows Firewall causes compatibility issues, you may need to open static ports in the firewall or place the application into the exception list. Some useful settings to maintain functionality are:

• Prohibit use of Internet Connection Firewall on your DNS domain network. Prevents Windows Firewall from being enabled or configured when connected to the domain from which the policy was received. For example, if a client computer receives a policy from the corp.contoso.com domain, the Windows Firewall will not attempt to filter traffic when connected to the corp.contoso.corp DNS domain.

• Windows Firewall: Allow authenticated IPSec bypass. Allows unsolicited incoming traffic from any computer that is authenticated using Internet Protocol security (IPSec). This setting requires IPSec configuration on all relevant computers.

• Windows Firewall: Allow remote administration exception. Allows remote administration of a computer using administrative tools, such as Microsoft Management Console (MMC) and Windows Management Instrumentation (WMI). To do this, Windows Firewall opens TCP ports 135 and 445. Services typically use these ports to communicate using RPCs and DCOM. This policy setting also allows SVCHOST.exe and LSASS.exe to receive unsolicited incoming messages and allows hosted services to open additional dynamically-assigned ports, typically in the range of 1024 to 1034.

• Windows Firewall: Allow file and printer exception. Allows file and printer sharing. To do this, Windows Firewall opens UDP ports 137 and 138, and TCP ports 139 and 445. If you enable this policy setting, Windows Firewall opens these ports so that the computer can receive print jobs and requests for access to shared files. You must specify the IP addresses or subnets from which these incoming messages are allowed. In the Windows Firewall component of Control Panel, the File and Printer Sharing check box is selected and administrators cannot clear it.

• Windows Firewall: Allow ICMP exceptions. Defines the set of Internet Control Message Protocol (ICMP) message types that Windows Firewall allows. Utilities can use ICMP messages to determine the status of other computers. For example, PING uses the echo request message. If you do not enable the "Allow inbound echo request" message type, Windows Firewall blocks echo request messages sent by PING running on other computers, but does not block outbound echo request messages sent by PING running on the computer on which this setting is enabled. Blocking PING requests from other computers may raise management application issues because the remote user cannot confirm that the target computer is on the network.

• Windows Firewall: Allow Remote Desktop exception. Allows this computer to receive Remote Desktop requests. To do this, Windows Firewall opens TCP port 3389. You must specify the IP addresses or subnets from which Remote Desktop requests are allowed. In the Windows Firewall component of Control Panel, the Remote Desktop check box is selected and administrators cannot clear it.

• Windows Firewall: Define program exceptions and Windows Firewall: Define port exceptions. Allow the pre-configuration of an exception list for deployment to network clients.

• Windows Firewall: Allow logging. Allows Windows Firewall to record information about the unsolicited incoming messages that it receives.

Figure 3.17 shows an example of the Windows Firewall log.

Figure 3.17 Windows Firewall logfile

Programmatically Opening Ports

Independent software vendors (ISVs) can place their programs into the exception list during installation by using the INetFWAuthorizedApplication API. ISVs should note that:

• An application must be running in the context of a user with Administrator rights to add itself to the Windows Firewall exceptions list.

• Ports are automatically opened and closed for allowed Winsock applications, regardless of the user context in which the applications are running.

• Applications should get the user’s consent before adding themselves to the AuthorizedApplications collection.

• Svchost.exe cannot be added to the AuthorizedApplications collection.

For more information about INetFwAuthorizedApplication, see the Microsoft Web site at

https://msdn.microsoft.com/library/default.asp?url=/library/en-us/ics/ics/inetfwauthorizedapplication.asp.

To view additional information regarding this technology in this guide, click the following links:

Introduction to Windows Firewall

Application Compatibility Testing for Windows Firewall

Data Execution Prevention

Windows XP SP2 provides for configuration of DEP through the boot entries in the boot.ini file, System in control panel, and the Application Compatibility Toolkit (ACT).

Global Configuration

By default, DEP is configured to protect only core Windows applications and services. This configuration policy level is called OptIn. DEP can be configured to use one of the four different policy levels described in Table 3.10.

Table 3.10 The Four Policy Levels of DEP

Configuration	Description
OptIn (default configuration)	DEP is enabled by default for limited system binaries and applications that “opt-in.” With this option, only Windows system binaries are covered by DEP by default.
OptOut	DEP is enabled by default for all processes. Users can manually create a list of specific applications that do not have DEP applied using System in Control Panel. IT professionals and ISVs can use the ACT to opt-out one or more applications from DEP protection. System Compatibility Fixes (“shims”) for DEP do take effect.
AlwaysOn	This provides full DEP coverage for the entire system. All processes always run with DEP applied. The exceptions list for exempting specific applications from DEP protection is not available. System Compatibility Fixes (“shims”) for DEP do not take effect. Applications that are opted-out using the ACT run with DEP applied.
AlwaysOff	This does not provide any DEP coverage for any part of the system, regardless of the hardware DEP support. The processor does not run in PAE mode unless the /PAE option is present in the boot entry.

Hardware-enforced and software-enforced DEP are configured in the same manner. If the system-wide DEP policy is set to OptIn, the same Windows core applications and services are protected by both hardware and software-enforced DEP. If the system is not capable of hardware-enforced DEP, the Windows core applications and services are only protected by software-enforced DEP.

Similarly, if the system-wide DEP policy is set to OptOut, applications that have been exempted from DEP protection are exempted from both hardware and software-
enforced DEP.

The four system-wide DEP configurations are controlled through boot.ini switches. The Boot.ini settings are as follows:

/noexecute=policy_level

where policy_level is defined as AlwaysOn, AlwaysOff, OptIn, or OptOut.

Any existing /noexecute setting in the Boot.ini file is not changed when Windows XP SP2 is installed or if a Windows operating system image is moved across computers with and without hardware-enforced DEP support.

During installation of Windows XP SP2, the OptIn policy level is enabled by default unless a different policy level is specified in an unattended installation. If the /noexecute=policy_levelsetting is not present in the boot entry for a version of Windows that supports DEP, the behavior is the same as if the /noexecute=OptInoption was included.

End users who are logged on as administrators can manually configure DEP between the OptIn and OptOut policies using the Data Execution Prevention tab inside the System Properties dialog box. The following procedure describes how to manually configure DEP on the computer:

1. Click Start, click Control Panel, and then double-click System.

2. Click the Advanced tab. Then under Performance, click Settings.

3. Click the Data Execution Prevention tab.

4. Click Turn off hardware DEP (software DEP enabled) to select the OptIn policy.

5. Click Hardware and software DEP enabled for all programs except to select the OptOut policy.

6. Click Add and add the applications with which you do not want to use DEP.

IT professionals can control system-wide DEP configuration with a variety of methods. The Boot.ini file can be modified directly with scripting mechanisms or with the Bootcfg.exe tool, which is included as part of Windows XP SP2.

For unattended installations of Windows XP SP2, you can use the Unattend.txt file to pre-populate a specific DEP configuration. You can use the OSLoadOptionsVar entry in the [Data] section of the Unattend.txt file to specify a system-wide DEP configuration.

Per-Application Configuration

For the purposes of application compatibility when DEP is set to the OptOut policy level, it is possible to selectively disable DEP for individual 32-bit applications.

End-User Configuration

For end users, the Data Execution Prevention tab in System Properties can be used to selectively disable DEP for an application.

Figure 3.18 Configuring the DEP exception list in system

To add an application to the exceptions list when the DEP policy is set to OptOut, click the Add button and select the program with which you do not want to use DEP.

When an application encounters a problem with DEP, the user receives a prompt. If the user is a member of the Local Administrators group, it is possible for the user to exempt the application from DEP protection.

The application that generated the prompt is placed in the DEP exceptions list, but the application is not marked as enabled. Figure 3.19 shows a DEP alert dialog box.

Figure 3.19 Data Execution Prevention Alert

IT Professional Configuration

Windows XP SP2 provides several methods to configure DEP in the enterprise.

Disabling DEP for an Application

For Windows XP SP2 deployments in which end-user configuration is not possible or not practical, Windows XP SP2 provides a new compatibility fix that can be used to disable DEP for a given application. The DisableNX compatibility fix can be applied to an application using the Compatibility Administrator program, which is a part of the ACT.

Once the DisableNX compatibility fix has been applied to a program using Compatibility Administrator, the resulting Custom Compatibility Database can be deployed to Windows XP SP2 systems using a variety of methods including logon scripts, SMS or Group Policy.

For more information about using the Windows Application Compatibility Toolkit, see the Microsoft Web site at

https://www.microsoft.com/windows/appcompatibility/toolkit.mspx

Enabling DEP for an Application

It may be desirable to enable DEP protection for several applications beyond core Windows components without setting the system-wide DEP configuration to the OptOut policy level.

In this scenario, the Compatibility Administrator tool can be used to apply the AddProcessParametersFlags compatibility fix to an application to enable DEP protection. The AddProcessParametersFlags compatibility fix must be added with a command line parameter value of “20000”.

To specify a command line value for a compatibility fix, the Compatibility Administrator tool must be started with the /x switch.

To apply the AddProcessParametersFlags compatibility fix to an application,

1. Click Fix from the toolbar to create a new compatibility fix.

2. Provide the required information, including the path to the application’s executable, and click Next.

3. Apply any necessary additional compatibility modes or layers for the application. (Note that no compatibility modes or layers are required to enable DEP for an application. DEP is enabled for the application by adding the AddProcessParameters flags compatibility fix below.) Click Next.

4. Check the AddProcessParametersFlags compatibility fix and click the Parameters button.

5. In the Command Line text box, enter “20000” and click OK.

6. Click Next to specify the matching information.

7. After specifying the matching information, click Finish to create the application fix.

Once the application fix has been created, the resulting Custom Compatibility Database can be deployed to Windows XP SP2 systems using a variety of methods including logon scripts, SMS, or Group Policy.

To view additional information regarding this technology in this guide, click the following links:

Introduction to DEP

Application Compatibility Testing for DEP

Distributed Component Object Model\Remote Procedure Call

The security that Windows XP SP2 applies to DCOM and RPCs prevents many network-based exploits that target these services. Therefore, careful consideration is required before changing security settings that affect network communications.

Distributed Component Object Model

Windows XP SP2 applies DCOM security to the COM server component to prevent anonymous access. The permissions are split into two ACLs:

• Launch and Activate Permissions

• Access Permissions

The system-wide ACLs are located in the Component Services management console, under My Computer Properties. Figure 3.20 shows this dialog box, which allows configuration of computer wide and default application DCOM security.

Figure 3.20 DCOM security configuration interface for setting the system-wide configuration

There are two ACLs for each permission type:

• Edit Limits. Sets computer wide permissions.

• Edit Default. Defines default application permissions. An administrator can then accept the default application permissions for each separate COM application or customize permissions individually. These permissions can be configured in the specific application properties in the COM services management console.

Figure 3.21 shows the DCOM security configuration interface for a specific application.

Figure 3.21 DCOM security interface for the IIS Admin Service

Computer-wide ACLs are stored in the registry at:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
\Ole \MachineAccessRestriction= ACL

and

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
\Ole \MachineLaunchRestriction= ACL

Computer-wide restrictions permission settings can be pushed through Group Policy. You can use Active Directory Group Policy to configure computer-wide settings using the following path:

Windows Settings\Security Settings
\Local Policies\Security Options

Figure 3.22 shows Group Policy settings for DCOM Machine Access permissions configuration.

Figure 3.22 Using Group Policy to set computer wide DCOM configuration

When Group Policy is in effect on a computer, it is honored and the local machine computer-wide restriction permission is ignored.

Configuration of the DCOM ACL creates a new security descriptor in the registry.

If you implement a COM server and expect to support remote activation by a non-administrative COM client or remote unauthenticated calls, you should initially consider whether this is the best configuration. If so, you need to change the default DCOM configuration for computer-wide limits (Edit Limits).

If you implement a COM server and override the default security settings, you should confirm that the application-specific Launch permission ACL grants Activation permission to appropriate users. If it does not, you need to change your application-specific Launch permission ACL to give activation rights to the appropriate users, so that applications and Windows components that use DCOM do not fail.

Caution: If these computer-wide restriction permissions are used incorrectly, it can cause applications and Windows components that use DCOM to fail.

The Deny access control entry (ACE) should be used judiciously. You should carefully assess its implications before you apply it. A Deny ACE could result in unintended results and may lock users out of certain functionality to which they need access. Depending on the security group for which you set the Deny ACE, this restriction could affect administrators on the local computer.

DCOM applications can also be exempted from activation security checks by editing the registry at:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
\Ole\AppCompat\ActivationSecurityCheckExemptionList

Add a value with a value name of the application ID taken from the DCOM Config section of the Component Services MMC, and a value data of:

0 The application is not exempt from the activation security check

1 The application is exempt from the activation security check

Configure this list using Group Policy at:

Administrative Templates\System\Distributed COM
\Application Compatibility Settings

Remote Procedure Call

Windows XP SP2 provides developers and administrators the ability to secure RPC communications through the following settings:

RestrictRemoteClients registry key. The path to the key may not already exist but should be created at

HKEY_LOCAL_MACHINE\ SOFTWARE\Policies\ Microsoft\Windows NT\RPC.

The RestrictRemoteClients registry value accepts three values:

0 – Bypasses the new interface restrictions. Behavior is the same as Service
Pack 1.

1 – (Default) Restricts access to all RPC interfaces. All remote anonymous calls are rejected by the RPC runtime. If an interface registers a security callback and provides the RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH flag, this restriction does not apply to that interface. If the key does not exist (default), the system assumes this value for the key.

2 – Imposes the new interface restrictions without exemptions. This is the same as a value of 1, except that the RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH flag does not result in exempting an interface. With this value, a system cannot receive remote anonymous calls using RPC. Applications that use DCOM might not work correctly if this value is set. This new security model allows an administrator to limit the system attack surface for the RPC protocol.

EnableAuthEpResolution registry key. The path to this key may not already exist but should be located at

HKEY_LOCAL_MACHINE\ SOFTWARE\Policies \Microsoft\Windows NT\RPC.

This value must be set on the client to enable authenticated communication with the RPC Endpoint Mapper on the remote computer running Windows XP SP2. This configuration is required with the Windows XP SP2 default setting of RestrictRemoteClients. The allowed values for EnableAuthEpResolution are:

0 – Disabled

1 – Enabled

RPC interface registration flags. Three new interface registration flags have been created, which make it easier for an application developer to secure an RPC interface.

RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH. When this flag is registered, the RPC runtime invokes the registered security callback for all calls, regardless of the call security settings. Without this flag, RPC rejects all unauthenticated calls before they reach the security callback. This flag works only when a security callback is registered.

RPC_IF_SEC_NO_CACHE A security callback is registered for an interface to restrict access to that interface. The typical security callback impersonates the client to determine if the client has sufficient rights to make a call to the interface. If a particular client identity passes a security callback once, it usually passes the same security callback every time. The RPC runtime takes advantage of this pattern by remembering when an individual client identity passes a security callback and skips the security callback for subsequent calls by that client to the same interface. This feature is called security callback caching and has existed since Windows 2000. For Windows XP SP2, use the RPC_IF_SEC_NO_CACHE flag to disable security callback caching for a given interface. This configuration is useful if the security check might change, possibly rejecting a client identity that was previously permitted.

RPC_IF_LOCAL_ONLY. When an interface is registered with this flag, RPC rejects calls made by remote RPC clients. In addition, local calls over all ncadg_* protocol sequences and all ncacn_* protocol sequences (except for named pipes, using ncacn_np) are also rejected. If a call is made on ncacn_np, RPC allows the call only if it comes from Server Service. Ncalrpc calls are always allowed through.

The default security configurations in Windows XP SP2 may cause some compatibility issues. The following three options are available to resolve these issues. These options are listed in order of preference.

• Require your RPC clients to use RPC security when contacting your server application. This is the best method to mitigate security threats.

• Exempt your interface from requiring authentication by setting the RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH flag during interface registration. This configures RPC to allow anonymous connections only to the interface of your application.

• Force RPC to exhibit the same behavior as earlier versions of Windows by setting the RestrictRemoteClients registry key to “0”. RPC then accepts anonymous connections to all interfaces. This option should be avoided if possible because it reduces the overall security of the computer.

To view additional information regarding this technology in this guide, click the following links:

Introduction to DCOM/RPC

Application Compatibility Testing for DCOM/RPC

Attachment Execution Service

The Attachment Execution Service (AES) is a new functionality in Windows XP SP2 and introduces a few application compatibility issues. AES gives a new and consistent look for file and attachment download dialog boxes across applications. These new features include:

• A file handler icon

• A new information area added to the bottom of the dialog box that provides slightly different information, depending on whether the downloaded file type is of higher or lower risk

All downloaded executable files are checked for publisher information. Once the file is downloaded, the Authenticode dialog box displays publisher information. It is possible to configure download and execution of files where the signature is invalid in Internet Options on the Advanced tab or using Active Directory Group Policy at:

Administrative Templates\Windows Components\
Internet Explorer\Internet Control Panel\Advanced Page

The UI has a list of dangerous file types for e-mail file attachment downloads that are more stringent than before, and may result in additional warning prompts. The file type list cannot be edited, but the feature can be turned off for Outlook Express by clicking Options on the Tools menu. You can prevent the use of the dangerous file types list on the Security tab by clearing the Do not allow attachments to be saved or opened that could potentially be a virus check box.

Figure 3.23 shows the configuration of the dangerous file types list in Outlook Express.

Figure 3.23 Configuration options for dangerous file types list in Outlook Express

AES may prevent an e-mail attachment that a user has downloaded to the local file system from executing. The file is marked so that its source is known, even if it is executed at a later date. If the file is considered dangerous, it is blocked. This feature requires NTFS file system (NTFS) on the user's computer. This behavior can be changed for the file on the General tab of the file properties. Figure 3.24 shows how to unblock a downloaded executable attachment.

Figure 3.24 Unblocking a downloaded executable attachment in Windows Explorer

To view additional information regarding this technology in this guide, click the following links:

Introduction to Attachment Execution Service

Application Compatibility Testing for Attachment Execution Service

Removing Mitigation Fixes

So far this chapter has considered applying mitigation fixes to overcome application compatibility issues. The goal of this process is to enable an application to function by reducing security in one or more areas.

If, after careful consideration, you decide to soften the default security and apply mitigation fixes, you should also implement a process and timeframe for removing the fixes and reconfiguring, redeveloping, upgrading, or retiring the problematic applications.

Figure 3.25 shows the options for deploying Windows XP SP2 to cope with application incompatibilities.

Figure 3.25 Windows XP SP2 deployment paths after application compatibility issues

The process is as follows:

1. After compatibility testing, document any incompatibilities.

2. Identify what is necessary to make the application compatible with the configuration of the computer.

3. Make necessary changes for application compatibility.

4. Deploy Windows XP SP2.

If Step 2 identifies mitigation as necessary:

1. Change the configuration of the computer to overcome compatibility issues.

2. Deploy Windows XP SP2.

3. Implement a process to remove the mitigation fixes. This should include:

   1. Identifying redevelopment work required.

   2. Creating a mitigation removal procedure.

   3. Creating a reconfiguration procedure.

   4. Setting a time frame for whole process to complete.

4. Make necessary changes for application compatibility.

5. Remove the mitigation fixes that were applied.

6. Re-secure the operating system.

Summary

This chapter has demonstrated the process of reconfiguring the operating system security to allow applications to run successfully after applying Windows XP SP2. This procedure is not recommended but may be necessary in the short term.

The recommended approach is to maintain security configurations and make changes to the application so that it works with Windows XP SP2. If upgrading or modifying the application is not possible, cautious changes to the security configuration should be made, but only to the extent necessary to ensure correct operation of the application. A defined removal process should also be created to return the operating system to the highest possible security once the application has been upgraded or modified.

The next chapter discusses considers deployment methods for Windows XP SP2.