Rules Engine Concepts

Updated 3 months ago by admin

At the core of the Web Security product is a flexible Rules Engine that determines how to control and monitor web activity. An understanding of the Rules Engine is important to get the most out of Web Security.

The Rules Engine also controls and monitors cloud applications, if the Cloud Applications Security product is licensed.

Rule types

The Rules Engine processes web activity by your users according to Rules defined in the Web Security product. Two types of Rule are available: Filter Rules and Feature Control Rules. Active Rules are applied to all web traffic captured by the deployed Agents for the given Unified Security Account.

Filter Rules

Filter Rules consist of

  • Conditions: ways to identify web traffic
  • Matches: what you're looking for in identified web traffic
  • Actions: what to do with matched web traffic

Feature Control Rules

Just like a Filter Rule, a Feature Control Rule has Conditions and Matches. A Feature Control Rule is specific to a third-party web application, and can be used to permit, limit or deny features of that third-party application.

Rule Conditions

Both Filter Rules and Feature Control Rules always have at least one Condition, although a Rule can have more than one Condition.

Active Directory Username

The web traffic request must originate from at least one of the selected Active Directory users (based on sameaccountname, which is captured by an endpoint agent or network gateway).

Active Directory Organisational Unit

The web traffic request must originate from a user who is a member of at least one of the selected Organisational Units.

Active Directory Security Group

The web traffic request must originate from a user who is a member of at least one of the selected Security Groups.

Device

The web traffic request must originate from either an IP address or MAC address of the selected device.

The use of IP address or MAC address is governed by the Device Identification Method setting.

Device Group

The web traffic request must originate from either an IP address or a MAC address of a device belonging to the specified Device Group.

Device Type

The web traffic request must originate from one of the selected Device Types.

Tag

The web traffic request must be tagged with one of the selected Tags. Tags are applied to agents via Configuration Profiles.

Time

The web traffic request must have a timestamp that lies within the selected day of the week, day of the month, month, or specified time-span.

Rule Matches

Filter Rules and Feature Control Rules both use Matches, but the available Matches differ for each type of Rule.

Matches for Filter Rules

Web Category

The requested URL must be categorised in at least one of the selected web categories.

Custom URL

The requested URL must match a pattern found in at least one of the selected URL categories.

Keyword Category

The requested URL (or App Action Value, if the Cloud Application Security product is installed) must match a pattern in the selected Keyword Categories.

Keyword Categories can match the URL, the App Action Value, or both. The determination as to which type of match is used is made when creating or editing the Keyword Category itself.

Read more about Keyword Categories

If the Cloud Application Security product is licensed, additional Matches will also be available:

Specific Class

The requested App Action Value must be for an App that belongs to at least one of the selected Cloud Application classes (from the App Catalog). A class is essentially a grouping of apps by their type. For example, File Storage, Cloud CRM or IaaS.

Specific App

The requested App Action Value must be associated with at least one of the selected Apps from the App Catalog.

You won't be able to add a Specific App Match unless you have first added a Specific Class Match and selected only one Cloud Application class.
Specific Action

The requested App Action Value must be associated with at least one of the selected actions from Apps in the App Catalog.

You won't be able to add a Specific Action Match unless you have first added a Specific Class Match (with only one Cloud Application class selected) and a Specific App Match (with only one App selected).
As you add more Specific matches, the rule builder will automatically group the Specific options together which indicates they are linked. All of the matches contained in the red border must be true for the rule to match.
It's not possible to select Apps or Actions across multiple classes or apps in the same rule. If your policy requires this, create a separate rule for each scenario.
Generic Action

The App Catalog contains thousands of actions across hundreds of apps, so to make this more manageable the actions are grouped into what is known as Generic Actions.

The requested App Action must be for at least one of the selected generic Cloud Application actions. Generic Actions apply across all apps in the App Catalog, rather than specific Apps. Examples of Generic Actions are uploading a file or posting a public message.

Cloud Risk Level

The request must be for a Cloud Application action that meets selected Risk Level. You can use the toggle to choose whether the Match will trigger for requests below the selected Risk Level, or above it.

For example, a Match of "Below: Cloud Risk Level -> High" will match any request categorised as Average risk or Low risk.
If the selected action is associated with a custom Risk Level, this will override the Baseline Risk associated with the action. If this is used in conjunction with the Generic Action or Specific Action matches, then the Risk Level will apply to the actions specified using AND logic. For more information about custom Risk Levels, see the App Catalog.

Matches for Feature Control Rules

If the request is for a Google search engine result, enforce the strict Safe Search feature to block adult content. This will override the user's own preference settings.

Google Safe Search can also be enforced globally on a gateway, rather than on a Rules-based level. In this case, the settings on the gateway will override the Rule.
Disabling Safe Search after it has been enforced will not disable Safe Search on the end-user's machine, because the user's machine will have a local cookie stored that will override the request. After the Google Safe Search Match has been disabled, end-users will need to manually re-enable it in their Google search engine settings.

If the request is for a Yahoo! search engine result, enforce the strict Safe Search feature to block adult content. This will override the user's own preference settings.

If the request is for a Bing search engine result, enforce the strict Safe Search feature to block adult content. This will override the user's own preference settings.

If the request is for a YouTube video search result, enforce the strict Safe Search feature to block adult content. This will override the user's own preference settings.

YouTube for Schools

If the request is for a YouTube video search result, insert the YouTube For Schools header with the given token. This will cause the search to be executed as if it came from a YouTube For Schools account.

You will need a unique X-Youtube-Edu-Filter token to be able to correctly configure this Match.
Google App Domain

If the request is for Google Apps, restrict the request to the specified domain.

You will need a X-Google-Apps-Allowed-Domains token to be able to correctly configure this Match. This token can simply consist of the domain(s) to which you want to restrict access. For example, mydomainname.com.
Google Safe Search, Yahoo Safe Search, Bing Safe Search and YouTube Safe Search are reliant on data provided by third-party data sources. Therefore, the actual content blocked is outside the control of the Unified Security Service Web Security product.

Rule logic

Rules can consist of multiple Conditions, Matches and match values. When more than one options is chosen, Web Security uses intelligent logic to determine the correct way to proceed.

Rule logic for Conditions

Conditions use AND logic, which means that each Condition added to the Rule must be true. However, the options selected within each Condition use OR logic (meaning that the option will match if one or more of the selections are true.

An easy way to think about the difference between OR logic and AND logic is that OR means "any of the options", and AND means "all of the options".

In the example above, two Conditions have been added. In order for this Rule to trigger, both of these Conditions must be true. In this case, the web request must match a specific Active Directory group and the request must occur within a specified time-frame. However, the AD Group Condition has two groups selected within it (the 'Account Operators' group and the 'Administrators' group). The AD Group will match either of these groups. So, if a request comes from a user who belongs to the 'Account Operators' group but not to the 'Administrators' group, this Rule will still trigger (as long as the request occurs within the specified time-frame).

Rule logic for Matches

In contrast to Conditions, Matches can use either AND or OR logic, depending on your requirements. Matches use OR logic by default.

In the example above, because the match logic has been set to AND, both Matches must be true in order for this Rule to trigger. So, the request must match the selected URL category and must also match the selected Web category.

Rule Actions

Rule Actions determine what should happen if the Conditions and Matches in the Rule are true.

Feature Control Rules do not have Actions.

When a Rule is first created, it will by default have an Action of Block, along with a Log Level Action of 'Normal'. You can easily add additional actions, or override these defaults, by dragging from the Actions panel to the Selected Actions column. There are several potential Actions available:

Allow

Allow the web request to proceed.

Block

Remember to also apply a Template action.

Stop the web request. The user will instead be shown the specified HTML template.

Time Quota

Remember to also apply a Template action.

If the user's Time Quota has not been exceeded, the web request is allowed to proceed, and the user's Time Quota is reduced accordingly. If the user's Time Quota has been exceeded, the final Action is automatically switched to a Block action.

Quota usage is reset at midnight, relative to the agent timezone.
Apply to

Determine exactly how the remaining Time Quota is calculated:

  • User only: the quota is associated with the captured username. This user will be able to use the quota if they are logged in on other devices.
  • Device only: the quota is associated with the captured device (based on MAC address). Any user making a web request from that device will consume time from the same Quota.
  • User & Device: the warning is associated with the captured username and the captured device. Quota will only be consumed if both username and MAC address are present.

The default option is 'User & Device'.

Allow for (minutes)

The number of minutes for which the user is allowed to access the target site, after the Continue button is pressed. The minimum is 15 minutes, and the maximum is 23 hours 55 minutes.

Warn

Remember to also apply a Template action.

The web request is stopped, and the user is instead shown the specified HTML template. If the template contains the placeholder text $WARN$, a Continue button will be available, so that the user can still access the blocked content if they deem it acceptable.

The Warn action can also be configured to require a password before the user is allowed to proceed.

Apply to

Determine exactly when the warning template is shown:

  • User only: the warning is associated with the captured username. This user will be able to use the warning feature if they are logged in on other devices.
  • Device only: the warning is associated with the captured device (based on MAC address). Any user making a web request from that device will be able to use the warning feature.
  • User & Device: the warning is associated with the captured username and the captured device. The warning feature will only be available if both username and MAC address are present.

The default option is 'User & Device'.

Allow for (minutes)

The number of minutes for which the user is allowed to access the target site, after the Continue button is pressed. The minimum is 15 minutes, and the maximum is 23 hours 55 minutes.

Password

If a password is entered into this field, a user will not be allowed to proceed beyond the Warning page until the correct password is entered.

If you don't require a password, just leave the Password field blank.

Redirect

Stop the web request, and redirect the user to the specified URL.

Log Level

Choose the level of priority against which you want this web request to be logged. The default Log Level is 'Normal'.

Rule Priority

The Rules Engine executes each Rule in turn, in the order they appear on the Filter Rules screen, from top to bottom. You can easily change the priority order by dragging and dropping.

A good rule-of-thumb is to have the most specific Rules at the top of the list, and the broadest Rules at the bottom.

MIME Type

Choose the MIME type against which to match this action.

MIME categories are global. There are over 450 MIME types in the category list. If you have a need to filter against a MIME type that is not currently included in the list, please contact your service provider.
Use caution when selecting the Executable Binary category. It's not a requirement for web servers to return the correct Content-Type header (which is what indicates the MIME type). In fact, it's quite common for for executable binaries - particularly malware - to be sent with a Content Type of plain/html.

Template

Use this Action in conjunction with other actions such as Warn, Time Quota or Block. The Template action indicates which pre-defined HTML Template should be shown to the user.

Request versus Response scanning

An Action can either be "request-based" - in which case the Action is performed on the user's web request as it's made - or "response-based" (in which case the Action is performed against the web response that is returned when the user's web request has been carried out.

  • A request-based Action will be indicated with a icon.
  • A response-based Action will be indicated with a icon.


How did we do?