How to Configure Security Policies on Cisco Firepower Threat Defense (FTD): Complete Guide

The security policy is where FTD actually earns its keep — it’s the rulebook that decides what traffic gets inspected, blocked, logged, or allowed through, and how deeply. Get it wrong and you either leave gaps attackers walk through or you inspect so aggressively that legitimate business traffic grinds to a halt. This guide walks through FTD’s policy architecture from the ground up and shows how to build, tune, and troubleshoot it properly in Firepower Management Center (FMC).

Understanding FTD’s Policy Model

Unlike classic ASA, where policy was largely just ACLs plus NAT, FTD’s policy model is layered and centered around the Access Control Policy (ACP), which acts as the orchestrator for everything else:

Access Control Policy
 ├── Security Intelligence (reputation-based blocking, first line of defense)
 ├── Access Control Rules (the core allow/block/inspect rulebook)
 │     ├── Intrusion Policy (Snort-based IPS inspection)
 │     ├── File Policy (malware/AMP inspection)
 │     └── SSL/TLS Decryption Policy (visibility into encrypted traffic)
 ├── Identity Policy (user-to-IP mapping for identity-aware rules)
 └── Default Action (what happens to traffic matching nothing above)

Traffic hits FTD, gets evaluated by Security Intelligence first (cheap, fast reputation checks), then walks the Access Control rule list top-down, and whichever rule matches first determines the traffic’s fate — including whether it gets handed off to deeper inspection (IPS, file/malware, SSL decryption).

Networking and Protocol Fundamentals Behind the Policy Engine

FTD runs on Snort (Snort 3 in current releases) as its detection engine, sitting behind the Lina data-plane engine inherited from ASA. Understanding this two-engine architecture explains a lot of troubleshooting behavior:

• Lina handles basic packet forwarding, NAT, routing, and the underlying ACL/access-control enforcement.
• Snort handles deep packet inspection — IPS signatures, file inspection, application identification (via Cisco’s OpenAppID/NBAR-based engine), and SSL decryption.

A packet can be permitted at the Lina layer but still dropped by Snort if it matches an intrusion rule — this is why “the ACL allows it but it’s still blocked” is a completely normal and expected FTD behavior, not a bug.

Step 1: Building the Access Control Policy

In FMC: Policies > Access Control > Access Control Policy > New Policy.

Give it a name, assign a default action (Block all traffic is the safer starting default; Network Discovery Only/trust-based defaults exist too but should be deliberate choices, not accidents), and choose a base Intrusion Policy to associate with the default action if you want IPS inspection even on unmatched traffic.

Step 2: Security Intelligence (Reputation Filtering)

Before any rule evaluation, Security Intelligence blocks traffic to/from known-bad IPs, domains, and URLs using Cisco Talos threat intelligence feeds.

Policies > Access Control > Access Control Policy > Security Intelligence tab:

• Add the built-in Talos IP reputation feeds (e.g., “Attackers”, “Bogon”, “Malware”) to the Block list.
• Optionally set feeds to Monitor-only first in a new deployment, to validate false-positive rates before hard-blocking.
• Add custom block/allow lists for known internal exceptions.

This step matters because it stops obviously malicious traffic before it ever consumes Snort inspection cycles — a real performance consideration at scale.

Step 3: Building Access Control Rules

Each rule is built from matching criteria plus an action:

Matching criteria can include:

• Zones (source/destination security zones)
• Networks (source/destination IP/subnet, or Network Objects/Groups)
• Ports/Protocols (or Port Objects)
• Applications (via App-ID — e.g., match “Facebook-Video” specifically, not just port 443)
• URLs (category or reputation-based, e.g., block “Gambling” category)
• Users/Groups (via Identity Policy integration with AD)

Actions:

• Allow — permits and optionally sends to IPS/File/SSL inspection
• Trust — permits without further inspection (performance-friendly for known-safe, high-volume flows like backup traffic)
• Block / Block with reset — drops silently or with a TCP RST
• Monitor — logs only, continues rule evaluation (doesn’t terminate matching)
• Interactive Block — used for HTTP, shows a warning page users can click through

Example: Building a Rule Set

A typical enterprise perimeter policy, top to bottom (order matters — first match wins):

1. Block-Known-Bad — deny traffic from/to Security Intelligence-flagged categories not already covered (belt-and-suspenders explicit rule for visibility in rule hit counts).
2. Allow-Internal-to-DMZ-Web — Source Zone: Inside, Destination Zone: DMZ, Destination Port: 443, Application: HTTPS — Action: Allow, with Intrusion Policy and File Policy attached.
3. Allow-Guest-Internet-Limited — Source Zone: Guest, Destination: Any, Applications: allowed business categories only — Action: Allow with SSL decrypt + IPS.
4. Block-P2P-and-Anonymizers — Application category match — Action: Block with reset.
5. Default Action — Block all traffic, logged.

CLI Verification (via FTD CLI, useful for confirming what got pushed)

> show access-control-config
> show running-config object network DMZ-WEB-SERVERS
> show asp table classify domain permit

Note: FTD policy is primarily managed through FMC, but the underlying Lina CLI (accessible via show commands, and limited configure for platform settings) is invaluable for verification.

Step 4: Intrusion (IPS) Policy

Policies > Intrusion > Create Policy, based on a Cisco-provided base policy such as Balanced Security and Connectivity (a sane default) or Security Over Connectivity (more aggressive, higher false-positive risk).

Attach the Intrusion Policy to individual Access Control rules (not globally by default) so you control exactly which traffic gets IPS-inspected — typically everything crossing a trust boundary, and selectively East-West traffic depending on your segmentation model.

Key tuning tasks:

• Rule state tuning — disable signatures irrelevant to your environment (e.g., IIS-specific signatures if you run no IIS) to reduce noise and processing overhead.
• Suppression and thresholding — suppress known-benign repeat triggers without disabling the rule entirely.
• Variable Sets — define $HOME_NET and $EXTERNAL_NET accurately; this single setting has an outsized effect on both detection accuracy and false-positive rate.

Step 5: File and Malware Policy (AMP)

Policies > Malware & File > New File Policy. Attach to Access Control rules where file transfer visibility matters (typically inbound web/email-adjacent flows, and any DMZ-facing rule).

Configure file type rules per direction (Upload/Download) with actions: Detect, Block, Malware Cloud Lookup (queries Cisco AMP cloud for file disposition), or Block Malware. Enable Dynamic Analysis submission for unknown files where policy allows sending samples to the cloud sandbox.

Step 6: SSL/TLS Decryption Policy

Since the overwhelming majority of traffic today is encrypted, an IPS or file policy that can’t see inside TLS is mostly blind. Policies > Access Control > SSL.

Two decryption approaches:

• Decrypt – Resign — for outbound traffic where FTD acts as a trusted MITM using an internal CA certificate deployed to client trust stores (standard for outbound web browsing inspection).
• Decrypt – Known Key — for inbound traffic to servers you control, where you load the server’s actual private key onto FTD.

! Example consideration, not literal CLI — cert import is done via FMC GUI:
! Objects > PKI > Add Internal CA, then reference it in the SSL Policy decrypt-resign rule

Always build explicit Do Not Decrypt rules for categories with legal/privacy sensitivity (e.g., Financial, Health) and for known certificate-pinned applications that break under MITM decryption (many mobile apps, some Microsoft 365 endpoints per Cisco/Microsoft guidance) before deploying decryption broadly.

Step 7: Identity Policy (User Awareness)

Integrate with Active Directory (via Identity Realms, System > Integration > Realms) and deploy identity rules to map IP-to-user via passive methods (AD agent) or active authentication (captive portal). This enables rules like “Allow Finance-AD-Group to Finance-App-Servers” instead of relying purely on IP subnets, which is far more resilient to DHCP churn and BYOD environments.

Real-World Deployment Workflow

Scenario: Mid-size enterprise deploying FTD at the internet edge, replacing a legacy ASA with basic ACLs.

1. Baseline in Monitor mode — deploy the ACP with rules built but Intrusion Policy set to a monitor-only variant and Security Intelligence in “Monitor” for the first 1–2 weeks. Review Connection Events for what would have been blocked.
2. Tune false positives — adjust App-ID mismatches, whitelist legitimate SaaS traffic misclassified by category.
3. Move to enforcement gradually — flip Security Intelligence to Block, then flip Intrusion Policy rule actions from monitor to drop for high-confidence signature classes first.
4. Layer in SSL decryption last, after the plaintext-visible ruleset is stable, since decryption introduces its own certificate/compatibility troubleshooting surface.
5. Document and version-control policy exports (FMC supports policy export/import) before major changes, enabling rollback.

Common Configuration Mistakes

• Overly broad “Allow Any-Any” rules placed above specific rules, silently shadowing more restrictive rules below them (rule order is first-match, so shadowed rules never fire — FMC’s rule conflict warnings should never be ignored).
• No Intrusion/File Policy attached to Allow rules — an “Allow” action with nothing attached is just a stateful firewall rule, no IPS/AMP value at all.
• Decrypting everything on day one, breaking certificate-pinned apps enterprise-wide and generating a flood of help desk tickets.
• Ignoring Security Intelligence categories that are too broad for the business (e.g., blocking entire cloud-provider IP ranges that also host legitimate SaaS).
• Not tuning $HOME_NET, leaving it as default any, which degrades Snort’s ability to distinguish internal vs. external context for many signatures.
• Policy sprawl — hundreds of rules with no naming convention or grouping, making future troubleshooting and audits painfully slow.

Troubleshooting Security Policy Behavior

Symptom	Diagnostic Approach
Traffic unexpectedly blocked	Check Analysis > Connection Events, filter by source/dest, review “Reason” column (ACP rule name, IPS, SI category, SSL rule)
Traffic that should be blocked is passing	Verify rule order (first match wins) — a broader Allow rule above it is likely shadowing; check Access Control Policy > Show Rule Conflicts
IPS not triggering on known-bad traffic	Confirm Intrusion Policy is actually attached to the matching Access Control rule, not just created; verify rule state isn’t set to “Disabled” in the base policy
SSL decryption breaking specific apps	Check Analysis > Connection Events SSL flow status; add a Do-Not-Decrypt exception by SNI/category for the affected app
High Snort CPU / dropped packets under load	Review rule tuning (too many enabled signatures for traffic volume), verify hardware sizing matches inspected throughput, check show snort3 statistics
Policy deploy fails or hangs in FMC	Check System > Health > Monitor for device connectivity, review deployment job logs under Deploy history for the specific error

CLI-side health check commands on the FTD itself:

> show snort3 statistics
> show asp drop
> show conn count
> system support diagnostic-cli
firepower# show capture

Best Practices Summary

• Build policy in explicit, documented, top-down logic — least-specific rules at the bottom, most-specific and highest-priority exceptions near the top.
• Use objects and object groups (Network Objects, Port Objects, URL Objects) instead of hardcoded values, for maintainability.
• Stage changes through monitor-mode before hard enforcement wherever the business risk of false positives is high.
• Review Connection Events regularly — the policy is a living document, not a set-and-forget artifact.
• Keep Intrusion Policy rule sets tuned to your actual environment rather than running every signature Cisco ships.
• Combine Identity, App-ID, and URL categorization for policy that reflects business intent, not just IP/port tuples.

Frequently Asked Questions

What’s the difference between “Block” and “Block with reset”? “Block” silently drops packets; “Block with reset” sends a TCP RST back to the client, causing the application to fail fast/cleanly instead of hanging on a timeout. Reset is generally friendlier to end-user experience and troubleshooting clarity.

Does every Allow rule need an Intrusion Policy attached? Not strictly, but any Allow rule without one gets zero IPS inspection for that traffic — a deliberate choice for high-trust, high-volume flows (e.g., trusted backup traffic) but usually a mistake if left unattached by default across the board.

Can I use both an Intrusion Policy and File Policy on the same rule? Yes — both are attached independently within an Access Control rule and inspect the same matched traffic in parallel for their respective threat categories.

How do I exempt specific traffic from SSL decryption? Add a “Do Not Decrypt” rule in the SSL policy above the decrypt rule, matching by category, distinguished name, or SNI — commonly used for certificate-pinned apps and privacy-sensitive categories.

Why does FMC warn about rule conflicts? It’s detecting that a rule later in the list can never match because an earlier, broader rule already captures all its traffic — always worth investigating, since it usually indicates unintended shadowing rather than deliberate design.

Summary

FTD’s security policy isn’t one setting — it’s a layered pipeline: Security Intelligence filters the obvious threats cheaply, Access Control Rules make the core allow/block decisions using zones, objects, applications, and identity, and attached Intrusion, File, and SSL policies add depth where you actually need visibility. The engineering discipline that separates a solid FTD deployment from a fragile one is staged rollout (monitor before enforce), disciplined rule ordering, and continuous tuning based on real Connection Event data rather than a policy built once and never revisited.

References

• Cisco Secure Firewall Management Center Configuration Guide — Access Control Policies: https://www.cisco.com/c/en/us/td/docs/security/firepower/index.html
• Cisco Snort 3 Migration and Configuration Guide
• Cisco Talos Intelligence (Security Intelligence feeds): https://talosintelligence.com/
• Cisco Firepower SSL/TLS Decryption Best Practices documentation