Skip to main content
CID222 Docs

Cisco Secure Web Appliance

Add CID222 as an external data-loss-prevention server on Cisco WSA and scope the access policy to the provider hostnames.

  • Version: 0.4
  • Feature: icap
  • Role: admin_user
  • Type: task

Cisco's Secure Web Appliance treats an external scanner as a data-loss-prevention server. This procedure adds CID222 as one, scopes the access policy to the provider hostnames, and narrows inspection to the requests that can carry a prompt.

What do I need?

Licence
Any
Role
admin_user

Prerequisites

  • Cisco Secure Web Appliance 14.x or later, hardware or virtual.
  • Administrative access to the appliance's web interface.
  • The CID222 ICAP listener published and reachable from the appliance on TCP 1344 — see ICAP and third-party gateways.
  • The appliance's source address admitted by the CID222 peer list.

Warning

Written from Cisco's own documentation and the CID222 inspection contract. Not verified against a live Secure Web Appliance. Console paths are a guide to the right screen, not a transcript.

Configure the appliance

Add CID222 as an external server

Under Network → External DLP Servers → Add Server, add a server named cid222 with the appliance address and port 1344, a service URL of icap://<appliance-ip>:1344/inspect, and a concurrent-connection limit suited to your traffic.

Selecting Test Connection reports the server as reachable within about two seconds.

The console validates the path component of the service URL when you save. Use /inspect; CID222 does not route on the path, so the value only has to satisfy the console.

Bind it in an access policy

Under Web Security Manager → Access Policies, add an external-inspection rule matching a custom category that holds the provider hostnames, and submit and commit the change.

Policy distribution is immediate.

Narrow inspection to the right requests

Scope the rule to the request methods that carry content, rather than all methods.

Prompts and uploads are sent, not fetched, so this removes most of the inspection load. Do not narrow it so far that uploads are excluded — an upload can use a different method from a conversation.

Verify

  1. From a managed workstation, send a prompt containing a test identifier to a provider site. The model receives it masked, or the browser shows a block page.
  2. Select Detection & Filtering → All Detections and filter to browser traffic. The attempt appears as MESSAGE_MASKED or MESSAGE_BLOCKED, carrying the username the appliance forwarded in user-principal form.
  3. On Browser Inspection, the appliance appears in the connected-sources table.

If it fails

  • Test Connection fails → the listener is unreachable, or the peer list does not admit this appliance.
  • The console refuses the service URL → shorten the path. The path is not part of the CID222 contract.
  • Prompts are inspected but uploads are not → the method scoping excludes the upload method, or the upload host is outside the category.
  • Every caller arrives with the same address → Every ICAP caller arrives as the same docker bridge address.

Next steps

Last updated on

On this page