# FTD Advanced Inspection — AVC, URL, Malware & TLS Decryption Source: https://ai.techclick.in/blog_cisco_ftd_advanced_threat_inspection Markdown: https://ai.techclick.in/blog_cisco_ftd_advanced_threat_inspection.md Publisher: Techclick Infosec Pvt Ltd A clear, interactive guide to the Snort-powered advanced controls on Cisco Secure Firewall Threat Defense (FTD) in 2026: Application Visibility & Control (AVC) with OpenAppID, URL filtering by category and reputation, Security Intelligence IP/URL/DNS lists, the file & malware policy with Secure Endpoint/Malware Defense cloud lookups, dynamic analysis via Secure Malware Analytics, file disposition and retrospective alerts, and TLS/SSL decryption (decrypt-resign vs decrypt-known-key). FTD Advanced Inspection — AVC, URL, Malware & TLS Decryption student learning map A visual study map for FTD Advanced Inspection — AVC, URL, Malware & TLS Decryption showing learning path, evidence, traps, and practice sequence. TECHCLICK STUDY MAP FTD Advanced Inspection — AVC, URL, Malware &... Cisco · learn the flow, prove with evidence, avoid unsafe shortcuts 1. Start 🎯 By the end you will be able to 2. Understand Pick where you want to start 3. Prove ① Application Visibility &... 4. Practice ② URL filtering & Security... How to use this page First build the mental model, then connect the concept to a realistic production decision. Finish by testing yourself. Techclick Infosec Pvt Ltd | ai.techclick.in | Training Contact: WhatsApp +91 92772 29456 Content-specific feature visual for this lesson: use it as the 60-second map before reading the full detail. 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. - Advanced inspection services around Snort Snort engine advanced inspection AVC (OpenAppID) URL filtering Security Intelligence File & malware TLS decryption 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 443 b) OpenAppID detectors identify the application by behaviour, independent of port c) By dropping all encrypted traffic d) 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. Inspection order — cheap first, deep last Security Intelligence early IP/URL/DNS block lists URL filtering category + reputation AVC identify the application File & malware disposition + sandbox 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 TLS b) Because it replaces the intrusion policy c) Because it is a cheap, high-confidence early drop of known-bad IPs/URLs/domains, saving the deeper engines work d) 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. An HTTPS flow through the inspection stack SI check known-bad? drop early Decrypt resign, see plaintext URL + AVC category + app-id File / malware disposition verdict Allow / block act on the result 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. File disposition and retrospection File seen hash sent to cloud Disposition Malware/Clean/Unknown Dynamic analysis sandbox the unknown Retrospective verdict changes later 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 check The flow's destination IP/URL/domain is checked against Security Intelligence lists first — it is not on a block list, so it continues. ▼ ② Decrypt A decrypt-resign rule applies: the firewall re-signs the cert with the internal CA and decrypts, so Snort can read the plaintext. ▼ ③ URL + AVC URL filtering checks the category/reputation and AVC identifies the application — both now possible because the flow is decrypted. ▼ ④ File / malware The 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 . ▶ Play Next ▶ ⚠ Break it ↺ Reset 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 file b) Nothing — the verdict is fixed at transfer time c) Automatically deletes the file from every endpoint d) 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. Decrypt-resign vs decrypt-known-key Decrypt-resign For outbound user traffic Firewall re-signs the cert Uses an internal CA clients trust Acts as a TLS man-in-the-middle Decrypt-known-key For inbound traffic to your You import the server private key No re-signing needed Decrypts only servers you own 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 key b) No decryption — inspect the ciphertext directly c) Disable HTTPS entirely on the firewall d) 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. What is AVC and why is it better than port-based rules? How does URL filtering work on FTD? What is Security Intelligence and when does it run? How does FTD detect malware in files? What is retrospective malware detection? What is the difference between decrypt-resign and decrypt-known-key? 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 · Remember Which framework does AVC use to identify applications? a) The Lightweight Security Package b) OpenAppID detectors c) HOME_NET variables d) The decrypt-resign CA 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. Q6 · Understand On what basis does FTD URL filtering classify a website? a) Category and reputation, via Talos-fed cloud lookups b) Only the destination port c) The file's hash d) The TCP window size 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. Q7 · Apply You run a public web server and want FTD to inspect inbound HTTPS to it for attacks. Which decryption method? a) Decrypt-resign with an internal CA b) No decryption is possible for inbound traffic c) Block all inbound HTTPS instead d) Decrypt-known-key, importing the server's private key 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. Q8 · Analyze Malware is reaching hosts over HTTPS even though URL, AVC and file policies are all configured. Most likely cause? a) The intrusion base policy is Balanced b) The OpenAppID detectors are out of date c) There is no decryption policy, so the engines only see ciphertext d) Security Intelligence is enabled 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. Q9 · Evaluate An interviewer asks the correct inspection order on Secure Firewall. Best answer? a) File/malware first, then everything else b) Security Intelligence first (cheap, early), then URL/AVC in the access-control rules, then deep intrusion/file inspection c) Decryption only, nothing else needed d) Intrusion rules first, Security Intelligence last 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. Q10 · Understand What does a file 'disposition' of Unknown mean, and why does it matter? a) The file is confirmed safe and needs no further action b) The file was blocked by Security Intelligence c) The cloud has no verdict yet; the file can be sandboxed and later flagged retrospectively if reclassified as malware d) The file is always deleted automatically 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. Submit all answers Try again 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: walk an HTTPS malware download through Secure Firewall and name the one missing control that lets it through. Then compare with the expert version. Compare with expert answer 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. Generate my one-liner 📩 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 → --- Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees. Browse all lessons: https://ai.techclick.in/blogs AI index: https://ai.techclick.in/llms.txt