Guest

Cisco Security Manager

Getting Started with Cisco Security Manager 4.0

  • Viewing Options

  • PDF (2.6 MB)
  • Feedback
Getting Started with Cisco Security Manager 4.0

Table Of Contents

Getting Started with Cisco Security Manager 4.0

Abstract

Assumptions Made In This Paper

Understanding Key Security Manager Concepts

Key Concepts: Device Interactions

Key Concepts: Policy Abstraction

Adding the ASA to the Security Manager Inventory

Configuring Unsupported Commands Using FlexConfig Policies

Tips for Using FlexConfig Policies

Evaluating Unsupported Commands for FlexConfig Configuration

Adding the AIP-SSM

Configuring the Service Policy for IPS Inspection

Understanding How the AIP-SSM Works

Key Concepts: Service Policy Rules

Identifying the Traffic for IPS Inspection

Create the Shared Policy and Default Rule for Inspecting All Traffic

Add a Local Rule to Exempt the Management Station from IPS Inspection

Convert Local Rules to Shared Rules

Submitting and Deploying Changes to the Firewall


Getting Started with Cisco Security Manager 4.0


Abstract

Cisco Security Manager is an enterprise-class security management software application. You can use it to manage security policies on a wide variety of devices, including adaptive security appliances (ASA), intrusion prevention system (IPS) appliances and service modules, integrated security routers (ISRs), and so forth. You can also use Security Manager to view events generated from ASA and IPS devices.

This paper uses a Cisco Adaptive Security Appliance (ASA) that contains an Advanced Inspection and Prevention (AIP) Security Services Module (for IPS inspection) to illustrate various techniques for managing device configurations in Security Manager, from adding the device to configuring shared and local policies to deploying policy changes. The main purposes of this paper are:

To explain some basic concepts that will help you use Security Manager with any type of device.

To demonstrate the end-to-end usage of Security Manager.

To illustrate the capabilities of shared and inherited policies.

To explain how to evaluate policy discovery results for possible FlexConfig usage.

To show the simplicity of configuring security policies using the Security Manager client in comparison to using the CLI.

To show several different approaches to configuring policies.

You can use the techniques described in this paper with other device types.

For more information about the products discussed in this paper, see the following:

Cisco Security Manager: http://www.cisco.com/go/csmanager.

Cisco ASA devices and software: http://www.cisco.com/go/asa.

Cisco ASA Advanced Inspection and Prevention Security Services Module: http://www.cisco.com/en/US/products/ps6825/index.html.

Assumptions Made In This Paper

This paper makes the following assumptions:

You are using Security Manager 4.0. Although the concepts and techniques discussed in this paper apply to other versions of Security Manager, the screen shots and command paths might be different for other versions of the product.

You have installed the Security Manager server and installed all relevant service packs and patches. For information on installing the server, see Installing and Upgrading Server Applications in the Installation Guide for Cisco Security Manager.

You have installed the Security Manager client as explained in Installing and Configuring the Client in the Installation Guide for Cisco Security Manager.

You have completed the recommended initial configuration with the following minimum settings:

SMTP server—Although this paper does not use e-mail notification, you should identify the e-mail server through which critical notifications are sent. There are a variety of configuration settings you can use to send notifications for specific events.

Administrator accounts—At the very least, define your account information including your e-mail address. You must have full administrator privileges to perform all the actions explained in this paper.

Workflow mode—This paper assumes that you are using non-Workflow mode. If you are using Workflow mode, you will need to start an activity to configure policies and to create deployment jobs. The procedures are otherwise the same with the addition of the Workflow-management steps.

For more information, see "Completing the Initial Security Manager Configuration" in Getting Started with Security Manager in the User Guide for Cisco Security Manager.

The ASA and AIP-SSM devices are configured with management IP addresses. Both devices are also configured to allow SSL (HTTPS) communications with the Security Manager server.

This paper does not provide a complete ASA or AIP-SSM configuration; instead, the assumption is that the ASA and AIP-SSM are fully configured, but that the ASA policy required to send traffic to the AIP-SSM for IPS inspection is not configured. For general information about the basic configuration requirements to enable device discovery in Security Manager, see Preparing Devices for Management in the User Guide for Cisco Security Manager.

Understanding Key Security Manager Concepts

The following topics explain some key concepts that you need to understand to effectively use Security Manager:

Key Concepts: Device Interactions

Key Concepts: Policy Abstraction

Key Concepts: Device Interactions

To benefit from Security Manager, you must understand its relationship to other configuration applications and to the devices you are managing. As a standard practice, you should discover devices once only and use no method other than Security Manager to make configuration changes to those devices. If you do want to use another management application, you should configure Security Manager and the other application to manage specific, non-overlapping portions of the configuration.

The following concepts clarify these pragmatic rules:

No Automatic Out-of-Band Management—Once initial configuration settings are discovered, all changes are made to Security Manager's internal representations of policies and settings. These internal representations are translated to configuration commands and published to the devices during a Security Manager deployment operation. However, Security Manager does not synchronize its internal representation with the device after the initial discovery. Therefore, out-of-band changes, which are changes made outside of Security Manager using the command line interface or another management application, are not reflected in Security Manager.

If you do need to make out-of-band changes, for example, to respond to a network emergency, you should recreate the policy change in Security Manager before the next policy deployment to the device. Consider the following tips:

You can have Security Manager proactively scan the device for out-of-band changes using the Tools > Detect Out of Band Changes command. Use the results to make changes to policies in Security Manager. If changes are identified that are simply the same commands on different lines in the configuration file, you can ignore those differences. Look for semantic differences only. (This feature is available for ASA, FWSM, PIX, and IOS devices, but not for IPS devices such as the AIP-SSM.)

Security Manager automatically overwrites out-of-band changes during deployment, but you can control how Security Manager reacts when it comes across out-of-band changes. The default action is for Security Manager to warn you about the detected out-of-band change and then overwrite it. You can instead specify that Security Manager should stop the deployment; this will give you the opportunity to update policies without losing what might be desired configuration changes. You can change the Out of Band Change Behavior setting either when you create a deployment job, or you can change the system default on the Tools > Security Manager Administration > Deployment settings page.

Avoid Device Rediscovery—When a device is discovered, Security Manager generates local policy rules and configuration settings to match the discovered configuration. Any changes you make in Security Manager after the initial discovery, such as defining policy objects, object groups, and shared policies, are unique to Security Manager's policy model. When configurations are deployed, some policy objects and all shared policies are flattened, losing the policy object and shared policy assignments.

If you rediscover at a later date, Security Manager replaces the configuration defined in its database with a fresh configuration of all local policies and only those policy objects discoverable from the device. You lose any shared policy assignments and undiscoverable policy object usage. If you do have to rediscover a device, for example, after making a major device software version upgrade, the extent of data loss is related to the extent to which you use shared policies for the device configuration. Before rediscovering a device, make note of shared policy usage on the device so that you can easily reassign shared policies where desired.

Manage the Active Device for Failover Pairs—Some managed devices, such as the ASA, support standby or failover devices. The active devices are responsible for synchronizing policy changes with the failover device through a dedicated link. At any point in time, one of the devices is active and the other is in standby mode. Security Manager publishes its configuration to the active device, which appears at a single IP address regardless of which physical device is active. Therefore, you should never attempt to manage the standby device in Security Manager. Define the active device, and that device will synchronize any policy updates it receives from Security Manager with its standby device.

Explicitly Unmanage Policy Types You Want to Manage with Other Applications—Security Manager does not manage every possible device command, but system defaults assume that you want to use Security Manager to manage all policies that it can configure. However, you can change the system setting. For example, if you want to use a different management application to manage user accounts, you can explicitly "unmanage" the user account policies in Security Manager. When you unmanage a policy type, Security Manager completely ignores the commands related to the policy: these commands are not discovered, they are not deployed, they are not evaluated for out-of-band changes, and the policies related to them are not even displayed in Security Manager. You can unmanage policies for ASA, PIX, FWSM, and IOS devices, but not for IPS devices. There are some policy types, such as firewall policies, that you cannot unmanage. To control which policies are managed, use the Tools > Security Manager Administration > Policy Management settings page.

Key Concepts: Policy Abstraction

The true power of Security Manager lies in the effective use of shared policies and policy objects. By analyzing the similarities in the security policies for different devices, you can develop common policies and assign them to more than one device. Then, you can update a set of devices by updating a single policy or policy object. For more information on the basics of policy types and policy management, see Managing Policies in User Guide for Cisco Security Manager.

The following are the key concepts of policy abstraction:

Device view—In Security Manager, the device view allows you to define local, device-specific rules or assign shared rules to a device. This view is device centric and organizes device-specific policies and other settings, such as interfaces, log settings, banner pages, and device administrative accounts. However, you can convert local rules to shared rules while in Device view, and edit shared rules that are assigned to a device.

Policy view—A view that allows you to define reusable policy rules that can be assigned to a device. If you create a shared policy in Device view, it also appears in Policy view.

Policy Objects—Security Manager allows you to group commonly related objects, whether they are services, users, networks, IP addresses, and so forth. This technique can simplify policy development and increase the clarity of policy rules in Security Manager. For example, you can group network protocols to reflect applications, network objects to identify hosts with a common operating system or asset type, or users to define appropriate remote access VPN availability.

Local vs. Shared Policies—Local policies refer to policies that are defined for a single device; they are written from the perspective of a device looking at its attached networks and resources. Any changes that you make to a local policy affect only that device.

Shared policies exist separately from any single device. You create shared policies when you want to define a security policy that should be identical, or broadly similar, on a set of devices. You then assign the shared policy to the desired devices. When you need to make a change to the policy, you change the shared policy, and the configuration of all assigned devices is automatically changed during deployment.

The power of shared policies is that they can help you quickly configure like devices used under similar situations, and they can represent abstract concepts, such as streaming audio/video, TelePresence, remote worker, and network guest.

Rules Policies—Some policies are rules-based, typically converting to commands that include access control lists (ACLs). These rules policies have individual rules that are sorted in a meaningful order; typically, the device processes the rules from top to bottom and applies the policy of the first rule that matches the traffic being analyzed. When configuring a rules-based policy, the following concepts are important:

Mandatory vs. Default Rules—The structure of the rules table depends on whether you configure a local policy or a shared policy. If you configure a local rule-based policy for a single device, the policy contains a flat table of local rules. If you configure a shared rule-based policy, Security Manager divides the rules into two sections: Mandatory and Default. The Mandatory section contains rules that cannot be overridden by the local rules defined in a child policy. The Default section contains rules that can be overridden by local rules. You can define rules in either section and move rules between sections using cut-and-paste. If you add local rules, the Local section is added between the Mandatory and Default sections, and the relationship changes to inheritance rather than sharing.

Inheritance and Local vs. Shared Rules—A rules policy assigned to a device can include both local and shared rules. Thus, you can create a shared policy that defines common, global restrictions and requirements that apply to more than one device (for example, prohibiting certain types of services), and per device, add local rules to account for variations in traffic patterns in the networks attached to the device. With rules policies, you do not have to decide between using a local or shared policy; you can combine the best of both policy types.

When you use a combination of shared and local rules, the relationship is called inheritance. The local policy rules inherit the mandatory and default rules from the inherited shared policy. You can also nest inheritance, so that you inherit policies from a sequence of shared policies. The Local policy layer always resides between the nested Mandatory and Default sections of all inherited policies.

Copying shared and local policies—To ease policy development, you can copy a shared policy and modify it. This feature accelerates development of policy rules based on a portion of the referenced objects. For example, if you want to define a shared policy that represents an application for the same group of network nodes, you can copy a shared policy that references those objects and modify the services inspected.

You can also copy local, device-specific policies. This can make it easier to configure a new device that has characteristics similar to an existing device, or to migrate from one device type to another when upgrading the hardware in your network (assuming a high degree of similarity between the old and new device). Copying local policies provides the ability to copy policies that do not exist as shared policies, such as interface or virtual sensor policies. After copying the policy, you frequently need to make some edits so that the policy applies correctly to the target device. For an example use case for copying local policies, see Migrating from 1800/2800/3800 ISRs to 1900/2900/3900 ISRs Using Cisco Security Manager 3.3.1 on Cisco.com.

Adding the ASA to the Security Manager Inventory

You add devices to the Security Manager inventory so that the Security Manager server can communicate with the device, analyze its policies, and eventually modify those policies. For more information about adding devices and device management, see Managing the Device Inventory in the User Guide for Cisco Security Manager, particularly the topic "Adding Devices to the Device Inventory."

For this example, we assume you have an adaptive security appliance (ASA) with a single context in routed mode and that it is configured to accept HTTPS connections from the Security Manager server.


Tip Ensure that the device is configured with a management IP address and use that address for discovery.



Step 1 In Device view, select File > New Device or click the New Device (+) button above the Device selector to open the New Device wizard.

Step 2 Select Add Device from Network and click Next.

The Device Information page appears.

Step 3 On the Device Information page, specify the following key values under Identity:

Host Name—asa-fw

Domain Name—example.com

IP Address—10.100.10.1

OS (Operating System) Type—ASA

The following values are also in the Identity group:

Display Name—This field is automatically populated with either the hostname.domain_name values or the IP address, whichever you typed in first. The display name is the text used in Security Manager to refer to a device, for example, in device selectors and reports. It does not necessarily have to relate to anything configured on the device. However, for practical purposes, allowing the name to default to either the hostname or IP address is most often appropriate, but use whatever display name works most effectively for your organization.

Transport Protocol—For ASA devices, this is a read-only field. You must use HTTPS (SSL) for device communication.

System Context—Do not select this option because the device is in single-context mode. You select this option only when discovering multiple-context ASA, PIX, and FWSM devices when you are discovering the system execution space, which allows you to add all security contexts defined on the device in one action.

Step 4 Verify that the Discover Device Settings group is configured to discover Policies and Inventory, and that Platform Settings and Firewall Policies are selected for policy discovery.

Also select RA VPN Policies if you have remote access VPN configured on the device.

The following graphic shows how the Device Information page should look. Click Next to continue.

Step 5 On the Device Credentials page, enter the user names and passwords required to log into the device. You must enter the primary device credentials—the traditional User EXEC mode and Privileged EXEC mode passwords.

In this example, the user account admin is used. Security Manager masks the passwords.


Tip The HTTP Credentials group is mainly for device types that allow more than one access method, such as routers. You can also use it to specify non-default connection values, for example, if the device is configured to use a port other than 443 for HTTPS/SSL communications. If you accept the default, where Use Primary Credentials is selected, the primary credentials are used and anything specified in the HTTP Credentials group is ignored.


The following illustration shows how the page should look.

Step 6 At this point, you can either click Next, which allows you to assign the device to a device group, or click Finish to complete the wizard and add the device. If you click Finish, the device is not added to a group unless you selected a default device group. For the purposes of this example, we will click Next and create a device group.

Whether you click Next or Finish, Security Manager tests device connectivity using the supplied credentials. You cannot discover the device unless the test succeeds.

Step 7 On the Device Grouping page, do the following to create a new group and to select it for the ASA device.

Assuming that you do not already have device groups, there should be two "group types" listed on the page, Department and Location. These are predefined top-level group types; you can use them or delete them as you see fit. All device groups exist within a group type (of which there can be eight). For purposes of this example, we will create a new group type and a group within the type.


Tip Device groups are for convenience. There are several operations you can perform, such as assigning shared policies or selecting devices for deployment, where you can select a device group as a short cut for selecting all the devices in the group. If you create device groups based on how you want to manage the device, it can potentially simplify your procedures.


a. From either the Department or Location drop-down lists, select Edit Groups. This command opens the Edit Device Groups dialog box. It does not matter which drop-down list you use; the point is to get to the Edit dialog box, where you can create, edit, or delete all device groups and group types.

b. In the Edit Device Groups dialog box, click the Add Type button. A new group type appears with the name "New Group Type" selected.

c. Type in the name of the new group type and press Enter. For this example, type in ASA Devices. (If you need to rename a type or group, select it, then click it again to make the text editable.)

d. With the ASA Devices group type selected, click the Add Group to Type button. A device group with the name "New Group" appears under the ASA Devices group type.

e. Type in the name of the new group and press Enter. For this example, type in ASA with AIP-SSM. The following graphic shows how the Edit Device Groups dialog box should look at this point.

f. Click OK. The group is added to the database and is automatically selected in the New Device wizard's Device Grouping page. Note that you could select more than one group for a single device (the device configuration is not different group to group; there is only one device configuration).

Step 8 Click Finish.

The Discovery Status dialog box opens to show the progress of the device discovery. The Messages list shows messages generated during the discovery; select a message to see detailed information in the Description and Action fields. Figure 1 shows sample results with the list of unsupported commands displayed. These are commands that Security Manager cannot provision with its native security policies. The next section will explain how to analyze these commands for FlexConfigs.


Tip You can retrieve this discovery information after you close the dialog box. To review discovery results at any time, including the list of unsupported CLI commands, select Tools > Device Discovery Status.


Figure 1 Device Discovery Details: Unsupported CLI Commands Discovered

Step 9 Click Close when the discovery is completed and you have analyzed the results.

The device selector is updated to include the new device and the device is automatically selected. You can use the Policies selector to examine how Security Manager translated the device configuration into Security Manager policies.


Configuring Unsupported Commands Using FlexConfig Policies

Unmanaged commands that were detected during discovery provide an opportunity to evaluate whether to use FlexConfig policies in their place or whether to leave them unmodified on the device. The following sections show how to evaluate those discovered, unmanaged commands and to determine whether to define policies to address the unsupported ASA commands in our example device. For more information about FlexConfigs, see Managing FlexConfigs in the User Guide for Cisco Security Manager.

Tips for Using FlexConfig Policies

Evaluating Unsupported Commands for FlexConfig Configuration

Tips for Using FlexConfig Policies

Following are some general tips about using FlexConfig policies:

Managed commands are generated by Security Manager. Security Manager is responsible for defining, editing and removing all commands of this type on a device. Unmanaged commands are not generated by Security Manager and therefore, it does not change any commands of this type on the device unless you have explicitly overwritten the commands using a FlexConfig policy.

The FlexConfig policy is made up of one or more FlexConfig policy objects, and these objects can either be placed before (prepended) or after (appended) the commands generated by Security Manager.

Security Manager includes a set of predefined FlexConfig policy objects. Before creating a new object, evaluate whether an existing object can either fill your needs directly, or be copied to form the basis of a new object.

For example, the ASA_virtual FlexConfig object defines virtual HTTP and Telnet servers, which you might need to configure if you use firewall AAA rules to control network access through an ASA (which is not the same as AAA control for logging into the ASA). If you need to configure virtual servers for this purpose, you could:

Assign the ASA_virtual FlexConfig object to the FlexConfig policy for the ASA.

In the ASA device properties (right-click the device and select Device Properties), open the Policy Object Overrides list and click Text Objects. Then, find the virtualHttpIpAddress and virtualHttpTelnetAddress objects and create overrides that specify the appropriate IP addresses for these virtual servers on this specific ASA. You can determine which text objects are used as variables in a FlexConfig object by editing it; system-defined objects open in read-only mode.

FlexConfig objects can include one-time commands, which are commands that are issued once to a device without error. In other words, if they are issued more than once, you will get an error reporting that the command has already been set.

For one-time commands, you must remove the command from the FlexConfig object before you generate and deploy the policy. If your FlexConfig objects are well designed, the one-time commands are segregated into separate objects so that you can simply remove the entire object from the FlexConfig policy. You need to include the one-time commands again only if the settings are somehow cleared, or if you need to make some other change to the setting.

Deleting a one-time command from the FlexConfig policy does not disable it; one-time commands have corresponding disable commands, such as no threat-detection basic-threat to disable a command.

If you include a command that enters a submode, such as interface configuration mode, you need to include the appropriate exit commands to leave the mode.

You can disable and then re-enable a command to prevent getting an error when deploying one-time commands; however, use this option only when there are no dependencies on a command.

If you are deploying to a device, you should remove most appended commands after the initial deployment. This is especially true for object groups, where any unbound object group is replaced in the Ending Command section during command generation, then re-sent each time the configuration is deployed to a device. The device displays an error because the firewall device shows that the object group already exists. If you are deploying to a file or to an Auto Update Server or Configuration Engine, the appended commands should remain.

Security Manager assumes you know what you are doing when you use FlexConfigs. Although FlexConfigs are evaluated for syntactical errors, they are not evaluated for semantics. For example, you can send a well-formed text string to the device that is not actually a valid command. If you make semantic errors, you will see deployment errors.

Evaluating Unsupported Commands for FlexConfig Configuration

The following procedure provides an example of the process you can use for evaluating whether to configure unsupported commands in FlexConfig objects.


Step 1 First, review the unmanaged command output created during device discovery (Figure 1):

Line 3:terminal width 255
Line 64:no asdm history enable
Line 97:threat-detection basic-threat
Line 98:threat-detection statistics access-list
Line 99:ssl encryption des-sha1 rc4-md5
Line 110:prompt hostname context 


Tip Some commands might occur within the context of other commands, where the commands before and after the unsupported command are relevant to understanding the usage of the unsupported command. You can use Configuration Archive to view the complete discovered configuration, unsupported commands and all. Select Tools > Configuration Archive, then select the device, select the discovered configuration, then click View.


Following is an analysis of each command:

Line 3 sets the width of the terminal window to 255 characters; a command that is important only when connecting to the device through an SSH console. This type of command is unmanaged by Security Manager because it is aesthetic and specific to viewing screen output in CLI mode. It is not a candidate for FlexConfig.

Line 64 turns off history tracking in ASDM, which is an alternate administrative application. Cisco Security Manager maintains its own revision tracking and rollback abilities and does not use the ASDM history buffer. Disabling this feature returns system resources to the ASA device. However, it is a one-time command, meaning that once the value is set, it is retained. Therefore, it is not a candidate for FlexConfig.

Line 97 enables basic threat detection. It is a one-time command and not a candidate for FlexConfig.

Line 98 enables access list statistics if they were previously disabled. It is a one-time command and not a candidate for FlexConfig.

Line 99 specifies that SSL/TLS connections must use either the DES cipher with SHA1 hash function or the RC4 cipher with an MD5 hash function. It is a one-time command and not a candidate for FlexConfig.

Line 110 specifies that the hostname and context (if any) be printed at each prompt. It is a one-time command and not a candidate for FlexConfig.

So none of these commands are good candidates for FlexConfig, and we do not need to configure a FlexConfig policy. However, let us consider an example that would require FlexConfigs.

Step 2 For sake of illustration, lets assume that the ASA has the following command configured:

timeout tcp-proxy-reassembly 00:00:50

Security Manager supports most of the timeout command settings, which are configured in the Platform > Security > Timeouts policy. However, Security Manager does not support configuring the TCP proxy reassembly timeout value. Because this is not a one-time command, meaning you can reissue the command, you could create a simple FlexConfig object to recreate the setting. Keep in mind that you need to do this only if you want to control the value through Security Manager, rather than simply changing it in the CLI if the need ever arose.

Following are the steps required to recreate the command in the FlexConfig policy. Note that in this example, we create the FlexConfig policy object while editing the FlexConfig policy. You can also create the object in the Policy Object Manager (select Tools > Policy Object Manager).

a. Select the FlexConfig policy for the ASA, which is at the bottom of the Policies selector.

b. Click the Add (+) button to open the FlexConfigs Selector dialog box. This dialog box lists all existing FlexConfig objects.

c. Click the Create (+) button beneath the list of available FlexConfigs to create a new object. This opens the Add FlexConfig dialog box.

d. Enter a name for the object, for example, Custom_ASA_Timeout_TCP_Proxy_Reassembly.

e. Because the timeout command has no dependencies, you can use either Append or Prepend for the FlexConfig type. We will leave the Type as the default: Append.

f. Type the following text into the body of the FlexConfig object.

timeout tcp-proxy-reassembly

For purposes of illustration, we are going to use a variable for the timeout value rather than simply typing in 00:00:50. By using a variable, you could reuse the FlexConfig object for other ASA devices, and use device overrides to specify different timeouts if desired.

g. Right-click in the space after the command you typed in and select Create Text Object. This command is a short-cut for creating single value text objects. (If you want to create a complex array, you need to open the Policy Object Manager and create the text object there.)

h. In the Create Text Object dialog box, enter TCP_proxy_timeout for the object name, and 00:00:50 for the object value:

i. Click OK. The object is added to the FlexConfig and shown in the variables list. It is also added to the system as an independent Text object, which you will be able to find in the Policy Object Manager or in any Text Object selector. By default, text objects created this way are configured to allow device-level overrides. The following illustration shows how the object should look at this point:

j. Click the Validate FlexConfig button above the body (circled in the graphic above) to have Security Manager evaluate the syntax of the object. Validation ensures that there are no syntactical problems with the object, such as undefined variables. You should get the message that validation has completed with no errors.

k. Click OK to save the object. The object is now listed in the FlexConfigs Selector dialog box in the list of Available FlexConfigs.

l. Select the object, click >> to move it to the Selected FlexConfigs list, and click OK. The following illustration shows how the FlexConfig policy should look.

m. Click Save to save the FlexConfig policy.

n. If you want to, you can verify your work by previewing the configuration using Tools > Preview Config. Scroll to the bottom of the configuration, and appended commands will be listed separated by a few blank lines from the commands generated from Security Manager policies. If configured correctly, the variable will be replaced by the correct value.


Adding the AIP-SSM

Next, add the ASA Advanced Inspection and Prevention Security Services Module (AIP-SSM) that is installed in the asa-fw appliance. While the module physically resides inside the ASA appliance, it is logically a separate device, and that is how Security Manager treats it. You must add it as a separate device. Like the asa-fw device, you can discover the AIP-SSM module and its current configuration and policies. For this example, the device is named asa-aip-ssm, and we assume it is already configured with a management IP address, that the Security Manager server IP address or subnet has been added as an allowed host, and that the device has a basic configuration.


Tip With some devices, such as routers and Catalyst switches, you can discover modules contained in the device when you add the parent device. However, with ASA, you must add the device and its IPS module separately. This is true for all types of IPS module that you can install in an ASA.



Step 1 In Device view, select File > New Device or click the New Device (+) button above the Device selector to open the New Device wizard.

Step 2 Select Add Device from Network and click Next to open the Device Information page.

Step 3 On the Device Information page, specify the following values under Identity:

Host Name—asa-aip-ssm

Domain Name—example.com

IP Address—10.100.10.14

OS (Operating System) Type—IPS

The required transport method is HTTPS (SSL), and the display name should be derived as asa-aip-ssm.example.com.

Step 4 Verify that the Discover Device Settings group is configured to discover Policies and Inventory, and that Platform Settings and IPS Policies are selected for policy discovery.

The following graphic shows how the Device Information page should look. Click Next to continue.

Step 5 On the Device Credentials page, enter the user names and passwords required to log into the device and click Next.

Security Manager tests device connectivity, which must succeed.

Step 6 On the Device Grouping page, select the ASA with AIP-SSM device group from the ASA Devices list. (You created this device group and group type when adding the ASA.)

Step 7 Click Finish.

The Discovery Status dialog opens to show you the progress of the device addition and policy discovery. When discovery is finished and you close the dialog box, the Device selector in Device view should look similar to the following illustration:


Configuring the Service Policy for IPS Inspection

To enable the AIP-SSM to inspect traffic that passes through the ASA, you must configure a service policy to identify the traffic to inspect. The following topics explain more about how the AIP-SSM inspects traffic and how to configure the necessary policy on the ASA.

Understanding How the AIP-SSM Works

Key Concepts: Service Policy Rules

Identifying the Traffic for IPS Inspection

Submitting and Deploying Changes to the Firewall

Understanding How the AIP-SSM Works

The Advanced Inspection and Prevention Security Services Module (AIP-SSM), and the similar lower-end Advanced Inspection and Prevention Security Services Card (AIP-SSC), is a service module that you install into an ASA 5500 series security appliance. The AIP SSM/SSC runs advanced IPS software that provides proactive, full-featured intrusion prevention services to stop malicious traffic, including worms and network viruses, before they can affect your network.

The AIP SSM/SSC runs separately from the adaptive security appliance, and you need to add it to the device inventory as a separate device. It is, however, integrated into the ASA traffic flow. The AIP-SSC does not have any external interfaces. The AIP-SSM has one external interface used for management only.

When you configure the AIP SSM/SSC, you need to configure the service policy rules on the host ASA as well as the IPS policies on the AIP SSM/SSC device. The service policy rules determine which traffic is inspected by the IPS module. When you identify traffic for IPS inspection, the traffic flows through the ASA and the AIP SSM/SSC as follows:

1. Traffic enters the ASA.

2. Firewall policies, such as interface access rules, are applied.

3. Traffic is sent to the AIP SSM/SSC over the backplane when you operate in inline mode. If you configure the system to use promiscuous mode, a copy of the traffic is sent to the AIP SSM/SSC.

4. The AIP SSM/SSC applies its security policy to the traffic and takes appropriate actions.

5. Allowed traffic is sent back to the adaptive security appliance over the backplane. In Inline mode, the AIP SSM/SSC may block some traffic according to its security policy; in other words, that traffic is not passed back.

6. VPN policies are applied (if configured).

7. Traffic exits the ASA.

The following illustration depicts traffic flow when running the AIP SSM/SSC in Inline mode. In this example, the AIP SSM/SSC automatically blocks traffic that it identifies as an attack. All other traffic is returned to the ASA.

The next illustration depicts traffic flow when the AIP SSM/SSC is running in Promiscuous mode. In this example, the AIP SSM/SSC sends a shun message to the ASA for traffic it has identified as a threat.

Key Concepts: Service Policy Rules

In Security Manager, you use the Service Policy Rules > IPS, QoS, and Connection Rules policy to configure service policy rules. Following are some key concepts that will help you understand this policy (and similar rules-based policies, such as access rules):

Modular Policy Framework (MPF)—A framework for defining reusable policy objects that are assigned to an ASA or PIX Firewall interface. This framework is specific to the ASA/PIX software, and is modeled by Security Manager in policies that mask, to some extent, the way the framework exists in the CLI configuration. This framework includes the following three types of objects that Security Manager generates as needed. One of the benefits of using Security Manager is that you use a wizard to generate your rules, and you do not need to completely understand the complex CLI implementation of these objects, whereas in CLI, you would have to configure each of these separately.

Class map—Defines what traffic to pass to an AIP-SSM. The selection of traffic is made either through an ACL or a match statement. Class maps are referenced by a policy map.

Policy map—Defines the actions to take on traffic. The traffic is specified by one or more class maps.

Service policy—Identifies the interfaces to which a policy map is assigned. The service policy applies the policy map to an interface in an ASA appliance.

Interface Role policy objects—Interface role objects are a Security Manager abstraction. Many types of policies require that you identify the interfaces to which the policy applies. However, instead of typing in "GigabitEthernet0/1" or "inside," you can create an interface role object that specifies a pattern for interface names. If you name your interfaces consistently, and use them for the same purposes, you can create interface role objects that are named for the services supplied by those interfaces. For example, if you always use the same interface with the same name for VPN connections, you could create an interface role named "VPN_Interface" that contains the name of the interface.

Interface role objects are most helpful when there are more than one interface that typically supplies a service, or when you know there are certain policies that you will want to apply to every GigabitEthernet interface, no matter how many there are. For example, an interface role defined with the string "GigabitEthernet*" will match all GigabitEthernet interfaces on any device. Note that the string applies to the interface name, not the port name, so if you named the GigabitEthernet0/1 port on an ASA "inside," the string match is compared to "inside," not to "GigabitEthernet0/1."

Typically, you can use an interface role object for any attribute that requires an interface name. Keep in mind that if a particular attribute allows for the specification of a single interface, if you use an interface role, the role must also resolve to a single interface name on the device.

Policy Object Manager and On-the-Fly Object Editing—The Policy Object Manager collects all policy objects in a single view. Using the Policy Object Manager, you can create, edit, delete, and configure device-level overrides for all available types of policy objects.

However, you can also create and edit policy objects while you are editing policies that use those objects, which is called "on-the-fly editing." One of the benefits of on-the-fly editing is that Security Manager pre-screens policy objects so that you can create only those types of objects that can be used in the policy. For example, if a policy requires an extended access list, you are prevented from creating a standard access list by mistake. If a policy allows a single type of content in an object, such as a single interface name in an interface role object, or a single host IP address in a network/host object, you are prevented from saving invalid content.

Using the Policy Object Manager is good when you have a lot of objects to adjust independently of any particular device or policy. However, if you are creating new objects, you must already know by other means exactly the types of objects that you will need. In many, if not most, cases, configuring objects on-the-fly is the easiest way to configure objects and to identify the objects that you will need.

For more tips concerning policies, see Key Concepts: Policy Abstraction.

Identifying the Traffic for IPS Inspection

Use the IPS, QoS, and Connection Rules service policy to configure the rules required to enable IPS inspection by the AIP-SSM or any other ASA-hosted IPS module.

For this example, we will define IPS inspection on the internal interface (named "inside") using a shared policy with two rules:

A general rule that sends all traffic to the AIP-SSM for IPS inspection. This diverted traffic will be inspected by the active IPS signatures in inline mode, which means that any traffic failing to pass inspection is dropped.

As explained in Understanding How the AIP-SSM Works, traffic is first processed by the access rules attached to the interface. Therefore, an IPS, QoS, and Connection Rules policy that applies to "all" traffic is in reality applying to "all traffic that has not already been dropped by the interface access rules."

Because the interface access rules have already filtered unwanted traffic from the ingress, you might need only a single, simple rule to perform IPS inspection on all traffic.

The configuration of this rule is explained in Create the Shared Policy and Default Rule for Inspecting All Traffic.

The purpose of the second rule is mainly to illustrate how various types of policy objects are used, and to explain policy sharing and inheritance by example. A network management station is exempted from IPS inspection. The following procedures create this rule:

Add a Local Rule to Exempt the Management Station from IPS Inspection. This procedure shows how to add local modifications to a shared policy by using an inheritance relationship.

Convert Local Rules to Shared Rules. This procedure shows how to generalize the local rule and to turn it into a mandatory rule in the shared policy. The procedure uses device-level policy object overrides so that local (device-specific) modifications can be made to a rule by overriding the value of a policy object used in the rule.


Note If you find that some of your traffic is being dropped unintentionally, you can define Mandatory rules to exempt that traffic from being sent to the AIP-SSM. For example, you would want to exempt any crypto traffic or a custom application that does not conform to relevant RFCs.


Create the Shared Policy and Default Rule for Inspecting All Traffic

The following procedure shows how to create the shared policy and add the initial rule, which sends all traffic to the AIP-SSM for IPS inspection.


Step 1 Select View > Policy View, or click the Policy View button in the toolbar, to open Policy view.

Step 2 In the Policy Types selector, open the PIX/ASA/FWSM Platform folder, then open the Service Policy Rules subfolder.

Step 3 Right-click the IPS, QoS, and Connection Rules policy in the Service Policy Rules folder and select New IPS, QoS, and Connection Rules Policy. The Create a Policy dialog box opens.


Tip You can also click the Create a Policy (+) button beneath the Policies list or right-click in the Policies list itself. However, if you right-click in the Policies list for policies that can be inherited, you will most likely create a policy that has an inheritance relationship to an existing policy. To remove the inheritance relationship, right-click the new policy, select Inherit <policy type> to open the Inherit Rules dialog box, then select "No Inheritance" and click OK.


Step 4 In the Create a Policy dialog box, type in the name of the policy and click OK. For this example, type in AIP-SSM_IPS_Inspection.

The following illustration shows how the Policy Type and Policies selectors and the new empty policy should look at this point, assuming that you do not already have shared policies defined.

Step 5 When configuring shared rules-based policies, you must first decide which section in which to create the rule. The Mandatory section defines rules that cannot be overridden for individual devices, whereas you can override the rules defined in the Default section. Additionally, rules policies are processed by the device on a first match wins basis.

Thus, for our rule that will send all traffic to the AIP-SSM for IPS inspection, if we place it first in the Mandatory list, no other rule we define will be processed. Therefore, when creating a broad rule that is supposed to apply to all or most traffic, you typically want to add the rule to the Default section.

Hence, select the AIP-SSM_IPS_Inspection Default section heading in the body of the policy.

Step 6 With AIP-SSM_IPS_Inspection Default selected, click the Add Row (+) button beneath the rules table. The button is on the far right of the window.

The Insert Service Policy (MPC) Rule wizard opens at step 1, Configure a Service Policy.

Step 7 In step 1 of the wizard:

Ensure that Enable The Current MPC Rule is selected. If you ever need to temporarily turn off a rule, you can edit the rule and deselect this check box. That way, you can suspend a rule without deleting it from the table, making it easy to reconfigure the rule when it is again needed.

Select the Interfaces radio button, then click Select to open the Interfaces Selector dialog box. Select the Internal interface role object in the Available Interfaces list and click >> to move it to the selected list.

The Internal interface role object is a pre-defined interface role that includes interface name patterns that are typically associated with interfaces that are attached to internal networks. In this case, we are assuming that the ASA has an interface named "inside." You can view the contents of an object by selecting it in the list and clicking the Edit button (a pencil icon). Pre-defined objects are opened in read-only mode, whereas you can change the content of objects that you created.


Note There is nothing special about the name "Internal." The Internal interface role will match only those interfaces whose names match the name patterns defined in the object. If none of the interfaces that you use to attach to your internal network match these name patterns, the Internal interface role object will not in fact match your internal interfaces. Rather than selecting the Internal interface role object, you can type in the name of a specific interface (for example, GigabitEthernet0/1), or create a new interface role object that fits your organization's naming scheme. You can click the Create (+) button in the object selector to create a new object.


The following illustration shows how the page for step 1 should look.

Step 8 Click Next to proceed to step 2, Configure the Traffic Class.

Step 9 Accept the default traffic class Use class-default As The Traffic Class. The class default is all traffic.

Step 10 Click Next to proceed to step 3, Configure the Actions.

Step 11 On the Intrusion Prevention tab, make the following selections:

Select Enable IPS For This Traffic. This option makes the rule apply to IPS inspection.

For IPS Mode, accept the default, which is Inline.

For IPS Card Failure, accept the default, which is Open. If the AIP-SSM is unavailable because it is in reset or shutdown mode, the fail mode determines what happens to traffic that is selected for IPS inspection. Because traffic has already been processed by interface access rules to remove unwanted traffic, failing open, so that traffic is allowed to pass through the ASA, is typically the desirable policy. However, if your organization requires a more aggressive stance, select Close. In fail-close mode, the traffic is dropped unless it can first be passed to the AIP-SSM.

The following illustration shows how the page for step 3 should look.

Step 12 Click Finish. The rule is added to the shared policy, which should now look like the following illustration.

Step 13 Click Save to save the policy. The save button is in the lower right corner of the window.

Step 14 Before adding the second rule, we will assign the shared policy to the ASA. When in Policy view, you can easily do this by clicking the Assignments tab above the policy.

Step 15 On the Assignments tab, the device list is pre-filtered so that only devices to which the policy can apply are listed. Find the asa-fw.example.com device, select it and click >> to move it to the Assigned Devices list. Click Save to save the assignment. The tab should now look as follows.

Step 16 Switch to Device view (select View > Device View), select the asa-fw.example.com device, and select the IPS, QoS, and Connection Rules policy from the policy selector. The policy will show the content of the shared policy, and the banner above the policy will indicate the name of the shared policy that is assigned to the device, as shown in the following illustration.


Add a Local Rule to Exempt the Management Station from IPS Inspection

Let us assume that there is a workstation on the internal network that is used as a management station for managing the internal network devices. By experience, you know that the behavior of this workstation can result in a high number of false-positive IPS events. You also know that the workstation is maintained and controlled in such a manner that infection is unlikely.

There are two ways to handle this type of host: you could create event action filter rules in the AIP-SSM configuration to remove event actions from events generated by the host; or, you could create a rule in the ASA to simply never do IPS inspection for traffic that has the management station as the source address.

For our purposes, we will take the latter approach and exempt the management station from IPS inspection. To do this, we will have to create a rule that uses an ACL to identify the management station as exempt, and incorporate the ACL into a unique traffic class. We will create these objects on the fly as we configure the rule.


Tip This procedure assumes that you are already in Device view with the ASA selected and the IPS, QoS, and Connection Rules policy displayed. The policy assigned is a shared (not inherited or local) policy.



Step 1 Right-click the IPS, QoS, and Connection Rules policy in the Policies selector and select Add Local Rules. This converts the assignment to inheritance and adds the Local section between the Mandatory and Default sections.


Tip Shared policies do not allow local modifications. That is, you cannot maintain a pure shared policy assignment and add rules that are local to the selected device. Thus, you must convert the assignment to one of inheritance. Note that the policy banner might not update completely to show the new inheritance relationship until you select a different policy and then reselect the IPS, QoS, and Connection Rules policy.


The following illustration shows the inherited policy with a properly-updated policy banner.

Step 2 Select the Local section heading and click the Add Row (+) button beneath the rules table.

The Insert Service Policy (MPC) Rule wizard opens at step 1, Configure a Service Policy.

Step 3 In step 1 of the wizard, select Interface and then select (or type) Internal. Click Next to continue to step 2.

Step 4 In step 2 of the wizard, we will configure a new traffic class to exempt the management station:

a. Select the Traffic Class radio button, then click Select to open the Traffic Flows object selector. The object selector lists all existing Traffic Flow policy objects that are defined in the Security Manager database.

b. In the Traffic Flows object selector, click the Create (+) button to create a new object. The Add Traffic Flow dialog box opens.

c. For Name, enter ExemptNMS.

d. For Traffic Match Type, select Source and Destination IP Address (access-list). The dialog box changes to show additional fields for selecting an ACL policy object.

e. Click the Create (+) button beneath the list of ACL objects to create a new object. This opens the Add Extended Access List dialog box.

f. For ACL name, enter IPS_exempt.

g. In the Add Extended Access List dialog box, click the Add Row (+) button beneath the rules table to add a new rule. This opens the Add Extended Access Control Entry (ACE) dialog box.

h. Make the following selections in the ACE dialog box:

Action—Select Deny. In a traffic flow ACL, deny entries identify traffic that will not be provided the configured service. In this case, the service is IPS inspection, so Deny entries identify traffic that will not be inspected. Permit entries would identify traffic that would be subject to IPS inspection.

Source—Enter 10.100.10.24, the IP address of the management station.

Destination—Enter any.

Service—Enter IP.

The following illustration shows how the ACE dialog box should look at this point.

i. Click OK to save the ACE and add it to the ACL object. The following illustration shows what the ACL object should look like.

j. Click OK to save the ACL object. You are returned to the Add Traffic Flow dialog box.

k. Select the new ACL object. The following illustration shows what the traffic flow object should look like.

l. Click OK in the Traffic Flow dialog box. The object is created and you are returned to the Traffic Flow Selector dialog box with the new object selected.

m. Finally, click OK in the Traffic Flow Selector dialog box. Step 2 of the wizard is updated with the new traffic flow object, as shown in the following illustration.

Step 5 Click Next to proceed to step 3, Configure the Actions.

Step 6 On the Intrusion Prevention tab, make the following selections:

Select Enable IPS For This Traffic. This option makes the rule apply to IPS inspection.

For IPS Mode, accept the default, which is Inline.

For IPS Card Failure, accept the default, which is Open.

Step 7 Click Finish. The rule is added to the Local section of the policy, which should now look like the following illustration. Note that the inherited, shared policy, AIP-SSM_IPS_Inspection, is unchanged by this addition. The new rule exists in the configuration of asa-fw.example.com only.

Step 8 Click Save to save the policy. The Save button is in the lower right corner of the window.


Convert Local Rules to Shared Rules

In Add a Local Rule to Exempt the Management Station from IPS Inspection, we added a local rule to exempt the management station from IPS inspection. By using local rules, we changed a shared policy assignment to an inherited assignment.

Using local rules and inherited policies in this manner is fairly straight-forward. However, it is more complicated than using a pure shared policy, one where there are no local rules. After all, if you ever need to rediscover a device's policies (in which case all shared and inheritance relationships are broken and replaced with purely local policies), it is much easier to reassign a shared policy than it is to reconstruct a inheritance relationship with local rules.

In this example, we will generalize the local rule and convert it to a mandatory rule in the shared policy. We will then "disinherit" the policy, and reassign the shared policy without local rules. This example will demonstrate how you can use device-level overrides on policy objects so that a single rule can have different meanings on different devices. The assumption is that each subnet has its own network management station (which might not be a realistic assumption, but it demonstrates the concepts.)


Tip This procedure assumes that you are already in Device view with the ASA selected and the IPS, QoS, and Connection Rules policy displayed. The policy assigned is an inherited policy with one local rule defined.



Step 1 Select the local rule by clicking on the row. Typically, it is best to click on the rule number, because clicking elsewhere in the row can sometimes select an element within the rule.

Step 2 Right-click and select Copy. This action copies the rule to the clipboard. (You can also select Edit > Copy).


Tip You can also use the Cut command, which copies the rule to the clipboard and also deletes it from the policy. However, in this example, using copy or cut will accomplish the same thing.


Step 3 Select View > Policy View to change to Policy view.

Step 4 In Policy view, select PIX/ASA/FWSM Platform > Security Policy Rules > IPS, QoS, and Connection Rules from the Policy Types selector.

Step 5 Select the AIP-SSM_IPS_Inspection policy from the Policies selector below the Policy Types selector.

Step 6 Select the AIP-SSM_IPS_Inspection Mandatory section heading, then right-click and select Paste. The local rule is pasted to the mandatory rules section of the shared policy.

Step 7 Click Save (lower right of window).


Tip At this point, the asa-fw.example.com device has three rules in the IPS, QoS, and Connection Rules policy; one mandatory rule from the inherited policy, one local rule that is identical to the mandatory rule, and one default rule. The fact that the mandatory and local rule are redundant will not affect processing (if you were to deploy the policy as is), it would simply add unneeded lines to the configuration.


Step 8 Now we will generalize the new mandatory rule. To generalize the rule, we need to change the specific IP address of the management station, 10.100.10.24, to a network/host policy object that allows device-level overrides. This will make it possible to assign the unique management station IP address per device. You can do this either in the Policy Object Manager, or by on-the-fly policy object editing. Because we have not yet used the Policy Object Manager, we will use it in this procedure.

Perform the following steps to create the network/host object and the device-level override for it.

a. Select Tools > Policy Object Manager.

b. In the Policy Object Manager, select Networks/Hosts from the Objects selector. Any existing network/host objects are listed in the right pane of the window.

c. Click the New Object (+) button in the lower right of the window beneath the list of network/host objects, and select Group. This opens the Add Network/Host Group dialog box.


Note You could also select Host. However, the Host, Network, and Address Range objects are designed for creating object Network Address Translation (NAT) rules on ASA 8.3 devices. You can use Host, Network, and Address Range objects to limit the content of the object to specific address types, and leave the NAT fields blank, to accomplish the same thing as a Group object. However, the Group object is the generic network/host policy object for use on all device types.


d. In the Network/Host Group dialog box, make the following specifications:

Name—Enter a name for the object: NMS. (This is short for "network management station.")

Networks/Hosts—Leave the field blank. We are creating what is called an unspecified network/host object. The advantage of using a network/host object with an unspecified value is that Security Manager displays an error if you submit your changes without creating a device-level override on every device using the object; by contrast, when you define the object with a placeholder value (such as, 10.10.10.10), that global value could be deployed by mistake if you fail to define an override.

Allow Value Override Per Device—Select this option so that we can create device-level overrides.

e. Click the Edit button beneath the Allow Value Override Per Device check box to create the device-level override for asa-fw.example.com. Because this is a new object, you are warned that you must first save it before you can define the override (see the illustration below).

Click OK to save the object, and you are next warned that the Network/Hosts field is undefined, and that all devices that use the object will require a device-level override. Click Yes to confirm that you understand and to open the Policy Object Overrides dialog box.

f. In the Policy Object Overrides dialog box, click the Create Override (+) button in the lower right of the window to open the Create Overrides for Device dialog box.

g. In the Create Overrides for Device dialog box, select asa-fw.example.com from the Available Devices list and click >> to move it to the Overridden Devices list, as shown in the following illustration.

h. Click OK. The Edit Network/Host Group multi devices dialog box is opened. This dialog box is essentially the same as the Add Network/Host Group dialog box. When you create an object override, the dialog boxes are essentially identical to the ones that you use to create or edit the base object, with the exception that there is a field that shows the device on which you are creating the override, you cannot edit the object name, and you cannot change whether the object allows device-level overrides.

i. In the Edit Network/Host Group multi devices dialog box, enter 10.100.10.24 in the Networks/Hosts field. This is the IP address of the management station on the network protected by asa-fw.example.com, the IP address we used in the local rule. The following illustration shows how the dialog box should look.

j. Click OK to save the override. You are returned to the Policy Object Override dialog box and the new override is listed.

k. Click Close. You are returned to the original Add Network/Host Group dialog box.

l. Click OK. You are again warned that unspecified network/host objects will require device overrides. Click Yes to continue.

The list of network/host objects is updated to include the new object, and there is a check mark in the Overridable column. This check mark indicates the object can be overridden, not that it has defined overrides. If you double-click the check mark, the Policy Object Overrides dialog box opens, where you can create and manage the overrides.

Step 9 We now have a network/host policy object whose purpose is to define the IP address of the network management station used on a protected network. We also have a device-level override for the object defined on the asa-fw.example.com device. However, the policy object is not yet used in any policies assigned to the device; the object simply exists in the Security Manager database.

To take advantage of the network/host object, we must update the ACL policy object used in the Traffic Flow policy object that is assigned to our service policy rule. The following steps show how to do this:

a. In the Policy Object Manager, select Access Control Lists from the Objects selector.

The right pane is segregated into separate tabs for Extended, Standard, and Web ACL objects, and each tab shows any existing ACL objects. The IPS_exempt ACL object is shown on the Extended tab. The number in brackets next to the name indicates the number of entries in the ACL object.

Note that unlike other policy objects, you can click the + icon next to the object name to display the access control entries defined in each object. However, you cannot selectively edit an ACE; you must edit the object that contains the ACE.

b. Select the IPS_exempt Extended Access Control List object and click the Edit Row (pencil) button. The Edit Extended Access List dialog box opens.

c. In the Edit Extended Access List dialog box, select the one entry in the table and click the Edit Row (pencil) button. The Edit Extended Access Control Entry dialog box opens.

d. Do the following:

Delete 10.100.10.24 from the Source field.

Either type NMS into the Source field, or click Select to select it from a list of existing network/host policy objects.

e. Click OK in the Edit Extended Access Control Entry dialog box to save your changes. You are returned to the Edit Extended Access Control List dialog box and the entry is updated, as shown in the following illustration.

f. Click OK in the Edit Extended Access Control List dialog box to save your changes. You are returned to the Policy Object Manager.

Because this ACL object is already incorporated into the ExemptNMS traffic flow object that is used in the service policy rule, the NMS network/host policy object is now attached to a rule that is assigned to the asa-fw.example.com device.

g. Click Close to close the Policy Object Manager. You are returned to Policy view with the shared policy selected.

Step 10 We can now change the policy usage from inheritance to shared assignment.

a. Click the Assignments tab. Notice that the list of Assigned Devices is now empty, because asa-fw.example.com is no longer assigned the shared policy. Inherited policies are not listed here.

b. Select asa-fw.example.com in the Available Devices list and click >> to move it to the Assigned Devices list.

c. Click Save. You are warned that a local policy will be replaced, and you are given the option to choose whether to assign the policy or inherit the policy.

d. Select Assign Policy `AIP-SSM_IPS_Inspection' and click OK.

This action breaks the inheritance relationship, deletes the local rule, and assigns the updated shared policy to the device. The end result is that the actual security rules that will be configured on the device are the same, but the exemption rule is now modeled differently in Security Manager.

Step 11 To confirm the changes, select View > Device View to return to Device view. The asa-fw.example.com device should still be selected with the IPS, QoS, and Connection Rules policy displayed. The following illustration shows that the rules are now identical to the shared policy rules.

Step 12 If you want to know what these rules look like in device commands (CLI), select Tools > Preview Configuration.

Security Manager builds the commands required to generate the configuration defined in its database for the device. Policies are first validated, and you are notified of any configuration errors or warnings. You must fix errors before you can preview (or deploy) a configuration, but handle warnings as you see fit, because the configuration might be appropriate for your network.

Following are the commands that are generated by these two service policy rules and the objects that they incorporate. Only the commands generated by these rules are shown.

object-group network NMS
 network-object 10.100.10.24 255.255.255.255
access-list CSM_TF_ACL_IPS_exempt__1 extended deny ip object-group NMS any
class-map ExemptNMS
 match access-list CSM_TF_ACL_IPS_exempt__1
policy-map CSM_PM_1
 class ExemptNMS
  ips inline fail-open
 class class-default
  ips inline fail-open
service-policy CSM_PM_1 interface inside


Submitting and Deploying Changes to the Firewall

Once you have updated the policy in Security Manager, you must deploy the policy to the ASA. Changing policies in Security Manager has no effect on the device configuration until you deploy the policies.

"Deployment" is the process by which Security Manager logs into the device and makes changes to the configuration. Typically, you deploy directly to the device, in which case Security Manager sends only the changes to the configuration. However, you can also deploy to configuration files, an intermediate server such as Configuration Engine or Auto Update Server, or use the Token Management System (TMS). We will demonstrate direct-to-device deployment.


Tip The database submission and deployment process is very different based on Workflow mode. This example uses non-Workflow mode. If you are using Workflow mode, add the activity management steps to this procedure.



Step 1 Select File > Submit and Deploy to commit your changes to the policy and to start the deployment process.


Tip Security Manager is a database application and uses the concept of submitting changes to the database. When you work in a non-Workflow configuration session, or a Workflow activity (these are essentially the same thing), all of your changes are isolated from the database. To actually update the "real" configuration kept in the database, you must submit it. During submission, Security Manager validates that the new policies are sound.


When you submit your changes, the Validation Result dialog box appears, presenting any warnings and errors. If you have any errors, you must resolve the errors before you can successfully submit. For example, you cannot submit changes if there are no hosts or networks defined in the Allowed Hosts IPS policy.

Click the Details button to open the Validation dialog box, which organizes errors and warnings by error type and also by device.

Step 2 When there are no errors, and you are comfortable with any warnings or other messages generated by Validation, click OK on the Validation Result dialog box. Security Manager then submits your changes to the database and starts the deployment process, opening the Deploy Saved Changes dialog box.

Step 3 In the Deploy Saved Changes dialog box, select the asa-fw.example.com device.

Security Manager automatically selects all changed devices for deployment, but you can deselect devices to deploy just the ones you want. You can select specific devices, or you can select all the changed devices in a device group by selecting the group.

Because we changed a policy on the ASA but not the AIP-SSM, only the ASA is listed as a changed device in our device group, as shown in the following illustration.

Step 4 If you are unsure of the deployment method that has been configured as the system default, click Edit deploy method, verify that asa-fw.example.com is listed and that the deployment method is Device. (If you are following these instructions using a dummy device, you can change to a File deployment and select a temporary directory as the destination.) Note that you can also change how Security Manager handles out-of-band changes (see Key Concepts: Device Interactions).

Step 5 Click OK to close the Edit Deploy Method dialog box and return to the Deploy Saved Changes dialog box.

Step 6 Click Deploy to deploy the changes.

The Deployment Status Details dialog box appears. You can view the configuration file, and a transcript of the communication session with the device, by double-clicking the icons in the Config and Transcript columns.

To analyze the messages, select the message in the messages list (lower left of window), and the details are displayed in the boxes in the lower right of the window.