Create Custom Content Filtering Rules
You will more than likely need to create policy rules that accomplish your corporate web use guidelines while ensuring the web resources required for your business remain available. For example, you might have applied a global block to a specific content category or web application, but now need to allow specific users or groups access.
Tip: To save time, create policy objects (Overview > Object Library page) that you know you will use multiple times. For example, a set of allowed domains or a group of categories.
In Solutions mode, select Content Filtering > Policy.
To launch the rule wizard, click Add Rule.
- The Conditions area is where you define the constructs of the policy rule. From who or where did the request originate? To where is it going? And does it apply to specific content or based on a time frame?
- The Verdict area is where you define the action to take if the rule is triggered.
Construct and Editor Tutorials
This example demonstrates what you can add to the Sources construct of the rule, including how to use the editor. Click Add Sources.
The policy editor is flexible, allowing you to select objects and existing lists as well as create new lists from objects within. Refer to the screenshot.
Select from objects that the WSS currently detects, such as usernames and group names provided by the authentication methods (Auth Connector or SAML IdP), IP addresses, and fixed locations. You can also select a Geolocation, which means the request originated from a specific country.
Tip: Geolocation policy requires an add-on license. See About Geolocation Policies for more details.
- If you have previously created custom lists in the Object Library (Overview > Object Library) or previously in the policy editor, select a List item.
The policy editor provides static objects that apply to all connections from those sources.
- Unauthenticated Users—A username that is not part of your corporate username database.
- Mobile Devices—Users who log in through a smartphone or tablet.
- WSS Agents—Users who log in from remote client systems that have the Symantec WSS Agent installed. These are connections from beyond the corporate network.
- The editor displays all of the objects that are available for this rule. Select one or more and click the right-arrow to assign them to the rule.
- You can also click New and select to create a new list or in applicable constructs a new object.
After completing your selections, perform one of the following.
- If this rule is intended for these sources only, click Save.
To add different source constructs, click the back-arrow (upper-left); repeat to add sources and click Save.
This creates an OR construct; the rule triggers if the content request originates from a source associated with any of the objects.
You can also continue to add sources that create an AND construct. Consider the following example.
The Admin clicked Add "AND" Group and added two fixed Locations as Sources. Now the rule is triggered by any user belonging to the events or pr groups AND from the specified Locations, one through a firewall device and one through explicit proxy.
This example demonstrates what you can add to the Destinations construct of the rule, plus how to create lists within.
Click Add Destinations. Select internet elements to which this rule applies. As with the Sources construct, you can create AND/OR policies.
- IP/Subnets and URLs/Domains—You might have a need to trigger policy when the destination is a specific server, such as a testing server, or a specific URL path.
- Category—Policy applies when the request is for websites that belongs to a specific content category. The Symantec Global Intelligence Network (GIN) continuously rates and classifies websites as they come online.
- Web Application—Policy applies when the request is for one or more of the thousands of web applications the WSS detects. This is also known as a Cloud Access Security Broker (CASB) discovery and policy solution.
Create a List
After you name, create, and save the list, it becomes available for future selection in other rules.
The final trigger Construct bases the rule on the following elements.
- Schedule—If you set a schedule, the rule applies only on the specified days and during the specified hours. For example, you might want certain content restriction rules to apply only during core business hours.
- Browser—Your company might elect to employees to use the most recent versions or even one specific browser vendor.
File Type—Trigger the rule if the request is for specific types of files, such as Databases or Audio and Music.
Actions—When paired with Web Application Destinations, you can provide a robust, granular policy. For example, you might allow access to various social networking sites, but want to prevent the uploading or downloading of photos and videos for specific applications.
This page provides an additional Filter field from which you can select a specific application and view what actions the WSS detects.
Conflicts with Actions and File Types
- Notice that some Actions are amended with an A. Rules that contain specific actions, such as File Upload, must be enforced during request before the actual upload request reaches the server. Such objects require the rule to be created in Group A.
- Notice that all File Types are amended with a B. For rules that contain specific actions, such as Executable, the Web Security Service must see the contents of the response so that it can detect whether it is actually an executable. Such require the rule to be created in Group B.
If you attempt to create a construct that contains incompatible elements, the WSS displays a red exclamation mark to indicate an error. You can roll over the letters to read an explanation. You must create separate rules to achieve your policy goal.
Now that you have created the conditions that trigger the policy rule, the final configuration is to instruct the WSS what action to take. This is called the Verdict.
- Allow: Completely—Users are allowed access to the content.
- Allow: Coaching—Before allowed content access, users must click a message that acknowledges their request for such content and that they understand their web activities are monitored. You can also change the interval between coaching message re-displays.
- Block—Users are denied access to the content.
- Block: Password Override—You can specify a password that you can distribute to users who request access to a blocked content. You can also change when the coaching message re-displays.
- Redirect—In addition to blocking access to the content, you can enter a URL that redirects users to a specific web resource. For example, when a user attempts to browse inappropriate content, redirect them to an internal web page that describes your corporate web use guidelines.
Now the that rule is complete, click Add Rule.
Based on the constructs, the WSS automatically inserts the rule to the bottom of Group A or B accordingly on the Content Filtering Rules page. However, you might elect to rearrange the rule. For example, you have a rule that takes an action based on a group membership but want to take some other action for a specific user.
To move that rule above the group rule, select the rule number to display a menu.
The orange triangles indicate that the policy is not yet activated. The WSS also displays policy discrepancies, which you must first resolve.
Click Activate to implement the policy.
Exempt URLs from Permanently Blocked Categories
The Group A G1 rule provides a construct for Permanently Blocked Categories. By default, Child Pornography is permanently blocked (others might be added in the future). It cannot be changed.
But you might have a requirement for specific users or groups to be able to access URLs that belong to a Permanently Blocked Category.
- In the editor menu bar, click Settings.
In the dialog, select Allow exemptions to Permanently Blocked Categories in Content Filtering.
The editor adds a new row designated as P1.
- Click the Permanently Block Source Exemptions and/or the Permanently Block URL Exemptions links and add exemptions as required.
Tip: This topic provides a high-level description of the rules editor. See Policy: How Do I? for use case examples.