Threat Protection: DNS Security, SWG, Firewall, IPS, and Talos

The first two layers a request meets — DNS-layer security and the Secure Web Gateway — do the heaviest lifting by raw volume. Both descend directly from Cisco Umbrella, the cloud security stack Secure Access is built upon. A useful analogy: DNS Defense is the guard at the front gate checking the address on a visitor's badge (cheap, fast, turns away the obviously unwanted), while the SWG is the receptionist who opens the briefcase and reads the documents.

DNS-layer blocking of malware and phishing

Cisco Secure Access DNS Defense enforces at Cisco's global network of more than 50 recursive DNS resolvers. Queries are evaluated against Talos threat intelligence and AI-based models; domains tied to malware, phishing, botnets, ransomware, cryptomining, and "newly seen domains" are blocked at resolution time. The layer is especially strong against two evasive categories: DGA command-and-control (malware generates thousands of candidate names daily; AI recognizes the pattern) and DNS tunneling / data exfiltration (stolen data encoded inside DNS queries).

Figure 6.1: The layered threat-protection stack — each control inspects a different property of the connection.

Worked example — the phishing link. A user clicks a link and the endpoint issues a DNS lookup. One of three things happens at resolution time: known-malicious → refuse to resolve, land on a block page; newly seen / risky → resolve but flag risky and selectively proxy to the SWG; clean → session proceeds.

Figure 6.2: The phishing-link DNS lookup — three outcomes at resolution time.

URL filtering, content categories, and the two resolutions

The DNS layer sees only domains; the SWG sees the full URL. Content filtering exists at both layers but at different resolutions:

TLS/SSL decryption and inspection

Most web traffic is TLS-encrypted, and an engine cannot filter a URL, scan a file, or match a signature on ciphertext. Secure Access decrypts using a MITM forward-proxy model. For an outbound HTTPS connection: (1) client sends ClientHello; (2) the node consults the decryption policy first — Decrypt, Block, or Bypass; (3) if decrypting, it establishes two separate TLS sessions — presenting a proxy cert signed by the internal CA to the client, and validating the real server's cert on the server side; (4) plaintext is inspected in the middle, then re-encrypted and forwarded.

Figure 6.3: MITM forward-proxy TLS decryption — two separate TLS sessions bridged by in-the-clear inspection.

The client only trusts the proxy cert because the org deployed its internal CA root to every endpoint's trust store — the single most important operational prerequisite. Two cert modes exist: Re-sign (forward proxy) for outbound Internet traffic, and Known-key for servers you own. Trade-offs to plan around: certificate-pinned and mTLS apps must be bypassed; TLS 1.3 only allows insertion during the initial handshake (pair with TLS Certificate Visibility); decryption is CPU-intensive. Lighter alternatives include SNI-based policy and the Encrypted Visibility Engine (EVE), which fingerprints the ClientHello without full decryption.

Web traffic is only part of the picture. Malware that has landed often abandons the browser and communicates over custom protocols and arbitrary ports. And within allowed, reputable connections, an attacker may deliver an exploit. Catching these needs two more layers: the cloud-delivered firewall and the IPS.

A note on precision: Cisco has not published exhaustive documentation on every internal detail of the Secure Access CDFW and IPS. Specifics about the Snort engine and CDFW architecture are well-founded inferences from Cisco's broader Umbrella SIG and Secure Firewall architecture, of which Secure Access is the SSE successor.

Layer 3–7 cloud firewall

The CDFW — descended from the Umbrella SIG firewall — enforces network-level policy in the cloud for outbound traffic: policy by IP, port, protocol, and application; non-web traffic control (custom protocols malware uses precisely because they are not HTTP); and geo/IP controls and segmentation. In a full-SSE deployment, all internet-bound traffic is steered via IPsec/GRE tunnels or endpoint agents, evaluated by DNS for name resolution, then routed by protocol — web to the SWG, non-web primarily to the CDFW. The result: network-level policy enforced consistently for remote and on-prem users alike.

Worked example — C2 beaconing after compromise. An infected endpoint first tries DNS-based C2 using DGA domains, but DNS Defense's AI refuses to resolve them and flags exfiltration. Thwarted at DNS, the malware falls back to a direct IP connection over a non-standard port — exactly where the CDFW earns its keep: its outbound port/protocol policy and IP-reputation controls block the connection that never touched DNS or the web proxy.

Intrusion Prevention System (IPS)

DNS and the SWG ask about destination reputation and payloads. The IPS asks a different question: is this traffic attempting to exploit something? It performs deep packet inspection for exploit signatures, protocol anomalies, shellcode, buffer-overflow attempts, and known attack patterns within otherwise-allowed traffic. This matters because a sophisticated attack can arrive from a clean-reputation source — a compromised legitimate website. The engine is built on Snort, maintained by Talos, matching on HTTP methods/URIs/headers, payload patterns, file types, and behavioral patterns like C2 beacons. Critically, the IPS decrypts in memory, hands plaintext to Snort, and immediately discards the payload, storing only alerts, metadata, and verdicts.

Application control

Because the SWG and firewall can inspect decrypted Layer-7 content, Secure Access can enforce policy at the level of what the application is doing — genuine Layer-7 rules like "block POSTs to social media, allow login pages only, inspect file uploads." The decryption engine and its policy are shared: IPS, SWG, and firewall rely on the same TLS decision tree and Do-Not-Decrypt (DND) lists, but each component only sees what its own policy permits. Because the decryption policy is evaluated before the access-control policy, an access rule can match on properties that exist only because the traffic was decrypted first.

Everything so far — the domain reputations, URL categories, file verdicts, and Snort signatures — draws from a common well: Cisco Talos, Cisco's global threat-research organization and one of the largest dedicated cybersecurity intelligence teams in the industry. It maintains two open-source engines that underpin Cisco detection: Snort (IPS) and ClamAV (antivirus).

Cisco Talos threat intelligence

The Talos pipeline runs in three stages: telemetry collection (DNS queries, web traffic, firewall/IPS events, email, malware submissions, external partnerships); analysis and classification (statistical models and ML produce reputation scores, categories, malware verdicts, and IPS signatures); and distribution into Cisco Security Cloud Control, driving policy across Umbrella's DNS/web engines, Secure Firewall, Secure IPS, and Secure Access. The scale is significant — Umbrella uses Talos analytics to block over 170 million malicious DNS queries every day.

Figure 6.4: Talos intelligence fan-out — one intelligence fabric feeding every enforcement point.

File inspection and sandboxing

Reputation catches known-bad files; a fresh zero-day whose hash Talos has never seen needs a different approach — run it and watch. In the SWG path: (1) the SWG intercepts a downloaded file; (2) it's checked against signatures/reputation, known-bad blocked immediately; (3) if suspicious/unknown, it's forwarded to Cisco Secure Malware Analytics (formerly Threat Grid) for dynamic behavioral analysis; (4) policy decides the outcome. An API-based path scans files in SaaS apps (Box, Dropbox, M365, Drive, S3, Azure) with no traffic steering — catching a malicious file uploaded to a shared folder even when no browser traffic passed through the proxy.

Remote Browser Isolation as containment

RBI assumes a site might be malicious and never lets its code touch the endpoint. The session runs in a disposable browser in Cisco's cloud; only a safe rendering stream (pixels + sanitized DOM) returns to the local browser. Because the browser is isolated, exploit kits, drive-by downloads, and browser zero-days are contained. RBI is expensive and reserved for high-risk situations — DNS/SWG policy decides when to invoke it (uncategorized, newly seen, or allowed-but-high-risk destinations).

Worked example — the drive-by download. A user visits a legitimate but compromised site serving a browser exploit: DNS Defense allows the clean-reputation domain; the SWG decrypts and inspects, sending files to the sandbox; the IPS matches a Snort signature against the exploit JavaScript and drops the session before it reaches the browser; RBI, if configured, would have detonated the whole session harmlessly in the cloud. No single layer had to be perfect — the clean-reputation site sailed past reputation, but the exploit technique was caught by the IPS.

Figure 6.5: The drive-by download — defense in depth against a compromised clean-reputation site.