Skip to main content

// Symantec · Cloud SWG / WSS

Symantec Cloud Secure Web Gateway
implementation, migration, support.

Symantec Cloud SWG (also marketed as Web Security Service / WSS) is the cloud-delivered evolution of Blue Coat ProxySG. It is one of the deepest cloud SWGs on the market, particularly for organizations that need fine-grained policy, deep SSL inspection, and CASB-aware controls. CyberKIS deploys Cloud SWG for global enterprises and migrates ProxySG estates to cloud.

Also known as: WSS · Web Security Service · Cloud SWG · ProxySG (legacy on-prem) · Symantec Web Filter

// 01 · Implementer perspective

What you need to know,
from someone who has shipped it.

Cloud SWG is the second-most-common Symantec engagement we run (after SES). The dominant scenario is migration from on-prem ProxySG appliances to Cloud SWG / WSS, and it has more moving parts than the marketing implies.

ProxySG to Cloud SWG is not a forklift. ProxySG policy uses Visual Policy Manager (VPM) with deep CPL (Content Policy Language). Cloud SWG policy is JSON / web UI based. Direct policy translation rarely works cleanly - we have to remodel the policy intent, not the policy syntax. Budget 4-6 weeks of policy work alone for a moderately complex ProxySG environment.

Traffic forwarding is the design question. Options: explicit proxy via PAC file, IPsec or GRE tunnel from the perimeter, SD-WAN integration, or roaming agent (WSS Agent / WSS PAC). Each has tradeoffs around user experience, latency, and bypass. Most organizations end up with two or three forwarding methods (e.g., agent for laptops, IPsec for branch offices).

SSL inspection is mandatory and political. Without SSL inspection you see almost nothing. With SSL inspection you have privacy and compliance conversations to have with HR and Legal. CyberKIS helps draft the user disclosure language and the exception list (banking, healthcare, etc.) before turning on inspection.

CASB integration is the multiplier. Cloud SWG + CloudSOC sees both web traffic AND specific SaaS app activity, enforces consistent policy across both, and lets you set risk-based controls (e.g., block uploads to unsanctioned cloud storage, allow with DLP scan to sanctioned ones).

// 02 · Capabilities

Full coverage of the
Cloud SWG / WSS platform.

We deploy and support every capability listed below - not just the headline features.

  • 01 SSL / TLS inspection at cloud scale
  • 02 URL filtering with 80+ content categories
  • 03 Real-time malware analysis (CAS - Content Analysis System)
  • 04 Sandboxing via Symantec Content Analysis Sandbox
  • 05 CASB inline integration with CloudSOC
  • 06 Remote-worker traffic forwarding (PAC, IPsec, GRE, SD-WAN)
  • 07 Granular policy by user, group, device, location, application
  • 08 Content disarm and reconstruction (CDR) for file downloads
03. // Migration paths

01

ProxySG (on-prem) Cloud SWG / WSS

The most common cloud SWG migration. Policy remodel, traffic forwarding redesign, SSL inspection re-implementation, ProxySG decommission. 12-20 weeks for a multi-site enterprise.

02

Zscaler ZIA Cloud SWG

Usually driven by Broadcom contract consolidation. Policy migration, agent swap, traffic forwarding cutover.

03

Cisco Umbrella Cloud SWG

Common where customer wants deeper SSL inspection and policy granularity than Umbrella offers.

04

No web security (post-VPN era) Cloud SWG

Greenfield deployment as part of an SSE / Zero Trust modernization.

Typical timeline: Greenfield Cloud SWG: 4-8 weeks. ProxySG migration: 12-20 weeks depending on policy depth and number of branch sites.

// 04 · Use cases

The engagements we
actually ship.

A non-exhaustive list of the scenarios that come up most often in CyberKIS Cloud SWG / WSS projects.

  • Migrating ProxySG appliances to Cloud SWG at end-of-life
  • Enabling SSL inspection for the first time (sensitive - needs policy + comms work)
  • Branch-office IPsec tunnel design (multi-site, redundant)
  • Roaming user protection with WSS Agent on laptops
  • CASB integration for cloud storage upload control
  • Sandbox / CDR for high-risk file downloads

// 05 · FAQ

Real questions,
honest answers.

What buyers ask before scoping a Cloud SWG / WSS project.

  • 01

    Is Cloud SWG the same as WSS (Web Security Service)?

    +

    Yes. Web Security Service was the historical Broadcom / Symantec name; Cloud SWG is the current marketing name in the SSE category. Same product, just renamed. Some Broadcom documentation still uses WSS interchangeably.

  • 02

    How do we migrate from ProxySG to Cloud SWG?

    +

    In four phases over 12-20 weeks: (1) Tenant provisioning and policy intent capture - we extract the WHY behind your ProxySG policy, not just the CPL; (2) Cloud SWG policy authoring matching that intent; (3) Pilot site cutover with parallel run (ProxySG still active, Cloud SWG observing); (4) Phased cutover and ProxySG decommission. The hardest part is honest policy intent extraction from years of accumulated ProxySG rules.

  • 03

    What is the difference between Cloud SWG and Zscaler ZIA?

    +

    Both are cloud SWGs. Cloud SWG has deeper SSL inspection controls and tighter integration with CloudSOC CASB and Symantec DLP. Zscaler has broader marketing presence and stronger automated SD-WAN partnerships. Both will block phishing URLs and inspect SSL. For organizations already invested in Symantec DLP or CASB, Cloud SWG offers tighter policy consistency.

  • 04

    Do we need SSL inspection? Is it legal?

    +

    Operationally, yes - without SSL inspection you see almost no web traffic content. Legally, it varies by jurisdiction and use case. Most enterprises run inspection with explicit user disclosure (acceptable-use policy) and an exception list for personal banking, healthcare, and similar sensitive categories. CyberKIS works with your legal and HR teams to draft the disclosure language and exception list before turning on inspection.

  • 05

    How do we get remote workers to use Cloud SWG?

    +

    WSS Agent is the dominant method - a lightweight forwarding agent on each laptop. Alternative: PAC file pushed via MDM, with split-tunnel rules. For most organizations the agent is simpler and more secure (PAC files can be bypassed; the agent enforces consistently).

06. // Pairs well with

// Get started

Ready to deploy
Cloud SWG / WSS?

Tell us your environment, current state, and timeline. We will come back with a fixed-scope plan.