Table Of Contents

Task Flow Checklists

Checklist for Planning Phase

Checklist for Implementation Phase

Checklist for Verification Phase

Checklists for Deployment Phase

Checklist for Deploying with Workflow Disabled

Checklist for Deploying with Workflow Enabled

Checklists for Operations Phase

Checklist for Rolling Back to a Previous Configuration

Checklist for Monitoring Firewall Devices Using Security Monitor

Checklist for Configuring Virtual Firewalls

Checklist for Configuring Firewall MC to Use Auto Update Server

Task Flow Checklists

---

This chapter describes the project phases and task flows that you should follow when you use Firewall MC to manage your firewall devices. First, however, you must develop a security policy that enables the application of security measures. Your security policy should:

•Identify security objectives for your organization.

•Document the resources to protect.

•Identify the network infrastructure with current maps and inventories.

•Identify the critical resources (such as research and development, finance, and human resources) that require extra protection.

After you develop your security policy, it becomes the hub of the Cisco Security Wheel, shown in Figure 2-1.

Figure 2-1 Cisco Security Wheel

The spokes of the Cisco Security Wheel represent network security as a continual process consisting of four steps:

1. Secure your system.

2. Monitor the network for violations and attacks against your security policy and respond to them.

3. Test the effectiveness of the security safeguards in place.

4. Manage and improve corporate security.

You should perform all four steps continually, and you should consider each of them when you create and update your corporate security policy.

The remainder of this section details recommended task flows according to the following project phases:

•Planning (see Checklist for Planning Phase).

•Implementation (see Checklist for Implementation Phase).

•Verification (see Checklist for Verification Phase).

•Deployment (see Checklists for Deployment Phase).

•Operations (see Checklists for Operations Phase).

Checklist for Planning Phase

Making informed decisions and completing the planning phase before you begin to represent the firewall devices will help you get the most benefit from Firewall MC. During the planning phase, you should define your corporate security policy. Many organizations already have a defined policy, and they use tools such as Firewall MC and firewall devices to implement relevant parts of that policy across their networks.

However, this phase also requires you to decide how you will use Firewall MC. These decisions shape your interaction with the product, the flow of tasks, and your ability to adhere to your defined security policy.

This phase also includes installing and preparing the Firewall MC server and bootstrapping the firewall devices that you intend to manage. As with any project, up-front planning is designed to save you time and money.

The following checklist describes the tasks required to understand the decision-making process and the basic flow required to deploy Firewall MC in the most productive manner. Each step might contain several substeps; the steps and substeps should be performed in order. The checklist contains references to the specific procedures used to perform each task.

	Task
	1. Select administrative authentication and authorization model. Although the administrative model is configured and defined independent of Firewall MC, you should define it before you use Firewall MC. You should also define the administrative roles and accounts that you plan to use. Tip Consider your workflow option when defining the roles and permissions of potential administrators ( Selecting the Workflow Mode, page 3-5). The workflow selection affects how you can restrict access. For more information, see: • Selecting the Administrative Model and Authentication Mode, page 3-1. • User Guide for CiscoWorks Common Services 2.2. • User Guide for Cisco Secure ACS for Windows Server (requires version 3.1 or later).
	2. Select workflow model. In Firewall MC, workflow refers to how you manage changes within the system. It is one method for defining administrative-task separation, change tracking, and change organization. You should choose your workflow according to how formal your organization's change audit program is. Firewall MC has several methods for keeping track of changes. Each method gradually increases the opportunities for an audit before you deploy configuration files to a firewall device. •No Workflow—Default. In this mode, Firewall MC tracks changes and locks for each user. Locks on devices or groups are released when you generate configuration files. However, other users are not required, or able, to review or approve changes before you deploy them to firewall devices. •Workflow enabled—The workflow feature is turned on. You must define discrete change packages, called activities, and discrete deployment packages, called jobs. In this mode, other users can review, but not approve, changes before they are deployed. Activities and jobs provide a layer of separation that you can enforce by using user roles and permissions. You can define a role that enables only changing the configuration and a different role that enables deploying those changes to the firewall devices. •Workflow with formal approval enabled—The workflow feature is turned on and you must submit an activity or job for approval before you can go to the next step. Tip No planning decision affects your interaction with Firewall MC more than the selection of a workflow process. If you remain unsure about which workflow model to use, start with the no-workflow default and gradually increase the settings to meet your needs. It is easier to move from less complex to more complex. For more information, see Selecting the Workflow Mode, page 3-5.
	3. Select default security stance. The default security stance identifies whether your firewall devices enable or deny traffic flows for which specific access rules are not defined. The default security stance differs between PIX Firewalls and FWSMs. FWSMs deny traffic flows on interfaces for which an ACL was not defined. For PIX Firewalls, the default stance is subject to the behavior provided by interface security levels: Unknown traffic is enabled from an interface with a higher security level to an interface with a lower security level (outbound), and the reverse case is denied. When managing PIX Firewalls, you should keep this feature in mind. For example, if you have a DMZ interface with no rules applied to it, then all networks behind the inside interface automatically have access to the DMZ network (assuming security levels of outside=0, DMZ=50, and inside=100). You can enforce a default security stance for all firewall devices by editing the default access rule table associated with the Global group. For more information, see Default Security Stance.
	4. Prepare inheritance model. Your inheritance model determines the level at which you can define settings and policy rules that your firewall devices inherit. It keeps you from having to define the same rules for each device. Your inheritance model and strategy depend on a hierarchical grouping structure. Therefore, the device groups you define, and their structure, should represent some logical, abstract organization of your network. The groups and structure help other administrators interpret the active policies and can provide logical separations of work, such as organizing by site or department. When you create device groups, you do not need to rely on network topology. Although creating device groups is optional, groups enable you to divide your network strategically to facilitate: •Management—Devices within a group can share common policies. •Deployment—You can deploy a set of devices instead of individual devices. •Visualization—Device groups help you to see the relationships among devices in your network. For more information, see: • What Is Inheritance?. • Managing Your Grouping Structure.
	5. Specify device-level inheritance method. This aspect of inheritance identifies how you want device-level settings to be reused. You can specify one of the following: •Any setting not overridden at the device level is inherited from a parent. •Settings defined for a group are mandatory and cannot be altered for all children of that group. •No settings are inherited. For more information, see: • What Is Inheritance?. • How Settings Are Inherited.
	6. Define global building blocks. Building blocks enable you to define logical collections of network objects and network services. You can use the name of the group to optimize your configuration by issuing a single command that applies to every item in a group. By defining these groups in advance, you are forced to consider your network and the services that run across it abstractly. This consideration enables you to define relationships among objects and services that are more easily interpreted by others in your organization. You use building blocks to associate names to use in place of the corresponding data values in settings and rules. You can define the following building blocks for use in policy rules: •Categories—Categories identify arbitrary metadata that you can apply to network groups and access rules. This metadata provides a value that can be searched and sorted beyond the definitions of the groups and rules. •Network Objects—Network objects are logical collections of objects on or outside of your network. They are one of the many components that you can use for constructing policy rules and are key components for constructing scalable security policies. They can contain one or more network or host IP addresses or other network objects. You use network-object building blocks to refer to multiple network objects from a source or destination condition within a policy rule. Each condition can refer to a single item, such as an IP address, an interface, or a specific hostname or address. By collecting multiple objects in a network object definition, you can refer to all objects in the group as a single item from a source or destination condition. One benefit of defining logical network objects is in the creation of scalable security policies. By using the associative capabilities of network objects, you can expand your policies along with your network. When you add an object to or remove an object from a network-object definition, the change automatically propagates to all other network objects and policies that refer to that network-object definition. Another benefit is that the network object groups reduce the complexity of your security policies by reducing the number of rules required to define policies and by defining a meaningful logical name for such collections. The configuration files and activity audit reports will have a much simpler structure which, when combined with appropriately named network-object groups, makes them easier to read and interpret.
	•Service Definitions—A service definition describes the parameters for a particular type of network traffic, such as the protocols and port the traffic uses. You can reference service definitions directly within your policy rules, or you can create larger collections of service definitions, called service groups, that you can also reference within your policy rules. The service definition describes the network traffic; the policy rule that references the service definition defines who can use the network service and under what circumstances. •Service Groups—Service groups are convenient because they reflect the nature of most applications (such as a web browser) that require several network services to function. You can create service groups to represent the composition of a particular application, or you can model them after the logical organizations that exist on your network, such as a development team or corporate department. Having service groups spares you from having to reference service definitions singly within your policy rules. •AAA Server Groups—AAA server groups represent collections of authentication servers focused on enforcing specific aspects of your overall network security policy. For example, you can group those servers dedicated to authenticating internal traffic, external traffic, or remote dial-in users, as well as servers that authorize the administration of your firewall devices. •Address Translation Pools—Address translation pools enable you to define logical collections of addresses to be used in translation rules. As with service groups and network objects in policy rules, having collections of addresses simplifies the definition and maintenance of your translation rules. For more information, see: • Using Categories and Color-Coding, page 10-5. • Defining Network Objects, page 10-9. • Configuring Service Definitions, page 10-24. • Defining Service Groups, page 10-28. • Defining AAA Server Groups, page 10-31. • Defining Address Translation Pools, page 10-35.
	7. Specify use expectations for object groups in configuration files. When you import devices with existing configurations, you can choose to import and reuse previously defined object groups. Alternatively, you can also choose to merge them into the building blocks that you defined in Firewall MC. During generation, you can choose to retain the object groups as part of the configuration files that you generate and deploy, to defer to optimizations provided by Firewall MC, or to flatten all of the rule lists and remove all references to object groups. For more information, see Configuring Object Grouping, page 3-30.
	8. Define mandatory and default policy rules. Based on your defined inheritance model and building blocks, you should identify those policy rules that reflect the expected and accepted usage on your network. Considering the use of network services before defining actual firewall devices helps you maintain a clear separation between rules that can be inherited or are mandatory and rules that are device specific. For more information, see: • How Inheritance Works for Access and Translation Rules. • Configuring Access Rule Tables, page 11-16. • Address Translation Basics. • Configuring Dynamic NAT and Dynamic Policy NAT. • Bypassing NAT.
	9. Specify handling of generated commands not supported by a specific firewall device. Not all features of a specific OS version running on a firewall device are supported by Firewall MC. For this reason, you must specify how to be notified of invalid, unenforceable settings. This problem is most prevalent at the group level, assuming that you have chosen an inheritance model. You can choose whether to be notified, and if so, by which of the following methods: •Generate errors for overridden features and warnings for inherited features. •Generate errors for all requested unsupported features. •Generate warnings for all requested unsupported features. For more information, see Configuring Feature Tracking Controls, page 3-28.
	10. Select a deployment model. The deployment model that you select identifies your preferred method of publishing generated configuration files. You have three options to choose from: •Deploy to file. •Deploy directly to firewall device. •Deploy to Auto Update Server. If you enable the workflow model, you can override this setting during deployment. Otherwise, this setting is global for all devices that you manage. For more information, see Configuring Deployment Controls, page 3-22.
	11. Define deployment responses to errors, warnings, and external changes encountered during deployment. When deploying command sets to a firewall device, three types of problems can occur for which you must specify a default system response: •Configuration on the firewall device has changed outside of Firewall MC. Firewall MC checks whether the previously deployed command set is the same one that is running on the firewall device. If they differ, you can specify that Firewall MC generate an error and quit the deployment or generate a warning and overwrite the active command set, which results in losing externally made changes. •Firewall MC receives commands that it does not understand and adds them as a beginning or ending command of a device configuration. Firewall MC tries to validate the generated command sets before deploying them. Because it does not understand all possible commands and syntax options, you must specify whether Firewall MC should issue a warning and deploy such commands or issue an error and quit the deployment. •Firewall MC receives warnings or errors from the firewall device in response to deploying a line of the configuration file to the device. An error received from a firewall device can be harmless, or it can result in instability. How you choose to handle warnings and errors depends on your expertise in determining what errors mean. When Firewall MC encounters an error, you can choose to quit the deployment and reboot the firewall device to restore the previous command set, ignore the error and continue publishing the commands, or quit the deployment and leave the firewall device in an unknown state. You can also specify whether Firewall MC should optimize the generated command sets. Optimization generates command sets that are typically smaller than similar configurations defined by administrators; however, it is more difficult to understand what policy is active on the firewall device when you review these optimized commands. For example, the contents of network object and service groups can be combined to reduce the rule set. If you enable optimization, you can use Firewall MC to review the more logical presentation of the policy, but you should never expect a one-to-one correlation between rules defined in the GUI and rules generated as part of the command set. For more information, see Configuring Management Controls, page 3-13.
	12. Bootstrap firewall devices. Ensure that any supported devices you plan to manage are installed on your network and that you can open an HTTPS connection from the CiscoWorks Server to the firewall devices. Back up any configurations running on the devices. For more information, see: • Bootstrapping PIX Firewalls. • Bootstrapping Firewall Services Modules.

Checklist for Implementation Phase

The major part of device configuration is performed during the implementation phase. Device configuration includes representing the firewall devices in Firewall MC and defining your network security policy by using access and translation rules.

The following checklist describes the steps required to prepare your network devices so they can be managed by Firewall MC. Each task might contain several steps; the tasks and steps within should be performed in order. The checklist contains references to the specific procedures used to perform each task.

	Task
	1. Represent firewall devices. Representing firewall devices involves providing basic contact information about a firewall device. An icon is created under the selected device group to represent each device. As part of this task, you must select the group to which the firewall device will belong. When you represent devices, you are populating the hierarchy and affecting the inheritance model. To import device information, you can have Firewall MC query the device directly, or you can import the information from a file.You can import a single device or multiple devices at one time. You can specify the devices to import in a .csv file, which can be created manually or can be exported from a device tracking application such as CiscoWorks Resource Manager Essentials. For more information, see: • Populating Firewall MC with Firewall Devices, page 7-1. • Importing PIX Firewalls That Use Conduit and Outbound Commands, page 7-5. • Populating Firewall MC Using the Import From File Methods, page 7-9. • Importing Multiple Firewall Configurations from a CSV File, page 7-12. • Discovering Settings from a Firewall, page 7-22.
	2. Represent supporting security components. Firewall devices rely on many supporting components to provide a comprehensive security solution and additional information about the network. These components include filtering servers and DHCP servers and, in the case of assisted deployment, TFTP and Auto Update servers. For more information, see: • Identifying Supporting Devices, page 7-29. • Configuring URL Filter Servers, page 7-29. • Configuring a DHCP Server, page 7-36. • Configuring DHCP Relay Servers, page 7-39. • Editing DHCP Relay Agents, page 7-41. • Configuring TFTP Servers, page 7-43. • Representing Auto Update Servers, page 7-45.
	3. Configure basic settings for firewall devices. Firewall MC uses a series of wizards to help you configure settings. Each page of a wizard groups a series of settings that affect the same feature. You can configure the following features according to your network needs: •Version of the firewall device OS system. •Interfaces, including type and settings, IP addresses, security levels, and interface names. •Firewall administration settings, such as passwords and types of connections enabled. For more information, see: • Setting the Firewall Operating System Version, page 8-2. • Configuring Interfaces, page 8-5. • Configuring Firewall Device Administration, page 8-25. • Configuring Authentication Prompts, page 8-64.
	4. Configure advanced services for firewall devices. Advanced settings are optional features that provide advanced processing or security features. Firewall MC uses a series of wizards to help you configure these settings. Each page of a wizard groups a series of settings that affect the same feature. For more information, see: • Configuring IDS Policy, page 8-68. • Configuring IDS Signatures, page 8-71. • Configuring Anti-Spoofing, page 8-73. • Configuring Fragments, page 8-75. • Configuring TCP Options, page 8-78. • Configuring Timeouts, page 8-81. • Configuring Basic Fixups, page 8-84. • Configuring Multimedia Fixups, page 8-89. • Configuring Flood Guard, page 8-94.
	5. Define routing rules. Before a firewall device can forward the packets that it receives, you must define the route settings for that device. The firewall devices that Firewall MC manages support static and dynamic routing. To ensure that traffic flows are possible, you must determine what method or combination of methods should be used by the firewall devices on your network. For more information, see: • Learn More About Routing. • Configuring Static Routes. • Configuring RIP. • Configuring Proxy ARP Settings.
	6. Define device-level access rules. You must define the device-specific access rules that, along with the default and mandatory rules for the device, will enforce your corporate security policy. You can define the following types of access rules: •Firewall rules. •AAA rules. •Web filter rules. For more information, see: • Inserting or Editing a Firewall Rule, page 11-17. • Inserting or Editing an AAA Rule, page 11-24. • Inserting or Editing a Web Filter Rule, page 11-29.
	7. Define device-level translation rules. Address translation enables you to control the use of IP addresses in your network and provides additional security by protecting internal addresses from visibility on the external network. You should define the device-level translation rules that, along with the default and mandatory rules for the device, support your IP addressing scheme and security needs. For more information, see: • Notes About Translation Rules. • NAT Types. • Configuring Static NAT and PAT. • Configuring Dynamic NAT and Dynamic Policy NAT. • Bypassing NAT.
	8. Define CLI commands manually to address any required, but unsupported, features. PIX Firewall and Firewall Services Module (FWSM) CLI commands receive different levels of support from Firewall MC, which is contingent upon the version of Firewall MC you have installed, and the OS version you are running on your firewall devices. You must understand the level of support that each command receives. This understanding enables you to use commands or command combinations in PIX Firewall and FWSM configuration files so that import operations and deployment jobs succeed. If you import a device configuration that includes commands Firewall MC does not recognize, the unrecognized commands are placed in the Ending Commands in Firewall MC. Ending Commands are deployed after all Firewall MC generated commands are deployed. You can define CLI commands manually in the Beginning and Ending Commands to address any required, but unsupported, features. You should also verify that commands placed in Ending Commands during import are still required. Ending Commands are sent with each deployment; as a result, they can cause errors when a command that is already configured is issued again on the firewall device. For more information, see: • Supported Devices, OS Versions and Commands for Management Center for Firewalls 1.2 • Configuring Beginning Commands, page 13-3. • Configuring Ending Commands, page 13-5.
	9. Define logging settings. Firewall MC provides part of the full audit functionality that VMS provides. Although Firewall MC addresses administrative events fully, it relies on Security Monitor to collect, retain, and categorize the network activity records. Firewall MC configures the devices to generate and publish the audit records, as syslog records, to Security Monitor. However, Security Monitor processes and stores these records and provides the reporting features for network activity and usage statistics. Using Firewall MC and Security Monitor together provides a complete security solution for your firewall devices. For more information, see: • Specifying Log Settings for Firewall Devices, page 16-6. • Refining the List of Generated Syslog Messages, page 16-16. • Configuring Logging Level for Device-Level Monitoring, page 16-27.
	10. Define IPSec Settings. Firewall MC enables you to configure a PIX Firewall to operate as a Cisco Secure VPN client and to control remote management access to your PIX Firewall. For more information, see: • Configuring Easy VPN Remote, page 17-67. • Configuring Easy VPN Management, page 17-72.
	11. Define failover settings. Failover enables you to configure two firewall devices so that one will take over operation if the other fails. For more information, see: • Configuring PIX Firewall Failover Pairs. • Configuring FWSM Failover Pairs. • Configuring Failover Settings in Firewall MC.

Checklist for Verification Phase

Verifying security policy can occur several times throughout the project. As illustrated by the spokes in the Cisco Security Wheel, you perform the monitoring and testing steps to study the active security policy across your network. However, you can also verify that specific traffic flows are correctly restricted, enabled, or otherwise changed before deployment.

Many organizations benefit from the ability to compare desired policies with actual policies and their effects. This is referred to as policy audit. You can use compatible methods, such as analyzing traffic logs, probing for known vulnerabilities, and studying the defined configurations and device settings to audit policies. From Firewall MC, you can verify configuration and device settings before you deploy them. You can also configure your managed firewall devices to publish syslog messages to traffic analysis tools, such as Security Monitor and CiscoWorks Security Information Management Solution (SIMS).

The following checklist describes the steps required to verify the implementation of your security policy. Each task might contain several steps; the tasks and steps should be performed in order. The checklist contains references to the specific procedures used to perform each step.

	Task
	1. Generating configuration file changes. After you define settings and rules, you can generate and view the configuration file to make sure it includes your changes before you deploy the configuration. Viewing device configurations enables you to verify that the changes you made result in generating the commands that you expect. For more information, see Viewing Configurations.
	2. Study traffic flows. To verify the implementation of your corporate security policy, you must verify that the implemented policy rules have the desired effect. This includes verifying that desired access is permitted while unauthorized access is denied. If you are using Security Monitor to collect, retain, and categorize the network activity records, and you configured your devices to generate and publish the necessary audit records, you can use the reporting features in Security Monitor to study your traffic flows and usage statistics. For more information, see Using Monitoring Center for Security 1.2.
	3. View device settings reports. At any time, you can view a report that identifies device settings for a device or device group and shows whether a particular setting is inherited, mandatory, or overridden. You can use these reports to verify that your corporate security policy was implemented correctly and to identify settings that can be handled using inheritance. For more information, see Viewing a Device Settings Report.
	4. View configuration difference reports. Firewall MC provides a report to help you determine whether a device's running configuration matches the latest configuration deployed to that device and whether a device is using a configuration that can be replaced by a more recent, approved configuration. For more information, see Viewing a Configuration Difference Report.

Checklists for Deployment Phase

During the deployment phase, your focus is on the actual deployment of verified configuration files to your managed firewall devices. This phase brings about the policy changes that you planned, implemented, and verified.

The process for deploying configurations depends on the workflow setting you are using. If the workflow feature is not enabled, deployment is simplified, but you will not have as much control over the deployment process. For more information, see Selecting the Workflow Mode, page 3-5.

Checklist for Deploying with Workflow Disabled

The following checklist describes the steps required to understand the decision-making process and the basic flow required to deploy configurations when workflow is disabled. Each task might contain several steps; the tasks and steps should be performed in order. The checklist refers you to the specific procedures used to perform each step.

	Task
	1. Specify the method to use for deployment. Before you deploy device configurations, you must specify how Firewall MC handles deployment for each device. You can deploy to a device (default), a file, or an Auto Update Server (AUS). When workflow is disabled, you do not have the option of selecting the deployment method during deployment. For more information, see Configuring Deployment Controls, page 3-22.
	2. Generate and deploy the configuration. After making desired configuration changes, you must generate the new configuration files. After you generate the new configurations, you can deploy those files or save them and then deploy later from the Deployment tab. For more information, see Generating Configurations for Modified Devices.

Checklist for Deploying with Workflow Enabled

The following checklist describes the steps required to understand the decision-making process and the basic flow required to deploy configurations when workflow is enabled. Each step might contain several substeps; the steps and substeps should be performed in order. The checklist contains references to the specific procedures used to perform each step.

	Task
	1. Submit the activity. If approval is enabled, all activities must be approved before you can create a job to deploy those configuration changes. If approval is disabled, the submit and approve process is a single step and the activity is approved automatically when you submit it. Note Approval is disabled by default. To enable approval, see Requiring Formal Approval, page 3-9. For more information, see: • Approving Activities, page 3-9. • Submitting an Activity for Review. • Approving or Rejecting an Activity (Approval Process Enabled).
	2. Create a job. After an activity is approved and committed, you must create a job to deploy the updated configuration information to the devices. When you create a job, you submit one or more firewall device configurations for review. You access this feature from the Workflow tab. For more information, see: • Understanding Jobs, page 3-8. • Using Job Management
	3. Submit the job. If approval is enabled, all jobs must be approved before you can deploy the configuration changes. If approval is disabled, the submit and approve process is a single step and the job is approved automatically when you submit it. Note Approval is disabled by default. To enable approval, see Requiring Formal Approval, page 3-9. If you receive a job for review, you can approve it (grant permission for the job to be implemented) or reject it (deny permission for the job to be implemented). For more information, see: • Approving Jobs, page 3-10. • Submitting a Job for Review (Approval Process Enabled). • Approving or Rejecting a Job (Approval Process Enabled).
	4. Deploy the job. After a job is approved, the final stage is to deploy it. You can deploy a job to a device (default), a file, or an Auto Update Server (AUS). For more information, see Deploying a Job.

Checklists for Operations Phase

The operations phase consists of periodic operations that you should perform to keep your security system up-to-date and to recover from unexpected failures.

Checklist for Rolling Back to a Previous Configuration

After you deploy a configuration, you might need to disregard the deployment and revert to the previous configuration file. Perhaps the deployment was not successful, or you simply want to revert to the previous configuration settings for certain devices. To do this, you can use the rollback feature.

---

Caution Applying a rollback configuration to a firewall device causes the device and Firewall MC to lose synchronization. The information in Firewall MC represents the state of the firewall device before the rollback. Use the rollback procedure as a way to quickly correct a configuration that is not secure or blocks required traffic. However, remember to use Firewall MC to correct the firewall device configuration and then use Firewall MC to deploy the corrected configuration to restore synchronization.

---

The following checklist describes the steps required to understand the decision-making process and the basic flow required to roll back to a previous configuration on a firewall device. Each step might contain several substeps; the steps and substeps should be performed in order. The checklist contains references to the specific procedures used to perform each step.

	Task
	1. Enable workflow. Before you can access the rollback feature, you must enable workflow if it is not already enabled. For more information, see Setting Workflow Options, page 3-11.
	2. Generate the previous configuration file. The rollback feature enables you to write the last good configuration files for some or all devices within a job. The configuration files are stored in the directory you specified in the rollback wizard. For more information, see Select Workflow > Job Management..
	3. Update the firewall device with the rollback configuration file. After generating the previous configuration file, you must clear the current configuration on the firewall device, reestablish communication with the firewall device, and then update the firewall device with the rollback configuration file. For more information, see Select Workflow > Job Management..

Checklist for Monitoring Firewall Devices Using Security Monitor

Auditing the flow of traffic across your firewall devices enables two other features, notifications and network activity reporting. However, before you can generate notifications or network activity reports, you must specify the settings for logging and retaining audit records about events within the system or logged by a firewall device.

After you specify and save these settings, you can use Security Monitor to review customized network activity reports that present the types of audit information most useful to you. In addition, you can view activity reports in Firewall MC as part of your security policy review process. If the firewall devices are configured to allow Telnet or console administrative connections, you can also review syslog messages from a console or Telnet client connected directly to a firewall device.

The following checklist outlines the steps required to understand the decision-making process and basic flow required to define your audit event monitoring and logging settings. Each step might contain several substeps; the steps and substeps should be performed in order. References to the specific procedures used to perform each step are included.

	Task
	1. Configure the Security Monitor to monitor the syslog stream of each firewall device. The Security Monitor server collects audit- event streams from one or more firewall devices and combines them into audit records that you can refine into more meaningful data. The data is collected and used for administrative reports about network activity. For more information, see Configuring Security Monitor to Listen for Syslog Messages, page 16-5.
	2. Enable logging and specify the syslog settings that each firewall device must generate so the Security Monitor server can detect the selected audit events. Before you can generate meaningful reports or notifications about the network activity of a firewall device, you must enable logging and select a facility and a suitable log level. This log level must be the one that generates the syslog details required for tracking session-specific data and device-specific events that you are interested in. To select this log level, first study the audit events that you want Security Monitor to retain, then study the documentation provided with your firewall devices to determine the minimum log level required to generate those audit events. For more information, see: • Specifying Log Settings for Firewall Devices, page 16-6. • Enabling Logging on a Firewall Device, page 16-7. • Defining Syslog Facility Settings, page 16-9. • Directing Syslog Traffic to a Syslog Server, page 16-15.
	3. Refine the set and frequency of audit events that the firewall devices should generate. You can use any of the following four methods to refine the list and the frequency of audit events generated by a firewall device: •Reclassifying messages. For a specific syslog message ID, you can define a rule that overrides the default log level of the message. •Disabling messages. For a specific syslog message ID, you can define a rule that disables the generation of that message by a firewall device. •Generating messages by ACL. You can require that a firewall device generate a syslog message when an ACL is applied to a session request. This level of detail enables you to study statistics about ACL use, such as thresholds about the number of deny sessions allowed. •Defining Thresholds. For a specific log level, you can specify threshold values for generating a syslog message. For more information, see: • Refining the List of Generated Syslog Messages, page 16-16. • Reassigning the Level of a Syslog Message, page 16-17. • Enabling or Disabling a Syslog Message by ID, page 16-18. • Generating Enhanced Audit Data for Firewall Rules, page 16-19. • Configuring Rate Limit Level for a FWSM, page 16-22. • Configuring the Rate Limit of Individual Syslog Messages for FWSM Devices, page 16-24.
	4. Save configuration settings and publish device-specific command sets to the firewall devices. For your changes to take effect, you must generate the appropriate command sets and then publish those command sets to the necessary devices. For more information, see: • Generating and Verifying Configuration Files. • Deploying Configuration Files.

Checklist for Configuring Virtual Firewalls

To use virtual firewalls, you must perform part of the configuration using a terminal connection to the switch and the FWSM module. In addition, you must import each security context into Firewall MC. Even though multiple security contexts can reside on the same module, Firewall MC treats each context as a unique, standalone firewall device.

The following checklist outlines the steps required to understand the decision-making process and basic flow required to prepare the FWSM module for import into Firewall MC. Each step might contain several substeps; the steps and substeps should be performed in order. References to the specific procedures used to perform each step are included.

	Task
	1. Bootstrap the firewall device for FWSM 2.1. The FWSM contains a system configuration that identifies basic settings for the card, including a list of contexts. This configuration is the startup configuration in the Flash memory partition. For more information, see the Catalyst 6500 Series Switches and Cisco 7600 Series Router Firewall Services Module Configuration Guide that shipped with your firewall device.
	2. Configure the FWSM in the Catalyst 6500 series switch or Cisco 7600 series router. Completing this task enables the module to be recognized by the switch. •Assign VLANs and interfaces to the FWSM. The FWSM uses VLANs in place of external physical interfaces. •Add virtual switched interfaces (VSIs) to the Multilayer Switch Feature Card (MSFC). •Enable HTTPS. Ensure that you can open an HTTPS connection from the CiscoWorks Server to the firewall devices. For more information, see the Catalyst 6500 Series Switches and Cisco 7600 Series Router Firewall Services Module Configuration Guide that shipped with your firewall device.
	3. Define Security Contexts. You can set up your FWSM with logical interfaces to behave like multiple firewalls, which are also referred to as security contexts. •Single context mode—Only one firewall context exists, so the FWSM blade behaves as a single firewall device. Context management is therefore not a factor. •Multiple context mode—Multiple virtually independent firewall contexts exist. Multiple contexts are equivalent to having multiple standalone firewalls. Contexts are conveniently contained within a single card. For more information, see Chapter 8, "Configuring Device-Level Settings."
	4. Select Routed or Transparent Mode. Identify where your firewall device will reside on the network. •Routed firewall mode—Layer 3 IP interfaces are used. Use of firewalls is between different networks. Also referred to as L3 Mode. •Transparent firewall mode—VLAN-based Layer 2 interfaces are used. Use of firewalls is within the same subnet. Also referred to as L2 Mode. For more information, see Chapter 8, "Configuring Device-Level Settings."
	5. Classify packets. Each packet that enters the FWSM must be classified, so that the FWSM can determine to which context to send a packet. The FWSM classifier "knows" only about context IP addresses that have static NAT translations or active NAT translations (xlates). You can share a VLAN interface as long as each IP address space is unique, or you can have overlapping IP addresses as long as the VLANs are unique. •All new incoming traffic must be classified, even from inside networks. •For transparent firewalls, interfaces do not have IP addresses, so you need to use unique VLANs. For more information, see the Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide that shipped with your firewall device.
	6. Populate Firewall MC with the device. •Manually create the device— Define the contact and configuration settings for the FWSM manually in Firewall MC. •Import the device—Import configuration information individually from a single file or import multiple configuration files from a CSV file. For more information, see: • Creating Firewall Devices by Defining the Basics, page 7-15. • Populating Firewall MC Using the Import From File Methods, page 7-9.

Checklist for Configuring Firewall MC to Use Auto Update Server

The CiscoWorks Auto Update Server (AUS) provides a web-based interface for upgrading device configuration files and software images on PIX Firewalls that use the auto update feature. AUS can be installed on the Firewall MC server. Firewall MC can be configured to deploy configuration files to the AUS. For more information on configuring AUS for image updates, see the latest version of Using Auto Update Server.

The following checklist outlines the steps required to understand the decision-making process and basic flow required to prepare the firewall device to pull configuration files from the AUS and to Firewall MC to publish configuration files to AUS. Each step might contain several substeps; the steps and substeps should be performed in order. References to the specific procedures used to perform each step are included.

	Task
	1. Configure the PIX Firewall to Use Auto Update Server. You can specify that you want your firewall to poll an Auto Update Server (AUS) and retrieve any configuration changes from that AUS. However, before you can use Firewall MC to publish configurations to an AUS, you must ensure that the devices you're administering are configured to pull their configurations from the AUS. You must prepare each firewall device to use the AUS. Note FWSM cannot pull configurations from an Auto Update Server. This option is available only to PIX Firewall OS Version 6.2 or later. In addition, firewalls configured to use failover cannot use the AUS feature. You can specify this option before or after you import the firewall into Firewall MC. For more information on configuring this option before importing a firewall into Firewall MC, see the Bootstrapping PIX Firewall to Use Auto Update Server. For more information on configuring this option after importing the firewall into Firewall MC, see Representing Auto Update Servers, page 7-45. Representing the AUS in Firewall MC provides the firewall device with the information required to contact the server.
	2. Configure Firewall MC and AUS to Communicate with the Firewall Device. Even though the firewall device is configured to pull information from the AUS, you must still specify the contact information that is required by the AUS to authenticate the firewall. These credentials enable the AUS to perform immediate auto update, if so configured. For more information, see Configuring Firewall Device Contact Info, page 8-29.
	3. Configure Firewall MC to Use AUS on Deploy. If workflow is enabled, you can select whether to deploy to an AUS as part of the job deployment. However, you can configure the default deployment to use the AUS. Additionally, if workflow is not enabled, this is the only option for selecting the AUS on deploy. For more information, see Configuring Deployment Controls, page 3-22. If you encounter problems deploying to AUS, see: – Firewall MC authenticating with an AUS, page A-10 – Firewall MC/AUS authenticating with a PIX Firewall, page A-11