New Capabilities Following the Agent Traffic Manager Release

Products

• Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

What are the new features with Agent Traffic Manager for Cloud SWG?

Resolution

Until now, the deployment of Cloud SWG security services, such as DNS Proxy, Cloud Firewall, or Zero Trust Network Access has been an all-or-none configuration. This meant that admins had to resort to multiple accounts and creative deployment scenarios to implement different configurations, bypasses, selective intercept, and locations to achieve their business requirements. The net result of this was a complex and difficult-to-maintain configuration that was fragile and could result in unexpected agent behavior. 

Now that the Agent Traffic Manager (ATM) is enabled on your tenant, these workarounds are a thing of the past.

Located in your portal under the Connectivity tab, the Agent Traffic Manager introduces a new policy-based construct to define the behavior of agents that connect to Cloud SWG.  The Agent Traffic Manager helps you address three main questions for every agent deployed within your organization:

 

First - Should this Agent be active? 

Admins now can define under which conditions agents are active or passive. Passive agents are completely inactive, as if the agent were not even installed. Active agents establish a tunnel to Cloud SWG, which leads us to the next question… 

Second - What does this Agent do?

The Agent Traffic Manager is used to granularly define which agents intercept which traffic. Admins can specify rules based on user or group membership, location or egress address, and other conditions. Use these conditions in an order-based set of rules that offer flexibility and control in defining the services that are intercepted and redirected to the cloud service. The services that Agent Traffic Manager can control are: 

• DNS proxy 
• Cloud Firewall
• Cloud SWG web filtering for standard web ports or any subset of ports
• CloudSOC CASB Gatelets integration 
• Zero Trust Network Access

And it doesn’t stop there - further configuration is still available as we answer the next question…

Third - What exceptions are there to the rule? 

There are always exceptions to the rule - maybe you have one user that needs access to a training website, or maybe a specific department should not have access to one specific internal resource. To achieve these requirements in as narrow a scope as possible without opening up exceptions to the entire user population, the Agent Traffic Manager allows admins to define bypasses for specific domains, IPs, and executables and apply them to individual users, groups, and locations. Only matching individuals will get these bypass rules. Define the criteria for bypasses, allowing the agent to ignore certain types of traffic only for the individuals matching the rule. 

 

This sounds great - do you have specific examples? 

The policy-based controls that the Agent Traffic Manager exposes makes complex deployments much easier to define. This enables the administrator to define agent states, enable services, and offer exceptions from a single location in the Cloud SWG portal. 

 

Some concrete examples: 

1. Intercepting just a single service (for example, Zero Trust Network Access) becomes possible without the requirement to redirect all traffic through Cloud SWG. Our users in the Washington regional office should have their agents intercepting ZTNA traffic going to the organization’s private applications when working from the office. This is achieved with the following policy rule.

2. Gradual deployment of services (for example, Cloud Firewall) across your entire employee population becomes lower-risk and controlled. First, we can build a policy allowing the Support team in the regional office to start the testing. 

Then, as we grow confident in the service configuration and policy, we extend the trial to the entire Support team regardless of their location. 

As a step before full coverage, the DevOps group asks not to be included in the rollout for an additional 2 months. We can create a policy to enable the service for the entire organization other than the DevOpS group. They will continue to only leverage Cloud SWG web browsing capabilities. 

3. Stopgap measures can easily be implemented to account for unique customer requirements. For example, an employee is traveling to a cybersecurity convention where DNS based attacks are very common. We can create the following policy rule instructing the user’s agent to be using the DNS proxy. No other user in the organization is affected. 

4. Agent installation and management becomes cloud-managed. We can roll out the agent in “heartbeat” mode by pushing the agent installation file to all of our users at the same time using our software deployment solution (SCCM, JAMF, etc.). Upon successful installation the agent creates a secured tunnel to the service and reports a successful connection. It does not intercept any traffic or impact the user. Once we are ready to enable services we can do so as described in #2 

From the preceding examples we can see the true strength of the Agent Traffic Manager. It enables seamless agent deployment, temporary service enablement, gradual service rollout, and full utilization of our extensive product portfolio. 

 

I’m sold!  What’s next?

Agent Traffic Manager will be delivered in two separate releases. The first release is available for all customers right now, and provides the capability to control the services as described above. Improved passive control and bypass will be released in the near future.

Agent Traffic Manager is available in our public infrastructure and will be rolled out to the FedRAMP environment towards the end of the year. 

Questions? Contact technical support by visiting: https://support.broadcom.com/security.