• ITP overview
• Availability and encryption
• Components
  • Core components
  • Components legend
• DNS resolution in ITP
  • DNS resolution in SIA-only orgs
  • DNS resolution in SIA and SPA orgs
• Network requirements
• Failure behavior

ITP overview

Internet Threat Protection (ITP) is a Secure Web Gateway (SWG) solution. Its core functions include web traffic filtering (identifying and blocking access to known threats, domain categories, and URLs), access policy enforcement (blocking or allowing access to specific domains, categories, apps, or geolocations), and payload inspection of web requests.

The heart of ITP is the secure web gateway (SWG) agent, a proxy which lives in the cloud and has distributed points of presence. At each point, the SWG agent acts as an intermediary between users and the public internet, inspecting traffic and blocking users from malicious content. It integrates third-party threat intelligence and ITP policy rules to determine whether to block or allow users’ access to internet resources.

ITP is useful for corporations that want to protect remote and on-site users (threat blocking) and for organizations that have compliance requirements for internet access control (non-compliance blocking).

Availability and encryption

In orgs that use ITP, CSE’s SWG agent manages DNS requests, and web requests when TLS decryption is on. CSE has globally distributed SWG agents in 18 regions.

ITP policies come into effect immediately upon device registration; they affect only devices that have an ITP policy associated to them. If ITP policies are updated, changes come into effect immediately.

CSE components use encrypted protocols to run ITP: The CSE desktop app uses DoT (DNS over TLS) and CSE’s Chrome Extension uses DoH (DNS over HTTPS).

In rare scenarios, CSE supports fallback protocols (e.g., UDP and TCP). If communication between CSE’s SWG agent and CSE’s third-party threat intelligence vendor is ever interrupted, users’ requests will still be resolved; however, users may temporarily encounter high latency.

Components

Core components

1. Users’ devices that have an ITP policy associated to them automatically update their name servers to point to CSE’s name servers for all DNS traffic (via the local DNS proxy).
2. The next time the device makes a DNS request, it sends the request to CSE name servers, along with the device’s unique identifier.
3. The name servers recognize the device based on its unique identifier and then match the device to the associated ITP policy.
4. Finally, the ITP policy determines whether to block or allow the request.

Components legend

ITP component	Definition
SWG agent	A proxy that lives in the cloud. It acts as an enforcement node that receives and manages devices’ DNS requests, and web requests when TLS decryption is on; it then integrates threat intelligence and ITP policy rules to determine whether to block or allow users’ requests. If it allows the request, it handles certificate emulation of the web server the user is trying to reach and secures transport of the web request.
Third-party threat intelligence vendor	Identifies domain threats and categories and can resolve or block resolution of DNS requests forwarded by the SWG agent.
DNS proxy	A local proxy on the user’s device that forwards all DNS requests to the SWG agent.
Web proxy	A local proxy on the user’s device that forwards all web requests to the SWG agent.
PAC file	A file on the user’s device that configures and directs traffic to the web proxy. Once the admin sets a PAC file, the OS configures itself to know when it needs to send traffic to the web proxy.

DNS resolution in ITP

Depending on how a device is configured (i.e., whether it has an ITP policy associated with it), there are several available DNS resolution paths. DNS resolution can happen through CSE’s Service Tunnel, the device’s default DNS resolver, or through the SWG agent (which resolves or blocks DNS requests based on ITP policy rules and threat intelligence). Which path a request takes also depends on your CSE licenses. A Secure Internet Access (SIA) license covers what users can reach on the internet, including ITP. A Secure Private Access (SPA) license covers access to your private resources, including Service Tunnels. See Licenses.

DNS resolution in SIA-only orgs

DNS resolution in SIA and SPA orgs

Network requirements

ITP needs these conditions on your network and on each device:

• Firewalls allow DNS over TLS. The CSE desktop app sends DNS requests to CSE over DoT. If your firewalls restrict outbound DNS, allow this traffic, or devices cannot reach the SWG agent.
• Firewalls do not inspect SWG traffic. If a firewall runs its own TLS inspection, such as SonicWall Deep Packet Inspection of SSL (DPI-SSL), exclude *.swg.banyanops.com from it. See Firewalls with their own TLS inspection.
• Port 53 is free on the device. If another service on the device already uses that port, ITP does not start. See Known Issues.
• Private domains are bypassed. The SWG agent resolves DNS from public resolvers, which have no records for your internal domains. Add each internal domain to Domain and URL Bypass in every ITP policy. See Private domains failing to resolve.
• The CSE certificates are installed. On macOS Sequoia, the CSE desktop app cannot install the certificates without action from the user, and CSE cannot enforce ITP without them. Deploy them through your MDM system. See Known Issues.

Failure behavior

This is how ITP behaves when part of the system is unavailable:

Situation	What happens
The SWG agent cannot reach the threat intelligence vendor	DNS requests still resolve, but users can see high latency.
DNS over TLS is unavailable	In rare cases, CSE falls back to DNS over UDP or TCP.
Another service on the device uses port 53	ITP does not start, but the ITP health check still reports that it is working.
An internal domain is not bypassed	The domain fails to resolve, so users cannot reach it.
A user turns off ITP in the desktop app	ITP turns back on automatically after 1 hour, and CSE logs both events under Events. You can require a passcode before users can turn off ITP. See Disabling ITP.
TLS decryption is on and an application pins certificates	The connection fails closed, and the application cannot connect. See Some applications stop connecting.