Posted: 4 Min ReadProduct Insights

Roll Out SSE Components Without Getting Rolled Over

Say hello to your Symantec Cloud SWG Agent Traffic Manager (ATM)

Security Service Edge (SSE) adoption can feel risky. The big question on everyone’s mind: how can we level the risks of end-user deployment without disrupting productivity? Customers know SSE changes the flow of every packet, meaning even a small shift can impact your team’s workflows—so each step needs a steady hand.

The risk doesn’t go away after deploying your first SSE component, either. Most organizations roll out SSE components gradually to avoid disrupting business—starting with the proxy, then moving to cloud firewalls or Zero Trust Network Access (ZTNA). However, deploying a new component on top of an existing one produces the same risk faced with the first, all over again. To manage this, administrators need SSE-native controls over what capabilities are available to which users and when. 

The Cloud SWG Agent Traffic Manager (ATM) makes risk containment challenges a thing of the past. Accessible from your Cloud SWG portal via the Connectivity tab, ATM centralizes agent behavior management with a policy-based approach—like a universal remote control. With it, you can toggle agents or SSE features and create traffic intercept exemptions. Best of all, you can apply these controls to any office, user group, or even a single user for the ultimate fine-grained deployment control.

ATM: Riddle me these questions three

To do this, ATM policy tackles three key questions for every deployed agent:

1. Should this agent be active?

ATM allows administrators to define the conditions for active or passive agents. Passive agents do not direct user traffic to the cloud but check in periodically to see if the agent should switch to active mode, per administrator policy. Conversely, active agents establish a tunnel to Cloud SWG, sending intercepted traffic to the cloud for filtering. Active/passive controls help safely roll out the agent into an active state one group or location at a time. Some customers use it to set the agents to passive when users are in the office and active when remote. 

2. What should this agent intercept and send to the cloud?

You can control exactly which traffic each agent intercepts with ATM. Administrators can create rules based on user or group membership, location, egress address, and other conditions. ATM intercept rules are organized in an order-based system, offering flexibility and control over which services are intercepted and redirected to the cloud. The services that ATM can manage include:

  • Cloud SWG (Symantec cloud proxy service)
  • Zero Trust Network Access
  • CloudSOC CASB Gateway
  • DNS Proxy
  • Cloud Firewall

The control doesn't end there. Administrators can further refine configurations with exceptions to the rules.

3. What exceptions are there to the intercept rules?

There are always exceptions. The most common bypass in an SSE agent is for internal resources. The cloud proxy can’t access internal websites, so this traffic should stay local. ATM makes it easy to create bypass rules that tell the agent what to ignore. If you’re deploying ZTNA, you can even access private apps through our cloud, reducing the need for local bypass. ATM bypass rules can target specific domains, IPs, and executables and apply to individual users, groups, device tags, and locations. 

With the power and flexibility of ATM bypass rules, you can ensure that bypasses are applied only where needed, minimizing potential gaps in coverage. This also lets employees working at customer sites trigger bypass rules when online in those locations. 

Powerful new ways to identify devices and trigger ATM rules

Assigning Device Tags to agents based on customizable criteria creates nearly limitless rule options. For instance, you could write a script that checks for OS version on the endpoint and set a device tag on the agent if it matches a particular version. ATM intercept rules can trigger when that tag is present, making it possible to narrow ATM rules by OS version or almost any other factor you can dream up. 

Another ATM Device Tag use case is to limit ZTNA usage to devices that have migrated off the legacy VPN. Device Tags can easily identify VPN-connected devices, tag the agent and then write an ATM policy that enables ZTNA intercept based on the VPN state.

Real-world ATM use cases

ATM’s policy-based controls simplify complex deployments, allowing administrators to manage agent states, enable services and set exceptions from a single location in the Cloud SWG portal. Here’s how customers can put it to use:

  • Selective intercept. With ATM, you can start by intercepting only ZTNA traffic and add Cloud SWG intercept later. For example, you can configure agents in the Washington office to intercept ZTNA traffic for private applications, with Cloud SWG intercept introduced once the ZTNA project is completed.
  • Gradual service deployment. Roll out services like Cloud Firewall incrementally, starting with a specific team, such as IT practitioners in a specific office. As confidence in the configuration grows, the rollout can extend to the entire IT team and eventually to the entire organization.
  • Temporary measures. For unique needs—such as protecting an employee at a cybersecurity convention—a policy rule can route DNS traffic through the DNS Proxy without affecting other users.
  • Cloud-managed installation and management. Deploy agents in a "heartbeat" mode using software deployment solutions like SCCM or JAMF. The agent creates a secure tunnel and reports a successful connection without intercepting traffic. It then continues sending a heartbeat through the tunnel, allowing the admin to enable services when required.
  • Automation. Device Tags simplify automation, such as keeping agents inactive until machine reimagining processes complete. Just have your deployment automation add a Device Tag for install_hold and write a rule to keep devices with that tag inactive. Once your automation completes, it can remove the tag, bringing the machine online securely.

ATM puts you in control of SSE component and rollout steps. It facilitates seamless agent deployment, temporary service enablement, gradual service rollouts, and full utilization of an extensive product portfolio.

What’s next for your Symantec ATM?

ATM is rolling out in two phases. The first release is available now and provides the interception capabilities described above. Enhanced passive control, Device Tags, and bypass functionalities are slated for a November 15th release, so stay tuned. 

For any questions or technical support, visit Broadcom Security Support.

Symantec Enterprise Blogs
You might also enjoy
3 Min Read

Data Protection Made Simple

Now available: Symantec DLP 16.1

Symantec Enterprise Blogs
You might also enjoy
5 Min Read

Securing Your Foundation

Why you need host-based access control

About the Author

Dori Varas

Senior Product Manager, SASE, Zero Trust

Dori is a Senior Product Manager in Symantec’s Zero Trust Information Security Group and is the product owner for Mirror Gateway.

Want to comment on this post?

We encourage you to share your thoughts on your favorite social platform.