policy best practices.1

Document created for SGOS v5

Policy Best PracticesBlue 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 ConstructExpress 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

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 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 IntegrityUnderstand the Implications of Using the ALLOW Action

While most administrators are very comfortable using the ALLOW action, many do not fully understand the

;Default policy is DENY

define subnet corporate_subnet 10.10.12.0/24

end

;First, explicitly allow access to only our users

client.address=corporate_subnet ALLOW

;Next, impose any authentication requirements (all access must be authenticated)

authenticate(corp_realm)

;Next, begin to exclude specific types of requests

url.domain=playboy.com DENY category=(gambling, hacking, chat) \

exception(content_filter_denied)

;Default policy is ALLOW

define 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)

authenticate(corp_realm)

;Next, apply general rules to specific types of requests streaming.content=yes max_bitrate(56k) im.buddy_id=!corporate_buddies im.strip_attachments(yes)

;Next, create bitrate exceptions to the layers above group=executives max_bitrate(256k) group=marketing max_bitrate(156k)

;Next, create im attachment exceptions to the layers above group=public_relations im.strip_attachments(no)


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

url.extension=.exe DENY

category=(sports) exception(content_filter_denied)

client.address=192.168.15.252/30 ALLOW

PREFERRED IMPLEMENTATION

url.extension=.exe DENY

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


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.


define subnet my_users 10.0.0.0/8 192.168.0.0/16

end

client.address=!my_users DENY

category=(pornography, gambling) exception(content_filter_denied)

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

client.address=!my_users FORCE_DENY

category=(pornography, gambling) force_exception(content_filter_denied)

condition=executable condition=!approved_application \ exception(user_defined.too_risky)

Policy OptimizationNote: 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

url=http://www.playboy.com/.* DENYurl=.*\.exe$ DENY url.domain=.*\.myspace\.com DENYurl=http://www.site.com/.*\.jpg DENY

PREFERRED SYNTAX

url.domain=www.playboy.com DENYurl.extension=.exe DENYurl.domain=myspace.com DENYurl.domain=www.site.com url.extension=.jpg DENY


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


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

OPTIMIZED IMPLEMENTATION

url.domain=www.abc.com DENYurl.domain=www.jkl.com DENYurl.domain=www.mno.com DENY url=http://www.def.com/chatweb/ DENYurl=http://www.ghi.com/finance/ DENYim.buddy_id=bill DENYim.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).


client.address=10.1.1.252 DENYclient.address=10.1.1.253 DENYclient.address=10.1.1.254 DENYclient.address=10.1.1.255 DENY


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.


url.domain=company.comurl.domain=www.company.comurl.domain=www.company.com/cgi-binurl.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.


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


define subnet test_network 10.0.0.0/8 192.168.0.0/16 216.52.23.3 216.52.23.5

end

client.address=test_network category=(gambling) OKcategory=(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.


url.domain=etrade.com OKurl.domain=nyse.com OKurl.domain=stocktrader.com OKurl.domain=scottrade.com OKcategory=(brokerage/trading) exception(content_filter_denied)

OPTIMIZED IMPLEMENTATIONdefine category exception_sites

etrade.com nyse.com stocktrader.com scottrade.com

end

category=exception_sites OKcategory=(brokerage/trading) exception(content_filter_denied)


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.


authenticate(myrealm)

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


authenticate(myrealm)

group=hruser=bluecoat\bob.kent OKurl.domain=www.mercurynews.com/hotjobs/ OKurl.domain=sfgate.com/jobs/ OKurl.address=216.52.23.5 DENYcategory=(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.

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

Blue Coat Systems, Inc.www.bluecoat.com

Corporate HeadquartersSunnyvale, CA USA // +1.408.220.2200

EMEA HeadquartersHampshire, UK // +44.1252.554600

APAC HeadquartersHong Kong // +852.3476.1000


policy best practices.1

Documents