Cato Threat Prevention: Best Practices & Configuration Guide

Why Getting Cato Threat Prevention Right Matters More Than Getting It Fast?

Most teams rush the rollout. They enable Cato's security services, flip everything to Block mode on day one, and spend the next three weeks firefighting false positives, frustrated users, and broken business applications.

The better approach takes a few extra days upfront — and saves months of remediation work down the line.

Cato's threat prevention stack is genuinely powerful. Anti-Malware, NG Anti-Malware (powered by SentinelOne's AI engine), IPS, and TLS Inspection work together as a multi-layered security system that operates inline across all WAN and internet traffic — with no noticeable performance impact for end users. But that power is only realized when these services are configured correctly, rolled out in the right sequence, and tuned to your organization's specific traffic environment.

This guide walks through the architecture of Cato's security layers, the recommended rollout workflow, and the configuration best practices that enterprise security teams use to achieve maximum protection with minimum disruption.

Explore Cato SASE Today

Understanding Cato's Two-Layer Security Architecture

Before configuring anything, it's essential to understand how Cato structures its protection. Every network flow in the Cato Cloud passes through two distinct layers of inspection — and they serve fundamentally different functions.

Layer 1: The Access Layer (Who Gets In)

The Access Layer is your first line of defense. It consists of two firewalls that determine whether traffic is permitted to flow at all:

WAN Firewall Controls traffic between organizational entities — sites, users, hosts, subnets, and cloud resources. By default, Cato's WAN firewall operates on a whitelisting model: only traffic explicitly permitted by a defined rule is allowed. Everything else is blocked. This is the correct default posture, and it should not be weakened without deliberate justification.

Internet Firewall Controls outbound traffic to the internet. Unlike the WAN firewall, the Internet firewall uses a blacklisting model — the final rule is an implicit any-any allow, meaning internet traffic is permitted unless a rule explicitly blocks it. This is where your URL filtering, application control, and category blocking rules live.

Important: Cato ships with a pre-configured Internet firewall rule that blocks known dangerous traffic categories. This rule should never be disabled. It represents the baseline protection that your organization benefits from without any configuration effort — removing it silently erodes your security posture.

Cato's Security team continuously maintains pre-built application and website categories within both firewalls, updating them based on global threat intelligence. Leverage these categories rather than building manual lists from scratch.

Layer 2: The Security Layer (What Gets Through)

Traffic that passes the Access Layer moves to the Security Layer — where Cato's threat prevention engines perform deep content inspection. This is where malware is caught, intrusion attempts are detected, and advanced threats are neutralized.

The Security Layer has three core engines:

The Three Threat Prevention Engines: What Each One Does

Engine 1: Anti-Malware (Classic)

Cato's Anti-Malware operates as a cloud-based anti-virus gateway with capabilities that go significantly beyond traditional signature scanning:

Deep Packet Inspection (DPI) Analyzes the actual payload of network traffic — not just headers or metadata. For encrypted traffic, this requires TLS Inspection to be enabled (more on this below).

True Filetype Detection This is a capability that many teams underestimate. Cato identifies the actual type of a file based on its content — not its extension or content-type header. An attacker renaming malware.exe to document.pdf does not fool Cato's filetype detection. This closes one of the most commonly exploited gaps in signature-based AV systems.

Signature and Heuristics Database Malware detection uses a continuously updated combination of known signatures (exact threat matches) and heuristic analysis (behavioral pattern matching for near-known threats). The database is maintained in real time based on global threat intelligence.

A critical data privacy note: Cato does NOT upload customer files or data to external cloud repositories for analysis. All inspection happens within the Cato Cloud. For organizations in regulated industries — financial services, healthcare, legal — this is a significant compliance advantage over cloud sandbox solutions that send files to third-party infrastructure.

Engine 2: NG Anti-Malware (SentinelOne AI Engine)

NG Anti-Malware is where Cato's threat prevention goes beyond traditional AV. Powered by SentinelOne's machine learning model, this engine addresses the fundamental limitation of signature-based detection: it cannot catch what it has never seen before.

How the AI Model Works The SentinelOne engine was trained by extracting behavioral and structural features from millions of malware samples. Supervised machine learning then learned to distinguish the patterns that separate malicious files from benign ones — not based on known signatures, but based on learned characteristics of how malicious files are structured and behave.

What It Covers NG Anti-Malware inspects three file categories that are the most common vectors for advanced threats:

• Portable executable files (.exe, .dll, .sys) — the primary delivery format for ransomware and trojans
• PDF files — frequently weaponized with embedded scripts or exploit payloads
• Microsoft Office documents — the most common phishing attachment format globally

Why This Matters in 2025 Zero-day malware, polymorphic ransomware variants, and custom-built attack tools are specifically designed to evade signature databases. NG Anti-Malware's AI model can flag these threats based on structural characteristics — even when no signature exists. This is the engine that catches what classic Anti-Malware misses.

Engine 3: IPS (Intrusion Prevention System)

Cato's cloud-based IPS inspects all network traffic — inbound, outbound, and WAN — for network-level threats that malware scanning alone cannot address:

• Exploit attempts targeting known CVEs and unpatched vulnerabilities
• Protocol anomalies and evasion techniques
• Brute force and credential stuffing attacks
• Command-and-control (C2) beaconing and callback traffic
• Lateral movement patterns within the WAN
• DNS tunneling and covert channel communication
• Anonymizer and proxy tunneling protocols

IPS can operate in two modes — and the distinction matters enormously for how you roll it out:

The critical difference: In IDS/Monitor mode, you get full visibility into what IPS would block — without any impact on live traffic. This is your validation phase before enforcement.

Also Read: What is Site to Site WAN Connectivity? Cato Cloud

The Proven Rollout Workflow: Monitor First, Block Second

This is the sequence that enterprise security teams use to deploy Cato threat prevention without disrupting business operations. It takes a few extra days compared to enabling Block mode immediately — and eliminates weeks of false positive remediation afterward.

Step 1: Enable All Threat Prevention Policies in Monitor Mode

Before touching Block mode, enable Anti-Malware, NG Anti-Malware, and IPS in Monitor (IDS) mode for all traffic — both WAN and internet.

In Monitor mode:

• All traffic flows normally — nothing is blocked
• Malicious or suspicious traffic is logged and flagged as security events
• You build a baseline of what your environment actually looks like from a threat perspective

Why this step cannot be skipped: Every organization has traffic patterns, legacy applications, and internal tools that are unique. Enabling Block mode without a Monitor phase guarantees false positives — legitimate business traffic that matches a threat signature. In Monitor mode, you discover these before they cause disruption.

How long to run Monitor mode: A minimum of 5–7 business days is recommended. For complex environments with legacy applications, OT-adjacent systems, or unusual internal protocols, extend this to 2–3 weeks.

Step 2: Configure Alert Notifications for Monitor Mode Events

During the Monitor phase, configure the tracking option to send email alerts when malware is detected or when IPS events are generated.

This is important for two reasons:

1. It keeps the security team actively aware of what the engines are detecting — rather than requiring manual log reviews
2. It creates an audit trail of the pre-enforcement threat landscape, which is useful for reporting and for justifying the move to Block mode

Note: In Monitor mode, there are no alerts for blocked traffic — because nothing is being blocked. Alerts fire on detection events, not enforcement actions.

Step 3: Review Events and Tune Before Promoting to Block

After 5–7 days in Monitor mode, review the generated security events systematically:

For IPS events:

• Identify any signatures firing on legitimate business traffic
• Determine whether hits represent real threats or application behavior that resembles attack patterns
• Create targeted exceptions for confirmed false positives — scoped to the specific application, user group, or site, not globally

For Anti-Malware events:

• Review any flagged files against known-good file hashes or trusted domains
• Configure file hash or domain exceptions for confirmed legitimate files
• Document every exception with a business justification and review date

Promotion strategy: Promote to Block mode category by category rather than all at once. For example:

1. Block known malware signatures first (lowest false positive risk)
2. Block exploit attempts and CVE-based IPS signatures
3. Block C2 and tunneling signatures
4. Block heuristic and AI-flagged threats last (highest variability)

Step 4: Enable TLS Inspection

This is the step most organizations delay — and it's the one that makes every other security engine significantly more effective.

Up to 95% of internet traffic in enterprise environments is now encrypted. Without TLS Inspection, Cato's Anti-Malware, NG Anti-Malware, and IPS engines are operating blind on the majority of your traffic. Malware delivered over HTTPS, C2 callbacks over encrypted channels, and ransomware droppers hiding inside TLS sessions all bypass inspection entirely without this step.

What TLS Inspection does: Cato decrypts traffic at the PoP, passes it through the threat prevention engines for inspection, then re-encrypts and forwards it to the destination. From the end user's perspective, the connection is seamless. From the security engine's perspective, the traffic is fully visible.

Why it's the final step: TLS Inspection has the broadest potential for disruption — particularly for applications that use certificate pinning or non-standard TLS configurations. Enabling it after the Monitor phase means you have already baselined your environment and are prepared to handle exceptions systematically.

Get Started with Cato SASE

Implementation approach for TLS Inspection:

• Enable in Monitor mode first (mirroring the threat prevention workflow)
• Add bypass rules for certificate-pinned applications (financial apps, endpoint security tools, certain SaaS platforms)
• Promote to full inspection after validating no critical applications are broken
• Add TLS Inspection to your quarterly exception review cycle

Cato's official guidance is explicit: For maximum detection results, TLS Inspection must be enabled. It is not optional for organizations that want full coverage — it is the capability that makes everything else work on modern encrypted traffic.

Configuration Best Practices: Reference Checklist

WAN Firewall

• Keep the default whitelist posture — only explicitly permitted traffic should flow between sites
• Audit WAN firewall rules quarterly and remove any rules that no longer reflect current architecture
• Use Cato's identity-aware policy (user/group-based rules) rather than relying solely on IP-based rules
• Document the business justification for every permit rule

Internet Firewall

• Never disable the pre-configured dangerous category block rule
• Use Cato's pre-built application and website categories rather than manual domain lists — they are maintained continuously by Cato's security team
• Add explicit block rules for categories relevant to your risk profile (newly registered domains, anonymizers, crypto mining) above the implicit allow-all
• Review and tighten the implicit any-any allow rule as your environment matures — move toward a more restrictive default posture over time

Anti-Malware

• Enable for all traffic from day one — the performance impact on end users is negligible
• Enable True Filetype Detection — do not rely on extension or content-type header checks alone
• Configure exceptions using file hashes rather than domain-level allows where possible
• Review exception lists quarterly

NG Anti-Malware

• Enable alongside classic Anti-Malware — they are complementary, not redundant
• Ensure coverage includes PE files, PDFs, and Office documents
• Pay particular attention to NG Anti-Malware events during the Monitor phase — these are frequently the catches that classic signatures miss

IPS

• Start in IDS/Monitor mode — never go directly to Block in a new deployment
• Enable for all three traffic directions: inbound, outbound, and WAN
• Scope exceptions as narrowly as possible — by specific signature, user group, and site
• Review IPS events weekly during initial deployment, then monthly after stabilization
• Correlate IPS events with your SIEM for end-to-end visibility

TLS Inspection

• Treat TLS Inspection enablement as its own phased rollout project
• Build a bypass list before enabling: certificate-pinned apps, endpoint security tools, HR/payroll systems
• Enable in Monitor mode first, validate, then enforce
• Communicate the change to end users where certificate trust changes may be visible (browser padlock behavior)

Also Read: Cato Sockets Explained: SASE Site Connectivity

Common Implementation Mistakes — And How to Avoid Them

Mistake 1: Going straight to Block mode The most common and costly mistake. Always start in Monitor mode and validate before enforcing. One week of patience eliminates weeks of remediation.

Mistake 2: Skipping TLS Inspection indefinitely Many teams enable it as a "future phase" that never arrives. Without TLS Inspection, your threat prevention coverage on encrypted traffic is near zero. Schedule it as a mandatory phase in your rollout plan.

Mistake 3: Creating broad exceptions to resolve false positives A global domain exception applied to resolve one application's false positive silently opens a gap for every user and site. Scope all exceptions to the minimum necessary — specific signature, specific user group, specific site.

Mistake 4: Not reviewing Monitor mode events before promoting to Block Enabling Monitor mode and then switching to Block a week later without reviewing the event data defeats the purpose of the phased rollout. The value of Monitor mode is in the analysis, not just the time elapsed.

Mistake 5: Treating exception lists as permanent Every exception is a calculated risk. Without quarterly reviews, exception lists accumulate stale entries that represent silent gaps in your coverage. Build the review into your security operations calendar.

Mistake 6: Disabling the default dangerous category firewall rule This rule is there for a reason. Disabling it — even temporarily to resolve a user complaint — removes a layer of protection that covers categories Cato's security team has identified as actively dangerous. Find the specific application causing the issue and create a targeted exception instead.

Real-World Rollout Timeline: What to Expect

Conclusion

Cato's threat prevention stack — Anti-Malware, NG Anti-Malware, IPS, and TLS Inspection — is one of the most capable inline security systems available in a SASE platform. But capability without correct configuration is just potential. 

Book a call with our SASE Expert

Key Takeaways

Start in Monitor mode. Always. Validate before you enforce. The data from your Monitor phase is the intelligence that makes Block mode safe.

Treat TLS Inspection as mandatory, not optional. Without it, you're running your security engines on a fraction of your actual traffic. Schedule its rollout in week three or four — not in a future phase that never comes.

Scope exceptions precisely and review them quarterly. Every broad exception is a silent gap. Every unreviewed exception is a risk that accumulates over time.

Use Cato's maintained categories and threat intelligence. The pre-built application categories, dangerous category block rules, and continuously updated signature databases are Cato's security team working on your behalf. Leverage them rather than rebuilding from scratch.

Enable both Anti-Malware engines. Classic and NG Anti-Malware address different threat vectors. One catches known threats efficiently. The other catches what the first one misses.

Follow this framework — and the phased rollout timeline — and Cato threat prevention will deliver enterprise-grade protection across every user, site, and traffic flow in your environment.

Frequently Asked Questions

Does enabling Cato threat prevention affect network performance for end users?

No. Cato's threat prevention engines operate inline within the PoP infrastructure using purpose-built processing hardware. End users experience no noticeable latency increase from Anti-Malware or IPS processing. This is a meaningful architectural advantage over on-premises security appliances that introduce processing delays.

What is the difference between IPS mode and IDS mode in Cato?

IPS mode (Block) detects malicious traffic and drops it, preventing it from reaching the destination. IDS mode (Monitor) detects the same traffic and logs it as a security event — but allows it to flow normally. IDS mode is the correct starting point for all new deployments and allows you to validate policies before enforcement.

Why does Cato recommend enabling TLS Inspection last?

TLS Inspection is the most impactful configuration change in the rollout — both for security coverage and for potential disruption. Enabling it last ensures you have already baselined your environment, configured your exceptions, and validated all other threat prevention engines. It also reduces the risk of TLS-related application breakage during the initial rollout period.

Does Cato send customer files to external repositories for malware analysis?

No. Cato explicitly does not share files or data with external cloud repositories. All malware analysis occurs within the Cato Cloud. This is particularly important for organizations in regulated industries where data residency and confidentiality requirements prohibit file uploads to third-party analysis services.

How does NG Anti-Malware differ from standard Anti-Malware?

Standard Anti-Malware uses signature and heuristic databases to detect known threats. NG Anti-Malware uses SentinelOne's AI model — trained on millions of malware samples — to detect unknown and zero-day threats based on learned behavioral and structural characteristics. The two engines are complementary and should both be enabled simultaneously.