Catching up with Zscaler Internet Access (ZIA)

“Think and wonder, wonder, and think” - Dr. Suess

In my three and a half years as an employee at Zscaler, and five years before that as a customer, I’ve always been impressed by the pace of innovation across our platform capabilities. SaaS delivery means new features spring up all the time, many of which busy customers may or may not be aware of. Those that keep up with the innovations may still be reluctant to change anything that’s already doing what’s expected of it.

So when I’m speaking with customers about their cybersecurity posture, such as when conducting a routine policy review, I keep my mantra handy: Look for opportunities where controls can drive more prevention and automation with the lowest possible risk, cost, liability, and friction for each security control point.

Each customer has a different set of requirements and tolerance for the amount and types of friction a solution adds to information flow and, in turn, end-user productivity. What Zscaler customers have in common is that they rely on the Zscaler Zero Trust Exchange to reduce as much of that cost and friction as technologically possible across the cyber stack while maintaining the best security posture and overall risk level.

If you are a security leader you can ask yourself periodically, “Is the balance between control friction and protection where it needs to be today, and if not what else can and should I be doing? If you are using Zscaler Internet Access (ZIA), for instance, chances are you can be doing a lot more with it as there are many ZIA features, many of which are new or underutilized. (I, myself, have trouble keeping up and I work here.)

Below are six examples with my personal take in hopes of helping you further manage and mitigate risk, bring your configuration up to date, improve cyber hygiene, and hunt down needless risks.

Domain Generated Algorithms (DGAs)

Easy to implement and hard to block, DGAs allow threat actors to generate a large list of domain names to launch malware attacks that evade security countermeasures and provide continuous C2. The Advanced Threat Policy feature includes an option to block domains that are suspected to be generated by DGAs. You should enable it.

In addition to blocking these categories in the Advanced Threats Policy, blocking them via DNS Control ensures the action happens earlier in the killchain and applies to all traffic, including non-web traffic such as Secure Shell (SSH).

ZIA Device Posture

Most customers are familiar with device posture, which is a profile based on a set of criteria that a user’s device must meet to access applications with ZIA. When a user requests access to an application, the Zscaler Client Connector (ZCC) evaluates and sends the posture of the device to the ZIA Public Service Edge. The service edge allows access to the requested application only if the device meets the posture requirements. For users without ZCC, identity providers such as Okta and Azure send device context when users authenticate via SAML. In these instances, few customers utilize the device trust level selection.

Device trust is a great opportunity to go beyond recognizing a managed device versus unmanaged. To add posture profile levels for ZIA, you first need to create a baseline for device postures. While you can easily get carried away setting up postures, a simple approach is to establish a ranking for "High Trust", "Medium Trust", or "Low Trust" across operating systems. The devices that do not fall into any categorization of these trust levels are "Unknown" devices. Posture checks for all trust levels are evaluated by ZCC on the device and the highest matching level is used in ZIA posture or device trust level. Just keep in mind you need to assign a ZIA Posture profile in the ZCC App Profile beforehand.

Cloud Application Instances

If you have users that access cloud storage like Box but in every attempt, have a rule to redirect them to the official corporate instance of it if they are trying to access any other instance, you can be more granular and less draconian in your policy-making.

Cloud Application Instances allows you to create instances for cloud applications with specific instance identifiers (e.g., domains). The feature consists of two parts, the first is creating them and the second is associating the instance with the Cloud App Control and DLP policy rules. In the case of the Box example, you can create a rule so that all end user actions are permitted for the corporate instance. In unsanctioned instances, you can block key actions but permit those that pose little risk as the graphic below illustrates:

Custom Cloud Applications 

Custom Cloud Applications gives you greater flexibility when creating rules to control access to custom applications if it's not already present in Zscaler for discovery. You can also edit the status of all the cloud applications of your organization, in addition to the Application Information page, to one of the following application statuses:

• Sanctioned: If you approve the application for your organization's use because it meets all your security requirements
• Unsanctioned: If you don't approve the application for your organization’s use because of its vulnerability – attack ingress or exfiltration egress

In the example below, fine-grained rules determine that for an application called IceDrive, access is granted to users with managed devices running the ZCC, and only through a sanctioned browser. Additionally, for every session attempt, the device must pass High Trust posture control and a user must have a behavior risk score below 80.

Cloud Application Risk Profiles

The Cloud Application Risk Profile feature allows you to control how cloud applications are used in your organization. Within it is the Shadow IT Report which I recommend you use. It shows the number of sanctioned and unsanctioned applications in use and their number of users. It also shows the application categories, the risk index, and the certifications for each application. 

You can tag sanctioned apps and make calculated risks to help the business move forward while applying just enough friction to keep everyone safe. In the report below only 18 of over 10,000 apps have the highest risk index level of “5” which helps to put real risk into perspective.

You can create the Cloud App Control policy rules based on the cloud application attributes. In the above example, you can create a risk profile with the following criteria: Risk Index is 5 (AND) Application Status to Unsanctioned. This profile can be used as a foundational policy in all Cloud Application Categories to restrict high-risk, unsanctioned apps for that category (i.e., Cloud File Sharing, Hosting Providers, Instant Messaging, Webmail, etc.)

Data Discovery Report

The Data Discovery Report (dashboard) gives visibility and insight into your organization's data loss prevention (DLP) content based on your DLP policies and dictionaries and machine-learning data generated by an analysis of the content in your organization. The goal is to inform policy decisions so that you can better apply the zero trust tenant of least-privileged access. In the example below, you can see how easily you isolate the files in the top 10 ML categories and from there drill down to uncover sources where PII or PHI, for instance, can be leaking out of the organization and what to do about it with a variety of cloud app or file type controls.

As a final thought, we often forget that all vendor solutions are tools designed to solve a wide variety of problems but how one goes about solving theirs specifically is a bespoke endeavor that varies from one organization to the next. By exploring the ZIA features covered above and implementing those in ways that make sense for your organization, you shift to hunting risk, particularly that which can cause material harm, rather than tactically responding to it and you further extend the zero trust ideology to Internet-based apps. 

What to read next 

Zero trust: Getting pragmatic with policy enforcement - Part 1

Zero Trust: Getting pragmatic with policy enforcement - Part 2