Cisco Firepower FTD: Access Control Policies, IPS Tuning, and Snort Rule Management

Overview

Cisco Firepower Threat Defense (FTD) is the unified next-generation firewall image that merges the ASA firewall engine with the Sourcefire intrusion prevention system into a single software platform. Before FTD existed, customers had to choose between an ASA (stateful firewall, VPN, NAT) and a separate Sourcefire IPS appliance, or run ASA with FirePOWER Services — a module bolted onto the ASA that ran Sourcefire in a service chain but did not fully integrate the two engines.

FTD eliminates that split. One image, one management plane, one policy — though that management plane is FMC (Firepower Management Center), not ASDM. This is the adjustment that catches most ASA-experienced engineers off guard. ASDM is gone for FTD. All policy, object, and deployment management happens through the FMC web GUI or the FMC REST API.

ASA with FirePOWER Services vs native FTD:

In enterprise environments managing 42-country network security footprints — a scale where consistent policy enforcement is the difference between compliance and exposure — FTD's unified management model is decisive. A single FMC deployment can manage hundreds of FTD sensors globally.

---

FTD Deployment Modes

Routed Mode is the most common deployment. FTD acts as a Layer 3 router and firewall. Interfaces have IP addresses; the device participates in routing (static routes, OSPF, BGP supported). This is the direct replacement for an ASA in routed mode.

Transparent Mode (inline Layer 2) makes FTD a bump-in-the-wire. Data interfaces have no IP addresses; the device is invisible at Layer 3. Traffic passes through without any routing changes required in the network. Useful for inserting security inspection into an existing network without IP re-addressing or routing changes.

Inline Set deploys FTD interfaces as an IPS inline pair — traffic enters one interface and exits the other, inspected by Snort in blocking mode. In IPS-only mode (without full ACP enforcement), this is how FTD acts as a pure next-generation IPS.

Passive Mode connects to a SPAN/mirror port. FTD sees copies of traffic but cannot block anything. Used for monitoring, baselining, and identifying what an IPS policy would block before committing to inline deployment.

High Availability — Active/Standby pairs two FTD units. The active unit handles all traffic; the standby monitors via a dedicated failover link and a state link. The state link synchronizes connection table, NAT translations, and VPN sessions so that failover is stateful — established connections survive a failover event without resetting. FMC manages both units as a single logical device.

---

Diagram 1 — FMC-Managed FTD HA Deployment

---

Policy Processing Order

This is the single most important concept in FTD operations. Traffic entering an FTD interface passes through multiple inspection engines in a fixed sequence. Understanding this order explains why a rule in the Access Control Policy never fires, why IPS doesn't see certain traffic, and why Security Intelligence blocks take precedence over explicit allow rules.

The complete FTD policy processing pipeline:

1. Prefilter Policy — First decision point. Fast-path or block based on Layer 3/4 headers only (no deep inspection). Designed for trusted high-bandwidth traffic (e.g., encrypted backup streams) that should bypass Snort entirely to preserve performance. Rules here use Fastpath (bypass all inspection) or Block (drop before any other processing).

2. SSL Policy — Decides whether to decrypt TLS traffic. If traffic matches a Decrypt-Resign or Decrypt-Known-Key rule, the SSL handshake is intercepted and the payload is decrypted before being passed to subsequent engines. If Do-Not-Decrypt matches, the flow continues as opaque HTTPS.

3. Identity Policy — User identification. FTD queries AD (via ISE or the Firepower User Agent) to map source IPs to usernames. This enables user-based Access Control rules — "allow Marketing to YouTube, block Everyone else."

4. Security Intelligence — IP address, URL, and DNS reputation feeds. Cisco Talos-maintained block lists are evaluated here, before the Access Control Policy. Connections to known C2 servers, malware distribution points, or tor exit nodes are dropped here — the ACP never sees them.

5. Access Control Policy — The main policy. Rules processed top-to-bottom, first match wins. Each rule specifies source/destination zones, networks, applications, URLs, users, ports, and an action. This is where most policy work happens.

6. Intrusion Policy (Snort) — If an ACP rule's action is Allow with an associated Intrusion Policy, matched traffic is passed to the Snort engine for deep packet inspection. Snort evaluates all enabled rules against the traffic stream. Matching rules generate events and can drop the connection.

7. File Policy — If an ACP rule has an associated File Policy, files transferred in the allowed traffic are extracted and inspected. SHA-256 hashes are submitted to the AMP cloud for malware disposition.

8. DNS Policy — DNS sinkhole for malicious domains. Works alongside Security Intelligence DNS feeds.

---

Diagram 2 — FTD Policy Processing Pipeline

---

Access Control Policy

The Access Control Policy (ACP) is the primary policy document in FTD. Every rule is a row in an ordered list — the engine compares each packet/connection against rules from top to bottom and stops at the first match. If no rule matches, the Default Action applies.

Rule components:

Action types explained:

• Allow — Permit the connection. If an Intrusion Policy is attached, traffic passes through Snort. If a File Policy is attached, files are inspected. This is the most common action for legitimate traffic.
• Block — Drop the connection. A TCP reset is sent to both sides. Generates a connection event with block reason.
• Block with Reset — Same as Block, but explicitly sends TCP RST to both endpoints.
• Trust — Permit the connection and bypass all further inspection (no Snort, no File Policy, no SSL decryption). Use this for extremely high-bandwidth trusted traffic (inter-datacenter replication, backup) where inspection overhead is unacceptable and the traffic is genuinely trusted.
• Monitor — Match and log, but continue processing remaining rules. Traffic is not permitted or blocked by this rule — it keeps moving down the list. Used for logging and visibility without affecting traffic.
• Interactive Block — Present a block page with a "click to proceed" option. Used for URL filtering with a warning page.

Example Access Control Policy structure:

Logging configuration: Each rule has logging options: log at connection beginning (generates an event immediately on match), log at connection end (generates event with full byte counts and duration — more useful for analysis). Enable both for critical rules; end-only for high-volume rules to reduce event storage.

---

Intrusion Policy and Snort Engine

The Intrusion Policy is a Snort rule set attached to Access Control Policy rules with an Allow action. When a connection matches an ACP Allow rule that has an intrusion policy, every packet in that flow is passed through the Snort inspection engine.

Cisco-provided base policies (ordered from permissive to strict):

Rule states for individual Snort rules:

• Generate Events — Alert mode. Snort creates an event in the IPS Events log but does not drop the packet. The connection continues.
• Drop and Generate Events — IPS mode. Snort drops the offending packet (or the connection, depending on rule type) and generates an event. This is blocking mode.
• Disabled — Rule is inactive. No evaluation, no events, no performance impact.

The base policy sets the default state for all rules in that policy. A custom intrusion policy starts from a base and then overrides individual rule states.

---

Snort Rule Structure

Snort rules are the detection signatures that the Snort engine evaluates against traffic. Understanding rule syntax is essential for writing custom rules, evaluating Talos rule updates, and understanding why a rule fires (or doesn't).

! Anatomy of a Snort 2 rule:
!
! alert tcp $EXTERNAL_NET any -> $HOME_NET 80 (msg:"ET WEB SQL Injection"; content:"UNION SELECT"; nocase; sid:2001234; rev:3;)
!
! ┌─ action ─────────────────────────────────────────────────────────────────┐
! │  alert   → generate event (in Snort standalone: also log)
! │  drop    → block packet and generate event (IPS inline mode)
! │  pass    → whitelist — stop evaluating further rules for this flow
! └──────────────────────────────────────────────────────────────────────────┘
!
! ┌─ protocol ────────────────────────────────────────────────────────────────┐
! │  tcp / udp / icmp / ip
! └──────────────────────────────────────────────────────────────────────────┘
!
! ┌─ source ──────────────────────────────────────────────────────────────────┐
! │  $EXTERNAL_NET = variable defined in Variable Sets (default: !$HOME_NET)
! │  any           = match any IP
! │  any           = match any source port
! └──────────────────────────────────────────────────────────────────────────┘
!
! ┌─ direction ───────────────────────────────────────────────────────────────┐
! │  ->  = unidirectional (src to dst)
! │  <>  = bidirectional (match either direction)
! └──────────────────────────────────────────────────────────────────────────┘
!
! ┌─ rule options (inside parentheses) ───────────────────────────────────────┐
! │  msg:"..."         → human-readable event description
! │  content:"..."     → byte string to match in payload (case-sensitive)
! │  nocase            → make preceding content match case-insensitive
! │  offset:N          → start content match N bytes into payload
! │  depth:N           → only search first N bytes for this content
! │  pcre:"/.../flags" → Perl-compatible regex match
! │  flow:established  → match only established TCP sessions (not SYN)
! │  sid:NNNNNN        → unique rule ID (Snort ID)
! │  rev:N             → rule revision number
! │  classtype:...     → rule classification category
! └──────────────────────────────────────────────────────────────────────────┘
!
! Example rules:
!
alert tcp $EXTERNAL_NET any -> $HOME_NET 80 (msg:"ET WEB_SERVER SQL Injection UNION SELECT"; content:"UNION"; nocase; content:"SELECT"; nocase; distance:0; flow:established,to_server; sid:2001234; rev:3;)
!
alert udp $HOME_NET any -> any 53 (msg:"ET DNS Query to Known Malware C2 Domain"; content:"|01 00 00 01 00 00 00 00 00 00|"; offset:2; depth:10; content:"badactor"; nocase; sid:9000001; rev:1;)
!
! Custom local rules — add in FMC under:
! Objects → Intrusion Rules → Create Rule
! SID range 1000000–1999999 is reserved for local custom rules

---

Tuning IPS — Reducing False Positives

An untuned IPS is worse than no IPS. Excessive false positives cause alert fatigue, lead engineers to disable rules wholesale, and ultimately create an IPS that no one trusts. Systematic tuning is how production IPS deployments stay effective.

Three tuning mechanisms:

1. Suppress — Permanently silence a rule for specific traffic:

! Suppression: never generate events for this rule on this host
! Configure in FMC: Intrusion Policy → Rules → right-click rule → Add Suppression
!
! Type: Source — suppress when traffic comes FROM this IP
! Type: Destination — suppress when traffic goes TO this IP
! Type: Rule — suppress rule entirely (all traffic — use with caution)
!
! Example: vulnerability scanner generating false SQL injection alerts
! Suppress generator 1, sig_id 2001234, track by_src, ip 10.10.0.50
! → No events generated when the scanner (10.10.0.50) triggers rule 2001234
! → Rule still fires for all other source IPs — surgical suppression

2. Threshold — Rate-limit event generation:

! Threshold: generate event only if rule matches N times in X seconds
! Prevents event floods from single noisy sources
!
! Type: limit   → alert on first N events per interval, suppress rest
! Type: threshold → alert only after N events in interval
! Type: both    → alert after N events, then limit to N per interval
!
! Example: ICMP sweep rule generating thousands of events per minute
! threshold gen_id 1, sig_id 469, type limit, track by_src, count 5, seconds 60
! → Generate at most 5 events per source IP per 60 seconds

3. Variable sets — Correctly define $HOME_NET:

! Variable sets are the most impactful tuning action with least effort
! Most Snort rules distinguish $HOME_NET (internal) from $EXTERNAL_NET
!
! FMC default: $HOME_NET = any (WRONG — disables directional logic)
!
! Correct configuration:
! Objects → Object Management → Variable Sets → Default-Set
!   $HOME_NET    = 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
!   $EXTERNAL_NET = !$HOME_NET
!   $HTTP_SERVERS = [list of internal web servers]
!   $SQL_SERVERS  = [list of internal database servers]
!
! With correct $HOME_NET, rules like "external → internal SQL injection"
! only fire on genuinely inbound attacks, not internal host-to-host traffic

Pass rules — whitelist before IPS rules:

A Snort pass rule matches traffic and stops all further rule evaluation for that flow. In FTD, the equivalent is creating a Prefilter Policy Fastpath rule for trusted traffic, or setting the ACP rule action to Trust (bypasses Snort entirely). For traffic that must pass through Snort but should have specific rules disabled, use suppressions scoped to the relevant IP objects.

---

SSL Inspection Policy

Without SSL inspection, HTTPS traffic is an opaque stream. The Snort engine sees the TCP handshake, the TLS negotiation, and then an encrypted payload it cannot read. An attacker delivering malware over HTTPS, a user exfiltrating data via a personal Google Drive upload, SQL injection through an HTTPS API — all invisible to IPS and file policies without decryption.

Three SSL rule actions:

Decrypt-Resign — Used for outbound corporate traffic (internal users browsing the internet). FTD intercepts the TLS handshake, impersonates the remote server to the client, and re-signs the certificate using an internal CA certificate. The client gets a certificate signed by the corporate CA (which must be trusted by all endpoints). FTD sees decrypted HTTP, Snort inspects it, then re-encrypts and forwards to the real server. Clients with certificate pinning (some mobile apps, some banking apps) will fail — add bypass rules for those applications.

Decrypt-Known-Key — Used for inbound traffic to servers you control. Upload the server's private key to FMC. FTD uses the private key to decrypt the client's session key, inspect the decrypted payload, re-encrypt, and forward. No certificate re-signing — the original server certificate is presented unchanged.

Do Not Decrypt — Explicit bypass. Traffic in this category passes through without decryption. Use for categories where decryption is legally or ethically restricted: financial institutions, healthcare portals, HR SaaS platforms, and any site where the certificate cannot be resigned (certificate pinning, HPKP).

---

Diagram 3 — SSL Decrypt-Resign Flow

SSL inspection and Do-Not-Decrypt categories to always bypass:

---

File Policy and AMP for Networks

A File Policy is attached to an Access Control Policy rule with an Allow action. It inspects files transferred within allowed connections — HTTP downloads, FTP transfers, email attachments via SMTP.

File inspection workflow:

1. FTD reassembles the file from the TCP stream.
2. Calculates SHA-256 hash of the file.
3. Submits hash to the AMP (Advanced Malware Protection) cloud lookup service.
4. AMP returns a disposition: Clean, Malware, Unknown, or Unavailable.
5. If Malware: FTD generates a malware event and (if configured) blocks the transfer.
6. If Unknown: optionally submit to dynamic analysis (Threat Grid sandbox) for behavioral analysis.

Retrospective detection is the capability that distinguishes AMP from simple antivirus hash matching. A file may be allowed at time of transfer because its hash is marked Unknown. Hours or days later, Cisco Talos identifies the file as malware and updates the AMP cloud disposition. AMP for Networks generates a retrospective alert — even though the file was allowed previously, you now have a record of which endpoint received it, at what time, allowing for incident response.

File Policy configuration options:

---

FTD Troubleshooting

FTD provides multiple troubleshooting tools at different layers. The FTD CLI (accessible via FMC → Devices → right-click → CLI) gives packet-level visibility.

Packet Tracer — simulate a packet through the FTD policy stack:

! Packet-tracer simulates a packet through ALL policy stages
! Shows exactly which rule permits or blocks the simulated flow
!
ftd# packet-tracer input inside tcp 10.10.0.50 12345 203.0.113.100 443
!
! Phase 1: ROUTE-LOOKUP — found route via outside
! Phase 2: ACCESS-LIST — matched rule "Allow-Web-Browsing" (Rule ID 5)
! Phase 3: CONN-SETTINGS — default connection settings applied
! Phase 4: IP-OPTIONS — no options
! Phase 5: NAT — dynamic PAT applied, translated to 203.0.113.1:54321
! Phase 6: IP-OPTIONS — post-NAT
! Phase 7: FLOW-CREATION — flow created
! Result: ALLOW
!
! If result is DROP: the phase that shows DROP tells you exactly which
! policy (ACL, NAT, Security Intelligence) is blocking the flow
!
! FMC GUI equivalent: Devices → Packet Tracer (under device management)

Packet Capture — capture real traffic on an interface:

ftd# capture MYCAP interface inside match ip host 10.10.0.50 any
! Captures all traffic to/from 10.10.0.50 on the inside interface
ftd# capture MYCAP interface inside match tcp host 10.10.0.50 host 203.0.113.100
! Narrow capture to specific TCP flow
ftd# show capture MYCAP
! Display captured packets
ftd# show capture MYCAP packet-number 1 dump
! Hex dump of first packet — useful for payload analysis
ftd# no capture MYCAP
! Delete capture when done — captures consume memory

Connection and access-list verification:

ftd# show conn all
! List all active connections through the firewall
! Flags: U=up, I=inbound, O=outbound, E=ESPI, H=HA state sync
ftd# show conn address 10.10.0.50
! Show only connections involving a specific IP
ftd# show access-list
! Show all ACL entries with hit counts
! Hit count incrementing confirms the rule is being matched
! Zero hits on an allow rule = traffic not reaching that rule (blocked earlier?)
ftd# clear access-list counters
! Reset hit counts for clean baseline testing

HA and Snort status:

ftd# show failover
! Shows: Active/Standby state, failover interface status, last failover reason
! "Active unit failed" in history indicates what triggered last failover
ftd# show failover state
! Quick active/standby status with timestamps
ftd# show snort statistics
! Snort engine stats: packets processed, dropped, bypassed
! High bypass count = Snort falling behind, consider performance tuning
ftd# show snort counters
! Detailed Snort internal counters — useful when Snort restart is suspected
!
! WARNING: Snort restarts (triggered by policy deployment) cause a traffic
! outage on the inspected flows. In FTD 6.3+, Snort restarts are hitless
! for most deployments, but verify your version before production deployments.
! Check: show snort counters | include restart

System support trace — live debug per flow:

ftd# system support trace
! Interactive trace — enter source IP, dest IP, protocol, ports
! FTD generates verbose per-packet debug for the next matching flow
! Shows each policy engine's decision in real time
! Press Ctrl+C to stop — extremely verbose output, use narrowly

Common FTD issues and resolutions:

---

Summary

FTD's policy stack rewards engineers who understand the processing order end to end. Security Intelligence runs before the ACP — meaning Talos intelligence feeds block the most egregious threats before any rule is evaluated. Snort only sees traffic that the ACP explicitly Allows with an attached Intrusion Policy — Trust rules are a performance optimization that also disables all inspection, so use Trust deliberately. SSL inspection is the force multiplier that makes IPS and file policies meaningful against modern HTTPS-dominant traffic patterns, but it requires a carefully managed certificate deployment and Do-Not-Decrypt bypass list for pinned applications.

In a multi-country enterprise environment, these are not theoretical considerations — they are the operational decisions that determine whether a 3 AM malware alert is caught by the IPS or passes uninspected through an untuned policy. Systematic tuning, correct variable set configuration, and a disciplined rule ordering strategy are what separate a functional FTD deployment from one that provides genuine security value.