What's the general methodology for controlling bandwidth in Zscaler?

Let's discuss the thought process for defining and implementing bandwidth control in Zscaler.

What's the general methodology for controlling bandwidth in Zscaler?
Photo by ui-martin / Unsplash
💡
This is part of an on-going series in cybersecurity foundations. Check the cyber 101 article tag index from time to time for more content.

Bandwidth (especially internet-facing bandwidth) is a finite resource. In some enterprise environments it might be more, while in other environments it might be less. Ultimately though, there's only so much "water that can flow through a pipe". That's why bandwidth control features are very important. In today's article, I'd like to discuss the methodology for defining process and policies from a Zscaler perspective.

How big is the pipe?

The first thing to identify is the overall bandwidth constraints from an internet perspective. This comes in two forms:

  • Download (Mbps)
  • Upload (Mbps)

To be clear and explicit, the values we're talking about here is the potential upper limits of traffic that could/would be going through Zscaler. We're not counting the bypassed traffic like site-to-site SD-WAN communication, private links, etc.

What data falls in what categories?

Once the upper limits are known to Zscaler, we'll need to define the groups of data we're prioritizing by sorting them into "bandwidth classes".

Sorry, I couldn't resist an opportunity to include a slightly relevant comedy reference pun.

From a technical perspective, a bandwidth class is just a traffic category label. It can be based on:

  • Pre-defined URL Categories
  • Pre-defined cloud application definitions
  • Custom domains as defined by the Zscaler admin.

So you might be thinking: "OK, Mike. How do I determine which apps get a 'fast lane' for internet access in my environment?" For that, it's often best to passively monitor traffic first. Zscaler has a few dashboards and reports that can be helpful including QBR Reports and Web Insights. My general recommendation is to collect at least a solid week or two of data. That way you're capturing multiple elements of the business processes (weekend maintenance, multiple work-shifts, etc). In other words, let the logs and analytics give you meaningful visibility before enforcing an overzealous policy.

What are the enforcement rules?

Once you've captured the speed constraints (download/upload limits) and data categories (class definitions), the last technical piece is building bandwidth control rules. Rules are where this all comes together. Each rule lets you define:

  • Bandwidth Classes
  • Locations
  • Location Groups
  • Time
  • Protocols
  • Minimum bandwidth - This defines the minimum percentage of bandwidth to leave available for this matching rule/data.
  • Maximum bandwidth - This defines the maximum percentage of bandwidth to allow the matching data to consume. It's used as a capacity limit for undesired network traffic.

For more information on this topic, check out the following resource:

https://help.zscaler.com/zia/about-bandwidth-control