Skip to main content

 

Splunk Lantern

Using Cisco Secure Firewall advanced logging with the Cisco Security Cloud app for the Splunk platform

Cisco Secure Firewall Threat Defense (FTD) version 10.0 introduces advanced logging, using Zeek-style protocol telemetry emitted directly from the firewall via syslog. It also introduces a significantly improved Splunk integration that splits event types at index time and adds MITRE ATT&CK enrichment. Combined with the Encrypted Visibility Engine (EVE), which uses on-box machine learning to identify malicious processes in encrypted traffic, these capabilities give SOC teams detailed visibility into what is happening on the wire without requiring a separate sensor or traffic decryption.

This article explains how to configure the FTD v10 Splunk integration and advanced logging, describes each of the six advanced log types, and shows how to use the Cisco Security Cloud app dashboards to investigate DNS exfiltration, C2 beaconing, HTTP anomalies, and protocol anomalies.

Prerequisites

  • Cisco Secure Firewall Threat Defense version 10.0 or later. Advanced logging is not available in earlier FTD versions.
  • FTD version 7.6 or later to use the Encrypted Visibility Engine (EVE). Version 7.6 is also the current recommended release for EVE.
  • Syslog forwarding configured from your FTD or FMC to the Splunk platform.
  • The Cisco Security Cloud app installed from Splunkbase.

Setting up the FTD v10 Splunk integration

FTD version 10.0 introduced a revised Splunk integration that provides two key improvements over earlier versions:

  • Native JSON parsing. FTD now emits events in JSON format, which eliminates the parsing overhead of earlier pipe-delimited formats and significantly reduces indexing time.
  • Source type splitting at index time. Events are bucketed into separate source types per event type at the point of indexing. Searching for intrusion events no longer requires filtering across all connection events first, so you search only the source type you need. This reduces common searches from minutes to seconds.

The integration also adds enhanced Common Information Model (CIM) mapping for both existing event types (connection, intrusion, malware) and the new advanced log types, as well as MITRE ATT&CK enrichment with dedicated fields for searching across the kill chain.

Enabling advanced logging per firewall rule

Advanced logging is enabled on a per-rule basis in FTD, the same way connection logging is configured today. Enable it selectively rather than on every rule, starting with rules that carry the highest-value traffic:

  • Broad outbound internet rules (for DNS, HTTP, and EVE visibility)
  • Inbound DMZ rules (for detecting probes and inbound attacks)
  • Inter-site or inter-company VPN rules (treated as an inbound trust boundary)

Advanced log events are shorter than standard connection events (which can reach 2 KB per event), so the volume impact of enabling advanced logging is smaller than you might expect. In FTD version 10.5, field-level selection per log type will give you further control over which fields are captured and forwarded.

The six advanced log types

Advanced logging adds six log types, produced by Snort, FTD's built-in packet inspection engine. All six share a uid field that correlates records across log types, so a WEIRD anomaly, its parent connection, and any DNS or HTTP records from the same flow all share a single uid value and can be pivoted between in a single search.

  • CONN — The foundational connection record. Every connection produces a CONN event; all other log types reference it via uid.
  • DNS — DNS query and full response, including every IP returned, per-answer TTLs, and complete TXT record payloads.
  • HTTP — One record per HTTP transaction, including method, URI, user agent string, body lengths, and HTTP version. HTTP/2 connections produce a separate HTTP event per request, all sharing the same uid.
  • FTP — Full command transcript for an FTP session: every command and server response, the submitted username, and reply codes.
  • WEIRD — Protocol anomaly records produced when a Snort inspector detects behavior that is anomalous but below the threshold of a confirmed intrusion. Includes the inspector name and a full anomaly description.
  • NOTICE — Intrusion alert records emitted in Zeek syntax, enabling intrusion events to participate in correlated searching alongside the other log types via uid. Includes a direct referral URL to documentation for the triggering Snort rule.

For full documentation on each log type, see Advanced logging in the Cisco Secure Firewall docs.

In FTD version 10.5, the uid field is planned to be extended to all traditional FTD event types—connection events, malware events, and intrusion events—enabling those existing event types to correlate into the advanced logging framework.

Using the Cisco Security Cloud App dashboards

The Cisco Security Cloud app includes a pre-built Advanced Logging dashboard that provides a starting point for SOC investigation. Install the app from Splunkbase and configure it to point to the source types produced by the FTD v10 integration.

The dashboard includes the following panels:

Panel What to look for
Advanced Logs over Time Baseline event volumes by log type. Sudden spikes in any type are worth investigating.
Unusual Connection States CONN states filtered to exclude normal graceful closures, showing states that indicate resets, timeouts, or incomplete handshakes. A spike in CLT_TCP_SYN_SENT SRV_TCP_SYN_RECV might indicate a SYN flood or active port scan.
Widely-Communicating Hosts A weighted ranking of hosts talking to the most unique destinations and ports. Hosts that rank highly on both dimensions might be performing reconnaissance or are compromised.
Top Ports over Baseline Destination ports that spiked in the last 24 hours compared to the prior week's baseline. Unusual ports appearing suddenly can indicate new services, misconfigurations, or lateral movement.
DNS Queries over Time Query volumes broken out by response code (NOERROR, NXDOMAIN, SRVFAIL). Spikes in NXDOMAIN can indicate domain generation algorithm (DGA) activity, which is compromised hosts cycling through generated domains looking for the active attacker-controlled one.
Top Failed DNS Queries The domains generating the most DNS failures. Clusters of failures from the same host are a DGA indicator.
Domains with Many Subdomains Hosts querying unusually high numbers of subdomains under a single domain. Filter out known CDN traffic to surface anomalies.
WEIRD Events (global map) Geographic distribution of WEIRD event source IPs. Select a country to pivot into the correlated events.
Rare User Agents The most prevalent user agents from the bottom of the frequency distribution. Enterprise tools sometimes have custom UA strings, but rare UAs from unexpected hosts are worth reviewing.
Rare Connection State History Unusual history flag sequences from CON records. The sequence SH (SYN + SYN-ACK, no ACK) is a common indicator of a port scanner or SYN flood.

The following demo walks through some examples of the Advanced Logging dashboard.

Pivoting from a WEIRD event to full connection context

The WEIRD Flow Drilldown dashboard demonstrates the value of the uid correlation field. Select any WEIRD event in the dashboard and the drilldown automatically retrieves the parent CONN record and any protocol-specific records (DNS, HTTP, FTP) that share the same uid and fall within a one-hour window of the anomaly.

The following demo shows the WEIRD Flow Drilldown dashboard in action.

Start WEIRD event investigations by reviewing the msg_source to identify which Snort inspector flagged the anomaly, then use the uid to pull the full flow context. Filtering the WEIRD Events panel by inspector type (for example, to show only HTTP or DNS anomalies) narrows the results to a specific protocol before drilling down.

SOC use cases

Detecting DNS exfiltration and tunneling

The DNS log type supports several searches that surface common exfiltration and tunneling techniques:

  • Queried domains never visited. A DNS lookup that returns an IP address that the querying host never subsequently connects to is anomalous. Normal DNS behavior resolves a name to reach a destination, while a query with no follow-on connection suggests the DNS response was the destination (as in DNS exfiltration, where the attacker's authoritative server receives the data encoded as subdomain queries and acknowledges with a fake IP).
  • Long subdomain lookups from a single host. DNS exfiltration typically chops data into chunks encoded as subdomains. A host performing many lookups against the same domain where each subdomain is over 40 characters is a strong indicator worth investigating. Filter out known CDN domains before reviewing results.
  • Large TXT record responses. TXT lookups are uncommon outside of email infrastructure (SPF, DKIM checks). Large TXT payloads from hosts that are not mail servers can be a sign of DNS C2, commands encoded in TXT responses.
  • High DNS failure rates from specific hosts. A host infected with DGA malware generates many NXDOMAIN responses as it cycles through generated domain names. The Top Failed DNS Queries panel and the hosts-with-high-failure-rate view surface this pattern.

Identifying C2 beaconing with the Encrypted Visibility Engine

EVE uses on-box machine learning to fingerprint encrypted traffic and assess the likelihood that a connection originates from a malicious process. It does not require decrypting traffic. EVE output includes a threat confidence score bucketed into five tiers: very high, high, medium, low, and very low.

Recommended approaches for using EVE data:

  • Monitor medium-confidence scores. FTD can be configured to block very-high and high-confidence threats autonomously. Medium-confidence connections, those just below the block threshold, warrant review. A connection scored at 89% confidence when the block threshold is 90% might still be malicious.
  • Track hosts with high EVE scores over time. A sudden increase in the number of hosts generating high EVE scores can indicate a worm spreading through the network or a phishing campaign delivering the same payload to multiple users. Pivot from those source IPs to EDR data or consider quarantine.
  • Search for process names starting with malware. When EVE designates a connection as very high or high confidence, the process name field typically begins with malware. Searching for process="malware*" surfaces connections that EVE has flagged as needing immediate investigation.

Hunting HTTP anomalies

The HTTP log type surfaces several patterns that are not visible in standard connection events:

  • Known-malicious user agent strings. Publicly available lists document user agent strings associated with attack frameworks such as Cobalt Strike and Metasploit. Searching for these strings in the user_agent field surfaces both active attacks and internal security team testing. The Cisco Security Cloud App includes a Rare User Agents panel that shows the most prevalent of the uncommon user agents in your environment as a starting point.
  • Unusual HTTP verbs. PUT, DELETE, and PATCH requests from endpoint hosts are uncommon outside of specific application and IT subnets. Their presence elsewhere can indicate API abuse, malware C2, or misconfigured applications. Some malware families use custom fake verbs that are an immediate indicator of compromise.
  • Beaconing patterns. A host sending small, consistent HTTP requests to the same destination at fixed intervals—for example, every 37 minutes—is a classic C2 check-in pattern. The request body length and response body length fields in the HTTP log help identify consistent small-payload exchanges.
  • URI path anomalies. Search the uri field for path traversal sequences (../), encoded characters (%2e%2e), and unusual parameter structures that can indicate exploitation attempts against your web-facing resources.

Investigating connection state anomalies

The Unusual Connection States panel in the Advanced Logging dashboard filters out normal graceful connection closures and surfaces states that indicate unusual or incomplete connection behavior. Use the panel to identify:

  • High volumes of CLT_TCP_SYN_SENT SRV_TCP_SYN_RECV — SYN packets sent but the three-way handshake never completed. A spike here is a common indicator of a SYN flood or a port scanner such as Nessus that does not complete handshakes for performance reasons.
  • Connection resets from unexpected parties — for example, a server resetting a connection before data transfer can indicate a service crash, a misconfigured access control, or a connection being terminated by a security device mid-session.

Click any connection state value in the panel to pivot directly to the CONN events with that state.

Recommendations for deployment

Recommendations for getting started:

  • Enable advanced logging on your most impactful rules first: broad outbound internet rules, inbound DMZ rules, and inter-site VPN rules. You can extend to additional rules as you become familiar with the volume and tune your dashboards.
  • Adopt the FTD v10 Splunk integration when you upgrade to version 10.0. The JSON format and source type splitting significantly improve search performance. Even if you are not yet on 10.0, upgrading the Cisco Security Cloud app brings CIM mapping improvements for existing event types.
  • Enable the Encrypted Visibility Engine and keep vulnerability database updates set to auto-update. The on-box machine learning model is updated with each vulnerability database release. Falling significantly behind on updates degrades detection accuracy.
  • Use the Cisco Security Cloud app dashboards as a starting point and customize them. The app dashboards are updated monthly as new log types and detection searches are added.

Next steps

Now that you know how to use Cisco Secure Firewall advanced logging and the Encrypted Visibility Engine to detect threats in the Splunk platform, watch the full talk from Cisco Live Las Vegas 2026, Build a Better SOC: Splunk Dashboards for Cisco Secure Firewall (BRKOBS-2015). In the talk, you can learn more about the six advanced log types, the EVE threat confidence scoring model, and how to use the Cisco Security Cloud App dashboards to investigate DNS exfiltration, C2 beaconing, and protocol anomalies.

You might also find the following resources useful:

  • Written by Marc Mastrangelo (Leader, Product Management) and Bill Spry (TME Technical Leader)
  • Cisco