In part 1 of this blog series on deployment best practices, we reviewed the three key success factors to streamline the transformation to zero trust architecture: a solution that’s menu-driven, scalable, and automated. Now that you’ve chosen a partner like Zscaler, and not just a vendor, let’s talk about three tips to make your deployment go smoothly: Start with identity, find your apps, and know your policy.
1. Start with identity
Who are you? How does your organization define your identity? In zero trust, we use identity and context to determine access. Verifying identity and context is the foundation of the architecture of the Zero Trust Exchange.
When it comes to your zero trust deployment, this means understanding your identity provider by asking the following about your data and users:
Data
- How does your identity provider get its data?
- Is the data entered manually?
- Does the data sync to your on-premises directory?
Users
- How are users grouped and arraigned?
- What user attributes are used?
- How accurate are they?
From here, it’s important to decide which attributes to use. For most organizations, this would mean using the common memberOf and department attributes. The memberOf attribute maps to the user’s assigned security groups. The department attribute maps to the user’s department.
However, with a product like Zscaler Private Access, any attribute can be sent from the identity provider and rules can be written to reference it. This means you can write rules based on: department, cost center, birth month, and so on. The key is knowing which of your identity provider’s values are most conducive to determining access in a zero trust environment.
2. Find your apps
Which applications keep you up at night dreading a call that users lost access? A legacy mainframe? A cloud ERP? The director’s executive assistant’s preferred scheduling solution?
At the beginning of your zero trust journey, take a moment and note these bellwether applications. Whether it’s private on-prem, private cloud, or a public SaaS, you’ll want to take note of what the application is, who has access to it, where it’s housed, and who controls it. This list should form the core of your functionality testing. It doesn’t need to be an exhaustive list, but it will ensure critical functions receive top priority. Don’t be afraid to include those applications that have small user bases but a big impact, especially custom and older apps. These can have hidden caveats.
With Zscaler Private Access, it’s important to know your key apps, but not necessarily to define every application at the start! ZPA supports application discovery, which allows you to build access policies for via wildcard domains and subnets. Using a wildcard domain allows ZPA to match on any fully qualified domain name (FQDN) using your domain. For example “*.department.gov” matches both “web.department.gov” and “app.department.gov”.
Using subnets allows you to define services and applications based on their internal IP. This method uses standard CIDR notation such as 192.168.1.0/24. From there, apps are discovered as they’re used. ZPA also supports one-click application definition from application discovery. When I work with clients in deployment, I ask them to name their top 5—10 key applications, then show them how to set up application discovery and use it to define the rest of their applications.
Application discovery applies a very wide policy, so it’s best to use it initially, not for an extended period. Note: with ZPA applications, the most specific match wins, meaning you don’t have to worry about a general rule for *.organization.gov overriding a rule for webserver.organization.gov.
3. Know your policy
Which policies and legislation govern your organization? What’s considered ‘acceptable use’ for your employees, customers, and guests? Who is allowed to post to social media?
Historically due to the costs involved with on-premises SSL inspection, a choice had to be made between inspection and performance. Zscaler ZIA lets you choose both thanks to its line rate SSL decryption that allows you to build policies that couldn’t be built before. Now you can easily decide to let everyone view social media, but only let authorized staff create posts. But this power goes beyond social media.
Who can upload and download files from file sharing sites?
Who can post videos and who can watch them? You can also restrict content types on YouTube.
Do you want to limit access to personal webmail but allow access to your organization’s webmail?
Understanding the current rules you have and their limitations will allow you to understand and explore how the Zscaler Zero Trust Exchange delivers more for you.
When deploying customers, I caution them against arbitrarily moving their old rules into Zscaler Internet Access. Most rule sets have accreted over the years and are in need of review. Additionally, their policies were written to run on a legacy platform. As noted above, those limitations are likely removed. What I recommend is to enable the default URL blocking rule (it blocks all the requisite categories that you would expect), default SSL inspection, and malware rules. From there, we can look at written policy and legacy rules and determine what we can do today.
In closing, I’m sure a long-dead general has an applicable quote about how knowing oneself is a key to victory. This may be true, but in the case of zero trust deployment, knowing your IT environment is the key to a successful and rapid deployment. Understanding how your Identity provider gets its information, and what information it gets, is key to understanding the breadth of criteria that can be used in policy. Knowing your key and bellwether apps allows your team to focus on the mission-critical (and keep phones quiet at night).
Lastly, knowing the formal guidance you operate under will allow you to leverage Zscaler fully to maximize security and enhance user experience.
