Transcript
In this series of short videos, we'll be taking a look at recommendations for the configuration of URL filtering. This is part two, URL filtering policy. Let's start by looking at what the objectives are for good URL filtering policy. These are, first, protecting users and data from security threats, such as malware and data loss, second, limiting the business's exposure to liability by blocking access to inappropriate content, for example, pornography, hate speech, or drugs, third, reducing productivity loss caused by users accessing sites or cloud applications that do not serve a legitimate business purpose. To this end, Zscaler recommends you begin building URL filtering policy by starting from your corporate acceptable use policy. Next, it's recommended that you use the retain parent category option when creating custom URL categories, as this will ensure URLs can be evaluated against their original category, as well as any custom categories they are part of. This will make understanding your URL filtering policy and troubleshooting unwanted behaviors easier. As with other policy engines, it's recommended that you build policy in a top-down model, with the most specific rules at the top, since policy is evaluated in order. Zscaler recommends blocking the legal liability, malicious, and suspicious categories entirely. We also recommend creating a policy to caution users when they access URLs in the miscellaneous category, which is the category to which URLs belong when they have not yet been categorized. Finally note that the default behavior for the URL filtering module is an implicit allow. You should decide whether this is acceptable or whether you want to configure a default block policy and explicitly allow only select categories. Let's take a look at an example URL filtering policy. Here, as rules number 1 and 2, we start with global-specific allow and global-specific block rules. These rules are where you would control access to specific URLs belonging to categories that would otherwise be incorrectly allowed or blocked. Putting these rules at the top allows us to ensure exact matching works to our advantage. Rule number 3 is a global security-oriented block rule, and rule number 4 is a global legal liability block. These block specific categories for all users that are privacy or security risks, and legal liability risks respectively. Rule number 5 blocks the file host, webmail, and peer-to-peer categories for all users. Since URL filtering policy is evaluated after cloud app control policy, you can define allowed applications in these categories as part of your cloud app control policy, and this URL filtering rule will block all other cloud applications in these categories not explicitly allowed this way. Below rule number 5 is where you would place rules that apply only to specific users or locations, whatever those rules might be. Here, we recommend that you create these rules in a disabled state at first while building your policy, then enable all user-specific and location-specific rules at the same time to ensure policy is properly applied. The final rule, numbered 8 here, is the global category-based block rule. This rule is where you will select all URL categories you wish to block for all users. Placing it at the bottom ensures that it is evaluated after any of your specific allow rules. As a reminder, the default behavior for URL filtering is an implicit allow. This means any URL category not explicitly blocked will be allowed for your users. Next, here are a few things to look out for when creating and configuring URL filtering policy. First, when configuring custom URL categories for use in URL filtering policy, we recommend that you use FQDNs and not IP addresses. This helps make sure that destinations are correctly blocked or allowed based on your URL filtering policy when a user tries to access a URL, as users will generally be entering user-friendly FQDNs rather than IP addresses in their browsers. IP-based policy blocks should generally be implemented in Cloud Firewall policy instead. Next, under Advanced Policy Settings, you will find a number of toggles. At minimum, Zscaler recommends enabling the Suspicious New Domains lookup setting. This will allow you to create policy to block the Newly Registered and Observed Domains and Newly Revived Domains categories, which contain domains that are often used as part of phishing or malware distribution campaigns. We also recommend enabling the Enable Embedded Sites categorization setting. The remaining settings should be evaluated on the basis of your organization's security policies. Under Administration, Advanced Settings, it is also recommended that you enable all HTTP tunnel control settings. These settings will help prevent HTTP tunneling, which is a common method of obscuring traffic to avoid detection, by inspecting tunneled traffic and blocking tunneling on non-standard ports. Similarly, it's recommended that you enable the domain fronting protections in this section. Although domain fronting can have legitimate uses, it can also be used to disguise command and control traffic. Before enabling these settings, it's recommended that you review any instances of domain fronting observed in your logs to validate whether or not you need to configure exceptions, and that you continue to monitor logs for some time after enabling this setting. That's it for this video. Thank you for watching.
