Best Practices for the Web Policy and Rulesets

When configuring the Web policy, adding rulesets, ordering them, and then having them protect your organization and systems exactly how you need them takes planning and an understanding of how Umbrella's Web policy and its rulesets work. We strongly recommend that you plan your Web policy and its rulesets before you start adding rulesets to Umbrella's Web policy. To help you get started, we recommend that you first read through all of Umbrella's Web policy documentation. Decide before you start as to how you want Umbrella to protect your organization and systems.

Certificates
Various features of the Web policy require that you install a root certificate. Both HTTPS inspection and Umbrella block pages require that you install a root certificate in every browser that will be used. We recommend that you install certificates before you start configuring the Web policy and add rulesets. For more information see, Manage Certificates.

Web Policy and ruleset behavior
Umbrella Web policy enforcement works on the principle of implicit allow. Meaning, if something is not explicitly blocked, such as a security category or a destination, Umbrella allows the transaction. Some transactions can be explicitly allowed; for example, destination or application requests. Explicitly allowed destinations cannot be explicitly blocked, except in the case of anti-virus (AV) or AMP file reputation matches.

The Web policy's rulesets are evaluated toward an identity starting at the top of the ruleset list and moving downward until a match is made. The first identity to match a ruleset is the ruleset enforced. Umbrella stops evaluating and the matching ruleset’s settings are applied. However, rules within the matching ruleset are matched on both identity and destination. Even if the identity matches a rule, if the destination does not match, the next rule is evaluated. This continues until there is a match or all rules have been exhausted. If there is no match, the default of implicit allow is applied. Therefore, always configure your rulesets and their rules so that the first ruleset listed that includes a particular identity also includes all configuration settings including rules destinations that you want applied to that identity.

Build your ruleset from the bottom-up—start with the Default ruleset
For the Web policy, the Default ruleset—listed as the Default Web Policy—applies to any identity that does not match any other ruleset. Therefore, it is the ruleset of last resort. If you have an identity that is not selected for a ruleset, the default ruleset is applied to that identity. Your default ruleset is the one that you rely on if an unknown or unexpected device or user attempts to access the internet from within your organization's network. As such, we recommend that you always make the default ruleset your most restrictive ruleset. Consider making your default ruleset the one through which the majority of your users and devices are governed.

Build additional rulesets as exceptions to the default ruleset, from least specific to most specific
After configuring the default ruleset, build additional rulesets from least to most specific. For example, you might create an additional ruleset for "All Roaming Computers", then layer another ruleset on top of that for a small number of roaming computers that have slightly different requirements. By taking this "exception-based" approach you are less likely to encounter any unintended results.

Utilize the top-level groups of identities when possible
Top-level groups like "All networks" and "All Roaming Computers" are special because they dynamically inherit new identities. This means that if you create a ruleset for "All Roaming Computers", and then, after the fact, provision several new mobile devices, they automatically have that ruleset applied to them. As a best practice, these rulesets should be lower in priority than more specific rulesets or the top-level group ruleset will take precedence over any rulesets which include more specific identities, rendering those rulesets useless.

Organize settings for reuse
Various policy settings can be reused across rulesets, so keep this in mind when you create, name, and update settings. For example, destination lists. It is best to organize destination lists so that multiple rulesets might use a general-use destination list (for example, "Block Social Networks") and create exception lists for those one-off situations where the destination list is unlikely to be used elsewhere.

Layer your rulesets according to location
If you are using Umbrella with roaming or mobile features, you can create location-based rulesets. The most common example is to first create a security-only ruleset (for example, no content filtering) for all of your roaming laptops, then create a more restrictive ruleset for your corporate network—ordered above the roaming laptop ruleset. This is counter-intuitive to the idea of organizing your rulesets from least to most specific, but in this case, it means that when your roaming laptops enter your corporate network, they must adhere to the more stringent rulesets of the workplace. While they are outside of the network, however, they will still have a layer of security wherever they go but are free to visit whatever websites they choose.

Keep your destination lists small
While Umbrella can support up to 5000 destinations in a single destination list, that many destinations in a single destination list has an impact on Umbrella's performance. A list of that size might take over one hour to load into Umbrella's infrastructure. We recommend that for peak performance, you keep your destination lists small—no more than 100 destinations per destination list.

Limit a ruleset to less than 100 rules
Umbrella can support up to 100 rules per ruleset. To minimize the load time of the Umbrella policies, we recommend that you keep the number of rules defined in a ruleset small—no more than ten rules per ruleset.

Configure the Secure Web Gateway
Configure the secure web gateway with HTTPS inspection to decrypt and inspect web traffic. We do not recommend that you apply the same deployed identities in both your DNS policies with the intelligent proxy configured and Web policy rules with SWG controls enabled. Choose the type of policy, deployments, and configuration components that best match the identities and traffic in your organization.

---

Web Policy Precedence < Best Practices for the Web Policy and Rulesets > Manage Global Settings