Enable ICAP-based DLP for Unified Data Protection

Last updated
Save as PDF

Limited Availability: ICAP over DLP is a Limited Availability feature. To enable ICAP over DLP, contact Skyhigh Support.

In general, ICAP (Internet Content Adaptation Protocol, RFC 3507) is a standard networking protocol used to extend the capabilities of proxy servers by offloading specialized tasks to dedicated adaptation servers. While a proxy (the ICAP client) is efficient at moving traffic, it is not designed for deep inspection, such as virus scanning or sensitive data detection. ICAP enables the proxy to forward this inspection work to an ICAP server, for example, the Skyhigh Security DLP/DSPM engine. Within the Secure Web Gateway (SWG), ICAP is supported to handle client requests more effectively. In earlier configurations, clients sent HTTP requests directly to the SWG Cloud. With ICAP, a third‑party proxy now forwards those requests to the SWG Cloud, encapsulating the HTTP traffic for inspection and processing. Instead of receiving raw HTTP requests, the SWG Cloud processes them through ICAP, enabling seamless integration with external proxies while maintaining centralized inspection and policy enforcement.

ICAP-based DLP Service

An ICAP‑based Data Loss Prevention (DLP) service integrates Skyhigh DLP with third‑party proxies, providing centralized inspection of data in real time without requiring changes to existing network infrastructure. Extending Skyhigh DLP coverage to external proxies without native DLP gives organizations full visibility into web traffic through a single policy layer. This approach increases deployment flexibility, reduces integration effort, and promotes broader DLP adoption.

Key Benefits

Extends Skyhigh DLP protection to third‑party proxies without built‑in DLP
Delivers centralized visibility into data in motion across all web traffic
Simplifies deployment and integration, encouraging wider DLP adoption, thereby facilitating seamless compliance with emerging data regulations.

Key Capabilities

ICAP server support with Secure Web Gateway (SWG) acting as the inspection endpoint for third‑party proxies.
Centralized policy enforcement across both cloud and on‑premises web traffic.
Secure, encrypted connectivity between proxies and the DLP service for safe content inspection.

Use Cases for ICAP over DLP

Use Case 1: Enforcing Unified Policies Across Mixed Environments

An organization uses a legacy on-prem proxy but wants to use the same modern DLP classifications they use for Office 365 or Slack. Skyhigh acts as the Single Pane of Glass, ensuring the same Advanced Data Classification, such as Exact Data Matching, applies to both web traffic and SaaS apps.

Use Case 2: Real-time Monitoring of Outbound Web Traffic

A user attempts to upload a proprietary design file to a personal cloud storage site. The third-party SWG intercepts the traffic and sends it via ICAP to the Skyhigh DSPM engine for content inspection and deep discovery of risks associated. In addition, if a violation is detected, the upload is blocked, or the user is coached in real-time.

Use Case 3: Hybrid Cloud Data Inspection

A company is in the middle of a multi-year cloud migration and cannot yet replace its physical hardware. It can use ICAP DLP to bridge the gap. It allows the company to outsource the heavy lifting of data inspection to the Skyhigh cloud without tearing out their existing proxy infrastructure.

ICAP Client Configuration

The SWG On‑prem acts as a third‑party proxy when it sends requests to the Cloud SWG via ICAP. To enable this request flow through ICAP, the following requirements must be met:

On the SSE web interface, you must generate an API key to enable ICAP-based DLP inspection. During this process, a Content Inspection option becomes available. The API key is then included in ICAP client requests to authenticate and authorize access to the DLP service, enforcing role‑based access control so that only authorized users and systems can forward requests for inspection. For more details, see Create a API Keys.
For correct rendering of our block pages, the ICAP Client should forward all HTTP GET requests starting with the URL path: /mwg-internal/de5fs23hm64ds to the ICAP Server. This allows fetching the subresources of the blockpage. Alternatively, the ICAP Client may be configured to replace our SSE blockpage with its own blockpage.
To support the DLP Agentless feature, the ICAP Client should forward all HTTP GET requests with host static.mwginternal.com to the ICAP Server.
The ICAP client should be configured with either of these URLs, depending on the field it can use to provide the API Key:
‘Authorization’ Header: icaps://icap.wgcs.skyhigh.cloud:11344/v1/web/
Query string: icaps://icap.wgcs.skyhigh.cloud:11344/v1/web/?api_key=<APIKEY>
URL path: icaps://icap.wgcs.skyhigh.cloud:11344/v1/web/<APIKEY>
On the SWG On‑prem, you configure policy settings to make it act as an ICAP client. This setup forwards requests from the Skyhigh Secure Web Gateway On‑prem to Skyhigh SSE for DLP inspection, ensuring that content is inspected without disrupting existing traffic flow. For more details, see Configure Selective Forwarding from SWG On-Prem to Skyhigh SSE DLP as ICAP

How it work?

Policy evaluation occurs twice: once during the request cycle and again during the response cycle if the request is not blocked. ICAP enables this dual evaluation via sending separate requests, REQMOD for the request cycle and RESPMOD for the response cycle.

The SWG On‑prem receives a web request from the client.
It sends an ICAP REQMOD request to the SWG Cloud.
The SWG Cloud applies the customer’s configured policy for the request cycle and returns an ICAP response.
- If the response indicates a block, the SWG On‑prem enforces the block, and the request ends.
- If not blocked, the SWG On‑prem forwards the web request to the destination server.
When the server responds, the SWG On‑prem sends an ICAP RESPMOD request to the SWG Cloud.
The SWG Cloud applies the configured policy for the response cycle and returns an ICAP response.
Based on this response, the SWG On‑prem either blocks the content or delivers the original server response to the client.

The SWG On‑prem can be configured to send REQMOD, RESPMOD, or both, depending on organizational requirements. Policies in SSE apply regardless of whether traffic is received through ICAP or direct HTTP, though customers may choose to configure rules specifically for ICAP traffic. The primary use case is DLP scanning, ensuring sensitive data is inspected and protected in real time while maintaining seamless connectivity between proxies, SWG, and the ICAP service.

Troubleshooting

Policy execution. REQMOD applies only to the Web.Request cycle, while RESPMOD applies only to the Web.Response cycle. Because RESPMOD does not include a request cycle, rules designed to block requests, such as the Global Block ruleset, will not apply. As a result, direct traffic sent to SWG Cloud may be blocked during the request cycle, but traffic inspected through ICAP RESPMOD is not, since only the response cycle is evaluated in that mode.
Certificate configuration Issue. You should not use certificate pinning for the ICAP server certificate because it can be rotated or changed without notice. The certificate is issued by a public trusted CA.
API key Issue. Revoked or deleted API keys may take up to one hour to stop working, which can result in errors. Confirm that the API key is active and correctly generated in the SSE web interface, and replace invalid or deleted keys as needed.