INTRODUCTION

The Secure Anywhere Access Initiative set forth by Bill Gates in 2007 incorporates and carries forward the earlier Trustworthy Computing Initiative that drove the Microsoft design in years past. To meet the goals in both initiatives, Microsoft IT has undertaken a long-term effort to improve the security of the managed assets and data. Microsoft IT determined that a Defense-in-Depth strategy would be necessary to ensure that resources could be secured adequately from external and internal threats. Defense-in-Depth refers to a security strategy that uses several layers with the goal to provide end to end security rather than deploying a single type or line of defense. Microsoft IT chose IPsec, a standards-based protocol upon which Microsoft IT could create a trusted computing environment, known as Domain Isolation. Domain isolation creates a logical network of authenticated computers, which helps to prevent untrusted computers from accessing trusted resources. This concept also encompasses server isolation so that servers and critical data could be further secured. Like domain isolation, server isolation also uses IPsec, optionally with encryption enabled, to ensure that only trusted computers can communicate with the servers participating in the isolation. Prior to creation of the domain isolation environment, Microsoft operated a largely open network. The assumption was made that domain computers behind the perimeter firewall could be trusted, whereas those that were not joined to the domain could not be trusted. However, all computers could still access domain resources. Windows Firewall provided the next addition to the security environment at Microsoft. Computers running Windows Server 2003 SP1 and Windows XP SP2 used these host-based firewalls to provide a level of protection right at the computer itself. With the release of Windows Vista and Windows Server 2008, Windows Firewall has been further enhanced to include both inbound (which was previously available in Windows XP SP2 and Windows Server 2003 SP1) and outbound protection. Additionally, management of IPsec has been simplified and improved. Both IPsec and Windows Firewall are now managed through one interface, and creation of domain and server isolation environments is now wizard driven. Windows Server 2008 also introduced Network Access Protection (NAP). NAP enables granular control over access to resources using identity, group membership, and policy compliance. For instance, NAP can be used to ensure compliance with corporate network policies, preventing computers from connecting to resources if they don't meet the security criteria.

BUSINESS BENEFITS
Microsoft has gained several key business benefits through its security efforts. A more secure environment means less downtime due to unexpected security events. This benefits Microsoft IT and end users alike, which in turn means more productivity for the business.

Improvement of Overall Computer Security

By undertaking its security efforts and processes, Microsoft IT has helped foster confidentiality, integrity, and availability across the entire Microsoft environment. Confidentiality refers to maintaining appropriate controls and, when necessary, encryption on sensitive data to prevent unauthorized access. Integrity refers to ensuring that data remains unchangedwhether in storage or in transitbecause of or by unauthorized means. Finally, availability includes the steps taken to make sure that systems and data are available and ready for use when needed.

Protection of Intellectual Property

Because of the nature of certain data, some areas of the Microsoft network need a higher level of security than others. These areas protect important business assets to Microsoft such as source code, marketing materials, product specifications, planning information, and Human Resources (HR) and Accounting data. The loss of any of these materials would be significant. The use of IPsec with optional encryption for systems requiring more stringent security along with host-based firewalls and application segregation allows Microsoft IT to protect these systems while still using Group Policy for central management. Additionally the use of NAP allows the IT Administrators to make decisions about the health state of systems before they are allowed to access Corporate assets.

Increased Policy Compliance

Computers that are not part of the domain cannot take part in IPsec communication and are therefore isolated. When Microsoft IT originally deployed IPsec, this factor resulted in a 30 percent increase in the number of computers that joined the domain. Computers on the domain are subject to Group Policy and management with Microsoft Systems Management Server 2003 and other domain-management tools, creating a more secure and controlled environment.

Full Integration with IPv6 and NAP

The need for always-on, always-connected infrastructure together with an increasing number of connected devices means that support for IPv6 is more important than ever. IPv6 enables a much larger network address space so that more devices can be connected. Windows Vista and Windows Server 2008 fully support IPv6. This always-connected network also means that applications such as NAP are also more important than ever. Windows Server 2008 and Windows Vista fully support NAP.

Application-agnostic Network Security

By choosing standard protocols and industry best practices, Microsoft IT is able to provide network security that isn't dependent on the application and doesn't need to be customized for an individual applicationthat is, application

agnostic. The business directly benefits from this approach because Microsoft IT isn't required to manage application security or custom security details for a given application.

EXISTING NETWORK AND SECURITY OVERVIEW

Microsoft ITs role is like that of other organizations, with several areas of responsibility vital to performance of the business. The primary role is to provide IT services, such as user support, management of computers, and management of network operations. Microsoft IT ensures 24x7 availability of computing resources to more than 500 locations around the globe. Microsoft IT is responsible for managing a large, dynamic environment of more than 140,000 users and more than 260,000 client computers. Desktop environments are controlled by end users but Microsoft IT must maintain overall management of the security of those computers. In addition, Microsoft IT must manage the company's server infrastructure. This computing environment is managed to ensure maximum availability while maintaining data integrity and confidentiality of proprietary and sensitive data.

Challenges of the Security Environment

The security environment at Microsoft is extremely challenging. Some of the challenges that Microsoft IT faces include:

Approximately 100,000 intrusion attempts each month. Approximately 1 million infected or malicious e-mail messages received each month. Special environments for product development and testing have specific security requirements.

Microsoft IT shares the same challenges faced by IT departments in any company: maintaining security while enabling users to do their jobs, preventing unauthorized devices from entering the network, protecting against viruses and malware, and supporting day-to-day activity on a busy network. The computing environment at Microsoft also presents unique challenges compared to other large-scale IT environments. Microsoft IT manages the entire network with security in mind, but the highly dynamic environment at Microsoft that encourages innovation and development presents additional challenges, including:

Local administration. Microsoft fosters a development environment which enables administrator-level access for users' own desktop environment. Further, a literate user base tends to test the limits of the computing tools available. Therefore, it is common for these computers to have different configuration settings, which creates a challenge to effectively manage the computers without enforcing unnecessary policy changes.

Multiple computers per user. It is common for Microsoft employees have two or more computers for development. Using multiple computers enables the developers to develop and test with specific configurationsfor example, a specific version of the Windows operating system or a specific patch applied while another computer is reserved for day-to-day tasks such as e-mail access. Developers also frequently reimage their computers for testing purposes, and over 5,000 PCs are rebuilt every day.

Several approved applications and versions. Microsoft developers maintain several legacy versions of software on client computers to facilitate the testing of patches and to provide ongoing support for those applications. In addition, as new software is developed, users frequently run it in parallel with older versions for testing purposes.

Security Evolution
As computers and networks have evolved so too have the threats against them. Merely protecting assets at the perimeter is no longer sufficient to ensure data security within the corporate network. Microsoft IT approaches security as a process, with several key elements:

Strong passwords. Perimeter firewalls. Smart card authentication. Policy enforcement. IPsec. Host-based firewalls. Application segregation. Vulnerability scanning. NAP

In early phases of the security evolution, IPsec was used to create domain isolation and server isolation. Following on the implementation of IPsec and domain and server isolation, Microsoft IT implemented host-based firewalls. The Windows Firewall version released with Windows XP SP2 and Windows Server 2003 SP1 enabled this additional but important layer in the security evolution. By using the Authenticated Bypass feature of Windows Firewall, the firewalled systems could still be scanned for security and compliance by trusted computers. The next method for achieving additional security is application segregation. Using this feature, Microsoft IT uses the concept of least privilege to create an environment in which systems can only communicate with each other if there is a valid business reason to do so. The communication is allowed only on the application ports specifically allowed. Because the application segregation environment is built using the IPsec and Windows Firewall implementations that already exist within the Microsoft environment, no additional software is necessary to add this feature. Application segregation is managed through Group Policy.

Role of IPsec at Microsoft

The Internet Engineering Task Force (IETF) designed a security architecture for the Internet Protocol. IPsec provides authentication, packet integrity, and encryption for IP packets. Part of the IPsec protocol, Internet Key Exchange (IKE) provides key management and security negotiation. IPsec is traditionally thought of as a tunneling protocol, typically used in virtual private network (VPN) remote access scenarios. IPsec operates in two modes: Tunnel mode and Transport mode. In Tunnel mode, the entire IP packet, including header information, is optionally both encrypted and authenticated. In Transport mode, only the packet's payload is optionally encrypted and authenticated.

Trusted Environment Through SecureNet

Microsoft IT uses IPsec in Transport mode to create an authenticated network of computers called SecureNet, in which each computer operating in the SecureNet is assured that it is communicating with a known counterpart. This configuration mitigates damage from rogue devices on the network. The Encapsulating Security Payload (ESP) portion of the IPsec protocol suite, operating in a configuration called ESP-Null, along with IKE creates the framework for SecureNet. Certain servers and areas of the network are maintained with more stringent security requirements. In these areas, Microsoft IT uses IPsec with encryption. IPsec policies and filters are distributed through Group Policy, and the Access This Computer from the Network user right is used on sensitive resources. Computers and devices connected with IPsec operate alongside untrusted computers and devices on the same physical network and address space while maintaining logical separation. Untrusted devices are not allowed to access resources unless granted explicit permission to do so. Further, untrusted devices cannot access trusted devices in the SecureNet but rather must access boundary resources. A boundary resource is a specific host set up by Microsoft IT with limited access permissions for untrusted devices.

Improvements with Windows Vista and Windows Server 2008

Windows Vista and Windows Server 2008 made several key improvements surrounding both the implementation and the management of IPsec in the corporate environment. Microsoft IT uses these improvements to decrease deployment and administration while still maintaining security. Among the improvements are:

Simplified IPsec policy.A simple policy for IPsec is now available that reduces the number of exceptions necessary. It also eliminates the delay involved in negotiating IPsec between hosts by sending both clear-text and IKE at the same time. If the responding host is IPsec-capable, IPsec will be used. If not, the communication will remain in clear text. Simplified IPsec configuration. IPsec is now configured within Windows Firewall with the Advanced Security Microsoft Management Console (MMC) snap-in. This application provides a central location for management both of Windows Firewall rules and of IPsec filters and rules (now known as Connection Security). Figure 1 shows the Windows Firewall with Advanced Security application.

Figure 1.

The

Windows

Firewall

with

Advanced

Security

MMC

snap-in

in Windows Server 2008 Improved support for load balancing and clustering. Previous versions of the Windows operating system required up to two minutes to reestablish a connection when a load-balanced or clustered node failed. With Windows Vista and Windows Server 2008, this delay is significantly reduced. When TCP retransmissions are detected, IPsec begins renegotiating with another node. This means that a failover typically will not affect application stability. New wizard for server and domain isolation. Creating server and domain isolation configurations is now done

through the Windows Firewall with Advanced Security MMC snap-in and is wizard driven. Rules are created based on responses provided in the wizard, including the mode to be used from among these choices:

Request authentication for inbound and outbound connections. Require authentication for inbound connections and request authentication for outbound connections. Require authentication for inbound and outbound connections.

Network Access Protection. Network Access Protection (NAP) is a new addition to Windows Server 2008 that is used to validate client configurations prior to allowing those clients access to domain resources. NAP can not only validate a client's health status but also provide automatic updating to the client in order to bring it into compliance. NAP will be discussed in detail later in this paper. Improved authentication and cryptographic capabilities. In addition to the existing IKE, Kerberos, and machine certificates, Windows Vista and Windows Server 2008 add support for Network Access Protection (NAP) health certificates, NTLM version 2 (NTLMv2), and Anonymous authentication as well as Authenticated IP (AuthIP). AuthIP is an enhanced version of IKE that offers additional flexibility with support for user-based authentication, authentication with multiple credentials, improved authentication method negotiation, and asymmetric authentication. Like IKE, AuthIP supports main-mode and quick-mode negotiation. AuthIP also supports extended mode, a part of IPsec peer negotiation during which a second round of authentication can be performed. Extended mode, which is optional, can be used for multiple authentications. For example, with extended mode you can perform separate computer-based and user-based authentications. Multiple authentication support is part of IPsec enforcement for the Network Access Protection (NAP) platform, in which IPsec peers authenticate with computer credentials and also use a health certificate to prove that they are compliant with system health requirements. Additional cryptographic capabilities have been added, including support for Advanced Encryption Standard (AES)-128, AES-256, and AES384 for encryption and Elliptic Curve Cryptography (ECC)based key exchange using P-256 and P-384.

Server and Domain Isolation

IPsec is used as the foundation upon which server and domain isolation is implemented at Microsoft. A visual depiction of the environment is shown in Figure 2.

Figure 2. The Microsoft IT environment with server and domain isolation

Windows Firewall
Windows Firewall enables host-based security on client computers, providing protection by blocking access to inbound TCP and UDP ports. The client-based protection complements Microsofts perimeter firewall. The first version of Windows Firewall filtered only inbound traffic. Microsoft IT also took advantage of the Authenticated Bypass feature, which enables authenticated hosts to bypass firewall protections to perform duties such as vulnerability scanning. With the release of Windows Vista and Windows Server 2008, several improvements have been made to Windows Firewall:

Support for both incoming and outgoing filtering. One of the most important improvements in Windows Firewall is the ability to filter both incoming and outgoing traffic, unlike the previous version which filtered only inbound traffic. Microsoft IT enabled this functionality as default policy for all Windows Vista client computers.

Additional exception capabilities. Exceptions can be configured based on Active Directory directory service groups, IP protocol number, source and destination IP addresses and ports, and the interface in which the packet arrives or to which it is destined. Both IP version 4 (IPv4) and IP version 6 (IPv6) are fully supported in Windows Firewall. Dynamic exception capabilities can be used whereby the hosts currently configured Dynamic Host Configuration Protocol (DHCP), Windows Internet Naming Service (WINS), Domain Name System (DNS), and default gateway are used and updated within the firewall when they change. Microsoft IT enables local administrators to configure exceptions to the firewall policy based on their own needs. For example, if a developer is working with applications that require specific TCP ports to be allowed, the developer can configure an exception for that application.

Improved management interface. The Windows Firewall with Advanced Security MMC snap-in provides an integrated application within which all aspects of firewall rules can be configured. Additionally, IPsec rules are now configured through this same application. Microsoft IT uses the Windows Firewall with Advanced Security snap-in to manage both Windows Firewall and IPsec.

Working with Mixed Client Devices

One of the challenges in implementing server and domain isolation and host-based firewalls is the number of nonWindows devices on the Microsoft network. Computers running Mac OS X, Linux, UNIX, and other operating systems are found on the network for compatibility and other testing along with devices such as Microsoft Xboxall of which need access to network resources. The need to maintain these client devices on the network created the need for boundary resources that would be allowed to talk to both trusted and untrusted computers and devices. Servers providing basic network services such as DNS and DHCP must be available to all client devices, regardless of whether they are part of the domain-isolated environment. Both clear-text and IPsec communication are available depending on the capabilities of the client device.

Application Segregation
The next phase in the evolution of Microsoft ITs security strategy is application segregation. Microsoft maintains an extranet on which individuals located internally or externally access resources. The extranet is logically separated from the internal network. Application segregation describes the environment in which server resources located in the extranet are accessed by individuals external or internal to Microsoft as well as communication within the extranet itself. Application segregation dictates the concept of least privilege at a network level, meaning that only those communications that have a valid business reason are allowed to continue, and then only at the minimum level necessary to accomplish the task. For example, even if an IP address is allowed to connect to a given resource, the application segregation framework further limits what that connection can do solely to what is necessary or allowed from that IP address. Application segregation is implemented atop the IPsec and Windows Firewall foundations that Microsoft IT already created. The existing use of IPsec within Microsofts network makes application segregation easier to implement and requires fewer resources. Further, management of application segregation was done using the same tools as

Windows Firewall and IPsec policies today. No dependencies on specific network devices or layouts were necessary for application segregation. Application segregation requires mapping of applications to determine the current patterns of communication between and among the servers. This information is used to create groups containing consumers of applications. Microsoft ITs application segregation uses logical groups of consumers and data providers to delineate how communication will take place. These groups are then mapped to security groups to indicate their role. The security groups have IPsec and firewall policies applied to them, which in turn are applied to the resources. This all takes place through Group Policy. Application segregation servers operate in Request Mode and therefore do not require IPsec as part of client communication. However, if IPsec is available it will be used. Otherwise, the communication falls back to clear text, which is what it would have been without IPsec. Figure 3 shows the Microsoft IT environment, including the extranet.

Figure 3. The extranet environment in context as part of application segregation

Network Access Protection (NAP)

Network Access Protection is a new addition to Windows Server 2008 that enables enforcement of a minimum set of client health requirements prior to be allowed access to resources. NAP provides the following functions: Health Policy Validation NAP enables validation of the system health policy for clients on the network. A client joining the network first obtains an IP address and then begins communication with the NAP servers in order to have its health checked. The NAP servers determine the level of compliancy with the health policy on the network and if the client is in compliance, a health certificate is issued. Network Access Limitation In the event that a client is non-compliant, it will not be allowed to communicate on the secure network. Remediation The NAP infrastructure attempts to bring the client into compliance. If the client can be brought into compliance it is given a health certificate and allowed to communicate on the secure network. Compliance The NAP infrastructure continues to communicate with clients to ensure that they maintain compliance with the health policy requirements for the network.

Systems Capable of Using NAP

Windows Server 2008, Windows Vista, and Windows XP SP3 are all capable of working with NAP.

Systems Not Capable of Using NAP

Systems not capable of NAP need to have health certificates created which can then be used to access NAP-based secure resources. These systems, including computers running older versions of Microsoft Windows, will not have their health examined by the NAP infrastructure. Note: For more information on the architecture of NAP, see

http://www.microsoft.com/technet/itsolutions/network/nap/naparch.mspx

PLANNING
The planning phases related to each step of securing the Microsoft environment largely depend on the phase and technology used.. For example, deploying IPsec requires different steps than the Windows Firewall deployment. However, large scale deployments across the Microsoft corporate network also required some similar steps during each deployment.

Planning the IPsec Rollout

During the implementation of domain isolation with IPsec, Microsoft IT took the steps described in the following sections.

Determine Segmentation Requirements

Microsoft IT started by evaluating the security measures already in place and identified several attacks that could be launched from unmanaged computers. The goal of the project was to deploy a mechanism to protect individual host computers that Microsoft IT managed on the corporate network from attacks launched by unmanaged host computers. The result of this evaluation was to create segregation within the network.

Choose Technology
Microsoft IT considered 802.1x, virtual LANs (VLANs), and VPNs as solutions for domain isolation before settling on IPsec. IPsec provided a scalable solution that did not require additional hardware or software investment. IPsec also did not require changing IP addressing on internal networks, as might have been the case with VLANs or VPNs. IPsec provided additional abilities to further isolate host computers into security groups and encrypt traffic, if desired.

Design IPsec and Group Policy Objects

Microsoft IT first created the security groups and GPOs for IPsec policy assignment and management. Microsoft IT used two group and IPsec policies: one for the default Secure Request behavior and the other for the boundary server exceptions using the Request Mode Security behavior. The team then worked with the network engineering team to identify all the IPv4 subnets assigned to the corporate network. This list of subnets was used to create the default rule and filter set for IPsec use, called the Secure Subnets rule. Microsoft IT also worked with the network engineering team to identify exceptions to the secure subnets filter list and set up rules for each of them as needed.

Test Policies and IPsec Functionality and Behaviors

With the filters designed and GPOs defined, Microsoft IT first enabled policies that had filters with limited subnets listed so that only small numbers of computers used IPsec, a phased subnet approach. This allowed Microsoft IT to deploy IPsec on limited computers to tightly control the initial testing. This testing confirmed the need for boundary machines and helped Microsoft IT refine the filters and filter rules.

Create a Rollout Schedule

With limited testing complete, Microsoft IT examined the network organization to create a rollout schedule across the enterprise. Because of the potentially disruptive nature of a large-scale IPsec deployment, the Microsoft IT team planned the deployment in a way that would allow them to resolve unanticipated problems with minimal impact on most employees. The deployment would start with the smallest individual subnets, then entire buildings, and eventually the entire network.

Deployment was planned in two phases:

Phase 1: Deploy Request mode IPsec to appropriate computers. Phase 2: Deploy Secure Request mode IPsec to appropriate computers.

Develop a Test Process and Strategy

During the rollout, Microsoft IT carefully monitored traffic on deployed subnets as well as the impact on the user community through help desk call volumes and other observations. Based on this monitoring, Microsoft IT then reevaluated the rollout process and strategy. The deployment focused on ensuring minimal impact to users, placing a high priority on allowing employees to work uninterrupted. Microsoft IT used the phased subnet deployment approach for its global Request mode deployment with a great deal of success. The Secure Subnets filter list was slowly expanded as the rollout progressed until the full set of corporate network subnets were in the list and nearly all network traffic was encapsulated with IPsec. When Request mode deployment was complete, all domain-joined computers in the enterprise had the same Secure Subnets filter list. To support its Secure Request rollout, Microsoft IT created a new, more-specific rule and filter list (with smaller subnet designations) and assigned a Secure Request filter action to it. Although deploying by subnet provides a more granular level of control for IPsec deployment and allows an IT organization to gauge the impact from the deployment, it does create some challenges when using a more restrictive filter action. Specifically, with Secure Request or Require mode, users with non-domainjoined computers on the deployed subnets will be blocked from initiating sessions with other computers with the policies. While this is the end state of a secure IPsec deployment, the effects can be confusing to users, because the users assume that the changes will not apply to their non-domainjoined computers. Microsoft IT started its Secure Request deployment with the per-subnet filter list method but found that the changes were too confusing for the user populations and created a broader impact than Microsoft IT felt was acceptable. In response, the rollout process was changed to deploy to individual domains instead of subnets, starting with the smallest domains. The main corporate domain, containing the majority of Microsoft ITmanaged computers, was deployed last.

Communicate with Users

The IPsec deployment was completely transparent to the majority of Microsoft employees and required no user interaction. At peak deployment times, the maximum number of help desk calls per month related to IPsec was less than 250. This call volume was extremely low compared to other systemsthe Microsoft help desk gets around 7,000 calls each month. Help desk personnel were trained to help users with network problems when IPsec was deployed. They were equipped with troubleshooting flowcharts, process articles, and training on Windows Management Instrumentation (WMI), IPsec, Kerberos authentication, and DNS to resolve issues that arose. Some employees using computers previously unmanaged by Microsoft IT were prevented from accessing from resources they needed and therefore they were encouraged to put their unmanaged computer on a managed domain. Developers and other users of servers containing sensitive intellectual property, HR information, or accounting information also needed to be aware of the changes to the security policy that IPsec enforced. Previously, these

groups were able to access the sensitive servers from any computer connected to the corporate network, passing their user credentials to the server applications. With the deployment of IPsec, these servers could only be accessed by an authorized user from a computer in the proper domain security group. Microsoft IT used the Access This Computer from the Network logon right to restrict access to these domain security groups, and IPsec would block connections from unauthorized computers. The business decision to allow access to this information only to authorized computers was communicated to users of these servers. The entire company was notified and kept aware of progress on the IPsec deployment through a variety of methods:

Security bulletins sent through e-mail to all employees Internal training sessions Informal lunch-time presentations (brown bag sessions) Stories in an internal corporate newsletter Self-paced multimedia training An internal Web page with technical detail and a Frequently Asked Questions (FAQ) section For most employees, no training was necessary. Before requiring IPsec for connections to SecureNet servers, an e-mail message was sent to all employees notifying them that their computers must meet two requirements:

Running a minimum Microsoft ITspecified operating system Joined to a Microsoft ITmanaged domain

The e-mail message warned that computers not meeting these requirements would not be able to gain access to Microsoft ITmanaged servers and internal Web sites after a specified date and provided links to the internal Web page for more information.

Planning the Windows Firewall Rollout

With the Windows Firewall rollout, Microsoft IT took advantage of experiences from the IPsec implementation. Without the need to choose a technology, less planning was necessary for this rollout, and the process followed several of the same general steps as the IPsec rollout. The integration of Windows Firewall with Advanced Security into Windows Vista and Windows Server 2008 enabled advanced features such as Authenticated IP to be used as part of the rollout. For the Windows Firewall rollout, Microsoft IT followed the steps described in the following sections.

Design Firewall and Authenticated IP GPOs

Microsoft IT built GPOs for the default rule set, which would be deployed to Windows Vista and Windows Server 2008 computers.

Test the Policies

The policies created in the previous step were tested to understand the behavior of Windows Firewall and Authenticated IP between computers running Windows Vista and Windows Server 2008 and those running legacy operating systems such as Windows Server 2003 or Windows XP.

Create a Rollout Schedule

A schedule to roll out the Windows Firewall enhancements was planned. The results of this planning showed that a phased rollout, in which a pilot domain was used first, would be the most effective way to ensure availability of crucial resources. The rollout schedule was: 1. 2. Roll out to the pilot domain. Roll out company-wide.

In this step, a rollback plan was also developed in the event that unforeseen issues required a complete rollback of the Windows Firewall implementation.

Test the Process and Create Documentation

Microsoft IT conducted further testing and created project documentation. The documentation helped train help desk and Tier 2 support staff, which also occurred during this step.

Communicate with Users

To help ensure a smooth rollout, Microsoft IT informed users of the addition of Windows Firewall, which was to be enforced on computers running Windows Vista and Windows Server 2008. Because the default setting was to block incoming connections not explicitly allowed by a rule, Microsoft IT informed users that this might mean that access to resources that had previously been allowed might no longer be available. It is common for users at Microsoft have local administrative rights, and Microsoft IT allows users to change the firewall rules. This means that users might choose to allow inbound connections when required for their work. This needed to be communicated to users so that they could change firewall rules as necessary to perform their job.

Deploy Windows Firewall to the Pilot Production Domain

Microsoft IT deployed the Group Policy settings to enable Windows Firewall in a limited production environment. This was done to further attempt to identify any issues that would arise in a production environment with Windows Firewall enabled.

Deploy Windows Firewall Worldwide

With no additional issues found, Microsoft IT deployed the Windows Firewall settings to all domain-joined client computers and boundary computers through Group Policy

Planning the NAP Deployment

The NAP deployment consisted of three phases. Each of the three phases was divided into pilot and general release subphases. 1. Reporting 2. Deferred Enforcement 3. Enforcement

Reporting Mode Deployment

NAP was initially deployed in reporting mode which enabled Microsoft IT to determine the impact on users for later phases of deployment. Some of the goals Microsoft IT met with the reporting mode deployment were:

Verification of clients participating in NAP. Capturing of daily statistics on client status, including health and unhealthy clients. Verification that healthy clients receive health certificates. Obtaining of a baseline NAP server performance. Identification and, where possible, resolution of differences in reporting between other tools such as SMS, SER, and MOM. Identification and remediation of failures with the NAP infrastructure or communication between the infrastructure and clients. Identification of tools and data that will be needed to troubleshoot NAP issues for later phases of deployment. Estimation of impact to end users in deployment of later phases. Training of Help Desk and support staff.

Deferred Enforcement
During the Deferred Enforcement phase of NAP deployment, end users began to see notifications from the operating system, though no changes were made to enforce the health policies. The notifications created help desk calls from users unfamiliar with NAP and the messages being received. Microsoft accomplished several goals during the Deferred Enforcement phase, including:

Requirement of health for IPSec configuration Capturing of statistics on healthy and unhealthy clients. Monitoring and comparison of server performance versus the baseline obtained in the Reporting Mode phase. Comparison of SMS, MOM, SER, and NAP reports. Identification and resolution of remediation failures. Utilizing tools to assist in troubleshooting NAP issues.

Enforcement
The final phase of NAP deployment is Enforcement. During Enforcement, NAP is deployed. Because this phase has the greatest risk of affecting the business, the Reporting Mode phase must be fully complete and all data analyzed in order to minimize the impact and quickly remediate any issues that arise. During enforcement, Microsoft IT accomplished these goals:

Capturing of statistics of healthy and unhealthy clients. Comparison of SMS, MOM, SER, and NAP reports. Identification and resolution of remediation failures.

DEPLOYMENT
The deployment of both IPsec and Windows Firewall took advantage of tools already built into the Windows Server operating system. Windows Server 2003 was used for the IPsec rollout, while Windows Server 2008 was used for the implementation of Windows Firewall. Both IPsec and Windows Firewall settings can be configured through Group Policy and pushed to domain computers on a corporate network. This makes large-scale deployments much easier and much less prone to error than manual deployments through other means. Microsoft IT used Group Policy to deploy IPsec and Windows Firewall settings. The Domain Computers group uses the default Group Policy settings, which include IPsec policies and filters. Certain computers are denied access to the default policy and instead use a different policy applied through their security groups.

IPsec Policy Settings

Before deploying IPsec, Microsoft IT completed the steps described in the following sections.

Create Dedicated GPOs for IPsec

Microsoft IT created three GPOs for each domain for IPsec while other GPOs were used for encryption testing.. Two of these GPOs are the primary IPsec policies, accounting for more than 99 percent of the computers in each domain:

Request mode GPO Secure Request mode GPO

Client computers apply GPOs in a specific, inherited order. The first listed GPO has precedence over any that follow. This ordering ensures that the least-restrictive IPsec policy is applied if there is an error. Figure 4 illustrates how the GPOs are applied for domains within Microsoft.

Figure 4. GPO application process for Microsoft domains The third GPO, Require Encryption, is used for additional security on certain resources.

Create Security Groups

Several computers within the Microsoft network need special IPsec policies that are not applied with the default policy. Because of this, Microsoft IT created a set of security groups for these computers. Each security group can allow or deny the application of a GPO. For example, devices that are secured with IPsec and those are not must be

able to contact servers such as DNS servers and domain controllers. These servers are added to a No IPsec security group. The computers security group and the GPO associated with the domain are used to determine which IPsec policy that computer receives. Microsoft IT created the following security groups:

Universal security groups to control the application of GPOs. Several universal security groups were created at the forest level, which helped to simplify administration. Universal security group for Group Policy/IPsec policy administration. A specific security group consisting of designated user accounts was created. This enables Microsoft IT to control who can administer IPsec across the entire forest.

Administer Group Policy

Microsoft IT uses Windows Server 2008 to administer Group Policy for IPsec. However, Microsoft IT still maintains computers that run the Microsoft Windows 2000 operating system. Because Windows 2000 had a more limited set of capabilities for IPsec, Microsoft IT defined IPsec rules and filters to work with Windows 2000 and later computers. Microsoft IT administrators built local IPsec policies, the result of which is a file with an .ipsec extension containing the exported policies. The file is then imported into a test environment, where it is evaluated with the goal of validating the policies. After the policies are validated, they are imported into each domain for a standardized deployment. The .ipsec files also serve as a disaster recovery backup for IPsec policy settings. The previously discussed default policy and filter rules are used for the majority of computers on the network. An IPsec policy consists of a set of rules. Each rule consists of a filter list and an action and can specify an authentication method, a tunnel, and a connection point. A filter list contains a set of filters. Each filter specifies a source network, a destination address or network, and optionally a port and protocol. Filter actions can be Permit, Block, or a customizable Negotiate Security action. Figure 5 illustrates the relationship of these building blocks of an IPsec policy.

Figure 5: Structure of an IPsec Policy. Each host computer may only have a single active IPsec policy. Microsoft IT defined different IPsec policies that apply to computers through different GPOs during different phases of the deployment process. There are cases in which IPsec may already be in use for other things. Some businesses use IPsec block and permit filters to secure individual servers. These existing IPsec deployments may directly conflict with a deployment like the one Microsoft IT uses: A single computer cannot have separate policies for being part of a SecureNet-like environment and still use a separate IPsec policy to locally secure a server. To address these issues, specific secure servertype policies can be implemented within the larger context of the domain policies with either more restrictive settings (require encryption, for example) or less restrictive settings (permit all Simple Mail Transfer Protocol [SMTP] traffic for monitoring, for example). These individual server policies can be implemented by linking specific GPOs to organizational units (OUs) or by using security group filtering to apply the secure server settings to a subset of servers.

Policy Settings
To create the IPsec policy imported into the domain, Microsoft IT uses an MMC snap-in to define a local IPsec policy on a computer running Windows Server 2008. Individual rules are managed from the IPsec policy properties sheet. Filter lists and filter actions can be defined directly from the MMC snap-in or in individual rule definitions. Policy settings are associated with particular elements: the policy itself, individual rules, filters, and filter actions. Table 1 describes the standard IPsec policy deployed to most computers that Microsoft IT manages.

Table 1. IPsec Policy Settings in Use in the Microsoft IPsec Deployment

Policy setting Default Filter Action Value Secure Request Notes At Microsoft, the IPsec policy for most domain-joined computers specifies a Secure Request default filter action. Each computer with this policy uses IPsec on outbound IP requests to all subnets not excluded by another filter. If IPsec is not successfully negotiated within 500 milliseconds, the computer falls back to unauthenticated traffic for that host computer and a soft Security Association (SA) is established. All inbound unauthenticated requests to host computers with this policy are denied. Only incoming requests that successfully negotiate IPsec are permitted. This filter action is not present by default but can be created in a new filter action by clearing the Accept unsecured communication check box and selecting the Allow unsecured communication check box. Note that this policy is only supported on Windows 2000 SP3 and later operating systems, Windows XP SP1 and later and Windows Server 2003. In Windows 2000 and Windows XP, Security. Default Filter List Any <-> Secure A set of filters limits IPsec to corporate subnets. If a portable computer connects to a network other than the corporate network, it does not use IPsec for outgoing or incoming communications. If a Microsoft ITmanaged computer connects to a private network using a Request for Comments (RFC) 1918 IP range specified in this filter list, the computer cannot connect to computers in the this policy behaves like Request

Subnets

overlapping IP address ranges. For example, the entire 10.0.0.0/8 network space is defined to use IPsec within the Microsoft corporate network. If a Microsoft computer connects to a different corporate network also using this range, it may not be able to successfully establish communications with any other hosts if incompatible IPsec policies are being used, and all incoming communication requests will be blocked. Microsoft has explicitly exempted two small private IP address ranges to allow employees to connect and use home networks. Default Authentication Method Kerberos Windows IPsec can use one of three authentication methods:

Policy setting

Value

Notes Kerberos, supplied by Active Directory A certificate signed by a particular certification authority (CA) A specific string used as a pre-shared key By using Kerberos for authentication, IPsec can use much of the power in Active Directory to define security groups and further segment the network. At Microsoft, Kerberos is the default authentication method for IPsec. Certificates are supported by particular rules to support computers that are not part of an Active Directory domainfor example, allowing VPN clients to connect without being managed by Active Directory. Pre-shared keys are not recommended for most installations, because they can be easily compromised and cannot be easily revoked.

Default

Negotiate

ESP

with

NULL

IPsec provides for two different security methods: Authentication Header (AH) and ESP. Generally, AH is used for authenticating and validating the integrity of data. ESP is generally used when encryption is desired. Even though Microsoft IT does not use encryption for most traffic within the corporate network, ESP was chosen for all IPsec traffic for several reasons: ESP can pass through Network Address Translation (NAT) devices. Encryption can be easily enabled for particular servers, if desired. Additional network bandwidth and server overhead is minimal.

Security Method

encryption

Main Mode Lifetime

2 hours

The default main mode lifetime for Windows is 8 hours. This specifies the length of time an SA between two computers is valid before being cleared out of memory and renegotiated. Microsoft IT chose to set a shorter main mode lifetime to reduce memory usage on busy servers.

Quick Mode Lifetime

1 hour (Windows IPsec setting) default

Length of time a key is valid before being regenerated. Quick mode SAs have a hard-coded 5-minute idle timeoutthey are removed if no traffic is exchanged for 5 minutes.

Policy setting IPsec Key Exchange Default Method Negotiate Method Order Security Preference Security

Value AES

Notes The Microsoft ITpreferred security method specifies that the key exchange is encrypted with AES.

Custom

For filter actions specifying that IPsec must be negotiated to permit traffic, a custom security method was created to specify ESP with no encryption. All keys are set to expire after one hour. The default security method for all traffic is ESP without encryption, but with all combinations of security methods specified, computers with IPsec policies using this filter action should be able to use encryption and other IPsec features when required by the other host.

IPsec Filter Design

Microsoft IT takes advantage of the Hotfix released with Knowledge Base (KB) article 914841 to simplify the rules for IPsec filters for Windows XP SP2 and Windows Server 2003 SP1. Doing so reduces the number of rules required for exceptions. With the release of Windows Vista and Windows Server 2008 creation of IPsec rules for Domain and Server Isolation scenarios is wizard-driven which in turn further reduces the need for complex filter lists and exceptions.

Windows Firewall Settings

The default settings for Windows Firewall at Microsoft is to block all inbound connections except those for which a rule has been explicitly defined. Outbound connections are allowed by default unless they match a rule to affect them otherwise. Windows Firewall is required on all computers running Windows Vista and Windows Server 2008 on the corporate network. Computers in boundary networkseven those running Windows XP and Windows Server 2003 are required to have Windows Firewall, as well.

Supporting Non-IPsec Platforms

On the Microsoft corporate networks, certain computers and devices are not capable of using IPsec as deployed by Microsoft IT. These machines primarily include:

Non-Windows computers and devices. Apple Macintosh computers, UNIX computers, Xbox consoles, and Pocket PCs do not have Windows IPsec installed or easily deployed. Legacy Windows operating systems. Some groups in Microsoft have test computers running

Windows NT 4.0 or Windows 9x, which are incapable of using Group Policybased IPsec. Windows computers not joined to a managed domain. Some development groups run private domains for testing. Individuals in development and testing roles have test and development computers not connected to a managed domain.

Remote Access Service (RAS) and VPN clients not owned by Microsoft. Partner and vendor companies need to connect to certain Microsoft resources. All employees can connect to the corporate network using home computers. These computers may not have a machine account in a managed domain.

Historically, all these computers have had access to domain resources. With IPsec deployed, these computers cannot access computers inside the SecureNet. Windows IPsec is compatible with IPsec implementations available on these other platforms, but Microsoft IT chose to design the IPsec policies to exclude them, because they are not managed to the security standards required for SecureNet. Microsoft has a business need to allow some non-domainjoined computers access to business resources that would otherwise be in SecureNet. In addition to the types of client computers already listed, there are specific infrastructuretype services that cannot be secured by IPsec. To establish IPsec in the first place, a computer must have network connectivity and be able to get the IPsec policy from a domain controller. This means that domain controllers must communicate with unauthenticated hosts, and DHCP relay agents must be able to forward responses from DHCP servers so client computers can gain access to the network. In addition, WINS and DNS are needed so that client computers can locate the domain controllers and allow access to boundary machines and the Internet by guest and test computers that do not require access to SecureNet. Certain other services do not support IPsec, such as network thin clients or other bootstrap clients that need to download an image from a computer running Remote Installation Service (RIS) and Windows Server 2003, Automated Deployment Services (ADS).

Boundary Machines
Developing effective ways to connect specific non-Windows devices with a business need to access domain resources is a high priority for Microsoft IT, driven by the Secure Anywhere Access initiative. Currently, these devices must access resources through boundary machines, which have special IPsec rules. To manage exceptions from the general SecureNet deployment of IPsec, Microsoft IT defined different types of boundary machines. Although a boundary machine is an IPsec-enabled computer, it accepts non-IPsec inbound connections, straddling the border between SecureNet and the untrusted corporate network. Boundary machines do not proxy communication between SecureNet and the untrusted corporate network; they are simply SecureNet computers that allow access from the untrusted corporate network. Note that boundary machines:

Use Request security behavior, not Secure Request mode. Give Microsoft great flexibility in defining exceptions to the default IPsec policy using security groups instead of IP addresses.

Boundary machines require extra management and security, because they provide a way for untrusted computers to gain access to SecureNet resources. Microsoft IT has identified specific acceptable reasons for having a boundary machine. All the computers that share a particular reason for allowing untrusted access are put into a defined security group. In this way, threats to particular services can be quickly blocked, and additional group policies such as firewall rules may be deployed to particular security groups. For example, all RIS servers are placed in a special security group. As boundary machines, they permit incoming non-IPsec from any computer, which allows the RIS servers to support computers that download operating system

images before loading Windows or having any IPsec capabilities. By being part of a RIS server security group, Group Policy denies access to the default corporate IPsec policy, and the RIS server security group allows the Request mode policy to be applied. Another common type of boundary machine is a file and print server used by Macintosh computers in a particular group or building. File servers are granted boundary status on a case-by-case basis. Several Mac business units require access to particular domain resources for developing their software. Requests from these groups are typically granted, but efforts are underway to consolidate Mac resources to particular computers. Any employee may request that a particular computer be made a boundary machine, based on a strong business need to access corporate resources. The employee must provide the reason for asking for the exemption along with supporting details. Microsoft IT can then evaluate the need, then grant or deny the request. Deploying IPsec has allowed Microsoft IT to identify where security risks exist on the network and gain a better understanding of the computer population within the corporate network. Microsoft IT can now deny insecure network traffic by default and grant it on a case-by-case basis, after gaining an understanding of the ramifications and the ability to further restrict the insecure traffic, quickly, if necessary. In other words, developing a detailed understanding of the exception scenarios provides IT administrators with the required knowledge for taking additional security steps to strengthen the overall security of the environment. After deploying Secure Request mode to the entire corporate network, fewer than 2 percent of all domain-joined computers were boundary machines. Now that the deployment is complete, Microsoft IT can continue to isolate, consolidate, and take additional security steps to mitigate the risks that boundary machines pose. For example, all RIS servers are placed in a special security group. As boundary machines, they permit incoming non-IPsec from any computer, which allows the RIS servers to support computers that download operating system images before loading Windows or having any IPsec capabilities. By being part of a RIS server security group, Group Policy denies access to the default corporate IPsec policy, and the RIS server security group allows the Request mode policy to be applied. Another common type of boundary machine is a file and print server used by Macintosh computers in a particular group or building. File servers are granted boundary status on a case-by-case basis. Several Mac business units require access to particular domain resources for developing their software. Requests from these groups are typically granted, but efforts are underway to consolidate Mac resources to particular computers. Any employee may request that a particular computer be made a boundary machine, based on a strong business need to access corporate resources. The employee must provide the reason for asking for the exemption along with supporting details. Microsoft IT can then evaluate the need, then grant or deny the request. Deploying IPsec has allowed Microsoft IT to identify where security risks exist on the network and gain a better understanding of the computer population within the corporate network. Microsoft IT can now deny insecure network traffic by default and grant it on a case-by-case basis, after gaining an understanding of the ramifications and the ability to further restrict the insecure traffic, quickly, if necessary. In other words, developing a detailed understanding of the exception scenarios provides IT administrators with the required knowledge for taking additional security steps to strengthen the overall security of the environment.

After deploying Secure Request mode to the entire corporate network, fewer than 2 percent of all domain-joined computers were boundary machines. Now that the deployment is complete, Microsoft IT can continue to isolate, consolidate, and take additional security steps to mitigate the risks that boundary machines pose.