Cisco Secure Firewall: The Origins and Evolution of Sourcefire

The journey of Cisco Secure Firewall begins with the creation of SNORT in 1998 by Martin Roesch. SNORT was an open-source Intrusion Prevention System (IPS) that quickly gained popularity for its flexibility and community-driven development. However, while it was powerful, it lacked centralized management capabilities.

In 2001, Roesch founded a company called Sourcefire with the aim of commercializing SNORT. While SNORT remained open-source, Sourcefire enhanced it by packaging it as an appliance and adding a user-friendly management console. This console introduced centralized control for tasks such as rule management, updates, and configuration, features not available in the standalone open-source version.

Over the years, Sourcefire evolved by introducing several key features:

  • RNA (Real-time Network Awareness) transitioned into FireSIGHT, which is now known as Network Discovery.
  • The addition of Access Control Policies, bringing in Next-Generation Firewall (NGFW) features.
  • URL Filtering to enhance web security.
  • Support for VPN connectivity between appliances, though this functionality is reportedly not commonly used in the field.
  • Advanced Malware Protection (AMP), sourced from Sourcefire’s 2011 acquisition of Immunet. This cloud-based anti-malware solution uses global threat intelligence rather than relying on traditional local signatures.

In 2013, Cisco acquired Sourcefire and began integrating its capabilities into Cisco’s broader security portfolio. As a result, AMP was embedded across multiple Cisco security platforms, including:

  • Web Security Appliance (WSA)
  • Email Security Appliance (ESA)
  • Email Threat Defense (ETD)
  • Secure Firewall (formerly Firepower)
  • Meraki MX Firewalls
  • Secure Access
  • Cisco Multicloud Defense
  • Cisco Umbrella
  • And more…

This acquisition and integration marked the beginning of Cisco’s consolidated threat defense platform, now marketed under the Cisco Secure Firewall umbrella. Today, Secure Firewall continues to build on Sourcefire’s legacy by offering unified threat management, advanced malware protection, and deep network visibility in both on-premises and cloud environments.

 

Typical Secure Firewall Deployment Scenarios and Policies

Cisco Secure Firewall (formerly Sourcefire) supports a variety of deployment models tailored for different network zones and traffic types. These deployments help organizations optimize protection without compromising performance or visibility.

At the Internet Edge, Secure Firewall is typically deployed in an inline or bridge configuration. This placement is ideal for enabling IPS, firewall capabilities, URL filtering, and Cisco’s Security Intelligence features, which provide dynamic threat blocking based on global intelligence feeds.

In eCommerce environments, Secure Firewall is commonly positioned in the DMZ, also in inline or bridge mode. Here, it is used to secure web-facing applications and services, offering intrusion prevention, firewall enforcement, security intelligence, and geolocation-based filtering.

Within the enterprise data center, Secure Firewall can be deployed in passive mode using SPAN (Switched Port Analyzer) configurations. This allows for threat detection without inserting the firewall into the traffic path, which can be beneficial for visibility without latency or risk to uptime.

For cloud-based data centers, particularly in public cloud environments, deployments often focus on visibility and detection rather than inline enforcement. In multi-data center deployments, the architecture introduces complexities such as asymmetric traffic flows. These can lead to issues like false positives, degraded throughput, and packet misinterpretation.

To mitigate such challenges, Cisco Secure Firewall offers two common solutions:

  • Deploying Secure Firewall on dedicated appliances or virtual machines with clustering to improve session awareness and redundancy.
  • Using passive IPS deployments, which allow inspection without disrupting traffic flow or introducing latency.

 

Policy Architecture in Secure Firewall

Policy configuration is a core part of Secure Firewall’s NGFW capabilities. At the heart of this architecture is the Access Control Policy (ACP). ACP serves as the umbrella policy that references and links together various other security policies,such as intrusion prevention, malware detection, and SSL decryption, into a unified enforcement framework.

Here’s a breakdown of key policy types within Secure Firewall:

  • Intrusion Policy: Defines the IPS rules applied to traffic. This policy leverages SNORT rule sets and Cisco Talos threat intelligence for deep packet inspection.
  • File/Malware Policy: Manages Advanced Malware Protection (AMP) settings. This cloud-based engine detects and blocks malicious files using behavioral analysis and sandboxing.
  • Network Discovery Policy: Formerly known as FireSIGHT, this policy enables visibility into the network’s hosts, operating systems, applications, and users.
  • SSL Policy: Configures SSL decryption rules, allowing inspection of encrypted traffic for threats hidden within secure sessions.

Together, these policies allow Secure Firewall to deliver robust, granular control over network security while adapting to diverse deployment scenarios.

 

Cisco Secure Firewall Packet Processing: The Big Picture

Source: BRKSEC-3533

Credit for above image: Cisco Live Presentation BRKSEC-3533

Understanding how packets are processed within Cisco Secure Firewall (formerly Firepower) is essential for optimizing performance and policy enforcement. The architecture of Cisco Secure Firewall Threat Defense (FTD) integrates two main processing engines: the Lina engine, responsible for traditional firewall functions, and the Snort engine, which handles advanced inspection like intrusion prevention, malware detection, and URL filtering.

Step-by-Step Packet Flow in Cisco FTD

  1. Packet Reception (RX) and Ingress
    • A packet first arrives at the ingress interface. If fragmentation is detected, the defragmentation policy is applied early in the process.
  2. NAT and VPN Handling
    • Next, UN-NAT is performed to revert any prior address translation.
    • If the packet is VPN-encrypted, VPN decryption occurs here to expose the inner payload for further inspection.
  3. Session and Prefilter Check
    • If the session is already established (an existing connection), the packet can bypass deep inspection and proceed via the fastpath.
    • If it’s a new connection, the packet is subjected to the Prefilter Policy, where decisions about bypassing Snort or continuing deeper analysis are made.
  4. Access Control and Snort Ingress
    • The packet hits the L3/L4 Access Control List (ACL) to apply base-level firewall policies.
    • From here, the packet enters the Snort engine via the DAQ (Data Acquisition) module, where deep inspection begins.

 

Snort Engine Inspection Path

Once in the Snort path, the packet goes through several advanced security checks:

  • SI IP Blacklist: Checks against Security Intelligence IP blocklists.
  • SSL Decryption: If the traffic is encrypted, SSL decryption policies are applied to allow inspection.
  • SI DNS/URL Blacklist: Traffic is checked against domain and URL threat intelligence feeds.
  • Identity Policy: Determines user identity for context-aware access decisions. Packets may be dropped here if unauthorized.
  • Layer 7 ACLs: Application- and URL-based filtering rules are applied.
  • QoS Classification: Classifies traffic for bandwidth enforcement.
  • Network Discovery: Gathers telemetry about hosts, services, and applications.
  • File Policy: Applies malware analysis using AMP; malicious files may trigger drops.
  • Snort Rules: Applies signature- and behavior-based intrusion detection and prevention. If a rule matches, a Snort Verdict is issued, possibly resulting in a drop.

 

Return to Lina Engine (Post-Snort Path)

After Snort processing, the packet re-enters the Lina engine for remaining services:

  • Flow Update: Updates session tracking information.
  • ALG Checks: Performs Application Layer Gateway validations (e.g., for SIP or FTP).
  • NAT IP Header: Applies destination NAT as configured.
  • QoS Enforcement: Enforces any configured traffic shaping or prioritization.
  • VPN Encryption: If needed, encrypts the packet before it exits.

 

Routing and Final Transmission

  • L3 Routing: Determines the outbound interface based on the routing table.
  • L2 Address Resolution: Performs ARP resolution.
  • TX (Transmit): Finally, the packet is transmitted out of the firewall.

If at any stage a drop condition is met (e.g., violation of Snort rules, blacklisting, failed identity policy), the packet is discarded.

Cisco Secure Firewall’s integration of the Lina and Snort engines provides both high-throughput fast-path processing and deep, context-aware inspection, ensuring robust security without compromising performance. The modular inspection path allows administrators to fine-tune where and how packets are evaluated, providing maximum flexibility in securing complex environments.

 

IPS Traffic Flow in Cisco Secure Firewall

When a packet enters a Cisco Secure Firewall system, it follows a well-defined inspection path beginning with decoding and ending with an Access Control Policy (ACP) decision. Each stage plays a crucial role in either preparing the packet for inspection or enforcing a security outcome.

From Packet Ingress to Preprocessing

The process begins when the packet ingresses to the sensor and is sent to the Decoder. The decoder standardizes the packet format and hands it off to a series of preprocessors, which prepare the data for deeper inspection.

Two common examples of preprocessors are:

  • Frag3: Works at the IP layer to reassemble fragmented packets. This ensures that attackers can’t evade detection by splitting malicious payloads across multiple packet fragments.
  • Stream5: Operates at the TCP layer, rebuilding full TCP streams from individual packets to allow inspection engines to see the full picture, such as a complete HTTP session.

These preprocessors ensure the data is coherent and complete before it’s passed to the Snort engine for rule-based analysis.

 

Security Intelligence Layer

After preprocessing, the next layer is Security Intelligence (SI). This component operates like a dynamic blacklist/whitelist filter. SI checks the packet’s attributes, like source/destination IP, DNS, or URL, against Cisco-maintained threat feeds, which are regularly updated via Cisco Talos. SI decisions are fast and happen before deeper analysis, allowing known-bad traffic to be dropped early for efficiency.

Admins can also define their own custom blocklists and allowlists as part of Security Intelligence. This makes it a powerful front-line filter, reducing the load on deeper inspection engines by preemptively denying known threats.

 

Access Control Policy (ACP)

If the packet passes the SI filter, it moves on to the Access Control Policy (ACP) phase. This is where Secure Firewall evaluates contextual rules that define what actions should be taken on the traffic.

ACP functions similarly to an ACL on traditional firewalls but with far more flexibility and context. It allows matching based on:

  • Source and destination IPs or networks
  • Applications
  • Ports and protocols
  • User identity
  • URL categories
  • Geolocation
  • And more

Once a packet matches an ACP rule, the rule is applied and no further rules are evaluated—just like a traditional firewall rule. Depending on the rule configuration, the action could be to:

  • Allow the traffic and apply an IPS policy
  • Block the traffic outright
  • Trust the traffic (bypass deep inspection)
  • Redirect it for Network Discovery
  • Apply File or Malware Inspection

Here’s a simplified example of an Access Control Policy structure:

  • Rule 1: Allow all traffic from 10.1.0.3 to any destination—no additional inspection applied.
  • Rule 2: Allow traffic to financial apps over port 80 and apply Intrusion Policy 1.
  • Rule 3: Allow traffic to 10.0.0.8 over port 21 with both Intrusion Policy 2 and a File Policy.
  • Default Action: If no rule matches, apply a default behavior like blocking, trusting, applying IPS, or logging for Network Discovery.

This layered model gives Cisco Secure Firewall the ability to inspect traffic intelligently, matching the need for high performance with strong security.