Chapter 2: Managing Content Policy Language
45
•Do not mix the CacheOS 4.x filter-file syntax with CPL syntax.
Although the Content Policy Language is backward-compatible with the filter-file syntax, avoid
using the older syntax with the new. For example, as the filter-file syntax uses a different order of
evaluation, mixing the old and new syntax can cause problems. Blue Coat strongly rec ommends
not mixing the two syntaxes.
Blacklists and Whitelists
For administrative policy, the intention is to be cautious and conservative, emphasizing security over
ease of use. The assumption is that everything not specifically mentioned is denied. This approach,
referred to as the whitelist approach, is common in corporations concerned with security or legal issues
above access. Organizations that want to extend this concept to general Internet access select a default
proxy policy of deny as well.
In the second approach, the idea is that by default everything is allowed. Some requests might be
denied, but really that is the exception. This is known as blacklist policy because it requires specific
mention of anything that should be denied (blacklisted). Blacklist policy is used by organizations
where access is more important than security or legal responsibilities.
This second approach is used for cache transactions, but can also be common default proxy policy for
organizations such as internet service providers.
Blacklists and whitelists are tactical approaches and are not mutually exclusive. The best overall policy
strategy is often to combine the two approaches. For example, starting from a default policy of deny,
one can use a whitelist approach to explicitly filter-in requests that ought to be served in general (such
as all requests originating from internal subnets, while leaving external requests subject to the default
DENY). Further policy layers can then apply more specific restrictions in a blacklist mode to filter-out
unwanted requests (such as those that fail to conform to content filtering policies).
Whitelisting and blacklisting can also be used not simply to allow or deny service, but also to subject
certain requests to further processing. For example, not every file type presents an equal risk of virus
infection or rogue executable content. One might choose to submit only certain file types (presumably
those known to harbor executable content) to a virus scanner (blacklist), or virus-scan all files except
for a whitelist of types (such as image files) that may be considered safe.
General Rules and Exceptions to a General Rule
When writing policy many organizations use general rules, and then define several exceptions to the
rule. Sometimes, you might find exceptions to the exceptions. Exceptions to the general rule can be
expressed either:
•Through rule order within a layer
•Through layer order within the policy.

Using Rule Order to Define Exceptions

When the policy rules within a layer are evaluated, remember that evaluation is from the top down,
but the first rule that matches will end further evaluation of that layer. Therefore, the most specific
conditions, or exceptions, should be defined first. Within a layer, use the sequence of most-specific to
most-general policy.