Introduction

In an increasingly complex and evolving cyber threat landscape, a single point of defense is no longer sufficient. The principle of 'Defense in Depth'—a cybersecurity strategy employing multiple, overlapping security controls—is crucial for robust protection. This document provides a detailed overview of the extensive threat capabilities inherent in Cisco Secure Firewall. By leveraging world-class threat intelligence from Talos and AMP Cloud, Cisco Secure Firewall implements a sophisticated, multi-layered security architecture designed to detect, prevent, and mitigate a wide spectrum of cyberattacks, ensuring comprehensive network resilience.

The layers of threat protection covered in the document are listed below:

Before we delve into each of these layers, it is important to know the sources where the security feeds come from.

Talos

Talos is Cisco’s threat intelligence research organization, an elite group of security experts devoted to providing superior protections for our customers, products and services. It is a proven, global team with industry-leading expertise across the attack chain, including an incident response team that offers trusted proactive and reactive services. Cisco Talos:

• Analyzes 886 billion security events per day (from over 46 million devices globally across 193 countries and regions)
• Blocks 9 million malicious emails every hour
• Analyzes 2000 new samples every minute and
• Blocks 2000 malicious domains per second.

Talos collects data from web requests, emails, malware samples, open-source data sets, endpoint intelligence, and network intrusions, and maintains the official rule sets of Snort.org.

The threat-related updates that the firewall receives from Talos are:

• Security Intelligence feeds - Reputation intelligence to quickly block connections to or from IP addresses, URLs, and domain names
• URL categories and reputation - Controlling access to websites based on the URL’s general classification and risk level
• Intrusion Rules – Rules to inspect reassembled packets for attack string (or pattern) matches.

More details on Talos:

Talos 2024 Year in Review
Talos Services

AMP Cloud

The Advanced Malware Protection (AMP) cloud is a Cisco-hosted cloud service that uses big data analytics and continuous analysis to provide intelligence that the system uses to detect and block malware on your network.

The AMP cloud provides dispositions for possible malware detected in network traffic by managed devices, as well as data updates for local malware analysis and file pre-classification. As the firewall system identifies files transmitted through network traffic that do not have a known disposition, the firewall system submits SHA-256 lookups as well as Spero signature lookups for the unknown files, receiving disposition results from the AMP cloud.

Cisco offers the following options for obtaining data from the Cisco cloud about known malware threats:

AMP public cloud

Here, the Firewall Management Center, which manages Cisco Secure Firewalls, communicates directly with the AMP public cloud. There are three public AMP clouds in the United States, Europe, and Asia.

AMP private cloud

An AMP private cloud is deployed on your network and acts as a compressed, on-premises AMP cloud. Privacy sensitive customers deploy AMP private cloud as all the functions are deployed internally.

Dynamic Analysis Cloud

The firewall will perform on-box analysis to identify files in network traffic and their characteristics. As files are identified that could have malicious characteristics (e.g. an office doc with a macro enabled, as opposed to an office doc with no macro), the firewall will submit the full file to the Dynamic Analysis Cloud. The Dynamic Analysis Cloud will perform a full sandbox analysis of the file and return a threat score to the firewall. A full report of the sandbox analysis is available in the Dynamic Analysis Cloud.

Two options exist for deploying Dynamic Analysis Cloud:

• Secure Malware Analytics Cloud
• On-premises Secure Malware Analytics Appliance

If your organization's security policy does not allow the system to send files outside of your network, you can deploy an on-premises appliance. This appliance does not contact the public Secure Malware Analytics Cloud.

The list of file types eligible for Dynamic Analysis is determined by the vulnerability database (VDB), which is updated periodically.

Let's now explore how different types of attacks are mitigated by the firewall through the Snort engine, with examples.

Security Layers

Security Intelligence (DNS)

What is Security Intelligence (DNS)?

This is a list of known-bad domains. The intelligence comes from Talos Feeds with multiple categories, which are updated multiple times a day. The feed is titled “Cisco-DNS-and-URL-Intelligence-Feed” under Objects > Security Intelligence > DNS Lists and Feeds. It is a system-provided feed that cannot be deleted. However, you can change the frequency of its update (default is 2 hours) or disable the update altogether.

You can also configure customer-defined lists and feeds.

The configuration for DNS Security Intelligence is done via the DNS policy, which is linked to the Access Control policy as shown below. Clicking on the Edit icon takes you to the DNS policy wherein you can add DNS rules.

Scenario:

Client sitting behind a Cisco firewall is reaching out to a domain name that is blocklisted by Security Intelligence.

Traffic Flow:

Client is opening a webpage that has Security Intelligence (SI) blocklisted domain name.

DNS request is first sent to get the domain name resolved to an IP address. Firewall scans the domain name being requested in the DNS request packet and since it belongs to the list of malicious domain names, the traffic is immediately blocked by the firewall. This stage requires the DNS packet to pass through the firewall.

In addition to Security Intelligence feeds on the firewall for domain names, we can have a second layer of defense by integrating Umbrella. Cisco Umbrella DNS Connection in the management center helps to redirect DNS queries to Cisco Umbrella. This allows Cisco Umbrella to validate requests, allow or block them based on the domain names, and apply DNS-based security policy on the request. Cisco Umbrella DNS Security augments the Security Intelligence (SI) based DNS Security. Thus, it provides two lines of protection. If the Firewall SI DNS policy blocks or drops a DNS request, the request is not forwarded to Cisco Umbrella.

Secure Firewall Management Center fetches the Umbrella DNS Policy from the associated Umbrella tenant and shows it as an additional DNS policy in the Security Intelligence settings. Any changes to the Umbrella policy on the Umbrella tenant are synchronized to the Firewall Management Center. When redirecting DNS requests to Cisco Umbrella, the Umbrella Connector running on the Secure Firewall adds an EDNS (Extension for DNS) record containing its identification info. The Umbrella Cloud uses this info to ensure that it forwards the request to the correct Umbrella tenant and applies the appropriate policy.

For an Umbrella "blocked" connection, Umbrella responds with a block page IP address, and the block logs would be seen on Umbrella and not under the firewall event logs.

License required:

IPS
Umbrella DNS Essentials at the minimum (if using Umbrella).
Refer to Umbrella packages for more details on Umbrella/SSE licenses.

Security Intelligence (IP)

What is Security Intelligence (IP)?

This is a list of known bad IPs. The intelligence comes from Talos Feeds with multiple categories which are updated multiple times a day. The feed is titled as “Cisco-Intelligence-Feed” under Objects > Security Intelligence > Network Lists and Feeds. It is a system-provided feed that cannot be deleted. However, you can change the frequency of its update (default is 2 hours) or disable the update altogether.

You can also configure customer-defined lists and feeds.

Customers can also manually add IP addresses to a Global Block List for similar effects. This can be initiated directly from Firewall Management Center's event viewers and dashboards. Any IP can be immediately blocked from event viewers and dashboards by a simple right click action. In this case, the next packet going through the firewall to the blocked IP, either belonging to the same session or a new session, will get blocked.

The configuration for Security Intelligence networks is done under the Access Control Policy.

Scenario:

Client sitting behind a Cisco firewall is reaching out to an IP address that is blocklisted by Security Intelligence.

Traffic Flow:

Client is opening a webpage that gets resolved to a Security Intelligence (SI) blacklisted IP address. The Client initiates the TCP handshake to the resolved IP address and the block happens at Packet 1 itself which implies an immediate detection and block.

License required:

IPS

Security Intelligence (URL)

What is Security Intelligence (URL)?

This is a list of known bad URLs. The intelligence comes from Talos Feeds with multiple categories which are updated multiple times a day. The feed is titled as “Cisco-DNS-and-URL-Intelligence-Feed” under Objects > Security Intelligence > DNS Lists and Feeds. It is a system-provided feed that cannot be deleted. However, you can change the frequency of its update (default is 2 hours) or disable the update altogether.

You can also configure customer-defined lists and feeds.

Customers can also manually add URL addresses to a Global Block List for similar effect. This can be initiated directly from Firewall Management Center's event viewers and dashboards.
Any URL can be immediately blocked from event viewers and dashboards by a simple right click action. In this case, the next packet going through the firewall to the blocked URL, either belonging to the same session or a new session, will get blocked. The Talos-provided URLs are all domain-level entries; hence, the blocks occur at the Client/Server Hello phase. However, if the customer defined lists and feeds have full URL paths, the blocks might occur at the HTTP GET phase (if seen by the firewall).

The configuration of Security Intelligence URLs is done under Access Control Policy.

Scenario:

Client sitting behind a Cisco firewall is reaching out to a URL that is blacklisted by Security Intelligence.

Traffic Flow:

Client is opening a webpage that has a Security Intelligence (SI) blacklisted URL. Post the TCP handshake, the Client Hello packet is sent which gets blocked by the Firewall. The client packet has a Server Name Indication (SNI) field which is required to indicate the server which SSL/TLS certificate is to be selected for completing the SSL handshake. This SNI field is being used to detect the URL the client is attempting to access.

License required:

IPS

Threat Intelligence Director (TID)

TID feeds exist for IP, URL, Domain and SHA256. These are the feeds that come from third party apps like ThreatQ, Infoblox, AlienVault, etc.

TID gives an open environment that will take in these feeds, parse the data down into understandable / usable indicators and then feed them into FTD. There we can monitor, allow, or block based on these non-Cisco feeds. With both Security Intelligence and threat intelligence director, you can import threat intelligence into the system by either manually uploading flat files or configuring the system to retrieve flat files from a third-party host. The Threat Intelligence Director provides increased flexibility in managing flat files.

One of the leading technology sets that assist in this integration is the adoption of STIX (Structured Threat Information eXpression) and TAXII (Trusted Automated eXchange Intelligence Information). These are well defined standards that direct how information is packaged up and how it is to be shared or delivered.

The configuration of TID is done under Integration > Intelligence > sources on the FMC.

License required:

IPS (For IPv4, IPv6, URL, and DNS detection and observables)
Malware Defense (For SHA-256 detection and observables)

Encrypted Visibility Engine (EVE)

What is EVE?

Encrypted Visibility engine provides insights into encrypted traffic, specifically TLS/SSL traffic, without decrypting it. This advanced approach of providing smart visibility is crucial for detecting threats that are hidden inside encrypted traffic without compromising privacy & performance. EVE leverages machine-learning-based technology that analyses encrypted traffic metadata to identify and classify applications, detect malicious traffic, and enforce security policies without the need for TLS/SSL proxy in Firewalls. These insights into encrypted sessions are obtained by Cisco's open-source Mercury library that is packaged in Cisco's vulnerability database (VDB). The library analyzes incoming encrypted sessions and matches it against a set of known fingerprints. This database of known fingerprints is available in the Cisco VDB. EVE Database is built from 120,000 Secure Client endpoints every day, from over 30 DCs around the globe collecting 1B TLS fingerprints daily and from 10,000 samples sandboxed by Secure Malware Analytics every day.

EVE generates fingerprint string by extracting and concatenating selected bytes from network packets to uniquely identify protocol behaviors. For example, a TLS fingerprint is created by analyzing the Client Hello message and extracting key attributes such as the TLS version, cipher suites, extensions, and their respective values. This fingerprint string, combined with additional destination context-such as the destination IP address, port, and server information, is then used as input to the classifier for further analysis. EVE supports other protocols, for example, QUIC and HTTP as well. HTTP fingerprints are computed from HTTP request packets, and QIUC fingerprints are computed from the QUIC Initial Packet. EVE can also fingerprint Encrypted Client Hello packets by looking into the outer client hello.

EVE is configured under the Advanced settings of the Access Control policy.

Scenario:

A compromised client connecting to a Command-and-Control(C2) Server on the Internet through the firewall. A malicious piece of code gets installed on a client machine, after which, the client creates an encrypted channel with the Command-and-Control server with symmetric/asymmetric cryptography.

Traffic Flow:

The Client initiates the TCP handshake to the resolved IP address which is a C2 server starting with SYN and SYN ACK from the Server to the Client. The TCP handshake ends with ACK from the client to the server. The SSL/TLS handshake is initiated with Client Hello from the Client wherein the clear text fields are read by the EVE engine and traffic is blocked.

License required:

IPS

Access Control Policy (URL)

What is URL filtering?

URL filtering is a feature in your Access Control Rule which is applicable when you use a web browser to browse websites via the HTTP/HTTPS protocol. For other applications, you must use an FQDN-based access control rule instead of URL filtering.

With URL filtering you can filter connections based on:

• Category
• Reputation

Talos divides the URL categories into Content and Threat categories.

Cisco Talos maintains threat levels associated with web domains and their activity. These levels describe a spectrum that characterizes the risk of visiting a website or IP address, based on extensive telemetry and investigation. With this intelligence, users and analysts can more clearly distinguish established trusted sites and exceptionally untrusted sites from lesser-trusted ones.

URL filtering is done under the URL option in your Access Control Rule.

Scenario:

A client reaching out to a URL with an untrusted web reputation.

Traffic flow:

Client is opening a webpage for which it initiates the TCP handshake to the resolved IP address. Post completion of the handshake, client hello is initiated from the client wherein the URL is read from the SNI field after which, it is blocked by the firewall.

The URL check can also happen at the Server Hello stage where the Common Name (CN) or Subject Alternative Name (SAN) field of the Server certificate is investigated. If the traffic is encrypted with TLS1.2, the firewall reads the server cert in server hello and blocks the connection if the URL is untrusted. If the traffic is encrypted with TLS1.3, firewall checks the cache for server certificate matching the SNI in the client hello packet, if not sends out a sidecar connection for TLS1.2 and gets the server cert and checks the URL.

Since the SNI in the client hello packet can easily be spoofed, the CN or SAN from the server certificate sent over the server hello packet is preferred.

License required:

URL

Access Control Policy (Application Visibility)

What is Application Visibility?

Application Visibility uses application filters to configure application control. For example, you can easily use system-provided filters to create an access control rule that identifies and blocks all high risk, low business relevance applications or specific applications. If a user attempts to use one of those applications, the system blocks the session.

Using application filters simplifies policy creation and administration. It assures you that the system controls application traffic as expected. Because Cisco frequently updates and adds application detectors via system and vulnerability database (VDB) updates, you can ensure that the system uses up-to-date detectors to monitor application traffic. You can also create your own detectors and assign characteristics to the applications they detect, automatically adding them to existing filters.

The system can detect application traffic encrypted with StartTLS, including SMTPS, POPS, FTPS, TelnetS, and IMAPS. In addition, it can identify certain encrypted applications based on the Server Name Indication in the TLS ClientHello message, or the subject distinguished name value from the server certificate. These applications are tagged SSL Protocol.

All the application detectors supported on Cisco firewalls can be found at appid.cisco.com. As of July 2025, 7300+ application detectors are supported with nearly 700 belonging to the category of Generative AI.

Application filtering is done under the Application option in your Access Control Rule.

Scenario:

A client attempting to access a high-risk application

Traffic Flow:

Client initiates a session towards a high-risk application. Risk is an application characteristic which is the likelihood that the application is being used for purposes that might be against your organization’s security policy. It ranges from Very High to Very Low. Currently, more than 600 applications have been identified as ‘High Risk’.

Most of the application detectors are SNI-based. With encrypted traffic, these can be detected at the client hello stage based on the SNI field. Else, the firewall reads the CN/SAN on the server certificate in server hello and blocks the connection. If TLS 1.3 is being used, the server certificate is encrypted. Hence, the firewall checks the cache for server certificate matching the SNI in the client hello packet. If not, sends out a sidecar connection for TLS1.2 and gets the server cert.

In the case of non-encrypted protocols such as IoT / SCADA, VoIP apps etc., application detection is done via deep packet inspection and protocol decoding which requires the firewall to investigate 3-5 packets on average.

License required:

Essentials

Malware Policy

What is Malware Policy?

Malware Policy is used to detect, capture, track, analyze, log, and block the transmission of malware in network traffic.

SHA256 hash is first computed, after which malware inspection is done. The verdict is first checked in the local cache of the firewall. If not present in the local cache of the firewall, it is checked in the FMC cache. If not present in the FMC cache, it is queried to the AMP Cloud.

In addition to SHA256 lookup, the additional ways for malware inspection are:

Local Malware Analysis: done using ClamAV which is a signature database provided by Talos. Because local analysis does not query the AMP cloud, and does not run the file, it saves time and system resources.

Spero signature: Machine-learning based structural analysis of Microsoft executable files, Spero signature is sent to the AMP Cloud.

Dynamic Analysis of the file: Eligible files are uploaded to Secure Malware Analytics (either in the public cloud or via an on-premises appliance) for detonation and thorough analysis.

Malware detection can be done in multiple protocols, for example, HTTP, SMTP, IMAP, POP3, FTP, and SMB.

Malware Policy is configured under Policies > Malware & File.

This policy is then to be selected under File Policy of your Access Control Rule.

Scenario:

A client downloading an executable file with malware.

Traffic Flow:

In the application traffic, if there is a file transfer, the file is inspected and if found malicious, it is blocked. The verdict can be determined by performing a file hash lookup against our Cisco Security Cloud, or by local malware analysis which can be performed on box.

If the malware cloud lookup disposition of the file is Unknown or Unavailable and if the system has pre-classified the file as potential malware, the file can be sent for Dynamic Analysis wherein the file is sent for sandboxing to Malware Analytics cloud (or on-prem) to get its threat score.

Malware analysis can only be performed on files that can be seen; hence, encrypted traffic requires decryption.

License required:

Malware defense

Intrusion Policy

What is Intrusion Policy?

An intrusion policy uses intrusion and preprocessor rules to examine the decoded packets for attacks based on patterns. Intrusion policies are paired with variable sets, which allow you to use named values to accurately reflect your network environment. In inline deployments, they can block or alter malicious traffic. Your access control policy invokes intrusion policies that are the system’s last line of defense before the traffic is allowed to its destination.

The system is delivered with system-provided policies, such as Balanced Security and Connectivity, Security over Connectivity etc., using which you can take advantage of the experience of Talos. For these policies, Talos sets intrusion and inspector rule states, as well as provides the initial configurations for inspectors and other advanced settings. In addition to this, Talos provides extensive zero-day coverage, offering protection against vulnerabilities which have not yet been publicly disclosed in the form of TruffleHunter rules. These rules are discovered through in-house research or private disclosure from a vendor or partner and delivered as compiled code to ensure confidentiality. 2500+ TruffleHunter rules are currently enabled in Security over Connectivity base policy.

Snort is available in open source and has hundreds of thousands of users – it’s the de facto standard IPS, authored by Cisco. Snort 3 is the latest version of the Snort intrusion detection and prevention system (IDS/IPS). It offers significant improvements over Snort 2, including a flow-based detection engine, multi-threading, and enhanced performance. It also allows setting the security level based on the rule group. This allows much more granular customization of the policy while still leveraging the Talos security levels. This frees the user from having to constantly maintain their customized rule set. Snort 3 rules are downloaded as LSP (Lightweight Security Package) updates. Snort 2 used to be downloaded as SRU (Snort Rule Updates).

Intrusion Policy is configured under Policies > Intrusion.

The policy is then to be selected under the Intrusion policy of your Access Control Rule.

Scenario:

Intrusion content being delivered from a server to a client.

Traffic Flow:

In this example, SMTP traffic is initiated from the client. Intrusion content is detected in the HTTP response sent by the server to the client. All the SMTP related rules are categorized under the category Server > Mail. The default action for the rules, the CVE number, GID, SID, assigned rule groups, etc. can be viewed within the Intrusion policy.

When enabling intrusion prevention, it is highly recommended to configure traffic decryption to maximize efficacy.

License required:

IPS

SnortML

What is SnortML?

SnortML is a machine learning-based exploit detection engine for the Snort Intrusion Prevention System. Traditional intrusion rules are designed to be highly specific to minimize false positives. However, this specificity means they may not detect new or variant forms of attacks. Undisclosed or new vulnerabilities, commonly known as zero-day attacks, often take time to be analyzed and released as signature-based rules. During this gap, systems remain exposed, and damage can occur before signatures are updated.

With the introduction of SnortML, we can now address this challenge by identifying such variants. SnortML utilizes a model file—downloaded via LSP updates—that has been trained on thousands of attack samples within a particular category, such as SQL injection. As a result, even zero-day variants of SQL injection attacks can be detected.

Snort ML uses a deep neural network to detect exploits. Here, a deep neural network is trained on malicious and benign traffic corpora. The neural network infers generalized versions of the exploit patterns in the malicious corpora and learns to distinguish between malicious and benign traffic. With its new Machine Learning capabilities, attacks never seen before can be detected and blocked in real-time. For the first release of the feature, coverage was provided to detect and block SQL injection attacks by looking for URI in HTTP traffic. The support is now extended to CMDi as well, with more on the roadmap.

The snort_ml model file can be viewed under your Intrusion policy.

Scenario:

SQL injection attack from client to server

Traffic Flow:

HTTP traffic is initiated from the client wherein the HTTP URI is inspected in the request which could be GET, POST, PUT etc. The SnortML IPS rules have GID: 411and rule message: prepended with '(snort_ml)'. GID stands for Generator ID which identifies the source or subsystem generator behind the rule.

License required:

IPS

MITRE ATT&CK:

MITRE ATT&CK is a globally recognized knowledge base of adversary tactics and techniques used in cyber-attacks, based on real-world observations. It helps organizations understand how attackers operate and how to better defend their environment. The MITRE ATT&CK framework provides a comprehensive taxonomy of attacker tactics and techniques that can be mapped to Cisco firewall operations. This helps organizations strengthen defenses, improve detection, and respond effectively to threats targeting or evading their Cisco firewall infrastructure.

MITRE Tactics, Techniques, and Procedures (TTPs) are added to Intrusion and Malware events in order to act on traffic based on the MITRE ATT&CK Framework. This enables administrators to view and handle traffic with more granularity by having the ability to group rules by vulnerability type, target system, or threat category.
MITRE TTPs can be viewed as a progression graph in the FMC Unified Event Viewer. Expanding the event gives an option to click ‘Details’ which opens the corresponding MITRE ATT&CK page.

Conclusion

In summary, Cisco Secure Firewall stands as a cornerstone of a robust 'Defense in Depth' strategy, delivering comprehensive threat capabilities designed to counter the full spectrum of modern cyberattacks. By integrating real-time global threat intelligence from Talos, advanced malware protection, sophisticated intrusion prevention, and innovative features like Encrypted Visibility Engine and Snort ML, Cisco Secure Firewall provides a multi-layered defense that adapts to evolving threats. This holistic approach ensures that organizations can confidently protect their networks, data, and users, maintaining resilience and operational continuity in today's challenging digital environment.