Outlining the Project Phases

Having made the decision to move forward with the CSA product, the security team needs to agree on the high-level phases the project will follow. The organization should already have a standard methodology for this process, including the following:

• Training

• Planning

• Testing

• Pilot

• Implementation

• Continued evolution phases

Each of these major phases has several steps included that will vary from environment to environment. Also, in smaller deployments, you might find that you can combine phases effectively and safely without impacting the success of the project. Throughout this chapter, you see the breakdown of each major phase and its application.

NOTE

You should consider discussing the role a Cisco Partner could play in your deployment, whether partial or complete, and what the partner can bring to the guaranteed success of the implementation based on their expertise and prior installation best practices. Remember, there are always best practices, but your organization might not currently follow them. To find a Cisco Partner, go to http://www.cisco.com/en/US/partners/index.html.

The Training Phase

To begin the project, selected individuals should be trained to fully understand the product, its capabilities, its implementation, and its ongoing maintenance.

NOTE

Cisco training partners offer a Host Intrusion Prevention System (HIPS) class in various locations around the world. To attend one of these classes, consult your preferred Cisco training partner for schedules and availability.

The Planning Phase

After completing the training, the security team should enter the planning phase, which is crucial to the success of the deployment. In the planning phase, you outline all the detailed steps that you will use throughout the project as well as the success criteria for the project and who should perform each task.

Many organizations use software applications to define and track the project as well as the associated timelines, which are typically displayed on Gantt charts. It is important to understand that these steps and success criteria will flesh out as you proceed through the process as the means by which you define success criteria for each task become more evident. Although it is true that the criteria and tasks may change, you must be certain that any changes in the definition of a task occur prior to that task beginning so that you can control the task and limit its effect on surrounding tasks within the workflow. From a very high-level view, you should define the major tasks involved in each phase and the major success criteria for completion of each phase. Until these criteria are reached, you should not proceed to the next step.

The Testing Phase

The testing phase assists in several ways to ensure the organization completes a successful deployment. In the testing phase, you install the CSA MC server and other key representative systems in a mock environment detached from the production network. Within this test environment, you can do the following:

• Train other employees on the CSA product

• Test your understanding of the CSA architecture and its components

• Gain a basic understanding of the impact of the CSA on your critical systems, host, and business workflow

The following step-by-step list outlines tasks within the typical testing phase:

Step 1.	Gather information.
Step 2.	Decide on the test bed size and components.
Step 3.	Install the test environment.
Step 4.	Install the test CSA management architecture.
Step 5.	Create and configure the test CSA hierarchy.
Step 6.	Configure CSA administrative and maintenance settings.
Step 7.	Create the base test policy.
Step 8.	Deploy the test policy.
Step 9.	Tune the policy.
Step 10.	Add advanced policies.
Step 11.	Continue to tune policy.
Step 12.	Place the policy in Enforcement Mode.
Step 13.	Create alerts.
Step 14.	Export, report, and document the test phase.
Step 15.	Train staff and users.
Step 16.	Verify success criteria.

These phases can vary from deployment to deployment based on the size and scope of the deployment, including the type of policies and enforcement controls that are implemented. Another factor that can affect the phases, which you learn more about in subsequent sections, is the level of involvement of the Cisco Partner that may have been selected to assist.

NOTE

The phases outlined in this chapter do not always include step-by-step instructions to complete the task, but rather just sample success criteria. To create detailed steps, review the respective sections of this book as well as other resources, including your training materials, to compile the information for your specific deployment.

Gather Information

As one of the most important tasks within each and every phase, gathering all appropriate and correct information enables you to develop suitable task-success criteria. You need to gather information that is not entirely technical in nature from many parts of your organization. Here is a sample list of information required:

• Why are you deploying the product? It is imperative that you determine very early in the project what the ultimate goal is in implementing the product in your environment. You might decide your organization only wants to prevent worm and virus behavior, or you might want to include personal firewall rules, system and user state rules, application control, and so on. Making this determination now does not limit what you can enable later on in the product, but it will help control the project and maintain implementation timelines.

• What applications are in use in your organization? Compiling a list of authorized applications will assist in the policy creation process as well as team understanding of the baselines that will be created. Tuning the product is much easier when you know what should be seen running on the systems so that other processes can be flagged as suspect and investigated. If your environment seems to have too many authorized or acceptable applications to fully document, focus on the critical business applications in this step.

• Is point-to-point file sharing allowed? Establish whether your users are allowed to share files directly or over the Internet. This information should be outlined in your written security policy.

• Can everyone access the Internet and e-mail? Although many mechanisms can be deployed on the egress of your network to control Internet access and usage, placing strict policy on the endpoints themselves can prevent Internet use from protected systems even when they are not connected to your corporate network.

• Who is allowed to install applications? In many environments, users are not permitted to install applications. Unfortunately, the attempted enforcement mechanism is usually in the form of a signed acceptable use policy. Using the CSA control mechanisms to prevent unauthorized installations can prevent unintended applications from compromising your entire computing infrastructure.

• Are any other software agents deployed? Within any corporate environment, there are often agents deployed that can interrogate the system hardware, perform installation of applications, provide VPN access, act as a personal firewall, or provide virus protection. Many of these locally installed agents could be seen as suspect by the CSA product because of their deep interrogation of the system. You should be aware of any similar product prior to installation so that you can make appropriate decisions regarding installation of the CSA network shim and creation of the necessary exception policies.

• Are any multimedia applications in use? Multimedia applications that access the network often use complex protocols and streams to exchange information between entities. Note these dynamic connections because you might need to create exceptions.

• How do you patch systems and install updates or software? Centralized software updates and installation over the network often trigger various CSA protective mechanisms because downloading and installing remote software is a trait of worm and Trojan horse behavior. You need to understand the installation techniques and connections used during software installation to create policies that allow the installations to continue to occur within defined security parameters.

• What networking control mechanisms are in place? The CSA MC and agents must communicate over the network to provide policy updates and log events as they occur. The successful communication might require the networking and firewall teams to enable the translations, routing, and ports necessary.

• How large should the test bed be? You must determine which systems, applications, and user environments need to be re-created in the test bed.

Many important pieces of information must be gathered to set appropriate tasks. Many of the answers to the preceding questions should be information that is well defined in your written security policy, and so you can glean much information from there.

Determine Test Bed Size and Components

You must determine which systems, applications, and user environments need to be re-created in the test bed. Systems in the test bed should be of the same hardware type and operating system/patch level that is true to production. This task is not limited to the application servers and user workstations that should be replicated, but also applies to networking components. You should acquire basic switching, routing, and firewall systems representative of your production environment to ensure communication rules and flows are adequately tested. This environment will not only be used for initial tests, but can also be used for training new administrators and the untrained staff members. Another use for this environment is the ongoing testing of new policy and rule modules as they are developed as well as testing new applications against current policy enforcement rules.

NOTE

Every IT organization should already have solid change control and quality assurance mechanisms in place. The test bed you create should be used in the testing phases associated with any future change that might be impacted by policy rules and enforcement. The CSA product, because of its nature, needs to be incorporated into these practices.

Install the Test CSA Management Architecture

After installing your test environment, you can begin installing the CSA MC system. This step and several others in this section could be completed in parallel because they do not initially impact each other. The later steps need to be completed in a specific order to ensure success. The first item to complete for this task is the installation of the CiscoWorks VPN/Security Management System (VMS) server application on hardware that meets, or preferably exceeds, the minimum requirements. You need to verify the installation is successful. You also need to understand the configuration parameters associated with this application. At this point, the only component within the application suite you need to install is CiscoWorks Common Services. After successfully installing the VMS product, you can install the CSA MC.

Installing the CSA MC requires the team to decide on the type of installation. In version 4.5, you have the option to install all components on a single server or you can break out portions of the installation to other servers. The components required are as follows:

• The CSA MC configuration front end

• The CSA MC database

• The CSA MC logging server

You should choose the appropriate installation type for your desired level of high availability as well as the number of agents you must service. In addition, if you are implementing more than 500 agents, you need to purchase and install Microsoft SQL server as the database because the included Microsoft Database Engine (MSDE) database cannot grow beyond 2 GB. After installing the CSA MC components, you must ensure the servers are reachable via Domain Name Server (DNS) resolution so that the necessary communication and Secure Sockets Layer (SSL) certificates can function.

Create and Configure the Test CSA Hierarchy

After installing the necessary products, you can begin to configure the CSA MC building blocks and customize the CSA MC to suit your needs. During this task, you might decide to archive unnecessary built-in components that clutter your view to simplify your further configuration. Some administrators export every component before configuring a single CSA component. Doing so allows them to revert or re-import the objects if they are ever changed or manipulated accidentally or in a way that would warrant bringing something back to the default. After exporting the components, you can remove/delete the ones you will not be using within your deployment. When the base components are viewable to your liking, you can continue by creating variables that might prove useful to your organization, such as groups, file sets, network sets, and user and system state sets. You do not need to configure all or any of these components at this point because you can create them as your policy evolves.

NOTE

It is important that you understand what component you are removing and the impact it might have. Upon installation of the CSA MC, the local VMS server has a security agent installed to protect the system. Removing any of the attached policy and subcomponents could cause problems to arise.

When configuring the hierarchy of the CSA MC architecture, you must determine the types of systems you will have within your deployment and the granularity of the policy control mechanisms as it relates to the hierarchy. Many novice administrators initially begin creating several groups that correspond to several occupational- or security-related functions. It is, however, typically a better strategy to start with very few groups and only add groups where absolutely necessary.

When creating groups for users (not servers at this point), the initial question to ask is "What operating systems are deployed that will be protected by the CSA agents?" These operating system determinations will be grouped into Windows, Solaris, and Linux. The next question to ask is "What security practices are common to all systems in my architecture and what security practices are common per operating system?" Both of these questions help you decide how to best use the built-in mandatory groups.

The CSA mandatory groups should include all security controls that are required across the architecture and per operating system group. Examples of these rules include "Individuals may only use an approved web browser when using the Internet within acceptable use guidelines" or "No system may run TFTP, web, or FTP servers without prior approval." Rules such as this are considered global and should not pertain to a specific subset of users, but rather to all users. The mandatory groups could also include system application programming interface (API) protective rules that limit worm and Trojan behavior, root values for system polling, and so on.

After aligning the mandatory groups with security practices, you can create the next level of group hierarchy. This level should include very few groups and will relate to the type of user interaction necessary on the endpoints. The policy applied at this level will include agent control rules and will determine how much interaction, if any, the user can have with the agent. Interaction includes viewing the agent, configuring local firewall policy, and receiving query messages. Many deployments simplify this level of hierarchy into just two groups: a group that can install software and one that cannot. You must be able to answer query messages to install software; therefore, that group would have access to the GUI. The other group might not have the ability to view the GUI, therefore, are unable to respond to query messages.

After determining the installation groups, you can decide whether any other policies will apply only to certain groups of users. You might decide that you do need specific additional groups. Or you might determine that you can deploy the same policies to a smaller number of groups and that application-specific rules deployed to agents that do not have those applications installed will not have any adverse impact. If so, you can overlay the policies on the users utilizing a smaller number of groups. An example of this is to implement a web server control policy on every system even though some systems might not have one installed. This implementation protects the systems that do have web servers, while not weakening security of the systems that are not running them because of the granular nature of the rules contained in the policy. Such an implementation also ensures that if a web server is installed at a later date, no compromise in security level will occur. Your rule set size per agent will increase slightly due to this additional rule overhead, but the number of these rules will most likely be minimal in relation to the other necessary controls.

NOTE

Creating too many groups can prove problematic as your deployment grows. Every time you need to generate rules, the number of groups and complexity of your hierarchy will determine the amount of time necessary to re-create the appropriate rule sets for the agents.

After determining the other necessary groups for policy implementation, you should decide how to use additional functional groups. It is a best practice to include other groups to temporarily or permanently control other aspects of the CSA system. Examples of functional groups are listed here:

• Test Mode group Creating a group with no policy attached but with an adjusted polling interval and Test Mode checked can prove advantageous. Sometimes, you need to place a host policy completely into Test Mode, which you cannot do at the policy level. You most likely will not want to place all hosts in that group into Test Mode to perform a system test, so creating a Test Mode group enables you to place that user into Test Mode by adding the host to the group in addition to the original group(s). When a host is in multiple groups, any group that contains the Test Mode selection will place that agent into Test Mode.

• Application Deployment Investigation group You can use this group as an additional group much like the Test Mode group to use the Application Deployment Investigation feature temporarily on certain hosts without placing an entire large group into this mode.

• Short Polling group You can create groups that have a short (or alternate) polling cycle to use as an additive group when troubleshooting systems.

• Software Update group When you are implementing CSA software updates, the systems that are assigned the update process are determined by group. To test or deploy in smaller-size batches, you can move systems in and out of this group to receive the updates in a controlled manner.

• Geographic groups You can create an additive group determined by geography, building, floor, subnet, and so on to provide a mechanism used when reporting and correlating data or applying alert mechanisms. You might have systems grouped by functional use but want to track a security event by location, which might help locate the source. Running a report to or filtering the events by floor might assist in troubleshooting an isolated breach.

  Your organization might have several buildings with many types of users spread throughout these buildings. Although certain groups can be developed for policy implementation and are aligned more specifically with the users role, creating a group that bundles all users by building or location regardless of role will allow alerts from these systems to be forwarded to the appropriate staff personnel responsible for the building s technical needs.

• Groups specific to alerts and filters You might decide to create functional groups to allow day-two support of the product to mirror your current support and alerting mechanisms. These groups will only bundle certain systems together for alerting the appropriate technical support staff and for similar group reports.

In addition to users, you must create groups for the CSA-protected servers. These groups are typically based on applications running on the server. Desktop systems can be bundled more generically because these systems use a wide array of applications, whereas servers are much more specific regarding how they should function. Servers are typically used in very specific ways, and the resulting policies for servers are therefore typically much more restrictive, which forces you to use a new group per application.

Application servers typically serve a very granular purpose and function predictably every day. Therefore, you can use more controlling policies and selective group assignments than you would with your workstations, which tend to be mush less predictable in function day after day. After creating your hierarchy to the best of your ability, you can continue on to the next task of creating the administrative and maintenance settings for the CSA MC.

Configure CSA MC Administrative and Maintenance Settings

Before progressing too far into the deployment, you should set up the maintenance and administrative parameters on the server. This task includes creating the administrative users and rights required to view and manipulate the database as well as configuring the CSA MC backup policy from the Maintenance option on the menu bar. It is important that you have a method to restore the database in case an outage occurs. Also, be sure to test the multiserver installation for high availability with a hot and cold CSA MC server at this point to verify interaction.

Create the Base Test Policy

Now that you have created some basic hierarchy to determine how you will apply your policy and have configured the CSA MC server maintenance parameters, you can begin to develop policies specific to your environment. You might decide to reuse some of the built-in policies and rule modules, edit the base policies to fit your environment, or create new policies better suited to your architecture and business model. Regardless of the option selected, you need to have your written security policy on hand because the policies you create on the CSA MC will be the direct implementation of that document. If you choose to use or modify any of the predefined policies, it is a best practice to clone the component and edit the newly created object. If the original object clutters your view at this point, you could export and remove it from the system.

The initial policy you create should include agent control rules and any of the global policies included in the mandatory groups. You will most likely also configure the worm and Trojan horse protection rules and any system-wide firewall policies that need to be in place. Do not attempt to implement too many rules at any one time as you begin, because every rule you create might require some basic tuning. You should also configure any additional sets; they are required to accomplish your task of mapping to written policy. Additional sets could include items such as user and system state sets.

NOTE

When implementing user state sets, it is considered a best practice to use groups rather than users in the definitions. Changing a user assigned to the policy requires rule generation each time, but moving a user in and out of a Windows group does not require a state definition change on the CSA MS and therefore does not require generating rules or pushing additional changed policies.

Deploy the Test Policy

After creating a set of rules and developing some basic policies you can implement what you have created on your test systems. You should always do this in Test Mode with verbose logging so that you can work out the conflicts early in your process rather than later in production. At this point, you must determine whether to deploy the network shim and how you will deploy the agents into your environment.

You do not need the network shim to implement network access control rules. The network shim can provide protection for your system against port scans and various malicious packets. Although this might sound like protection every system should have, you need to understand the implications of installing a shim on a system.

The shim can conflict with other software that also uses shims, such as VPN clients, personal firewalls, and other system agents. If you decide to use an unattended or scripted installation method, you must decide when building the agent kit whether to add this ability, because the user will not be prompted. If you attempt to install the shim in your agent kit, and a conflict arises at install time, the install will fail or other issues could occur, including system lockup. For this reason, always test the shim against your known application suite. The applications that tend to conflict most often with the network shim are workstation related, and for that reason you might decide to use the shim only on servers, because they are most likely the target of port scan, malicious packet, and denial-of-service (DoS) attacks. The workstations are better protected and port scans better detected by using a defense-in-depth approach to security design and implementing network Intrusion Detection System (IDS) sensors in your organization.

NOTE

An argument is often made for using the shim on all Internet-facing (or hostile-net-facing) systems to protect against the shim-prevented attacks and report detected port scans. One point to consider in this argument is that if your mobile user is in fact mobile when port scanned, you will most likely not receive the message that it has occurred until that user reconnects to the network anyway. In addition, even if the mobile system is scanned while in a remote portion of the world and you do receive the message, what are you going to do about it? In most cases, the answer is nothing, because of the location and inability to provide remote network security controls on the untrusted network.

Deploying the agent also requires you to consider the methods available to your organization beyond just agent kit configuration. You need to use your current software distribution system, login scripts, or other delivery methods to get the agent installed. You should also consider rebooting the systems at installation completion and the impact that could have on the users and the system security.

Tune the Test Policy and Add Advanced Policies

After installing the base policy you created on select test systems, you can begin to receive messages from the systems regarding possible conflicts the rules are causing. You should test the system rigorously by running applications through their normal interactive sessions. You might also decide to abnormally use systems to test the policys preventive measures, including virus and worm protection.

NOTE

Before testing your systems against worms and viruses, be sure that your systems and test network cannot impact the production environment. You should physically disconnect all production-connected cables at this time.

When tuning the policy, you will want to use Test Mode, the event log, diagnostic information, and log files on the agent systems. In addition, you will become familiar with the Event Management Wizard when tuning and the Application Behavior Analysis tool provided with the CSA product. This task is an important portion of the CSA implementation process, and you should thoroughly understand policy evolution and ensure it is a controlled event.

When you believe the current policy is tuned within acceptable parameters, which include system query messages and events triggered, step back to policy creation and create the next portion of your policy, whether it is specific to a group, application, or network control. After creating additional advanced policies and rules, redeploy and then tune again. This process should continue to loop until you have met your predetermined success criteria. In other words, rinse and repeat until clean.

Place the Policy in Enforcement Mode

Upon successfully completing the policy creation and tuning cycle, you should then remove the hosts from the Test Mode group, which will place the agents into Enforcement Mode using the developed policy. You must retest the systems using interactive methods to guarantee the policy was tuned appropriately. You might have had rules in your policy that were set to not log events that were not displayed during Test Mode. In Enforcement Mode, their implications will show up, and you can search for the issues in the event log and local agent log files.

Create Alerts

Now that you have tuned your policy within acceptable usage limits, you will want to set up alerting mechanisms to notify the correct people when specific events occur. This process requires your decisions as to how to configure various event sets that will trigger the many alert possibilities. Throughout the tuning phase and upon completion, you will gain a great understanding of the alerts you expect to see and which ones should trigger notification.

Export, Report, and Document

You can now begin to export the developed objects and policies for backup. You will want to securely store these objects to ensure you have an offline copy available for disaster recovery. You might also choose to run reports regarding the policies and groups used to provide additional hardcopy documentation that might be necessary as a reference later in the product s installed life cycle. You should also alter any procedural documentation that might be impacted by the security agent. Change control mechanisms should be altered to include any agent-affected mechanisms as well as to ensure that future changes in the computing environment consider the agent impact.

Train Staff and Users

You should now be able to train the monitoring staff regarding the use of the NOC/SOC (network operations center/security operations center) screens, such as the Event Summary. The monitoring staff members must understand the various alerts and diagnostic screens available to them prior to the pilot phase, during which they will be required to interact more closely with the product. Any other staff who will support the pilot phase of the project should also be included in necessary training to ensure success of the project, including IT management, workstation and server support, and the help desk.

You should also begin to train the user base at this point. Most specifically, train the users who will participate in the pilot phase. The users should feel comfortable with any interaction required and understand the messages they might view. In addition, users should understand the features of the product and the contact information of their support team in case any issues or questions arise.

Verify Success Criteria

Upon completion of all tasks in the test phase, verify that you have successfully completed all objectives and are prepared to begin the next phase of the project. Verification should be done internally by the team and possibly by a third-party group (this could be an internal corporate resource) that can audit the results before proceeding to the next phase.

The Pilot Phase

The pilot phase includes many of the same tasks completed in the test phase of the project, with a few major differences in the circumstances and environment. The pilot phase of the project is functioning in the production network with real data, systems, and business flow occurring. Any negative impact can cause production business to stop. You must keep in mind that even pilot implementations should be regarded and treated as production because they can affect business.

Another major difference in the pilot phase is that the systems are being used by real users, not by knowledgeable IT staff members. Systems and applications are not always used as designed, and you will most likely find users interacting in ways different from what you witnessed in the test phase. You are also sure to find new and previously untested applications residing on the pilot system, whether approved or not by the IT staff. These applications include necessary business applications as well as Trojan horses, worms, and viruses. You can, however, use your new familiarity with the product and lessons learned in the test phase to quickly remedy and tune the systems appropriately.

Any negative results in the pilot phase could potentially sabotage the project, and so tuning should be meticulously managed. User perception regarding the success of the pilot is what will allow the pilot to continue to the next phases. The following is a step-by-step list of tasks within the typical pilot phase and a brief description of any changes that occur in this phase (in contrast to what occurred within the same task as seen in the test phase):

Step 1.	Gather information You will have a different list of information from what originally was gathered. This list should have been altered throughout the test phase as erroneous information was detected and additional necessary information was located.
Step 2.	Finalize the pilot size and included systems Include a wide sample of disparate systems to ensure applications and user saturation across the pilot. Do not just use IT employee systems. You must use real systems used by real employees to ensure you run into all of the issues you will witness in the complete deployment.
Step 3.	Implement network changes If during the test phase it was determined that you needed to make any changes to the network, including firewall rules, access control lists, routing, or DNS entries, you should make those changes at this time within your change control window.
Step 4.	Install the CSA management architecture You will want to install the CSA MC on the permanent production hardware that will be used for the rest of the project through completion.
Step 5.	Create and configure the CSA hierarchy You should import all the documented policies, rule modules, rules, and other components to the production system. You might need to slightly edit some of the variables to better align with the production computing environment because it differs from the test environment. You should also install the valid permanent license you have purchased for the pilot users.
Step 6.	Configure CSA administrative and maintenance settings Just as before, configure the necessary maintenance settings to ensure the system is adequately protected from failure and that your team is able restore the system.
Step 7.	Deploy the policy Deploy the pilot policy in Test Mode. You will also be tuning your installation process in this task.
Step 8.	Tune the policy Using the various policy-tuning methods, continue to fine tune the policy implemented. Use the Application Behavior Investigation and Application Deployment Investigation features at this point to better understand what is really installed in your environment. As you further develop policy, you will continue to tune until satisfied with the outcome.
Step 9.	Implement alerts Prior to placing the agents in Enforcement Mode, configure alerts to ensure you can provide timely remediation to any events that might warrant remediation.
Step 10.	Place the policy in Enforcement Mode Begin to remove systems from Test Mode to enforce policy. This should be performed in a very controlled manner initially to ensure success. Once again, remember that any negative results could impact the perceived success of the implementation as well as corporate acceptance of the product. Even something as simple as a user receiving too many pop-up windows, as defined by the user, regardless of the technical success of the project, could make the implementation appear as a failure.
Step 11.	Export, report, and document Completely document the outcome of the pilot and modify any documentation that will impact the production-wide rollout. You will also export the finalized policies as a backup.
Step 12.	Train additional staff and users You should now continue to train the remaining staff and employees who will participate in the completion of the project. This training should include any alterations that might be necessary through the evolution of the project and lessons learned.
Step 13.	Verify pilot success criteria Verify all success criteria have been met.
Step 14.	Plan for the implementation phase Using the previously documented planning steps, your team should prepare for the additional rollout of the product, which might include developing additional policies in the test environment.

The Implementation Phase

The implementation phase is similar to the steps followed for the pilot phase. You use the same CSA MC server and the policies fine tuned during the pilot phase. The implementation phase is just an expansion of the pilot to include all remaining systems. Following are the remaining tasks necessary to complete the project:

Step 1.	Gather information Gather any information about systems, applications, or networks not included in the pilot.
Step 2.	Create and configure additional CSA hierarchy If any additional groups are needed, create them at this time.
Step 3.	Deploy the policy Deploy the final project policy in Test Mode. You also fine tune your installation process in this task.
Step 4.	Tune the policy Just as the previous similar tuning tasks, tune appropriately using all tuning aids available.
Step 5.	Implement alerts Continue to fine tune alerts.
Step 6.	Place the policy in Enforcement Mode Enforce the policy in a controlled manner and monitor closely.
Step 7.	Export, report, and document Completely document the outcome of the implementation and modify any documentation that will impact further implementations. You also export the finalized policies as a backup.
Step 8.	Verify project success Verify all success criteria have been met.

Continued Evolution of the CSA Deployment

After the production environment is saturated with CSAs, you can begin to decide how to add additional controls to the product deployment through additional policies. You should implement these controls using the very same processes, phases, and tasks discussed throughout this chapter. You should also always implement the changes within change control guidelines, which should now include procedures and steps for the CSA product.