Skip to main content

Check out Interactive Visual Stories to gain hands-on experience with the SSE product features. Click here.

Skyhigh Security

Filtering Process

A filtering process is performed on Secure Web Gateway that uses the implemented rules to ensure web security for your network. This process blocks attempt to access the web that does not comply with your web security policy and allows those that are compliant.

The process is performed in different cycles.

  • Request cycle — Filters requests for web access submitted by users in your network
  • Response cycle — Filters responses to requests sent by web servers to your network
  • Embedded object cycle — Filters embedded objects, for example, files or archives, sent embedded in requests or responses.

Only one filtering cycle is going on at a particular point in time on Secure Web Gateway.

The rule sets of your web security policy can be configured differently with regard to these cycles. A particular rule set can apply to all cycles, or only to one, or to any combination of them.

Properties of filtered objects

The activities that are performed by rules on Secure Web Gateway can be seen as parts of a comprehensive filtering process. This process filters web traffic that is caused by the web usage of the users within your network.

This process filters web traffic. It blocks some objects and lets others pass through, like a tea sieve or strainer that catches the tea leaves and allows the liquid to flow through its perforations.

How does the process tell the tea leaves from the liquid? The tea strainer obviously uses size as a key concept. If something is too big, it cannot pass through.

Similarly, the filtering process on the appliance uses in its rules all kinds of properties that web objects can have or that are related in some way to web objects to make filtering decisions.

A property of a web object checked in the filtering process is, for example, being virus-infected. A web object can have the property of being virus-infected, put more simply, it can be virus-infected.

Other examples could be the property of belonging into a particular URL category or the property of having a
particular IP address.

The following can then be asked about these and other properties:

  • For a given web object, what value does property p have?
  • And: If this value is x, what action is required?

Giving an answer to the second question leads to a rule:

If the value of property p is x, action y is required.

A property is a key element in every rule on the appliance. Understanding the property is essential to understanding the rule.

When you are creating a rule, it is a good idea to begin by thinking about the property you want to use. Using a property of an already existing rule as an example, you might consider something like the following:

I want to filter viruses and other malware. I use the property of being virus-infected and build a rule around it. I let this rule require a blocking action to be taken if a given web object has this property.

The rule could look as follows:

If being virus-infected has the value true (for a given web object), block access to this object.

The web object could, for example, be a file that a web server has sent because a user of your network requested it and that is intercepted and filtered on the appliance.

Properties and rules are explained in this section using normal language. However, the format they have on the user interface of the appliance does not differ from this very much.

For example, the above rule about virus infections could appear on the user interface as follows:

Antimalware.Infected equals true –> Block (Default)
where Antimalware.infected is the property and Block is the action, which is executed in the default way.

The arrow does not appear on the user interface, it is inserted here to show that the blocking action is triggered if a given web object really has the property in question.

Filtering users

Properties can be related to web objects, but also to the users that request them.

For example, a rule could use the property user groups that user is member of to block requests sent by users who are not in an allowed group:

If user groups that user is member of (for a given user) are not on the list of allowed groups, block requests sent by this user.

Filtering cycles

The filtering process on the appliance has three cycles: the request cycle, the response cycle, and the embedded objects cycle. Only one of them can go on at a given moment.

The request cycle is performed for filtering requests that users of your network send to the web, the response cycle is for the responses received upon these requests from the web.

When embedded objects are sent with requests or responses, the embedded objects cycle is performed as an additional cycle of processing.

An embedded object could, for example, be a file sent with a request to upload a file and embedded in this file. The filtering process begins with the request cycle, filtering the request and checking the file that is requested for uploading. Then the embedded objects cycle is started for the embedded file.

Similarly, the response cycle and the embedded objects cycle are started one after another for a file that is sent in response from a web server and has another file embedded in it.

For every rule on the appliance, it is specified in which cycle it is processed. However, the cycle is not specified individually for a rule, but for the rule set that contains it.

A rule set can be processed in just one cycle or in a combination of cycles.

Process flow

In the filtering process, the implemented rules are processed one after another, according to the positions they take in their rule sets.

The rule sets themselves are processed in the order of the rule set system, which is shown on the Rule Sets tab of the user interface.

In each of the three cycles, the implemented rule sets are looked up one after another to see which must be processed in this cycle.

When a rule is processed and found to apply, it triggers an action. The action executes a filtering measure, such as blocking a request to access a web object or removing a requested object.

In addition to this, an action has an impact on the filtering process. It can specify that the filtering process must stop completely, or skip some rules and then continue, or simply continue with the next rule.

Processing also stops after all implemented rules have been processed.

Accordingly, the process flow can be as follows:

Implemented Rules  Process Flow

 

 

All rules have been processed for
each of the configured cycles
and no rule has been found to
apply.

Processing stops.

 

  • In the request cycle, the request is allowed to pass through to the appropriate web server.
  • In the response cycle, the response sent from the web is forwarded to the appropriate user.
  • In the embedded objects cycle, the embedded object is allowed to pass through with the request or response it was sent with.

Processing begins again when the next request is received.

 

 

 

 

A rule applies and requires that
processing must stop
completely.

Processing stops.

An example of a rule that stops processing completely is a rule with a
blocking action.

If, for example, a request is blocked because the requested URL is on a blocking list, it is no use to process anything else.

No response is going to be received because the request was blocked and not passed on to the appropriate web server. Filtering an embedded object that might have been sent with the request is also not needed because the request is blocked anyway.

A message is sent to the user who is affected by the action, for example, to inform this user that the request was blocked and why.

Processing begins again when the next request is received.

 

 

 

A rule applies and requires that
processing must stop for the
current rule set.

Processing stops for this rule set.

The rules that follow the stopping rule in the rule set are skipped.

An example of a rule that stops the processing of a rule set is a whitelisting rule followed by a blocking rule in the same rule set.

When a requested web object is found on a whitelist, the request is allowed to pass through without further filtering. Therefore the rule set is not processed any further and the rule that eventually blocks the object is skipped.

Processing continues with the next rule set.

The next rule set can contain rules that, for example, block a request, although it was allowed to pass through the preceding rule set.

 

 

A rule applies and requires that
processing must stop for the
current cycle.

Processing stops for this cycle.

The rules and rule sets that follow the stopping rule in the cycle are skipped.

An example of a rule that stops the processing of a cycle is a global whitelisting rule.

When a requested object is found on a global whitelist, the request is allowed to pass through to the appropriate web server. To ensure the request is not blocked eventually by any of the following rules and rule sets, the request cycle is not processed any further.

Processing continues with the next cycle.

 

A rule applies and requires that
processing continues with the
next rule.

Processing continues with the next rule.

This can be the next rule in the current rule set or the first rule in the next rule set or cycle.

An example of a rule that lets the filtering process continue unimpeded is a statistics rule.

This rule just counts requests by increasing a counter and does otherwise nothing.

 

  • Was this article helpful?