Technical Brief: Policy Best Practices

Document created for SGOS v5

Policy Best Practices

Blue Coat Policy is a powerful tool that allows administrators to create and apply flexible policies in their
network. This flexibility, and the ability to create almost limitless rule combinations, is possible because of the
extensive set of available conditions, properties, and actions. With many administrators becoming more familiar
with policy (CPL and VPM), and many even choosing to create CPL-based policies instead of VPM-based
policies, it is no surprise that administrators often want to know the best way to achieve a particular policy or
set of policies.

The purpose of this document is to provide recommended practices in three key areas:

-> Policy constuct

-> Policy integrity

-> Policy optimization

The Policy Construct section provides specific advice regarding policy structure. The Policy Integrity section
is focused on best practices geared toward creating robust policy. Finally, the Policy Optimization section is
designed primarily to provide recommendations on policy syntax that can optimize existing policy. Many of the
practices described in this document serve several purposes. For example, in creating robust policy, you may
also be creating policy that is more optimized. Similarly, while optimization and performance are generally a
concern for administrators who have extensive policy or have a ProxySG appliance that is reaching a maximum
CPU threshold, the recommended practices provided are also useful for making policy of any size more
manageable and easier to understand.

Except where otherwise stated, all of the examples provided in this document assume a default policy of
ALLOW.

Policy Construct
Express Separate Decisions in Separate Layers
As policy grows and becomes more complex, maintenance becomes a significant issue. Maintenance will
be easier if the logic for each aspect of a policy is separate and distinct. Try to make policy decisions as
independent as possible, and express each policy in one layer or two adjacent layers.

Be Consistent With the Model

Set the default policy (allow or deny) according to whichever more closely reflects corporate security policy
— and then use blacklist or whitelist approaches as appropriate. The recommended approach for a WAN
optimization solution is a default policy of ALLOW; the recommended approach for a security gateway solution
is to begin with a default policy of DENY. In either solution, the model is the same – place general rules in early
layers and exceptions in later layers. The following examples illustrate this model.
 Technical Brief: Policy Best Practices

;Default policy is DENY ;Default policy is ALLOW

define subnet corporate_subnet define condtion corporate_buddies
10.10.12.0/24 im.buddy_id=billBCSI
end im.buddy_id=chrisBCSI
;First, explicitly allow access to only our users ….
<proxy> im.buddy_id=wendyBCSI
client.address=corporate_subnet ALLOW end

;Next, impose any authentication requirements (all ;Impose any authentication requirements (all access
access must be authenticated) must be authenticated)
<proxy> <proxy>
authenticate(corp_realm) authenticate(corp_realm)

;Next, begin to exclude specific types of requests
<proxy>
url.domain=playboy.com DENY
category=(gambling, hacking, chat) \
exception(content_filter_denied)
;Next, apply general rules to specific types of
requests
<proxy>
streaming.content=yes max_bitrate(56k)
im.buddy_id=!corporate_buddies im.strip_
attachments(yes)
;Next, create bitrate exceptions to the layers above
<proxy>
group=executives max_bitrate(256k)
group=marketing max_bitrate(156k)
;Next, create im attachment exceptions to the layers
above
<proxy>
group=public_relations im.strip_attachments(no)

Ordering of Layers
Blue Coat policy supports several types of layers. If you are using the Visual Policy Manager (VPM), the layers
are labeled with logical descriptions and the ordering of the layers displayed in the Policy layer selection menu
reflects the preferred ordering of the layers in policy. If you are writing CPL, the equivalent layer types are
shown below:
Layer type Logical Implementation

<admin> Admin Authentication Layer

<admin> Admin Access Layer
<dns-proxy> DNS Access Layer
<proxy> SOCKS Authentication Layer
<ssl-intercept> SSL Intercept Layer
<ssl> SSL Access Layer
<proxy> Web Authentication Layer
<proxy> Web Access Layer
<cache> Web Content Layer
<forward> Forwarding Layer

Policy Integrity
Understand the Implications of Using the ALLOW Action
While most administrators are very comfortable using the ALLOW action, many do not fully understand the
 Technical Brief: Policy Best Practices

affect that it can have on policy. Specifically, the ALLOW action, depending on where it is being used in policy,
can unintentionally reverse a previous denial that the administrator did not intend to reverse. For example, an
administrator may create a rule indicating that a particular group of users is allowed to access sports sites.
If this is achieved by creating a policy rule with the ALLOW action, it could unintentionally allow a request that
perhaps would have been denied based on some other criteria characteristic of the request – for example, that it
was an executable download.

The best way to avoid using the ALLOW action is to arrange your policy in the following way — instead of having
2 layers – one with the general rule and another with the exceptions – create one layer in which the rules are
arranged so that the exception group never matches on the original action at all. Since a layer will evaluate only
until the request matches a rule, matching a condition (even one with no action) is still a match. Policy rules
with no action are legal syntax, but for those who find that it makes the policy harder to read, the OK action can
be used.

Example

In this example, the administrator intended the third layer to allow users to go to sports sites. But actually,
it is also allowing them to download executables. In the preferred implementation, by placing both the client
rule and the category rule in the same layer, and replacing the ALLOW with an OK (no action), the rules can be
ordered so that clients in the indicated subnet result in a match before the content-filtering category condition
is evaluated. Because the match has no action and the ALLOW action was not applied to those users, no
previous DENY actions are reversed.

TYPICAL IMPLEMENTATION PREFERRED IMPLEMENTATION

<proxy> <proxy>
url.extension=.exe DENY url.extension=.exe DENY

<proxy> <proxy>
category=(sports) exception(content_filter_denied) client.address=192.168.15.252/30 OK
category=(sports) exception(content_filter_denied)
<proxy>
client.address=192.168.15.252/30 ALLOW

Understand the Difference Between DENY and FORCE_DENY

ALLOW and DENY are the most common policy actions implemented. Therefore, it is beneficial to understand
the difference between DENY and FORCE_DENY. The DENY action can be set and overridden by a later ALLOW
action; FORCE_DENY cannot be overridden by a later ALLOW action. Using FORCE_DENY can be key not just
for preventing later policy from “accidentally” overriding a policy rule, but also for preventing any unnecessary
processing of requests that the adminstrator does not intend to allow anyway.

Example

The policy shown below implements the DENY action. Let us assume that a user, who is not in the subnet
my_users, makes a request for a non-approved executable. Let us also assume that the user-defined
condition “executable” tests response headers and/or response data. After evaluating the first layer, the
user is temporarily marked for denial by the policy-processing engine since he is not a member of my_
users. Evaluation of the next layer results in a category lookup to determine if the user should be returned
a content_filter_denied exception. Evaluation of the last layer results in a request for the object from the
origin server so that the policy-processing engine can determine whether or not the object satisfies the
condition=executable and condition=!approved_application conditions, and can then determine
whether or not it should return the too_risky exception.
 Technical Brief: Policy Best Practices

In this case, a better policy implementation would be to replace DENY with FORCE_DENY, which results in
the immediate denial of any clients not in the my_users subnet. This prevents unnecessary processing of
the user’s request – a category lookup and server-side request in this particular example. Similarly, using
force_exception( ) instead of exception( ) in the second layer will result in users in the my_users
subnet being immediately denied if they attempt to access pornography or gambling sites instead of the request
continuing evaluation in layer three. This prevents an unnecessary server-side request to determine which
error page to present to the user. In this particular example, since the executable condition is the last rule in
the policy, a force_exception( ) in layer three will not change the behavior of policy. If there was additional
policy, however, you would also want to use force_exception( ) in layer three to ensure that executables
of non-approved applications are immediately denied with the indicated exception.
TYPICAL IMPLEMENTATION PREFERRED IMPLEMENTATION

define subnet my_users define subnet my_users

10.0.0.0/8 10.0.0.0/8
192.168.0.0/16 192.168.0.0/16
end end

<proxy> <proxy>
client.address=!my_users DENY client.address=!my_users FORCE_DENY

<proxy> <proxy>
category=(pornography, gambling) exception(content_filter_denied) category=(pornography, gambling) force_exception(content_filter_denied)

<proxy> <proxy>
condition=executable condition=!approved_application \ exception(user_ condition=executable condition=!approved_application \ exception(user_
defined.too_risky) defined.too_risky)

Policy Optimization
Note: Using the Visual Policy Manager (VPM) versus Content Policy Language (CPL)

The VPM was designed to provide a user-friendly way for administrators to quickly create and install policy.
While the VPM is the preferred method of configuring policy for most administrators, due to its ease of use,
it currently supports only a subset of the functionality available through policy. For the recommendations in
this section, the VPM can be used to implement the CPL policy that is provided. For implementing policy not
available in the VPM, administrators can choose to convert their VPM policy into CPL and maintain only a local
(CPL) policy file, or they can choose to maintain two separate policy files – the VPM file for general policy, and
the local (CPL) file for layers and/or rules that require syntax not available in the VPM. Some administrators
find that once they become more familiar with CPL syntax, they prefer writing CPL instead of finding the user-
friendly equivalent in the VPM.

Use Regular Expressions Only When Absolutely Necessary

Conditions using regular expressions, while extremely powerful, are the most CPU-intensive policy that you can
implement. Many administrators choose to create rules using regular expressions because they are not fully
aware of the numerous conditions available, or simply do not understand them. This results in suboptimized
policy and, in many cases, also results in the regular expression matching content that is unintended (in addition
to the content it is desired to match). In most cases where regular expressions are used, an alternate solution is
available which will not only result in faster policy processing, but prevent unintended matches. Some common
examples are listed below.
COMMON REGULAR EXPRESSIONS PREFERRED SYNTAX

url=http://www.playboy.com/.* DENY url.domain=www.playboy.com DENY

url=.*\.exe$ DENY url.extension=.exe DENY
url.domain=.*\.myspace\.com DENY url.domain=myspace.com DENY
url=http://www.site.com/.*\.jpg DENY url.domain=www.site.com url.extension=.jpg DENY
 Technical Brief: Policy Best Practices

Note that in the previous examples, it is assumed that the URL scheme (http, https, etc) is irrelevant in the
decision to deny and is thus not included in the preferred syntax column. Administrators often include the URL
scheme when placing URLs in policy but often don’t intend to limit the rule strictly to HTTP (for example). If the
URL scheme is a requirement, the url.scheme= condition should be used.

Place Rules Most Likely to Match at the Beginning of the Layer

If your policy contains layers with hundreds or even thousands of rules, you can optimize policy evaluation by
placing those rules that are most likely to match at the beginning of the layer. Since layers are evaluated only
until a rule matches, placing the rules most likely to match at the beginning of the layer provides a performance
benefit because the rest of the layer does not need to be evaluated. Note that this can be done only if the
ordering of the rules within the layer does not change the intended behavior of the layer.

Place Like Conditions Together Within the Layer

If your policy contains layers with hundreds or even thousands of rules, you can optimize policy evaluation by
placing rules with like conditions together. Even though the number of rules is the same, the compiler is able
to apply optimizations to the policy. Note that this can be done only if the ordering of the rules within the layer
does not change the intended behavior of the layer.
TYPICAL IMPLEMENTATION OPTIMIZED IMPLEMENTATION

<proxy> <proxy>
url.domain=www.abc.com DENY url.domain=www.abc.com DENY
url=http://www.def.com/chatweb/ DENY url.domain=www.jkl.com DENY
url=http://www.ghi.com/finance/ DENY url.domain=www.mno.com DENY
url.domain=www.jkl.com DENY url=http://www.def.com/chatweb/ DENY
im.buddy_id=bill DENY url=http://www.ghi.com/finance/ DENY
url.domain=www.mno.com DENY im.buddy_id=bill DENY
im.buddy_id=bob DENY im.buddy_id=bob DENY

Use Subnets When Possible

When implementing any policy that involves IP addresses, use subnets if at all possible. Instead of referencing
10.1.1.252, 10.1.1.253, 10.1.1.254, and 10.1.1.255, use 10.1.1.252/30. For lists of IP addresses that cannot be
referenced by a single subnet, or for lists of subnets, the define subnet definition should be used (see “Use
Definitions to Minimize the Number of Rules”).

TYPICAL IMPLEMENTATION OPTIMIZED IMPLEMENTATION

<proxy> <proxy>
client.address=10.1.1.252 DENY client.address=10.1.1.252/30 DENY
client.address=10.1.1.253 DENY
client.address=10.1.1.254 DENY
client.address=10.1.1.255 DENY

Select the Appropriate URL Condition

The most common policy rule involves some form of a URL. Often, administrators use the url= condition
because it seems the most straightforward, although in many cases another condition would better accomplish
the desired result. When adding a URL-based policy rule, determine whether the desired decision should be
based on the subdomain, domain, the domain+path, a portion of the URL, or the complete URL. Note that this is
only a subset of the available URL conditions.
 Technical Brief: Policy Best Practices

url.domain=company.com
url.domain=www.company.com
url.domain=www.company.com/cgi-bin
url.path=”/cgi-bin/”
url=http://www.company.com/cgi-bin/
url=http://www.company.com/cgi-bin/query.pl?q=test#fragment

Use Definitions to Minimize the Number of Rules

Blue Coat policy supports the use of definitions to bind a set of conditions, actions, or transformations to a
user-defined label. More importantly, implementing definitions and later referencing those definitions in policy
rules results in faster policy evaluation than using multiple policy rules to accomplish the same thing. Fewer
rules to evaluate means faster policy processing. If there is a way to reduce the number of rules and have the
resulting policy accomplish the same thing as the original, that is the preferred policy design.

Example 1 – define subnet

Administrators often use the client.address= condition in policy rules. If multiple client.address=
rules are being evaluated and the same action is being triggered for each client.address= match, use of
the define subnet definition is preferred.

TYPICAL IMPLEMENTATION OPTIMIZED IMPLEMENTATION

<proxy> define subnet test_network

client.address=10.0.0.0/8 category=(gambling) OK 10.0.0.0/8
client.address=192.168.0.0/16 category=(gambling) OK 192.168.0.0/16
client.address=216.52.23.3 category=(gambling) OK 216.52.23.3
client.address=216.52.23.5 category=(gambling) OK 216.52.23.5
category=(gambling) exception(content_filter_denied) end

<proxy>
client.address=test_network category=(gambling) OK
category=(gambling) exception(content_filter_denied)

Example 2 – define category

Depending on your default policy and whether you have implemented content filtering, administrators often
create blacklists or whitelists of domains or URLs. Instead of listing these as individual policy rules, the define
category definition should be used. Using the define category definition will result in more optimized
policy, and often, policy that can be better managed. If multiple domain or URL rules are being evaluated and
the same action is being triggered for each match, use of the define category definition is preferred.

TYPICAL IMPLEMENTATION OPTIMIZED IMPLEMENTATION

define category exception_sites
<proxy>
etrade.com
url.domain=etrade.com OK
nyse.com
url.domain=nyse.com OK
stocktrader.com
url.domain=stocktrader.com OK
scottrade.com
url.domain=scottrade.com OK
end
category=(brokerage/trading) exception(content_filter_denied)
<proxy>
category=exception_sites OK
category=(brokerage/trading) exception(content_filter_denied)
 Technical Brief: Policy Best Practices

Use Layer Guards to Prevent Layers from Being Evaluated Unnecessarily

Since layers are used to make a single policy decision (if you are following best practices), it is quite likely that the
rules within a layer are related by a common condition. If so, layer guards can be implemented to first check if the
common condition to the group of policy rules is true for a particular request before rule evaluation begins.

TYPICAL IMPLEMENTATION OPTIMIZED IMPLEMENTATION

<proxy> <proxy>
authenticate(myrealm) authenticate(myrealm)

<proxy> <proxy> group=hr

group=hr user=bluecoat\bob.kent OK user=bluecoat\bob.kent OK
group=hr url.domain=www.mercurynews.com/hotjobs/ OK url.domain=www.mercurynews.com/hotjobs/ OK
group=hr url.domain=sfgate.com/jobs/ OK url.domain=sfgate.com/jobs/ OK
group=hr url.address=216.52.23.5 DENY url.address=216.52.23.5 DENY
group=hr category=(news/media) exception(content_filter_denied) category=(news/media) exception(content_filter_denied)

Note: Layer guards are supported only in the VPM of SGOS 5.2 and higher. All SGOS versions support layer guards in
CPL.

Blue Coat Systems, Inc. Corporate Headquarters EMEA Headquarters APAC Headquarters
www.bluecoat.com Sunnyvale, CA USA // +1.408.220.2200 Hampshire, UK // +44.1252.554600 Hong Kong // +852.3476.1000
Copyright © 2009 Blue Coat Systems, Inc. All rights reserved worldwide. No part of this document may be reproduced by any means nor translated to any electronic medium without the written consent of Blue Coat Systems, Inc. Specifications
are subject to change without notice. Information contained in this document is believed to be accurate and reliable, however, Blue Coat Systems, Inc. assumes no responsibility for its use. Blue Coat, ProxySG, PacketShaper, ProxyClient and
BlueSource are registered trademarks of Blue Coat Systems, Inc. in the U.S. and worldwide. All other trademarks mentioned in this document are the property of their respective owners. v.TB-POLICYBP-v4-0309