Server and Domain Isolation Using IPsec and Group Policy

This chapter provides guidance to help manage a server and domain isolation solution after successful deployment into a production environment.

It is important for support staff to understand that the isolation solution adds an additional layer of security, and that more than a network connection and an IP address are needed for a host to successfully connect to a resource. Similarly, the staff that is responsible for IPsec policies and Group Policy must understand that a single, incorrectly-set option can significantly restrict the functionality of hosts that consume the policies. For these reasons, a well-documented and well-communicated set of management processes and procedures should be in place for the support teams to use after the solution becomes operational.

The information provided in this chapter is designed to help you develop these solution management processes. Ideally, the information here should be customized as much as possible to reflect the needs of your own implementation. The key to success in managing a server and domain isolation solution is to plan ahead.

On This Page

	Chapter Prerequisites
	Change Management
	Backup/Restore Considerations
	Mitigation of Network-Based Infections
	Summary

Chapter Prerequisites

Before you use the information provided in this chapter, you should be familiar with the concepts used in the Microsoft® Operations Framework (MOF) and the concepts of IPsec. Familiarity with Microsoft Windows® 2000 Server (or later) is also required in the following areas:

Before proceeding with this chapter, you should read the rest of this guide and have a thorough understanding of the architecture and design of the solution.

Top of page

Change Management

A key goal of change management processes is to ensure that all parties affected by an impending change are aware of and understand the impact of the change. Because most systems are heavily interrelated, any changes made in one part of a system may have profound impacts on another. To mitigate or eliminate any adverse effects, change management attempts to identify all affected systems and processes before the change is deployed. Typically, the target (or managed) environment is the production environment, but it should also include key integration, testing, and staging environments.

All changes to an IPsec environment should follow the standard MOF change management process:

The following section outlines the change development procedures for some of the key changes that will likely be required on a regular basis in your IPsec environment. Each change development procedure will have a companion change release procedure that describes how to deploy the change into production.

Changing IPsec Policy

It is important to understand how changes in IPsec policy will affect communication. As in the initial rollout, the first concern is with the timing of the changes, because this timing affects the ability to implement a change and the timeframe for rolling back the change.

Policy Application Delays

When the assignment of IPsec policy in a Group Policy object (GPO) is changed to a new IPsec policy, certain delays occur. There is the Active Directory replication delay of the GPO attribute that contains the assignment in the domain, and also the polling delay of domain member Group Policy clients to detect the change in the GPO. These delays can range from less than a minute in a small location to a matter of hours in a global enterprise. Microsoft recommends that you test and document these delays (minimum, maximum, and median) for your particular environment so that when a change is introduced, the time required for the first impact and the complete rollout can be predicted.

When the contents of an already assigned IPsec policy are changed, similar delays occur. There is an Active Directory replication delay of the IPsec policy objects, and also the polling delay of the IPsec policy service on the member computers. It is possible to create a condition where the replication of the policy assignment in the GPO happens before the replication of the IPsec policy, which would cause clients to behave as if they have a domain-based IPsec policy assigned—but they would not to be able to retrieve that policy. In such a case, Windows 2000 and Windows XP hosts will simply fail to apply the domain-based policy. Also, they will not apply any local policy that might be assigned.

To properly accommodate Active Directory replication delays, ensure that you first create all the objects (GPO, IPsec policy, and so on) and then make the assignment of IPsec policy into the GPO.

Changes That Affect IPsec Connectivity

There are many areas that can affect connectivity within the policies and groups that make up an IPsec solution. This section provides information on how common changes can affect IPsec connectivity from the perspective of changing a server policy when clients may not have the latest update. If a change causes Internet Key Exchange (IKE) main mode or quick mode to fail, then traffic flow will stop as soon as the current IPsec security associations (SAs) idle or their lifetime in bytes or in seconds expires.

This discussion covers the impact of most types of changes on IPsec client-server functionality. It does not assume the Woodgrove Bank IPsec policy designs. For this discussion, clients may have policy that is similar to the Woodgrove Bank design (in which the clients have filters to initiate IKE to the server), or they may use only the default response rule (which is not used in Woodgrove's design).

Main Mode Changes

Changing an authentication method or main mode security method will cause the IKE to delete the existing main modes, which will not affect established quick mode IPsec SAs. The new main mode SAs will be generated when the next quick mode rekey occurs.

Generally, server policy change will not affect the ability of existing clients to rekey main mode. However, some changes on the server side that can cause IKE main mode negotiation with clients to fail include:

The following server policy changes will not affect a client's ability to rekey main mode SAs:

Quick Mode Changes

Any change in a filter action that was being used for an IPsec SA will cause the existing IPsec SAs that were established under those policy settings to be deleted. Therefore, a new quick mode will be attempted if traffic is flowing. Some traffic may be lost in the process of this change, but TCP connections should recover. However, for high-speed data transfers, the impact of an immediate IPsec SA deletion is that outbound traffic will be dropped until the new quick mode can be established. For example a burst of packets from a video data stream, which TCP could not recover from, will cause the connection to reset for the video application.

Server policy changes that will affect the ability of active IPsec clients to rekey quick mode include the following:

The following server policy changes will not affect a client's ability to rekey quick mode:

IPsec Policy Change Procedures

The following sections provide steps for modifying IPsec policies that are delivered by using GPOs. Although the steps presented for each task use the IP Security Policy Microsoft Management Console (MMC) snap-in, each of these tasks can also be accomplished by using the Netsh command-line tool on a Windows Server 2003 system.

Microsoft recommends the Windows Server 2003 platform as a policy management station because it provides the best capabilities exist for scripting and for monitoring.

Windows IPsec policy export and import is designed for backup and restore purposes. The export function copies all IPsec policy objects in the storage location to ensure that all related objects are captured in the backup. Export is the recommended method to move all of the current domain policy into local storage for testing. Because of the chance for errors, be careful to delete every unwanted object (including policies, filter lists, and filter actions) from a local store before using the export function. Microsoft does not recommend the use of an exported local store to import into the domain because of the possibility that old object versions could overwrite more recent domain versions and break links between the objects.

Command line scripts are the recommended method for creating IPsec policy and making significant additions to existing objects, such as adding filters to an existing filter list. Generally, such significant changes in an IPsec policy should be done through creation of a new IPsec policy version.

After the policy is created, you can use either scripts or the IPsec Policy Management MMC snap-in to make changes. After IPsec policy has been created and is operational, the IPsec Policy Management MMC snap-in is recommended to make small changes.

Because the Windows 2000 command-line tool Ipsecpol.exe only supports the ability to create policy, the MMC snap-in can be used to manage changes in Windows 2000 Active Directory. The addition of a new object with the same name is not allowed in Netsh add commands. For this reason and because scripts are often run many times, Netsh scripts should include initial steps that delete policy objects that already exist before new ones are added. Deletion of a nonexistent object will return an expected error message that will not stop the script from executing.

Deletion of a domain IPsec policy that is already assigned to a GPO will invalidate the GPO link. The GPO must be edited to re-assign the latest version of the IPsec policy.

Note   Although the following section discusses how to modify IPsec policies directly in Active Directory, it is assumed that any changes have been tested on a local system or test environment before deployment in a production environment.

Changing IPsec Policy Assignment for an Isolation Group

To change the IPsec policy assigned to an isolation group, you can replace the current IPsec policy with the new IPsec policy.

The Group Policy Management Console (GPMC) is used to change the IPsec policy that a particular GPO is distributing. After identifying the new IPsec policy and the GPO that distributes the current policy, complete the following steps.

To change the IPsec policy assigned to an isolation group

Changing an Existing IPsec Policy in the Domain

Because the functionality of IPsec was extended in Windows XP and then again in Windows Server 2003, the IPsec policy storage format has been changed to include the settings for these extensions. Be careful not to use an IPsec Policy Management MMC snap-in from an earlier release to view or edit policy that contains these extensions. If you click OK when viewing a policy component, you will overwrite the existing settings with settings in current memory even if you made no changes. Updates were made in Windows XP service packs and Windows 2000 Service Pack 4 (SP4) to detect newer versions of policy to help avoid this potential problem. However, the MMC snap-in simply fails to save changes as if modify access was denied and use the error messages that existed at the time the product was released. Similarly, if the user running the MMC snap-in only has read permission to the IPsec policy objects, then any changes will be lost when an access denied error occurs. Use the read-only mode of the IPsec Policy Management MMC snap-in in Windows Server 2003 whenever you do not intend to make changes. Finally, the MMC snap-in does not provide the ability to enter a different user ID and password when connecting to a remote computer or domain. The user must be logged on to the desktop as someone with appropriate permissions to make the intended changes.

Changing an Existing Rule Filter List

There are times when it is necessary to modify an existing rule filter list to add, remove, or modify a filter item. You can use the IP Security Policy Management MMC snap-in to perform this modification. Remember that the order of a filter in a filter list has no effect on the order in which the IPsec driver will process packets. The filters for all filter lists in all rules of an IPsec policy are ordered by using an internal algorithm for weighting. To make a change, you must manually ensure that you are not creating a duplicate filter for any other filter used in the IPsec policy. As part of the change testing process, the policy should be assigned locally on a computer so that the IPsec Monitor MMC snap-in or command line output can be used to view the exact filter ordering and detect duplicate filters.

To add a computer to a filter list

Note   After the new system is added to an exemptions filter list, the computer account should be added to the No IPsec security group.

To edit a computer entry in a filter list

To remove an entry from a filter list

Note   After the system is removed from an exemptions filter list, the computer account should be removed from the No IPsec security group.

Changing an Existing Rule Filter Action

Each rule in an IPsec policy has a corresponding filter action that is performed when the rule is matched. Although it is possible to assign a new IPsec policy to the computers that have the new rule and filter action combination, it may make more sense instead to change the filter action for a rule in an IPsec policy that already exists. For example, if a custom IPsec policy exists for a set of computers, it would make sense to change the filter action assigned to the rule rather than generate a new IPsec policy.

You can use the IP Security Policy Management MMC snap-in to configure a rule in an IPsec policy to use a new filter action.

To change an existing rule filter action

Changing an Existing Rule Authentication Method

The default authentication method in IPsec policies uses the Kerberos version 5 protocol. Over time it may become necessary to change an authentication method that is associated with an existing rule. For example, a public key infrastructure (PKI) could be rolled out so that certificates can be used to authenticate computers.

Although different information is needed for each authentication method that can be chosen, the general steps for adding an authentication method are similar. For example, to use a preshared key you must identify the key, and to use certificates the certificate authority (CA) must be known. To add a new authentication option to an existing IPsec rule, complete the following steps.

To add an option to an existing rule

Adding a New Rule to an Existing IPsec Policy

New rules are added to IPsec policies that already exist to further restrict or allow communication to occur between computers in the environment. For example, if an IPsec-capable system needs to communicate with systems in a particular isolation group but does not get its policy from the IPsec infrastructure, you can make changes to the isolation group policy to allow the communication.

In this example, the non-managed IPsec host would need to have a policy applied to it that allows the communication to occur. Furthermore, a shared authentication method must be decided upon; either certificates or a preshared key could be used. A new rule could be created in the existing IPsec policy for the isolation group to allow the traffic to occur after the appropriate authentication method was agreed upon.

The necessary steps would be to create a new filter list in the directory, associate the new filter list with the existing policy, and then configure the authentication mechanism to include the new authentication method that is chosen.

To create a new filter list to allow all traffic to occur to a specific computer

To modify an IPsec policy to use a new filter list and filter action

Moving Hosts Between Isolation Groups

For various reasons, hosts will periodically need to be moved from one group to another. It is important to understand the implications of changes to group membership in terms of traffic communications. The following sections describe the steps for adding or removing hosts from groups.

Adding or Removing a Host in the Exemption List

You can add a host to or remove a host from the Exemption List by modifying the IPsec exemption filter lists and the No IPsec security group. To do so, follow the steps in the "Changing an Existing Rule Filter List" section earlier in this chapter.

The exemption filter list, the host's name, and its IP address must be known to complete this task.

Adding or Removing Hosts and Users in Existing Groups

When you add a host to or remove a host from a network access group (NAG), the steps are specific to the role the host plays in the group. If the host acts only as an initiator, it is sufficient to either add or remove it from the associated NAG. However, if the host acts as a responder, the policy that controls the update of the "Access this computer from the network" right must either be applied or removed. If the system acts as both an initiator and responder, both steps must be taken.

Adding or Removing Initiators in an Existing Network Access Group

You can add or remove an initiator in a network access group by using standard group management tools to modify the associated security group.

To modify a NAG relative to a specific computer

Adding or Removing Users in an Existing Network Access Group

Although isolation groups were created to restrict which hosts can initiate communication to the restricted resource, they can also be used to help restrict which users have access to a resource. If there is no requirement to restrict a resource in a manner that is similar to a NAG, then the Domain Users group is granted the "Access this computer from the network" right on the responders. If there is a requirement to restrict a resource, then a NAG Users group is created.

You can add or remove a restricted user from a NAG Users group by using standard group management tools to modify the associated security group. This procedure is only required if a NAG Users group has been created and assigned to the NAG; if the Domain Users group is being used, then this procedure is not necessary.

To modify a NAG Users group relative to a specific user

Adding or Removing Responders in an Existing Network Access Group

To remove a responding host (the responder) from an existing NAG, you can remove the GPO assignment that configures the "Access this computer from the network" right on the responder. The GPO application can be controlled through any of the standard means of ensuring policy application with Active Directory. However, the approach used in this guide assigned the GPO to an organizational unit (OU) that was created to hold the domain computer accounts of responders. Simply moving the computer account out of the responders OU will cause it to no longer receive the assigned GPO, and access will no longer be restricted. The computer would revert to the Isolation Domain policy. (If the computer account was also a member of a domain local security group that consisted of network access groups, then it must also be removed from that group.)

Care should be taken to ensure that hosts that are members of multiple NAGs are still able to communicate with other NAGs after they are removed from one of the NAGs.

Adding New Network Access Groups

Creation of a new NAG is a fairly straightforward process. First, you must create a domain local group to control the access to the resource and a GPO to update the "Access this computer from the network" right on the hosts that act as servers in the NAG. Then you must apply that GPO to the servers, and identify the hosts that belong in the group.

Only initiators need to be members of the NAG. In other words, if two servers are in the same isolation group and will never initiate communications to each other, they do not need to be added to the NAG for their isolation group. However if these two servers need to communicate, they will need to be added to the NAG like all other initiators.

If a server acts as a responder within multiple NAGs, care must be taken to ensure that after the GPO is applied, all NAG security groups in which the server participates are present on that system's "Access this computer from the network" right. If necessary, additional GPOs may be required so that specific computers meet this need.

Creating a New Network Access Group for Initiator Computers

Complete the following steps to create a new NAG.

To create a new NAG for initiator computers

Adding Initiator Computer Accounts to a Network Access Group

Complete the following steps to populate a new NAG with initiator accounts.

To populate the new NAG for initiators with the initiator accounts

If there is a requirement to further restrict which users in the domain are allowed to access the restricted resource, a group for the restricted NAG users must be created. Otherwise, the Domain Users group can be used instead.

Creating a New Network Access Group for Restricted Users

Complete the following steps to create a NAG for restricted users.

To create a new NAG for user accounts

Adding Restricted User Accounts to a Network Access Group

Complete the following steps to populate a new NAG with restricted users.

To populate the new NAG with user accounts

Creating a GPO to Grant the "Access This Computer from the Network" Right

A GPO is used to assign the "Access this computer from the network" right to the appropriate NAGs.

The following table provides an example of a GPO implementing a NAG and the associated group names that need to be granted the "Access this computer from the network" right.

Table 6.1  Example NAG Policy Definition

Note   The listed groups are the minimum that should be added. The administrator will need to determine whether there are any additional groups that should be granted this right.

The Domain Users group is added as a default. If the administrator also wishes to restrict users as well as computers, a NAG Users group will need to be created like the one for computer accounts that contains the selected user accounts.

To create a GPO to grant the Access this computer from the network right

Deploying Network Access Group GPOs

To deploy NAG GPOs, they first need to be linked to a location within the domain environment so that they can be applied to the appropriate responders within the NAG. The GPO application can be controlled through any of the standard methods for ensuring policy application with Active Directory. It is beyond the scope of this guidance to provide specific steps, because they would be dependent on the OU structure and management methods employed within the organization.

Disabling IPsec in an Isolation Group

You can disable an IPsec policy by modifying the GPO that delivers the policy. To disable the IPsec policy, the GPO is configured so that the computer settings are disabled.

To disable the computer settings of the GPO

Re-Enabling IPsec in an Isolation Group

You can re-enable IPsec policies that have been disabled by modifying the GPO that delivers the policy. To re-enable a disabled IPsec policy, the GPO is configured so that the computer settings are enabled.

To enable the computer settings of the GPO

Removing IPsec from an Isolation group

You can remove an IPsec policy by modifying the GPO that delivers the policy. To remove the IPsec policy, the GPO is configured so that the IPsec policy is no longer assigned.

To unassign the IPsec policy of the GPO

Top of page

Backup/Restore Considerations

This section provides information about how to evaluate the processes that specifically deal with backup and restoration of the server and domain isolation solution components.

Active Directory Backup

IPsec policies are not stored in the Group Policy objects that are used to deliver the policies. Group Policy backup and restore capabilities will only capture information about which IPsec policies are assigned to Group Policy objects, not the actual IPsec policy information.

Although a full System State backup of a domain controller will capture the IPsec policy information, it is also possible to use the IP Security Policy Management MMC snap-in's Export Policies and Import Policies menu commands to back up and restore IPsec policies.

Note   It is important to secure your IPsec policy backups. However, the backup is a file that inherits the NTFS file system permissions of the directory in which it is stored, and the data in the file is not encrypted or signed. You should protect the IPsec configuration information in these files by using appropriate permissions or security procedures. Only authorized IPsec administrators should have access to these backup files.

For more information about backing up System State data on a computer running Windows Server 2003, see the Back up System State data page.

Host Restoration

On computers for which IPsec policy has been restored from backup (either a tape backup or an image-based backup), the IPsec policy that is applied might be a cached copy of the Active Directory-based IPsec policy or a local IPsec policy.

If the computer is assigned Active Directory-based IPsec policy, the IPsec service attempts to retrieve the latest copy of the assigned IPsec policy from Active Directory before it applies the cached copy of the Active Directory-based policy. When doing so, the IPsec service first queries Domain Name System (DNS) for the current list of the IP addresses of all of the domain controllers. If the IPsec policy objects have been deleted from Active Directory, the cached copy of the Active Directory-based policy is applied instead.

The list of domain controller IP addresses in the cached copy of the Active Directory-based IPsec policy might have changed substantially since the IPsec policy backup was created (for example, if new domain controllers were added). If so, communication might be blocked with current domain controllers—and therefore authentication that used the Kerberos protocol will fail when attempts are made to establish IPsec-secured connections remotely. In addition, the computer might not be able to receive Group Policy updates. This problem can be resolved as follows:

Top of page

Mitigation of Network-Based Infections

Some circumstances may require rapid disruption of communications to ensure the security of the environment, such as when a virus outbreak or security intrusion occurs. The following sections discuss various ways to isolate hosts that participate in authenticated communications. By design, these methods do not isolate the infrastructure or exempted servers, because care must be taken not to isolate the infrastructure servers so that the systems do not lose the ability to update their IPsec policies from the domain.

Note   Although these methods of isolation are technically sound, they have not been tested in a lab environment. It is strongly suggested that you test these methods in a lab environment before relying on them.

Isolating the Isolation Domain

Hosts in the isolation domain are allowed to initiate communications with untrusted hosts. If there is a need to quickly block this type of traffic, the IPSEC – Secure Request Mode (Ignore Inbound, Allow Outbound) filter action can be modified so that the "Allow unsecured communication with non-IPsec-aware computers" right is disabled. After the IPsec polling period has elapsed, all hosts in the isolation domain should be blocked from communicating with systems that are not participating in the IPsec environment.

To modify the IPSEC – Secure Request Mode (Ignore Inbound, Allow Outbound) filter action

After this option has been set, the policy will block all network traffic that is destined for untrusted hosts. After the issue has been resolved, the communication can be restored by re-enabling the option.

Blocking Ports

IPsec policies that are deployed to internal organizational local area network (LAN) computers are configured to allow all communication across all ports. This approach simplifies the configuration and management of the environment. However, if a host using IPsec becomes infected with malware such as a virus or worm, the host will likely spread the infection to other computers. Depending on the policies the computer is using, the infection could spread to both trusted and untrusted hosts.

IPsec policies can be used to help reduce the spread of malware by explicitly blocking the ports that malware uses. The main limitation to this approach is the delay required for all computers to detect the policy change that adds the blocking filters. In addition, some worms have flooded the network and made it difficult for IPsec policy changes to be retrieved. And some worms have used ports that are also used by critical services such as DNS, which would make it difficult to update the policy after blocking filters were applied on the host. Blocking can be accomplished by creating a rule that blocks traffic from any IP address to the specific port that a certain form of malware uses. This rule is added to all policies in the environment. After the malware is removed, the rule can be removed from the policies.

After you identify the ports and protocols that a certain form of malware uses, create a filter list that matches the criteria of the malware communication by following the steps in the "Adding a new rule to an existing IPsec policy" procedure in the "Changing IPsec Policy" section earlier in this chapter. The IPsec policy polling interval should be reduced right away as soon as the decision is made to use port blocking in domain policy. The polling interval can be increased again once the threat has subsided.

However, instead of creating a filter that uses any IP address to a specific IP address, create a filter that uses "My IP Address" to any IP address. Typically, mirrored filters are not used. A filter list that contains two one-way filters is required, one for inbound to a well known port and one for outbound traffic to a well known port. For example, the following filters block the SQL port 1433 exploited by the SQLSlammer worm:

From Any IP Address -> My IP address, TCP, src *, dst 1433, not mirrored

From My IP Address -> Any IP address, TCP, src *, dst 1433, not mirrored

Clearly, these filters will also block the SQL application connections and would be removed when the worm threat had subsided. Use caution not to block access to critical infrastructure ports such as DNS unless absolutely necessary. These filters are more specific than the Woodgrove Bank subnet filters that negotiate IPsec for all traffic on the internal network because they have a specific IP address defined.

After the filter is created, add a rule to all isolation domain and group IPsec policies to associate the filter list with the IPsec – Block filter action. You may want to include in your policy design a rule that already associates an empty IPsec Filter List used for blocked ports with the block action. This empty filter list could be used by rules in all IPsec policies and enabled so that all domain members will check this filter list on each polling interval. Or the rule could be disabled, and the IPsec service polling would detect when the rule is enabled in each isolation group policy.

If for some reason the port blocking prevents IPsec from accessing Active Directory to obtain an updated policy, then the IPsec service can be administratively stopped and restarted on the computer, or the computer can be restarted. When the IPsec service starts, it will attempt to download the latest version of the assigned IPsec policy before applying the older version in the cache.

Isolation to Within Child Domain Only

If an entire domain needs to be isolated from the rest of the domains in the forest, the policy for that domain can be configured to use a preshared key rather than the Kerberos protocol. This approach will allow computers within the child domain to maintain communications with other systems in the same domain, but it will block communication with systems outside of the domain to which they usually would have access.

Each policy in the child domain would need to be modified so that it used only a preshared key for the IPsec – Secure Organization Subnets rule. Any existing authentication methods, such as the Kerberos protocol, will need to be removed. To configure the authentication methods, follow the steps in the "Changing an Existing Rule Authentication Method" section earlier in this chapter.

If additional rules that perform authentication exist in the policy, they will also need to be configured to use a preshared key. All policies in the child domain that is to be isolated will need to be configured in this way. To minimize the chance of IKE main mode authentication failures as the policy is rolled out, the preshared key authentication method can be ordered first in the authentication method list, followed by the Kerberos method. After all computers have the updated policy, the Kerberos authentication method can be removed. A similar process is used to restore authentication for the Kerberos protocol and remove the preshared key after the threat has subsided.

Isolation to Predefined Groups

Although network access groups are one implementation that can be used to isolate a predefined group of computers, preshared keys or certificates can also be used to perform the same isolation. The primary difference from network access groups is that you will need to create separate policies for each group of computers to secure the traffic between the computers that have a preshared key or certificate. This solution requires additional traffic communication planning, particularly if a system belongs to more than one group.

The major drawback to preshared keys is that they are stored in plaintext in the policy and thus are easily discovered (their secrecy is compromised) from a client within the domain. This drawback may not be a concern if the preshared key value is being used simply for temporary isolation during a worm outbreak.

Because of a limitation in how IKE checks certificate constraints at the root CA rather than at the issuing CA, a unique root CA would need to be deployed for each group.

Top of page

Summary

This chapter provided information, processes, and procedures for managing, maintaining, and modifying a server and domain isolation solution after it has been successfully deployed and made operational.

The processes and procedures should be well documented and communicated to all staff who are involved in the day-to-day management of the hosts in the environment. Because there is always the potential for a small change to an IPsec policy to disable a protected communications path, these processes and procedures should be designed to help ensure that no errors are introduced as a result of someone not understanding the ramifications of a policy change.

Top of page

7 of 14