TTechclick ⚡ XP 0% All lessons
Cisco · Secure Firewall · Access ControlInteractive · L1 / L2 / L3

FTD Access Control Policy — Zones, Rules & the Inspection Order

The Access Control Policy is the master policy on an FTD: security zones and rule criteria decide what matches, and rule actions decide what happens. This lesson walks the full inspection order — LINA prefilter, optional decryption, Security Intelligence, the first-match access control rules, then Snort intrusion and file inspection — and the two gotchas that trip everyone up: Trust vs Allow, and a broad rule that shadows a specific one.

📅 2026-06-18 · ⏱ 15 min · 5 infographics · live packet demo · 🏷 10-Q assessment + AI Tutor inline

⚡ Quick Answer

A clear, interactive guide to the Cisco FTD Access Control Policy (2026): security zones and rule anatomy, the rule actions (Block, Allow, Trust, Monitor, Interactive Block), top-down first-match evaluation and the default action, the prefilter policy, and the full inspection order — LINA prefilter to optional TLS decryption to Security Intelligence to access control to Snort intrusion and file inspection.

🎯 By the end you will be able to

Read as:

Pick where you want to start

1

Zones & rule anatomy

Security zones and the rule match criteria.

 2

Rule actions

Block, Allow, Trust, Monitor.

 3

Prefilter & order

The full LINA-to-Snort inspection order.

 4

Order & best practice

Default action, first match, shadowed rules.

🧠 Warm-up — 3 questions, no score

Just notice which ones make you pause. We answer all three inside the lesson.

1. What groups FTD interfaces so you can use them in a rule?

Answered in Zones & rule anatomy.

2. Which action permits traffic but skips deep inspection?

Answered in Rule actions.

3. What runs first, before Snort even sees the packet?

Answered in Prefilter & order.

Most engineers think…

Most people think the FTD access control policy is just a firewall ACL: a list of allow/deny lines, top to bottom, done. That mental model is half-right and it is exactly why people misuse Trust and accidentally shadow their own rules.

The Access Control Policy (ACP) is the master policy on FTD, and it sits inside a bigger pipeline. Before a rule is even evaluated, the prefilter runs in LINA, then optional decryption, then Security Intelligence. Only then do the rules run top-down, first match, and the action you pick — especially Trust vs Allow — decides whether Snort ever inspects the traffic. Understanding that order is what stops you from trusting traffic you meant to inspect.

① Security zones & rule anatomy — what a rule matches on

A security zone groups one or more interfaces — say all the inside interfaces into an INSIDE zone and the internet-facing one into an OUTSIDE zone. Zones are how a rule talks about where traffic comes from and goes to without naming raw interfaces.

An access control rule then matches on a set of criteria: source/destination zones, networks (objects), ports, applications (Layer-7 app identity, not just ports), URLs (category or specific), and users (from identity). A rule can use one criterion or several — all listed criteria must match for the rule to fire.

The interview line: zones plus L3/L4 plus L7 plus identity — an FTD rule is far richer than a classic 5-tuple ACL, which is exactly why the action you attach to it matters so much.

Figure 1 — What an access control rule matches
A single FTD rule can match on zones plus L3/L4 plus L7 application, URL and user identity — far richer than a 5-tuple ACL.What an access control rule matchesACP rulematch criteriaSecurity zonesNetworksPortsApplications (L7)URLsUsers (identity)
A single FTD rule can match on zones plus L3/L4 plus L7 application, URL and user identity — far richer than a 5-tuple ACL.
Quick check · Q1 of 10 · Remember

What is a security zone used for in an access control rule?

Correct: c. A security zone groups one or more interfaces and is used as source/destination match criteria, so a rule can say INSIDE to OUTSIDE without naming raw interfaces. Rules also match on networks, ports, applications, URLs and users.
👉 So far: Security zones group interfaces; an FTD rule matches on zones plus networks, ports, applications, URLs and users — richer than a 5-tuple ACL.

② Rule actions — Block, Allow, Trust, Monitor

The action decides the fate of matched traffic. Block silently drops it; Block with reset drops and sends a TCP reset. Allow permits it and hands it to Snort — so an Allow rule can run an intrusion policy and a file/malware policy for deep inspection. Trust permits the traffic but skips deep inspection entirely — no IPS, no file inspection. Monitor never decides the fate of traffic; it only logs the connection and lets evaluation continue to lower rules. Interactive Block warns the user with a page they can click through.

The gotcha you must name: Trust vs Allow

Both let traffic through, but only Allow inspects. If you Trust traffic you meant to inspect, Snort never sees it — malware or exploits ride straight through. Use Trust only for traffic you are deliberately exempting from inspection (e.g. a trusted high-volume backup), and use Allow with an intrusion policy for anything you actually want protected.

Figure 2 — The rule-action ladder
From hard drop to permit-and-skip — each action decides both the fate of the traffic and whether Snort ever inspects it.The rule-action ladderBlock / Block w/ resetdrop (reset sends TCP RST)Interactive Blockwarn page, user can continueAllowpermit + Snort IPS/fileTrustpermit, skips inspectionMonitorlogs only, never decides
From hard drop to permit-and-skip — each action decides both the fate of the traffic and whether Snort ever inspects it.
🗂️
Security zone
tap to flip

A logical group of interfaces used as source/destination match criteria, so rules say INSIDE→OUTSIDE instead of naming raw interfaces.

✅
Allow vs 🤝 Trust
tap to flip

Allow permits and inspects — it can run intrusion and file policies in Snort. Trust permits but skips deep inspection entirely.

⏩
Prefilter
tap to flip

Runs first in LINA, before Snort: fastpath, block or analyze, plus tunnel rules. Cheap early decisions for traffic that needs no deep inspection.

🛰️
Security Intelligence
tap to flip

Reputation-based IP, URL and DNS blocking from Cisco Talos, applied before the access control rules run.

Allow inspects, Trust does not

Say it cleanly in interviews: Allow permits AND hands traffic to Snort for intrusion and file inspection; Trust permits and skips inspection. If you want IPS or malware checks on a flow, it must be Allow — reserve Trust for traffic you are deliberately exempting.

Quick check · Q2 of 10 · Understand

Which rule action permits traffic but skips intrusion and file inspection?

Correct: b. Trust permits the traffic and skips deep inspection entirely — Snort never sees it. Allow permits and inspects (it can run intrusion and file policies); Monitor only logs and never decides.
👉 So far: Actions: Block / Block-with-reset drop; Allow permits and inspects (IPS + file); Trust permits and skips inspection; Monitor only logs; Interactive Block warns.

③ The prefilter and the full inspection order

Not everything reaches Snort. The Prefilter policy runs first, in the LINA data plane, before deep inspection. Its actions are Fastpath (permit and skip the rest — cheapest), Block, and Analyze (send on to access control / Snort), plus tunnel rules for encapsulated traffic. It exists to make cheap, early decisions on traffic that does not need deep inspection.

The full order, end to end

Trust short-circuits this: a Trust match permits and skips the Snort stage entirely.

Figure 3 — The full FTD inspection order
Prefilter and Security Intelligence make cheap early decisions in LINA before the first-match access control rules hand Allowed traffic to Snort.The full FTD inspection orderPrefilterfastpath / block /analyzeDecryptoptional TLS/SSLSec IntelligenceIP/URL/DNS blockAccess controlfirst match winsSnortIPS + file if Allow
Prefilter and Security Intelligence make cheap early decisions in LINA before the first-match access control rules hand Allowed traffic to Snort.
Figure 4 — Trust vs Allow
Both permit the traffic, but only Allow hands it to Snort — Trust skips intrusion and file inspection entirely.Trust vs AllowTrustPermits the trafficSkips intrusion (IPS)Skips file/malwareUse for deliberate exemptionsAllowPermits the trafficRuns the intrusion policyRuns file/malware policyUse when you want inspection
Both permit the traffic, but only Allow hands it to Snort — Trust skips intrusion and file inspection entirely.
Putting everything in access control rules

A common slip is forcing every decision into Snort-level access control rules. Cheap, high-volume traffic that needs no deep inspection belongs in the prefilter (fastpath) or Security Intelligence — making those early LINA-stage decisions keeps Snort free for traffic that actually needs inspection.

▶ Watch a packet run the access control gauntlet

How one packet is evaluated top-down against the ACP. Press Play for the healthy inspected path, then Break it to see the classic failure.

① PrefilterThe packet reaches LINA; the prefilter sets it to Analyze, so it goes on to deep inspection rather than fastpath.
▼
② Security IntelligenceSI checks the source/destination reputation against Talos — it is clean, so evaluation continues.
▼
③ Match Allow + IPSThe first matching access control rule is an Allow rule with an intrusion policy attached.
▼
④ Snort inspects — forwardSnort runs intrusion and file inspection; the packet is clean and is forwarded out the egress interface.
Press Play to step through the healthy inspected path. Then press Break it.
Quick check · Q3 of 10 · Understand

In the FTD inspection order, what happens first, before Snort?

Correct: a. The prefilter runs first in the LINA data plane — fastpath, block or analyze, plus tunnel rules — before any Snort deep inspection. The order is prefilter, optional decryption, Security Intelligence, access control rules, then Snort.
👉 So far: Order: LINA ingress, prefilter (fastpath/block/analyze), optional decryption, Security Intelligence, first-match access control, then Snort intrusion/file on Allow, then egress.

④ Default action, rule order & best practice

Rules are evaluated top-down, first match wins: the first rule whose criteria all match decides the action, and evaluation stops (Monitor is the exception — it logs and keeps going). Anything that matches no rule falls through to the Default Action at the bottom of the policy.

The shadowing trap

Because it is first-match, a broad rule above a specific one shadows it. Put a wide Trust any-any near the top and the specific Allow-with-IPS rule below it never runs — traffic is trusted and Snort never inspects it. The fix is ordering: specific rules above broad ones.

The interview line: order specific before broad, prefer Allow-with-IPS over Trust for anything you want inspected, and let the default action be an explicit block — not an accident.

Figure 5 — First match, then the default action
Rules are checked top-down; the first full match decides, and anything matching no rule hits the default action.First match, then the default actionRule 1all criteria match?Rule 2…nfirst match wins, stopNo matchfall throughDefault actionexplicit block ideally
Rules are checked top-down; the first full match decides, and anything matching no rule hits the default action.

Arjun at a Chennai SaaS firm faces this

He built an Allow rule with an intrusion policy for traffic to the app servers, but the IPS dashboard shows zero events for that path even under a known test exploit.

Likely cause

A broad Trust any-any rule sits above the specific Allow-with-IPS rule, so the app traffic matches Trust first and bypasses Snort.

Diagnosis

First-match means the higher Trust rule wins; the specific Allow rule is shadowed and never evaluated, so no intrusion inspection ever happens.

FMC ▸ Policies ▸ Access Control ▸ rule order
Fix

Move the specific Allow-with-IPS rule above the broad Trust rule (or scope the Trust narrowly), then deploy.

Verify

Re-run the test exploit — the intrusion dashboard now logs events on that path, confirming Snort is inspecting the Allowed traffic.

Prove order with the rule hit counts

Do not guess which rule a flow hits. Use the rule hit counts and connection events in FMC to see exactly which rule matched. If a specific rule shows zero hits while a broader rule above it climbs, you have found a shadowed rule — fix the order and re-check.

Quick check · Q4 of 10 · Analyze

A broad Trust any-any rule sits above a specific Allow-with-IPS rule. What happens to that specific traffic?

Correct: d. Rules are first-match top-down, so the broad Trust matches first, permits the traffic and skips inspection; the specific Allow-with-IPS rule below it never runs. The fix is to order the specific rule above the broad Trust.
👉 So far: First match wins and falls through to the default action; a broad Trust/Allow above a specific rule shadows it — order specific before broad.

🤖 Ask the AI Tutor

Tap any question — instant, scoped to this lesson. No login, no waiting.

Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.

📝 Wrap-up assessment — six more

You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end.

Q5 · Understand

Which action permits traffic AND allows intrusion and file inspection to run?

Correct: b. Allow permits the traffic and hands it to Snort, so it can run an intrusion policy and a file/malware policy. Trust permits but skips inspection; Monitor only logs; Block with reset drops and sends a TCP reset.
Q6 · Remember

Where in the inspection order does Security Intelligence run?

Correct: c. Security Intelligence does reputation-based IP/URL/DNS blocking via Talos after the prefilter and any decryption, but before the access control rules. The order is prefilter, decrypt, SI, access control, then Snort.
Q7 · Apply

You want cheap, early permit decisions on high-volume traffic that needs no deep inspection. Which mechanism?

Correct: a. Prefilter Fastpath permits traffic and skips the rest of the pipeline in LINA, before Snort — ideal for high-volume flows that need no deep inspection. An Allow-with-IPS rule would send it through Snort instead.
Q8 · Analyze

An Allow-with-IPS rule shows zero hits and traffic on that path is never inspected. Most likely cause?

Correct: d. Rules are first-match top-down. A broad rule above the specific one matches first, so the specific Allow-with-IPS rule never runs and shows zero hits. Re-order specific above broad to restore inspection.
Q9 · Understand

What does the Monitor action do when traffic matches it?

Correct: c. Monitor only logs the connection and lets evaluation continue to lower rules; it never decides the fate of traffic. To permit or drop you need Allow/Trust or Block.
Q10 · Evaluate

An interviewer asks for one best-practice rule for ordering an access control policy. Best answer?

Correct: b. First-match means a broad rule above a specific one shadows it, so order specific before broad. Prefer Allow-with-IPS for anything you want inspected (Trust skips Snort), and make the default action an explicit block rather than an accidental allow.
Lesson complete — saved to your profile.
Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again".

🧠 In your own words

Type one line: why can a broad Trust rule above a specific Allow-with-IPS rule let an exploit through? Then compare with the expert version.

Expert version: Because the access control policy is evaluated top-down, first-match: the first rule whose criteria all match decides the action and evaluation stops. A broad Trust any-any rule placed above the specific Allow-with-IPS rule matches first, so the traffic is permitted and — because Trust skips deep inspection — Snort never runs the intrusion or file policy on it. The specific rule is shadowed and never executes, so an exploit rides straight through. The fix is ordering and action choice: move specific rules above broad ones, scope Trust narrowly, and use Allow-with-IPS for any traffic you actually want inspected.

🗣 Teach a friend

Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.

📖 Glossary

Access Control Policy (ACP)
The master policy on an FTD — an ordered set of rules plus a default action that decides what traffic is allowed, blocked, trusted or monitored.
Security zone
A logical group of one or more interfaces used as source/destination match criteria in access control rules.
Allow
Permits matched traffic and hands it to Snort, so an intrusion policy and a file/malware policy can run on it.
Trust
Permits matched traffic but skips deep inspection entirely — no intrusion or file inspection by Snort.
Monitor
Logs the connection but does not decide the fate of traffic; evaluation continues to lower rules.
Prefilter policy
An early LINA-stage policy that fastpaths, blocks or analyzes traffic (plus tunnel rules) before Snort deep inspection.
Security Intelligence
Reputation-based IP, URL and DNS blocking using Cisco Talos intelligence, applied before the access control rules.
Default action
The catch-all applied to traffic that matches no rule — e.g. block all, or an intrusion-inspected allow.
Shadowed rule
A specific rule placed below a broader one that matches first, so the specific rule never runs under first-match evaluation.

📚 Sources

  1. Cisco — Secure Firewall Management Center Device Configuration Guide: Access Control Policy overview and rules. cisco.com
  2. Cisco — FTD: security zones and interface objects. cisco.com
  3. Cisco — Access control rule actions — Block, Allow, Trust, Monitor and Interactive Block. cisco.com
  4. Cisco — Prefilter policies and tunnel rules (fastpath, block, analyze). cisco.com
  5. Cisco — Secure Firewall: traffic processing / inspection order — LINA, Security Intelligence, access control and Snort. cisco.com
  6. Cisco Talos — Security Intelligence feeds and Snort 3 intrusion rule sets. talosintelligence.com

What's next?

Got the policy and the order? Next, go deep on Snort 3 intrusion policies — rule groups, base policies, the Cisco Talos rule set, and how an Allow rule hands traffic to deep inspection without slowing the LINA data plane.

Next · All interview lessons → Practice on exam.techclick.in →