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 exible policies in their network. This exibility, 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 specic 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 signicant 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 reects 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 dene subnet corporate_subnet 10.10.12.0/24 end ;First, explicitly allow access to only our users <proxy> client.address=corporate_subnet ALLOW ;Next, impose any authentication requirements (all access must be authenticated) <proxy> authenticate(corp_realm) ;Next, begin to exclude specic types of requests <proxy> url.domain=playboy.com DENY category=(gambling, hacking, chat) \ exception(content_lter_denied)

;Default policy is ALLOW dene condtion corporate_buddies im.buddy_id=billBCSI im.buddy_id=chrisBCSI . im.buddy_id=wendyBCSI end ;Impose any authentication requirements (all access must be authenticated) <proxy> authenticate(corp_realm) ;Next, apply general rules to specic 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 reects the preferred ordering of the layers in policy. If you are writing CPL, the equivalent layer types are shown below:
Layer type <admin> <admin> <dns-proxy> <proxy> <ssl-intercept> <ssl> <proxy> <proxy> <cache> <forward> Logical Implementation Admin Authentication Layer Admin Access Layer DNS Access Layer SOCKS Authentication Layer SSL Intercept Layer SSL Access Layer Web Authentication Layer Web Access Layer Web Content Layer 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. Specically, 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 nd 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-ltering 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 <proxy> url.extension=.exe DENY <proxy> category=(sports) exception(content_filter_denied) <proxy> client.address=192.168.15.252/30 ALLOW PREFERRED IMPLEMENTATION <proxy> url.extension=.exe DENY <proxy> client.address=192.168.15.252/30 OK category=(sports) exception(content_filter_denied)

Understand the Difference Between DENY and FORCE_DENY

ALLOW and DENY are the most common policy actions implemented. Therefore, it is benecial 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-dened condition executable tests response headers and/or response data. After evaluating the rst 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_lter_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 satises 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 users 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 define subnet my_users 10.0.0.0/8 192.168.0.0/16 end <proxy> client.address=!my_users DENY <proxy> category=(pornography, gambling) exception(content_filter_denied) <proxy> condition=executable condition=!approved_application \ exception(user_ defined.too_risky) PREFERRED IMPLEMENTATION define subnet my_users 10.0.0.0/8 192.168.0.0/16 end <proxy> client.address=!my_users FORCE_DENY <proxy> category=(pornography, gambling) force_exception(content_filter_denied) <proxy> condition=executable condition=!approved_application \ exception(user_ 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 conguring 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 le, or they can choose to maintain two separate policy les the VPM le for general policy, and the local (CPL) le for layers and/or rules that require syntax not available in the VPM. Some administrators nd that once they become more familiar with CPL syntax, they prefer writing CPL instead of nding the userfriendly 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 url=http://www.playboy.com/.* DENY url=.*\.exe$ DENY url.domain=.*\.myspace\.com DENY url=http://www.site.com/.*\.jpg DENY PREFERRED SYNTAX url.domain=www.playboy.com DENY url.extension=.exe DENY url.domain=myspace.com 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 dont 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 benet 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 <proxy> url.domain=www.abc.com DENY url=http://www.def.com/chatweb/ DENY url=http://www.ghi.com/finance/ DENY url.domain=www.jkl.com DENY im.buddy_id=bill DENY url.domain=www.mno.com DENY im.buddy_id=bob DENY OPTIMIZED IMPLEMENTATION <proxy> url.domain=www.abc.com DENY url.domain=www.jkl.com DENY url.domain=www.mno.com DENY url=http://www.def.com/chatweb/ DENY url=http://www.ghi.com/finance/ DENY im.buddy_id=bill 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 denition should be used (see Use Denitions to Minimize the Number of Rules).
TYPICAL IMPLEMENTATION <proxy> client.address=10.1.1.252 DENY client.address=10.1.1.253 DENY client.address=10.1.1.254 DENY client.address=10.1.1.255 DENY OPTIMIZED IMPLEMENTATION <proxy> client.address=10.1.1.252/30 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 Denitions to Minimize the Number of Rules

Blue Coat policy supports the use of denitions to bind a set of conditions, actions, or transformations to a user-dened label. More importantly, implementing denitions and later referencing those denitions 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 denition is preferred.
TYPICAL IMPLEMENTATION <proxy> client.address=10.0.0.0/8 category=(gambling) OK client.address=192.168.0.0/16 category=(gambling) OK client.address=216.52.23.3 category=(gambling) OK client.address=216.52.23.5 category=(gambling) OK category=(gambling) exception(content_filter_denied) OPTIMIZED IMPLEMENTATION define subnet test_network 10.0.0.0/8 192.168.0.0/16 216.52.23.3 216.52.23.5 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 ltering, administrators often create blacklists or whitelists of domains or URLs. Instead of listing these as individual policy rules, the define category denition should be used. Using the define category denition 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 denition is preferred.
TYPICAL IMPLEMENTATION <proxy> url.domain=etrade.com OK url.domain=nyse.com OK url.domain=stocktrader.com OK url.domain=scottrade.com OK category=(brokerage/trading) exception(content_filter_denied) OPTIMIZED IMPLEMENTATION define category exception_sites etrade.com nyse.com stocktrader.com scottrade.com end <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 rst check if the common condition to the group of policy rules is true for a particular request before rule evaluation begins.
TYPICAL IMPLEMENTATION <proxy> authenticate(myrealm) <proxy> group=hr user=bluecoat\bob.kent OK group=hr url.domain=www.mercurynews.com/hotjobs/ OK group=hr url.domain=sfgate.com/jobs/ OK group=hr url.address=216.52.23.5 DENY group=hr category=(news/media) exception(content_filter_denied) OPTIMIZED IMPLEMENTATION <proxy> authenticate(myrealm) <proxy> group=hr user=bluecoat\bob.kent OK url.domain=www.mercurynews.com/hotjobs/ OK url.domain=sfgate.com/jobs/ OK url.address=216.52.23.5 DENY 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.

www.bluecoat.com

Sunnyvale, CA USA // +1.408.220.2200

Corporate Headquarters

EMEA Headquarters

Hampshire, UK // +44.1252.554600

APAC Headquarters

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. Specications 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