Device View


This section describes how to add a device in Device View. You also learn how to configure access control lists (ACLs) from Device View.

Add Device

Cisco Security Manager can add a new device in several ways. The most common way is to import a device and its existing configuration from a live device on a network. Cisco Security Manager can also import a list of devices from other CiscoWorks applications through a Device Credentials Repository (DCR). Cisco Security Manager can also "hotstage" a new device and then deploy the configuration for that new device once the device in activated and placed in the network with its bootstrap configuration.

Figure 9-2 displays an example of initiating the process to create a new ASA device, and Figure 9-3 indicates how to place this new device into a device group. It is common practice to place a device into a device group based upon device location or functional group. However, any type of device group based upon function, asset cost, and so on can be created and used.

Figure 9-2. Add New ASA Device


Figure 9-3. Place New Device in Device Group


Each device in the Cisco Security Manager contains the set of management credentials shown in Figure 9-4. Some of the most used primary credentials include the username, password, and enable password. These primary device credentials can also be stored in a separate device identity server like Cisco ACS. Cisco Security Manager can natively store primary credentials for a device or retrieve these primary credentials from an external Cisco ACS server.

Figure 9-4. Device Credentials


Device credentials are required for the Cisco Security Manager to communicate with the device. Many Cisco security products that use device managers also use HTTPS for centralized management with the Cisco Security Manager.

Configure Access Conrol Lists (ACLs) from Device View

One of the most popular tasks in security operations or security management is configuration and deployment of access control list (ACLs) rules. The selection of a device in Cisco Security Manager from the device list will by default display the access control list (ACLs) rule table for that device. Users can initiate the process to add an access control list (ACLs) to that device by right-clicking on the access control list (ACLs) rule table as displayed in Figure 9-5.

Figure 9-5. Add an Access Control List (ACLs) to a Device


This process to add an access control list (ACLs) results in the display of the Add Firewall Rule wizard. This wizard includes fields for permit/deny, source, destination, service, interfaces, and logging. The Firewall Rule wizard also supplies default values for these parameters. These parameters can be modified, deleted, or added directly in the wizard. You also have the option to select the OK button to create the access control list (ACLs) with the default values.

Cisco Security Manager enables the user to right-click and edit a specific column in the access control list (ACLs) to create the new access control list (ACLs), as shown in Figure 9-6. This figure shows a modification to the destination field in the access control list (ACLs) rule.

Figure 9-6. Right-Click and Edit a Column in the Rule Table


Alternately, you can also select the rule number and then edit the fields of the access control list (ACLs) rule with the Edit Firewall Rule wizard shown in Figure 9-7. The Edit Firewall Rule wizard contains the same fields as the Add Firewall Rule wizard. The Edit Firewall Rule wizard enables the user to manually edit the fields or to add predefined objects for source, destination, and service fields in the access control list (ACLs) rule.

Figure 9-7. Edit Firewall Rule Wizard


Configuring Interface Roles

Cisco Security Manager introduces a feature that enables you to configure an access control list (ACLs) rule for multiple interfaces. The ability to configure an access control list (ACLs) rule for multiple interfaces reduces the administrative burden on security groups and increases security because rules can now be defined for a group of interfaces rather than a single interface. Interface groups or roles are created by matching a name pattern in the interface name. For example, the External interface group or role includes any interface that contains the name "Outside."

Cisco Security Manager creates many default interface groups or roles. In addition to the default roles, users can also manually create any customized interface role. An example of the interface roles that are provided by default includes the following:

  • All Interfaces

  • External

  • Internal

Figure 9-8 provides an example of how to select the External interfaces in the definition of an access control list (ACL) rule. Be sure to examine all the name patterns that are included in any default interface role prior to deploying access control list (ACLs) rules that reference a default interface role. For example, the External interface role group may include Ethernet1 by default, while the Internal interface role may include Ethernet0. Any customized interface role can be created in the Interface Role object in the Policy Object Manager. Interface roles that are created in the Policy Object Manager can be selected in the access control list (ACL) rule table.

Figure 9-8. Apply an Access Control List (ACL) Rule to External Interfaces


Apply Access Control List (ACL) Rules to Multiple Devices

Cisco Security Manager offers several mechanisms to apply a list of access rules to a group of devices. Once you are satisfied with the access control lists (ACLs) that are configured for one device, you can share and copy the access control lists (ACLs) to multiple devices from the Device View. The ability to share policy between multiple devices types is a powerful feature because you can apply this firewall access-rule table policy to a wide variety of devices, including a Cisco IOS router without the IOS firewall feature set. The IOS firewall feature set is also known as Context-Based Access-Control (CBAC). The security policy contained in the access control list (ACL) rule table will be configured with plain access control lists (ACLs) (TCP state information is not maintained for the connection) if the CBAC firewall feature set is not installed on the IOS router.

To share or apply firewall rules to multiple devices from the Device View, you can select a rule table and then initiate the share policy process. The process to share an access control list (ACL) rule policy from one device in the device view to multiple devices is initiated by right-clicking on the access-rule tab for the device and selecting the share policy option. Figure 9-9 displays an example of how to define a policy to be shared or applied to multiple devices. The shared policy must be given a name in order to be referenced and applied to multiple devices.

Figure 9-9. Mark an Access Control List (ACLs) Rule Table to Be Shared


The shared policy in the example shown in Figure 9-10 is named NYCWeb Policy and is composed of all access control list (ACL) rules in the rule table for a particular device. To apply NYCWeb Policy to multiple devices, select the policy assignment option and select the devices, group of devices, or all device options.

Figure 9-10. Assign Shared Access Control List (ACLs) Rule Policy to Multiple Devices


Invoking the Policy Query

As you have learned in this chapter, the Cisco Security Manager product provides the flexibility to apply a policy from one device to a group of devices. The end configuration of a device can be the result of several applied security polices. The access control list (ACLs) rule table for a device will display all the applied policies to that device. Cisco Security Manager contains a policy query function to indicate what specific policies have been applied to a device. The policy query function is invoked from the bottom of the firewall access control list (ACLs) rule table. Invocation of the policy query function enables the user to interactively display any particular rule combinations that have been configured for the device. Examples of the rule types that can be used in a policy query include the following:

  • AAA rules The AAA rules determine what traffic will be sent to the AAA server for authentication.

  • Access rulesaccess control list (ACLs) rules have been discussed in this chapter and previously in this book.

  • Inspection rules Inspection rules are protocol or application inspection rules like the kind you learned about in Chapter 3, "Cisco Adaptive Security Appliance Overview," for HTTP protocol inspection.

  • Web filter rules Web filter rules determine what traffic will be sent from the device to an external web filter URL server.

Figure 9-11 provides an example of the type of information that can be used in a policy query for a device. A policy query is initiated by selecting the Query button at the bottom of the rule table for a device. This example is for a policy query of the access control lists (ACLs) that match a particular source, destination, service, and interface query. Wildcards can also be used for the fields in a policy query. Both full-matches and partial matches of a query are displayed. Figure 9-12 displays the result of the policy query and the matching access control list (ACL). In addition to Policy Query, there is also the rule analysis and hit count functions available in the access control list (ACL) rule table for a device.

Figure 9-11. Policy Query Definition


Figure 9-12. Policy Query Results


Using Analysis and Hit Count Functions

The Analysis and Hit Count buttons are located next to the Query button at the bottom of the access control list (ACL) rule table for a device. The Analysis function performs an analysis on the access control list (ACL) rules in the rule table for the device. The rule Analysis function will display access control list (ACL) rules that conflict or overlap. For example, say that someone has configured a rule to permit any traffic to the web server destination object for web service (in other words, permit source of any destination of "web server" object for service of HTTP). Let's also say that several weeks later another admin added a rule to deny any traffic to the web server destination object for web service further down in the rule table. The Analysis function would display that these rules are in mutual conflict. An example of how Analysis would display a conflict for these access control list (ACLs) rules is provided in Figure 9-13.

Figure 9-13. Analysis


The Hit Count function displays how many times the access control list (ACLs) has been "hit" or triggered on the device. Hit Count statistics are very valuable in debugging scenarios because the user can see which access control list (ACLs) rules are being used on the device to determine which access control list (ACLs) rule is affecting network traffic. The Hit Count functionality is reset to zero when the device is rebooted. The Hit Count utility in the Cisco Security Manager also displays a delta or the number of times that the access control list (ACLs) rule has been triggered on the device since the last time the Hit Count utility was used for that device. In the previous example of the analysis of an access control list (ACLs) rule conflict, one rule would never receive any hits or be triggered on the device because it would be in conflict or superseded by the other conflicting and higher-priority rule.



Setf-Defending Networks(c) The Next Generation of network Security
Self-Defending Networks: The Next Generation of Network Security
ISBN: 1587052539
EAN: 2147483647
Year: N/A
Pages: 112

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net