Best Practices for Defining Policies

Policy Editor

Using the policy editor is straightforward, but there are some best practices to consider when defining policies for your organization: 

• Build your policies from the bottom-up.
  Your default policy (at the bottom of your list of policies) is the catch-all for all of the Identities you haven't defined a specific policy for. Try to make your default policy the one you want to be enforced if an unknown or unexpected device or user attempts to access the internet. As such, we recommend that you always either: 

• Make your default policy the most restrictive 
  or
• Make your default policy the one that you would want the majority of your users and devices to be governed by.
• Build your additional policies as exceptions, from least specific to most specific. 
  From there, you want to layer on policies from least to most specific. An example of this might be to make your first additional policy be for "All Roaming Computers", then layer another policy on top of that for a small number of Roaming Computers that have slightly different needs than the general population of Roaming Computers. By taking this "exceptions-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 policy for "All Roaming Computers", and then after the fact provision a number of new mobile devices, they automatically have that policy applied without you doing anything. As a best practice, these policies should be lower in priority than more specific policies or else they will take precedence over any policies which include those types of identities that they are above, and render those policies useless.
• Organize policy settings for re-use.
  Policy settings can be re-used in multiple policies, so keep that in mind when you create, name, and update these settings. A good example of this is destination lists. It is best to organize them so that multiple policies 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 policies according to location
  If you are using Cisco Umbrella with roaming or mobile features, you have the ability to create location-based policies. The most common example of this would be to first create a security-only (for example, no content filtering) policy for all of your roaming laptops, then create a more restrictive policy for your corporate network (which would be placed above the roaming laptop policy). This is counter-intuitive to previous statements above regarding organizing your policies from least to most specific, but in this case what it means is that when your roaming laptops enter your corporate network, they must adhere to the more stringent policies of the workplace. While they are outside of the network, however, they will have a layer of security wherever they go but are free to visit whatever websites they choose, as many users often use work laptops for some amount of personal browsing. 

Getting Started with Policies – Build your Policy

You build policies through the Policy wizard. You also use it to update existing policies.

By default, there's always at least one policy—the Umbrella default policy. This policy applies to all identities when no other policy above it covers that identity. In other words, the Umbrella default policy is a catch-all to ensure all identities within your organization receive a baseline level of protection.

Policies control the level of protection and logging, including which types of sites should be filtered. The Policy Wizard is the best way to start applying policies to the Identities you've created. For more details about Policies, read on! 

For more information on best practices for using policies after reading this Quick Start guide, click here to visit our Policy Precedence guide.

Step 1: Create your Policy

Step 2: Select Identities

1. In step two of the wizard, select any or all of the identities that you've created. If you chose Default Policy, all identities are selected.
   
   
   
   The identities you select determines to what these settings apply. This can be any combination of Identities available in your account. Categories (such as AD Computers for Insights) can be expanded to more selectively choose Identities to apply to a policy.

Step 3: Select Policy Settings

1. In step two of the wizard, configure content filtering, security, and destination list settings. 
   
   

• Category settings to enforce
  These settings filter types of content based on your Organization's acceptable use policies. By default, no content categories are blocked. A list of all categories and details for each can be found here.
  
  To create a new set of content filtering rules, click add new settings then update settings in the Category Settings editor. You can also update an existing setting by clicking it in the drop-down list. 
  
  

• Whitelist-Only mode—If checked, only domains explicitly allowed on a destination list will be allowed. Since many websites require many content domains, it may take some time to build a destination list.

• Security Settings to enforce
  These settings allow the configuration of which security type threats are blocked. Malware and Drive-By downloads, as well as mobile threats, cannot be disabled. Options include enabling blocking of DDNS-hosted domains.
  
  To create a new set of security filtering rules, click add new settings then update settings in the Security Settings editor. You can also update an existing setting by clicking it in the drop-down list. 
  
  The Intelligent Proxy may also be activated on select packages, and this allows for URL-based malware filtering for domains with legitimate content where some pages may contain malicious files.
  
  

• Destination Lists to enforce
  If you have particular domains you'd like to allow or block, add them to a destination list. There are two by default, block or allow, and you can create more to organize groups of internet addresses.
  
  To create a new set of destination list, click add new destination list. You can also update an existing list by clicking it in the table list. 
  
  Destination lists allow for the customization of filtering by creating a list of internet addresses that are explicitly blocked or allowed. Note that each destination list can be set to be a blocked list (default) or an allowed list. We recommend adding domains in the format "domain.com" rather than www.domain.com to ensure *.domain.com is included.
  
  Allowed list entries will always take precedence over blocked list entries. For example:

  • Blocking domain.com and adding mail.domain.com to the allowed list will still allow mail.domain.com. 
  • Adding domain.com to the Allowed List and blocking sub.domain.com will still allow sub.domain.com.

  Note: Destination lists are not saved until you click Save, despite appearing in the list view after entering it.

  For more information, please see our detailed article on adding/removing domains from a destination list.
  
    

Step 4: Select Block Page Settings

1. In step three of the wizard, configure block page settings.
   
   

• Block Page settings to enforce
  These settings allow for the customization of the block page. Choose a generic message across all block pages, or customize the message per type of block page. The block can also redirect to a custom URL.
  
  To create a new block page settings, click add new setting then update settings in the Block Page editor. You can also update an existing setting by clicking it in the drop-down list. 
  
  If not redirecting to a custom URL, a contact form can be added to allow blocked users to contact the administrator at the email provided.
  
  Finally, a custom logo can be uploaded to be displayed on the block page in place of the Cisco logo.
  
   

• Users that can bypass block pages
  Users who can log in to bypass block pages on this policy. A Bypass User must be checked on a policy in order for it to be active.
  
  To create a new bypass code, click add code.
  
  A bypass user can log in (when added to the policy) to bypass the selected type of block pages. Note that the user must already exist on the Dashboard to be added as a Bypass User (from System Settings -> Accounts).
  
  
  
  A Bypass Code must be checked on a policy in order for it to be active.
  
  Bypass codes can be created to allow blocked users to bypass the block page. When enabled for the policy, the selected categories and/or domains can be bypassed. Ensure that you set an expiration for the code or the default will expire within an hour. 

Step 5: Set Policy Details

1. Finally, in step four of the wizard, give the policy a good descriptive name and optionally enable logging
   
   To start, it's recommended that you enable logging to ensure that the desired settings are active. Logging settings are "Logging Enabled" for full logging, "Content Logging Disabled" for security logging only, and "Logging Disabled" to disable all logging.
   
    
2. Click Save.
   Policy settings are only saved after clicking Save. All changes will be lost unless you click Save.

Deleting a Policy

1. Navigate to Policies > Policy List and click the name of the policy to expand it.
2. Click Delete Policy.

Additional Dashboard Settings – System Settings

• Accounts—Use this setting to add and remove users from the Umbrella dashboard and set the user roles (to create roles, see Delegated Admin below.) For more information on adding a new user to the dashboard, see our adding a user article.
• Delegated Admin—Grant users partial privileges to the dashboard. For more details, see our article on Delegated Administration.
• Active Directory User Exceptions—Helps exclude service accounts from being recorded in the logging. For more details, read our article on AD User Exceptions.
• Sites and Active Directory—If your package includes Active Directory (AD) integration, this panel provides information and statuses of the AD components and Virtual Appliances (VAs). Download links and guides are also contained in this section. For more information, view our Active Directory Deployment Guide.
• Internal Domains—For use with the Umbrella roaming client. Here, configure domains that should be resolved to the local DNS server instead of to Umbrella. For more information, see our Internal Domains article.

For a more in-depth guide to policies, see our full Policy guide. For information about how to determine which policy is applied to an identity, read this article.

Next up: View Reports