Which framework does AVC use to identify applications?

Correct: b. AVC uses OpenAppID detectors — behavioural fingerprints that identify thousands of applications independent of port. The LSP is the Talos intrusion rule package; HOME_NET is an intrusion variable; the CA is for decryption.

On what basis does FTD URL filtering classify a website?

Correct: a. URL filtering classifies sites by category (e.g. Gambling) and reputation/risk, using Talos-fed cloud lookups, matched inside access-control rules. Ports, file hashes and TCP fields are unrelated to URL classification.

You run a public web server and want FTD to inspect inbound HTTPS to it for attacks. Which decryption method?

Correct: d. Decrypt-known-key is the inbound method for servers you own: you import the server's private key so the firewall can decrypt the traffic without re-signing. Decrypt-resign is for outbound user traffic, not inbound to your own server.

Malware is reaching hosts over HTTPS even though URL, AVC and file policies are all configured. Most likely cause?

Correct: c. Without a TLS/SSL decryption policy, every advanced engine sees only encrypted bytes and cannot inspect the payload, so malware inside HTTPS slips through. The fix is a decrypt-resign rule so Snort can see inside the TLS session.

An interviewer asks the correct inspection order on Secure Firewall. Best answer?

Correct: b. Cheap, high-confidence blocks run first: Security Intelligence drops known-bad IPs/URLs/domains early; URL and AVC act inside the access-control rules; the deepest, most expensive intrusion and file/malware inspection run last on what survives.

What does a file 'disposition' of Unknown mean, and why does it matter?

Correct: c. Disposition is the file's verdict: Malware, Clean or Unknown. Unknown means the cloud has no verdict yet — the file can be sent for dynamic analysis, and if Talos later reclassifies the hash as malware, a retrospective alert names the hosts that already received it.

FTD Advanced Inspection: AVC, URL Filtering, Security Intelligence, Malware & TLS Decryption (2026)

Q: How does AVC block BitTorrent even when it runs over port 443?

Correct: b. AVC uses OpenAppID behavioural detectors to identify the actual application regardless of the port it uses, so you can block BitTorrent by name without blocking port 443 wholesale. Port-based rules are trivially bypassed.

Q: Why is Security Intelligence placed before the access-control rules?

Correct: c. SI is the cheap, early filter: dropping known-bad IPs/URLs/domains (from Talos feeds) before the access-control rules costs almost nothing and stops bad traffic from ever reaching the deeper, more expensive engines.

Q: A file was allowed as Unknown yesterday; today Talos reclassifies its hash as malware. What does FTD do?

Correct: a. Retrospection is the killer feature: when a previously Unknown/Clean hash is later judged malware, FTD raises a retrospective alert identifying exactly which hosts received it, so you can hunt it down even though it slipped past at the time.

Q: You need to inspect employees' outbound HTTPS to the internet for malware. Which decryption method fits?

Correct: d. Decrypt-resign is the outbound method: the firewall acts as a TLS man-in-the-middle, re-signing the server certificate with an internal CA your managed clients already trust, so it can decrypt and inspect user-to-internet traffic. Known-key is for inbound traffic to servers you own.

Most engineers think…

Most people think a next-gen firewall 'just sees everything' on the wire. In 2026, with the vast majority of traffic encrypted, that assumption is exactly how malware gets in.

Cisco Secure Firewall does layer powerful Snort-powered controls onto the access-control policy — AVC to identify apps by behaviour not port, URL filtering by category and reputation, Security Intelligence to drop known-bad IPs/URLs/domains early, and a file & malware policy backed by the Secure Endpoint cloud. But none of it sees inside TLS unless you add a decryption policy. Understanding which control runs when — and why decrypt-resign vs decrypt-known-key matters — is what turns a blind firewall into one that actually inspects modern traffic.

① Application Visibility & Control (AVC) — apps, not ports

The single most important idea here: a modern firewall must control traffic by application, not by port number. Almost everything rides over 443 today, so 'block port 6881' no longer stops BitTorrent. AVC solves this.

AVC uses OpenAppID detectors — behavioural fingerprints that identify thousands of applications regardless of the port they use. Snort watches how a flow behaves and labels it, so you can write rules like allow Office365, block BitTorrent, throttle streaming by name.

Why it matters

Port-based rules are trivially bypassed; app-based rules follow the application wherever it hides. AVC also feeds visibility — you see which apps and how much, per user — which is the basis for sane policy. The catch: if the traffic is encrypted and undecrypted, AVC's view is limited, which is why decryption (Section 4) matters so much.

Figure 1 — Advanced inspection services around Snort

Snort powers a stack of advanced controls layered onto the access-control policy.

Say 'apps, not ports' in interviews

Lead with the AVC value proposition: a modern firewall controls traffic by application using OpenAppID, not by port. 'Allow Office365, block BitTorrent, throttle streaming' is policy that follows the app wherever it hides — far stronger than a port-based ACL anyone can bypass.

Quick check · Q1 of 10 · Understand

How does AVC block BitTorrent even when it runs over port 443?

a) By blocking all of port 443b) OpenAppID detectors identify the application by behaviour, independent of portc) By dropping all encrypted trafficd) Only the Security Intelligence list can do it

Correct: b. AVC uses OpenAppID behavioural detectors to identify the actual application regardless of the port it uses, so you can block BitTorrent by name without blocking port 443 wholesale. Port-based rules are trivially bypassed.

👉 So far: AVC uses OpenAppID to identify thousands of apps by behaviour, independent of port — so you write rules per-app (allow Office365, block BitTorrent), not per-port.

② URL filtering & Security Intelligence — category, reputation & early blocking

Two controls work on where traffic is going. URL filtering classifies sites by category and reputation — Talos-fed cloud lookups — so a rule can block the Gambling category or anything with a poor reputation score, used directly inside access-control rules.

Security Intelligence (SI) is the cheap, early filter. It uses Talos feeds of known-bad IPs, URLs and DNS domains (plus your own lists) to block or allow traffic before the access-control rules even run. Dropping a known C2 IP at SI costs almost nothing and saves the deeper engines from ever touching it.

Order matters

The interview line: SI is first and cheapest, URL/AVC come inside the access-control rules, and intrusion/file inspection are deepest and most expensive. Putting the cheap, high-confidence blocks first is what keeps a busy firewall fast.

Figure 2 — Inspection order — cheap first, deep last

Security Intelligence runs first and cheapest; file/malware inspection is deepest and most expensive.

🧬

AVC / OpenAppID

tap to flip

Identifies thousands of applications by behaviour, independent of port — so you write rules per-app (allow Office365, block BitTorrent), not per-port.

🌐

URL filtering

tap to flip

Classifies sites by category and reputation via Talos-fed cloud lookups, used inside access-control rules to block risky or unwanted destinations.

🛡️

Security Intelligence

tap to flip

Early, cheap block/allow lists for known-bad IPs, URLs and DNS domains from Talos — runs before the access-control rules to drop bad traffic fast.

🦠

Malware Defense

tap to flip

File fingerprints go to the Secure Endpoint (AMP) cloud for a disposition; unknowns can be sandboxed, and retrospective alerts fire if a verdict changes later.

Treating Security Intelligence like the intrusion policy

SI is not deep inspection. It is an early, cheap block/allow of known-bad IPs, URLs and DNS domains that runs before the access-control rules. Confusing it with the intrusion policy (which runs Snort rules on allowed flows) is a classic Secure Firewall interview slip — keep the order straight.

Quick check · Q2 of 10 · Analyze

Why is Security Intelligence placed before the access-control rules?

a) Because it can decrypt TLSb) Because it replaces the intrusion policyc) Because it is a cheap, high-confidence early drop of known-bad IPs/URLs/domains, saving the deeper engines workd) Because it identifies applications by behaviour

Correct: c. SI is the cheap, early filter: dropping known-bad IPs/URLs/domains (from Talos feeds) before the access-control rules costs almost nothing and stops bad traffic from ever reaching the deeper, more expensive engines.

👉 So far: URL filtering blocks by category + reputation inside access-control rules; Security Intelligence drops known-bad IPs/URLs/domains early and cheaply, before the rules run.

③ File control & malware — Secure Endpoint, disposition & retrospection

The file & malware policy does two jobs. File control blocks or logs files by type (e.g. block executables from the internet). Malware detection sends a file's fingerprint to the Secure Endpoint / Malware Defense (AMP) cloud for a verdict, with local and SPERO heuristics for files the cloud has not seen.

Each file gets a disposition — Malware, Clean or Unknown. Truly unknown files can be sent for dynamic analysis (Secure Malware Analytics / Threat Grid) — detonated in a sandbox to see what they do.

Retrospection — the killer feature

A file allowed today as Unknown can be re-judged later. If Talos reclassifies that hash as malware, FTD raises a retrospective alert telling you exactly which hosts already received it — so you can hunt it down even though it slipped past at the moment of transfer.

Figure 3 — An HTTPS flow through the inspection stack

SI checks first, then decrypt, then URL, AVC and file/malware before an allow or block.

Figure 4 — File disposition and retrospection

A file gets a verdict now; if Talos changes its mind later, a retrospective alert names the hosts.

▶ Watch an HTTPS download get inspected end-to-end

How one encrypted flow passes SI, decryption, URL, AVC and malware inspection. Press Play for the healthy path, then Break it to see the classic blind spot.

① SI checkThe flow's destination IP/URL/domain is checked against Security Intelligence lists first — it is not on a block list, so it continues.

▼

② DecryptA decrypt-resign rule applies: the firewall re-signs the cert with the internal CA and decrypts, so Snort can read the plaintext.

▼

③ URL + AVCURL filtering checks the category/reputation and AVC identifies the application — both now possible because the flow is decrypted.

▼

④ File / malwareThe downloaded file is fingerprinted to the Secure Endpoint cloud; the disposition comes back Malware, so it is blocked and logged.

Press Play to step through the healthy inspection path. Then press Break it.

Quick check · Q3 of 10 · Understand

A file was allowed as Unknown yesterday; today Talos reclassifies its hash as malware. What does FTD do?

a) Raises a retrospective alert naming the hosts that already received the fileb) Nothing — the verdict is fixed at transfer timec) Automatically deletes the file from every endpointd) Re-downloads the file to re-scan it

Correct: a. Retrospection is the killer feature: when a previously Unknown/Clean hash is later judged malware, FTD raises a retrospective alert identifying exactly which hosts received it, so you can hunt it down even though it slipped past at the time.

👉 So far: The file & malware policy gives each file a disposition (Malware/Clean/Unknown) via the Secure Endpoint cloud, sandboxes unknowns, and raises retrospective alerts when a verdict changes.

④ TLS/SSL decryption — decrypt-resign vs decrypt-known-key

Everything above is blind inside encrypted traffic. The TLS/SSL decryption (Decryption / SSL) policy is what lets Snort see inside HTTPS — because threats hide in TLS.

There are two main methods. Decrypt-resign is for outbound traffic (your users to the internet): the firewall re-signs the certificate with an internal CA your clients trust, so it can read the flow. Decrypt-known-key is for inbound traffic to servers you own — you load the server's private key so the firewall can decrypt without re-signing.

Decrypt with judgement

You decrypt so URL, AVC and malware inspection actually work. But you bypass sensitive categories — banking, healthcare — for privacy and compliance. The interview line: resign outbound, known-key inbound, and bypass what you must not read.

Figure 5 — Decrypt-resign vs decrypt-known-key

Resign for outbound user traffic; known-key for inbound traffic to servers you own.

Arjun at a Chennai logistics firm faces this

A user's laptop is compromised by malware downloaded over HTTPS, yet the firewall's URL, AVC and file/malware policies all show the flow as clean and allowed.

Likely cause

There is no TLS/SSL decryption policy, so every advanced engine only ever saw ciphertext and could not inspect the actual download.

Diagnosis

Check the Decryption policy — it is empty; the file was delivered inside TLS, so URL filtering, AVC and the malware policy never saw the real payload.

FMC ▸ Policies ▸ Access Control ▸ Decryption (SSL)

Fix

Add a decrypt-resign rule for outbound user traffic using an internal CA pushed to the managed clients, bypassing sensitive categories like banking and healthcare, then re-deploy.

Verify

Re-test the download: the file is now decrypted, fingerprinted, the malware disposition is returned and the transfer is blocked with a logged event.

Prove decryption is actually happening

Do not assume the decryption policy works — confirm it. Browse an outbound HTTPS site through the firewall and check the connection events show the flow as decrypted (and the cert presented to the client is re-signed by your internal CA). If it still shows encrypted, your decrypt-resign rule or the client CA trust is misconfigured.

Quick check · Q4 of 10 · Apply

You need to inspect employees' outbound HTTPS to the internet for malware. Which decryption method fits?

a) Decrypt-known-key, importing each website's private keyb) No decryption — inspect the ciphertext directlyc) Disable HTTPS entirely on the firewalld) Decrypt-resign, where the firewall re-signs with an internal CA the clients trust

Correct: d. Decrypt-resign is the outbound method: the firewall acts as a TLS man-in-the-middle, re-signing the server certificate with an internal CA your managed clients already trust, so it can decrypt and inspect user-to-internet traffic. Known-key is for inbound traffic to servers you own.

👉 So far: TLS/SSL decryption is required for the rest to work: decrypt-resign outbound (internal CA), decrypt-known-key inbound (server key), and bypass sensitive categories like banking/health.

🤖 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.

🧠 In your own words

Type one line: walk an HTTPS malware download through Secure Firewall and name the one missing control that lets it through. Then compare with the expert version.

Expert version: Security Intelligence checks the destination IP/URL/domain first and lets it pass (not on a block list); a decrypt-resign rule re-signs the cert with the internal CA so Snort can read the plaintext; URL filtering scores the category/reputation, AVC identifies the application, and the file/malware policy fingerprints the download to the Secure Endpoint cloud, returns a Malware disposition and blocks it — with a retrospective alert if the verdict only arrives later. The one missing control that lets malware through is the decryption policy: with no decrypt-resign rule the flow stays encrypted, every engine sees only ciphertext, and the malicious file is invisible until it reaches the host.

🗣 Teach a friend

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

📩 Quiz me on this in 7 days. Opt in and we'll email 3 micro-questions on Cisco FTD & FMC at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time.

📖 Glossary

AVC (Application Visibility & Control): Snort identifies the application behind a flow by behaviour, independent of port, so you write policy per-app rather than per-port.
OpenAppID: Cisco's open application-detection framework; detectors fingerprint thousands of apps by behaviour and signatures, regardless of the port used.
URL filtering: Classification of destinations by category and reputation via Talos-fed cloud lookups, matched inside access-control rules to block or allow sites.
Security Intelligence (SI): Early block/allow lists of known-bad IPs, URLs and DNS domains (Talos-fed plus custom) that run before the access-control rules — cheap and fast.
Secure Endpoint / Malware Defense (AMP): The Cisco cloud that returns a malware verdict for a file by its hash; formerly Advanced Malware Protection (AMP).
File disposition: The verdict assigned to a file — Malware, Clean or Unknown — which drives the action FTD takes on the transfer.
Retrospective detection: When a previously Unknown/Clean file hash is later reclassified as malware, FTD alerts on the hosts that already received it.
Secure Malware Analytics (Threat Grid): Dynamic analysis: unknown files are detonated in a sandbox to observe behaviour and reach a verdict.
Decrypt-resign: Outbound TLS decryption where the firewall re-signs the server cert with an internal CA the clients trust, acting as a man-in-the-middle.
Decrypt-known-key: Inbound TLS decryption for servers you own; you import the server's private key so the firewall can decrypt without re-signing.

📚 Sources

Cisco — Secure Firewall Management Center Device Configuration Guide: Application Detection (AVC) and OpenAppID. cisco.com
Cisco — URL Filtering and Security Intelligence on Secure Firewall Threat Defense. cisco.com
Cisco — File policies and Malware Defense (Secure Endpoint / AMP) on FTD: disposition & retrospection. cisco.com
Cisco — Secure Malware Analytics (Threat Grid) dynamic file analysis. cisco.com
Cisco — TLS/SSL Decryption policy: decrypt-resign vs decrypt-known-key. cisco.com
Cisco Talos — URL and IP reputation, categories and threat-intelligence feeds. talosintelligence.com

What's next?

Got the advanced inspection stack? Next, go deep on Cisco Secure Firewall deployment and high availability — routed vs transparent mode, clustering, failover pairs and how FMC pushes policy to many devices at scale.

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

FTD Advanced Inspection — AVC, URL, Malware & TLS Decryption

🎯 By the end you will be able to

Pick where you want to start

AVC

URL & SI

File & malware

TLS decryption

① Application Visibility & Control (AVC) — apps, not ports

Why it matters

② URL filtering & Security Intelligence — category, reputation & early blocking

Order matters

③ File control & malware — Secure Endpoint, disposition & retrospection

Retrospection — the killer feature

▶ Watch an HTTPS download get inspected end-to-end

④ TLS/SSL decryption — decrypt-resign vs decrypt-known-key

Decrypt with judgement

🤖 Ask the AI Tutor

📝 Wrap-up assessment — six more

🧠 In your own words

🗣 Teach a friend

📖 Glossary

📚 Sources

What's next?