Server and Domain Isolation Using IPsec and Group Policy

This chapter provides information about how to obtain the necessary information to plan for and deploy a server and domain isolation solution. Successfully deployment requires an accurate and up-to-date picture of the information technology (IT) infrastructure. After reading this chapter, you will have a good understanding of the information that is required for you to complete the design of a server and domain isolation solution.

The final part of this chapter discusses the process of understanding and documenting which identified computers are likely to be able to work as "trusted" computers within the solution. The design team will require this information when they create the plans for the solution.

On This Page

	Chapter Prerequisites
	Who Should Read This Chapter
	Identifying Current State
	Capacity Considerations
	Predeployment Concerns
	Trust Determination
	Capturing Upgrade Costs for Current Hosts
	Summary

Chapter Prerequisites

Before using the information in this chapter, ensure that you and your organization meet the following prerequisites. The guidance that this chapter provides is specifically tailored to meet the needs of an organization that is closely aligned with these prerequisites. Failure to meet all the prerequisites will not necessarily have a negative impact on your project, but you will maximize the value of this guidance if you meet them.

Knowledge Prerequisites

You should be familiar with concepts of IPsec, and also have a solid understanding of the following:

Before proceeding with this chapter, you should also read the previous chapters in this guide and have a thorough understanding of the architectural and design concepts of the solution.

Organizational Prerequisites

Planning the isolation groups for an organization is a task that usually involves many different people. The information that is needed to determine the exact requirements will often come from a number of sources throughout the organization. You should consult with those members of your organization who may need to be involved in the planning of these groups, including the following people:

Note   Depending on the structure of your IT organization, these roles may be filled by a number of people, or there may be fewer people spanning several roles.

In addition to requiring information from the listed teams, it is important to understand that current operational practices will need to be updated with the introduction of IPsec into the environment. It is also possible that software and hardware will need to be updated, such as BIOS and firmware updates for network devices. Finally, additional network tools may be required to help support and troubleshoot the IPsec environment.

IT Infrastructure Prerequisites

This chapter also assumes that the following IT infrastructure exists:

Top of page

Who Should Read This Chapter

This chapter is designed for IT professionals who are responsible for creating the IT infrastructure inventory that solution architects and designers will use. These IT professionals will usually be members of the organization's support or operations staff. A good level of technical understanding of both the tools and technologies involved in the information-gathering process and the organization's current infrastructure is required to get the most benefit from this chapter.

Top of page

Identifying Current State

The process of obtaining and maintaining a reliable record of an organization's computers, software, and network devices is a classic IT challenge. A successful project will depend on the information obtained from such a process. Before starting the planning process for a server and domain isolation project, you need to collect and analyze up-to-date information about the computers, the network, and the directory services that are already deployed in the organization. This information will allow you to create a design that accounts for all possible elements of the existing infrastructure. If the gathered information is not accurate, problems can arise when devices and computers that were not considered during the planning phase are encountered during implementation. The following sections outline the required information in each area and provide examples of the information that was gathered for the Woodgrove Bank server and domain isolation solution.

Network Discovery

Perhaps the most important aspect of planning for server and domain isolation is the network architecture, because IPsec is layered on the Internet Protocol itself. An incomplete or inaccurate understanding of the network will prevent any isolation solution from being successful. Understanding subnet layout, IP addressing schemes, and traffic patterns are part of this effort, but the following two components are vital to completing the planning phase of this project:

The goal is to have enough information to identify an asset by its location on the network in addition to its physical location.

It is better to start with a network architecture that is very well thought out, has easily identifiable address ranges, and has as few overlaps or discontinuous ranges as possible. There may be specific business requirements or circumstances (such as mergers and acquisitions) that do not allow for a "streamlined" network, but if the current state is documented and understood, the task of identifying the network and its managed assets is simpler. Do not use a complex and poorly documented network as a starting point for the design, because it can leave too many unidentified areas that are likely to cause problems during implementation.

This guidance helps obtain the most relevant information for planning server and domain isolation but does not attempt to address other issues, such as TCP/IP addressing and variable length subnet masking, virtual local area network (VLAN) segmentation, or other network optimization methods and techniques. The obtained information will be used to formulate the implementation and operational components of the server and domain isolation solution.

Documentation of Network Segmentation

If your organization does not have its current network architecture documented and available for reference, such documentation should be obtained as soon as possible before proceeding with the solution. If the documented information is not current or has not been validated recently, you have two basic options:

Although the required information can be presented in a number of different ways, a series of schematic diagrams is often the most effective method of illustrating and understanding the current network configuration. When creating network diagrams, try to avoid flooding them with too much information. If necessary, use multiple diagrams showing different layers of detail.

For example, in the Woodgrove Bank scenario, the team created the following diagram to illustrate the high-level view of its existing wide area network (WAN) and site environment:

Figure 3.1  Woodgrove Bank WAN and site network diagram
See full-sized image

After the team created this diagram, it proceeded to create more detailed diagrams for each site, and ultimately each subnet within each site.

While documenting your network you may find some network applications and services that will not be compatible with IPsec. Current examples of such incompatibility include the following:

IPsec breaks network-based prioritization and port/protocol-based traffic management when ports and protocols are used. Unfortunately, there is no workaround for encrypted packets. If traffic management or prioritization must be based on ports or protocol, the host itself must be capable of any traffic management or prioritization functions.

Next, it is important to record exactly what information is needed for the various devices in the network.

Network Infrastructure Devices

The devices that make up the network infrastructure (routers, switches, load balancers, and firewalls) will communicate using IPsec after the solution is implemented. For this reason, it is important to examine the following characteristics of these devices on the network to ensure that they will be able to handle the technical and physical requirements of the design:

Also note that IPsec can affect an intrusion detection system (IDS), because a specific parser will be required to interpret data inside of packets. If the IDS does not have a parser, it cannot examine data in those packets to determine whether a particular session is a potential threat. In this case, deciding to use IPsec indicates that your organization needs IPsec more than it needs the IDS.

The information identified in this section is critical for the success of the project, because it helps you to understand the current configuration and "health" of the network infrastructure before configuring those devices to use IPsec (or placing additional load on them if they are already configured to pass IPsec traffic). By studying peak use information, you can determine whether the device is capable of using IPsec in its current state or if it requires a memory or firmware upgrade to support the expected load. The make and model information will prove useful when obtaining hardware to upgrade the devices (if necessary). Information about other configuration parameters or features that might be peculiar to that make and model may also be helpful. The number of ACLs configured on devices will help you estimate the effort that will be required to configure the devices to support IPsec. If no device on the network is configured to allow IPsec traffic, and your network has a large number of routers, device configuration could be a significant effort.

After you obtain this information, you can quickly determine whether it is necessary to upgrade the devices to support the requirements of the project, change the ACLs, or take other measures to ensure that the devices will be able to handle the loads that will be expected of them.

Analysis of Current Network Traffic Model

After you gather the addressing and network infrastructure information, the next logical step is to carefully examine the communications flow. For example, if a department such as Human Resources (HR) spans several buildings, and you want to use IPsec to encrypt information in that department, you need to know how those buildings are connected to determine the level of "trust" to place in the connection. A highly secured building that is connected by copper cable to another building that is not protected can be compromised by an eavesdropping or information replay attack. If such an attack were a threat, IPsec could assist by providing strong mutual authentication and traffic encryption for trusted hosts. However, the solution cannot account for the fact that a lack of physical security on trusted hosts will remain a threat.

When you examine traffic flow, look closely at how all managed and unmanaged devices interact, including non-Windows based devices such as Linux, UNIX, and Mac in addition to versions of Windows that are earlier than Windows 2000 SP4. Ask yourself such questions as, Do certain communications occur at the port/protocol level, or are there many sessions between the same hosts across a wide array of protocols? How do servers and clients communicate with each other? Are there any current security devices or projects that are implemented or planned that could impact the isolation project? For example, using Windows XP SP2 and Windows Firewall to "lock down" certain ports such as UDP 500 would cause the IKE negotiation to fail.

When you use the threat modeling process performed in Chapter 2, "Understanding Server and Domain Isolation," to examine the different types of network traffic, you can easily find those protocols and applications that generate traffic that should be secured from untrusted or unmanaged devices. Some of the more common applications and protocols are:

After documenting the physical and logical network, the next step is to examine current traffic patterns and answer the following questions:

●    Do you currently have subnets that are dedicated to specific types of traffic (for example, Mac workstations and UNIX workstations, or mainframe-to-terminal connections)?

●    Do you need to separate different types of traffic or traffic between locations?

Active Directory

After the network, Active Directory is the second most important item from which to gather information. You should understand the forest structure, including domain layout, organizational unit (OU) architecture, and site topology. This information makes it possible to know where computers are currently placed, their configuration, and the impact of making changes to Active Directory as a result of implementing IPsec. The following list describes the necessary information for completing this portion of the discovery effort.

The Woodgrove Bank scenario uses a single forest (corp.woodgrovebank.com) that contains four domains spread across five sites. Each site may contain a domain controller (DC), primary domain controller (PDC), or global catalog (GC) server as shown in the following table:

Table 3.1  Woodgrove Bank Active Directory Information

The Woodgrove Bank Active Directory design used the two-way trust relationships that are automatically created by the forest. No additional cross forest or external trusts were in place.

The following figure shows an example of the high-level OU structure that Woodgrove Bank used. This structure was used consistently across the three main regional domains of Americas, Europe, and Asia.

Figure 3.2  Woodgrove Bank OU structure example
See full-sized image

Because the server and domain isolation project was Woodgrove Bank's first IPsec implementation, there were no existing active IPsec policies in place.

Host Discovery

The most valuable benefit of conducting an asset discovery project is the large amount of data that is obtained about hosts (workstations and servers) on the network. In Chapter 4, "Designing and Planning Isolation Groups," decisions are made that require accurate information about the state of all hosts to ensure that they are able to participate in the design's IPsec communications.

Host Data Requirements

This section describes the host information that is needed and discusses how to represent this information physically and logically.

After collecting all this information and consolidating it into a database, perform regular discovery efforts at periodic intervals to keep the information current. You will need the most complete and up-to-date picture of the managed hosts on their networks to create a design that will match your organization's requirements.

You can use various methods to gather data from the hosts on the network. These methods range from high-end, fully automated systems to completely manual data collection. Generally, the use of automated methods to gather data is preferred over manual methods for reasons of speed and accuracy. However, the information that is required is the same, regardless of which method is used; only the amount of time spent obtaining the information is different. Typical problems that manual processes encounter include having duplicate information, ensuring that the scope of the effort is accurate (such as whether all networks were scanned and host information captured or just the client subnets), and obtaining the information in a timely manner so that it is useful to the project. A discussion of all elements of a complete IT system's audit is outside the scope of this project. However, it is important to understand that this audit information should be available to the organization for many more reasons beyond the needs of this solution. Asset tracking and security risk management are just two important examples of processes that require a current and accurate system inventory.

Automated Discovery

Using an automated auditing network management system such as SMS will provide much valuable information about the current state of the IT infrastructure. One problem with automated systems, however, is that hosts that are offline, unplugged, or otherwise physically (or logically) unable to respond to queries for information will not show up in the final database. Even the most automated systems require an element of manual management to ensure that the hosts are accessible and accounted for correctly.

Many products and tools are available from a variety of vendors. Some methods use a central scanning mechanism, and some use agents that are installed on the client computers. It is outside of the scope of this guide to compare or recommend products for purchase, but the solution requires that the discovery data highlighted in this chapter is present for the design considerations made in chapters 4 and 5.

For more information about how SMS 2003 can help perform asset management (or can help gather the information that this project requires), see the demonstration and the asset management datasheet on the SMS 2003 Asset Management page.

Manual Discovery

The biggest difference between manual discovery methods and automated methods is time. It could take a few dozen people days or weeks to manually gather the information required for this project, and possibly longer in a larger enterprise. If you plan to use a manual method to audit the current state of your infrastructure, it is important that the obtained information be available in an electronic format such as a spreadsheet or database. The sheer volume of data that can be generated can make the process of filtering and analyzing very difficult if you cannot quickly and accurately generate specific queries that return the required information. In addition, you can use local IT administrators to obtain the information or validate any information that was collected previously.

Even if your organization does not possess an automated auditing tool, there is still an element of automation that you can obtain by using the standard remote management and scripting interfaces that are available on the Windows platform. The primary issue with using these tools is ensuring that clients are not missed simply because they are not compatible with the management tool or script.

You can use the Windows Scripting Host (WSH), Microsoft Visual Basic® Scripting Edition (VBScript), and Windows Management Instrumentation (WMI) to create a script file that can collect the system configuration information. The following table shows the availability of both VBScript and WMI by platform.

Table 3.2  VBScript and WMI Availability by Platform

Note   You can download the Microsoft Windows Script 5.6 Update from the Microsoft Windows Script Downloads page. You can download the Windows Management Instrumentation (WMI) CORE 1.5 installation package from the Microsoft Download Center.

An example VBScript called Discovery.vbs is provided in the Tools and Templates folder of this solution. This script uses WMI to retrieve all of the information listed in the "Host Data Requirements" section of this chapter, with the exception of role and physical location. The information is collected in the text file C:\Discovery\<systemname>_info.txt on the local computer. You could modify the script to collect additional information or to place the collected information on a remote file share.

If WMI or VBScript is not available on the host computer, you can collect some information by using a batch script and external tools. The difficulty is that the batch language is extremely limited in functionality, and configuration information is not easily obtained from the command line in earlier versions of Windows.

To perform a host discovery, it is necessary to query hosts and provide a place to store the results of those queries.

Whether you use an automatic, manual, or hybrid option to gather the information, one of the biggest issues that can cause problems to the design is capturing the changes between the original inventory scan and the point at which the implementation is ready to start. After the first scan has been completed, you should make support staff aware that all further changes need to be recorded and the updates noted in the inventory.

This inventory will be critical for planning and implementing IPsec policies, which subsequent chapters discuss.

Top of page

Capacity Considerations

After information-gathering is complete, the impact of IPsec (including some capacity planning) will be your next area of focus. This section describes some of the essential aspects of properly planning for IPsec in your environment.

Impact of IPsec

Because IPsec uses various cryptographic techniques, it can consume significant overhead on a computer. The scenarios that require closer analysis will be those that require encryption. For example, one might use the Triple Data Encryption Standard (3DES) and Secure Hash Algorithm (SHA-1) to check integrity in situations that require the strongest available encryption and key exchange protection. Another scenario involves security association (SA) negotiation. You could use a shorter lifetime for the main mode SA such as three hours, but as with many security considerations you should expect to have to make tradeoffs. Each main mode SA occupies approximately 5 KB of RAM. A situation in which a server is expected to broker tens of thousands of concurrent connections could lead to overutilization. Other factors include CPU utilization on network infrastructure servers, increased overhead on servers and workstations running IPsec (especially servers, because they will contain more main mode SAs than clients in most cases), and increased network latency as a result of IPsec negotiation.

Note   In Microsoft's own deployment of this solution it was found that it is normal to expect a one to three percent increase in utilization on your network as a direct result of using IPsec.

Another primary concern is networks that are connected with an NAT device between them. The problem is that NAT does not allow Authentication Header (AH) conversations between hosts, because NAT violates the very principle that AH is designed to provide: the authentication of an unchanged packet, including the header. If NAT devices exist on the internal network, ESP would need to be selected instead of AH. ESP provides for the ability to encrypt data, but does not require encryption. This factor is important from a capacity consideration perspective because encryption has overhead that must taken into account during the planning and design phases of the project. ESP can also be implemented with null encryption, which provides the strongest IPsec peer-to-peer communication possible without breaking communications with NAT. And because it does not use encryption, it would have a lower impact than ESP with encryption.

Impact of Policy

IPsec policy and Group Policy will both have an impact on computers' startup times as well as the time that it takes for users to log on. While you are in the information gathering phase, it is useful to note the computer startup times and logon times of users before implementing the solution. Recording these times here will provide a baseline to which you can compare the test systems during the pilot to determine the impact on the overall time that it will take for a user to be logged on.

Top of page

Predeployment Concerns

The preceding sections described information that you should gather from the network, Active Directory, and the hosts to help make an isolation effort succeed. This section lists areas of concern that you should examine closely before deploying IPsec.

Network Infrastructure

Information gathering enables you to plan for IPsec isolation in a network. After gathering this information, careful analysis of the data will reveal most of the problems that you will face during pilot and deployment. Although the following items do not comprise a comprehensive list, they are important to consider when beginning your analysis of gathered information prior to testing and deployment.

Overused Devices

You might need to upgrade or reconfigure switches or routers that currently exceed 75 percent utilization to allow for increased traffic on the device and still provide some extra utilization for bursts of traffic. Proper capacity planning for the implementation of IPsec is more about testing and anticipated traffic loads than exact calculations. Because it is extremely unlikely that the scenario, traffic patterns, user concentrations, and applications are exactly the same for any two customers, proper planning and considerations for how network devices will be affected is imperative. For example, certain aspects of IPsec are completely predictable. Each packet using IPsec with ESP will be exactly 36 bytes larger than the same packet that does not use IPsec. Because there are six messages required to establish a single main-mode SA, it is easier to account for how utilization might be affected on a particular device. You can use tools such as the Tivoli Switch Analyzer from IBM or other network analyzer solutions to assist in capacity planning for IPsec in your IT environment.

Incompatible Devices

Devices that are not compatible with IPsec cannot participate in IPsec communications. If such devices need to communicate with a managed device, you should place them in the IPsec exemption list. One alternative is to either upgrade device hardware or software to support IPsec. Another alternative is to allow those unmanaged devices to communicate with boundary computers when they fall back to clear for their outbound communications.

Devices Configured Incorrectly

Incorrectly configured devices can increase the possibility of failed communications and increased load on the device, and they can even lead to compromised devices. Following best practices for configuration, administration, and security of the devices will help alleviate this concern.

IP Addressing

Because IP addresses are the fundamental building block of an IPsec solution, it is important that the addressing be as "clean" as possible. Things such as overlapping address spaces, duplicate addresses, incorrect subnet masks, and other problems can complicate normal network operations. Adding IPsec to such a network will only complicate troubleshooting and cause people to suspect IPsec as the source of the problems. Organizational growth, mergers and acquisitions, and other factors can quickly lead to an outdated and inaccurate picture of IP addressing on a network. To eliminate the biggest issues with IPsec, ensure that the network is divided into subnets that do not overlap, the route tables are nicely summarized, and address aggregation is easily determined.

Active Directory Information

If the current Active Directory implementation is functioning properly (that is, name resolution, Dynamic Host Configuration Protocol [DHCP], application of Group Policy, trust relationships, and so on), nothing should affect IPsec. You should scrutinize any changes made between the time Active Directory was examined and the time that the isolation project begins to ensure that you will not encounter any compatibility problems.

Host Information

The previous sections have helped you gather sufficient information about the hosts on your network. After you determine which clients and servers are able to use IPsec, note how you need to isolate them and what applications you need to closely examine for the impact that the isolation solution may have on them.

Determining Client/Server Participation

After gathering information about the hosts, it is relatively straightforward to determine which hosts would be eligible for integration into the isolation solution. For example, only Windows 2000-, Windows Server 2003-, and Windows XP-based computers can communicate with IPsec. However, perhaps not all of the clients that can participate should do so. An important part of the design process is to determine from the information gathered in this chapter which computers and devices will be included in the solution and in which group they will reside.

Determining Services That Need to Be Isolated

In the context of the server and domain isolation project, a service is an application, such as Microsoft Exchange Server, Microsoft SQL Server™, or Internet Information Services (IIS) that provides its services to clients on the network. You should evaluate these services individually to determine whether they are candidates for server and domain isolation. There are a number of reasons why these services may have to be included in the solution, such as organizational policy, government regulation, or other business requirements. For example, there may be an organizational policy that dictates that all communications between mail servers must be secured by using IPsec, but the communications between clients and servers do not need to be secured in this manner. Chapter 4, "Designing and Planning Isolation Groups," discusses the isolation process in greater detail. When attempting to isolate services, carefully consider those servers that operate multiple services, such as a file server that provides Web services and File Transfer Protocol (FTP) and is also a mail server.

Network Load Balancing and Clustering

Organizations that are using server and domain isolation may choose to exempt computers that use Network Load Balancing (NLB) and clustering. IPsec is not compatible with NLB in "no affinity" mode because IPsec prevents different computers from using the same client connection. Because of this incompatibility, you should not attempt to use NLB in "no affinity" mode with IPsec.

Managing Exceptions

Managing exceptions is an important part of IPsec planning. Determining where to use computers that will allow access from untrusted hosts and controlling access between managed and unmanaged computers is a crucial element of isolation. It is considered a best practice to keep the number of exceptions to the minimum number possible. Technical needs may dictate that some computers or services are exempted from IPsec, such as domain controllers and DHCP, DNS, and WINS servers. Because these computers should still be managed, the potential risk is lower than allowing unmanaged computers to communicate with managed, trusted computers.

Non-Windows-Based Devices

Most enterprise networks are not homogenous. You must account for diversity of elements such as operating systems, network infrastructure, and hardware platforms when planning an IPsec deployment. If your organization has non-Windows-based computers, you should understand that the consumption of IPsec policy outside of the Windows realm is not currently possible. An organization might decide to address this limitation by treating some platforms as trusted, but because these platforms cannot consume IPsec policy, the server and domain isolation solution will not protect them. The following section addresses how to determine trust.

Management and Monitoring Devices

One aspect of IPsec that is often overlooked during initial planning is its impact on management and monitoring of traffic on the network. Because IPsec requires authentication and can allow for encryption, some devices will no longer be able to monitor or manage IPsec enabled computers. In cases where encryption is required, an organization is asserting that security is more important than the operational need to monitor the data as it transits the network. In other cases, it will be necessary to evaluate what changes you can make to an application or device to enable IPsec monitoring (such as an ESP parser that can look at ESP traffic). If it is not possible to upgrade monitoring or management devices to support IPsec, it is vital that you record this information. The solution architect or architecture team will need to use this information in Chapter 4 "Designing and Planning Isolation Groups."

Top of page

Trust Determination

After obtaining information about the host devices that are currently part of your IT infrastructure, you must make a fundamental determination that will directly affect the ability of a host to participate in the solution. This determination is to decide at what point a host can be considered trusted. The term trusted can mean many different things to different people, so it is important to communicate a firm definition for it to all stakeholders in the project. Failure to do so can lead to problems with the security of the trusted environment, because the overall security cannot exceed the level of security set by the least secure client that is allowed to achieve trusted status.

To understand this concept, consider the four basic states that are applicable to hosts in a typical IT infrastructure. These states are (in order of risk, lowest risk first):

The remainder of this section defines these states and how to determine which hosts in your organization belong in which states.

Trusted State

Classifying a host as trusted does not imply that the host is perfectly secure or invulnerable. Fundamentally, trusted implies that the host's security risks are managed. The responsibility for this managed state falls to the IT administrators and users who are responsible for the configuration of the host. A trusted host that is poorly managed will likely become a point of weakness for the entire solution.

When a host is considered trusted, other trusted hosts should be able to reasonably assume that the host will not initiate a malicious act. For example, trusted hosts should expect that other trusted hosts will not execute a virus that attacks them, because all trusted hosts are required to use mechanisms (such as antivirus software) to mitigate the threat of viruses.

Communication between trusted hosts should not be obstructed by the network infrastructure. For example, because a trusted host can assume that other trusted hosts have no malicious intent, the blocking of IP-level packets to restrict access by other trusted hosts is not generally required. You should implement any restrictions that are needed to control host communications by port or protocol by using a host-based firewall on the computer itself, not by using IPsec.

In the Woodgrove Bank scenario, the security team defined the following five key goals that were used to plan what technologies would be required by a host to allow it to achieve trusted status:

The support team at Woodgrove Bank used these goals to define a set of technology requirements to determine whether a host could be considered trusted.

When defining the trusted status, ensure that asset owners are free to impose additional security requirements to meet the business needs of a specific asset. For example, your HR department may require an additional biometric logon mechanism for specific servers. This requirement will have no bearing on the ability of the servers to be trusted in the context of this solution. However, you should take care to ensure that the requirements of a specific asset do not conflict with the requirements of the trusted status.

Spend some time defining the goals and technology requirements that your organization would consider suitable as the minimum configuration for a host to obtain trusted status.

For example, the design team used the following list of technology requirements in the Woodgrove Bank scenario:

It is important to understand that the trusted state is not constant; it is a transitive state that is subject to changing security standards and compliance with those standards. New threats and new defenses emerge constantly. For this reason, it is imperative that the organization's management systems continually check the trusted hosts to ensure ongoing compliance. Additionally, these systems should be capable of issuing updates or configuration changes if required to help maintain the trusted status.

A host that continues to meet all these security requirements can be considered trusted. However it is very likely that most host computers that were identified in the discovery process discussed earlier in this chapter will not currently meet these requirements. Therefore, it is important to identify which hosts can become trusted and which ones cannot (and therefore must be considered untrusted). To help with this process, you can define an intermediate trustworthy state. The remainder of this section discusses the different states and their implications.

Trustworthy State

It is useful to identify as soon as possible those hosts in your current infrastructure that will be able to achieve a trusted state, if necessary. A trustworthy state can be assigned to indicate that the current host is physically capable of achieving the trusted state with required software and configuration changes.

For each computer that is assigned a trustworthy status, you should make an accompanying configuration note that records what would be required to allow the host to achieve trusted status. This information is especially important to both the project design team (to estimate the costs of adding the host to the solution) and the support staff (to enable them to apply the required configuration).

Generally, trustworthy hosts will fall into one of the following two groups:

Use these groups to assign costs for implementing the solution on the computers that require upgrades.

Known, Untrusted State

During the process of categorizing an organization's hosts, you will identify some hosts that cannot achieve trusted status for certain well-understood and well-defined reasons. These reasons may include the following types:

There can be a number of functional reasons for a host to remain in the known untrusted state. The following list includes a few examples of functional reasons that may lead to a classification of this state:

In addition, Windows NT does not support all of the required security capabilities. For example, it does not support Group Policy or IPsec policies or provide a mechanism that ensures that local Administrator-level access can be obtained if needed. Also, its security configurations are not reapplied on a regular basis to ensure that they remain in effect.

Note   The discussion of Windows NT being untrustworthy is strictly in relation to the implementation of server and domain isolation and is not a reflection on its use as an operating system at large. For the servers in this project, upgrading to the Windows Server 2003 platform presents the most secure and manageable solution.

However, if the host has to be accounted for in the design because it provides a required role for the organization, you should assign it a status of known, untrusted. What this means is that a risk has been identified that the solution cannot mitigate. You must use additional techniques to mitigate this known threat. Because of the varied nature of hosts in this category, specific guidance on these techniques cannot be provided. However, the goal of these mitigation techniques should be to minimize the risk posed by this host.  

Unknown, Untrusted State

The unknown, untrusted state should be considered the default state for all hosts. Because hosts in this state have a configuration that is unknown, you can assign no trust to them. All planning for hosts in this state should assume that the host has been or is capable of being compromised and is therefore an unacceptable risk to the organization. Designers of the solution should strive to minimize the impact that the computers in this state can have on their organizations.

Top of page

Capturing Upgrade Costs for Current Hosts

The final step in this chapter is the process of recording the approximate cost of upgrading the computers to a point that they are capable of participating in the solution. You must make several key decisions during the design phase of the project that require answers to the following questions:

By answering these questions, you can quickly determine the level of effort and approximate cost of bringing a particular host or group of hosts into the scope of the project. It is very likely that no single person—or even several people within one role—will gather all of this data. Some of it may be gathered by help desk or field service technicians, whereas other data will need an architect or business sponsor-level input. It is important to remember that the state of a computer is transitive, and that by performing the listed remedial actions you can change the state of a computer from untrusted to trusted. After you decide whether to place a computer in a trusted state, you are ready to begin planning and designing the isolation groups, which Chapter 4, "Designing and Planning Isolation Groups" in this guide discusses.

The following table is an example of a data sheet that you could use to help capture the current state of a host and what would be required for the host to achieve a trusted state.

Table 3.3  Sample Host Collection Data

The following list explains each column from Table 3.3:

In the previous table, the host HOST-NYC-001 is currently "known, untrusted." However, it could be considered trustworthy if the required upgrades are possible. However, if a large number of computers require the same upgrades, the overall cost of the solution would be considerably higher.

The host SERVER-LON-001 meets the hardware requirements but needs to be upgraded to an operating system that is capable of consuming IPsec policy and is domain-joined. It also requires antivirus software. The projected cost is the amount of effort that is required to upgrade the operating system and install antivirus software combined with the cost of the operating system and antivirus software licenses.

After obtaining the information described in Table 3.3, save it with the other information that you have gathered in this chapter so that it the architect or architecture team can use it. This information will be the foundation of the efforts undertaken in Chapter 4, which focuses on designing the isolation groups.

It should be noted that the costs identified in this section only capture the projected cost of the host upgrades. There are many additional design, support, test, and training costs that will be associated with the project. These additional costs will need to be accounted for in the overall project plan if an accurate project cost is to be identified.

Top of page

Summary

This chapter provided an overview of the information that is required to conduct a server and domain isolation project, including impact considerations. You can use the guidance in this chapter to perform the following tasks:

Accomplishment of these tasks will gather all of the information that you need to begin the isolation group design in the following chapter.

More Information

This section provides links to areas of additional information that may prove helpful in implementing this solution:

Top of page

4 of 14