User Guide for Cisco Security Manager 3.2 - Using Monitoring, Troubleshooting, and Diagnostic Tools [Cisco Security Manager]

Table Of Contents

Using Monitoring, Troubleshooting, and Diagnostic Tools

Device Managers

IDM

PDM

ASDM

SDM

Understanding Communication

Starting Device Managers

Device OS Version Interoperability with Device Managers

Device Connectivity Test

Performance Monitor (Status Provider)

Understanding Performance Monitor as a Status Provider

Configuring Performance Monitor as a Status Provider

Understanding the Events to be Monitored

Device Reachability

VPN Tunnel Status

CPU Usage Threshold

Supported Services and Platforms for Monitoring and Reports

Supported Event Types for Each Service Type

Working with Event Thresholds

IPS Event Viewer

Understanding Communication

Guidelines for Working with IEV from Security Manager

Starting IEV Client

Navigating to IPS Signature Policy in Security Manager from IEV

IPS Signature Policy Lookup from the Realtime Dashboard

IPS Signature Policy Lookup from the Views Tab

Security Manager Access Rule Lookup from Device Manager Syslog

Navigating to ACL in Security Manager from ASDM Syslog

Navigating to ACL from the Log Buffer Viewer

Navigating to ACL from the Real-time Log Viewer

Navigating to ACL in Security Manager from SDM Syslog

Security Manager Policy Table Lookup from a MARS Event

Taskflow for Policy Table Query from MARS Events

Understanding Security Manager Device Lookup

Understanding Access Rule Table Lookup

Security Appliance and Router System Log Messages Supported for Policy Lookup

Understanding Signature Table Lookup

Guidelines for Working with Policy Table Lookup from MARS

Checklist for Policy Table Lookup from MARS

Devices and OS Versions Supported by Both Security Manager and MARS

Bootstrapping Security Manager Server to Communicate with MARS

Adding a Security Manager Server to MARS

Navigating to Access Rule Policy in Security Manager from MARS

Navigating to IPS Signature Policy in Security Manager from MARS

Read-Only Security Manager Policy Lookup Page for Access Rules

Read-Only Security Manager Policy Lookup Page for an IPS Signature

MARS Events Lookup from a Security Manager Policy

Taskflow for MARS Events Query from Policy Table

Understanding MARS Events Lookup

About Historical Events for a Policy

About Realtime Events for a Policy

Obtaining Events for an Access Rule Policy

Obtaining Events for a Signature Policy

Guidelines for Working with MARS Events Lookup from Security Manager

Checklist for Events Lookup from Security Manager

Adding a MARS Appliance to Security Manager

About Authentication for Events Lookup from Security Manager

Navigating to MARS Events from an Access Rule Policy

Navigating to MARS Events from an IPS Signature Policy

Login to CS-MARS ip_address Dialog Box

Using Monitoring, Troubleshooting, and Diagnostic Tools

High network availability is a requirement for large enterprise and service provider networks. Network managers face increasing challenges to providing high availability, including unscheduled down time, lack of expertise, insufficient tools, complex technologies, business consolidation, and competing markets. Monitoring involves the study of network activities and device status to identify anomalous activities or behavior. Diagnosing and correcting network and system faults (outages and degradations) increases service availability and tools to isolate, analyze, and correct faults are highly imperative. The following topics describe the tools that are available in Security Manager 3.1 and later to provide integrated network monitoring services and diagnostic capabilities for troubleshooting significant events in your network and resolution:

•Device Managers

•Device Connectivity Test

•Performance Monitor (Status Provider)

•IPS Event Viewer

•Security Manager Access Rule Lookup from Device Manager Syslog

•Security Manager Policy Table Lookup from a MARS Event

•MARS Events Lookup from a Security Manager Policy

Device Managers

In Security Manager 3.0.1 and earlier, you cannot start device managers for devices that are managed by Security Manager, with the exception of Catalyst 6500/7600 Device Manager (DM 6500/7600). With Security Manager 3.1 and later, you can start device managers for all supported devices, such as PIX security appliances, Firewall Services Module (FWSM), IPS sensors, IOS routers, and Adaptive Security Appliance (ASA) devices. Device managers provide several monitoring and diagnostic features that enable you to get information regarding the services running on the device and a snapshot of the overall health of the system. By starting device managers from Security Manager, you eliminate the need to open an HTTPS connection between your client system and the device you want to monitor.

The Security Manager server is shipped with device manager images for the supported devices. When the Security Manager server receives a request to start a device manager, the corresponding device manager image is downloaded to the Security Manager client. The default location for the device manager images is C:\Program Files\Cisco Systems\Cisco Security Manager Client\cache. The device manager images are uninstalled when you uninstall the Security Manager client on your client system.

Note When you use a device manager that you started from Security Manager, you can only view the existing device configuration. If you perform configuration changes from the device manager, and save the changes to apply them to the running configuration of the device, an error message is displayed stating that the device manager started from Security Manager does not allow you to perform configuration changes on the device.

Although you can modify device configurations using the device manager running on the device, we recommend that you do not make changes to a device configuration outside of Security Manager (an out-of-band change) if you are adding the device to the inventory to be managed by Security Manager.

The following topics describe the device managers that you can start from Security Manager:

•IDM

•PDM

•ASDM

•SDM

IDM

The Cisco Intrusion Prevention System (IPS) Sensor software is an inline, network-based solution, that identifies, classifies, and stops malicious traffic, including worms, spyware/adware, network viruses, and application abuse, before they affect business continuity. IPS sensors analyze network packets and flows to determine whether their contents appear to indicate a network intrusion. Additionally, the IPS solution, in combination with IPS Sensor software, works with other network security resources to provide proactive protection of your network.

Intrusion Prevention System Device Manager (IDM) is an application that enables you to configure and manage your IPS sensors. The web server for IDM resides on the sensor. Security Manager provides the ability to start IDM without the need for IDM to be installed on your IPS sensor. IDM started from Security Manager does not depend on the type of browser. Using IDM, you can monitor whether sensors that are initialized and configured to be managed by IDM can be reached and are functioning properly. When an IPS sensor detects an unauthorized network activity, the alarm generated can be viewed from IDM.

Note The IDM user interface consists of the File and Help menus. There are Configuration and Monitoring buttons in IDM 5.0 and 5.1 whereas IDM 6.0 contains an additional button, Home. IDM constantly retrieves status information to keep the Home window updated with the device details, alert summary, and sensor resource and interface status.

From an IDM started from Security Manager client, you can click the Monitoring button and navigate to the menus in the left-hand pane to configure monitoring. You can use the Monitoring menus to edit the settings that enable you to monitor sensor health.

When you access the online help for IDM 5.1, the Enter Network Password dialog box pops up after you click Yes in the Security Alert dialog box. Enter your username and password and click OK. This behavior is different from the method of accessing online help for other versions of IDMs in which only the security certificate alert appears and you are not prompted to enter credentials to display online help.

See IDM product documentation for more information.

Related Topics

•Device Managers

•Understanding Communication

•Starting Device Managers

PDM

PIX Device Manager (PDM) software provides secure administration of FWSM and PIX Firewalls. Security Manager provides the ability to start PDM without the need for PDM to be installed on your PIX Firewall or FWSM. PDM started from Security Manager does not depend on the type of browser and uses the Java plug-in shipped with Security Manager. PDM manages FWSM Releases 1.1, 2.3 and 2.2 when it runs in single or multiple context modes, and PIX OS versions 6.0 through 6.3.

PDM provides you with a graphical user interface to the firewall and FWSM to administer it. PDM is also compatible with the firewall and FWSM CLI and includes a tool for using standard CLI commands within PDM. With PDM, you can graph many aspects of the firewall and FWSM, including system activity such as CPU and memory utilization, and performance statistics for xlates, connections, AAA, fixups, URL filtering and TCP Intercept. You can also print or export the graphs. Additionally, using PDM, you can monitor DHCP client lease information, interface statistics, Telnet and SSH sessions, current PDM sessions to the firewall, syslog messages based on their level of severity, and VPN tunnels.

The PDM home page lets you view at a glance important information about your firewall such as the status of your interfaces, the version you are running, licensing information, and performance. Many of the details available on the PDM home page are available elsewhere in PDM, but this is a useful and quick way to see how your firewall is running. All information on the home page is updated every ten seconds, except for the Device Information.

See PDM product documentation for more information.

Related Topics

•Device Managers

•Understanding Communication

•Starting Device Managers

ASDM

Cisco Adaptive Security Device Manager ( ASDM) provides security management and monitoring through a web-based management interface. Bundled with ASA 5500 Series Adaptive Security Appliances, PIX Security Appliances, and FWSM, ASDM integrates an array of robust security services to prevent unauthorized administrative access to a device. Security Manager provides the ability to start ASDM without the need for ASDM to be installed on your device. ASDM started from Security Manager does not depend on a type of browser and uses the same Java plug-in that is shipped with Security Manager.

ASDM offers in-depth monitoring and reporting services in addition to the at-a-glance monitoring capabilities on the home page. You can view detailed device status information, including blocks used and free, current memory utilization, and CPU utilization. ASDM also tracks real-time session and performance monitoring data for connections, address translations, and AAA transactions on a per-second basis. Connection graphs enable you to stay fully informed of your network connections and activities. ASDM provides 16 different graphs to display potentially malicious activity, real-time monitoring of bandwidth usage for each interface on the security appliance, and VPN statistics and connection graphs. By running separate instances of ASDM, you can connect to multiple security appliances from a single workstation.

The ASDM home page includes a dynamic dashboard that provides a complete system overview and device health statistics at a glance. You can view important information about your security appliance, such as the status of your interfaces, CPU and memory usage details, number of connected IKE and IPsec tunnels, the version you are running, device information, UDP and TCP connections per second, real-time syslog viewer and traffic throughput. Many of the details available on the ASDM home page are available elsewhere in ASDM, but this is a useful and quick way to see how your security appliance is running. Status information on the Home page is updated every ten seconds.

See ASDM product documentation for more information.

Related Topics

•Device Managers

•Understanding Communication

•Starting Device Managers

SDM

Cisco Router and Security Device Manager (SDM) is a tool that can be used to proactively manage Cisco IOS software-based router resources and security before they affect mission-critical applications on the network. Security Manager provides the ability to start SDM without the need for SDM to be installed on your router. SDM started from Security Manager does not depend on the type of browser. SDM requires no previous experience with Cisco devices or the Cisco command-line interface (CLI). Cisco SDM supports a wide range of Cisco IOS Software releases.

The SDM home page displays system and configuration overview information about your router hardware and software, such as the running configuration, interface-specific firewall policies, and number of static and dynamic routes. The home page provides for faster and easier monitoring of security configurations.

The home page also provides a quick snapshot of detailed VPN status, such as the number of active VPN connections, the name of an interface with a configured VPN connection, the type of VPN connection configured on the interface, and the name of the IPsec policy associated with the VPN connection.

See SDM product documentation for more information.

Related Topics

•Device Managers

•Understanding Communication

•Starting Device Managers

Understanding Communication

Security Manager client intercepts all HTTPS requests made by device managers and sends them to the Security Manager server. The server processes the requests redirected by the client by obtaining information from the device or sending data such as the device manager image to the client. This communication between the client and server is transparent to the device manager, and appears as though there is a direct connection between the device manager and the device. Because the Security Manager client intercepts all requests from the device manager, you do not need to enable SSL on all Security Manager clients for secure access between the client and the server and between the device manager and Security Manager.

When a device manager is started from Security Manager, the Security Manager client starts the correct device manager image for the selected device. If the device manager image is not available in the client cache directory, the image is obtained from the Security Manager server. The Security Manager client starts only one instance of device manager per device and closes the device manager window when you exit the Security Manager client or the idle session timeout period is exceeded.

Related Topics

•Device Managers

•Starting Device Managers

•Device OS Version Interoperability with Device Managers

Starting Device Managers

You can start device managers for all devices (both static and dynamic IP addresses) that are supported by Security Manager. Device managers can be started on all versions of Windows that are supported by Security Manager. The device manager opens in a separate window and you can switch between the Security Manager client and device manager windows at any time. If the device manager window for a device is not active or has been minimized, an error message is displayed when you attempt to start the device manager for the same device. You can either choose to close the previous instance of device manager and start a new window, or cancel the operation to start a fresh device manager instance and activate the device manager window that was started before. The credentials that you supplied while adding the device to Security Manager inventory are reused to start the device manager. If you did not enter the device credentials while adding the device, an error message is displayed when you start the device manager stating that the device credential information for logging in to the device must be entered.

Keep in mind the following guidelines when working with device managers started from Security Manager:

•Security Manager is shipped with device manager images and does not use the device manager image installed on the device to start a device manager.

•All users associated with any of the CiscoWorks Common Services roles except the Help Desk role or any of the predefined Cisco Secure ACS roles have permission to start device managers from Security Manager clients.

•You can start device managers for multiple devices at the same time from the same Security Manager client.

•You can start only one device manager per device per Security Manager client.

•You can start multiple device managers for the same device at the same time from different Security Manager clients systems.

•You can start a device manager from Security Manager even if the device manager is not installed on the device.

•The security appliance and FWSM allow a maximum of 5 concurrent ASDM instances per context, if available, with a maximum of 32 ASDM instances divided between all contexts for security appliance and 80 ASDM sessions between all contexts for FWSM. To display a list of active ASDM sessions and their associated session IDs, use the show asdm sessions command in privileged EXEC mode. ASDM sessions use two HTTPS connections: one for monitoring that is always present, and one for making configuration changes that is present only when you make changes. For example, the system limit of 32 ASDM sessions represents a limit of 64 HTTPS sessions, divided between all contexts.

The maximum number of persistent HTTPS connections that can be established with the security appliance is limited by the system limit for your device model. An error message is displayed if you attempt to exceed this limit. The concurrent firewall connections are based on a traffic mix of 80% TCP and 20% UDP, with one host and one dynamic translation for every four connections.

•PDM allows multiple PCs or workstations to each have one browser session open with the same firewall. A single firewall can support up to 16 concurrent PDM sessions. Only one session per browser per PC or workstation is supported for a particular firewall. The FWSM allows up to 32 PDM sessions for the entire module, and it allows a maximum of 5 concurrent HTTPS connections per context, which can be configurable.

•The number of concurrent IDM sessions is limited based on the IPS platform. IDS-4210, IDS-4215, and NM-CIDS are limited to three concurrent sessions. All other platforms allow ten concurrent sessions.

•If the device has a newer OS version, which is not supported by Security Manager, the most recent version of device manager that supports the OS version on the device is started. If no such version of device manager exists on the client, an error message is displayed when you start the device manager for such a device.

•The device manager started from Security Manager for a Cisco IOS router supports the most recent Cisco IOS software release, regardless of whether the device manager running on the router supports the most recent version of Cisco IOS software or not.

•You need to modify the Cisco Security Agent or any other anti-virus and network firewall software policies on the Security Manager client system to allow the device manager (xdm-launcher.exe) to be cross-launched. Else, the security agent installed on your client system might terminate the execution of the xdm-launcher.exe file when you attempt to start device manager.

•Starting multiple device managers might impact the Security Manager server and client performance. Memory and performance impact on the client is proportional to the number of device managers that are started. Increased number of requests to start device managers or retrieve current information from the device can have an adverse impact on the server performance.

•Device managers started from Security Manager provide read-only view. The home pages of device managers provide a bird's eye view of device health statistics and vital system information. In addition to the dashboard view capabilities on the home page, you can navigate to the other menus and view detailed information on various device configuration parameters.

•Device managers can be started for FWSM blades and ASA devices running in transparent mode (Layer 2 firewall) or routed mode (Layer 3 firewall) and supporting single security context or multiple security context. For FWSM and ASA devices in which multiple independent virtual firewall security contexts exist, you must define a unique management IP address for each security context to start the device manager.

•Although virtual sensors are displayed in the device selection tree, the option to start device manager from the Security Manager client is not available for these sensors.

•The credentials for the device that you entered using the Device Credentials page when you added the device to Security Manager are used to start the device manager for that device; you need not reenter the credentials. However, if you have not entered the device credentials during device addition to the Security Manager inventory, an error message indicates that the device credentials are not available when you start the device manager. Double-click the device in the Device selector, then click Credentials from the Device Properties page to add device credential information to the Security Manager database.

•You must enable HTTPS server on the devices so that the Security Manager client can intercept all requests from device managers and redirect them to the server. See the relevant product documentation for information on how to enable HTTPS server on the devices.

•The preferences that you set to change the behavior of some device manager functions in the read-only view are retained across sessions. For example, if you choose not to display the confirmation prompt when you try to exit the device manager window, that setting applies to all future instances of the device manager.

•You can access the command line interface (CLI) on the device from the Tools menu of device manager started from Security Manager and run several show commands to help you view pertinent information about device configuration parameters. Only show commands can be run from the Tools menu and you cannot execute other commands on the device from device manager.

•From an IDM started from Security Manager client, you can click the Monitoring button and navigate to the menus in the left-hand pane to configure monitoring. You can use the Monitoring menus to edit the settings that enable you to monitor sensor health.

•When you exit the Security Manager client, all device manager windows are closed.

This procedure describes how to start a device manager for a device added to the Security Manager inventory.

Before You Begin

•If an instance of the device manager is already running on your client system, an error message is displayed when you try to start the device manager again for the same device. If you get this error message, you are prompted to confirm whether you want to close the device manager window that was previously started and start it afresh or terminate the start operation. Click OK to close the previous instance of device manager and start a new window.

•Because Security Manager cannot determine the management interface and, therefore, the management IP address when you add a device from a configuration file, the hostname in the configuration file is used as the DNS hostname. If the hostname is missing in the CLI of the configuration file, the configuration filename is used as the DNS hostname. During live device discovery, the DNS hostname in the Device Properties page is not updated with the hostname configured on the device. Therefore, if the DNS hostname that appears on the Device Properties page is not the same as the hostname that you configured on the device, the device manager fails to start.

•Ensure that you have valid and complete configurations for the primary credentials and HTTP connection-related configurations by editing the device credentials information from the Device Properties page.

•If Security Manager cannot reach the device, an error message is displayed and the device manager fails to start. Configure device communication settings, such as device identity, the operating system running on the device, and device communication settings using the Device Properties page to establish a connection between Security Manager and the device.

•If Security Manager cannot reach the device and the device credentials are also not specified, an error message is displayed stating that the credential information for the device is not available when Security Manager checks the device properties before attempting to start the device manager.

•If SSL is not enabled on the device for secure access between the Security Manager server and the device, an error message is displayed when you try to start the device manager. Ensure SSL is enabled on the device so that communication between the Security Manager and device is encrypted. See the relevant product documentation for the command you must configure to enable SSL on the device.

Note DES encryption is not supported on Common Services 3.0 and later. Please make sure that all PIX Firewalls and Adaptive Security Appliances that you intend to manage with Cisco Security Manager have a 3DES/AES license.

Related Topics

•Device Managers

•Understanding Communication

•Device OS Version Interoperability with Device Managers

Step 1 Click the Device View button on the toolbar. The Devices page appears.

Step 2 In Device view, select a device from the Device selector, then do one of the following:

•From the Device selector, right-click a device to display menu options, then select Device Manager.

•Select Tools > Device Manager.

A warning message states that the device manager started from Security Manager does not allow you to perform configuration changes on the device and asks if you want to continue.

Tip To prevent this warning message from appearing in the future for any device, select the Do not show this again check box before continuing.

Step 3 To continue, click Yes.

Note When you start a device manager from Security Manager, the xdm-launcher.exe application, which is the device manager image, is run. If you had set the Cisco Security Agent (CSA) security level to medium or high on your server system, CSA displays a popup window, which indicates that a problem is detected, prompting you to confirm whether you want to allow xdm-launcher.exe to be started. You can either click Yes to allow the xdm-launcher.exe process to run whenever you are prompted to confirm, or modify the CSA policies on the Security Manager client system to allow xdm-launcher.exe to be run always.

If you have configured the CSA policies to prevent the execution of the xdm-launcher.exe process, the icon in the system tray (the red flag) will wave to indicate that CSA has a message for you when you start device manager. To read the message, double-click the CSA icon (the red flag in the Windows system tray) to open the CSA utility. The Messages tab displays by default. CSA considers xdm.launcher.exe as an untrusted application and places this information in the Untrusted Applications edit box. To remove the program executable from the list of untrusted applications, from the Untrusted Applications window of the CSA utility, select the <installation_location>\Cisco Security Manager Client\cache\xdm.launcher.exe entry in the edit box, where <installation_location> is the drive and directory in which you installed Security Manager client and press the Delete key. The restriction on the device manager application is removed and the device manager allowed to be started from Security Manager.

A progress bar indicates the progress of the device manager start and displays what percentage of the launch has been completed. The device manager home page is displayed when the start operation is complete.

Device OS Version Interoperability with Device Managers

Each version of the device manager image is compatible with specific versions of software running on the device. The most recent version of device manager supported for the software version running on the device is started from Security Manager, regardless of the device manager version installed on the device. For example, if SDM 2.2 is installed on a router running Cisco IOS 12.3 release, when you start the device manager for this router from Security Manager, SDM 2.4.1, which is the most recent version of SDM that supports the current and earlier Cisco IOS releases, is started. The version of device manager installed on the device is not taken into consideration. Only the most recent version of device manager is started for all devices.

Note For more information on the minimum hardware requirements for the device manager software, see the relevant device manager product documentation.

Table 22-1 lists the device manager version supported for the software version running on the device when you start the device manager from Security Manager.

Table 22-1 Supported Device Manager Versions and Device OS Versions

Device Manager

Device Manager OS Version

Device OS Version

ASDM

6.0(3)

ASA 8.0(2)¹, PIX 8.0(2)

5.2(2)F

FWSM 3.1, 3.2(1)1

5.2(3)

PIX 7.2, ASA 7.21

5.1(2)

ASA 7.11, PIX 7.1

5.0(7)

ASA 7.0(1) through ASA 7.0(7)1, PIX 7.0(1) through PIX 7.0(6)

PDM

4.1(5)

FWSM 2.2, 2.31

3.0(4)

PIX 6.3

2.1(1)

PIX 6.2, FWSM 1.11

1.1(2)

PIX 6.0, 6.1

IDM

5.1

IPS 5.0(x), IPS 5.1(x)

6.0

IPS 6.0(x)

SDM

2.4.1

Most recent and previous releases of Cisco IOS software running on your Cisco router.

¹^{Device managers can be started for FWSM blades and ASA devices running in transparent mode (Layer 2 firewall) or routed mode (Layer 3 firewall) and supporting single security context or multiple security context.}

Related Topics

•Device Managers

•Starting Device Managers

•Device OS Version Interoperability with Device Managers

Device Connectivity Test

In Cisco Security Manager 3.0.1 and earlier, you cannot validate whether a device that is added to the Security Manager inventory can be reached. Although Security Manager validates the data you entered, it does not validate whether the data you entered will allow you to contact the device. In release 3.1, you can verify whether Security Manager can contact the device when you are adding the device. For more information on device connectivity test, see Testing Device Connectivity, page 6-21.

Related Topics

•Testing Device Connectivity, page 6-21

Performance Monitor (Status Provider)

Effective network management requires the fastest possible identification and resolution of events that occur on mission-critical systems. As a result, the need to monitor and troubleshoot the health and performance of enterprise network security services has become very essential. Security Manager 3.0.1 and earlier enabled you to centrally administer security policies and device settings for either small or large scale networks. However, any errors generated by deploying configurations containing these polices to devices or while discovering polices from devices were not easy to rectify. In some cases, a deployment or discovery error could have been caused by device connectivity or network problems rather than an incorrect policy configuration.

Security Manager 3.1 and later enables you to configure status providers that collect information about the status of various events from external sources or status providers, such as Performance Monitor, and from internal sources, such as deployment. As a status provider, Performance Monitor collects the status of events, such as VPN tunnel up/down status, device reachability, and CPU usage threshold, and reports them to Security Manager. You can use the Inventory Status window in the Security Manager GUI to view the events reported by status providers. Performance Monitor is a browser-based tool that monitors and troubleshoots the health and performance of services that contribute to network security. It helps you to isolate, analyze, and troubleshoot events in your network as they occur, so that you can increase service availability.

Performance Monitor, which is an external status provider, must be registered with Security Manager and needs to be authenticated by Security Manager to send status on events it is monitoring. Security Manager authenticates Performance Monitor by comparing the username and password with the account information stored in the CiscoWorks or Cisco Secure Access Control Server (ACS) database, depending on which you established at installation as your AAA provider. After the authentication of your credentials, Security Manager begins to receive the status of events. Security Manager uses SSL to establish a secure communication with Performance Monitor. You must add a device to both the Security Manager inventory and Performance Monitor for its status to be collected and displayed by the Security Manager client. If the device is deleted from Performance Monitor but is still available in Security Manager, or if you excluded the device from being polled by Performance Monitor, the health and performance of the device is not displayed by Security Manager.

Related Topics

•Understanding Performance Monitor as a Status Provider

•Configuring Performance Monitor as a Status Provider

•Understanding the Events to be Monitored

Understanding Performance Monitor as a Status Provider

Security Manager polls data from external status providers, such as Performance Monitor, at an interval of five minutes by default. When a new external status provider is added, Security Manager begins polling and displays events from that provider. When a status provider is deleted from Security Manager, events from that provider are not displayed and polling of that provider is stopped. When the Security Manager server is restarted, the last event statuses that were obtained from deployment and Performance Monitor are displayed until the next polling cycle.

Security Manager overwrites the older events with the most recent events reported by status providers. Most recent events refer to events that were reported most recently by the providers for each event type. In other words, Security Manager does not accumulate the events reported by status providers at different points in time. As an example of two most recent events that will be persisted for Device1, assume that Performance Monitor logs a "DEVICE" event type with "critical" severity level, an "INTERFACE" event type with "warning" severity level at 12:00 noon, and no events of the same type have occurred since then until the time you view the event statuses in the Inventory Status window. In this case, both events would be displayed. As an example of one most recent event that will be persisted for Device1, assume that Performance Monitor logs a "DEVICE" event type with "warning" severity level at 1:00 p.m. and another "DEVICE" event type with "critical" severity level at 2:00 p.m. When you view the Inventory Status window at say, 2:00 p.m., the event that occurred at 2:00 p.m. would only be retained and displayed.

Note The following is the mapping between the event priority (severity) levels reported by Performance Monitor and event statuses displayed in the Inventory Status window:

•P1, P2—Critical events

•P3—Major events

•P4—Minor events

•P5—Warning events

Whenever Cisco Security Manager Daemon Manager is started or restarted, or the connection is restored with Performance Monitor after a network outage, Security Manager sends a list of devices, whose status needs to be monitored, to Performance Monitor. Security Manager also notifies Performance Monitor when a new device is added to the inventory or an existing device is deleted from the inventory. Security Manager also polls Performance Monitor for incremental changes in status at other times.

Related Topics

•Performance Monitor (Status Provider)

•Configuring Performance Monitor as a Status Provider

•Understanding the Events to be Monitored

•Supported Services and Platforms for Monitoring and Reports

•Supported Event Types for Each Service Type

•Working with Event Thresholds

Configuring Performance Monitor as a Status Provider

The Status Provider page enables you to select the status providers that you want to send information to the Security Manager server. Depending on the status providers you choose, Security Manager polls the appropriate sources and modifies the display of events in the Inventory Status window.

You can add more than one Performance Monitor as a status provider and view status messages from all of them at the same time. Additionally, you can configure the same status provider to send event details to multiple Security Manager servers. You can also view information from the same Performance Monitor on multiple Security Manager clients.

For more information on how to configure Performance Monitor as a status provider to send event details to Security Manager, see Configuring Status Providers, page 1-24.

Related Topics

•Understanding Performance Monitor as a Status Provider

•Configuring Performance Monitor as a Status Provider

•Understanding the Events to be Monitored

•Supported Services and Platforms for Monitoring and Reports

•Supported Event Types for Each Service Type

•Working with Event Thresholds

Understanding the Events to be Monitored

From the Inventory Status window, select a device in the upper pane and click the Status tab in the lower pane to view the list of Performance Monitors configured as status providers. You can click the arrow to expand or collapse the events reported by each status provider. Similarly, you can expand and collapse the event details by clicking the arrow next to the event name. The status of each event (whether it is normal or an abnormal condition has occurred) is displayed next to the event name. Table 22-2 describes the fields displayed for each event.

Table 22-2 Event Status Elements

Element

Description

Timestamp

Displays the most recent time at which Security Manager polling recorded the problem.

Description

Displays a description of the problem condition.

Recommended Action

Information about how the warning, error, or failure might be corrected.

Performance Monitor collects the status of events, such as VPN tunnel up/down status, device reachability, and CPU usage threshold, and reports them to Security Manager. An event is a notification that a managed device or component has an abnormal condition. Multiple events can occur simultaneously on a single monitored device or service module. Using Performance Monitor, you can configure a threshold for an event or use the default threshold. For more information on how to configure and enable thresholds to generate performance or failure events of any priority, see Working with Event Thresholds. The events in which a monitored component or service exceeded acceptable thresholds are displayed. Supported service types are remote-access VPN, site-to-site VPN, firewall, web server load-balancing, and proxied SSL. For more information on the service types supported for different device platforms, see Supported Services and Platforms for Monitoring and Reports. The following sections describe the events whose statuses are reported by Performance Monitor to Security Manager:

•Device Reachability

•VPN Tunnel Status

•CPU Usage Threshold

Device Reachability

You must add a device to both the Security Manager inventory and Performance Monitor for its status to be recorded in the Inventory Status window. Security Manager does not display events from devices that are added only to Performance Monitor. The device that you want to monitor must be a device type supported by both Security Manager 3.1 and later, and Performance Monitor 3.1 and later. Using Performance Monitor, you cannot add, import, or validate any unsupported device type, any device when the MCP process has stopped, any device that uses a dynamic IP address or lacks configured SNMP values, and a VPN 3000 Series concentrator, unless you specify the correct SNMP and XML credentials, HTTPS is enabled, and the VPN 3000 Concentrator Series Manager is running.

You must set up devices by configuring the bootstrapping devices so Performance Monitor can validate, poll, and monitor them. Performance Monitor enables you to import or manually enter the IP addresses, hostnames, and read-only community strings for supported devices in your network. You can import device attributes from a comma-separated value (CSV) file or from the Device Credentials Repository (DCR) on a Common Services-based server, or you can add device attributes manually. You can also create device groups to interact with multiple devices in a single operation. A device group is a named entity that can contain devices, other groups, or a combination of devices and groups.

After adding a device to Performance Monitor, you can validate a device of any kind to confirm that it exists and is reachable, has the required features and interfaces enabled, has the correct credentials, uses a static (non-dynamic) IP address, and has configured SNMP values. During device validation, Performance Monitor sets all validated devices to a managed state by default meaning that polling is enabled. If you choose to move a device to an unmanaged state, you must move it back to the managed state manually before you can monitor its health or performance. By default, device validation occurs once every day, at midnight. It also occurs at other times and intervals that you specify. You can perform an immediate, one-time validation at any time. For more information on how to add, validate, and manage devices, see User Guide for Cisco Performance Monitor 3.2.

In Performance Monitor, a device is either a physical node in the network or it is a virtual node that is defined by a physical node. In either case, a device must have an IP address. For example, you can use multicontext mode to partition a single firewall into multiple virtual devices, known as security contexts. You can add and manage contexts in the system configuration. The system configuration identifies basic firewall settings, but does not include any network interfaces or network settings for itself, rather, it uses a context that is designated as the admin context.

The admin context is just like any other security context, except that a user who logs in to the admin context has administrative rights over the system and all of the other contexts. In Performance Monitor, you import only the admin context from a device when you want to monitor every configured context on a physical device. Similarly, when you delete an admin context in Performance Monitor, you simultaneously delete the record that Performance Monitor maintains for every context on the relevant physical device.

Performance Monitor reports information about only those validated devices for which monitoring is enabled. Performance Monitor enables monitoring after a successful device validation; thus, it polls the device in following polling cycles. If you decide to exclude a device from polling, you can disable monitoring for it. Later, at your discretion, you can reenable monitoring manually.

Table 22-3 describes the different management protocols that Performance Monitor uses to test device connectivity, depending on the device platform.

Table 22-3 Management Protocols Supported for Device Platforms

Device Platform

Management Protocols

Cisco IOS VPN Routers

SNMP, HTTPS for some of the show commands, and VPN-related SNMP traps.

Adaptive Security Appliances 5500 Series

SNMP and HTTPS for some of the show commands and some syslogs.

Catalyst 6500 Series Switches with Content-switching Services Modules

SNMP and content-switching module-related SNMP traps.

Catalyst 6500 Series Switches with Firewall Services Modules

SNMP and HTTPS for some of the show commands and some syslogs.

Catalyst 6500 Series Switches with SSL Services Modules

SSH for show commands.

Catalyst 6500 Series Switches with VPNSMs

SNMP, HTTPS for some of the show commands, and VPN-related SNMP traps

PIX Security Appliances (known commonly as PIX Firewalls)

SNMP, HTTPS for some of the show commands and some syslogs.

VPN 3000 Concentrator Series

SNMP, HTTPS, XML interface (if the device is in a cluster), syslogs, and SNMP traps.

After you update the list of devices to be monitored, Performance Monitor polls reachable devices for their current status to compare device status information to performance and failure thresholds, generate performance and failure events, send event notifications, when appropriate, and update the values in tables and graphs. Security Manager obtains and displays a snapshot of the most recent device reachability status in the Inventory Status window during the next polling cycle. For a categorization of the device reachability, VPN tunnel status, and CPU usage event types by service type, see Table 22-6. For a description of the elements on the Global Notification page and Service Notifications page, see Working with Event Thresholds.

Related Topics

•Understanding the Events to be Monitored

•Supported Services and Platforms for Monitoring and Reports

•Supported Event Types for Each Service Type

•Working with Event Thresholds

•VPN Tunnel Status

•CPU Usage Threshold

VPN Tunnel Status

Performance Monitor enables you to determine whether a VPN Tunnel is up or down. Whenever a VPN Tunnel is not functioning, an event is logged in the Event Browser window in the Performance Monitor GUI. A tunnel is considered as down when an IPsec security association (SA) is not present. Performance Monitor tracks the IPsec SAs and displays the event status. Internet Key Exchange (IKE) is the facilitator and manager of IPsec-based communications. It is a hybrid protocol used to authenticate IPsec peers, negotiate and distribute encryption keys, and automatically establish IPsec security associations (SAs). IKE protocol lets two hosts agree on how to build an IPsec SA. Each IKE negotiation is divided into a Phase 1 and Phase 2. Phase 1 creates the first tunnel, which protects IKE negotiation messages. Phase 2 creates the tunnel that protects data. With IKE keepalive, tunnel peers exchange messages that demonstrate they are available to send and receive data in the tunnel. Keepalive messages transmit at set intervals, and any disruption in that interval results in the creation of a new tunnel, using a backup device. Devices that rely on IKE keepalive for resiliency transmit their keepalive messages regardless of whether they are exchanging other information. These keepalive messages can therefore create a small but additional demand on your network.

Both IPsec SAs and IKE SAs can have timeout values. The absence of these SAs does not necessarily indicate a problem with IPsec tunnel. But in majority of site-to-site VPNs, both IPsec SAs and IKE SAs need to be present for all the interesting traffic.

You must define parameters for each of the available authentication methods so that IKE and IPsec can use your IKE policies successfully. For preshared key, you can either enter a key manually, or have Security Manager automatically generate a key for each hub-spoke communication session. When using preshared keys for authentication, you can use main mode or aggressive mode for negotiating key information and setting up IKE SAs. Security Manager mirrors the spoke's preshared key and configures it on its assigned hub, so that the key on the spoke and hub are the same.

With IPsec, crypto ACLs define what traffic should be protected between two IPsec peers. Traffic might be selected based on source and destination address. The crypto ACLs used for IPsec are used only to determine which traffic should be protected by IPsec, not which traffic should be blocked or permitted through the interface. ACLs are applied to interfaces by way of crypto map sets. Each tunnel policy you create with Security Manager is translated into a crypto map entry that includes an ACL. A crypto map set can contain multiple entries, each with a different ACL. The crypto map entries are searched in order and the router tries to match the packet to the ACL specified in each entry.

When some packets to be encrypted are encountered by the VPN device, it uses the symmetrical keys derived in the IKE SA establishment for encryption of data. The interesting traffic is specified by a crypto ACL as in GRE and standard IPsec VPNs. In DMVPNs, the crypto ACL is derived automatically. The pair of SAs called as IPsec SAs are created for data encryption.

Based on the threshold you configure for the site-to-site VPN tunnel status event type, Security Manager polls Performance Monitor at the preconfigured interval and displays the status in the Inventory Status window. For a categorization of the device reachability, VPN tunnel status, and CPU usage event types by service type, see Table 22-6.

Related Topics

•Understanding the Events to be Monitored

•Supported Services and Platforms for Monitoring and Reports

•Supported Event Types for Each Service Type

•Working with Event Thresholds

•Device Reachability

•CPU Usage Threshold

CPU Usage Threshold

Performance Monitor enables you to track and analyze system CPU utilization. Commonly, high CPU utilization is caused by a security issue, such as a worm or virus operating in your network. This is especially likely to be the cause if there have not been recent changes to the network. Usually, a configuration change, such as adding additional lines to your access lists, can mitigate the effects of this problem. Although debugging can also be of great help in troubleshooting high CPU utilization in processes, it should be carried out with extreme caution because it may raise the CPU utilization even more. Cisco software-based routers use software in order to process and route packets. CPU utilization on a Cisco router tends to increase as the router performs more packet processing and routing. Catalyst 6500/6000 switches do not use the CPU in the same way. These switches make forwarding decisions in hardware, not in software. Therefore, when the switches make the forwarding or switching decision for most frames that pass through the switch, the process does not involve the supervisor engine CPU.

Throttles are a good indication of an overloaded router. They show the number of times the receiver on the port has been disabled, possibly due to buffer or processor overload. Together with high CPU utilization on an interrupt level, throttles indicate that the router is overloaded with traffic. Unusual activity related to a process could also load the CPU and result in an error message in the log. Therefore, the output of the show logging exec command should be checked first for any errors related to the process which consumes lots of CPU cycles. When the TCP timer process uses a lot of CPU resources, there are too many TCP connection endpoints. This can happen in data-link switching (DLSw) environments with many peers, or in other environments where many TCP sessions are simultaneously opened on the router. High CPU utilization in the Address Resolution Protocol (ARP) Input process occurs if the router has to originate an excessive number of ARP requests.

High CPU utilization also can result from the merging of two or more VLANs due to improper cabling. Also, if STP is disabled on those ports where the VLAN merger happens, high CPU utilization can occur. The Exec process in Cisco IOS Software is responsible for communication on the TTY lines (console, auxiliary, asynchronous) of the router. The Virtual Exec process is responsible for the VTY lines (Telnet sessions). The Exec and Virtual Exec processes are medium priority processes, so if there are other processes that have a higher priority (High or Critical), the higher priority processes get the CPU resources. If there is a lot of data transferred through these sessions, the CPU utilization for the Exec process increases. High CPU utilization on an interrupt level is primarily caused by packets handled on interrupt level. Interrupts are generated any time a character is output from the console or auxiliary ports of a router. Universal Asynchronous Receiver/Transmitters (UARTs) are slow compared to the processing speed of the router, so it is unlikely, though possible, that console or auxiliary interrupts can cause a high CPU utilization on the router (unless the router has a large number of tty lines in use).

Based on the threshold you configure for the CPU usage event type associated with a particular service, Security Manager polls Performance Monitor at the preconfigured interval and displays the status in the Inventory Status window. For a categorization of the device reachability, VPN tunnel status, and CPU usage event types by service type, see Table 22-6.

Related Topics

•Understanding the Events to be Monitored

•Supported Services and Platforms for Monitoring and Reports

•Supported Event Types for Each Service Type

•Working with Event Thresholds

•Device Reachability

•VPN Tunnel Status

Supported Services and Platforms for Monitoring and Reports

See Table 22-4 to understand which services this Performance Monitor release can monitor, and can issue reports for, on each supported Cisco platform.

Table 22-4 Supported Services and Platforms for Monitoring

Platform¹, ²

Monitored Service Type³, ⁴

VPN

Firewall

Other

DMVPN

Easy VPN

Remote Access

Site-to-Site

Firewall

Multicontext

Load Balancing

SSL

Adaptive Security Appliances 5500 Series

NA

NA

NA

Catalyst 6500 Series Switches

Content-switching Services Modules

NA

NA

NA

NA

NA

NA

NA

Firewall Services Modules

NA

NA

NA

SSL Services Modules

NA

NA

NA

NA

NA

NA

NA

VPNSMs

NA

—

—

NA

NA

NA

VPN SPAs

NA

—

—

NA

NA

NA

Cisco IOS VPN Routers

NA

NA

NA

NA

Cisco Integrated Services Routers

NA

NA

NA

NA

Cisco 7300 Series Routers

NA

NA

—

NA

PIX Security Appliances (known commonly as PIX Firewalls)

NA

NA

NA

VPN 3000 Concentrator Series

NA

NA

NA

NA

NA

¹Cisco no longer sells VPNSM for Catalyst 6500 Series switches. We encourage you to migrate to VPN SPA, which supports DES and 3DES, as well as 128-, 192-, and 256-bit AES keys. See: http://www.cisco.com/en/US/products/ps6267/products_data_sheet0900aecd8027cbb2.html.

²Supported services that vary for specific software or device versions:
·  PIX OS 7.0 and later support Easy VPN services, but not RAS clustering for Easy VPNs.
·  PIX OS 7.0 and later support Easy VPN, RAS VPN, site-to-site VPN, and virtual (multicontext) firewall services.
·  PIX OS 7.0 and later support RAS VPN and site-to-site VPN services in routed single context mode only.
·  FWSM versions 2.2 and later support virtual (multicontext) firewall services.
·  FWSM versions 3.1 and later support RAS VPN and site-to-site VPN services in routed single context mode only.
·  Cisco ASA Software Version 7.0 and later support Easy VPN, RAS VPN, site-to-site VPN, and virtual (multicontext) firewall services.

³Performance Monitor neither monitors nor offers reports for the load balancing of Cisco VPN 3000 concentrators or supported ASA appliances that you organize in virtual clusters. The Load Balancing column in this table refers exclusively to the web server load balancing services associated with supported content switching services modules in Catalyst 6500 series switches.

⁴In this table:
·  NA describes a service that the specified platform does not provide.
·  The em-dash character ( — ) describes a service that Performance Monitor does not monitor on the specified platform.

Related Topics

•Understanding the Events to be Monitored

•Supported Event Types for Each Service Type

•Working with Event Thresholds

•Configuring Performance Monitor as a Status Provider

Supported Event Types for Each Service Type

To configure the threshold for device reachability, VPN tunnel status, or CPU usage event types, depending on the platform type, you need to enable the event type supported by a particular service. Configuring an event type under one of the services enables the threshold for that event type under all applicable services. Table 22-5 describes only the events that affect the relevant service.

Table 22-5 Event Types Supported for Service Types

Monitored Service

Supported Event Types

Firewall

CPU Usage

Device Accessible via Https

Device Accessible via Snmp

Remote Access VPN

CPU Usage

Device Accessible via Snmp

SSL

CPU Usage

Device Accessible via Https

Site-to-Site VPN

CPU Usage

Device Accessible via Https

Device Accessible via Snmp

Tunnel Status

Related Topics

•Understanding the Events to be Monitored

•Working with Event Thresholds

•Configuring Performance Monitor as a Status Provider

Working with Event Thresholds

While Tunnel Status is a failure metric, CPU Usage and Device Accessible via Https or Device Accessible via Snmp are performance metrics. When you create a threshold, you:

•Define the boundaries of operational states (such as OK, Degraded, and Overloaded) for a performance metric or failure metric in a specific service.

•Specify the number of consecutive polling cycles during which an operational state must recur before records are updated.

•Associate a priority level with each possible operational state for a specific metric (for GUI display and user notification purposes).

Although the thresholds that you define use different services, metrics, and states, every threshold definition follows the same basic workflow.

Tip When conditions exceed or fall below the thresholds that you define, Performance Monitor records an alarm that you can display and interpret in the relevant Event Browser.

This procedure describes how to configure thresholds for the event types.

Related Topics

•Supported Services and Platforms for Monitoring and Reports

•Supported Event Types for Each Service Type

•Understanding the Events to be Monitored

•Configuring Performance Monitor as a Status Provider

Step 1 Select Admin > Events.

Step 2 Select a service from the TOC.

Step 3 Scan the entries in the Events list until you locate the performance metric or failure metric for which you plan to configure thresholds, then select the radio button in the relevant row.

Step 4 Click Threshold.

Tip You can also configure thresholds for an event if you select Admin > Notifications, then select an event and click Threshold. For a description of the elements on the Global Notification page and Service Notifications page, see Working with Event Thresholds.

A Threshold Configuration page appears. Table 22-6 describes the elements in this page.

•If you select a failure metric, two opposite State Name values (such as Up and Down) appear in the Threshold Configuration page. Or, one extreme state value (such as OK) precedes multiple intermediate state values.

•If you select a performance metric, a range of State Name values (such as OK, Medium, and High) appears in the Threshold Configuration page; each value is associated with an upper and lower percentage in a range.

Step 5 Select the Enable check box.

You must select the Enable check box, or you cannot define values in a Threshold Configuration page.

Step 6 Do one of the following:

•If you see two opposite values (such as the benign Up and the problematic Down) in the State Name area, specify:

–The event priority level for the problematic state.

–The number of polling cycle failures that trigger, and the number of successes that clear, the event associated with the problematic state.

•If you see a range of three values in the State Name area, specify the upper and lower threshold percentages, polling cycle repetitions, and priority levels for each of the three values in the range.

Note When you configure thresholds for a performance metric, the lower threshold percentage for a benign state is always zero (0%), and the priority is always OK. The upper threshold percentage for a problematic state is always 100%. You cannot change these values.

Step 7 Do one of the following:

•To discard your selections and return to the Events page, click Cancel.

•To save and implement your selections, click Apply.

•To reset all values to their default settings and remain in the Threshold Configuration page, click Default.

Table 22-6 Threshold Configuration Page Elements

Element

Description

Common GUI Elements for All Thresholds

Enable check box

Enables you to enable or disable the modification and implementation of threshold values.

State Name column

Displays two opposite states for a failure metric and a range of states for a performance metric.

Repetitions Before State Change column

Enables you to specify the number of consecutive polling cycles during which the relevant state must recur before Performance Monitor registers that the state has changed.

Event Priority column

Enables you to associate the relevant state with a priority level between P1 (the most severe) and P5 (the least severe).

Cancel button

Enables you to discard your changes and return to the Events page.

Apply button

Enables you to save and implement your threshold definitions for the current metric.

Default button

Enables you to reset all values to their default settings and remain in the Threshold Configuration page.

GUI Elements for Performance Thresholds Only

Lower Threshold column

Enables you to select the percentage that defines the lower boundary of a state. For example, you could select 10% as the lower threshold boundary for the intermediate state. (Your selection would, in such a case, be applied automatically as the upper threshold percentage for the benign state.)

Upper Threshold column

Displays a value that is equal to your definition of the lower threshold for the adjacent state, or displays 100% as the upper threshold for the problematic state.

IPS Event Viewer

The Cisco IPS Event Viewer ( IEV) offers a free monitoring solution for small-scale IPS deployments. Monitoring individual IPS devices, IEV is easy to set up and use, and provides the following capabilities:

•Support for IPSv6 through SDEE compatibility

•Customized reporting

•Configurable notification actions such as email and paging

•Visibility into applied response actions, virtual sensor ID, learned DST OS, and threat rating

IEV is a Java-based application that lets you view and manage alerts for up to five sensors. With IEV, you can connect to and view alerts in real time or in imported log files. You can configure filters and views to help you manage the alerts and import and export event data for further analysis. IEV reports the top alerts, attackers, and victims over a specified number of hours or days. IEV also provides access to MySDN for signature descriptions. See Cisco IPS Event Viewer Version 5.2 documentation for more information.

You can start IEV from Security Manager as a client-server application. IEV server is installed when you install the Security Manager server. When you start IEV on a Security Manager client, the IEV client files are obtained from the Security Manager server and copied to the folder where the Security Manager client was installed on your client system. The IEV client files are uninstalled when you uninstall the Security Manager client on your client system. The requirements and dependencies for installing IEV server and client are the same as those for Security Manager server and client software.

Note To enable communication between IEV server and IEV client, you need to modify the Cisco Security Agent or any other anti-virus and network firewall software policies on the Security Manager server to configure TCP ports 60002 and 60003 as open ports. If the server has a preexisting installation of the full Cisco Security Agent, the standalone agent is not installed on the system when you install Security Manager. In such a case, configure the Cisco Security Agent network services to accept connections on TCP ports 60002 and 60003. However, if the server on which you install Security Manager was not previously installed with the full, commercial version of Cisco Security Agent, the Security Manager installer installs a customized, standalone agent on your server and opens the necessary TCP ports for communication between IEV server and IEV client.

When you start IEV client from the Security Manager client system, IEV client automatically opens TCP port 5001 to establish communication with the IEV server.

Note Although IEV is displayed in the list of installed programs in the Add/Remove Programs window after installation, we recommend that you uninstall IEV using the Security Manager uninstaller instead of using the Add/Remove Programs control panel.

Note In Security Manager 3.2, the ability to start IEV client from your Security Manager configured in a high availability (HA) or data redundancy (DR) environment is supported.

Caution Disable any anti-virus or host-based intrusion detection software before beginning the Security Manager server installation. Close any open applications. The Wise installer, which is a commercially available Windows Installer (MSI) package, spawns a command shell application that can trigger your host-based detection software, which causes the IEV installation to fail.

Related Topics

•Understanding Communication

•Guidelines for Working with IEV from Security Manager

•Starting IEV Client

To verify IEV server installation, follow these steps:

Step 1 Review the /<path to Cisco IPS Event Viewer>/IEV/log/system.log file. It should only contain the following message:
Cisco IPS Event Viewer service successfully started.
Step 2 Select Start > Settings > Control Panel > Administrative Tools > Services to verify that the following Windows services have started:

• Cisco IPS Event Viewer service

This service lets IEV retrieve alerts from remote device(s), store alerts in the MySQL database, archive database files, and check for available disk space.

•MySQL service

This service controls the persistent storing and serving of data.

Note The Cisco IPS Event Viewer service depends on MySQL services. If you want to stop retrieving alerts, you can stop the Cisco IPS Event Viewer service. Later you can restart the Cisco IPS Event Viewer service to resume retrieving and storing alerts.

Caution Do not remove the c:\ my.cnf file. The MySQL server used by IEV requires this file.

IEV server is uninstalled when you uninstall Security Manager server.

Understanding Communication

Security Manager client intercepts all SSL requests made by IEV client and sends them to the IEV server running on Security Manager server. IEV server processes the requests redirected by the IEV client by obtaining information from the sensor or sending data such as the IEV image to the client. This communication between the IEV client and IEV server is transparent to the IPS sensor, and appears as though there is a direct connection between IEV client and the sensor.

The Cisco IPS Event Viewer and MySQL services must be running on the IEV server to enable IEV monitor sensors. IEV server retrieves the events from IPS sensors and stores them in the MySQL database. When you start the IEV client from Security Manager client, a secure connection is established between IEV client and IEV server, the Java application on the IEV client reads the event details from the MySQL database, and event data is displayed on the IEV client in various views, tables, and graphs.

If the IEV client files are not available in the client cache directory, the image is obtained from the Security Manager server. The Security Manager client starts only one instance of IEV client and closes the IEV client window when you exit the Security Manager client or when the idle session timeout period is exceeded.

Related Topics

•IPS Event Viewer

•Guidelines for Working with IEV from Security Manager

•Starting IEV Client

•Navigating to IPS Signature Policy in Security Manager from IEV

Guidelines for Working with IEV from Security Manager

Keep in mind the following guidelines when working with IEV started from Security Manager:

• IEV enables you to view alarms for up to five sensors at a time.

• IEV uses the same JRE version as Security Manager.

•IEV client is not preinstalled with Ethereal or any packet sniffer.

• If Ethereal was previously installed on your computer when you install Security Manager, you need to specify the directory where Ethereal was installed from the IEV main menu. You also need to modify the location of Ethereal if you later move the Ethereal executable file to a different directory or if you decide to install Ethereal after installing Security Manager.

Note Ethereal is a network protocol analyzer for Windows that lets you examine data from a live network or from a captured file. You can interactively browse the captured data and view summary and detail information for each packet, including the reconstructed stream of a TCP session. If you have Ethereal installed on the same host as IEV, you can start the Ethereal application from the IEV Tools menu and view IP log files. Also, if you have configured the sensor capturePacket parameter, IEV uses Ethereal to display the trigger packet.

•Cisco IPS Event Viewer and MySQL services are installed as Windows NT services.

•All IEV client-side runtime files, such as client log files and cache files, are copied to the subdirectory under the Security Manager client installation directory. The default location for these files is C:\Program Files\Cisco Systems\Cisco Security Manager Client\cache.

•All IEV server-side files, databases, log files, configuration files and other runtime files are installed in a subdirectory under the Security Manager server installation directory. The default location for these files is C:\Program Files\CSCOpx\IPSEventViewer.

• If you attempt to install IEV server on a Security Manager server system that has been already installed with IEV from Cisco.com, an error message is displayed.

•You can start only one instance of IEV client per Security Manager client system.

•You can start multiple IEV clients for the same IEV server at the same time from different Security Manager clients systems.

•You cannot start IEV client from a Security Manager client if the Security Manager server has also been installed on the same system.

•If you installed IEV server on a system using the Security Manager installer, you cannot install IEV separately from Cisco.com on the same system.

•If you installed IEV server on a system using the Security Manager installer, IEV server is not reinstalled when you attempt to reinstall Security Manager on the same system.

• Before IEV can receive events from a sensor, you must add the sensor to the list of devices that IEV monitors and specify the device credentials. See Cisco IPS Event Viewer Version 5.2 documentation for information on how to add a sensor to be monitored by IEV. You must also add the sensor to the Security Manager inventory to view event data from the sensors you are monitoring.

• When you want to stop receiving events from a sensor, you must remove the sensor from the list of devices that IEV monitors and from the Security Manager inventory separately. IEV terminates the connection to that sensor and no longer receives events from that sensor.

• Backup and restore of the Security Manager database does not apply to IEV database.

• IEV log files are archived when you generate the Security Manager diagnostics file.

• When you exit the Security Manager client, the IEV client window is closed.

Related Topics

•IPS Event Viewer

•Understanding Communication

•Starting IEV Client

Starting IEV Client

This procedure describes how to start an IEV client from the Security Manager client.

Before You Begin

•Make sure the Windows NT services for IEV server are running on the Security Manager server. To review the status of the Cisco IEV and MySQL services, select Start > Settings > Control Panel > Administrative Tools > Services.

•Make sure you selected an IPS sensor from the Device selector.

Related Topics

•IPS Event Viewer

•Understanding Communication

•Guidelines for Working with IEV from Security Manager

•Navigating to IPS Signature Policy in Security Manager from IEV

Step 1 Select Tools > IPS Event Viewer.

A dialog box asks you to confirm that you want to start IEV client from the Security Manager client.

Step 2 Click Yes to continue.

The IEV client window is displayed when the start operation is complete.

Navigating to IPS Signature Policy in Security Manager from IEV

Sensors use signatures to determine whether the contents of network packets meet the criteria of an attack. A signature is a pattern of traffic, often thought of as a set of rules, that your sensor uses to detect typical intrusive activity, such as denial of service (DoS) attacks. The Signatures policy page in Security Manager enables you to configure signatures for Cisco IPS sensors. When the packets match a given signature rule, the sensor generates an alarm. You can configure IEV to manage alarms from sensors by adding the sensors to the IEV Devices folder.

After you add the device to IEV, IEV sends a subscription request to the sensor. IEV will receive alerts and events from the sensor, beginning with the first event the sensor receives after connecting with IEV. An event is an IPS message that contains an alert, a block request, a status message, or an error message.

Using IEV, you can select an event generated by an IPS signature from the log of events within the Realtime Dashboard or the View folders, and navigate to the signature policy in Security Manager for that specific event. You can then edit the signature properties to modify the action the sensor must take to handle network attacks. The following sections describe how to look up the Signatures policy page in Security Manager from IEV:

•IPS Signature Policy Lookup from the Realtime Dashboard

•IPS Signature Policy Lookup from the Views Tab

IPS Signature Policy Lookup from the Realtime Dashboard

You can use the Realtime Dashboard to view a continuous stream of real-time events from the sensor. By default, the Realtime Dashboard displays the most recent events received from every device configured in IEV. You can configure the Realtime Dashboard to display only events from a particular device or only events of a particular severity level. You can also configure how often the Realtime Dashboard retrieves events from the sensor(s) and the maximum number of events to display.

This procedure describes how to look up an IPS signature in the Signatures policy page of Security Manager from the Realtime Dashboard of IEV:

Related Topics

•IPS Signature Policy Lookup from the Views Tab

•Navigating to IPS Signature Policy in Security Manager from IEV

Step 1 Open IEV client from the Security Manager client. For a description of the procedure to start IEV client, see Starting IEV Client.

Step 2 Choose Tools > Realtime Dashboard > Launch Dashboard.

IEV opens a subscription request with the sensor. If the connection is successful, the Realtime Dashboard appears and displays the most recent events received by the sensor since the request was opened.

Step 3 Right-click a row associated with an event, then select Go to CSM. The Security Manager client window is activated and the Signatures policy page appears with the IPS signature that generated the event highlighted in the policy table.

For each event entry in IEV, Security Manager searches all the signatures within the context of your current activity when Workflow mode is enabled (including policies defined in your private view and saved locally on the client, and policies committed to the Security Manager database), or current login session when non-Workflow mode is enabled. If the event entry had been triggered by a signature not referenced in the current activity, an error message appears.

You can edit the signature that triggered the event by right-clicking its row in the table and selecting Edit Row from the Row Context Menu.

IPS Signature Policy Lookup from the Views Tab

The Views tab lets you analyze filtered event data from a specified source. IEV ships with five default views; however, you can use the View Wizard to create and store user-defined views in the Views folder. Based on the data that is populated in a specific view, you can navigate to the events. For example, you can select the view configured to group events by signature name to organize the table of events by signature name. You can expand an event to view the details, such as signature name and severity level, associated with that event, and navigate to the Signatures policy in Security Manager.

IEV lets you access various tables and graphs that provide specialized views into the event data you are analyzing. Before you create a view and begin working with the individual tables and graphs, review the following descriptions.

The following tables organize the events for a view. The events shown in these tables and graph differ depending on the data source you choose for the view. The data source can be the event_realtime_table, archived tables, or imported log files.

•Alert Aggregation table—The first table displayed for any view. You access an alert aggregation table by double-clicking the view name in the Views folder.

•Expanded Details Dialog table—Displays the details of a particular event listed in an alert aggregation table. You access the Expanded Details Dialog table by right-clicking a row in the first column of an alert aggregation table.

•Drill Down Dialog table—Displays the individual entries for a particular column in the alert aggregation table, such as the individual source addresses associated with a UDP Bomb event. You access the Drill Down Dialog table by double-clicking a column (except first or Total Alarm Count) in an alert aggregation table.

•Alarm Information Dialog table—Displays the individual alerts for a particular event. You access the Alarm Information Dialog table by double-clicking the Total Alarm Count column in the alert aggregation table, or by right-clicking the first column of the Expanded Details Dialog table.

See Cisco IPS Event Viewer Version 5.2 documentation for more information.

This procedure describes how to look up an IPS signature in the Signatures policy page of Security Manager from the Views folder of IEV:

Related Topics

•IPS Signature Policy Lookup from the Realtime Dashboard

•Navigating to IPS Signature Policy in Security Manager from IEV

Step 1 Open IEV client from the Security Manager client. For a description of the procedure to start IEV client, see Starting IEV Client.

Step 2 Click the Views tab.

Step 3 Double-click the Views folder to view the list of defined views.

Step 4 To view individual alarms associated with an event from an alert aggregation table, do the following:

a. Right-click a cell in the first column in an alert aggregation table associated with the event you want to expand, and then choose Expand Whole Details.

The Expanded Details Dialog appears with the Whole Address tab displayed.

b. To view the events by address category, click the Class A Level, Class B Level, or Class C Level tab.

c. Right-click any column in the Expanded Details Dialog, then select View Alarms.

The Alarm Information Dialog appears.

Tip You also access the Alarm Information Dialog by double-clicking a column (except first or Total Alarm Count) in an alert aggregation table, right-clicking a cell in the first column from the Drill Down Dialog, and selecting View Alarms.

Note For cells that display an arrow (—>) after the number of occurrences, double-click that cell to display the contents of the cell.

A second table appears in the Drill Down Dialog and displays the contents of the cell. Double-clicking a cell containing an arrow (—>) in this second table displays the Alarm Information Dialog.

Step 5 Right-click a row associated with an event, then select Go to CSM. The Security Manager client window is activated and the Signatures policy page appears with the IPS signature that generated the event highlighted in the policy table.

For each event entry in IEV, Security Manager searches all the signatures within the context of your current activity when Workflow mode is enabled (including policies defined in your private view and saved locally on the client, and policies committed to the Security Manager database), or current login session when non-Workflow mode is enabled. If the event entry had been triggered by a signature not referenced in the current activity, an error message appears.

You can edit the signature that triggered the event by right-clicking its row in the table and selecting Edit Row from the Row Context Menu.

Security Manager Access Rule Lookup from Device Manager Syslog

Each interface on the device or appliance is associated with a list of ACEs that are associated with an ACL. When the firewall device finds a matching ACE, the device performs the associated action either permitting the packet into the firewall device for further processing, or denying entry to the packet. If no ACE matches the packet, the packet is denied. Activity on your firewall or router is monitored through the creation of syslog entries. If logging is enabled on the device, whenever an access rule that is configured to generate syslog entries is invoked—for example, if a connection were attempted from a denied IP address—a log entry is generated.

Security Manager 3.1 and later introduces a new Syslog to Access Rule Correlation tool that enhances day-to-day security management and troubleshooting activities. With this tool, you can quickly resolve common configuration issues, along with most user and network connectivity problems. Because the configuration process is simple, operational efficiency and response times for business-critical functions are improved. For ASDM and SDM started from within Security Manager, you can identify the ACL on a router or firewall that generated a syslog message received by ASDM and SDM. The access rule that triggered the syslog entry is highlighted on a first-match basis, even if there are multiple access rules that cause the same syslog message to be generated. The feature to perform the Security Manager policy table lookup, when the device generates a syslog message, is available in SDM 2.4.1, which supports all versions of Cisco IOS software running on a router, ASDM 6.0(3), which manages ASA 8.0(3) and PIX 8.0(3), and ASDM 5.2(2)F, which runs with FWSM 3.1 and 3.2.

Using ASDM 5.2(2)F and 6.0(3), you can select a syslog message generated by an ACL within the Real-time Log Viewer window or Log Buffer Viewer window, and navigate to the access control rule in Security Manager for that specific syslog. The Syslog to Access Rule Correlation tool also offers an intuitive view into syslog messages invoked by user-configured access rules. You can closely observe enterprise traffic patterns and monitor resource access behavior. For more information, see Navigating to ACL in Security Manager from ASDM Syslog.

Using SDM 2.4.1, you can select a syslog message generated by an ACL from the log of events categorized by security level and displayed under the Syslog tab of the Logging window. For each selected syslog message, you can look up the Security Manager to highlight the access control entry that matches the traffic that generated the message. You can then disable the rule to permit or deny the traffic. For more information, see Navigating to ACL in Security Manager from SDM Syslog.

System log messages with the following ID numbers are generated by FWSM blades and ASA devices if you configured logging for an access rule that matches the network traffic:

•106023—Generated when an IP packet was denied by the ACL. This message displays even if you do not have the log option enabled for an ACL.

•106100—If you configured the log option for the access-list command, the packets matched an ACL statement. The message level depends on the level set in the access-list command (by default, the level is 6). The message indicates either the initial occurrence or the total number of occurrences during an interval. This message provides more information than message 106023, which only logs denied packets, and does not include the hit count or a configurable level.

On Cisco IOS devices, system log messages are generated for access lists configured with the log or log-input keyword. The log keyword causes an informational logging message about the packet that matches the entry to be sent to the console. The log-input keyword causes the input interface, source MAC address, or virtual circuit to be included in the logging output. The message includes the access list number, whether the packet was permitted or denied; the protocol, whether it was TCP, UDP, ICMP, or a number; and, if appropriate, the source and destination addresses and source and destination port numbers. The message is generated for the first packet that matches, and then at 5-minute intervals, including the number of packets permitted or denied in the prior 5-minute interval.

Related Topics

•Navigating to ACL in Security Manager from ASDM Syslog

•Navigating to ACL in Security Manager from SDM Syslog

Navigating to ACL in Security Manager from ASDM Syslog

Using ASDM 5.2(2)F and 6.0(3), you can select a syslog message generated by an ACL within the Real-time Log Viewer window or Log Buffer Viewer window, and navigate to the access control rule in Security Manager for that specific syslog.

Navigating to ACL from the Log Buffer Viewer

The Log viewing feature of ASDM lets you view real-time system log messages that appear in the log buffer. When you start ASDM from Security Manager, the most recent ASDM system log messages appear at the bottom of the ASDM home page. The Log Buffer panel enables you to view log messages saved in the buffer in a separate window. Depending on the level of logging messages to view, ranging from Emergency to Debugging, and click View to open a separate window in which log messages appear. The Log Buffer window displays the identification number of the log message, date and time that the system log messages was generated, the logging level of a syslog message, and the addresses of the network or host from which the packet is being sent and received. You can select a syslog message and identify the ACL in Security Manager that created the log message.

This procedure describes how to look up the access rule in the policy table of Security Manager from the Log Buffer panel of ASDM.

Step 1 Open ASDM from the Security Manager client. For a description of the procedure to start device manager, see Starting Device Manager from Security Manager.

Step 2 From ASDM 5.2(2)F or 6.0(3), select Monitoring > Logging > Log Buffer. The Log Buffer panel appears.

Step 3 Click View to display the log messages currently in the buffer. The Log Buffer window opens as a separate window.

Step 4 Right-click a syslog message generated by a firewall access rule, then select Goto Rule in CSM. The Security Manager client window is activated and the Access Rules page appears with the access rule that generated the syslog message highlighted in the policy table.

Note If you try to navigate to Security Manager from a syslog message that was not generated by a firewall access rule, a popup window prompts you to select a message generated by an ACL.

For each syslog entry, Security Manager searches all the access rules within the context of your current activity when Workflow mode is enabled (including policies defined in your private view and saved locally on the client, and policies committed to the Security Manager database), or current login session when non-Workflow mode is enabled. If the syslog entry had been triggered by an access rule not referenced in the current activity, an error message appears.

You can edit the access rule that triggered the syslog message in their entirety by double-clicking a rule number in the table, or edit individual table cells by double-clicking a cell.

If you did not close any modal dialog box in Security Manager, navigation to the access rule in the policy table fails from ASDM. Close the modal dialog box and try to invoke the access rule in Security Manager again.

Note Security Manager uses modal dialog windows to display warnings or user notification messages. Generally, when an application displays a modal window or dialog, the application stops responding to any event (mouse action, keyboard entry, and so on) other than the event associated with the modal window (you must first respond to the modal window). If you overlay the modal window with any other application window (the modal window now is "invisible"), the application appears frozen. If your browser window appears frozen, ensure that there is no modal window that has inadvertently been covered.

Navigating to ACL from the Real-time Log Viewer

The Real-time Log Viewer panel enables you to view real-time system log messages in a separate window. Depending on the level and maximum number of logging messages to view, click View to display a separate window in which log messages appear. The Real-time Log Viewer window enables you to view incoming messages in real time and look up the ACL that generated the syslog message.

This procedure describes how to look up the access rule in the policy table of Security Manager from the Real-time Log Viewer panel of ASDM.

Related Topics

•Security Manager Access Rule Lookup from Device Manager Syslog

•Navigating to ACL in Security Manager from SDM Syslog

Step 1 Open ASDM from the Security Manager client. For a description of the procedure to start device manager, see Starting Device Manager from Security Manager.

Step 2 From ASDM 5.2(2)F or 6.0(3), select Monitoring > Logging > Real-time Log Viewer. The Real-time Log Viewer panel appears.

Step 3 Click View to display the incoming log messages on the security appliance in real-time. The Real-time Log Viewer window opens as a separate instance.

Step 4 Right-click a syslog message generated by an ACL, then select Goto Rule in CSM. The Security Manager client window is activated and the Access Rules page appears with the access rule that generated the syslog message highlighted in the policy table.

Note If you try to navigate to Security Manager from a syslog message that was not generated by a firewall access rule, a popup window prompts you to select a message generated by an ACL.

For each syslog entry, Security Manager searches all the access rules within the context of your current activity when Workflow mode is enabled (including policies defined in your private view and saved locally on the client, and policies committed to the Security Manager database), or current login session when non-Workflow mode is enabled. If the syslog entry had been triggered by an access rule not referenced in the current activity, an error message appears.

You can edit the access rule that triggered the syslog message in their entirety by double-clicking a rule number in the table, or edit individual table cells by double-clicking a cell.

Navigating to ACL in Security Manager from SDM Syslog

SDM 2.4.1 offers the following logs:

•Syslog—The router contains a log of events categorized by severity level. It is the router log that is displayed, even if log messages are being forwarded to a syslog server.

• Firewall Log—The log entries shown in the top part of this window are determined by log messages generated by the firewall. In order for the firewall to generate log entries, you must configure individual access rules to generate log messages when they are invoked.

•Application Security Log—If logging has been enabled, and you have specified that alarms be generated when the router encounters traffic from applications or protocols that you have specified, those alarms are collected in a log that can be viewed from this window.

•SDEE Message Log—If SDEE has been configured on the router, this log records SDEE messages. SDEE messages are generated when there are changes to IPS configuration.

This procedure describes how to look up the access rule in the policy table of Security Manager from the Logging panel of SDM 2.4.1.

Related Topics

•Security Manager Access Rule Lookup from Device Manager Syslog

•Navigating to ACL in Security Manager from SDM Syslog

Step 1 Open SDM from the Security Manager client. For a description of the procedure to start device manager, see Starting Device Manager from Security Manager.

Step 2 Select Monitor > Logging. The Logging panel appears with Syslog tab displayed. You can also open it by clicking the Syslog tab from any other tab in the Logging panel.

Step 3 Select a syslog message generated by an access rule, then click the Goto Rule in CSM button above the table of log messages displayed. The Security Manager client window is activated and the Access Rules page appears with the access rule that generated the syslog message highlighted in the policy table.

Note If you try to navigate to Security Manager from a syslog message that was not generated by a firewall access rule, a popup window prompts you to select a message generated by an ACL.

For each syslog entry, Security Manager searches all the access rules within the context of your current activity when Workflow mode is enabled (including policies defined in your private view and saved locally on the client, and policies committed to the Security Manager database), or current login session when non-Workflow mode is enabled. If the syslog entry had been triggered by an access rule not referenced in the current activity, an error message appears.

You can edit the access rule that triggered the syslog message in their entirety by double-clicking a rule number in the table, or edit individual table cells by double-clicking a cell.

Security Manager Policy Table Lookup from a MARS Event

While Security Manager enables you to centrally manage security policies and device settings in large scale networks, Cisco Security MARS identifies, isolates, and recommends precise removal of compromised network elements. Cisco Security MARS does this task by transforming raw security data into an easily-readable format to subvert valid security incidents and maintain compliance. MARS integrates with Security Manager to map traffic-related syslog messages to the firewall and to signature policies defined in Security Manager that triggered the event. Policy lookup enables rapid, round-trip analysis for troubleshooting firewall configuration-related network issues and policy configuration errors, and for fine-tuning defined policies. Following suggestions from MARS on access rule and signature changes to block the traffic, you can use Security Manager to manually mitigate using the access rule and signature recommendations provided by MARS, thereby, ensuring that the configuration management solution stays abreast of the mitigation responses. Security Manager can also publish the same change to all like devices that it manages, providing a more robust containment.

In Security Manager 3.1.1 through 3.0.1 and Cisco Security MARS 5.3.3 through 5.2.x and 4.3.3 through 4.2.1, although you can look up the Security Manager policy table that generated a MARS event or incident from within the MARS UI in read-only mode, you cannot alter the access rule that generated the event without logging in to Security Manager in a separate session. With Security Manager 3.2 and MARS 4.3.4 and 5.3.4, you can modify access rules generating the MARS event seamlessly from the read-only policy table popup window, which displays all rules associated with an event, by clicking the highlighted access rule number without starting Security Manager separately. Similarly, you can navigate to the signature summary table in Security Manager from MARS events associated with IPS sensors and IOS IPS devices and alter the signature properties. This feature enables you to map a syslog message to the policy that triggered that message and modify it simultaneously, thereby reducing time spent configuring and troubleshooting access rules in large or complex networks.

For example, consider the following case where a user cannot connect to destination X from source Y. To troubleshoot this issue, an administrator can do the following:

1. Log in to the MARS web interface and, using an on-demand query, determine whether an event has been received that shows that traffic from source Y to destination X has been blocked.

2. If such events are found, the administrator can continue by determining which access rule is actually blocking the traffic. To do so, the administrator would click the policy query icon in the row of one of the selected events. MARS then queries Security Manager to retrieve the list of access rules that match that traffic flow. Assuming that Security Manager was used to configure the routers and firewalls between source Y and destination X, a list of matching access rules are returned.

3. Next, the administrator can click the access rule number that matches the MARS query criteria and is highlighted to log in to the Security Manager user interface and modify the identified policy, or an access rule, to allow traffic between source Y and destination X. MARS reuses the already running Security Manager session, if one exists, or starts a fresh session using the Security Manager login credentials added to MARS. Thus, it is not required that the administrator make a note of the matching rules and start Security Manager outside of MARS to modify the policy.

The following sections describe how to configure Security Manager and MARS to ensure seamless integration for access rule and signature policies lookup in Security Manager from MARS syslogs:

•Taskflow for Policy Table Query from MARS Events

•Understanding Security Manager Device Lookup

•Understanding Access Rule Table Lookup

•Understanding Signature Table Lookup

•Guidelines for Working with Policy Table Lookup from MARS

•Checklist for Policy Table Lookup from MARS

•Devices and OS Versions Supported by Both Security Manager and MARS

•Bootstrapping Security Manager Server to Communicate with MARS

•Adding a Security Manager Server to MARS

•Navigating to Access Rule Policy in Security Manager from MARS

•Navigating to IPS Signature Policy in Security Manager from MARS

Taskflow for Policy Table Query from MARS Events

The Security Manager Policy Table Lookup icon appears in the Reporting Device column of the MARS session display when MARS receives a syslog triggered by the following:

•Matches against access rules from a Cisco PIX Firewall, Cisco Adaptive Security Appliance (Cisco ASA), Cisco Firewall Services Module (Cisco FWSM), or Cisco IOS, and the five tuple information required to establish an event (source IP, destination IP, source port, destination port, and protocol) can be derived.

•Connection establishment and tear-down using TCP, UDP, and ICMP on security appliances and FWSM blades.

•Firing of signatures from IPS and IOS IPS devices.

Clicking the icon queries Security Manager, the result of which is to identify the access rule in the policy table of the device that created the traffic incident or event. The following steps depict the policy query process between MARS and Security Manager:

1. From the Summary, Incidents, or Query page, navigate to the Incident Details page or the Query Results page for a particular incident ID and click the Security Manager Policy Query icon in the Reporting Device field to invoke the policy table lookup.

2. MARS establishes an HTTPS connection in one of two ways, depending on the authentication mechanism chosen while adding Security Manager to MARS: by using the MARS credentials or prompting the user for login credentials, or by using the Security Manager username and password saved in the MARS database.

3. If authentication fails, MARS displays an error message in a popup window. On successful authentication, MARS requests the device ID from Security Manager by providing the hostname and IP address.

4. If more than one device matches the MARS query criteria, all matching reporting devices are displayed in a popup window from which you can select the device for which you need to modify the access rule. If only one device matches the MARS query criteria, step 5 is performed. If no device matches the query criteria, an error message is displayed. For more information, see Understanding Security Manager Device Lookup.

5. MARS performs one of the following actions, depending on the type of syslog that generated the event:

–If an access rule triggered the syslog on ASA devices, PIX security appliances, IOS routers, or FWSM blades, MARS sends the syslog message to Security Manager. Security Manager then looks up the policy table for all access rules that match the device ID and five-tuple data. MARS also provides the action, direction, interface, and ACL name information.

–If a TCP, UDP, or ICMP connection establishment or teardown resulted in the syslog on ASA, PIX, or FWSM devices, MARS sends the raw syslog message to Security Manager for processing. Security Manager looks for all access rules that match the device ID, five-tuple data, direction of traffic flow, and mapped (NATed) IP addresses in the message.

–If the signature on an IPS or IOS IPS device triggered the syslog, MARS requests all signature policies that match the device, signature, and subsignature IDs. MARS displays an error message if you attempt to view the Security Manager signature summary table for a virtual sensor, because the virtual sensor ID is not available in the MARS event data to query Security Manager for a matching signature.

For more information on how Security Manager analyzes the syslogs from MARS and retrieves matching policies from the Access Rules page, see Understanding Access Rule Table Lookup. For more information on how the signature associated with an IPS event is retrieved from the signature policy table, see Understanding Signature Table Lookup.

6. The policy table lookup query is done in one of the following three ways, depending on whether Workflow or non-Workflow mode is enabled and Security Manager client is running or not.

–If an instance of the Security Manager client is not running and either Workflow or non-Workflow mode is enabled in Security Manager, the lookup query is performed on the policies committed to the Security Manager database.

–If Workflow mode is enabled and an instance of the Security Manager client is active, the lookup query is performed on all policies within the context of the current activity (in an editable state, namely, Edit, Edit Open, Submit, or Submit Open) as well as references found in data committed to the Security Manager database.

–If non-Workflow mode is enabled and a Security Manager client session is open, the lookup operation is performed on all policies in the current login session (within the context of the automatically created activity in non-Workflow mode).

7. For events generated by access rules and connection establishment and tear-down syslogs, MARS displays the read-only access rule policy lookup table with matching rules highlighted from which you can navigate to the Access rules page of Security Manager and fine-tune the policy. For IPS events, MARS displays the read-only signature details page from which you can click Edit Signature to navigate to the Signatures policy page in Security Manager and modify the highlighted IPS signature that generated the event.

8. For access rule and connection-related syslogs, click the hyperlinked rule number from the read-only access rule table window to start the Security Manager client and modify the highlighted rule. For syslogs triggered by IPS signatures, click Edit Signature from the read-only popup window to start the Security Manager client and modify the highlighted signature. You can also configure an event action filter to remove one or more actions from a signature event.

The Security Manager client is started from MARS in one of the following three ways:

–If the Security Manager client is not installed on the system to which the policy lookup query was made, you are prompted to install the Security Manager client and the page for downloading the application is opened.

–If an instance of the Security Manager client is already running, the existing session is reused.

–If the Security Manager client session has timed out or an instance is not active, a new instance of the Security Manager client is started.

Related Topics

•Understanding Security Manager Device Lookup

•Understanding Access Rule Table Lookup

•Understanding Signature Table Lookup

•Guidelines for Working with Policy Table Lookup from MARS

•Checklist for Policy Table Lookup from MARS

Understanding Security Manager Device Lookup

MARS requests the access rule and signature policy table of a device that Security Manager administers by supplying the following criteria to Security Manager:

•Device Name—Derived from the Device Name field in the Security and Monitoring Information page of MARS.

Note For devices that support the discovery operation, such as routers and firewalls, MARS renames this field's value to match the name discovered in the device configuration, which typically uses the hostname.domain format. For devices that cannot be discovered, such as Windows and Linux hosts and host applications, MARS uses the provided value.

When you add FWSM and ASA devices with multiple security contexts to Security Manager, the context name is set as the hostname in the Device Properties page and policy lookup from MARS events for these contexts works properly. If the hostname is not the same as the context name, policy lookup from events fails. In such cases, make sure that the hostname defined for that context in the Device Name field of the MARS GUI matches with the hostname configured in the Device Properties page of Security Manager for policy lookup to work correctly.

•IP Address—Derived from the Reporting IP field in the Security and Monitoring Information page of MARS.

•Domain Name—If available, derived from the device name in MARS (for example, c3550-225-125.clab.cisco.com).

The Device Lookup query takes the following actions between MARS and Security Manager:

1. Security Manager matches the MARS Device Name to the Security Manager host names. If only one matching hostname is discovered, the process for Policy Table Lookup is invoked.

2. If there are multiple matches on hostname and no unique display name matches, the domain name (if available) is used to narrow the choices.

3. If the domain name is not available, MARS Reporting IP is used to narrow the choices.

4. If a unique device cannot be identified, MARS displays a list of possible devices in a popup window that shows the IP address, host name, display name, and domain name for all possible device matches. The user manually selects the device and the process for the policy table lookup is invoked.

Related Topics

•Taskflow for Policy Table Query from MARS Events

•Understanding Access Rule Table Lookup

•Understanding Signature Table Lookup

•Guidelines for Working with Policy Table Lookup from MARS

Understanding Access Rule Table Lookup

The device lookup information is combined with the event information to perform the Security Manager access rule table lookup.

In the policy table lookup that was implemented in Security Manager 3.1.1 through 3.0.1 and MARS 5.3.1 through 4.2.1, the Security Manager policy query icon was displayed for all MARS events that had the 5-tuple data available. This method of lookup resulted in incorrect and inaccurate access rule matches from MARS events. For example, in earlier releases of Security Manager and MARS, the policy query icon was displayed for events generated by the connection establishment and teardown of management traffic from a firewall even though this traffic flow was not subjected to access rule check. Also, the incomplete parsing of connection-related syslogs was compounded by the absence of connection direction and post-NAT addresses in the teardown syslogs.

Security Manager 3.2 integration with MARS 4.3.4 and 5.3.4 for access rule table lookup supports more accurate mapping of MARS syslogs (events) to Security Manager access rules and reduces the number of irrelevant matches, thereby enabling faster and improved troubleshooting of access rules. This improved behavior is accomplished because MARS sends Security Manager the raw syslog message and not just the parsed event information, such as the event 5-tuple, action, ACL name, interface, and direction of flow. Using the raw event sent by MARS, Security Manager extracts critical data about the direction of traffic flow and other details, such as pre-NAT and post-NAT addresses. After the most accurately matching policy is found, Security Manager passes the information to MARS, which is translated in a readable format.

TCP and UDP connection setup/teardown syslogs represent the traffic flow through the firewall. A connection setup syslog is generated when a session is established through the device, when traffic flows to the device, or when traffic flows from the device. Each connection setup syslog has an associated teardown syslog, which is generated when the session is terminated. Although both the setup and teardown syslogs share a common connection ID, the teardown syslog does not contain the pre-NATed address and direction information. For teardown syslogs, MARS also transmits the corresponding setup syslog for that connection because it contains the necessary information for an accurate match. For sessionized events, MARS also sends the session object, which contains NATed details, to Security Manager for lookup. Security Manager parses the details from the syslog in raw format and performs two queries, instead of one, on the policy database to find a matching permit ACE in the inbound and outbound interfaces in the "in" and "out" directions, respectively. As a result, each policy query for a connection setup/teardown syslog yields zero, one, or two matches, depending on the configuration of a permit ACE on that interface in the specified direction. A maximum of two matching rules is displayed in the read-only access rule table popup window after the lookup.

ICMP connection setup and teardown syslogs do not contain the ICMP code, type, interface names, direction keyword, and a connection ID. Therefore, lookup of access rules for ICMP setup/teardown syslogs is not as accurate as their TCP and UDP counterparts owing to the absence of necessary details to locate an exact match. However, the ICMP setup/teardown syslogs associated with management traffic to and from a device are handled slightly differently. For management traffic triggered by TCP and UDP connection-related messages, Security Manager checks for the presence of the "NP Identity Ifc" keyword as the second interface in the syslog format for these protocols to obtain the most accurate matches for the lookup query. Although the Security Manager icon is displayed for events generated by ICMP connection teardown syslogs, an error message is displayed when you perform policy lookup from these events. The error message states that the corresponding connection setup syslog for the teardown syslog could not be found and asks you to try this operation after a few seconds. However, the same error is displayed even if you perform lookup at a later time.

Each syslog generated by an access rule or connection setup/teardown is associated with a unique ID. You can navigate to the policy rules that trigger syslogs in MARS from the Incident Details page by clicking the Security Manager icon. You can query policies only from those syslog IDs that are supported by MARS and Security Manager. For details on the syslog IDs supported by MARS and Security Manager for policy lookup from events, see Security Appliance and Router System Log Messages Supported for Policy Lookup.

MARS displays the policy table in a popup window. The matching access rule is displayed in highlight. If MARS was unable to provide the interface, direction, and action information, multiple matched access rules may be highlighted.

Sample TCP Connection Setup/Teardown Syslog Messages for an ASA Device
Mar 19 2007 21:05:59 2.168.154.2 : %ASA-2-302013: Built outbound TCP 
connection 42210 
Mar 19 2007 21:06:27 2.168.154.2 : %ASA-2-302014: Teardown TCP 
connection 42210 
Sample ICMP Connection Setup/Teardown Syslog Messages for an ASA Device
Mar 19 2007 21:03:44 2.168.154.2 : %ASA-2-302021: Teardown ICMP 
connection 
Mar 19 2007 21:03:44 2.168.154.2 : %ASA-2-302020: Built ICMP 
connection 
Sample UDP Connection Setup/Teardown Syslog Messages for an ASA Device
Mar 19 2007 21:08:53 2.168.154.2 : %ASA-2-302015: Built outbound UDP 
connection 42214 
Mar 19 2007 21:10:55 2.168.154.2 : %ASA-2-302016: Teardown UDP 
connection 42214 
Sample Cisco PIX Firewall Syslog Messages with Access Group Name Information
10.33.10.2 <142>%PIX-4-106023: Deny tcp src inside:10.1.5.234/3010 dst 
outside:5.6.7.8/21 
Sample Cisco IOS 12.2 Syslog Messages with ACL Name Information
100.1.20.2 Mon Jun 9 14:46:31 2003 <46>485232: Jun 9 14:46:29 PDT: 
%SEC-6-IPACCESSLOGP: list 
10.34.1.1 <46>146570: Dec 19 21:01:57 PST: %SEC-6-IPACCESSLOGP: list 
Related Topics

•Taskflow for Policy Table Query from MARS Events

•Understanding Security Manager Device Lookup

•Navigating to Access Rule Policy in Security Manager from MARS

Security Appliance and Router System Log Messages Supported for Policy Lookup

You can configure logging options on security appliances when a deny ACE matches a packet for network access (an access list applied with the access-group command). If you enter the log keyword without any arguments, you enable system log message 106100 at the default level (6) and for the default interval (300 seconds). If you do not enter the log keyword, the default logging occurs, using system log message 106023. In devices with multiple contexts, each security context includes its own logging configuration and generates its own messages.

System log messages begin with a percent sign (%) and are structured as follows:
%{ASA | PIX | FWSM}-Level-Message_number: Message_text
A unique 6-digit number identifies each message. The following syslog message IDs are supported for looking up policies in Security Manager from incidents generated in MARS. If you change the logging level of the firewall, ensure that the following messages IDs are generated at the new level so the MARS Appliance receives them.

106100, 106023, 302013, 302014, 302015, 302016, 302020, 302021

The default level for many of the events that are studied by MARS is the debug level, which can generate a high volume of additional events that are not used by MARS. If you are experiencing an influx of these other events, you can use the logging message command to either turn off events or change the severity level of the event to a level that generates required messages but not as many as debug. For details on the message, explanation, and recommended action for each of these message IDs, see the System Message Guide of the relevant product documentation.

On Cisco IOS routers, system log messages are generated for access lists configured with the log or log-input keywords. Use the log keyword to get access list logging messages, including violations. Use the log-input keyword to include input interface, source MAC address, or virtual circuit in the logging output. The first packet that triggers the access list causes an immediate logging message, and subsequent packets are collected over 5-minute intervals before they are displayed or logged. The logging message includes the access list number, whether the packet was permitted or denied, the source IP address of the packet, and the number of packets from that source permitted or denied in the prior 5-minute interval. You can look up access rules that generate these log messages by clicking the Security Manager policy query icon in the Incident Details page or the Query Results page of MARS.

For IOS routers, system log messages with the following identifiers support policy lookup and the Security Manager icon is displayed beside them in the MARS GUI:

%SEC-6-IPACCESSLOGDP, %SEC-6-IPACCESSLOGNP, %SEC-6-IPACCESSLOGS, %SEC-6-IPACCESSLOGP

For IOS system log messages with IDs other than the ones listed above and that are not generated by access rules, the Security Manager icon is not displayed in the MARS GUI.

Related Topics

•Taskflow for Policy Table Query from MARS Events

•Understanding Security Manager Device Lookup

•Understanding Access Rule Table Lookup

•Navigating to Access Rule Policy in Security Manager from MARS

Understanding Signature Table Lookup

Security Manager 3.2 and MARS 4.3.4 and 5.3.4 support signature summary table lookup for events generated by IPS devices (Cisco IPS sensors and Cisco IOS IPS devices) and IDS sensors. Sensors that use a signature-based technology can detect network intrusions. A signature is a set of rules that your sensor uses to detect typical intrusive activity, such as DoS attacks. As sensors scan network packets, they use signatures to detect known attacks and respond with actions that you define. The sensor compares the list of signatures with network activity. When a match is found, the sensor takes an action, such as logging the event or sending an alert. Signature-based intrusion detection can produce false positives that you can minimize by tuning your signatures. Some signatures have subsignatures, that is, the signature is divided into subcategories. When you configure a subsignature, changes made to the parameters of one subsignature apply only to that subsignature.

Security Manager looks for the following criteria from the raw event message that MARS sends for IPS events:

•Signature ID—Identifies the unique numerical value assigned to this signature. This value lets the sensor identify a particular signature.

•SubSignature ID—Identifies the unique numerical value assigned to this subsignature. A subsignature ID is used to identify a more granular version of a broad signature.

Note Signature policy lookup is not supported for virtual sensors because the sensor ID is not contained in the raw syslog message that is logged in MARS to enable Security Manager to perform a lookup.

Packet Data events that identify the data that was being transmitted on the network the instant an alarm was detected on IPS and IDS sensors can cause the size of the raw message associated with this event to become very huge. Also, these events are not triggered by signature rules on sensors. As a result, the Security Manager icon is not displayed for Packet Data events in the MARS GUI for policy lookup.

Events triggered by custom signature configured on a sensor are categorized as "Unknown Device Event Type" in the MARS GUI and the Security Manager icon is displayed for these events to enable policy lookup.

After a match is found, Security Manager transmits the signature details to MARS and the matching signature parameters are displayed in a read-only popup window in MARS. You can click Edit Signature to navigate to the signature summary table of Security Manager with the matching signature selected. You can also click Event Action Filter from the read-only popup window to configure a filter on the basis of signature categories to remove one or more actions from the signature event. The filter is applied in the order specified in the summary table. The authentication mechanism that you entered while adding Security Manager to MARS is used to open the signature summary table and a new instance of Security Manager is started if one is not running or the existing session times out.

Related Topics

•Taskflow for Policy Table Query from MARS Events

•Understanding Security Manager Device Lookup

•Guidelines for Working with Policy Table Lookup from MARS

•Navigating to IPS Signature Policy in Security Manager from MARS

Guidelines for Working with Policy Table Lookup from MARS

Remember the following points when you query the Security Manager policy table from MARS syslog messages:

•You need to use Security Manager 3.2 and MARS 4.3.4 or 5.3.4 to navigate to the policy table in Security Manager from MARS and modify the matching rule. If you add a Security Manager server running 3.0.x or 3.1.x to a MARS appliance running 4.3.2 through 4.3.4 or 5.3.2 through 5.3.4, you can perform the policy table lookup in view mode only.

Support for read-only policy table lookup from a MARS appliance running 4.3.4 or 5.3.4 is solely to provide backward compatibility with a Security Manager server running 3.0.1, 3.0.2, or 3.1.x.

•The Security Manager policy table lookup icon is not displayed for NetFlow events received by MARS from NetFlow-enabled reporting devices that are positioned within your network because they are not triggered by an access rule.

•The Security Manager policy table lookup icon is not displayed for events of type, Packet Data and Context Data, because they are not generated by signatures configured on Cisco IDS 4.x and Cisco IPS 5.x devices, whether they are sensor appliances or modules.

•For PIX and ASA devices or FWSM blades with multiple security contexts, you must enter the reporting IP address for each context while configuring the device in MARS. Otherwise, the Security Manager icon is not displayed beside events received from the contexts for which the reporting IP address is not defined in MARS and you can query events from such contexts only by running a query for "Unknown Reporting Devices" from MARS.

•A Local Controller can be configured to retrieve the policy tables from only one Security Manager server at a time. An error message is displayed when you attempt to add more than Security Manager server to a Local Controller.

•If you add a Local Controller, to which Security Manager server has been added, to a Global Controller, you can view the Security Manager server in the Security and Monitoring Information list of the Local Controller from the Global Controller interface. However, the Security Manager policy query icon is not displayed beside events or incidents displayed on a Global Controller.

•All users associated with any of the CiscoWorks Common Services roles except the Help Desk role or any of the predefined Cisco Secure ACS roles have permission to modify the matching policy by clicking the Security Manager icon from the read-only policy lookup table.

•While adding a Security Manager to MARS, only users with Admin role can be configured to enable MARS contact and discover Security Manager server configuration. Otherwise, an error message is displayed when you submit your changes.

•All users associated with any of the MARS roles with the exception of the Operator and Notifications Only roles can modify the Security Manager authentication credentials while editing an existing user account in MARS.

•If the Security Manager server cannot be reached from MARS when you perform a policy lookup, an error message is displayed asking you to restore the connection between MARS and Security Manager.

•If HTTPS is not enabled on Security Manager for secure access between the Security Manager server and MARS, an error message is displayed when you try to start Security Manager. Ensure HTTPS is enabled on the Security Manager server so that communication between the Security Manager and MARS is encrypted.

•If the Daemon Manager on the Security Manager server is not running, an error message is displayed prompting you to restart the service when you perform the policy table lookup.

•The MARS Appliance compares the certificate presented by Security Manager with a previously stored instance of the certificate while establishing a secure connection with Security Manager. If a conflict is detected, MARS accepts and stores the replacement certificate, either automatically or after prompting for manual acceptance, depending on the options configured in MARS. For more information on how MARS responds during attempts to establish a secure connection, see User Guide for Cisco Security MARS Local Controller 4.3.x and 5.3.x.

•The Security Manager username and password values that you enter or modify in the Reporting Applications tab is used by MARS to communicate with Security Manager server and discover meta information, such as version of software running on the server and configuration details. These credentials are different from the username and password in the Cisco Security Manager section of the User Configuration page.

The username and password pair in the User Configuration page comprise the credentials that MARS uses to authenticate with Security Manager to look up the policy table, when you select the option to use Security Manager credentials for policy lookup. The Security Manager username and password fields in the User Configuration page are populated with the values you enter in the policy query login dialog box if you chose to allow saving of Security Manager login credentials during policy lookup.

•If you did not specify the username and password for logging in to Security Manager or entered incorrect credentials while adding Security Manager, the connectivity test fails and an error message is displayed. Similarly, if you changed the login credentials in Security Manager but failed to update them in the MARS GUI, an error message is displayed during policy lookup.

•If a Security Manager client session is not open at the time you perform policy lookup, you are not logged out from the Security Manager instance (opened for the purpose of policy lookup) when the idle timeout period is exceeded or when you log out of the MARS session. The Security Manager session closes only when you log out from it or when the idle timeout configured for it is exceeded.

•If you selected the option to use the Security Manager login credentials for MARS to authenticate with Security Manager and did not choose to allow the login credentials to be saved in the login dialog box, these credentials are cached until you exit MARS or the idle session timeout period is exceeded; you are not prompted for login details until the MARS session is active. If the Security Manager session times out after MARS has successfully authenticated with Security Manager and you selected the option to be prompted for login credentials for policy table lookup, the login dialog box is displayed when you click the Security Manager icon from a MARS syslog.

•If you selected the option to be prompted for Security Manager login credentials to authenticate MARS during policy table lookup and deleted the Security Manager server from the MARS database, the username and password fields under the Cisco Security Manager section of the User Configuration Page (Management > User Management tab > Add) in the MARS GUI are dimmed. These fields are also dimmed if you chose not to allow saving of Security Manager login credentials while MARS authenticates with Security Manager.

•If you selected the option to use the Security Manager login credentials for MARS to authenticate with Security Manager and chose to allow the login credentials to be saved in the login dialog box, the username and password fields under the Cisco Security Manager section of the User Configuration Page are activated and can be edited by MARS users with Admin or Security Analyst roles.

•If you saved Security Manager login credentials in the Cisco Security Manager section of the User Configuration page and later logged in to MARS using an account with full read/write privileges to modify the cross-launch authentication settings by deselecting the Allow Users to Save Credentials check box in the Reporting Applications tab, the username and password entries in the Cisco Security Manager section of the User Configuration page are deleted. However, if you perform the same task using an Operator or Notifications Only user role, the Security Manager username and password details are not deleted from the User Configuration page, but can only be viewed.

•If you logged in to Security Manager using a user account that is different from the one that is being used to start Security Manager from MARS for the policy table lookup and you selected the option to use Security Manager credentials, a new instance of the Security Manager client is started even if a client session is active.

•If you log in to MARS using an account that is not defined in the Common Services 3.1 UI and selects the option to use MARS credentials in the Reporting Applications tab, you are prompted to enter the user credentials that is configured in Common Services during policy table lookup.

•If the Security Manager client is not installed on the system from which you are accessing the MARS web interface, you are prompted to install the Security Manager client during policy lookup and the page to download the client software is opened.

•If an instance of the Security Manager client is already running, the existing session is reused by MARS to display the policy lookup table for editing access rules or signatures.

•If the Security Manager client session has timed out or an instance is not active, a new instance of the Security Manager client is started to query the policy table for matching rules and signatures.

•If an instance of the Security Manager client is not running and either Workflow or non-Workflow mode is enabled in Security Manager, MARS performs the lookup query on the policies committed to the Security Manager database.

•If Workflow mode is enabled and an instance of the Security Manager client is active, the lookup query is performed on all policies within the context of the current activity (in an editable state, namely, Edit, Edit Open, Submit, or Submit Open) as well as references found in the data committed to the Security Manager database.

•If non-Workflow mode is enabled and an instance of the Security Manager client is active, the lookup query is performed on all policies in the current login session.

•If a modal window or dialog box is open in Security Manager or the modal window is overlaid with any other application window, an error message is displayed when the policy lookup query is performed. Close the modal dialog box in Security Manager and retry the task.

•If a new instance of the Security Manager client is started during policy table lookup, the time taken to display the matching rules might be slightly greater than the time consumed when a Security Manager client session is active.

•The time taken to display the policy table lookup query results is proportional to the number of rules in the policy table of Security Manager. Increased number of rules might impact the performance of MARS and Security Manager.

•The policy rules retrieved from the Security Manager policy table and displayed in the read-only policy query window in MARS are cached to enhance performance. Caching reduces the time taken to display query results on subsequent lookups as the query results are reused when a request is made to query policies for the same event.

•The Security Manager policy table lookup icon in MARS is displayed only for traffic logs triggered by the following event types:

–Matching of Access rules from a PIX firewall, ASA device, IOS router, or an FWSM blade, regardless of whether the 5-tuple information is available or not. If the 5-tuple data cannot be derived from the syslog, the most accurate match is displayed after policy table lookup.

–Connection establishment and tear-down using TCP, UDP, and ICMP on PIX, ASA, and FWSM devices.

–Firing of signatures from IPS and IOS IPS devices.

Note The versions of software running on the devices that report syslogs to MARS and for which policies are defined in Security Manager must be supported by both Security Manager and MARS. See Devices and OS Versions Supported by Both Security Manager and MARS for a list of devices supported by both Security Manager and MARS.

•The same events received by MARS can display the Security Manager policy table lookup icon inconsistently between the low-latency, realtime event query and standard queries, such as sessions ranked by time. Specifically, the icon will not appear in the low-latency, realtime query, but it may appear in queries against sessionized events.

This behavior is expected. When MARS receives events, they are parsed, sessionized, written to an event shared buffer, and then written to the database. Because sessionization takes time, sometimes keeping an event in cache for 2 minutes, the low-latency event query displays events right after parsing, but before sessionization. Displaying the event at this point allows the low-latency query to achieve a close to realtime effect. For some events, parsing cannot determine some part of the 5-tuple data, such as a destination address. Later, sessionization later fills in such missing data using configuration data. As a result, the 5-tuple data displayed by the low-latency event query can be different from values stored in the database, which are used to populate the standard queries.

•MARS displays the Security Manager security policy committed views, not the deployed views. If you change the access rule in Security Manager and do not deploy the changes to the device, the syslog is generated by the older access rule on the device because the changes are not synchronized and policy lookup is performed on the access rule saved on the device and not on the most recently saved changes in Security Manager.

•When you run a query for realtime or historical events and try to perform policy lookup from an incident in the query results, occasionally, an error message is displayed in the Policy Query popup window stating that an internal error has occurred. This error is temporary and disappears if you retry this operation after a while. You are prompted to log in again to Security Manager and policy lookup should be successful from then on. An error of this type also occurs when RPC connection fails or when policy changes to the device are not submitted to the Security Manager server.

•Although the Security Manager icon is displayed for events generated by ICMP connection teardown syslogs, an error message is displayed when you perform policy lookup from these events. The error message states that the corresponding connection setup syslog for the teardown syslog could not be found and asks you to try this operation after a few seconds. However, the same error is displayed even if you perform lookup at a later time.

•If the access rule associated with a device is empty in Security Manager, an error message is displayed when you perform the policy lookup query from MARS for a syslog generated by an access rule on that device.

•If you perform the policy table lookup for a device added to MARS only and not to Security Manager, an error message is displayed in the read-only policy table window. Make sure that you add the device to Security Manager and discover the policies so that the configuration on the device is synchronized with Security Manager.

•If you attempt to view the Security Manager signature summary table for a virtual sensor, an error message is displayed when you click the Security Manager icon for a syslog message from a virtual sensor because the virtual sensor ID is not available in the MARS event data to perform the policy lookup query.

•An error can occur with the policy query if a device configuration is discovered using Security Manager but it is not submitted in Security Manager. The following error message is an example of this issue:
<190>2312080: *May 9 23:50:02.199: %SEC-6-IPACCESSLOGDP: list 
permit-all permitted icmp 10.2.3.8 -> 
10.4.21.2 (0/0), 1 packet
An error occurred while querying policies from Cisco Security 
Manager. Reason: Failed to retrieve policy 
information from CSM. Reason: Cisco Security Manager Internal 
error: Failed to get interfaces in the device! 
Before you perform policy queries, verify that all discovered devices have been submitted in Security Manager.

•If an access rule policy contains network/host and service objects, the definitions of the elements contained in these objects are displayed in the read-only policy lookup table. For the matching policy, the definitions of the network and service objects are expanded and displayed.

•If no access rule is configured on the lower security interface in the "in" direction of the device for inbound traffic or if the access rule specified in the syslog is not available on the device, an error message is displayed during policy lookup. When you click the Security Manager icon for syslogs associated with such access rules, a message states that a matching rule cannot be found. You are prompted to make sure that the device is added to Security Manager and access rules are configured on it.

•When you click the Security Manager icon for an event triggered by management traffic, an error message is displayed stating that the selected event was not subjected to access rule matches. You are prompted to select another event and retry policy lookup.

•If an event is generated by a connection teardown syslog and the setup and teardown of the connection occur in two different sessions (with a gap of 2 minutes in-between), the corresponding connection establishment syslog is not sent by MARS to Security Manager when you perform policy lookup for such events. As a result, an error message is displayed stating that the connection setup syslog is not available to display the matching rules for that event. An identical error message is also displayed if you attempt to query access rules for a connection teardown event from the realtime event viewer of MARS.

•When you click the Security Manager icon for an event that contains a syslog ID that is not supported for policy lookup, you are prompted to select another supported event. Although the Security Manager icon is displayed in the MARS GUI only for those events that support policy lookup, you might see this error message while looking up policies for events generated by management traffic or connection teardown syslogs without a corresponding setup syslog.

•An error message is displayed stating that the syslog is invalid even when you click the Security Manager icon for one of the syslogs supported for policy lookup. This problem occurs if the syslog is not parsed by Security Manager and the syslog format received from MARS is incorrect.

•When you perform lookup for an event generated by outbound traffic setup/teardown syslog with an access rule configured on the higher security interface in the "in" direction, an error message is displayed stating that an implicit permit statement is present in the access rule. Also, this error message occurs if a firewall device is added to Security Manager and the changes are not submitted to the database at the time of performing policy lookup from MARS.

• If the device for which you perform access rule lookup has been added to Security Manager without submitting the configuration to the database or if the access rule that generated the syslog is not available on the device, an error message is displayed stating that the access rules on the device is not in synchronization with the one configured in Security Manager.

• For inbound traffic, when an event is generated by an access rule present on the lower security interface in the "in" direction and no matching rule found in Security Manager during policy lookup, an error message is displayed stating that the access rules on the device and in Security Manager are not synchronized. This error is also displayed when a matching policy cannot be found for access rules present on the higher security interface in the "in" direction or on the lower security interface in the "out" direction for outbound traffic.

•If you modify the access rule in Security Manager after the read-only policy query window is displayed with highlighted rules that generated the event and start the Security Manager client, the rule table in the read-only policy page is used as the basis for displaying the matched rule in Security Manager and the modified rule table in Security Manager is not considered.

•When you try to lookup a signature policy from an IPS event in MARS, an error message is displayed if invalid event details are passed from MARS to Security Manager.

•If the signature that generated an event in MARS is deleted or modified on the device, an error is displayed stating that the signature is not found when you perform policy lookup for such an event.

Related Topics

•Taskflow for Policy Table Query from MARS Events

•Understanding Security Manager Device Lookup

•Understanding Access Rule Table Lookup

•Understanding Signature Table Lookup

•Navigating to Access Rule Policy in Security Manager from MARS

•Navigating to IPS Signature Policy in Security Manager from MARS

Checklist for Policy Table Lookup from MARS

You can use the following checklist to track the tasks required to integrate MARS with a Security Manager server and the reporting and mitigation devices managed by that Security Manager server. Each step might contain several substeps; the steps and substeps should be performed in order. The checklist contains references to the specific procedures used to perform each task.

Step

Task

Step 1

Identify devices that need to be managed by both Security Manager and MARS.

The first step in integrating MARS and Security Manager involves identifying those devices for which Security Manager is used to define policy rules. You must ensure that devices are running a software version supported by both MARS and Security Manager. For a list of devices supported by both Security Manager and MARS, see Devices and OS Versions Supported by Both Security Manager and MARS.

Step 2

Identify and enable all required traffic flows between the devices and MARS.

After you identify the devices to be managed by the Security Manager server and monitored by MARS, you must verify that the network services they use for management, reporting, and notification are permitted along the required traffic flows. Ensure that the management, logging, and notification traffic between the MARS Appliance and each monitored device is allowed by intermediate gateways. For more information, see User Guide for Cisco Security MARS local Controller 4.3.x and 5.3.x.

Tip It is a recommended security practice to have all devices, including MARS Appliances, synchronized to the same time.

Step 3

Prepare the devices to be managed by Security Manager.

Before you can manage devices using Security Manager, you must set up the devices with a minimum configuration that provides basic connectivity. To enable communication between Security Manager and devices, you must configure transport settings on the devices, before you add them to the inventory. Bootstrapping involves getting the device up and running on the network, assigning it an IP address, and connecting it to the physical media. See the Chapter 5, "Preparing Devices for Management" chapter for details about preparing or bootstrapping the devices.

Step 4

Add the devices to Security Manager.

For more information, see the Managing the Device Inventory chapter.

Step 5

Bootstrap the devices managed by MARS.

After you identify the devices managed by the Security Manager server and to be monitored by MARS, you must prepare, or bootstrap, that device to ensure that the MARS Appliance can receive or pull any necessary logs from those devices. After you identify and bootstrap the devices and enable the required traffic flows, you must represent those devices in MARS, which uses this information to communicate with the devices. For more information on adding and activating devices, see User Guide for Cisco Security MARS Local Controller 4.3.x and 5.3.x.

Step 6

Add the devices to MARS.

For more information, see User Guide for Cisco Security MARS Local Controller 4.3.x and 5.3.x.

Step 7

Bootstrap each Security Manager server and add it to the correct MARS Local Controller.

For more information, see Bootstrapping Security Manager Server to Communicate with MARS.

Step 8

Perform policy lookups as required.

Once an event generated by one of the Security Manager-managed devices is received by MARS, you can perform a policy lookup operation and modify the possible policies that could have affected the generation of that event from the Security Manager server. For more information on how to perform policy table lookup for events generated by access rules and signatures, see the following sections:

•Navigating to Access Rule Policy in Security Manager from MARS

•Navigating to IPS Signature Policy in Security Manager from MARS

Related Topics

•Taskflow for Policy Table Query from MARS Events

•Understanding Security Manager Device Lookup

•Understanding Access Rule Table Lookup

•Understanding Signature Table Lookup

•Guidelines for Working with Policy Table Lookup from MARS

Devices and OS Versions Supported by Both Security Manager and MARS

You must ensure that devices that need to be monitored by MARS and managed by Security Manager are running a software versions supported by both MARS and Security Manager to perform the policy table lookup from MARS syslogs and events lookup from Security Manager policies.

Table 22-7 lists the software versions for each device platform supported by both Security Manager and MARS.

Table 22-7 Supported Devices and OS Versions for Security Manager and MARS Integration

Device Platform

Device OS Version

Cisco IOS Routers

12.x and later

PIX Security Appliances

6.0, 6.1, 6.2, 6.3, 7.0, 7.2, 7.2.1

Adaptive Security Appliances (ASA)

7.0.1, 7.2, 7.2.1

Cisco Intrusion Prevention System (IPS), IDSM-2 module

5.1, 6.0, 6.0.1, 6.0.2, 6.0.3

Cisco IOS Intrusion Prevention System (IOS IPS) sensors

Cisco IOS 12.4(11)T2 (the earliest supported Cisco IOS Software release)

Cisco Catalyst 6500 Series Switches

Cisco IOS 12.2 and later

Firewall Services Module (FWSM)

1.1, 1.2, 2.3, 3.1, 3.1.3, 3.1.5¹

¹FWSM support is supported only in Security Manager Enterprise Edition (Professional-50) and higher. The professional version includes support for the management of Cisco Catalyst 6500 Series switches and associated service modules; the Standard versions do not include this support.

Note For a complete list of devices and OS versions supported by Security Manager and MARS separately, see the Supported Devices and Software Versions document of the respective applications.

Related Topics

•Checklist for Policy Table Lookup from MARS

•Bootstrapping Security Manager Server to Communicate with MARS

•Adding a Security Manager Server to MARS

•Navigating to Access Rule Policy in Security Manager from MARS

•Navigating to IPS Signature Policy in Security Manager from MARS

Bootstrapping Security Manager Server to Communicate with MARS

To prepare the Security Manager server to be queried by MARS, you must configure the following settings:

•If you are using AAA authentication, such as Cisco Secure ACS, on the Common Services 3.1 server, you must update the administrative access settings to ensure that the MARS Appliance has the necessary access to the Security Manager server.

•Define a user account in Security Manager that MARS can use to perform queries. A separate account is recommended to provide a cleaner audit trail on the Security Manager server. You must create a user account with one of the following roles defined in Common Services 3.1 to be able to perform the policy table lookup query and modify the highlighted policy by starting Security Manager from the read-only popup window:

–Approver

–Network Operator

–Network Administrator

–System Administrator

Note Any of the predefined Cisco Secure ACS roles with the exception of the Help Desk role can modify matching policies by starting Security Manager from the read-only policy lookup table. Users with the Help Desk security level can only view the read-only policy lookup table. An error message is displayed when a user with a Help Desk role attempts to start Security Manager to modify a policy from the read-only popup window in MARS.

When you add a Security Manager server to MARS, if you choose to use the option to prompt users for Security Manager credentials for the policy table lookup, you might not need to create a separate MARS user account in the Common Services 3.1 UI for authentication purposes.

For more information on adding users and associating roles with them from the Common Services 3.1 UI, see User Guide for CiscoWorks Common Services 3.1.

Related Topics

•Checklist for Policy Table Lookup from MARS

•Adding a Security Manager Server to MARS

Adding a Security Manager Server to MARS

The Security Manager server is represented in MARS by defining a host with a software application residing on that host. The Security Manager server that you add to the Local Controller can be used to perform policy lookup only for those devices that it manages and that publish their events to MARS.

Each Local Controller can query one Security Manager server only; you cannot define more than one Security Manager server per Local Controller. You can define the same Security Manager server on multiple Local Controllers. When planning the zones for Global Controller/multi-Local Controller deployments, ensure that each Local Controller maps to the Security Manager server that manages the reporting devices monitored by that Local Controller.

If a Security Manager server is not added to MARS, the username and password fields in the Cisco Security Manager section of the User Configuration page are disabled. A message appears in the User Configuration page that the Security Manager credentials for policy table cross-launch cannot be saved in the MARS database because a Security Manager server is not yet added to MARS.

This procedure describes how to identify a Security Manager server to use for policy lookups from within the web interface of MARS.

Before You Begin

•Make sure that the Security Manager server is running version 3.2 if you want to look up the policy table and modify matching rules or signatures. If you add a Security Manager server running 3.0.1, 3.0.2, or 3.1.x to a MARS appliance running 4.3.2 through 4.3.4 or 5.3.2 through 5.3.4, you can query for policies in view mode only; you must open a Security Manager client instance separately to modify the policies.

Adding a Security Manager server running 3.0.1, 3.0.2, or 3.1.x to a MARS appliance provides the same behavior that existed in versions of MARS earlier than 4.3.4 and 5.3.4 to perform policy lookup.

•You must be logged in to the MARS Local Controller as a user with an Admin role.

Related Topics

•Guidelines for Working with Policy Table Lookup from MARS

•Checklist for Policy Table Lookup from MARS

•Devices and OS Versions Supported by Both Security Manager and MARS

•Bootstrapping Security Manager Server to Communicate with MARS

Step 1 Select Admin > System Setup > Security and Monitor Devices > Add.

Step 2 Do one of the following:

•Select Add SW Security apps on a new host from the Device Type list, and continue with Step 3. See Figure 22-1.

•Select Add SW security apps on existing host from the Device Type list. Select the device to which you want to add the software application and click Add. Continue with Step 6.

Figure 22-1 Device Discovery-Add SW security apps on new host

You can select the Add SW Security apps on an existing host option if you have already defined the host within MARS, perhaps as part of the Management > IP Management settings or if you are running another application on the host, such as Microsoft Internet Information Services.

Step 3 Specify values for the following fields:

•Device Name—Enter the name of the host (Security Manager server). This name is used for display purposes only in the MARS GUI and you can assign any meaningful name.

•Access IP—This address is used to discover settings and pull query data from a Security Manager server using HTTPS. This address represents the physical IP address of the Security Manager server.

•Reporting IP—(Optional) Enter the same IP address of the Security Manager server interface as the one entered in the Access IP field. This address also represents the physical IP address of the Security Manager server.

•Operating System—(Optional) Specify the operating system type by selecting Windows or Generic from the drop-down list.

Step 4 Under Enter interface information, enter the interface name, IP address, and netmask value of each interface in the Security Manager server from which configuration information will be queried.

Step 5 Click Apply to save these settings.

Step 6 Click Next to access the Reporting Applications tab.

Step 7 Select the Cisco Security Manager ANY from the Select Application list, and click Add. See Figure 22-2.

Figure 22-2 Device Discovery-Cisco Security Manager ANY Page

Step 8 If you entered an address in the Access IP field on the host that represents this Security Manager server, specify values for the following fields:

•User Name—Identifies the Cisco Security Manager administrative account to be used to discover configuration settings.

•Password—Identifies the password associated with the username account.

•Access Type—Identifies the protocol used to discover configuration information. Select HTTPS from the drop-down list.

•Access Port—Identifies the port that MARS uses to communicate with Security Manager. The default access port for HTTPS is port 443.

Step 9 Under Cross-Launch Authentication Settings, do one of the following:

•Click the Use MARS Credentials radio button if you want to use the MARS login credentials to contact Security Manager for the policy table lookup. The MARS user account must have been previously added to the Local User Setup page in the Common Services UI with a role other than Help Desk to navigate successfully to the Security Manager policy table and modify the matching rules. This option is useful when MARS and Security Manager use a common, external server for authentication and authorization such as Cisco Secure ACS.

•Click the Prompt User radio button if you want to prompt the user to enter the credentials to log in to Security Manager to cross-launch the policy lookup table from MARS. The Security Manager login dialog box is displayed when you click the Security Manager icon to view the read-only policy lookup table. When you select the Prompt User option, you can choose to allow the Security Manager credentials to be saved or not.

When you click this radio button, the Allow Users to Save Credentials check box, beneath it, is enabled. Select this check box if you want the Save Credentials check box in the Security Manager login dialog box to be enabled when you cross-launch the policy lookup table. Selecting the Save Credentials check box causes the Security Manager credentials to be saved in the MARS database and you are not prompted for access details during subsequent lookups.

If you deselect the Allow Users to Save Credentials check box, the Save Credentials check box is disabled in the login dialog box, prompting you to enter the login details each time you start the Security Manager policy table from MARS in a new session or after the timeout period. When the Allow Users to Save Credentials check box is deselected, the Security Manager credentials saved in the MARS database are deleted.

Note Login credentials are cached by MARS when you successfully log in to Security Manager. These credentials are discarded when you exit MARS or the idle session timeout period is exceeded.

If the Allow Users to Save Credentials check box is deselected, the username and password fields in the Cisco Security Manager section of the User Configuration page are disabled. A message appears in the User Configuration page that the Security Manager credentials to perform policy lookup cannot be saved in the MARS database because the Allow Users to Save Credentials check box is deselected. The message appears in the User Configuration page even when you choose to use MARS credentials for policy table lookup.

Step 10 (Optional) Click Test Connectivity to verify that the settings are correct and that the MARS Appliance can communicate with this Security Manager server.

If the username and password are correct and the MARS Appliance is configured as an administrative host for the device, a popup window appears with a "Connectivity successful." message when the discovery operation is successfully completed. Otherwise, an error message appears asking you to click the View Error link for more information about the probable cause and its possible solution.

Step 11 To add this device to the MARS database, click Submit.

The submit operation records the changes in the database tables. However, it does not load the changes into working memory of the MARS Appliance. The activate operation loads submitted changes into working memory.

Step 12 Click Activate.

After the MARS Appliance is activated, it can query the Security Manager server to perform policy lookups.

Navigating to Access Rule Policy in Security Manager from MARS

Access rules filter network traffic by controlling whether routed packets are forwarded or blocked at the firewall's interfaces. Rules are processed by a device from first to last, or first-match basis, against each received packet. After you configure and deploy access rules from Security Manager to a device and enable logging on the device monitored by MARS, a log entry is created when an access rule matches the network traffic that the device is processing and the action defined in the rule is used to decide if traffic needs to be permitted. An incident is generated in MARS after the log associated with an access rule is received from the device.

In MARS, an incident is a chain of events that are correlated by a rule to signal an attack upon your network. MARS simplifies and expedites the detection, mitigation, reporting, and analysis of the incident. The Network Summary dashboard, the Query Results pages, and the Incident pages help to detect recent incidents and show the rules and the events that compose them.

Using MARS, you can also navigate from messages that are generated during the establishment or tearing down of a TCP, UDP, or ICMP connection to the permit ACE in Security Manager for that specific syslog. You can then edit the access rule generating the MARS event or incident to update the action the device must take in response to a receiving packet.

This procedure describes how to look up and modify the access rule in the policy table of Security Manager from an incident in MARS.

Before You Begin

•Make sure you have performed all the tasks in the Checklist for Policy Table Lookup from MARS.

•Make sure that Security Manager can be reached from MARS.

•In the Query Reports page, the following result formats are supported for access rule lookup:

–All Matching Events.

–All Matching Event Raw Messages.

–All Matching Sessions.

–All Matching Sessions, Custom Columns (when Reporting Device Set is selected as one of the custom columns).

Related Topics

•Understanding Security Manager Device Lookup

•Understanding Access Rule Table Lookup

•Guidelines for Working with Policy Table Lookup from MARS

•Adding a Security Manager Server to MARS

•Read-Only Security Manager Policy Lookup Page for Access Rules

Step 1 Log in to the MARS Local Controller. The Dashboard page is displayed with the Summary tab selected.

If you selected the authentication option to use MARS credentials for policy lookup, log in as an Administrator or Security Analyst to be able to modify the matched access rules. If you selected the option to use Security Manager credentials for policy lookup, the MARS login user role does not matter.

Step 2 Identify the incident or event to investigate from the Query Results page or the Incident Details page.

•To navigate to the Query Results page, run a query to return events matching the specified query criteria. For example, if you run a query to return events ranked by time with the most current first from the Query/Reports tab, the Query Results page appears as shown in Figure 22-6. Click the Security Manager icon in the Reporting Device column from the query results.

•To navigate to the Incident Details page (see Figure 22-7), do one of the following:

–From the Query/Reports tab, run a query to return incidents ranked by either number of sessions or bytes transmitted that contain events that meet the query criteria. Click the link in the Incident ID column from the query results.

–From the Recent Incidents section of the Dashboard (see Figure 22-8), click the link in the Incident ID column.

–Click the Incidents tab to navigate to the Incidents page (see Figure 22-9), which displays recent incidents, and click the link in the Incident ID column.

–Search for the Incident ID by entering the ID in the appropriate field and clicking Show beside it.

Step 3 Click the Security Manager icon in the Reporting Device field to invoke the Security Manager policy table lookup.

If you selected the option to be prompted for credentials to log in to Security Manager for policy table lookup, a login dialog box is displayed. Otherwise, one of three popup windows is displayed.

Step 4 Enter the Security Manager login credentials and click OK.

You are prompted for credentials the first time you start a new MARS session. These credentials are cached until the session expires or you open a fresh session.

Note This dialog box is not displayed if you chose to use MARS credentials for logging in to Security Manager, or selected the check box to save Security Manager credentials when you performed the policy table lookup earlier.

If you access the MARS GUI using Internet Explorer, it is possible that the password is automatically entered in the login dialog box after you enter the username. This behavior occurs if you configured your browser to remember passwords. See the "Interoperation of MARS and Security Manager" chapter in the FAQ and Troubleshooting Guide for Cisco Security Manager 3.2 for information on how cached passwords can be cleared or the caching feature can be disabled.

One of the following three popup windows may appear:

•Multiple Events window— Lists all reporting device events in the session, this window appears in this step when there are two or more events in the session. See Figure 22-3. Go to Step 5.

•Multiple Devices window—Lists all matching reporting devices that meet criteria available to MARS. This window appears when there are two or more matching devices. See Figure 22-4. Go to Step 6.

•Policy Table window—Lists the policy table of the reporting device. Access rules that match the MARS criteria are highlighted, this window appears in this step when there is one event and a unique reporting device identified. See Figure 22-5. For a description of the elements in the Policy Query window, see Read-Only Security Manager Policy Lookup Page for Access Rules.

Figure 22-3 MARS Multiple Events Pop-up Window

Figure 22-4 MARS Multiple Devices Pop-up Window

Figure 22-5 Read-Only Access Rule Table Pop-up Window

Step 5 (Optional) If the Multiple Events window is displayed, click the Security Manager icon in the Policy field of the appropriate event. One of the following two popup windows may appear:

•Multiple Devices window. Go to Step 6.

•Policy Table window. For a description of the elements in the Policy Query window, see Read-Only Security Manager Policy Lookup Page for Access Rules.

Step 6 (Optional) If the Multiple Devices popup window is displayed, click the radio button next to the appropriate reporting device. Click Select. The read-only access rule table popup window appears for the selected device.

The access rules that match the MARS query criteria are highlighted. The access rules displayed in the read-only policy table window depend on whether an instance of the Security Manager client is running and whether Workflow or non-Workflow mode is enabled. For more information, see Task 6 in the Taskflow for Policy Table Query from MARS Events.

If there are more rules in the access rule table than can displayed in a single page, they are displayed across several pages and you can navigate back and forth. Pagination allows you to display a maximum number of items per page. Additional items carry over to the next page. You choose the number of items to display per page from the Rows per page drop-down list. Select a value from the Go to page drop-down list to navigate to the page number you desire, and click Prev or Next to navigate between pages.

To switch between matched rules, click Prev or Next, as required, beside the Go to matched policy drop-down list for each highlighted access rule. Select the first or last rule number from the Go to matched policy list to navigate to the first or last highlighted access rule. If multiple access rules match the query criteria, the first matching rule is highlighted, regardless of whether the page in which the match is found is the first page of the access rule table or not.

If an access rule contains network/host, interface, or service objects, you can click the object in the read-only policy lookup table to view the definitions of these objects in a popup window.

Step 7 Click the hyperlink in the rule number under the No. column for a highlighted access rule.

Note If an instance of the Security Manager client is running, the same instance is reused for the policy table lookup. If the Security Manager client session has timed out or is not open, a new client session is started. If the Security Manager client is not installed on the system, you are prompted to install the Security Manager client and the page to download the client software is opened.

Note When you try to start the Security Manager client from the read-only policy query window in MARS, the File Download dialog box appears prompting you to confirm whether you want to download the CsmContentProvider file to your system. This dialog box appears because of security settings in Internet Explorer. To enable the Open button to be displayed in this dialog box during during policy lookup, see the "Interoperation of MARS and Security Manager" chapter in the FAQ and Troubleshooting Guide for Cisco Security Manager 3.2.

The Security Manager client window is activated and the Access Rules page appears with the access rule that generated the event highlighted in the policy table. You can modify the access rule to control the flow of network packets and deploy the updated policy to the device to refine network protection.

If the highlighted access rule contains network/host, service, or interface objects, right-click the appropriate table cell of the rule in the Access Rules page and select Show <object> Contents from the shortcut menu to view the list of flattened values of the object.

Step 8 Click Transcript Details at the bottom of the read-only access rule table to open a popup window that displays information about the raw syslog for the event that you selected in MARS and the parsed format of the syslog after it is processed by Security Manager to find access rules that generated the syslog. These details enable you to understand the taskflow of the access rule lookup query and are informational messages, which can used to troubleshoot errors.

Step 9 Click the CS Manager Details link at the bottom of the page to open a dialog box displaying the server name, username used to log in to Security Manager, whether Workflow mode is enabled, and the activity from which the signature details are retrieved. Click the Close icon to close the dialog box.

Navigating to IPS Signature Policy in Security Manager from MARS

Sensors scan network packets using signatures to detect attacks or other misuses of network resources. When the sensor finds a match for an incoming packet with the signature, it takes some action, such as logging the event. If the signatures are configured on the sensor using Security Manager and the sensor is monitored by MARS, the sensor publishes the logs to MARS. From the Query page, you can define the query parameters and run a query to return events or incidents generated by signatures configured on the sensor. You can click the Security Manager icon from the returned events or raw messages associated with events. Alternatively, you can select a particular incident ID from the returned query results and view the details associated with the incident. From the Incident Details page, you can click the Security Manager icon in the Reporting Device column for the event that you want to examine.

Note In the Query Reports page, the following result formats are supported for access rule lookup:

•All Matching Events.

•All Matching Event Raw Messages.

•All Matching Sessions.

•All Matching Sessions, Custom Columns (when Reporting Device Set is selected as one of the custom columns).

A collection of events generated by sensors are also displayed in the Incidents page from which you can select an incident ID and navigate to the signature policy in Security Manager. You can then edit their parameters (tune them) to achieve optimal performance on your network, and particularly to minimize false positives and false negatives.

This procedure describes how to look up and modify an IPS signature in the signature summary table of Security Manager from an incident in MARS.

Before You Begin

•Make sure you have performed all the tasks in the Checklist for Policy Table Lookup from MARS.

•Make sure that Security Manager can be reached from MARS.

Related Topics

•Taskflow for Policy Table Query from MARS Events

•Understanding Security Manager Device Lookup

•Understanding Signature Table Lookup

•Adding a Security Manager Server to MARS

•Read-Only Security Manager Policy Lookup Page for an IPS Signature

Step 1 Log in to the MARS Local Controller. The Dashboard page is displayed with the Summary tab selected.

If you selected the authentication option to use MARS credentials for policy lookup, log in as an Administrator or Security Analyst to be able to modify the matched access rules. If you selected the option to use Security Manager credentials for policy lookup, the MARS login user role does not matter.

Step 2 Identify the incident or event to investigate from the Query Results page or the Incident Details page in one of the following ways:

•To navigate to the Query Results page, run a query to return events matching the specified quer criteria. For example, if you run a query to return events ranked by time with the most current first from the Query/Reports tab, the Query Results page appears as shown in Figure 22-6. Click the Security Manager icon in the Reporting Device column from the query results.

•To navigate to the Incident Details page (see Figure 22-7), do one of the following:

–From the Query/Reports tab, run a query to return incidents ranked by either number of sessions or bytes transmitted that contain events that meet the query criteria. Click the link in the Incident ID column from the query results.

–From the Recent Incidents section of the Dashboard (see Figure 22-8), click the link in the Incident ID column.

–Click the Incidents tab to navigate to the Incidents page (see Figure 22-9), which displays recent incidents, and click the link in the Incident ID column.

–Search for the Incident ID by entering the ID in the appropriate field and clicking Show beside it.

Figure 22-6 Query Results Page with Matching Events

Figure 22-7 Incident Details Page

Figure 22-8 Recent Incidents on MARS Summary Page

Figure 22-9 MARS Incidents Page

Step 3 Click the Security Manager icon in the Reporting Device field to invoke the Security Manager policy table lookup. If you selected the option to be prompted for credentials to log in to Security Manager for policy table lookup, a login section is displayed in the Policy Query popup window. See Figure 22-10Go to Step 4.

Otherwise, the Cisco Security Manager Policy Query popup window is displayed with the signature parameters in read-only mode. See Figure 22-11Go to Step 5. For a description of the elements in the Policy Query window, see Read-Only Security Manager Policy Lookup Page for an IPS Signature.

Note Events triggered by custom signature configured on a sensor are categorized as "Unknown Device Event Type" in the MARS GUI and the Security Manager icon is displayed for these events to enable policy lookup.

Figure 22-10 Read-Only Signature Policy Pop-up Window with Login Section

Figure 22-11 Read-Only Signature Policy Pop-up Window with Matching Signature Parameters

Step 4 Enter the Security Manager login credentials and click OK. The Cisco Security Manager Policy Query popup window is displayed with the signature parameters in read-only mode. For a description of the elements in the Policy Query window, see Read-Only Security Manager Policy Lookup Page for an IPS Signature.

You are prompted for credentials the first time you start a new MARS session. These credentials are cached until the session expires or you open a fresh session.

Note This dialog box is not displayed if you chose to use MARS credentials for logging in to Security Manager, or selected the check box to save Security Manager credentials when you performed the policy table lookup earlier.

If you access the MARS GUI using Internet Explorer, it is possible that the password is automatically entered in the login dialog box after you enter the username. This behavior occurs if you configured your browser to remember passwords. See the "Interoperation of MARS and Security Manager" chapter in the FAQ and Troubleshooting Guide for Cisco Security Manager 3.2 for information on how cached passwords can be cleared or the caching feature can be disabled.

Step 5 Do one of the following:

•Click Edit Signature to open the Signatures page in Security Manager. The IPS signature that generated the event is highlighted in the policy table. You can tune the signature parameters to detect network intrusions.

Note If an instance of the Security Manager client is running, the same instance is reused for the policy table lookup. If the Security Manager client session has timed out or is not open, a new client session is started. If the Security Manager client is not installed on the system, you are prompted to install the Security Manager client and the page to download the client software is opened.

•Click Add Filter to open the Add Event Action Filter dialog box in Security Manager to remove specific actions from an event or to discard an entire event and prevent further processing by the sensor. The fields that specify the actions that should be removed from the event, the percentage of packets to deny for deny attacker features, and the port and IP address used by the attacker host are populated with values derived from the event logged in MARS. The remaining fields in the Add Event Action Filter dialog box are displayed with default values. When you save the event action filter, it is stored as a local policy filter for that specific device.

•Click the CS Manager Details link at the bottom of the page to open a dialog box displaying the server name, username used to log in to Security Manager, whether Workflow mode is enabled, and the activity from which the signature details are retrieved. Click the Close icon to close the dialog box.

Note When you try to start the Security Manager client from the read-only policy query window in MARS, the File Download dialog box appears prompting you to confirm whether you want to download the CsmContentProvider file to your system. This dialog box appears because of security settings in Internet Explorer. To enable the Open button to be displayed in this dialog box during policy lookup, see the "Interoperation of MARS and Security Manager" chapter in the FAQ and Troubleshooting Guide for Cisco Security Manager 3.2.

Read-Only Security Manager Policy Lookup Page for Access Rules

Use the Cisco Security Manager Policy Query page in the MARS GUI to view the access rule that triggered the incident that you want to examine. This page takes one of the following forms, depending on the number of events and devices that match the incident you are investigating.

•A list of all reporting device events in the session when there are two or more events in the session. Click the Security Manager icon in the Reporting Device field for the event whose access rules you want to lookup. If multiple devices match the MARS query criteria, the page refreshes to display the information as described in the next bullet. If a unique device can be identified for the event, the page assumes the form as described in the third bullet.

•A list all matching reporting devices that meet criteria available to MARS when there are two or more matching devices. A radio button is displayed next to each device to select the device for which you want to lookup access rules. Selecting a device causes the page to display the information as described in the next bullet.

•Access rule table of the reporting device. Access rules that match the MARS criteria are highlighted, this window appears in this step when there is one event and a unique Security Manager device identified.

•An error message if no device matches the MARS query criteria.

Navigation Path

To access the read-only policy lookup page for access rules, do one of the following:

1. From the Query/Reports tab, run a query to return events or raw messages associated with events that meet the query criteria to display the Query Results page. Click the Security Manager icon in the Reporting Device column from the query results.

2. In the MARS GUI, navigate to the Incident Details page in one of the following ways:

–From the Query/Reports tab, run a query to return incidents ranked by either number of sessions or bytes transmitted that contain events that meet the query criteria. Click the link in the Incident ID column from the query results.

–From the Recent Incidents section of the Dashboard, click the link in the Incident ID column.

–Click the Incidents tab to navigate to the Incidents page, which displays recent incidents, and click the link in the Incident ID column.

–Search for the Incident ID by entering the ID in the appropriate field and clicking Show beside it.

Click the Security Manager icon in the Reporting Device field of the Incident Details page for incidents generated by access rules.

Related Topics

•Navigating to Access Rule Policy in Security Manager from MARS

•Guidelines for Working with Policy Table Lookup from MARS

•Taskflow for Policy Table Query from MARS Events

Note Although this page contains elements other than those listed in the field reference table, these elements are read-only or are used to navigate to other pages in MARS. Only the elements with which you can perform actions specific to access rule table lookup are listed in the table.

Note Even though the Security Manager icon in the event displayed at the top of the page can be clicked, it only refreshes the page with the same contents. You need to click the hyperlink in the rule number of the read-only policy table to navigate to the Access Rules page in the Security Manager client; clicking this icon does not start the Security Manager client.

Field Reference

Table 22-8 Read-Only Access Rule Policy Lookup Page

Element

Description

Cisco Security Manager Login

Available only if you selected the option to prompt the user for Security Manager login credentials for access rule lookup and the Security Manager credentials are neither cached nor saved in the MARS database.

User Name

The username for logging in to Security Manager.

Note The user must have administrative privileges to open the Security Manager client from the read-only access rule table. Otherwise, an error message is displayed when you click the hyperlinked rule number from the No. column of the access rule table.

Password

The password for logging in to Security Manager.

Submit

Sends the entered credentials to Security Manager and displays the read-only access table in the same page, if authentication is successful.

Save Credentials

Available only if the Allow Users to Save Credentials check box is selected in the Reporting Applications tab of MARS.

When selected, Security Manager credentials are saved in the MARS database and reused during policy lookup. You are not prompted for credentials during subsequent policy lookup operations if you select this check box.

Access rule policy table

If the Security Manager Login section is displayed, this table appears after MARS is successfully authenticated with Security Manager. Also, if a unique device and a single event cannot be identified for an incident, this table is displayed after you select the required device and event from the list of multiple devices and multiple events.

Go to matched policy

Select the rule number to which you want to navigate in the table.

Prev

Click to move to the matching access rule previous to the one currently highlighted in the table.

Next

Click to move to the matching access rule next to the one currently highlighted in the table.

No.

Identifies the ordered rule number in the table. Click the hyperlink in the rule number to start the Security Manager client with the current row highlighted the access rule table and modify its settings. Hold your cursor over the rule number to view a tooltip.

Note If an instance of the Security Manager client is already open, the same instance is activated.

Source

Identifies the source network object names or addresses of hosts and networks, for example, 10.1.1.1, 10.1.1.1/32, 10.1.1.1/255.255.255.255 and net10.

Clickable only if it represents a network object. Clicking the object displays the contents of the object in a popup window. The source IP address or hostname contained in the object is highlighted in the popup window if it matches with the source IP address in the syslog that generated this rule.

Destination

Identifies the destination network/host object names or addresses of hosts or networks.

Clickable only if it represents a network object. Clicking the object displays the contents of the object in a popup window. The destination IP address or hostname contained in the object is highlighted in the popup window if it matches with the destination IP address in the syslog that generated this rule.

Service

Identifies service objects that specify protocol and port information.

Clickable only if it represents a service object. Clicking the object displays the contents of the object in a popup window. The protocol and port contained in the interface object are highlighted in the popup window if they match with the protocol in the syslog that generated this rule. However, this feature of highlighted entries is supported only for TCP-based and UDP-based rules.

Interface

Identifies the logical name of the interface (interface role) or physical interface to which a rule is assigned.

Clickable only if it represents an interface object. Clicking the object displays the contents of the object in a popup window. Unlike network/host and service objects, the flattened-out interface objects that match with the interface value in the syslog that generated this rule are not highlighted in the popup window.

Go to page

Select the page number to which you want to navigate. Click Prev and Next on either side of the drop-down list to navigate between pages.

Rows per page

Select the number of rows that you want to be displayed in each page of the access rule table.

Transcript Details

Click to open a dialog box displaying information about the raw syslog for the event that you selected in MARS and the parsed format of the syslog after it is processed by Security Manager to find access rules that generated the syslog. These details enable you to understand the taskflow of the access rule lookup query and are informational messages, which can be used to troubleshoot errors.

CS Manager Details

Click open a dialog box displaying the server name, username used to log in to Security Manager, whether Workflow mode is enabled, and the activity from which the signature details are retrieved.

Read-Only Security Manager Policy Lookup Page for an IPS Signature

Use the Cisco Security Manager Policy Query page in the MARS GUI to view the signature that triggered the incident that you want to examine. From this page, you can open the Security Manager client to edit the signature parameters or define an event action filter to remove specific actions from an event.

Navigation Path

To access the read-only policy lookup page for IPS signatures, do one of the following:

1. From the Query/Reports tab, run a query to return events or raw messages associated with events that meet the query criteria to display the Query Results page. Click the Security Manager icon in the Reporting Device column from the query results.

2. In the MARS GUI, navigate to the Incident Details page in one of the following ways:

–From the Query/Reports tab, run a query to return incidents ranked by either number of sessions or bytes transmitted that contain events that meet the query criteria. Click the link in the Incident ID column from the query results.

–From the Recent Incidents section of the Dashboard, click the link in the Incident ID column.

–Click the Incidents tab to navigate to the Incidents page, which displays recent incidents, and click the link in the Incident ID column.

–Search for the Incident ID by entering the ID in the appropriate field and clicking Show beside it.

Click the Security Manager icon in the Reporting Device field of the Incident Details page for incidents generated by signatures.

Related Topics

•Navigating to IPS Signature Policy in Security Manager from MARS

•Guidelines for Working with Policy Table Lookup from MARS

•Taskflow for Policy Table Query from MARS Events

Note Although this page contains elements other than those listed in the field reference table, these elements are either read-only or are used to navigate to other pages in MARS. Only the elements with which you can perform actions specific to signature policy lookup are listed in the table.

Even though the Security Manager icon in the event displayed at the top of the page can be clicked, it only refreshes the page with the same contents. You need to click Edit Signature to navigate to the Signatures page in the Security Manager client; clicking this icon does not start the Security Manager client.

Field Reference

Table 22-9 Read-Only Signature Policy Lookup Page

Element

Description

Cisco Security Manager Login

Available only if you selected the option to prompt the user for Security Manager login credentials for signature rule lookup in the Reporting Applications tab and the Security Manager credentials are neither cached nor saved in the MARS database.

User Name

The username for logging in to Security Manager.

Note The user must have administrative privileges to open the Security Manager client from the read-only signature details page. Otherwise, an error message is displayed when you click Edit Signature or Add Filter.

Password

The password for logging in to Security Manager.

Submit

Sends the entered credentials to Security Manager and displays the read-only signature parameters in the same page, if authentication is successful.

Save Credentials

Available only if the Allow Users to Save Credentials check box is selected in the Reporting Applications tab of MARS.

When selected, Security Manager credentials are saved in the MARS database and reused during policy lookup. You are not prompted for credentials during subsequent policy lookup operations if you select this check box.

Signature Details

If the Cisco Security Manager Login section is displayed, this section appears after MARS is successfully authenticated with Security Manager. Otherwise, these details are displayed immediately after the policy query lookup page is opened.

Edit Signature

Click to open the Signatures page in Security Manager. The IPS signature that generated the event is highlighted in the policy table.

If an instance of the Security Manager client is already open, the same instance is activated. If the Security Manager client is not installed on the system, you are prompted to install the Security Manager client and the page to download the client software is opened.

Add Filter

Opens the Add Event Action Filter dialog box in Security Manager with the Actions to Subtract, % to Deny, Attacker Address, and Attacker Port fields populated with values derived from the MARS event. The remaining fields are displayed with default values.

Signature ID

Identifies the unique numerical value assigned to this signature. The signature ID contains hyperlinks to the Cisco Network Security Database (NSDB). Clicking on the link in the ID column will trigger the opening of an external browser window that opens to the entry in Security Center (MySDN) for that signature.

Signature Parameters

Displays the built-in micro-engine parameters for a particular signature. These parameters determine how the signature is configured and applied to an incoming packet.

Click the + icon beside the Parameters option to expand the tree and display the available signature parameters. If a + icon appears beside any of the items in the expanded list, it indicates that more options are available for this parameter.

CS Manager Details

Click open a dialog box displaying the server name, username used to log in to Security Manager, whether Workflow mode is enabled, and the activity from which the signature details are retrieved.

MARS Events Lookup from a Security Manager Policy

Security Manager 3.2 integrates with MARS 4.3.4 and 5.3.4 to quickly examine events generated in MARS by firewall and signature policies configured on network devices and optimize them to eliminate attacks and maintain compliance. As security policies become increasingly complex, enforcing them and managing changes becomes an arduous day-to-day task. At the same time, troubleshooting and monitoring updates requires expertise that comes with a higher cost of maintenance. To enable rapid troubleshooting for security appliance deployments of any nature, including those with complex security policies and numerous access rules, Security Manager 3.2 provides a facility to navigate to the events associated with an access rule or signature in MARS. MARS aggregates and presents massive amounts of network and security data in an easy-to-use format. Based on the information derived from the event log, you can edit the necessary policies and counter security threats.

Navigation from a Security Manager policy to a MARS event eliminates the need to run a detailed query in MARS by retrieving and populating the query criteria from the policy settings. If objects are referenced in policies, the complexity of the query criteria is increased because the components of the objects might need to be entered in the strings to be queried. However, when you select a Security Manager policy to navigate to the event generated in the MARS GUI by that policy, the contents of the objects are also expanded and prepopulated in the query fields.

The following sections describe how to configure Security Manager and MARS to ensure seamless integration for events lookup in MARS from the Security Manager policy table:

•Taskflow for MARS Events Query from Policy Table

•Understanding MARS Events Lookup

•Obtaining Events for an Access Rule Policy

•Obtaining Events for a Signature Policy

•Guidelines for Working with MARS Events Lookup from Security Manager

•Checklist for Events Lookup from Security Manager

•Adding a MARS Appliance to Security Manager

•Navigating to MARS Events from an Access Rule Policy

•Navigating to MARS Events from an IPS Signature Policy

Taskflow for MARS Events Query from Policy Table

From the Access Rules and Signatures pages in Security Manager, you can navigate to the Query Criteria: Result page of MARS to run a query using the query criteria populated by the policy settings and investigate an incident. The results of the query enable you to examine the event generated by the access rule or signature and modify the rules to suit your needs. You can right-click a signature or an access rule, depending on the type of the device, to set up a low-latency, realtime event query or a standard, sessionized query in MARS. You can then run the query or save the query criteria to reuse as a report. The result of a query and of a report is exactly the same, but you can save reports to avoid having to enter the values every time you want that specific output. The following steps depict the process of querying events in MARS from the policy table in Security Manager:

1. From the policy table in the Security Manager client, right-click an IPS signature ID or a firewall access rule, and select the option to view realtime or historical events in MARS. For access rules, you can also query for events matching a traffic flow, a particular access rule, and source or destination addresses.

2. Security Manager needs to associate the MARS device with the device that it monitors. If multiple MARS devices monitor the same device, Security Manager prompts you to select a MARS device from a list of available choices. If only one MARS device monitors a device, Security Manager automatically performs the mapping between MARS and the device. You can either discover the MARS device monitoring a device prior to lookup and save the mapping in the Security Manager database or establish the mapping at the time of looking up events.

3. Security Manager client sends an XML query to MARS, based on the type of event being queried. Security Manager server establishes an HTTPS connection and authenticates with MARS by using the Security Manager credentials or prompting the user for MARS credentials or using the Security Manager username and password saved in the MARS database, depending on the authentication mechanism chosen while adding MARS to Security Manager.

4. If authentication fails, Security Manager displays an error message in a popup window. If authentication with MARS is successful, MARS, in turn, needs to authenticate with Security Manager. MARS uses the credentials entered when Security Manager was added to MARS to authenticate itself. Once the two-way authentication is complete, MARS displays a popup window with the query parameters.

If you query for historical events matching an access rule or signature, the Query Criteria: Result page is displayed in the MARS GUI. You can either run an on-demand query or save the criteria as a report to run at a later time. For historical events, the Result Format drop-down list is populated with the All Matching Events option and the Filter By Time value is set to the last 10 minutes by default in the Query Criteria: Result page. If you query for realtime events, the query is run based on the values obtained from the selected policy rule in Security Manager and the results of the query are displayed in the Query Results page of MARS.

Note For realtime events, the query is automatically run when you lookup access rules or signatures and the results of the query are displayed in the realtime event viewer of MARS. However, for historical events, only the query criteria fields are populated from the data derived from Security Manager and the query must be submitted to view matching events. The time to be used to filter logged historical events is set to the last 10 minutes from the present time.

Related Topics

•Understanding MARS Events Lookup

•Obtaining Events for an Access Rule Policy

•Obtaining Events for a Signature Policy

•Guidelines for Working with MARS Events Lookup from Security Manager

•Checklist for Events Lookup from Security Manager

•Adding a MARS Appliance to Security Manager

•Navigating to MARS Events from an Access Rule Policy

•Navigating to MARS Events from an IPS Signature Policy

Understanding MARS Events Lookup

Security Manager requests the events matching an access rule by supplying the device details and other information associated with the access rule, such as service, source/destination addresses, action, and direction, to MARS. MARS displays the Query page with the following attributes prepopulated using the values passed by Security Manager:

•Device Details—General information about the device, such as hostname, domain name, management IP address, and display name.

•Source addresses—Source addresses of hosts and networks or collections of IP addresses in the network/host objects.

•Destination addresses—Destination addresses of hosts and networks or collections of IP addresses in the network/host objects.

•Service—Protocol and port information.

•Event Type—Groups of similar security events. An event type indicates some type of network activity or condition. Sometimes, events reported from different devices and different device types identify the same activity or condition, and therefore, they map to the same event type within MARS. An event type is the normalized signature from a reporting device. The MARS Appliance comes with a number of predefined event types. An event ID, which is a unique identifier for the event, is also sent with the event type to MARS.

•Keyword—ACL names and ACE hashcodes, if available, for access rule events or signature IDs and virtual sensor names for IPS events, combined with logical operators.

Note ACE hashcodes are supported on security appliances running a version of PIX or ASA software later than 7.0 only.

Because Security Manager and MARS do not share a common device repository, the XML query created by Security Manager and sent to MARS includes all the device information (management IP address, hostname, domain name, and display name) available in its database. MARS tries to match this information against the devices added to the MARS database. Events lookup from the policy table succeeds only if the relevant devices are added to both Security Manager and MARS and can be reached by MARS from Security Manager using a common IP address or hostname. For a complete list of devices and OS versions supported by Security Manager and MARS separately, see the Supported Devices and Software Versions document of the respective applications..

For events associated with IPS and IOS IPS devices, Security Manager uses the device details, signature ID, and subsignature ID to populate the query criteria fields in the Query page opened in MARS. If a virtual sensor is configured on your IPS device, the Keyword field displays the virtual sensor name in addition to the signature and subsignature IDs. You can also select multiple signatures from the Signatures policy table of Security Manager and query for realtime or historical events.

Sensors and other network devices can continually forward events to MARS. These events are stored in the MARS database. Querying for historical events from Security Manager policies allows you to view the events stored in the MARS database. You can also navigate from policies in Security Manager to view realtime events as they are forwarded to MARS. The following sections describe the differences in the syslogs displayed for realtime and historical events from access rule and signature policies in Security Manager:

•About Historical Events for a Policy

•About Realtime Events for a Policy

Related Topics

•Taskflow for MARS Events Query from Policy Table

•Obtaining Events for an Access Rule Policy

•Obtaining Events for a Signature Policy

•Guidelines for Working with MARS Events Lookup from Security Manager

•Checklist for Events Lookup from Security Manager

•Adding a MARS Appliance to Security Manager

•Navigating to MARS Events from an Access Rule Policy

•Navigating to MARS Events from an IPS Signature Policy

About Historical Events for a Policy

Using Security Manager, you can select from an access rule or signature ID and view historical event data in MARS. Historical events are forensic analysis tools that enable you to identify trends over longer periods of time than the real-time monitoring features of MARS. For an historical event query, MARS sessionizes the event data after it is received from the device and parsed. Sessionizing takes two forms: reconstructing a session-oriented protocol, such as TCP, where the initial handshake and the session tear down and reconstructing a sessionless protocol, such as UDP, where the initial start and session end times are defined more based on first and last packets tracked within a restricted time period. In other words, packets that fall outside of the time period are considered part of different sessions. When you perform an historical event query from a firewall access rule policy in Security Manager, syslogs triggered by connection establishment and teardown are also displayed in addition to the ones generated by access rules in the Query page of MARS.

Related Topics

•About Realtime Events for a Policy

•Understanding MARS Events Lookup

•Obtaining Events for an Access Rule Policy

•Obtaining Events for a Signature Policy

•Guidelines for Working with MARS Events Lookup from Security Manager

•Checklist for Events Lookup from Security Manager

•Adding a MARS Appliance to Security Manager

•Navigating to MARS Events from an Access Rule Policy

•Navigating to MARS Events from an IPS Signature Policy

About Realtime Events for a Policy

The realtime event viewer in MARS is a query option that permits you to monitor traffic in near real-time events as follows:

•View raw events as they stream to MARS before they are sessionized, with a maximum 5-second delay

•View a sessionized event stream—more delay is possible when there are many events in a session

When you query an access rule or a signature ID from Security Manager for realtime events in MARS, sessionized messages are displayed in the realtime event viewer, by default. The realtime events display as a continuously scrolling screen. You can configure query criteria to filter what is displayed. When viewing raw events, sessionization is not impeded, all the parsed raw events are sessionized per normal MARS operation. To view the most recent realtime events, you can submit the query at any time, adjust the scrolling rate, or pause and restart to reinitialize the realtime event viewer. The most recent events are always at the bottom of the output queue, and their freshness when you view them is limited by the number of events in the queue and the scroll speed of the display.

When MARS receives events, they are parsed, sessionized, written to an event shared buffer, and then written to the database. Because sessionization takes time, sometimes keeping an event in cache for 2 minutes, the realtime event query can be used to display events right after parsing and provides access to the most current data received.

When NAT or PAT is configured on the firewall, the source and destination addresses are mapped to the pre-NAT and post-NAT addresses accordingly. Regardless of whether NAT or PAT is configured on the device, the pre-NAT and post-NAT addresses are specified in the XML event query parameters for the source and destination address fields when Security Manager sends a query to MARS to look up events from policies. For inbound access rules, the destination address is considered as the pre-NAT address and for outbound access rules, the source address is considered as the post-NAT address.

Related Topics

•About Historical Events for a Policy

•Understanding MARS Events Lookup

•Obtaining Events for an Access Rule Policy

•Obtaining Events for a Signature Policy

•Guidelines for Working with MARS Events Lookup from Security Manager

•Checklist for Events Lookup from Security Manager

•Adding a MARS Appliance to Security Manager

•Navigating to MARS Events from an Access Rule Policy

•Navigating to MARS Events from an IPS Signature Policy

Obtaining Events for an Access Rule Policy

An ACE is a single entry in an access list that specifies a permit or deny rule, and is applied to a protocol, a source and destination IP address or network, and optionally the source and destination ports. From a firewall access rule table in Security Manager, you can right-click an access rule and navigate to events or syslogs triggered by the access rule in MARS. You can view realtime and historical syslogs matching a rule or a traffic flow. For events matching a rule, only syslogs generated by access rules are displayed. However, for events matching a flow, as all the necessary details from an access rule, such as pre-NAT and post-NAT addresses, are available in the query parameters sent by Security Manager, syslogs generated by connection setup/teardown are also displayed in addition to those generated by firewall access rules in the Query page of MARS.

When you select the option to display events matching a rule, the support of ACE hashcodes by the version of software running on a device determines the accuracy of syslog matches. Although Security Manager is able to gather the device information, the appropriate event types in MARS, 5-tuple data from the ACEs, and the ACL, these details can result in inaccurate or excessive syslog matches. To produce most accurate syslog matches for an ACE, PIX and ASA 7.0 and later support ACE hashcodes. Each ACE contains an MD5 hashcode, which is included in the syslogs generated by that ACE. For PIX and ASA devices running 7.0 or later, Security Manager includes the hashcodes of the ACEs generated by the selected rule in the query sent to MARS. ACE hashcodes are not supported on security appliances running a version of PIX or ASA software earlier than 7.0.

When Security Manager server contacts MARS to query the events associated with an ACE, two-way authentication between MARS and Security Manager takes place. On successful handshake, MARS requests the query parameters to populate the search criteria in the Query page of the MARS GUI. The following are the fields that Security Manager provides to MARS to display as query criteria for events that match an access rule:

•Device details—General information about the device, such as hostname, domain name, management IP address, and display name.

•Source addresses—Source addresses of hosts and the network/host objects expanded to display the networks or collections of IP addresses.

•Destination addresses—Destination addresses of hosts and the network/host objects expanded to display the networks or collections of IP addresses.

•Service—Protocol and port information.

•Event Type—"Built/teardown/permitted IP connection" for permit ACEs and "Deny packet due to security policy" for deny ACEs.

•Keyword—ACL name and hashcode, if available, connected by the AND logical operator.

When you define the query criteria in the MARS GUI, the Query Criteria: Keywords page enables you to specify only up to 10 keywords to search within the raw message. Each keyword is associated with a distinct color to enable easy identification of its occurrence in the query results. When you perform events lookup from access rules in Security Manager, hashcode of the ACE, if available, is sent to MARS to be displayed in the query criteria as a keyword. Because Security Manager uses the hashcodes of the ACEs on devices that support them to uniquely query for syslogs generated by the ACE in MARS, large access rules might contain thousands of such hashcodes contained in them. When the number of hashcodes or keywords exceeds ten, the Keyword field in the MARS Query Criteria page is dimmed and coloring is available only for the first ten occurrences of keywords in the raw syslog message. If the number of keywords or the sum of the number of sources, destinations, and protocols for an ACE or a signature exceeds the permissible limit of 150, an error message is displayed in the MARS GUI. The error message displays the possible cause and recommended action.

For the device to generate log entries, you must configure individual access rules to generate log messages when they are invoked. If logging is not enabled on the device for an access rule, messages about packets permitted or denied by the access rule are not sent to the configured facility, such as a console. Access lists have an implicit deny at the end of the list, so unless you explicitly permit it, traffic cannot pass. The implicit deny at the end of the access list does not generate a syslog message. If you want all denied traffic to generate messages, you must add the implicit access rule manually to the end of the access list. To view syslogs associated with access rules for which logging is not enabled and connection-related syslogs, you can view syslogs matching a traffic flow. A flow is defined by the source and destination IP addresses, protocols, and ports. Because the source port might differ for a new connection between the same two hosts, you might not see the same flow increment because a new flow was created for the connection. When you perform a query from a firewall access rule policy in Security Manager matching a traffic flow, syslogs triggered by connection establishment and teardown are also displayed in addition to the ones generated by access rules in the Query page of MARS. The following are the fields that Security Manager provides to MARS to display events that match a traffic flow:

•Device details—General information about the device, such as hostname, domain name, management IP address, and display name.

•Source addresses—Source addresses of hosts and the network/host objects expanded to display the networks or collections of IP addresses.

•Destination addresses—Destination addresses of hosts and the network/host objects expanded to display the networks or collections of IP addresses.

•Service—Protocol and port information.

•Event Type—"Built/teardown/permitted IP connection" or "Deny packet due to security policy".

Related Topics

•Taskflow for MARS Events Query from Policy Table

•Understanding MARS Events Lookup

•Obtaining Events for a Signature Policy

•Guidelines for Working with MARS Events Lookup from Security Manager

•Checklist for Events Lookup from Security Manager

•Adding a MARS Appliance to Security Manager

•Navigating to MARS Events from an Access Rule Policy

Obtaining Events for a Signature Policy

For signatures configured on IPS and IOS IPS devices managed by Security Manager, you can navigate to the network intrusion events detected and reported by the devices in MARS. You can select one or more signature IDs at a time from the Signatures page in Security Manager and navigate to the Query page of MARS for running a query on historical and realtime events. Events of type Packet Data are not displayed in the Query page of MARS when you perform a lookup from a signature rule because these event types are not triggered by signature rules. The following are the fields populated in the query criteria of MARS, based on the information Security Manager provides from the signature settings:

•Device details—General information about the device, such as hostname, domain name, management IP address, and display name.

•Keyword—Signature ID, subsignature ID, and virtual sensor name, if applicable.

Related Topics

•Taskflow for MARS Events Query from Policy Table

•Understanding MARS Events Lookup

•Obtaining Events for an Access Rule Policy

•Guidelines for Working with MARS Events Lookup from Security Manager

•Checklist for Events Lookup from Security Manager

•Adding a MARS Appliance to Security Manager

•Navigating to MARS Events from an IPS Signature Policy

Guidelines for Working with MARS Events Lookup from Security Manager

Keep the following points in mind while querying for realtime or historical events in MARS from the Security Manager policy table:

•You need to use Security Manager 3.2 and MARS 4.3.4 or 5.3.4 to navigate to the events in MARS from the Security Manager policy table. You cannot add a MARS appliance running a version lower than 4.3.4 or 5.3.4 to Security Manager.

•If the initial configuration to enable the MARS Appliance communicate with other devices on the network and prepare it to monitor data from reporting devices is not completed, an error message is displayed.

•If the MARS appliance has been shut down or cannot be reached from the Security Manager server when you try to view events, an error message is displayed asking you to restore the connection between MARS and Security Manager.

•If the device for which you are viewing events from the Security Manager policy table is not added to MARS, an error message is displayed.

•You can add multiple MARS Local Controllers to a Security Manager server, although you cannot add more than one Security Manager server to a MARS Local Controller. You cannot add a MARS Global Controller to a Security Manager server.

•If HTTPS is not enabled on Security Manager for secure access between the Security Manager server and MARS, an error message is displayed when MARS communicates with Security Manager. Ensure HTTPS is enabled on the Security Manager server so that communication between the Security Manager and MARS is encrypted.

•For FWSM, PIX, and ASA devices in which multiple independent virtual firewall security contexts exist, you must define a unique management IP address in Security Manager for each security context to query MARS events. Also, the hostname and reporting IP address for each virtual context must be configured while adding it to MARS. Otherwise, events lookup from policies on these contexts fails.

•If you add an IPS device to Security Manager and deselect the IPS check box in the Create Discovery dialog box to exclude IPS policies on the device from being discovered, the icon next to the IPS policy reverts to an empty icon to show that the policy was unassigned from the device's configuration. For all IPS device and service policies, a default signature policy is assigned to the device when you remove the configured policies from the device. If you try to perform events lookup from the default signature, a "Policy not found" error message is displayed. However, if you edit the default signature and save it, the policy icon changes to show that a local policy is configured on the device and you can navigate to events in MARS.

•If object grouping or rule optimization is enabled for an access rule defined in Security Manager and the associated access-list commands on the device do not match with the optimized rules, no events are displayed in MARS because of the mismatch in access rule relationship between Security Manager and the device.

•If only one MARS appliance monitors a device and you do not associate the MARS appliance with the device that it monitors from the Device Properties page in Security Manager by discovering the MARS appliance, the MARS appliance is resolved to the device after you perform the events lookup for the first time.

•If more than one MARS device monitors the same device, you are prompted to select from the list of available MARS devices when you discover it from the Device properties page or when you perform the events lookup. An error message is displayed if MARS cannot be reached by Security Manager during discovery.

•If you delete a MARS appliance monitoring a device from the Security Manager database, it is also removed from the Monitored By field in the Device Properties page of that device.

•If a device is monitored by two MARS appliances and you later delete one of them from the Security Manager database, the device is automatically associated with the remaining MARS device. You do not have to manually discover the MARS appliance for that device.

•If a device is monitored by multiple MARS appliances and you select a MARS appliance when prompted during events lookup for access rule or signature, the same MARS appliance is reused to perform a lookup the next time for the same device.

•You must create the Security Manager user account in the MARS database if you select the option to use Security Manager credentials for Security Manager to authenticate with MARS for events lookup. Otherwise, an authorization error message is displayed.

•The MARS username and password values that you enter or modify in the New/Edit CS-MARS Device dialog box is used by Security Manager server to communicate with MARS and discover meta information, such as version of software running on the server and certificate details. These credentials are different from the username and password that you enter in the Login to CS-MARS ip_address dialog box.

The username and password pair in the Login to CS-MARS ip_address dialog box comprise the credentials that Security Manager uses to authenticate with MARS to look up events matching a policy rule, when you select the option to use MARS credentials during the addition of MARS to Security Manager. The MARS username and password values you enter in the events lookup login dialog box are saved in the Security Manager database until the client session times out, if you chose to allow saving of MARS login credentials during events lookup

•If you selected the option to be prompted for login credentials while Security Manager authenticates with MARS, you are also logged out from the Security Manager instance when the idle timeout period is exceeded for the MARS session.

•If you selected the option to use the MARS login credentials for Security Manager to authenticate with MARS and did not choose to allow the login credentials to be saved in the login dialog box, these credentials are cached until you exit Security Manager or the idle session timeout period is exceeded; you are not prompted for login details until the Security Manager session is active. If the MARS session times out after Security Manager has successfully authenticated with MARS and you selected the option to be prompted for login credentials for events lookup, the login dialog box is displayed when you query for events.

•If logging is not enabled for a permit ACE on ASA, PIX, and FWSM devices, or if logging is not enabled on IOS routers for ACEs, a warning message is displayed when you view events. To view syslogs associated with access rules for which logging is not enabled, you can perform a lookup for events matching a traffic flow.

•When you perform lookup for events matching an access rule, a warning message is displayed stating that most accurate matches might not be possible if overlapping access rules are present. This message is shown only for those devices that do not support hashcodes in syslogs and access rules.

•If an instance of MARS is already running, the existing browser window might be reused to display the Query page of MARS or a new window might be opened, depending on the way you set your browser to reuse windows. Setting your browser to reuse windows (such as selecting the Reuse Windows for Launching Shortcuts check box from Tools > Internet Options > Advanced in your Internet Explorer) replaces the content in your current window with whatever content is generated after events lookup.

The actual setting you configure to allow reuse of browser instances varies depending on which browser you use. See your browser documentation or help system for more information on this configuration.

Related Topics

•Taskflow for MARS Events Query from Policy Table

•Understanding MARS Events Lookup

•Obtaining Events for an Access Rule Policy

•Obtaining Events for a Signature Policy

•Checklist for Events Lookup from Security Manager

•Adding a MARS Appliance to Security Manager

•Navigating to MARS Events from an Access Rule Policy

•Navigating to MARS Events from an IPS Signature Policy

Checklist for Events Lookup from Security Manager

You can use the following checklist to track the tasks required to integrate MARS with a Security Manager server before you query for MARS events from the policy table. The checklist contains references to the specific procedures used to perform each task.

Step

Task

Step 1

Identify devices that need to be managed by both Security Manager and MARS.

The first step in integrating MARS and Security Manager involves identifying those devices that are monitored by MARS and for which Security Manager is used to define policy rules. You must ensure that these devices are running a software version supported by both MARS and Security Manager. For a list of devices supported by both Security Manager and MARS, see Devices and OS Versions Supported by Both Security Manager and MARS.

Step 2

Prepare the devices to be managed by Security Manager.

Before you can manage devices using Security Manager, you must set up the devices with a minimum configuration that provides basic connectivity. To enable communication between Security Manager and devices, you must configure transport settings on the devices, before you add them to the inventory. Bootstrapping involves getting the device up and running on the network, assigning it an IP address, and connecting it to the physical media. See the Chapter 5, "Preparing Devices for Management" topic for details about preparing or bootstrapping the devices.

Step 3

Add the devices to Security Manager.

After you identify and bootstrap the devices, you must represent those devices in the Security Manager inventory, which uses this information to communicate with the devices. When you add a device to Security Manager, you bring in a range of identifying information for the device, such as its DNS name and IP address. This information is added during device discovery. You can also bring existing network configurations associated with a device by initiating policy discovery. For more information, see the Chapter 6, "Managing the Device Inventory" topic.

Step 4

Discover the MARS appliance monitoring a device from the Security Manager UI.

You can discover the MARS appliance monitoring a device from the Device Properties page. If do not perform discovery before querying for MARS events from the policy table of that device and only one MARS appliance monitors the device, the Monitored By field in the Device Properties page is automatically populated with the IP address of the MARS appliance after the events lookup for the first time.

Note If more than more MARS appliance monitors a device, you are prompted to select a MARS device from a list of available choices when you perform the events lookup or discover the MARS device from the Device Properties page, whichever occurs first.

For more information, see Discovering or Changing the CS-MARS Server for a Device, page 6-27.

Step 5

Add one or more MARS Local Controllers to the Security Manager server.

For more information, see Configuring CS-MARS Servers, page 1-25.

Step 6

Bootstrap the devices monitored by MARS and add them to the MARS database.

For more information, see User Guide for Cisco Security MARS Local Controller 4.3.x and 5.3.x.

Step 7

Bootstrap the Security Manager server and add it to the correct MARS Local Controller.

For more information, see Bootstrapping Security Manager Server to Communicate with MARS.

Step 8

Perform event lookups as required.

From the access rule or signature policy table in your Security Manager client, you can right-click a rule or signature and perform a lookup operation for historical and realtime events in MARS. Based on the event details for the selected device, you can modify the policy in Security Manager and deploy to the device to fine-tune the response to network traffic. For more information on how to perform events table lookup for syslogs triggered by access rules and signatures, see the following sections:

•Navigating to MARS Events from an Access Rule Policy

•Navigating to MARS Events from an IPS Signature Policy

Related Topics

•Taskflow for MARS Events Query from Policy Table

•Understanding MARS Events Lookup

•Obtaining Events for an Access Rule Policy

•Obtaining Events for a Signature Policy

•Guidelines for Working with MARS Events Lookup from Security Manager

•Adding a MARS Appliance to Security Manager

•Navigating to MARS Events from an Access Rule Policy

•Navigating to MARS Events from an IPS Signature Policy

Adding a MARS Appliance to Security Manager

MARS must be registered with Security Manager and needs to be authenticated by Security Manager to perform a lookup for events it is monitoring. You can add only MARS Local Controllers to Security Manager and not Global Controllers. Also, you can add more than one MARS device to Security Manager and associate them with the devices they monitor. In addition, you can define the same Local Controller on multiple Security Manager servers.

The CS-MARS page enables you to configure MARS devices from which you can query events from the policy table in Security Manager. For more information on adding MARS to Security Manager, see Configuring CS-MARS Servers, page 1-25.

In the CS-MARS page, you can also configure the authentication mechanism to be used when Security Manager contacts MARS to query events. For more information, see About Authentication for Events Lookup from Security Manager.

Security Manager uses HTTPS to establish a secure communication with MARS. You must add a device to both the Security Manager inventory and MARS to perform events lookup. If the device is deleted from MARS but is still available in Security Manager, or if you did not activate the device to process the event data by MARS, the query for events cannot be run for that selected device.

Related Topics

•Understanding MARS Events Lookup

•Obtaining Events for an Access Rule Policy

•Obtaining Events for a Signature Policy

•Guidelines for Working with MARS Events Lookup from Security Manager

•Checklist for Events Lookup from Security Manager

•Navigating to MARS Events from an Access Rule Policy

•Navigating to MARS Events from an IPS Signature Policy

About Authentication for Events Lookup from Security Manager

You can enable Security Manager to either contact MARS using the credentials that you entered while logging in to Security Manager or use MARS credentials for Security Manager to authenticate with MARS. If you select the option to be prompted for MARS credentials when the event query lookup is performed, you can also choose to save the MARS credentials in the login dialog box to avoid being prompted everytime you look up MARS events in a new Security Manager client session or if the client session times out.

If you selected the option to use MARS login credentials for Security Manager to authenticate with MARS and did not choose to allow the login credentials to be saved in the login dialog box, these credentials are cached until you exit Security Manager or the idle session timeout period is exceeded. You are not prompted for login details until the Security Manager session is active. If the MARS session times out after Security Manager has successfully authenticated with MARS and did not select the option to save credentials, the login dialog box is displayed when you perform an events lookup from the policy table.

Related Topics

•Checklist for Events Lookup from Security Manager

•Adding a MARS Appliance to Security Manager

•Navigating to MARS Events from an Access Rule Policy

•Navigating to MARS Events from an IPS Signature Policy

Navigating to MARS Events from an Access Rule Policy

Access rules are recognized in the form of an ordered list, which is represented in Security Manager as a table. When a device decides whether to forward or drop a packet, the device tests the packet against each access rule in the order in which the entries are listed and performs the action based on the condition set in the access rule. When you configure a rule in the Access Rules table, you can enable logging for each access rule. MARS records the events generated by access rules on the devices that it monitors. For devices monitored by MARS and managed by Security Manager, you can query events in MARS from the policy table in Security Manager.

From the Access Rules page, you can select an ACE and navigate to the syslog or event generated by the ACE in MARS. You can also look up events associated with the connection establishment and teardown for an ACE. You can view events matching either a rule or a traffic flow for an ACE. Presence of MD5 hashcodes in an ACE determine the accuracy of lookup for events matching a rule. If logging is not enabled for an ACE on the device, such as denied traffic, you can view syslogs matching a traffic flow. When you perform a query for events matching a traffic flow, events triggered by access rules and connection setup/teardown are displayed. However, when you perform a query for events matching a rule, only events triggered by access rules and not connection setup/teardown are displayed. For more information, see Obtaining Events for an Access Rule Policy.

You can also look up historical and realtime events matching a source or destination address by right-clicking the Source or Destination table cell, then clicking one of the Show Events options from the shortcut menu.

When you lookup realtime events for an ACE, the query is automatically run based on the values passed by Security Manager to MARS and the results of the query are displayed in the realtime event viewer of MARS. You can modify the query parameters and resubmit the query as required. However, when you lookup historical events for an ACE, the values sent by Security Manager to MARS are used to only populate the query criteria and the Query Criteria: Result page is displayed in the MARS GUI. You need to either modify the query fields or retain the prepopulated values and run the query to view historical events matching the selected ACE.

This procedure describes how to look up realtime and historical events in MARS from an access rule in the policy table of Security Manager.

Before You Begin

•Make sure you have performed all the tasks in the Checklist for Events Lookup from Security Manager.

•Make sure that MARS can be reached from Security Manager.

Related Topics

•Taskflow for MARS Events Query from Policy Table

•Understanding MARS Events Lookup

•Obtaining Events for an Access Rule Policy

•Guidelines for Working with MARS Events Lookup from Security Manager

•Checklist for Events Lookup from Security Manager

•Adding a MARS Appliance to Security Manager

•Navigating to MARS Events from an Access Rule Policy

Step 1 Select a device from the Device selector.

Step 2 Select Firewall > Access Rules. The Access Rules page appears. For a description of the GUI elements, see Access Rules Page, page J-2.

Step 3 From the work area, right-click the appropriate rule number.

Step 4 Do one of the following from the shortcut menu:

•Select Show Events > Realtime > Matching Rule to navigate to the realtime query results page in MARS. If the selected device does not support hashcodes in ACEs, a warning dialog box is displayed that query results might be inaccurate if the selected ACE conflicts or overlaps with other ACEs. Click OK to run the query. Otherwise, click Cancel. Go to Step 7.

Note To prevent this warning message from appearing in the future for any device that does not support ACE hashcodes, select the Do not show this again check box before continuing.

The fields in the Query Event Data section of the realtime query results page are prepopulated for events matching this ACE. You can modify the parameters of the Query Event Data filter as you require and submit. Real-time results begin to scroll up from the bottom of the page within 5 seconds.

Note Security appliances running ASA or PIX 7.0 and later only support ACE hashcodes.

•Select Show Events > Realtime > Matching Flow to navigate to the realtime query results page in MARS for events matching this traffic flow. The Query Event Data filter in the Query Results page of the MARS GUI is prepopulated with the query criteria derived from the ACE and device details. You can use this option if logging is not enabled for ACEs on the device and you want to view sessionized events as they stream to MARS from recent past to the current time. Go to Step 7.

•Select Show Events > Historical > Matching Rule to navigate to the historical query criteria page in MARS with fields prepopulated, based on the ACE and device details. If the selected device does not support hashcodes in ACEs, a warning dialog box is displayed that query results might be inaccurate if the selected ACE conflicts or overlaps with other ACEs. Click OK to run the query. Otherwise, click Cancel. Go to Step 7.

•Select Show Events > Historical > Matching Flow to perform a lookup for historical events in MARS that match this traffic flow. You can use this option if logging is not enabled for ACEs on the device and you want to view events accumulated over a longer period of time than the realtime query. Go to Step 7.

Step 5 (Optional) To view realtime or historical events matching the source, right-click the Source table cell of a rule in the Access Rules table, then click one of the following:

•Select Show Events > Realtime > Matching Source to perform a lookup for realtime historical events triggered in MARS by the ACE that matches this source. Go to Step 7.

•Select Show Events > Historical > Matching Source to perform a lookup for realtime historical events triggered in MARS by the ACE that matches this source. Go to Step 7.

Step 6 (Optional) To view realtime or historical events matching the destination, right-click the Destination table cell of a rule in the Access Rules table, then click one of the following:

•Select Show Events > Realtime > Matching Destination to perform a lookup for realtime historical events triggered in MARS by the ACE that matches this destination. Go to Step 7.

•Select Show Events > Historical > Matching Destination to perform a lookup for realtime historical events triggered in MARS by the ACE that matches this destination. Go to Step 7.

Step 7 One of the following windows is displayed:

•If more than one MARS appliance monitors the device, the Finding CS-MARS Device for device_IP_address dialog box appears, displaying the progress of discovery. If the device cannot be reached, an error message is displayed. You can abort the discovery any time when it is in progress.

If more than MARS device monitoring the device can be reached by Security Manager, the Select CS-MARS dialog box is displayed, prompting you to select the MARS device to be used for events lookup.

If you selected the option to prompt for MARS credentials during events lookup and these credentials are either not cached in the current Security Manager client session or saved in the MARS database, the Login to CS-MARS ip_address dialog box is displayed. Go to Step 8. Otherwise, the MARS Query Criteria: Result Page is displayed with the query fields prepopulated for historical events and the Query Results page is displayed with the results of the query for realtime events.

•If the device has already been associated with a MARS device from the Device Properties page or if only one MARS device monitors the device, the Login to CS-MARS ip_address dialog box is displayed if one of the following is true:

–You selected the option to prompt for MARS credentials during events lookup, and are performing events lookup for the first time in this Security Manager client session.

–You did not select the check box to save credentials when prompted for MARS login details in an earlier Security Manager client session.

Go to Step 8.

•If you selected the option to use Security Manager credentials to perform events lookup, the MARS Query Criteria: Result Page is displayed with the query fields prepopulated for historical events or the Query Results page is displayed with the results of the query for realtime events.

Note If an instance of MARS is running, the same instance is reused for the events lookup. If the MARS session has timed out or is not open, a new client session is started.

•Enter the MARS login credentials and click OK. For details, see Login to CS-MARS ip_address Dialog Box.

The MARS Query Criteria: Result or the Query Results page is displayed, depending on whether you are querying for historical or realtime events, with the query fields prepopulated using the ACE and device details. You can run or edit the query and save it as a report if you want to run it at regular intervals.

Step 8 Enter the MARS login credentials and click OK. For details, see Login to CS-MARS ip_address Dialog Box.

Note This dialog box is not displayed if you chose to use Security Manager credentials for logging in to MARS, or selected the check box to save MARS credentials when you performed the events lookup earlier.

Note The first time you navigate to events in MARS, a Security Alert dialog box is displayed if the SSL certificate of MARS is not saved in the trusted folder of the browser. Click Yes to choose to trust the certificate for the current session.

Note For historical events, the Result Format drop-down list is populated with the All Matching Events option and the Filter By Time value is set to the last 10 minutes by default.

On devices running ASA and PIX 7.0 and later that support hashcodes, the Keyword field in the Query Criteria: Result page is dimmed if there are more than ten keywords in the query parameters returned from Security Manager. Also, color-coding is available only for the first ten occurrences of the keywords in the raw message returned after you run the query; the remaining keyword occurrences are not colored.

Navigating to MARS Events from an IPS Signature Policy

From the Signatures policy page in Security Manager, you can select one or more signature IDs to run a historical or realtime event query in MARS. When an IPS or IOS IPS device detects and reports a network intrusion by comparing the configured signature against incoming traffic, a syslog is generated on the device and transmitted to MARS. An incident is generated in MARS after the log associated with the signature is obtained from the device. Looking up the events associated with a signature ID enables you to quickly identify attacks and tune your device configuration to minimize or prevent intrusions.

For virtual sensors, the name of the sensor is also prepopulated in the Keyword column of the query criteria page in MARS along with other parameters derived from the signature and device information. If you query events for a signature for which no events were generated in MARS, an empty page is displayed when you run the query.

When you lookup realtime events for a signature, the query is automatically run based on the values passed by Security Manager to MARS and the results of the query are displayed in the realtime event viewer of MARS. However, when you lookup historical events for a signature, the values sent by Security Manager to MARS are used to only populate the query criteria. You need to either modify the query fields or retain the prepopulated values and run the query to view historical events matching the selected signature.

This procedure describes how to look up realtime and historical events in MARS from a signature rule in the policy table of Security Manager.

Before You Begin

•Make sure you have performed all the tasks in the Checklist for Events Lookup from Security Manager.

•Make sure that MARS can be reached from Security Manager.

Related Topics

•Taskflow for MARS Events Query from Policy Table

•Understanding MARS Events Lookup

•Obtaining Events for a Signature Policy

•Guidelines for Working with MARS Events Lookup from Security Manager

•Checklist for Events Lookup from Security Manager

•Adding a MARS Appliance to Security Manager

•Navigating to MARS Events from an IPS Signature Policy

•Login to CS-MARS ip_address Dialog Box

Step 1 In Device view, select an IPS or IOS IPS device from the Device selector.

Step 2 Also in Device view, select IPS > Signatures > Signatures.

The Signatures page is displayed.

Step 3 In the summary table on the Signatures page, find the signature whose events you want to view and right-click its row in the work area. The shortcut menu appears.

Note You can also select multiple signatures at a time and view events generated by them.

Step 4 Do one of the following from the shortcut menu:

•Select Show Events > Realtime to navigate to the realtime query results page in MARS with fields prepopulated for events matching this signature rule. You can use this option if you want to view raw events as they stream to MARS from recent past to current time. Go to Step 5.

The fields in the Query Event Data section of the realtime query results page are prepopulated for events matching this signature. You can modify the parameters of the Query Event Data filter as you require and submit. Real-time results begin to scroll up from the bottom of the page within 5 seconds.

•Select Show Events > Historical to perform a lookup for historical events in MARS that match this traffic flow. You can use this option if you want to view events accumulated over a longer period of time than the realtime query. Go to Step 5.

Note If you right-click a signature that is disabled in the signature summary page and try to navigate to realtime or historical events in MARS, a warning message is displayed asking you to confirm whether you want to proceed with the events lookup. Click Yes to continue. To prevent this warning message from appearing in the future for any device, select the Do not show this again check box before continuing.

Step 5 One of the following windows is displayed:

•