USM Anywhere™

Cisco ASA

When you configure Cisco ASA to send log data to USM Anywhere, you can use the Cisco ASA plugin to translate raw log data into normalized events for analysis. The table below provides some basic information for the plugin:

Plugin Information
Device Details
Vendor Cisco
Device Type UTM
Connection Type Syslog

Integrating Cisco ASA

Before you configure the Cisco ASA integration, you must have the IP Address of the USM Anywhere Sensor and the Cisco Adaptive Security Device Manager (ASDM).

To configure Cisco ASA to send log data to USM Anywhere

  1. Connect to the ASA box, using ASDM.
  2. Go to Configuration > Device Management > Logging > Syslog Servers and click Add to add a syslog server.

    Note: Make sure you have connectivity between Cisco ASA and the USM Anywhere Sensor.

  3. In the Add Syslog Server dialog, specify the following:

    1. Interface associated with the server
    2. USM Anywhere Sensor IP address
    3. Protocol (TCP or UDP)
    4. Port number, 601 for TCP and 514 for UDP. See the Syslog Server Sensor App in USM Anywhere for more details.
    5. Click OK

    The new syslog server appears.

  4. In Queue Size, specify the number of messages allowed to be queued when the syslog server is busy. 0 means unlimited queue size.
  5. If the transport protocol between Cisco ASA and the syslog server is TCP, select Allow user traffic to pass when TCP Syslog server is down . Otherwise, Cisco ASA denies any new network access sessions.
  6. Click Apply.

To configure syslog on Cisco ASA

The header fields in the syslog messages sent by Cisco ASA include some important information needed by USM Anywhere to parse the messages correctly.

To make sure that the logging is enabled for USM Anywhere, use the command

ciscoasa(config)# logging enable

You also need to enable timestamp and hostname logging in the messages

ciscoasa(config)# logging timestamp

ciscoasa(config)# logging device-id hostname

For further asistance on Cisco ASA logging, please consult vendor documentation.

Setting the Syslog Logging Level for Cisco Devices

All Cisco devices that support syslog collection and output of system messages typically let you set a logging level which determines the type and severity of the messages that are sent to a syslog host such as USM Anywhere for processing and analysis. The following table describes the broad classification of each of these logging levels.

Logging Level Keyword/Severity Level Description
0 emergency System is unusable. Typically devices do not generate sylog messages with a severity/logging level of 0.
1 alert Immediate action is needed. These messages indicate that action has been taken by the security appliance to resolve a problem or that action needs to be taken by the administrator because of an interface failure, unit standby failure, or bad cables. An administrator should always follow up on an alert message.
2 critical Critical condition requiring immediate attention. These messages indicate that traffic has been blocked or dropped, that spoofed traffic has been detected, or that flags are invalid in traffic. An administrator should usually follow up on critical messages.
3 error Error condition or event. These error messages are specific to security appliance resources such as xlate failures and translation slot failures. An administrator should always follow up on error messages.
4 warning Warning condition or event. These messages are generally warnings about connection problems. An administrator might have to follow up on these warning messages.
5 notification Normal but significant conditions or events. These messages are a mix of notifications of what a security appliance logged-in user is doing on the machine and some messages about Java and ActiveX blocking. An administrator should look at these messages to ensure that unauthorized changes are not being made to the security appliance.
6 informational Informational messages only. These messages describe connections being built and torn down through the security appliance. In most cases, these messages don't need to be audited by an administrator unless users report that they are having problems with specific connections or services.
7 debugging Debugging messages only. These messages are mostly related to IPSec. An administrator uses these messages when bringing up an IPSec tunnel for the first time. For the other debug messages, refer to your device's technical documentation on the Cisco website.

When you set a logging level, all messages with the same classification number (and lower) are output to the syslog server that collect these messages. In addition, with many of these devices, you can also limit the rate or amount of syslog message volume that is output.

Note: Refer to the vendor documentation provided for your specific device, on the logging commands that are available, and how to use them to control Syslog message output.

By default, most Cisco devices are configured at notification (5) or informational (6) levels for syslog messages directed to USM Anywhere. (Logging level 7 is not recommended for syslog message output.) However, you may want to monitor the volume of messages that you are receiving from any particular device, particularly if the logging level is set at informational (6), because storage space can become an issue. You can also determine whether collecting any informational messages contributes significantly to your security monitoring efforts, or is just creating a lot of "noise".

Plugin Enablement

The Cisco ASA plugin automatically processes all messages when the raw message contains "(?:%ASA|%asa)(?:-\\w+)?-\\d-\\d{6}:".

Available Plugin Fields

The following plugin fields are important attributes extracted from the syslog message. The USM Anywhere reports use these fields, and you can also reference them when creating custom reports. In addition to reporting, the USM Anywhere correlation rules make use of these fields.

  • app_name
  • audit_reason
  • customfield_0
  • customfield_1
  • destination_address
  • destination_nat_address
  • destination_nat_port
  • destination_port
  • email_sender
  • event_category
  • event_name
  • event_severity
  • event_subcategory
  • rep_device_inbound_interface
  • rep_device_outbound_interface
  • rep_device_rule_id
  • request_url
  • security_group_name
  • source_address
  • source_mac
  • source_nat_address
  • source_nat_port
  • source_port
  • source_process_commandline
  • source_username
  • transport_protocol


For troubleshooting, refer to the vendor documentation: