Event Analysis Using External Tools

Integrate with Cisco SecureX

View and work with data from all of your Cisco security products and more through a single pane of glass, the SecureX cloud portal. Use the tools available via SecureX to enrich your threat hunts and investigations. SecureX can also provide useful appliance and device information such as whether each is running an optimal software version.

For more information about SecureX, see http://www.cisco.com/c/en/us/products/security/securex.html.

To integrate Firepower with SecureX, see the Firepower and SecureX Integration Guide at https://cisco.com/go/firepower-securex-documentation.

Event Analysis with Cisco SecureX threat response

Cisco SecureX threat response was formerly known as Cisco Threat Response (CTR.)

Rapidly detect, investigate, and respond to threats using Cisco SecureX threat response, the integration platform in the Cisco Cloud that lets you analyze incidents using data aggregated from multiple products, including Firepower.

View Event Data in Cisco SecureX threat response

Before you begin

Procedure

Step 1

In Firepower Management Center, do one of the following:

  • To pivot to Cisco SecureX threat response from a specific event:

    a. Navigate to a page under the Analysis > Intrusions menu that lists a supported event.

    b. Right-click a source or destination IP address and select View in Threat Response.

  • To view event info generally:

    a. Navigate to System > Integrations > Cloud Services.

    b. Click the link to view events in Cisco SecureX threat response.

Step 2

Sign in to Cisco SecureX threat response as prompted.

Event Investigation Using Web-Based Resources

Use the contextual cross-launch feature to quickly find more information about potential threats in web-based resources outside of the Firepower Management Center. For example, you might:

  • Look up a suspicious source IP address in a Cisco or third-party cloud-hosted service that publishes information about known and suspected threats, or

  • Look for past instances of a particular threat in your organization's historical logs, if your organization stores that data in a Security Information and Event Management (SIEM) application.

  • Look for information about a particular file, including file trajectory information, if your organization has deployed Cisco AMP for Endpoints.

When investigating an event, you can click directly from an event in the event viewer or dashboard in the Firepower Management Center to the relevant information in the external resource. This lets you quickly gather context around a specific event based on its IP addresses, ports, protocol, domain, and/or SHA 256 hash.

For example, suppose you are looking at the Top Attackers dashboard widget and you want to find out more information about one of the source IP addresses listed. You want to see what information Talos publishes about this IP address, so you choose the "Talos IP" resource. The Talos web site opens to a page with information about this specific IP address.

You can choose from a set of pre-defined links to commonly used Cisco and third-party threat intelligence services, and add custom links to other web-based services, and to SIEMs or other products that have a web interface. Note that some resources may require an account or a product purchase.

About Managing Contextual Cross-Launch Resources

Manage external web-based resources using the Analysis > Advanced > Contextual Cross-Launch page.

Pre-defined resources offered by Cisco are marked with the Cisco logo. The remaining links are third-party resources.

You can disable or delete any resources that you do not need, or you can rename them, for example by prefixing a name with a lower-case "z" so the resource sorts to the bottom of the list. Disabling a cross-launch resource disables it for all users. You cannot reinstate deleted resources, but you can re-create them.

To add a resource, see Add Contextual Cross-Launch Resources.

Requirements for Custom Contextual Cross-Launch Resources

When adding custom contextual cross-launch resources:

  • Resources must be accessible via web browser.

  • Only http and https protocols are supported.

  • Only GET requests are supported; POST requests are not.

  • Encoding of variables in URLs is not supported. While IPv6 addresses may require colon separators to be encoded, most services do not require this encoding.

  • Up to 100 resources can be configured, including pre-defined resources.

  • You must be an Admin or Security Analyst user to create a cross launch, but you can also be a read-only Security Analyst to use them.

Add Contextual Cross-Launch Resources

You can add contextual cross-launch resources such as threat intelligence services and Security Information and Event Management (SIEM) tools.

In multidomain deployments, you can see and use resources in parent domains, but you can only create and edit resources in the current domain. The total number of resources across all domains is limited to 100.

Before you begin

  • See Requirements for Custom Contextual Cross-Launch Resources.

  • If needed for the resource you will link to, create or obtain an account and the credentials needed for access. Optionally, assign and distribute credentials for each user who needs access.

  • Determine the syntax of the query link for the resource that you will link to:

    Access the resource via browser and, using the documentation for that resource as needed, formulate the query link needed to search for a specific sample of the type of information you want your query link to find, such as an IP address.

    Run the query, then copy the resulting URL from the browser's location bar.

    For example, you might have the query URL https://www.talosintelligence.com/reputation_center/lookup?search=10.10.10.10.

Procedure

Step 1

Choose Analysis > Advanced > Contextual Cross-Launch.

Step 2

Click New Cross-Launch.

In the form that appears, all fields marked with an asterisk require a value.

Step 3

Enter a unique resource name.

Step 4

Paste the working URL string from your resource into the URL Template field.

Step 5

Replace the specific data (such as an IP address) in the query string with an appropriate variable: Position your cursor, then click a variable (for example, ip) once to insert the variable.

In the example from the "Before You Begin" section above, the resulting URL might be https://www.talosintelligence.com/reputation_center/lookup?search={ip}. When the contextual cross-launch link is used, the {ip} variable in the URL will be replaced by the IP address that the user right-clicks on in the event viewer or dashboard.

For a description of each variable, hover over the variable.

You can create multiple contextual cross-launch links for a single tool or service, using different variables for each.

Step 6

Click Test with example data (test with example data icon) to test your link with example data.

Step 7

Fix any problems.

Step 8

Click Save.

Investigate Events Using Contextual Cross-Launch

Before you begin

If the resource you will access requires credentials, make sure you have those credentials.

Procedure

Step 1

Navigate to one of the following pages in the Firepower Management Center that shows events:

  • A dashboard (Overview > Dashboards), or

  • An event viewer page (any menu option under the Analysis menu that includes a table of events.)

Step 2

Right-click the event of interest and choose the contextual cross-launch resource to use.

If necessary, scroll down in the context menu to see all available options.

The data type you right-click on determines the options you see; for example, if you right-click an IP address, you will only see contextual cross-launch options that are relevant to IP addresses.

So, for example, to get threat intelligence from Cisco Talos about a source IP address in the Top Attackers dashboard widget, choose Talos SrcIP or Talos IP.

If a resource includes multiple variables, the option to choose that resource is available only for events that have a single possible value for each included variable.

The contextual cross-launch resource opens in a separate browser window.

It may take some time for the query to be processed, depending on the amount of data to be queried, speed of and demand on the resource, and so on.

Step 3

Sign in to the resource if necessary.

About Sending Syslog Messages for Security Events

You can send data related to connection, security intelligence, intrusion, and file and malware events via syslog to a Security Information and Event Management (SIEM) tool or another external event storage and management solution.

These events are also sometimes referred to as Snort® events.

About Configuring the System to Send Security Event Data to Syslog

In order to configure the system to send security event syslogs, you will need to know the following:

Best Practices for Configuring Security Event Syslog Messaging

Device and Version

Configuration Location

All

If you will use syslog or store events externally, avoid special characters in object names such as policy and rule names. Object names should not contain special characters, such as commas, that the receiving application may use as separators.

Firepower Threat Defense version 6.3 or later

  1. Configure FTD platform settings (Devices > Platform Settings > Threat Defense Settings > Syslog.)

    See also FTD Platform Settings That Apply to Security Event Syslog Messages.

  2. In your access control policy Logging tab, opt to use the FTD platform settings.

  3. (For intrusion events) Configure intrusion policies to use the settings in your access control policy Logging tab. (This is the default.)

Overriding any of these settings is not recommended.

For essential details, see Send Security Event Syslog Messages from FTD Devices.

All other devices

  1. Create an alert response.

  2. Configure access control policy Logging to use the alert response.

  3. (For intrusion events) Configure syslog settings in intrusion policies.

For complete details, see Send Security Event Syslog Messages from Classic Devices.

Send Security Event Syslog Messages from FTD Devices

This procedure documents the best practice configuration for sending syslog messages for security events (connection, Security-related connection, intrusion, file, and malware events) from Firepower Threat Defense devices.


Note

Many Firepower Threat Defense syslog settings are not applicable to security events. Configure only the options described in this procedure.

Before you begin

  • In FMC, configure policies to generate security events and verify that the events you expect to see appear in the applicable tables under the Analysis menu.

  • Gather the syslog server IP address, port, and protocol (UDP or TCP):

  • Ensure that your devices can reach the syslog server(s).

  • Confirm that the syslog server(s) can accept remote messages.

  • For important information about connection logging, see the chapter on Connection Logging.

Procedure

Step 1

Configure syslog settings for your Firepower Threat Defense device:

  1. Click Devices > Platform Settings.

  2. Edit the platform settings policy associated with your Firepower Threat Defense device.

  3. In the left navigation pane, click Syslog.

  4. Click Syslog Servers and click Add to enter server, protocol, interface, and related information.

    If you have questions about options on this page, see Configure a Syslog Server.

  5. Click Syslog Settings and configure the following settings:

    • Enable Timestamp on Syslog Messages

    • Timestamp Format

    • Enable Syslog Device ID

  6. Click Logging Setup.

  7. Select whether or not to Send syslogs in EMBLEM format.

  8. Save your settings.

Step 2

Configure general logging settings for the access control policy (including file and malware logging):

  1. Click Policies > Access Control.

  2. Edit the applicable access control policy.

  3. Click Logging.

  4. Select FTD 6.3 and later: Use the syslog settings configured in the FTD Platform Settings policy deployed on the device.

  5. (Optional) Select a Syslog Severity.

  6. If you will send file and malware events, select Send Syslog messages for File and Malware events.

  7. Click Save.

Step 3

Enable logging for Security-related connection events for the access control policy:

  1. In the same access control policy, click the Security Intelligence tab.

  2. In each of the following locations, click Logging (logging icon) and enable beginning and end of connections and Syslog Server:

    • Beside DNS Policy.

    • In the Block List box, for Networks and for URLs.

  3. Click Save.

Step 4

Enable syslog logging for each rule in the access control policy:

  1. In the same access control policy, click the Rules tab.

  2. Click a rule to edit.

  3. Click the Logging tab in the rule.

  4. Choose whether to log the beginning or end of connections, or both.

    (Connection logging generates a lot of data; logging both beginning and end generates roughly double that much data. Not every connection can be logged both at beginning and end.)

  5. If you will log file events, select Log Files.

  6. Enable Syslog Server.

  7. Verify that the rule is "Using default syslog configuration in Access Control Logging."

  8. Click Add.

  9. Repeat for each rule in the policy.

Step 5

If you will send intrusion events:

  1. Navigate to the intrusion policy associated with your access control policy.

  2. In your intrusion policy, click Advanced Settings > Syslog Alerting > Enabled.

  3. If necessary, click Edit

  4. Enter options:

    Option

    Value

    Logging Host

    Unless you will send intrusion event syslog messages to a different syslog server than you will send other syslog messages, leave this blank to use the settings you have configured above.

    Facility

    This setting is applicable only if you specify a Logging Host on this page.

    For descriptions, see Syslog Alert Facilities.

    Severity

    This setting is applicable only if you specify a Logging Host on this page.

    For descriptions, see Syslog Severity Levels.

  5. Click Back.

  6. Click Policy Information in the left navigation pane.

  7. Click Commit Changes.

What to do next

Send Security Event Syslog Messages from Classic Devices

Before you begin

  • Configure policies to generate security events.

  • Ensure that your devices can reach the syslog server(s).

  • Confirm that the syslog server(s) can accept remote messages.

  • For important information about connection logging, see the chapter on Connection Logging.

Procedure

Step 1

Configure an alert response for your Classic devices:

See Creating a Syslog Alert Response.

Step 2

Configure syslog settings in the access control policy:

  1. Click Policies > Access Control.

  2. Edit the applicable access control policy.

  3. Click Logging.

  4. Select Send using specific syslog alert.

  5. Select the Syslog Alert you created above.

  6. Click Save.

Step 3

If you will send file and malware events:

  1. Select Send Syslog messages for File and Malware events.

  2. Click Save.

Step 4

If you will send intrusion events:

  1. Navigate to the intrusion policy associated with your access control policy.

  2. In your intrusion policy, click Advanced Settings > Syslog Alerting > Enabled.

  3. If necessary, click Edit

  4. Enter options:

    Option

    Value

    Logging Host

    Unless you will send intrusion event syslog messages to a different syslog server than you will send other syslog messages, leave this blank to use the settings you have configured above.

    Facility

    This setting is applicable only if you specify a Logging Host on this page.

    See Syslog Alert Facilities.

    Severity

    This setting is applicable only if you specify a Logging Host on this page.

    See Syslog Severity Levels.

  5. Click Back.

  6. Click Policy Information in the left navigation pane.

  7. Click Commit Changes.

What to do next

Configuration Locations for Security Event Syslogs

Configuration Locations for Syslogs for Connection and Security Intelligence Events (All Devices)

There are many places to configure logging settings. Use the table below to ensure that you set the options you need.


Important

  • Pay careful attention when configuring syslog settings, especially when using inherited defaults from other configurations. Some options may NOT be available to all managed device models and software versions, as noted in the table below.

  • For important information when configuring connection logging, see the chapter on Connection Logging.

Configuration Location

Description and More Information

Devices > Platform Settings, Threat Defense Settings policy, Syslog

This option applies only to Firepower Threat Defense devices running version 6.3 or later.

Settings you configure here can be specified in the Logging settings for an Access Control policy and then used or overridden in the remaining policies and rules in this table.

See FTD Platform Settings That Apply to Security Event Syslog Messages and About Syslog and subtopics.

Policies > Access Control, <each policy>, Logging

Settings you configure here are the default settings for syslogs for all connection and security intelligence events, unless you override the defaults in descendant policies and rules at the locations specified in the remaining rows of this table.

Recommended setting for FTD devices running 6.3 or later: Use FTD Platform Settings. For information, see FTD Platform Settings That Apply to Security Event Syslog Messages and About Syslog and subtopics.

Required setting for all other devices: Use a syslog alert.

If you specify a syslog alert, see Creating a Syslog Alert Response.

For more information about the settings on the Logging tab, see Logging Settings for Access Control Policies.

Policies > Access Control, <each policy>, Rules, Default Action row, Logging (logging icon)

Logging settings for the default action associated with an access control policy.

See information about logging in the Access Control Rules chapter and Logging Connections with a Policy Default Action.

Policies > Access Control, <each policy>, Rules, <each rule>, Logging

Logging settings for a particular rule in an access control policy.

See information about logging in the Access Control Rules chapter.

Policies > Access Control, <each policy>, Security Intelligence, Logging (logging icon)

Logging settings for Security Intelligence Block lists.

Click these buttons to configure:

  • DNS Block List Logging Options

  • URL Block List Logging Options

  • Network Block List Logging Options (for IP addresses on the blocked list)

See Configure Security Intelligence, including the prerequisites section, and subtopics and links.

Policies > SSL, <each policy>, Default Action row, Logging (logging icon)

Logging settings for the default action associated with an SSL policy.

See Logging Connections with a Policy Default Action.

Policies > SSL, <each policy>, <each rule>, Logging

Logging settings for SSL rules.

See TLS/SSL Rule Components.

Policies > Prefilter, <each policy>, Default Action row, Logging (logging icon)

Logging settings for the default action associated with a prefilter policy.

See Logging Connections with a Policy Default Action.

Policies > Prefilter, <each policy>, <each prefilter rule>, Logging

Logging settings for each prefilter rule in a prefilter policy.

See Tunnel and Prefilter Rule Components

Policies > Prefilter, <each policy>, <each tunnel rule> , Logging

Logging settings for each tunnel rule in a prefilter policy.

See Tunnel and Prefilter Rule Components

Additional syslog settings for FTD cluster configurations:

The Clustering for the Firepower Threat Defense chapter has multiple references to syslog; search the chapter for "syslog."

Configuration Locations for Syslogs for Intrusion Events (FTD Devices Version 6.3+)

You can specify syslog settings for intrusion policies in various places and, optionally, inherit settings from the access control policy or the FTD Platform Settings or both.

Configuration Location

Description and More Information

Devices > Platform Settings, Threat Defense Settings policy, Syslog

Syslog destinations that you configure here can be specified in the Logging tab of an access control policy which can be the default for an intrusion policy.

See FTD Platform Settings That Apply to Security Event Syslog Messages and About Syslog and subtopics.

Policies > Access Control, <each policy>, Logging

Default setting for syslog destination for intrusion events, if the intrusion policy does not specify other logging hosts.

See Logging Settings for Access Control Policies.

Policies > Intrusion, <each policy>, Advanced Settings, enable Syslog Alerting, click Edit

To specify syslog collectors other than the destinations specified in the access control policy Logging tab, and to specify facility and severity, see Configuring Syslog Alerting for Intrusion Events.

If you want to use the Severity or Facility or both as configured in the intrusion policy, you must also configure the logging hosts in the policy. If you use the logging hosts specified in the access control policy, the severity and facility specified in the intrusion policy will not be used.

Configuration Locations for Syslogs for Intrusion Events (Devices Other than FTD and Versions Earlier than 6.3)

By default, the intrusion policy uses the settings in the Logging tab of the access control policy. If settings applicable to devices other than FTD 6.3 are not configured there, syslogs will not be sent for devices other than FTD 6.3 and no warning appears.

Configuration Locations for Syslogs for File and Malware Events

Configuration Location

Description and More Information

In an access control policy:

Policies > Access Control, <each policy>, Logging

This is the main location for configuring the system to send syslogs for file and malware events.

If you do not use the syslog settings in FTD Platform Settings, you must also create an alert response. See Creating a Syslog Alert Response.

In Firepower Threat Defense Platform Settings:

Devices > Platform Settings, Threat Defense Settings policy, Syslog

These settings apply only to Firepower Threat Defense devices running supported versions, and only if you configure the Logging tab in the access control policy to use FTD platform settings.

See FTD Platform Settings That Apply to Security Event Syslog Messages and About Syslog and subtopics.

In an access control rule:

Policies > Access Control, <each policy>, <each rule>, Logging

If you do not use the syslog settings in FTD Platform Settings, you must also create an alert response. See Creating a Syslog Alert Response.

Anatomy of Security Event Syslog Messages

Example security event message from FTD 6.3 and later (Intrusion Event)

Table 1. Components of Security Event Syslog Messages

Item Number in Sample Message

Header Element

Description

0

 PRI The priority value that represents both Facility and Severity of the alert. The value appears in the syslog messages only when you enable logging in EMBLEM format using FMC platform settings. If you enable logging of intrusion events through access control policy Logging tab, the PRI value is automatically displayed in the syslog messages. For information on how to enable the EMBLEM format, see Enable Logging and Configure Basic Settings. For information on PRI, see RFC5424.

1

Timestamp

Date and time the syslog message was sent from the device.

  • (Syslogs sent from FTD devices running version 6.3 or later) For syslogs sent using settings in the access control policy and its descendants, or if specified to use this format in the FTD Platform Settings, the date format is the format defined in the ISO 8601 timestamp format as specified in RFC 5424 (yyyy-MM-ddTHH:mm:ssZ), where the letter Z indicates the UTC time zone.

  • (Syslogs sent from all other devices running version 6.3 or later) For syslogs sent using settings in the access control policy and its descendants, the date format is the format defined in the ISO 8601 timestamp format as specified in RFC 5424 (yyyy-MM-ddTHH:mm:ssZ), where the letter Z indicates the UTC time zone.

  • Otherwise, it is the month, day, and time in UTC time zone, though the time zone is not indicated.

To configure the timestamp setting in FTD Platform Settings, see Configure Syslog Settings.

2

Device or interface from which the message was sent.

This can be:

  • IP address of the interface

  • Device hostname

  • Custom device identifier

(For syslogs sent from FTD devices version 6.3 and later only)

If the syslog message was sent using the FTD Platform Settings, this is the value configured in Syslog Settings for the Enable Syslog Device ID option, if specified.

Otherwise, this element is not present in the header.

To configure this setting in FTD Platform Settings, see Configure Syslog Settings.

3

Custom value

If the message was sent using an alert response, this is the Tag value configured in the alert response that sent the message, if configured. (See Creating a Syslog Alert Response.)

Otherwise, this element is not present in the header.

4

%FTD

%NGIPS

Type of device that sent the message.

  • %FTD is Firepower Threat Defense running version 6.3 or later

  • %NGIPS is all other devices running version 6.3 or later

  • For messages sent from devices running version 6.2.3 or earlier, this element is not present.

5

Severity

The severity specified in the syslog settings for the policy that triggered the message.

For severity descriptions, see Severity Levels or Syslog Severity Levels.

6

Event type identifier

For messages sent from devices running version 6.3 or later:

  • 430001: Intrusion event

  • 430002: Connection event logged at beginning of connection

  • 430003: Connection event logged at end of connection

For messages sent from devices running version 6.4 or later, the following event type IDs are also used:

  • 430004: File event

  • 430005: File malware event

For messages sent from devices running version 6.2.3 or earlier, an event type identifier is not present.

--

Facility

See Facility in Security Event Syslog Messages.

--

Remainder of message

Fields and values separated by colons.

Fields with empty or unknown values are omitted from messages.

For field descriptions, see:

Note

 

Field description lists include both syslog fields and fields visible in the event viewer (menu options under the Analysis menu in the Firepower Management Center web interface.) Fields available via syslog are labeled as such.

Some fields visible in the event viewer are not available via syslog. Also, some syslog fields are not included in the event viewer (but may be available via search), and some fields are combined or separated.

Facility in Security Event Syslog Messages

Facility values are not generally relevant in syslog messages for security events. However, if you require Facility, use the following table:

Device

To Include Facility in Connection Events

To Include Facility in Intrusion Events

Location in Syslog Message

FTD 6.3 and later

Use the EMBLEM option in FTD Platform Settings.

Facility is always ALERT for connection events when sending syslog messages using FTD Platform Settings.

Use the EMBLEM option in FTD Platform Settings or configure logging using the syslog settings in the intrusion policy. If you use the intrusion policy, you must also specify the logging host in the intrusion policy settings.

Enable syslog alerting and configure facility and severity on the intrusion policy. See Configuring Syslog Alerting for Intrusion Events.

Facility does not appear in the message header, but the syslog collector can derive the value based on RFC 5424, section 6.2.1.

Pre-6.3 FTD

Use an alert response.

Use the syslog setting in the intrusion policy advanced settings or an alert response identified in the access control policy Logging tab.

Devices other than FTD

Use an alert response.

Use the syslog setting in the intrusion policy advanced settings or an alert response identified in the access control policy Logging tab.

For more information, see Facilities and Severities for Intrusion Syslog Alerts and Creating a Syslog Alert Response.

Firepower Syslog Message Types

Firepower can send multiple syslog data types, as described in the following table:

Syslog Data Type

See

Audit logs from FMC

Stream Audit Logs to Syslog and the Auditing the System chapter

Audit logs from Classic devices (ASA FirePOWER, NGIPSv)

Stream Audit Logs from Classic Devices and the Auditing the System chapter

CLI command: syslog

Device health and network-related logs from FTD devices

About Syslog and subtopics

Connection, security intelligence, and intrusion event logs from FTD devices

About Configuring the System to Send Security Event Data to Syslog.

Connection, security intelligence, and intrusion event logs from Classic devices

 About Configuring the System to Send Security Event Data to Syslog

Logs for file and malware events

About Configuring the System to Send Security Event Data to Syslog

Limitations of Syslog for Security Events

  • If you will use syslog or store events externally, avoid special characters in object names such as policy and rule names. Object names should not contain special characters, such as commas, that the receiving application may use as separators.

  • It may take up to 15 minutes for events to appear on your syslog collector.

  • Data for the following file and malware events is not available via syslog:

    • Retrospective events

    • Events generated by AMP for Endpoints

eStreamer Server Streaming

The Event Streamer (eStreamer) allows you to stream several kinds of event data from a Firepower Management Center to a custom-developed client application. For more information, see Firepower System Event Streamer Integration Guide.

Before the appliance you want to use as an eStreamer server can begin streaming eStreamer events to an external client, you must configure the eStreamer server to send events to clients, provide information about the client, and generate a set of authentication credentials to use when establishing communication. You can perform all of these tasks from the appliance’s user interface. Once your settings are saved, the events you selected will be forwarded to eStreamer clients when requested.

You can control which types of events the eStreamer server is able to transmit to clients that request them.

Table 2. Event Types Transmittable by the eStreamer Server

Event Type

Description

Intrusion Events

intrusion events generated by managed devices

Intrusion Event Packet Data

packets associated with intrusion events

Intrusion Event Extra Data

additional data associated with an intrusion event such as the originating IP addresses of a client connecting to a web server through an HTTP proxy or load balancer

Discovery Events

Network discovery events

Correlation and White List Events

correlation and compliance white list events

Impact Flag Alerts

impact alerts generated by the FMC

User Events

user events

Malware Events

malware events

File Events

file events

Connection Events

information about the session traffic between your monitored hosts and all other hosts.

Comparison of Syslog and eStreamer for Security Eventing

Generally, organizations that do not currently have significant existing investment in eStreamer should use syslog rather than eStreamer to manage security event data externally.

Syslog

eStreamer

No customization required

Significant customization and ongoing maintenance required to accommodate changes in each release

Standard

Proprietary

Syslog standard does not protect against data loss, especially when using UDP

Protection against data loss

Sends directly from devices

Sends from FMC, adding processing overhead

Support for file and malware events, connection events (including security intelligence events) and intrusion events.

Support for all event types listed in eStreamer Server Streaming.

Some event data can be sent only from FMC. See Data Sent Only via eStreamer, Not via Syslog.

Includes data that cannot be sent via syslog directly from devices. See Data Sent Only via eStreamer, Not via Syslog.

Data Sent Only via eStreamer, Not via Syslog

The following data is available only from Firepower Management Center and thus cannot be sent via syslog from devices:

  • Packet Logs

  • Intrusion Event Extra Data events

    For a description, see eStreamer Server Streaming.

  • Statistics and aggregate events

  • Network Discovery events

  • User activity and login events

  • Correlation events

  • For malware events:

    • retrospective verdicts

    • ThreatName and Disposition, unless information about the relevant SHAs has already been synchronized to the device

  • The following fields:

  • Most raw IDs and UUIDs.

    Exceptions:

    • Syslogs for connection events do include the following: FirewallPolicyUUID, FirewallRuleID, TunnelRuleID, MonitorRuleID, SI_CategoryID, SSL_PolicyUUID, and SSL_RuleID

    • Syslogs for intrusion events do include IntrusionPolicyUUID, GeneratorID, and SignatureID

  • Extended metadata, including but not limited to:

    • User details provided by LDAP, such as full name, department, phone number, etc.

      Syslog only provides usernames in the events.

    • Details for state-based information such as SSL Certificate details.

      Syslog provides basic information like the certificate fingerprint, but will not provide other certificate details like the cert CN.

    • Detailed application information, such as App Tags and Categories.

      Syslog provides only Application names.

    Some metadata messages also include extra information about the objects.

  • Geolocation information

Choosing eStreamer Event Types

The eStreamer Event Configuration check boxes control which events the eStreamer server can transmit. Your client must still specifically request the types of events you want it to receive in the request message it sends to the eStreamer server. For more information, see the Firepower System Event Streamer Integration Guide.

In a multidomain deployment, you can configure eStreamer Event Configuration at any domain level. However, if an ancestor domain has enabled a particular event type, you cannot disable that event type in the descendant domains.

You must be an Admin user to perform this task, for FMC.

Procedure

Step 1

Choose System > Integration.

Step 2

Click eStreamer.

Step 3

Under eStreamer Event Configuration, check or clear the check boxes next to the types of events you want eStreamer to forward to requesting clients, described in eStreamer Server Streaming.

Step 4

Click Save.

Configuring eStreamer Client Communications

Before eStreamer can send eStreamer events to a client, you must add the client to the eStreamer server's peers database from the eStreamer page. You must also copy the authentication certificate generated by the eStreamer server to the client. After completing these steps you do not need to restart the eStreamer service to enable the client to connect to the eStreamer server.

In a multidomain deployment, you can create an eStreamer client in any domain. The authentication certificate allows the client to request events only from the client certificate's domain and any descendant domains. The eStreamer configuration page shows only clients associated with the current domain, so if you want to download or revoke a certificate, switch to the domain where the client was created.

You must be an Admin or Discovery Admin user to perform this task, for FMC.

Procedure

Step 1

Choose System > Integration.

Step 2

Click eStreamer.

Step 3

Click Create Client.

Step 4

In the Hostname field, enter the host name or IP address of the host running the eStreamer client.

Note

 

If you have not configured DNS resolution, use an IP address.

Step 5

If you want to encrypt the certificate file, enter a password in the Password field.

Step 6

Click Save.

The eStreamer server now allows the host to access port 8302 on the eStreamer server and creates an authentication certificate to use during client-server authentication.

Step 7

Click Download (download icon) next to the client hostname to download the certificate file.

Step 8

Save the certificate file to the appropriate directory used by your client for SSL authentication.

Step 9

To revoke access for a client, click Delete (delete icon) next to the host you want to remove.

Note that you do not need to restart the eStreamer service; access is revoked immediately.

Event Analysis in Splunk

You can use the Cisco Secure Firewall (f.k.a. Firepower) app for Splunk (formerly known as the Cisco Firepower App for Splunk) as an external tool to display and work with Firepower event data, to hunt and investigate threats on your network.

eStreamer is required. This is an advanced functionality. See eStreamer Server Streaming.

For more information, see https://cisco.com/go/firepower-for-splunk.

History for Analyzing Event Data Using External Tools

Feature

Version

Details

Integration with IBM QRadar

6.0 and later

IBM QRadar users can use a new Firepower-specific app to analyze their event data.

Available functionality is affected by your Firepower version.

See Event Analysis in IBM QRadar.

Enhancements to integration with Cisco SecureX threat response

6.5

  • Support for regional clouds:

    • United States (North America)

    • Europe

  • Support for additional event types:

    • File and malware events

    • High-priority connection events

      These are connection events related to the following:

      • Intrusion events

      • Security Intelligence events

      • File and malware events

Modified screens: New options on System > Integration > Cloud Services.

Supported Platforms: All devices supported in this release, either via direct integration or syslog.

Syslog

6.5

The AccessControlRuleName field is now available in intrusion event syslog messages.

Integration with Cisco Security Packet Analyzer

6.5

Support for this feature was removed.

Integration with Cisco SecureX threat response

6.3 (via syslog, using a proxy collector)

6.4 (direct)

Integrate Firepower intrusion event data with data from other sources for a unified view of threats on your network using the powerful analysis tools in Cisco SecureX threat response.

Modified screens (version 6.4): New options on System > Integration > Cloud Services.

Supported Platforms: Firepower Threat Defense devices running version 6.3 (via syslog) or 6.4.

Syslog support for File and Malware events

6.4

Fully-qualified file and malware event data can now be sent from managed devices via syslog.

Modified screens: Policies > Access Control > Access Control > Logging.

Supported Platforms: All managed devices running version 6.4.

Integration with Splunk

Supports all 6.x versions

Splunk users can use a new, separate Splunk app, Cisco Secure Firewall (f.k.a. Firepower) app for Splunk, to analyze events.

Available functionality is affected by your Firepower version.

See Event Analysis in Splunk.

Integration with Cisco Security Packet Analyzer

6.3

Feature introduced: Instantly query Cisco Security Packet Analyzer for packets related to an event, then click to examine the results in Cisco Security Packet Analyzer or download them for analysis in another external tool.

New screens:

System > Integration > Packet Analyzer

Analysis > Advanced > Packet Analyzer Queries

New menu options: Query Packet Analyzer menu item when right-clicking on an event on Dashboard pages and event tables on pages under the Analysis menu.

Supported platforms: Firepower Management Center

Contextual cross-launch

6.3

Feature introduced: Right-click an event to look up related information in predefined or custom URL-based external resources.

New screens: Analysis > Advanced > Contextual Cross-Launch

New menu options: Multiple options when right-clicking on an event on Dashboard pages and event tables on pages under the Analysis menu.

Supported platforms: Firepower Management Center

Syslog messages for connection and intrusion events

6.3

Ability to send fully-qualified connection and intrusion events to external storage and tools via syslog, using new unified and simplified configurations. Message headers are now standardized and include event type identifiers, and messages are smaller because fields with unknown and empty values are omitted.

Supported Platforms:

  • All new functionality: FTD devices running version 6.3.

  • Some new functionality: Non-FTD devices running version 6.3.

  • Less new functionality: All devices running versions older than 6.3.

For more information, see the topics under About Sending Syslog Messages for Security Events and subtopics.

eStreamer

6.3

Moved eStreamer content from the Host Identity Sources chapter to this chapter and added a summary comparing eStreamer to syslog.