This chapter describes the 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 the following 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:
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 effect relevant parts of that policy across their networks.
However, this phase also involves deciding 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. Making informed decisions and completing this work before you begin to represent the firewall devices will help you get the most benefit from Firewall MC.
The following checklist describes the steps 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 step.
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 using Firewall MC. You should also define the administrative roles and accounts that you plan to use.
Tip You should consider your workflow option when defining the roles and permissions of potential administrators (Selecting the Workflow Mode). The workflow selection affects how you can restrict access.
Result: The administrative model, roles, and accounts for administering Firewall MC are defined.
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 changes are managed within the system. It is one method of defining administrative-task separation and change tracking and change organization. You should choose your workflow according to how formal your organization's change audit program is. Firewall MC has different methods for keeping track of changes. Each method gradually increases the opportunities for audit before deploying 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 the configuration files are generated. However, other users are not required, or able, to review or approve changes before they are deployed to firewall devices.
Workflow enabled—The workflow feature is turned on. Users must define discrete change packages, called activities, and discrete deployment packages, called jobs. In this mode, other users can review changes but not approve them 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 do 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 default of no workflow and gradually increase the settings to meet your needs. It is easier to move from less complex to more complex.
Result: The workflow model is selected, and you understand the implications of the selection.
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 has not been 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 that has 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).
To provide greater security and to provide increased consistency between PIX Firewalls and FWSMs, Firewall MC adds an explicit deny IP any any rule to interfaces for which an ACL has not been defined. You can change this setting to prevent Firewall MC from adding the deny IP any any rule and to enable your firewall devices to handle traffic flows based on their default behavior.
Result: The default security stance is selected, and you understand the implications of the selection.
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.
Result: The hierarchical grouping structure is defined so that you can logically organize the firewall devices that you plan to manage with Firewall MC.
Building blocks enable you to define logical collections of network objects and network services. They enable you to optimize your configuration by issuing a single command that applies to every item in a group by using the name of the group. By defining these groups in advance, you are forced to consider abstractly your network and the services that run across it . 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 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 your network 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 of using network object groups is that they 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.
Result: The base set of building blocks is defined and ready to be used when you define access rules.
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.
Result: The use expectations for object groups are specified, and you understand the implications of the selection.
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.
Result: The mandatory and default policy rules are defined, and you understand the implications of these rules on the firewall devices you plan to manage.
9. Specify handling of generated commands not supported by a specific firewall device.
Because the Firewall MC GUI is unaware of the exact features supported by a specific OS version or type of firewall, you must specify how you want to be notified of invalid, unenforceable settings. This issue is most prevalent at 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.
Result: You understand what warning or error messages will be generated when you have configured a feature in the GUI that is not supported by the firewall device.
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.
Result: The deployment model is selected, and you understand the implications of the selection.
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, in the Beginning or Ending Commands, that it does not understand. 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 publishing 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.
Result: The response to external changes and deployment warnings and errors is defined, and you understand the implications of the selection.
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.
Result: The firewall devices on your network can be imported into Firewall MC without further changes.
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 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. 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 effecting 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.
Result: The firewall devices that you will manage with Firewall MC are represented in the GUI.
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.
Result: Supporting security components are represented in Firewall MC.
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:
Firewall OS Version.
Interfaces, including type and settings, IP addresses, security levels, and interface names.
Firewall administration settings, such as passwords and types of connections enabled.
Result: Basic configuration of your firewall devices is done.
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.
Result: Advanced configuration of your firewall devices is done.
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.
Result: The route settings for the firewall devices are defined.
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.
Result: The device-level access rules are defined.
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.
Result: The device-level translation rules are defined.
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 1.2. You must understand the level of support that each command receives. This understanding will enable 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 unsupported 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.
Result: You understand the level of support that commands receive from Firewall MC 1.2, have verified that commands placed in Ending Commands during import are still required, and have defined CLI commands manually in the Beginning and Ending Commands to address any required, but unsupported, features.
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, in the form of 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.
Result: The logging settings are defined so that the required information is being generated and logged.
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.
Result: The IPSec settings for your firewall devices are defined.
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 define the comparison of effected vs. desired policy 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 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. 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.
Result: The configurations for the firewall devices on your network are verified.
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.
Result: The traffic flows through your firewall devices are verified.
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.
Result: The firewall device settings are verified.
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.
Result: The status of the running configurations on your firewall devices is verified.
During the deployment phase, your focus is on the actual deployment of verified configuration files to your managed firewall devices. This phase effects the policy changes that you have 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.
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 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. 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.
Result: The deployment method for your firewall devices is defined.
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.
Result: The device configurations have been generated and either deployed or saved so that they can be deployed later.
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.
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.
Result: A job is created and ready to be approved or deployed.
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.
If you receive a job for review, you can approve the job (grant permission for the job to be implemented) or reject the job (deny permission for the job to be implemented).
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. In other words, 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.
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.
Result: The previous configuration files are saved to the specified directory.
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.
Result: The firewall device configuration is reverted back to the rollback configuration.
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 in 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. If the firewall device is configured to enable Telnet or console administrative connections, you can also review syslog message from a console or Telnet client connected directly to a firewall device.
The following checklist describes the steps required to understand the decision-making process and the 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. The checklist contains references to the specific procedures used to perform each step.
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 Security Monitor server collects this data and uses it for administrative reports about network activity.
Result: The Security Monitor server is prepared to receive all Syslog streams from the firewall devices.
2. Enable logging and specify the syslog settings that each firewall device must generate so that the selected audit events can be detected by the Security Monitor server.
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 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.
Result: The firewall devices generate the correct level of syslog messages so that the Security Monitor server can detect the audit events you are interested in.
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 the application of the ACL.
Defining Thresholds. For a specific log level, you can specify threshold values for generating a syslog message.
Result: The firewall devices generate only those audit events and the details that you are interested in.
4. Save configuration settings and publish device-specific command sets to the firewall devices.
For the changes that you made to take effect, you must generate the appropriate command sets and then publish those command sets to the necessary devices.
Result: The configuration is updated, the new command sets are published to the required devices, and the Security Monitor is listening for syslog traffic that originates from those devices.
