Securing the Network Edge: Cisco Secure Firewall Threat Defense Detections for Splunk

By integrating Cisco’s Firepower Threat Defense (FTD) with Splunk’s analytics platform, your security team immediately gains comprehensive, organization-wide visibility into network threats far beyond what any single firewall can detect alone. Yet, despite the critical need to bridge network and security data, many organizations still deploy perimeter defenses like Cisco's FTD but struggle to convert its rich telemetry into actionable insights useful to a SOC. Too often, these technologies operate in silos, forcing security teams to rely either on basic log collection without sufficient security context to generate an alert or on generic integrations like the Cisco Security Cloud Splunk App, which lack tailored, out-of-the-box detection capabilities and only report on firewall metrics like connections. This gap frequently leaves teams burdened with manually building custom detection logic from scratch, limiting the full potential of their security investments.

The Splunk Threat Research Team (STRT) identified this gap as an opportunity to demonstrate how these technologies can be more powerful when used together. Our "Better Together" initiative aims to provide immediate value for both customer bases:

• For Cisco customers: Out-of-the-box security detections translate FTD's powerful network telemetry into actionable security detections without requiring advanced Splunk knowledge.
• For Splunk customers: The rich context provided by Cisco FTD devices enables detailed visibility into network-level threats.

This initiative marks the first phase of a broader collaboration to deliver more integrated security monitoring experiences that emphasize the customer value across Cisco's security portfolio and Splunk's analytics capabilities. As part of Cisco, Splunk’s Threat Research Team uniquely collaborates directly with the Talos threat research and FTD engineering teams, learning the data structure and detection capabilities of these devices. In this article, we demonstrated how combining Cisco’s FTD telemetry with Splunk’s advanced analytics allowed us to develop 17 targeted detections including anomaly identification, suspicious file downloads, and high-volume intrusion alerts providing security teams threat visibility across their entire Cisco firewall deployment, rather than relying on isolated insights from individual devices.

Building a Real-World Test Environment

To create meaningful, battle-tested detections, STRT established a comprehensive lab environment that mimics real-world deployment scenarios. This allowed us to understand the data structure, test attack scenarios, and validate detection efficacy.

Animation: https://josehelps.github.io/cisco-ftd-visualization/

Our lab architecture consists of several key components deployed in an AWS VPC:

• Firewall Management Center (FMC): A management console hosted on Security Cloud Control that provides centralized policy administration
• Firepower Threat Defense (FTD): The core security appliance that generates the telemetry data
• Linux and Windows Hosts: Target systems that allow us to simulate internal networks and generate realistic traffic
• Splunk Instance: A dedicated environment for log ingestion, correlation, and detection development

To collect and process the data from our Cisco devices, we used the Cisco Security Cloud app for Splunk. This Splunk App offers seamless integration between Cisco security products and Splunk, featuring a modular UX input design, built-in health checks, and continuous monitoring to ensure operational integrity. The app supports multiple Cisco security products, including:

• Cisco AI Defense
• Cisco Duo
• Cisco Email Threat Defense (ETD)
• Cisco Identity Intelligence (CII)
• Cisco Multicloud Defense
• Cisco Secure Endpoint
• Cisco Secure Firewall (FTD/eStreamer/ASA)
• Cisco Secure Malware Analytics (SMA)
• Cisco Secure Network Analytics (SNA)
• Cisco Vulnerability Intelligence
• Cisco XDR

In our testing environment alone, we generated and analyzed over 650,000 events across four different event types in just 60 days, providing us with a deep dataset for detection development and validation.

Understanding the eStreamer protocol was essential for our work, as it provided the structure needed to parse and normalize the data within Splunk's Common Information Model (CIM). While most detections used raw data, we took the time to deeply understand what each field meant and how it was used.

The eStreamer protocol allows for specific event types to be ingested from the Firewall Management Center (FMC). While the FMC can provide a variety of event types (Discovery Events, Correlation Events, Impact Flag Alerts, and more), our integration with Splunk via the Cisco Security Cloud TA focuses on these four primary event types:

• Connection Events: Detailed network flow data including endpoints, protocols, and applications
• File Events: Information about files transferred over the network, including malware verdicts
• Intrusion Events: Alerts triggered by Snort rules and other intrusion detection mechanisms
• Intrusion Packets: Captured network traffic which triggered an Intrusion Event. The Intrusion Packets can be correlated with the corresponding Intrusion Event.

Each event type contains a rich set of fields that provide context for security analysis. For example, a Connection Event includes details such as:

{
 "EventType": "ConnectionEvent",
 "FirstPacketSecond": 1746616737,
 "InitiatorIP": "172.16.3.110",
 "ResponderIP": "99.78.180.156",
 "InitiatorPort": 32116,
 "ResponderPort": 443,
 "Protocol": "tcp",
 "AC_RuleAction": "Allow",
 "ClientApplication": "SSL client",
 "Application": "HTTPS",
 "EVE_Process": "pulumi",
 "EVE_ProcessConfidencePct": 99,
 "EVE_ThreatConfidenceIndex": 1
 // Additional fields omitted for brevity
}

These fields are defined in configuration structures called "FieldSetDef" in the FMC's EventCatalog.json, allowing us to request specific subsets of data for each event type.

For teams looking to expand on our work, Cisco's Secure Firewall eStreamer Fully-Qualified Events Guide provides comprehensive documentation of the protocol and event structure. Additionally, we've published our internal field mappings for each event type as part of our open-source security content to help others build upon these detections.

From Telemetry to Actionable Security

Our extensive attack simulations and side-by-side collaboration with Cisco's Talos team yielded a robust set of 17 security detections for Cisco Secure Firewall Threat Defense. These detections leverage the rich telemetry provided by FTD devices to identify potential threats across multiple stages of the attack lifecycle.

The detections are organized into the Cisco Secure Firewall Threat Defense Analytics analytic story, available through the Enterprise Security Content Update (ESCU) 5.4.0 release. This story provides a comprehensive framework for monitoring and detecting threats at the network perimeter using Cisco FTD devices.

Each detection in the analytic story comes with metadata mapping to the MITRE ATT&CK framework, providing security teams with context about the adversary tactics being employed.

The majority of these detections are classified as "Anomaly" detections, meaning they identify behaviors that deviate from normal patterns, while "Hunting" detections like "Rare Snort Rule Triggered" are designed to support proactive threat hunting activities.

What makes these detections particularly valuable is that each one includes sample attack data, allowing security teams to test and validate them in their own environments using the Attack Data project. This ensures that teams can verify the effectiveness of detections before deploying them in production environments.

These detections are organized around the following three key event types:

1. Connection events
2. File events
3. Intrusion events

Below, we walk through each event type, explain briefly what it offers, and show a detection built around it.

Connection Event Detections

Connection events log metadata about network traffic flows. These include source and destination IPs, ports, application protocols, SSL certificate fingerprints, and details from Cisco's Encrypted Visibility Engine (EVE)

{
    "EventType": "ConnectionEvent",
    "FirstPacketSecond": 1746616737,
    "LastPacketSecond": 1746616746,
    "ConnectionDuration": 9,
    "DeviceUUID": "11bc8e94-f604-11ef-bcfe-xxxxxxx",
    "InstanceID": 1,
    "ConnectionID": 13715,
    "AC_RuleAction": "Allow",
    "InitiatorIP": "172.16.xxx.xxx",
    "ResponderIP": "99.78.xxx.xxx",
    "InitiatorPort": 32116,
    "ResponderPort": 443,
    "Protocol": "tcp",
    "IngressInterface": "inside",
    "EgressInterface": "outside",
    "IngressZone": "inside",
    "EgressZone": "outside",
    "IngressVRF": "Global",
    "EgressVRF": "Global",
    "FirewallPolicy": "default",
    "FirewallRule": "Permit Outbound",
    "PrefilterPolicy": "Default Prefilter Policy",
    "ClientApplication": "SSL client",
    "Application": "HTTPS",
    "WebApplication": "Amazon Web Services",
    "InitiatorPackets": 19,
    "ResponderPackets": 20,
    "InitiatorBytes": 3497,
    "ResponderBytes": 6222,
    "NAP_Policy": "Balanced Security and Connectivity",
    "SSL_Policy": "None",
    "SSL_FlowStatus": "Success",
    "SSL_CipherSuite": "Unknown",
    "SSL_CertFingerprint": "ba6360463452acfa35e48eb7d446e4c1165ed659",
    "SSL_Version": "Unknown",
    "SSL_ServerCertStatus": "Valid",
    "SSL_ActualAction": "Do Not Decrypt",
    "SSL_ExpectedAction": "Do Not Decrypt",
    "URL": "https://ssm.us-east-2.amazonaws.com",
    "NAT_InitiatorPort": 32116,
    "NAT_ResponderPort": 443,
    "NAT_InitiatorIP": "172.16.xxx.xxx",
    "NAT_ResponderIP": "99.78.xxx.xxx",
    "EVE_Fingerprint": "tls/1/(0303)(c02bc02fc02cc030cca9cca8c009c013c00ac014130113021303)[(0000)(000500050100000000)(000a000c000a6399001d001700180019)(000b00020100)(000d001a0018080404030807080508060401050106010503060302010203)(0010000e000c02683208687474702f312e31)(0012)(0017)(002b00050403040303)(0033)(ff01)]",
    "EVE_Process": "pulumi",
    "EVE_ProcessConfidencePct": 99,
    "EVE_ThreatConfidencePct": 0,
    "EVE_ThreatConfidenceIndex": 1,
    "ClientAppDetector": "AppID"

}

This data gives us deep visibility into what's moving through the network and how it's moving. For example, we can spot unusual outbound destinations, identify the applications initiating connections (even over encrypted traffic), and observe when trusted protocols are being used in suspicious ways.

Take this detection, for instance:

Cisco Secure Firewall - Bits Network Activity

`cisco_secure_firewall` EventType=ConnectionEvent action=Allow ClientApplication="BITS" AND NOT url IN ("*://msedge.b.tlu.dl*")
| stats count min(_time) as firstTime max(_time) as lastTime by src_ip, dest, dest_port, transport, rule, url, EVE_Process, ClientApplication, ClientApplicationVersion, action
| `security_content_ctime(firstTime)` 
| `security_content_ctime(lastTime)` 
| `cisco_secure_firewall___bits_network_activity_filter`

Microsoft uses BITS (Background Intelligent Transfer Service) to deliver updates. But because it runs quietly in the background and can often bypass proxies or inspection layers, it's also a popular choice for adversaries to move data or establish command-and-control channels.

This detection identifies potentially suspicious use of the Windows BITS service by leveraging Cisco Secure Firewall Threat Defense's built-in application detectors.

Within Connection events, the ClientApplication field captures the name of the application initiating the connection, based on either built-in or custom app detectors.

One of those built-in detectors specifically identifies BITS traffic, which we used to flag cases where BITS was communicating with unexpected destinations. This lets us catch abuse attempts of such a service.

We've applied the same approach across other fields in the Connection event type. For example, the SSL_CertFingerprint field contains the SHA1 hash of the SSL certificate used in a session. By comparing this fingerprint against a list of known-bad certificates, we built a detection that can surface encrypted traffic tied to malicious infrastructure, even when domain or IP-based indicators aren't available.

Check out research.splunk.com to explore the full analytic story.

File Event Detections

File events capture details about files transferred over the network, including the file type, direction (download or upload), SHA hash, application used for the transfer, and AMP disposition (whether the file is known malware, clean, or unknown).

This telemetry gives us visibility into potentially risky file activity, such as executable downloads, data exfiltration attempts, or repeated downloads of the same suspicious file. Since attackers often deliver payloads through seemingly harmless downloads, file-level visibility is key to catching those early delivery stages.

{
    "EventType": "FileEvent",
    "EventSecond": 1746614252,
    "DeviceUUID": "11bc8e94-f604-11ef-bcfe-eeb1de9c8a63",
    "InstanceID": 1,
    "FirstPacketSecond": 1746614252,
    "ConnectionID": 13652,
    "InitiatorIP": "172.16.xxx.xxx",
    "ResponderIP": "146.75.xxx.xxx",
    "InitiatorPort": 32018,
    "ResponderPort": 80,
    "Protocol": "tcp",
    "FileDirection": "Download",
    "FileAction": "Malware Cloud Lookup",
    "FileSHA256": "5806a935e72d5606cd504f5cb1b4f533705118e869db872f6dc4876006defd8c",
    "SHA_Disposition": "Unknown",
    "SperoDisposition": "Spero detection not performed on file",
    "FileName": "am_delta_patch_1.427.653.0_d5919c1ed40292100562f06100e691cab2383d21.exe",
    "FileType": "MSEXE",
    "FileSize": 767600,
    "Application": "HTTP",
    "ClientApplication": "Parallels",
    "WebApplication": "Microsoft Update",
    "FilePolicy": "Test",
    "FileStorageStatus": "Not Stored (Disposition Was Pending)",
    "FileSandboxStatus": "Sent for Analysis",
    "FileStaticAnalysisStatus": "Failed to Send",
    "URI": "/d/msdownload/update/software/defu/2025/05/am_delta_patch_1.427.653.0_d5919c1ed40292100562f06100e691cab2383d21.exe",
    "IngressVRF": "Global",
    "EgressVRF": "Global",
    "Device": "172.16.0.10",
    "DeviceIP": "172.16.0.10",
    "DeviceSerialNumber": "9AD5V8FSS0D"
}

One particularly useful field here is FileType. Cisco Secure Firewall Threat Defense can classify transferred files by type, even within encrypted flows. This allows us to focus on higher-risk categories, such as executable formats (.exe, .msi, .scr, etc.), which are commonly associated with malware delivery. For example:

Cisco Secure Firewall - Binary File Type Download

This analytic detects file downloads involving executable, archive, or scripting-related file types that are commonly used in malware delivery. These file types include formats like PE executables, shell scripts, autorun files, installers, and known testing samples such as EICAR.

`cisco_secure_firewall` EventType=FileEvent FileDirection="Download" 
FileType IN ("ISHIELD_MSI", "BINHEX", "BINARY_DATA", "ELF", "MACHO", "JARPACK", "TORRENT", "AUTORUN", "EICAR", "LNK", "SCR", "UNIX_SCRIPT")
| lookup cisco_secure_firewall_filetype_lookup Name as FileType OUTPUT Description
| stats count min(_time) as firstTime max(_time) as lastTime
        values(uri) as uri
        values(ClientApplication) as ClientApplication
        values(file_hash) as file_hash
        values(SHA_Disposition) as SHA_Disposition
        by FileDirection FileType src_ip dest app file_name ThreatName dest_port Description
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
| table firstTime lastTime src_ip dest dest_port FileDirection FileType Description uri file_name file_hash app ClientApplication SHA_Disposition ThreatName
| `cisco_secure_firewall___binary_file_type_download_filter`

And just like with Connection events, we leveraged a combination of other fields such as FileDirection, SHA_Disposition and ResponderPort, to build detections that surface file downloads over uncommon ports, or malware being downloaded, which might indicate attempts to bypass standard security controls.

The full list of analytics related to this event type can be found at research.splunk.com.

Intrusion Event Detections

Intrusion events are generated when Snort and other detection mechanisms in Cisco Secure Firewall Threat Defense, match traffic against a rule. Each event logs information like the triggered signature, source and destination IPs, the rule's classification, and, when available, mappings to MITRE ATT&CK techniques.

This telemetry gives insight into actual attack behavior, whether it's exploitation, scanning, malware traffic, or other known patterns, especially when combined with the IntrusionPacket event. Because Snort rules are maintained by Cisco's Talos threat research team, they reflect real-world attacker techniques and are updated regularly based on emerging threats.

{
    "EventType": "IntrusionEvent",
    "EventSecond": 1746614252,
    "EventMicrosecond": 859986,
    "DeviceUUID": "11bc8e94-f604-11ef-bcfe-eeb1de9c8a63",
    "InstanceID": 1,
    "FirstPacketSecond": 1746614252,
    "ConnectionID": 13652,
    "InitiatorIP": "146.75.xxx.xxx",
    "ResponderIP": "172.16.xxx.xxx",
    "InitiatorPort": 80,
    "ResponderPort": 32018,
    "Protocol": "tcp",
    "IngressInterface": "outside",
    "EgressInterface": "inside",
    "IngressZone": "outside",
    "EgressZone": "inside",
    "PriorityID": 1,
    "GeneratorID": 1,
    "SignatureID": 11192,
    "SignatureRevision": 20,
    "Impact": 5,
    "IntrusionRuleMessage": "FILE-EXECUTABLE download of executable content",
    "Classification": "Potential Corporate Policy Violation",
    "WebApplication": "Microsoft Update",
    "ClientApplication": "Parallels",
    "Application": "HTTP",
    "IntrusionPolicy": "default",
    "FirewallPolicy": "default",
    "FirewallRule": "Permit Outbound",
    "NAP_Policy": "Balanced Security and Connectivity",
    "InlineResult": "Would block",
    "InlineResultReason": "Intrusion Policy in \"Detection\" Inspection Mode",
    "IngressVRF": "Global",
    "EgressVRF": "Global",
    "HTTP_Hostname": "au.download.windowsupdate.com",
    "HTTP_URI": "/d/msdownload/update/software/defu/2025/05/am_delta_patch_1.427.653.0_d5919c1ed40292100562f06100e691cab2383d21.exe",
    "SnortRuleGroups": "Rule Categories>File>Executable",
    "MitreAttackGroups": "MITRE>ATT&CK Framework>Enterprise>Execution>User Execution>Malicious File",
    "ApplicationID": 676,
    "ApplicationProductivityIndex": 3,
    "ApplicationRiskIndex": 1,
    "ClientApplicationID": 2802,
    "ClientApplicationProductivityIndex": 4,
    "ClientApplicationRiskIndex": 2,
    "Device": "172.16.xxx.xxx",
    "DeviceIP": "172.16.xxx.xxx",
    "DeviceSerialNumber": "9AD5V8FSxxx",
    "EgressInterfaceUUID": "efbb6160-f60a-11ef-a955-43d7eeccc024",
    "EgressZoneUUID": "efbcd7ac-f60a-11ef-a955-43d7eeccc024",
    "EventID": 250,
    "FirewallPolicyUUID": "00000000-0000-0000-0000-000068187db4",
    "FirewallRuleID": 268434433,
    "Hostname": "ip-172-16-0-50.us-east-2.compute.internal",
    "IngressInterfaceUUID": "ef9a2180-f60a-11ef-a955-43d7eeccc024",
    "IngressZoneUUID": "ef9c7c64-f60a-11ef-a955-43d7eeccc024",
    "InitiatorContinent": "North America",
    "InitiatorContinentCode": "na",
    "InitiatorCountry": "United States",
    "InitiatorCountryCode": "usa",
    "InitiatorCountryID": 840,
    "InlineResultID": 5,
    "InlineResultReasonID": 2,
    "IntrusionPolicyRevUUID": "c1fab45a-f615-11ef-bd70-44d7eeccc024",
    "IntrusionPolicyUUID": "0210b9f5-95a7-0ed3-0000-004294971142",
    "NAP_PolicyUUID": "a6738542-f604-11ef-8765-a4eeeeccc024",
    "ProtocolID": 6,
    "RealmID": 0,
    "RealmName": "Invalid ID",
    "SensorID": 2,
    "SnortVersionID": 3,
    "UserID": 9999997,
    "WebApplicationHTTP": "Microsoft Update",
    "WebApplicationID": 731,
    "WebApplicationProductivityIndex": 2
}

Intrusion events are particularly helpful when used at scale. One alert might not be significant on its own, but when the same rule is triggered across multiple systems or in high volume from a single source, that pattern can reveal larger attack campaigns or compromised assets. Lets pick the following detection example:

Cisco Secure Firewall - High Volume of Intrusion Events Per Host

This detection identifies systems triggering an unusually high number of intrusion alerts, which may indicate an active attack or compromise.

`cisco_secure_firewall` EventType=IntrusionEvent
| bin _time span=30m
| stats count as TotalEvents values(signature_id) as signature_id
        values(signature) as signature
        values(dest) as dest
        values(dest_port) as dest_port
        min(_time) as firstTime max(_time) as lastTime 
        by src_ip class_desc MitreAttackGroups InlineResult InlineResultReason rule transport app
| where TotalEvents >= 15
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
| `cisco_secure_firewall___high_volume_of_intrusion_events_per_host_filter`

By leveraging the metadata in the event and the event itself, we can start correlating and aggregating different intrusion alerts into an alert with higher confidence.

Better Together: The Power of Collaboration

This project represents the tangible benefits of collaboration between Cisco and Splunk. By combining Cisco's deep network security expertise with Splunk's advanced analytics capabilities, we've created detections that extract maximum value from both platforms. This partnership provided direct access to Cisco's 60,000 Snort rules, allowing us to prioritize and integrate the most valuable alerts into Splunk's detection framework. The result is a comprehensive set of detections that leverage the strengths of both platforms to provide better security outcomes for our customers.

The success of this initiative was made possible through close collaboration with Cisco's Talos Network Threat Detection and Response (NTDR) team. Special thanks to Nasreddine Bencherchali, who led the detection engineering efforts from the Splunk side and was instrumental in developing the Cisco Secure Firewall Threat Defense Analytics story.

The leadership from the Cisco team who supported this effort includes:

• Christopher Marshall, Director of Security Research
• Alain Zidouemba, Director of Detection & Response for Talos
• Marc Mastrangelo, Product Management
• Zack Kielich, Director, Solutions

Key technical contributors from Cisco included:

• Keith Lehrschall, Sr. Manager of Network Security Research
• Matthew Mickel, Security Research Engineering Technical Leader
• Spenser Reinhardt, Security Research Engineering Technical Leader
• John Levy, Security Research Engineering Technical Leader

What's Next: Building on the Foundation

While the initial release of 17 detections represents a significant milestone, it's only the beginning of our journey. Our roadmap includes several exciting developments:

1. Expanded platform coverage: We plan to extend our detection capabilities to additional Cisco security products beyond FTD.
2. Advanced correlation: We're developing detections that correlate data across multiple Cisco products, enabling more sophisticated threat hunting capabilities.
3. Endpoint integration: Future detections will combine network telemetry with endpoint data to provide a more complete picture of potential threats.
4. Targeted campaign detection: We're working on detections specifically focused on known threat actors and campaigns, leveraging Cisco Talos intelligence

Our commitment to the "Better Together" philosophy will continue to drive this initiative as we work to create a more seamless and effective security monitoring experience for customers who leverage both Cisco and Splunk technologies.

Getting Started

Ready to implement these detections in your environment? Here's how to get started:

1. Update your content: Install the latest Enterprise Security Content Update (ESCU) 5.4.0 or later from Splunkbase
2. Install the Cisco Security Cloud App: Deploy the Cisco Security Cloud app for Splunk to collect and normalize your Cisco FTD data
3. Explore the analytics: Visit the Cisco Secure Firewall Threat Defense Analytics story on Splunk Research to review the full set of detections
4. Contribute: Have ideas for improvements? Visit our Security Content repository on GitHub to contribute to the ongoing development of these detections
5. Stay connected: Join the #security-research channel in the Splunk user groups on Slack to engage with our research team and the broader community