Planning for the Security Features of Windows 7

With Windows 7, Microsoft has added and extended many security capabilities in its flagship Windows operating system (OS). Deciding which features to activate as well as testing will impact the planning for every Windows 7 rollout.

• Collectively, the security improvements to Windows 7 provide the most compelling reasons to upgrade.
• Many of the security features are only available with the enterprise stock-keeping units (SKUs) of Windows 7, which are only available to subscribers of enterprise agreement/software assurance (EA/SA; maintenance on the OS) or in the Ultimate version.
• New capabilities like BitLocker To Go and AppLocker provide basic capabilities, but dedicated security solutions offer greater functionality.
• From XP and Vista, Microsoft has made further changes in its Windows filter driver, which will require the recertification of all your organization's security tools (antivirus [AV], virtual private network [VPN], firewall, etc.).
• The move to 64-bit Windows will have a significant impact on security tools and testing.
• In a few cases, capabilities are provided for older versions of Windows, but many are unique to Windows Vista and Windows 7. Some are available only with Windows 7.
• No Microsoft security solutions for Mac or Linux are available, and only in a few cases are interoperable third-party solutions available. Likewise, the security capabilities of Windows 7 aren't available for Windows Mobile.
• Most security features of Windows 7 lack a dedicated management console and rely almost exclusively on Group Policy Objects (GPOs).
• The two most important things any Windows installation can do to improve security are to get off of Internet Explorer 6 (IE6) and run users as standard user and, although a migration to Windows 7 might make these easier, it doesn't require Windows 7 to take these steps.

• Run as a standard user wherever possible. Use the migration to Windows 7 as a catalyst to do this.
• Use the migration to Windows 7 as the catalyst to get rid of IE6. Ideally, don't wait on Windows 7 – do this now.
• Because most security features require EA/SA, the cost of EA/SA must be factored into any cost-benefit analysis of migration.
• Features such as Data Execution Prevention (DEP), Address Stack Layout Randomization (ASLR) and Safe Unlinking are built into every SKU of Windows 7, are not readily available from most commercial products, and significantly raise the bar for security.Ensure these are activated as part of your organization's base images and tested.
• Plan on significantly expanding the use of GPO-based management to support Windows 7 deployments.
• Even if you don't use Microsoft's built-in security capabilities, ensure that your standard security and management vendors have a timetable to support Windows 7 that aligns with your planned migration.
• Use Microsoft's "good enough" and "free" security capabilities with Windows 7 to secure better pricing or bundled "no cost" security capabilities from your incumbent desktop security vendor.
• Require security, management tool vendors, device drivers and application vendors to support 64-bit Windows. Most organizations will start moving some desktops to 64-bit with Windows 7, so now is the time to start pressuring vendors to support it.
• Require your security tool vendors to manage Microsoft's security capabilities from within their console and management frameworks. For example, several Endpoint Protection Platform (EPP) vendors manage the Windows firewall. The same should extend to the other security capabilities of Windows 7.

With Windows 7, Microsoft has added a large number of new security capabilities to Windows and extended ones that were first made available in Windows Vista. For organizations migrating from Windows XP, the vast majority of these features are new, and their impact must be planned for. In some cases, Microsoft's offerings may overlap with what organizations already have deployed – such as the Windows Firewall – so Microsoft's offering may not be used. In other areas, Microsoft's capabilities – such as DirectAccess – are unique to the OS, and the capabilities must be considered, tested and planned for accordingly.

Here, we analyze the major security capabilities of Windows 7 in order of importance. Since many security capabilities are only available in the Enterprise SKUs of Windows 7, which, in turn, are only available to subscribers of EA/SA, we have included information on which features require EA/SA and which do not.

The Ultimate version of Windows 7 is intended to be a superset of all Windows 7 capabilities, including all the security capabilities discussed in this research. Purchasing Windows Ultimate may be an alternative to EA/SA; however, organizations should understand that Windows 7 Ultimate is a consumer SKU, which means that there is no volume activation (each copy needs to be activated separately, with a unique activation code), doesn’t provide reimaging rights, and it only has five years of support from Microsoft (for security fixes), compared with 10 years for commercial editions like Windows 7 Pro and Windows 7 Enterprise. Also, the Microsoft Desktop Optimization Pack (which includes technologies such as App-V and MED-V) is only made available to EA/SA subscribers.

What it is: AppLocker is Microsoft's initial offering for a manageable application control solution (also referred to as "whitelisting" see "Application Control Market Update"). AppLocker is integrated directly into the kernel of Windows 7 and offers an improved alternative to its GPO-based software restriction policies (SRPs), adding more-scalable management policies.

Which versions: AppLocker's application control capabilities are only available with the Enterprise SKUs of Windows 7, which are limited to EA/SA subscribers. However, software restriction policies (which provide less-manageable application control capabilities for Windows XP and Vista) are available in all enterprise and business versions of Windows 7, Windows XP, and the Ultimate SKUs of each. AppLocker does not replace SRPs, and both may be used on a single machine.

• GPO-based SRPs have been available since Windows XP and are still available with Windows 7, but are difficult to manage, because applications can only be controlled using the individual checksum (hash), path name or digital signature of the publisher. Path names are too weak for secure deployments, and individual hashes are too difficult to manage because desktop applications are typically frequently installed and updated.
• The AppLocker technology moves the application control whitelist management to higher levels of abstraction – specifically based on the digital signature of the application and other application metadata – for example, the publisher of an application (from the digital signature) and also the name of the application, the name of the product suite and the version number.
• Policies based on digital signatures and application metadata allow for easier management of whitelists and, combined with other metadata, can provide more-granular policy formation. For example, "Enable all users to run MS Office if digitally signed by MS and version >12." Since AppLocker is tied in with Active Directory, the policies can be applied to specific users, groups or organizational units.
• To help organizations make the transition to application control, AppLocker supports an audit-only mode. Here, an organization can observe what would be blocked if AppLocker's policies were enforced. This provides critical visibility into what applications are running and which would have been blocked during deployment planning. These block/allow events are then put in individual audit logs, which may then be collected through PowerShell commandlets and used to create rules across the environment. Organizations can then grow and tweak the rule sets over time, and then start enforcing as exceptions are minimized.
• AppLocker can set policy on any application-level executable file, dynamic-link library (DLL), Microsoft Installer (MSI) or Microsoft Patch installer, and enables policies to be set on many types of scripts, including Windows Scripting Host, PowerShell, batch file and command files.
• To improve manageability, AppLocker supports "exception rules," so that handling exceptions can be done with minimal rules. For example the two rules:



• "Allow Office to run for all users EXCEPT Microsoft Access" (so that no one can run Microsoft Access).
• Then another rule that says, "Allow Finance to run Microsoft access if digitally signed by Microsoft and version is greater than 12…"
• The combination of the rules has the net effect of enabling everyone to run Office, but only Finance can run Microsoft Access.
• AppLocker supports whitelisting and blacklisting of applications.

• AppLocker is only available to EA/SA subscribers, and there is no equivalent back-level client for Vista or XP, nor are there any partners for non-Windows platform support, including Windows Mobile. Third-party products offer more ways to manage whitelists beyond just digital signatures and application metadata.
• Not every application has a digital signature, and in some cases, the organization's IT department may have to add one. Also, digital signatures only tell the organization that the code hasn't been tampered with since packaging; it doesn't say anything about the legitimacy of the code. Even with some slightly stronger requirements for code-signing certificates, the "bad guys" are able to obtain them. Further, as with any whitelisting solution, just because an application is digitally signed, doesn't mean it was well written, and it may contain embedded vulnerabilities or may be malicious.
• AppLocker is invoked at a user level and cannot affect policy on Windows Services or anything that runs in the local system or system service context.
• Although AppLocker can be used to set policy on DLLs that represent ActiveX controls or browser helper objects in Internet Explorer, the ability to set policies on DLLs is not exposed by default. We expect improved AppLocker policy setting for executable code within IE will be addressed in release 1 of Windows 7.
• Windows System Center (or other desktop management tools) don't link into AppLocker to help build the initial whitelist. Even when run in audit mode, there is no automated way organizations can build the initial set of application policies across hundreds or thousands of machines (other than writing scripts and manually consolidating exception logs).
• Like most application control offerings, AppLocker requires two rules to completely block an application – one covering the installation of the application and another covering the execution of the application. Users that install an application, but can't execute it, will likely generate help desk calls, so blocking the installation is preferred. However, the industry hasn't standardized on whether the version information reflected in the MSI package represents the version of the installer or the version of the application contained within. This ambiguity adds complexity in the planning and testing of AppLocker. Note, in many cases, that organizations will restrict the installation of new applications to System Center, Altiris or similar software distribution packages.

• Don't overlook the political and cultural challenges of exerting more control over desktop computing, especially in environments where users run as administrators and install whatever they want.
• When evaluating application control solutions, consider incumbent EPP and PC configuration vendors, in addition to point solutions as potential alternatives to AppLocker. Reducing agents and consoles (as well as cost and complexity) should be weighted in the evaluation.
• When antivirus agents and patching aren't possible, consider AppLocker and system hardening as alternative security controls for Windows 7-based fixed-function terminals, kiosks and other roles.

What it is: User account control (UAC) is not one thing, it is collection of technologies serving two primary functions – most importantly, to provide increased application compatibility for when users run as standard users, and, secondarily, to provide more protection for machines when users run as administrators.

Which versions: All versions of Windows 7 include UAC.

• UAC was first introduced with Windows Vista, and its primary benefit is to help organizations make the transition to running as a standard user by providing file and registry redirection, making a larger percentage of applications compatible when running as a standard user.
• When used to provide more protection when users run as administrators, UAC attempts to run most applications and commands with standard user privileges, using full administrative access only when necessary. However, with Windows Vista, UAC was criticized for displaying numerous prompts for seemingly mundane things (for example, simply viewing the firewall settings or changing the monitor resolution in Vista would initiate a prompt). Windows 7 has been refactored to minimize prompts – for example, the Windows 7 firewall enables a standard user to view, but not modify, the firewall settings.
• Based on feedback from Vista users, Microsoft has also made the prompting levels tunable by the end user or via GPO if centrally managed by IT. In addition to refactoring, if the user is running as a local administrator, Windows 7 will silently elevate many common activities that require the user to take action. This introduces some security risk, so some common applications are not (and cannot be) silently elevated – for example, CMD.EXE and RUN32DLL.EXE. Although UAC is not a security boundary, Microsoft claims that this feature cannot be used to silently elevate random code.
• If no prompts are desired, Windows 7 supports an "XP mode" with full suppression of all prompts.
• Starting with Windows Vista and unchanged with Windows 7, Microsoft has rearchitected and split its printer driver model so standard users can install printers, and administrators can control the allowed drivers.

• When running as a standard user, there are likely some legacy applications that will still require administrative privileges. Microsoft does not provide the capability to elevate a standard user to administrator for the purposes of legacy application compatibility. To achieve this requires the use of a third-party product, such as Avecto, BeyondTrust (recently acquired by Symark) or Viewfinity.
• Because of Windows' single user legacy and application ecosystem compatibility issues, the default out of the box with Windows 7 is still to run users as administrators. We look forward to the day when this changes to standard user privileges (such as Mac OS X and most Linux desktop distributions).
• Unless prompts are fully suppressed, if users are running as administrator, then there are activities that will generate prompts – even with the additional refactoring with Windows 7. This increases the risk that users running as administrators become immune to prompts, reducing their effectiveness over time.
• UAC is not a security boundary. UAC is meant to minimize exposure. However, if users are running as administrators, then nothing can be guaranteed. Proof-of-concept demonstrations have shown this protection can be bypassed.

• Regardless of what version of Windows you use, run users with standard user privileges wherever possible – period. This is the single biggest improvement in security that any Windows system can have. This will require that all Windows applications be tested with standard user rights, likely increasing testing time and migration planning.
• Use the migration to Windows 7 as a catalyst to run more users as standard users. If third-party applications still require elevation (even after the UAC redirection capabilities of Windows 7), consider the use of third-party products to provide exception-based elevation for these applications. Most Windows vulnerabilities are mitigated if users are configured as standard users. Also, many of the security policy enforcement capabilities of Windows 7 (such as the firewall, Defender, Universal Serial Bus [USB] port control and UAC) are at risk of being bypassed if users run as administrators.
• Require all Windows application vendors to support the running of their applications and, ideally, the installation as well, when users are configured with standard user privileges. If users need to install software, they may require administrative privileges, which will increase costs.

What it is: BitLocker is Microsoft's implementation of full disk encryption (FDE) for protecting system files and data. By encrypting the contents of the Windows volume, the contents are protected from unauthorized access without the decryption or recovery key. BitLocker was first introduced with Windows Vista and has been improved with Windows 7.

Which versions: BitLocker's FDE capabilities are only available with the Enterprise SKUs of Windows 7, which are limited to EA/SA subscribers. BitLocker's policies are managed via GPOs.

• BitLocker's inability to address multiple volumes on a single physical disk and multiple physical disks was addressed in Vista Service Pack 1 (SP1) and Windows 7.
• No reformat is necessary if Windows Vista BitLocker drives are upgraded to Windows 7.
• Windows 7 adds multiple, incremental improvements:



• More GPOs were added for manageability.
• Smart card-based authentication for access to data volumes has been added.
• Microsoft has expanded options for PIN policies used with the Trusted Platform Module (TPM)-based protection of the machine. For example, PINs now support length policies, as well as support for letters and numbers (with Vista, this was restricted to F1 through F10 keys for international compatibility).
• Organizations and users can define and enforce separate policies for the OS drive versus data drives.
• BitLocker still requires a boot partition to be configured. However, with Vista, this was 1.5GB in size and has now been reduced to 100MB in size. Further, this partition is now hidden and consumes no drive letter.
• When Windows 7 installs onto a bare disk, Windows will automatically create the dual partitions required.
• If an organization uses TPM-based boot protection (recommended), the TPM configuration routines can now be performed automatically without requiring a separate TPMconfig step.
• Finally, to support easier recovery scenarios, Microsoft has provided its Data Recovery Agent. Using the optional recovery agent, a single key (stored in a protected portion of Active Directory and recoverable by IT) may be used to recover any enterprise volume on any machine. This feature is typically demanded by large-scale enterprise deployments.

• BitLocker is only available to EA/SA subscribers, and there is no back-level client for XP, nor are there any partners for non-Windows platform support, including Windows Mobile. Third-party FDE solutions support consolidated key management across diverse platforms.
• BitLocker can't support smart card-based authentication scenarios for the boot volume that third-party solutions can.
• Despite incremental improvements, most third-party products available on the market offer more-comprehensive, multiplatform (including Windows XP and Windows Mobile), full-disk-encryption solutions with heterogeneous key management.

• Regardless of whether BitLocker is used, all mobile devices should be encrypted. If this has not been done already, it should be done immediately – ideally before a migration to Windows 7.
• Our recommendations from earlier research remain the same. Consider BitLocker when:



• You are an existing Microsoft EA/SA subscriber or are planning to become an SA subscriber in the Windows 7 time frame for reasons other than BitLocker, and:



• You haven't implemented any solution for full disk encryption.
• You are willing to wait for Windows 7 deployments to implement full disk encryption.
• Your hardware is compatible with BitLocker's specific requirements.
• You can live within BitLocker's limitations.

What it is: Developed by the same group as BitLocker, and sharing much of the same code, BitLocker To Go is Microsoft's solution for encrypting removable storage, addressing one of the more-significant limitations of the version of Windows Vista's BitLocker.

Which versions: BitLocker To Go's removable device encryption capabilities for creating encrypted media are only available with the Enterprise SKUs of Windows 7, which are limited to EA/SA subscribers. BitLocker To Go's policies are managed via GPOs.

• BitLocker To Go addresses a huge hole in the original BitLocker offering to address the protection of information as it is written off to removable media.
• The ability to read and write (but not create) BitLocker To Go encrypted media is available with all Windows 7 versions. Down-level reader clients are provided for Windows Vista, XP SP2 and XP SP3. This means that most versions of Windows can read BitLocker To Go formatted media.
• BitLocker To Go works with anything that mounts as a Windows drive and is formatted using either the file allocation table (FAT) or NT File System (NTFS). However, NTFS-formatted devices can't be equipped with the BitLocker To Go reader client.
• Encryption is transparent to the end user, requiring no explicit action by the end user to encrypt information.
• Keys are stored with the media and protected by a passphrase (optionally with a smart-card-based digital certificate), so there is no dependence on Active Directory to read or write encrypted media. Policies on the length and complexity of the passphrase are controlled via GPOs (as a benefit, if a machine is domain joined, this can be the same policy that enterprises use for end-user password strength and complexity).
• Like BitLocker, integration with Active Directory can be used to generate a 48-character recovery key in the event the user forgets his or her passphrase.
• Like BitLocker, BitLocker To Go offers the option of an enterprisewide recovery key (so that a different recovery key does not need to be managed for every USB device encrypted in the organization).

• BitLocker To Go is only available to EA/SA subscribers or with the Ultimate SKU. There are no partners for non-Windows platform support, including Windows Mobile.
• The ability to create BitLocker To Go drives is only available on the Enterprise and Ultimate Windows 7 SKUs. Other Windows 7 SKUs can read and write a BitLocker To Go formatted drive, but cannot create one. Windows XP and Vista machines are limited to read-only access.
• No down-level client is provided for Windows 2000 workstations or for non-Windows workstations, including Windows Mobile.
• BitLocker's policies for encrypting OS drives, fixed data drives and removable drives are treated as three separate policies that need to be defined and managed by the organization.
• BitLocker To Go will only encrypt FAT-formatted media that mount as Windows drive letters. This means that CD/DVD rewritable drives (which mount as drive letters, but don't use FAT or NTFS) cannot be encrypted by BitLocker To Go, a serious limitation.
• NTFS-formatted media can be encrypted, but can't carry a BitLocker To Go reader for back-level support on older machines (see Figure 1)
• BitLocker To Go decryption keys are stored on the media itself and unlocked by a passphrase, so the strength of protection is dependent on the strength of the passphrase.

• Like BitLocker, BitLocker To Go is good, but not great. Multiple third-party products offer policy-based encryption solutions that use a consistent framework to address fixed and removable media.
• Multiple third-party device encryption solutions are available that provide policy-based encryption capabilities across a broader array of devices and connections.
• Our recommendations are consistent with BitLocker. Consider BitLocker To Go when you are an existing Microsoft EA/SA subscriber or are planning to become an SA subscriber in the Windows 7 time frame for reasons other than BitLocker To Go, and:



• You haven't implemented any solution for removable device encryption.
• You are willing to wait for Windows 7 deployments to implement removable device encryption.
• You can live within BitLocker To Go's limitations, most notably the lack of down-level Windows client support and the absence of CD/DVD encryption support.

What it is: Continued evolution of Microsoft's Internet Explorer browser with a significant emphasis on Internet standards support. Internet Explorer 8 (IE8) builds on the security foundation laid down with IE7.

Which versions: All versions of Windows 7 include IE8. IE8 is also available for Vista, XP SP2 and XP SP3 workstations.

• IE8 provides continued improvements in browser security. Most notably:



• The ability to tie the use of specific ActiveX controls to specific sites. This feature is critical to reducing exposure to vulnerable ActiveX controls.
• The ability to tie the use of specific ActiveX controls to specific users (not machinewide).
• ActiveX Opt-In requires ActiveX controls not installed through the browser be opted into use within the browser before they can be used.
• The extension of DEP and ASLR protection into the browser.
• Like IE7 on Windows Vista, IE8 has used the mandatory integrity control capabilities of the underlying Windows Vista or Windows 7 OS to provide "protected mode" browsing, placing the browser in a minimally trusted state, providing additional security in the event of a browser breach. Thus, items running in IE can read but not write to objects at a higher level of integrity in the OS (most of the Windows OS runs at a medium level of trust; the browser runs at low). This is transparent to end users and prevents IE from changing or damaging the Windows OS.
• Evolution of phishing filter to SmartScreen filter, providing integrated anti-phishing protection and protection from socially engineered malware linked into Microsoft's security response center.
• Browser-based protection against Type I (reflection) cross-site scripting (XSS) attacks (for example, steal cookies, log keystrokes, deface sites and so on), all of which evade phishing filters and circumvent HTTPS.



• IE8 provides users with the option to browse using an "InPrivate Browsing" session. These sessions are not logged and not cached, and no permanent cookies are created. Organizations can disable this feature via GPOs if required.
• In a related, but separate, capability referred to as "InPrivate Filtering," IE8 can be set to throttle/limit cookies that are dropped during any browsing session (whether InPrivate Browsing or not). This feature is useful for individuals or organizations that are concerned about the use of monitoring and tracking cookies within their browser environments.
• The number of GPOs for the centralized management of IE8 has increased.
• IE8 has been rearchitected to separate and isolate each tab in the browser to separate, multithreaded processes. Other browsers, such as Chrome and Firefox, also support this. The benefit for users and enterprises is higher availability of the browser platform, such that a crash in one tab doesn't compromise (and potentially crash) the entire browser.
• If IE8 shuts down or fails catastrophically, IE8 can (via policy) be configured to restore all pages back to where you left off.

• The most significant change in IE8 is not security-related – the new rendering engine is more standards-compliant. This introduces significant Web-based application compatibility issues for applications written to specific idiosyncrasies of IE6. Although Microsoft includes IE5 and IE7 back-level rendering support, an IE6 rendering mode is not supported.
• IE8 doesn't include most parental control capabilities. This comes from a different group within Microsoft and is not integrated. IE8 can use Content Advisor (which uses a rating assigned by the site creator) to block access to sites.
• IE8 doesn't include URL filtering capabilities. Likewise, this comes from a different group within Microsoft (Forefront) and is not integrated. IE8 needs a standardized interface to manage policies for URL filtering (third parties or Microsoft).
• IE8 is not available for Windows 2000 workstations.
• The ability to restrict ActiveX control to specific pages is an important step – however, this capability introduces management overhead and IE8's default is not to activate this capability.
• The activation of DEP, ASLR and the SmartScreen Filter protection introduce the potential for false positives with poorly coded Web pages and ActiveX controls.

• Get off IE6 in 2010 – whether to IE7, IE8, Firefox, Chrome or another modern, secure browser running on XP, Vista or Windows 7.
• Run IE7 or IE8 on Windows Vista or Windows 7 to achieve the benefit of Protected Mode browsing.
• The effort and impact to migrate to IE8 from IE6 must not be underestimated. This migration is as significant an issue as legacy Windows application compatibility. Many Web-enabled enterprise applications will have issues rendering correctly, which means that all Web-enabled enterprise applications must be tested. Likewise, the security changes to IE8 will require that all plug-ins be tested as well.
• Ensure that DEP, ASLR and XSS protection are activated for the browser in your standard image and during all website and ActiveX control testing.
• Restrict ActiveX controls to specific sites, where possible. This will also lengthen the amount of time and planning for an IE8 migration.
• Security-sensitive organizations should consider the capabilities of InPrivate Blocking and InPrivate Browsing as a way to minimize data collected about users' browsing habits to entities outside of the organization.

What it is: DirectAccess (DA) is a VPN solution that enables remote users to transparently access internal network resources, such as enterprise shares, websites and other applications. Similar conceptually to Microsoft's Server and Domain Isolation (SDI —which has been available in various forms since Windows Server 2000, enabling authenticated server-to-server connections internal to an organization's internal network), DA extends this vision to create trusted connections to users on remote networks (for example, a public or home network or another organization's network). DA uses Windows 7's built-in capabilities of IPsec and Internet Protocol version 6 (IPv6) to establish secure sessions (optionally using Encapsulating Security Payload, Authentication Headers and encrypted payloads) to protect access to enterprise resources when accessed from unmanaged networks.

Which versions: DA capabilities are only available with the Enterprise SKUs of Windows 7, which are limited to EA/SA subscribers. This capability is also included in the Ultimate version. Policies for DA are managed via GPOs. Also, DA requires a DA server on the edge of the corporate network running Windows Server 2008 release 2 (R2 or later) that is joined to an Active Directory domain.

• DA doesn't require an additional VPN client.
• DA enables organizations to extend the boundaries of their trusted networks to machines on remote networks. This addresses the significant issue of getting patches, AV signature updates, software updates and so on to remote and mobile users that are Internet-connected, but rarely if ever connect back to the enterprise network.
• For organizations using SDI, DA and SDI can be used together in complementary scenarios – for example, DA used to enable a remote workstation to seamlessly connect to the enterprise network and then SDI could be used to further isolate and segregate the areas of the network that the user can access using IPsec policies.
• Whereas SDI couldn't traverse network address translation (NAT) or survive IPsec traffic being blocked, using a variety of tunneling options, DA is designed to do so.
• At a minimum, DA users must have valid domain user credentials. Optionally, for stronger authentication, DA supports two-factor authentication for remote users accessing the enterprise network.
• DA policies can be configured so that DA is disabled completely when connected to the enterprise network.
• DA hides most of the complexity of IPv6 address and IPsec certificate management. Organizations may use an external certificate provider if they already have one in place. If not, DA uses the built-in certificate-handling capabilities of Windows Server.

• For full functionality, DA requires some amount of IPv6. At a minimum, the IPv6 stack on the Windows 7 workstations must be enabled.
• Workstations that participate in DA must be domain-joined (where the certificates are stored), precluding the use of DA for contractor machines, home machines, Windows 7 consumer SKUs (except for Ultimate) and so on.
• Ideally, DA requires IPv6-capable infrastructure as well, although IPv4 infrastructure may be used as the transport (tunneling IPv6 over IPv4 using ISA-TAP [for use on internal networks] and 6to4, Teredo or IP-HTTPS [from external networks]). In these cases, DA requires at least one Windows Server 2008 R2 server (or a similar translation device) to function as the IPv4 to IPv6 gateway. Tunneling IPv6 traffic through external IPv4 networks introduces security challenges. The main risk is that hackers may attempt to send malicious IPv6 traffic through the tunnel. Implementing countermeasures adds complexity to the network.
• In cases where IPv6 to v4 tunneling protocols are blocked, Microsoft provides a fallback protocol, IP-HTTPS, which is new with Windows 7 and requires Windows Server 2008 R2. This protocol is Microsoft-specific and is not an Internet Engineering Task Force (IETF) standard, although it has been published under Microsoft's Open Specification Promise.
• Full end-to-end payload encryption using IPsec will blind network inspection devices to the traffic. We recommend and expect most DA deployments will use client-to-edge encryption and not full end to end encryption.
• DA is only available to EA/SA subscribers or the Ultimate version and there is no back-level client for Vista or XP, nor are there any partners for non-Windows platform support (client or server) or Windows Mobile.
• On DA connections, there is a risk in exposing the address of the DA server on public networks. Once the connection is established, policies can dictate whether or not all traffic after that point is encrypted. A misconfigured policy or misconfigured name resolution policy table could inadvertently expose internal addresses.
• Some organizations have a policy against "split mode tunneling" – where a machine is simultaneously connected to the unmanaged public Internet and the internal network (and thus, if compromised, becomes a potential "bridge" for attacks). DA can be configured to not allow this. Further, care must be taken in managing Domain Name System (DNS) tables to keep intranet-traffic routed correctly.
• No formal certification program for support of DA, Intra-Site Automatic Tunnel Addressing Protocol (ISATAP), 6to4, Teredo or IP-HTTPS has been established, so organizations must work out compatibility and translation issues in testing.
• The Teredo, 6to4 and IP-HTTPS protocols are not yet mainstream and, like any emerging protocol, likely contain vulnerabilities yet to be discovered. Mitigating this risk is the fact that most of these conversations will be encrypted, making attacks more difficult.
• No third-party gateway offerings support Microsoft's DA gateway function and IP-HTTPS, limiting an organization's choice to Microsoft DA Server gateway with Windows Server 2008 (or the next release of Microsoft's Unified Access Gateway, which supports DA and these protocols and offers more functionality).

• We recommend that this feature is not activated during initial migration. Although much of the complexity of IPv6 addressing and certificate management can be hidden, most enterprises don't have a strategy for how they will adopt IPv6 where adoption of DA would complicate the testing and migration to Windows 7. Few commercial gateway solutions are available as an alternative to Microsoft's Windows Server 2008 R2 DA server, so it should be tested carefully, even for a limited deployment.
• Focus initial DA deployments to accelerate Windows patch, AV signature and, potentially, software distribution updates to mobile users.
• If the organization is using SDI and DA, then extra testing will be required.
• When refreshing NAT and other network devices, ensure that they will support IPv6, Teredo, 6to4, ISATAP and IP-HTTPS, and certify for Windows 7 DA support.
• If business justification arises for the broader use of DA, then develop and budget for compensating security controls for the loss of visibility of encrypted payloads to the point where the payload is unencrypted – for example, network- or host-based intrusion prevention systems at termination points.

What it is: First introduced in Windows Vista, Windows Services Hardening (WSH) enables the application of access control lists (ACLs) on Windows Services. Essentially, developers are able to whitelist behaviors of Windows services to specific actions of Windows-level OS objects. This is a powerful security technique that protects against the exploitation of vulnerabilities that may be embedded in Windows OS services.

Versions: All Windows 7 SKUs include WSH. WSH is not managed via GPOs and is, instead, managed via per-machine registry and configuration settings. The capability is on by default for Windows services.

• WSH is rooted in the whitelisting of Windows services – a powerful and foundational security technique that protects against exploitation of vulnerabilities in Windows services. Most (but not all) Windows services come preconfigured with ACLs from Microsoft, so immediate protection is enabled out of the box.

• Windows services have security identifiers, so enabling this capability was straightforward. However, this option is not available for nonservices (for example, Windows applications, drivers or individual processes). To enforce known good behaviors of Windows applications would require the use of a third-party product, such as McAfee Host Intrusion Prevention, Symantec Critical System Protection and other similar offerings (see "Best Practices for Implementing Host-Based Intrusion Prevention Systems").
• Not all Microsoft Windows services have WSH profiles. Third-party services are not required to have these. Thus, protection of third-party Windows services may or may not be possible, and may require the manual configuration of policies to support this.
• This style of host-based intrusion prevention system (HIPS) doesn't fix the underlying vulnerabilities in services or prevent them from being attacked (for example, buffer overflows), which leaves open the possibility of a denial-of-service attack, but it raises the bar for exploiters to cause more serious damage.
• There is no centralized management console for WSH policies. Not managed via GPOs, WSH is managed using Web-based console interface and individual machine registry settings.

• Confirm that WSH is activated for all Windows services for which Microsoft provides a profile in your base Windows 7 images. WSH provides powerful security protection at minimal cost and effort. Activate it and test as a part of all of your standard Windows 7 images.
• Pressure Microsoft to extend this powerful hardening capability to all Windows applications, not just Windows services in the next release of Windows.
• Require third-party developers of Windows services to provide WSH profiles. Visual Studio should be enabled to automatically generate WSH manifests for automatic creation of the policies that govern WSH.

What it is: Windows Firewall is Microsoft's integrated bidirectional personal firewall for Windows 7. Like many of the security technologies in Windows 7, the bidirectional firewall was introduced first with Windows Vista, along with the Windows filter driver platform. From a functionality perspective, the Windows firewall remains the same with Windows 7. However, architecturally, there have been a number of changes in the Windows filter platform the firewall is built on. The platform has been redesigned to be more modular.

Which versions: All versions of Windows 7 include the personal firewall. The firewall is managed via GPOs.

• Third parities can more easily insert their firewalls to do network packet filtering. In Vista, what was an "all or nothing" proposition, Windows 7 enables security independent software vendors and users to more easily turn off the pieces they don't need.
• Windows Vista's firewall only enables one network profile to be active at a time (even if you had multiple networks you attached to). In Windows 7, every connection can have network profiles associated and active.

• You probably have a more-capable firewall from your incumbent EPP provider already. The Microsoft firewall has no deep packet inspection capabilities and no HIPS capabilities.
• The low-level architectural changes in the packet filter driver will break some security applications. Any network-level security solution must be explicitly certified for Windows 7.
• Microsoft needs to make the Windows firewall fully manageable by third parties via exposed application programming interfaces (APIs), not GPOs.

• Regardless of whether you use the Windows firewall or not, because of the packet filter driver changes in Windows 7, all low-level backup, security and system management tools that use the Windows packet filter should be explicitly certified for Windows 7. These types of tools should be a primary focus of compatibility testing and image development.

What they are: ASLR essentially randomizes the system call tables for each Windows Vista system on boot-up, introducing an element of genetic diversity between otherwise identical systems. In this way, an attack crafted to target a specific memory offset may work on one machine but fail on another otherwise identical machine. This forces the malicious software writer to use a brute force attack or not to use memory offsets, both of which raise the bar for hackers.

DEP uses the underlying hardware support of Intel and Advanced Micro Devices (AMD) processors to protect against memory injection attacks. DEP uses hardware to enforce a rule "Do not execute code from areas of memory marked for data usage." This prevents a large percentage of memory injection attacks (for example, buffer overflow exploits).

For similar protection to DEP at the OS level, Microsoft has added Safe Unlinking with Windows 7. Safe Unlinking is new kernel-level code that augments the allocation and deallocation of portions of memory by the Windows 7 kernel. Safe Unlinking performs a series of checks before memory is deallocated to ensure that attackers aren't trying to exploit the OS using what's known as a pool overrun (similar conceptually to a buffer overflow, but at the kernel level).

Versions: All versions of Windows 7 include ASLR, DEP and Safe Unlinking.

• ASLR is available today for users of Windows Vista, and DEP is available to users of Windows XP SP2 and higher. All these features should be activated and provide a significant amount of security protection at little or no cost, with minimal chance of application incompatibility.
• In addition to ASLR, Microsoft has added numerous heap defenses, with a complete redesign of the heap layout also introducing genetic diversity among other versions of Windows and providing dynamic security protection. For example, metadata in memory has been encoded using a random value so that metadata can't be overwritten in memory without detection. This, combined with encoded internal pointers, makes it difficult to get a valid address by brute force.
• Microsoft has also continued improvements in /GS, with integrity checking by placing a detection cookie in the heap. The size of the heap is also randomized when applications request a heap. None of these is a panacea – hackers may find workarounds – but collectively make attacks more difficult. If an attack on the heap is disclosed, the Windows 7 heap has also been designed to be modular, so it may be easily replaced later with updated security defenses as part of a service pack.
• Most hardware shipped since 2006 supports no execute/execute disable (NX/XD), so hardware support for DEP shouldn't be a significant issue.

• The activation of these features will require more testing with DEP activated, especially if DEP is activated at the application level. For developers, the activation of these features may complicate the debugging process for kernel-level developers.
• Systems older than 2006 (likely will not be upgraded) and some servers (for Hosted Virtual Desktop or terminal services use by Windows 7 code) may not have hardware-based support for NX/XD.

• Ensure all of these capabilities are activated on your base Windows 7 image before undergoing testing. Ensure your hardware supports NX/XD. Turn this on for XP SP2 and higher as well. Ensure IE8 uses DEP. Require any vendor of Windows applications to support complier options, /GS and so on, that support ASLR, DEP and Safe Unlinking capabilities of the OS.

What it is: Policy-based control of USB-connected devices, including block, read and write access.

Version: USB device control is included in all versions of Windows 7. It is manageable with GPOs.

• Microsoft's USB port control solution provides detailed, granular policy enforcement for USB-connected devices. Microsoft provides the ability to set policies for blocking, read, or write access:



• By manufacturer ID – for example, enable only the connection of HP printers or a specific brand of USB flash drives
• By device class ID – for example, block flash drives, but allow printers
• By individual device ID – for example, only allow a specific USB device to be used with a machine

• For organizations truly concerned with data loss prevention, there are many points of ingress and egress from a machine, in addition to USB-based devices, so USB device control alone is insufficient to achieve their broader data loss prevention goals.
• Most notably, CD/DVD drives, but also wireless, Bluetooth, general packet radio service, third-generation modems, infrared, parallel ports, serial ports, Firewire and so on need to be controlled. Competitive offerings on the market provide general device control policy enforcement that handles most of these scenarios.
• USB manufacturer, class and device IDs are vulnerable to forgery. A truly determined hacker will create USB devices that masquerade as printers (or other types of devices) to bypass these types of controls.
• Microsoft provides no content-aware policy decision-making capabilities. For example, allow the user to use the USB drive for most activities, and only block write access to the USB drive if there is an attempt to copy sensitive data.
• Users with administrative access to their machines may find a way to bypass these controls.
• BitLocker To Go will encrypt content on a USB drive and is complementary; however, these policies aren't linked with the USB device control policies.

• Look first to your EPP provider or mobile data encryption vendor to provide this capability at no extra cost. Favor vendors that take a comprehensive approach to DLP – USB is just one of many possible entrance points. If your incumbent EPP provider doesn't have these capabilities, evaluate the cost-benefit/risk of a more-capable third-party alternative versus Microsoft's built-in capability. For simply blocking access to USB flash drives of all types, Microsoft's solution is a solid solution.

What it is: Kernel Patch Protection (KPP) is kernel-level code that protects the Windows kernel dispatch table from being intercepted (also known as "hooked"). This prevents malware, such as keystroke loggers, from intercepting Windows kernel events, but can also interfere with legitimate security software that hooks the kernel to monitor Windows-level activities.

Because device drivers that load in kernel mode have complete system access, Microsoft is restricting the ability of users to load arbitrary device drivers. Device drivers must now be digitally signed.

Versions: All 64-bit versions of Windows 7 contain KPP and require signed device drivers (as well as Windows Vista 64 bit, Windows Server 2003 64-bit R2 and higher). The 32-bit versions of Windows 7 do not have these capabilities.

• Both of these capabilities are directionally the right thing to do for Microsoft and to strengthen Windows security. Stronger kernel protection is needed, and KPP and signed device drivers help to reduce exposure from malware, poorly written code or incompatible drivers.
• "Hooking the kernel" is the source of the nastiest Windows malware, most notably cloaked rootkits. Macintosh OS X and Linux already provide similar protection capabilities for the kernel.
• Microsoft has worked with security and management vendors to develop a standard set of APIs to gather kernel-level information in lieu of hooking the kernel. Kernel hooking is not enabled, but the ability to get more information out of the kernel is.

• KPP breaks many security applications that work by modifying the kernel dispatch table, most notably behavioral host-based intrusion prevention products. Most organizations will have some software and/or drivers that don't work correctly on 64-bit Windows that will lengthen migration planning and testing.
• Even with the standardized APIs, some security vendors claim they still cannot get the full functionality they need and their products remain only partially functional on 64-bit Windows.
• Although device drivers must be digitally signed to be installed, enterprises are not able to restrict to specific drivers from specific vendors. As discussed earlier, AppLocker is not able to control the installation and loading of device drivers either.
• As with AppLocker, just because a driver is digitally signed doesn't mean it was well written, doesn't contain embedded vulnerabilities or doesn't contain malicious code. Microsoft could strengthen its device certification program with mandatory code review or working with certificate providers to create higher levels of validation assurance when issuing code-signing certificates (much like Extended Validation Certifications for Secure Sockets Layer).

• A potential move to 64-bit Windows will require an evaluation of all the organization's standard drivers, desktop security and desktop management solutions to confirm that support for 64-bit Windows is provided (see "Plan to Implement Some 64-Bit Versions of Windows 7").
• Even if a security vendor says it supports 64-bit Windows, realize that some products will not deliver full functionality using 64-bit. Require security, management tool, device driver and application vendors to support 64-bit Windows. Most organizations will start moving some desktops to 64–bit, so the time to start pressuring vendors to support it is now.

What it is: Network Access Protection (NAP) is Microsoft's integrated client for network access control (NAC). The technology was first introduced with Windows Vista (and later XP SP3) and remains essentially unchanged with Windows 7.

Which versions: All business and enterprise versions of Windows 7 (except Home and Starter Edition) include the NAP client.

• The integration of a NAP client into Windows 7 provides basic NAC functionality (organizations that want more-advanced functions should consider deploying third-party NAC agents).
• EPP vendors still charge, on average, $10 per client for NAC/NAP functionality. Microsoft includes this capability at no additional cost.
• Back-level NAP capability was introduced with Windows XP SP3 (but has seen little adoption).
• Microsoft NAP agents support the Trusted Computing Group Trusted Network Connect statement of health protocol, so any server that supports this protocol can be used.

• Microsoft's own compliant statement of health server requires Windows Server 2008 R2.
• Microsoft provides no clients for Windows 2000. Further, support for Mac or Linux clients will require a third-party provider, such as, Avenda Systems.
• Partly due to the low uptake of Windows Vista, MNAP has achieved no traction in enterprise deployments.
• Early interoperability cooperation with Cisco has not progressed much beyond simple interoperability demonstrations. Cisco and Microsoft are working on the next iteration of their NAC alliance, but no public commitments and timelines have been released.
• Reporting from Microsoft's Network Policy Server is weak compared with more-mature solutions from NAC vendors.

• Use Microsoft's no-cost NAP client to pressure your incumbent EPP provider to provide lower-cost NAC capabilities as a part of your standard contract.
• Consider NAC/NAP projects outside the scope of the Windows 7 migration.
• Pressure Cisco and Microsoft to further their integration efforts.
• Focus 2010 efforts on guest networking projects, not full-scale NAC/NAP deployments.

What it is: Windows Defender is free anti-spyware (AS) capabilities originally included with Windows Vista and relatively unchanged with Windows 7.

Versions: Included with all versions of Windows 7.

• Basic AS capabilities backed by updates from Microsoft's security research labs. Microsoft's inclusion of Defender has helped to drive down pricing for anti-spyware to the point where most vendors provide this at no additional cost as a part of their EPP.
• For consumers and smaller organizations that want antivirus and anti-spyware, Microsoft released Windows Security Essentials at no cost in September 2009.

• Most organizations already have a no-cost AS capability provided by their incumbent AV providers.
• Defender has no antivirus capability for large enterprise users.
• Defender is designed for stand-alone use and has no centralized management capabilities, including GPOs. For managed AV and AS capabilities, organizations must purchase Forefront Client Security (or a competitive EPP offering from another vendor), which is charged separately.
• For very small enterprises and individual users, Microsoft Security Essentials is based on the same core technology as Forefront Client Security and is made available at no cost to consumers (and the current license restriction does not prohibit commercial use).
• There are no clear lines between what a virus is and what spyware is. Regulatory restrictions on Microsoft's ability to include AV means Microsoft must create a distinction between Defender and AV that other vendors don't have to. Thus, Defender alone doesn't typically score well in head-to-head tests against a combined AV/AS solution.
• Uses Windows Server Update Services (WSUS) for signature updates directly from Microsoft – there is no option to send these signatures via a managed enterprise server. This is an issue for organizations that don't want to use WSUS.

• Defender was really designed for consumers. Move to EPP offerings from your incumbent AV provider, which should provide no-cost anti-spyware protection. No organization should be paying extra for anti-spyware in 2009 and beyond.
• If you have no solution for AS, and your AV vendor won't provide it for free, consider Defender as a low-cost alternative for the short term. In the longer term, migrate to an EPP platform from vendors (including Microsoft).

What it is: Domain Name Systems Security Extensions (DNSSEC) was originally defined in 1999 and adds cryptography-based digital signatures to DNS results, eliminating the possibility of an attacker inserting fraudulent results. However, DNSSEC will not protect all DNS-related problems (such as phishing attacks or authorized insider abuse), and it requires the entire DNS infrastructure to be updated and to be able to handle the creation and validation of digital signatures. Specifically, the embedded DNS client in Windows 7 can secure the last-hop communication between the client and the DNS server, and it can also check to see if the server validated a signed zone.

Versions: Support for DNSSEC is new to Windows 7 and is available in all versions, including the Home and Starter Editions. For enterprises, policies governing DNSSEC usage are controlled via GPOs.

• Microsoft's built-in support reduces the need to deploy a separate IP stack or add-on product to obtain DNSSEC support.
• Microsoft's DNSSEC client addresses two primary capabilities:



• The Windows 7 DNSSEC client can verify that the DNS server validated a signed zone.
• It secures the last hop of communications between the client and the DNS server.
• By focusing on these two capabilities, Microsoft has avoided the infrastructure complexity of building trust anchors on the client, and enables organizations to phase in support for DNSSEC without massive infrastructure changes.
• Via the Name Resolution Policy table in the Windows 7 OS, Microsoft provides the flexibility to not ask for DNSSEC validation.

• The bulk of the complexity of managing DNSSEC shifts to the DNS servers, including the operational overhead of managing trust anchors.
• Most DNS servers serving consumers and enterprises aren't yet ready for DNSSEC. Likewise, most enterprises haven't planned out their DNSSEC infrastructures.
• Microsoft's own DNS server won't support DNSSEC until after Windows 2008 R2, and is not expected until at least the next major release of Windows Server.

• DNSSEC support should not be considered as a primary driver for Windows 7.
• If your servers don't support DNSSEC, don't plan on activating Windows 7's support for DNNSEC in the initial rollout. Focus first on adding DNSSEC support to your enterprise DNS servers. If your servers support DNSSEC, you will benefit from signed zones.

What it is: The Windows Audit subsystem was introduced with Windows Vista and exposed further with Windows 7. This provides detailed granular records of all Windows 7 events in a common audit log.

Versions: The Windows Audit function is available in all Windows 7 SKUs and all Windows Server 2008 SKUs. Windows' Audit policy is part of the Security Policy components of GPO and can be fully managed via GPOs.

• It provides detailed workstation-level auditing not previously available in Windows, and enterprise clients have expressed renewed interest in user activity monitoring.
• Users or organizations can place and monitor ACLs on all Windows OS objects and log all entries – specifically, why (or why not) an entity was granted access. This is extremely useful for troubleshooting access control issues and for forensics use if logs are centrally collected and managed.
• Any object in Windows OS can be "ACLed" for auditing object access (such file system or registry). Individually, each object would have to have its ACL set by hand or using Icacls.exe. For most enterprises, IT will want the ability to monitor the user without setting individual ACLs; thus, global security ACLs would be set via group policy.
• Policies can be set globally across desktops and servers.
• Most security information and event management (SIEM) efforts have focused on servers and server-based applications. Windows 7's audit function provides the alternative to monitor end-user workstations.

• Although audit policies can be managed with GPOs, Microsoft provides no centralized console to monitor audit logs. This capability really needs to be tied into a SIEM system, which Microsoft does not offer.
• There is a chance of log tampering if a user runs with administrative rights and/or the workstation has been compromised, so logs on workstations where users run as administrators must be considered suspect.
• The granularity of policies enforced and monitored will greatly affect the amount of information being logged. Logs can be set for first-in/first-out recording and limited to specific sizes.

• Don't activate this feature without a strategy for gathering and consolidating the logs – typically with a third-party log management or SIEM system.
• All users don't need to be monitored equally. Formulate policies specific to types of users and risk factors, such as the type of work being performed or the type of data being handled.
• The logging of end-user activities may violate privacy regulations. Ensure that the activation of this capability does not violate internal or external regulatory requirements.
• Evaluate the impact of auditing on storage, SIEM scalability and the need for this data. Simply gathering more data doesn't help if an organization doesn't have a strategy for using the data.

What it is: Microsoft has integrated a Rights Management Services (RMS) client into Windows 7. RMS is Microsoft's digital rights management (DRM) technology that has been shipping since 2002, and an RMS client was first introduced and integrated with Windows Vista and remains essentially unchanged with Windows 7.

Which versions: All business and enterprise versions of Windows 7 (except Home or Starter) include the RMS client.

• Like NAP, an integrated RMS client saves organizations the time and effort of distributing a DRM client.
• Microsoft Office consists of the same technology (renamed Information Rights Management, but based on the same core technology), including Microsoft Office SharePoint Server integration. As such, Microsoft RMS works well for internal-facing, Microsoft-centric application usage scenarios.

• Windows 7 doesn't include an RMS client access license. Although the client is there, there is an extra cost for each user to use it, which can become cost-prohibitive in large deployments and must be budgeted and properly licensed.
• Third-party applications are rarely RMS-enabled, so work with Microsoft partners, such as Liquid Machines. Alternatively, have the applications write out XML Paper Specification files (Microsoft's alternative to Adobe's Portable Document Format), which may then be RMS-enabled with Windows Vista or Windows 7.
• RMS is linked to Active Directory for certificate management, complicating interorganizational exchange of protected content by requiring that a copy of Active Directory be made accessible within the organization's "demilitarized zone."

• Consider a full DRM implementation outside the scope of the Windows 7 migration. Windows 7 is not required for RMS. For pockets of Windows-centric users exchanging sensitive documents, RMS may make sense, but should be evaluated against more-competitive and heterogeneous third-party offerings.

Overall, Microsoft continues to raise the bar for information security capabilities in its base OS. However, many of the capabilities are only available to EA/SA subscribers – and thus are not made available to every Windows 7 user. Although the consumer-oriented Ultimate version also provides all of these capabilities, this version is the most expensive and lacks some capabilities discussed earlier. In a sense, security is "rationed" to those that pay for maintenance on the Windows 7 OS or pay more for the Ultimate version. Organizations should weight the cost-benefit of an SA agreement or higher-cost Ultimate version before a Windows 7 migration.

Any migration to Windows 7 should include an evaluation of which security capabilities will be activated and which will not. In many cases, superior capabilities are available from third-party solutions, and a decision will need to be made if these capabilities are needed and if the existing vendor provides them. If not, weigh the pros/cons of Microsoft's built-in capability versus the for-fee third-party capability. Any security features activated must become a part of the base image and application testing and compatibility testing process.

We would like to see a road map and commitment by Microsoft to place capabilities such as BitLocker into the main OS over time (and, likewise, introduce new security add-ons) with EA/SA. We would also like to see every security capability in the Windows OS manageable via APIs so that third-party operations and management consoles could configure these across an enterprise as an alternative to GPOs.

Microsoft also faces internal tension in deciding what capabilities are reserved for its for-fee Forefront Client Security offering, which is run out of a separate business unit than the Windows OS. It is unclear how Microsoft decides what security capabilities will be charged for and included with Forefront Client Security, which will be a part of the Windows enterprise SKUs (and only available to EA/SA subscribers) and a part of the main OS for all users. Adding transparency to this decision-making process would help to address enterprise concerns about potential conflicts of interests when a vendor that sells the platform also generates revenue by selling add-on products to secure the underlying platform.

Even with these challenges, organizations should hold all of their OS vendors accountable to deliver innovations that strengthen the base security of the OS, such as ASLR, DEP, WSH, signed device drivers, KPP and so on. Microsoft has raised the bar for information security with Windows 7. Other vendors should meet or beat it.

Contributing Analysts: Lawrence Orans, Mike Silver and John Pescatore