1. Proxysg policy optimization and troubleshooting
Thank you for joining today’s Blue Coat Customer Support Technical Webcast!
The Webcast will begin just a minute or so after the top of the hour to allow today’s very large audience sufficient time to join
You may join the teleconference through the numbers provided in your invite, or listen through your computer speakers
Audio broadcast will go live only when the Webcast begins
The Presentation will run approximately 60 minutes
There will be a 30-minute Q/A session thereafter
Please submit questions using the Webex Q/A feature!

2. ProxySG Policy best practices
Jason tinsley
Sr. Consultant, Professional Services
September 15, 2015

3. Agenda ProxySG Policy Structure Optimizing Policy Performance
Troubleshooting Policy
Q&A

4. ProxySG Policy Structure
Policy Construct

5. Policy structure Topics Policy Overview General Best Practices
Policy Options
Layers
Rule Triggers and Actions
Policy Flow
VPM vs CPL

6. Policy Structure ProxySG Policy Subjective Powerful Flexible
Policy Formats
CPL (Content Policy Language)
VPM (Visual Policy Manager)
Hybrid
Blue Coat Policy Overview:
Subjective. Many variations based on deployment method, company policies, and even personal preference.
<click>
is a powerful tool that allows administrators to create and apply flexible policies in their network.
This flexibility utilizes an extensive set of conditions, properties, and actions, which give us the ability to create nearly limitless rule combinations
As you become more familiar with policy (CPL and VPM), you may become confused as to whether you want to build your policy with CPL or with the VPM, and will no doubt want to know the best way to achieve a particular policy or set of policies,
but keep in mind that sometimes the best method will be a hybrid of the two.
So with all these various methods, what is the best/simplest way of constructing your policy?

7. Policy structure General Policy Best Practices
Express Separate Decisions in Separate Layers
Easier to Maintain
Keep Policy Logic Separate & Distinct
One Layer or Two Adjacent Layers
Be Consistent
Use Comments
First we’ll cover some of the General Guidelines:
It is all well and good to create this “multi-layered, all-in-one” policy, that does everything you want, but you will need to remember that you will have to maintain that policy and it can be very easy to get lost in the weeds.
<click>
With that in mind, you will want to keep your policy decisions as independent as possible and express them in layers; particularly one policy per layer or two adjacent layers.
This will not only make it easier to maintain, but will help to prevent you from creating rules with the unintentional result of canceling out the action of other rules.
As your policy grows and becomes more complex, maintenance will become a significant issue. Maintenance will be easier if the logic for each aspect of a policy is separate and distinct.
So the essence of your policy’s foundation is: make policy decisions as independent as possible, and express each policy in one layer or two adjacent layers. Example on next slide.

8. Policy structure Default Blue Coat Policy Policy Flow Allow Deny
Admin Controls
SSL
Auth
Global Rules
Exceptions to Global Rules
Additional Actions (Content Analysis, Logging)

9. Policy structure
;Default Policy is DENY Define subnet corporate_subnet /24 end ;First, explicitly allow access to only our users <proxy "Web Access"> client.address=corporate_subnet ALLOW ;Next, impose any authentication requirements <proxy "Web Auth”> authenticate(corp_realm) ;Next, begin to exclude specific types of requests <proxy “Web Filter"> url.domain=playboy.com DENY category=(gambling, hacking, games) exception(content_filter_denied) ;Next begin exceptions to the general rule <proxy "Restricted Access"> group=execs, managers url.domain= fantasyfootball.com ALLOW
In this example we have broken out the different sections by function to help show the different policy layers.
--Explain slide, and use of the semi-colon in policy.--
Notice how when we use strictly CPL how the policy can tend to run together?
This is where the VPM can help by segregating the policy layers in an easier to read format.
<click>

10. Policy Structure

11. Policy structure Policy Options Policy Options
Here we can see where to set the Default Policy. Configuration  Policy  Policy Options
Allow or Deny
This is where we can also set the Policy Evaluation Order

12. Policy structure Ordering of Layers Layer Type Logical Implementation
<admin>
Admin Authentication Layer
Admin Access Layer
<dns-proxy>
DNS Access Layer
<proxy>
SOCKS Authentication Layer
<ssl-intercept>
SSL Intercept Layer
<ssl>
SSL Access Layer
Web Authentication Layer
Web Access Layer
<cache>
Web Content Layer
<forward>
Forwarding Layer
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 here on the left column:
It would also be a good idea to name your layers based on what function of filtering they are providing. In the VPM it is evident as to the name, but you can rename them as well as number them.
In the CPL you can also name the layer. <examples of both in the next slide>

13. Policy structure Admin Authentication Layer
Authenticate/Force Authenticate ProxySG Admins
Admin Access Layer
Allow Read-Only/Read-Write Access to ProxySG Admins
SNMP Access

14. Policy structure DNS Access Layer Modify DNS caching behavior
Take actions based on DNS responses
SSL Intercept Layer
Intercept/Tunnel SSL Traffic
Preserve Untrusted Issuers (Self-Signed Sites)

15. Policy structure SSL Access Layer
Allow or Deny Access Based on SSL Information
Modify SSL Validation Behavior

16. Policy structure Web Access Layer Allow/Deny Web Traffic
Log Web Traffic
Notify Users
Send Exception Pages
And More….

17. Policy structure Web Authentication Layer Authenticates Users
Web Content Layer
Sends Request/Response Traffic to ICAP Services
Modify Caching/Bandwidth Behavior

18. Policy structure Allow/Deny Trace Force_Deny Exception
To understand the integrity of policy, we first need to understand how that policy is made up.
This would be a good time to look at exactly what the proxy policy is looking to evaluate.
Triggers and Actions
CPL rules consist of triggering conditions and actions
VPM grouped the available triggers into multiple columns
CPL Triggers contain an “=“
Just as you can have multiple triggers, you can also have multiple Actions on a single rule; such as Allow & Trace & Bandwidth Mgt.
<click>
Allow/Deny
Trace
Force_Deny
Exception

19. Policy structure

20. Policy structure

21. Policy structure VPM CPL User-friendly Can be scripted Graphical
Using the Visual Policy Manager (VPM) versus Content Policy Language (CPL)
VPM
User-friendly
Graphical
Easy to use
Preferred method of configuring policy for most administrators
Supports subset of the functionality available through CPL
CPL
Can be scripted
For implementing policy not available in the VPM
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 implementing policy not available in the VPM; administrators can choose to maintain only a local (CPL) policy file, or you can also create a CPL layer in the VPM which allows for all the same syntax and configuration as the local file.
<click>

22. Optimizing Policy Performance
Policy Optimization

23. Policy performance Topics Rule Placement Subnets URL Conditions
Combined Objects/Conditions
Server Response-Based Objects
DNS-Based Objects
Layer Guards
Deny vs Force Deny
Regular Expressions
ICAP Best Practices
General Guidelines
Place Rules Most Likely to Match at the Beginning of the Layer
<click>
Place Like Conditions Together Within the Layer
If your policy contains layers with hundreds 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. This should be done only if the ordering of the rules within the layer does not change the intended behavior of the layer.
Use Subnets When Possible
Select the Appropriate URL Condition
This goes back to knowing the triggers and what exactly you are filtering for (scheme, url, domain, file path, file-extension…)
Use Definitions to Minimize the Number of Rules
Fewer rules means faster processing
Use Layer Guards to Prevent Layers from Being Evaluated Unnecessarily
layer guards can be implemented to first check if the common condition to the group of policy rules is true before rule evaluation begins.
Now let’s take a look at a few examples of optimizing our policy:

24. Policy performance Rule placement speeds processing:
Typical Implementation
<proxy>
url.domain= DENY
url= DENY
url= DENY
url.domain= DENY
im.buddy_id=bill DENY
url.domain= DENY
im.buddy_id=bob DENY
Optimized Implementation
<proxy>
url.domain= DENY
url.domain= DENY
url.domain= DENY
url= DENY
url= DENY
im.buddy_id=bill DENY
im.buddy_id=bob DENY
Rule Placement:
In this example we are assuming that users will visit those domains more often than Bill or Bob use their chat application.
So, 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 will provide a performance benefit because the rest of the layer does not need to be evaluated.
*Be cognizant that this can be done only if the ordering of the rules within the layer does not change the intended behavior of the layer.

25. Policy performance Rule placement speeds processing:
Typical Implementation
<proxy>
client.address= DENY
client.address= DENY
client.address= DENY
client.address= DENY
Optimized Implementation
<proxy>
client.address= /30 DENY
Use of Subnets
*what are the common variables? – in this case all are clients within the same subnet utilizing the same action.
When implementing any policy that involves IP addresses, use subnets if at all possible. Instead of referencing , , , and , use /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 which we will see in a future example.

26. Policy performance
url.domain=company.com url.domain= url.domain= url.path=”/cgi-bin/” url= url=
Use 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 domain, subdomain, the domain+path, a portion of the URL, or the complete URL.
For a full list of conditions, be sure to consult the Content Policy Guide.
<click>

27. Policy performance
Protocol
Host
Port
Path
File
Extension
Query
url.scheme=
url.path=
url.path.regex=
url.query=
url.query.regex=
url.host=
url.host.regex=
url.address=
url.port=
url.extension=
url.domain=
url=
url.regex=

28. Policy performance
Place Common Items Into a Condition (Combined Policy Object)
Typical Implementation
<proxy>
client.address= /8 category=(gambling) OK
client.address= /16 category=(gambling) OK
client.address= category=(gambling) OK
client.address= category=(gambling) OK
category=(gambling) exception(content_filter_denied)
Optimized Implementation
define subnet test_network /8
/16
end
<proxy>
client.address=test_network
category=(gambling) OK
category=(gambling)
exception(content_filter_denied
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.
Explain example:
*what are the common variables? - category
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.

29. Policy performance Server Response-Based Objects
Must wait for a response before processing
If site access fails from proxy to OCS, can result in unexpected behavior
Example:
<proxy> ALLOW condition=Whitelist DENY http.response.apparent_data_type=(executable, cabinet)
DENY condition=Blocked_Categories
If the request is blocked upstream, the request results in a Service Unavailable instead of a Forbidden
Solution: User layers and layer guards to minimize traffic checking response-based rules

30. Policy performance DNS-Based Objects
Overhead associated with doing queries
Host (DNS-based) Object
If DNS is slow to respond, performance will suffer
If hostname doesn’t have RDNS entry, request will fail
Solution: Minimize use of DNS-based objects and restrict DNS lookups
More information at:
NSlookupsontheProxySG

31. Policy performance Layer Guards
<Proxy “Corp Web Access”> group=corporate_user
url.domain=competitor.com DENY
category=(gambling) exception(content_filter_denied)
Layer Guards: allow execution/evaluation of a layer upon condition match
When creating layer guards in CPL, the condition goes on the same line as the Layer identifier.
In the VPM, it sits above the rule set.
Any rules below a layer guard will only be read if the condition of the layer guard is met.

32. Policy performance
Layer guards allow execution of a layer upon condition match
Typical Implementation
<proxy>
authenticate(myrealm)
group=hr user=bluecoat\bob.kent OK
group=hr url.domain=mercurynews.com OK
group=hr url.domain=sfgate.com/jobs/
group=hr url.address=
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=mercurynews.com/hotjobs OK
url.domain=sfgate.com/jobs/ OK
url.address= DENY
category=(news/media)
exception(content_filter_denied)
Describe example with attention to common conditions & Layer Guard usage.
<click>

33. Policy performance
Layer Guard – VPM Example

34. ALLOW DENY Deny Vs. Force Deny: DENY FORCE_DENY Policy performance
Category = (suspicious) DENY
<policy>
Category = (suspicious) Force_DENY
<policy>
Client.address = ALLOW
<policy>
Client.address = ALLOW
Deny can be over-written in policy, Force_Deny cannot.
Authenticate and Force_Authenticate
Use of Force Deny is optimal as well, as once there is a Force Deny match, no more web access filters will be evaluated, thus saving time and CPU.
ALLOW
DENY

35. Policy performance Authenticate Vs. Force Authenticate
NOT the same as Deny/Force Deny!
Authenticate – Does not ask the user to authenticate if the request will be denied
Force Authenticate – Asks the user to authenticate even if the request will be denied
If performance is more important, use Authenticate
If policy requires all requests be associated with a username, use Force Authenticate
More information at: ontent/Solutions/Authentication/IWA/IWA_policy_ta.htm

36. Policy performance Regular Expressions
Use Only When Absolutely Necessary
CPU-intensive
Often Misused or Used When Not Necessary
Although not recommended, we will go ahead and look at a few of the common Regex implementations and discuss their liabilities.
Conditions using regular expressions, while extremely powerful, are the most CPU-intensive policy that you can implement, and are therefor not recommended.
Regular expressions are used because admins are not fully aware of the numerous conditions available, or simply do not understand them.
This results in sub-optimized 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.
Let’s take a look at some common examples.
<next slide>

37. Be careful with special characters: \ ^ $ . | ? * + ( ) { } [ ]
Policy performance
Be careful with special characters:
\ ^ $ | ? * ( ) { } [ ]
* is not a wildcard!
* or .* are almost always unnecessary!
Be specific in what you are looking at:
Yes
Avoid
url.host.regex
url.path.regex
url.query.regex
url.regex (the entire URL)
Here we see a list of common Meta-characters. I’d like to draw your attention to the “splat” or asterisk, as it is commonly mis-perceived and used as a wildcard…
Below we have some examples with the focus on being as specific as possible.
A full URI can contain a large amount of characters, and the wrong use of regex will cause the policy to evaluate every single character for every transaction. That is a large CPU cost.

38. Be specific in what you are looking for:
Policy performance
Be specific in what you are looking for:
Regex
Finds
url.host.regex=\.com$
Finds hosts ending in “.com” – note that the period is escaped
url.host.regex=x+
Matches “x” one or more times
url.host.regex=x{2,5}
Matches “x” 2 to 5 times
url.path.regex=^\/bad-directory\/
Finds all URLs that begin with “/bad-directory”
url.query.regex=login=matt
Finds query strings that contain login=matt
(anchor this if possible)
Here are a few more examples, and I would like to draw your attention to the top example. Here is the correct use of the regex for the host of .com, an incorrect value (url.regex) would also capture the file-extension of .com which may or may not be intentional.
We don’t want to advocate the non-use of regex, but just want to impress that it is not always practical, because not all admins are fluent with regex, and it can make your policy more difficult to read.
But if you do decide to use regex, be as specific in your queries as possible!
--you are not trying to code, you are just writing proxy policy.

39. Policy performance Audit Policy Periodically
Delete Unused Rules/Layers
Fewer Rules = Faster Performance

40. Policy performance ICAP Best Practices
Make use of delete_on_abandonment(yes)
Minimize Queued Requests
Verify Current Connections < Max Connections
ip>:8082/OPP/Statistics
Refer to ntegration.pdf

41. Troubleshooting Policy

42. Policy troubleshooting
Topics
Policy Tracing
Policy Coverage Statistics

43. Policy troubleshooting
Policy Tracing
Logs what decisions are made on a session
Can only trace intercepted sessions
CPU intensive

44. Policy troubleshooting
Enable Global Tracing
Configuration -> Policy -> Policy Options
Enabling default policy tracing is not recommended in production!

45. Policy troubleshooting
Policy Tracing
Create Web Access Layer
Action is None
Track Object Contains Trace

46. Policy troubleshooting
View Traces
Located at ip>:8082/policy

47. Policy troubleshooting
Trace Output
start transaction
CPL Evaluation Trace: transaction ID=826812
transaction type: qualifier-index=1 name=http service=SG-HTTP-Service module=HTTP
...
<Proxy> condition=!__is_notify_internal
MATCH: DENY url.domain=//cnn.com/
<ssl> condition=!__is_notify_internal
miss : url.domain=//gmail.com/
miss : server.connection.negotiated_cipher=AES128-SHA
MATCH: client.address= trace.request(yes) trace.rules(all) trace.destination(my_trace.html)
Highlight shows identification for the start of a transaction.

48. Policy troubleshooting
Trace Output
start transaction
CPL Evaluation Trace: transaction ID=826812
transaction type: qualifier-index=1 name=http service=SG-HTTP-Service module=HTTP
...
<Proxy> condition=!__is_notify_internal
MATCH: DENY url.domain=//cnn.com/
<ssl> condition=!__is_notify_internal
miss : url.domain=//gmail.com/
miss : server.connection.negotiated_cipher=AES128-SHA
MATCH: client.address= trace.request(yes) trace.rules(all) trace.destination(my_trace.html)
Highlight shows the layers the transaction went through.

49. Policy troubleshooting
Trace Output
start transaction
CPL Evaluation Trace: transaction ID=826812
transaction type: qualifier-index=1 name=http service=SG-HTTP-Service module=HTTP
...
<Proxy> condition=!__is_notify_internal
MATCH: DENY url.domain=//cnn.com/
<ssl> condition=!__is_notify_internal
miss : url.domain=//gmail.com/
miss : server.connection.negotiated_cipher=AES128-SHA
MATCH: client.address= trace.request(yes) trace.rules(all) trace.destination(my_trace.html)
Highlight shows the matching rule in each layer the transaction passed through.

50. Policy troubleshooting
Trace Output
...
user: unauthenticated
authentication status='not_attempted' authorization status='not_attempted‘
DENIED: Either 'deny' or 'exception' was matched in policy
server.response.code: 200
client.response.code: 403
application.name: CNN
application.operation: none
DSCP client outbound: 65
DSCP server outbound: 65
Transaction timing: total-transaction-time 125 ms
Checkpoint timings:
stop transaction
Highlight shows the transaction’s user authentication results.

51. Policy troubleshooting
Trace Output
...
user: unauthenticated
authentication status='not_attempted' authorization status='not_attempted‘
DENIED: Either 'deny' or 'exception' was matched in policy
server.response.code: 200
client.response.code: 403
application.name: CNN
application.operation: none
DSCP client outbound: 65
DSCP server outbound: 65
Transaction timing: total-transaction-time 125 ms
Checkpoint timings:
stop transaction
Highlight shows the final result of the transaction.

52. Policy troubleshooting
Trace Output
...
user: unauthenticated
authentication status='not_attempted' authorization status='not_attempted‘
DENIED: Either 'deny' or 'exception' was matched in policy
server.response.code: 200
client.response.code: 403
application.name: CNN
application.operation: none
DSCP client outbound: 65
DSCP server outbound: 65
Transaction timing: total-transaction-time 125 ms
Checkpoint timings:
stop transaction
Highlight shows the response code, application, and QoS tags for the transaction.

53. Policy troubleshooting
Trace Output
...
user: unauthenticated
authentication status='not_attempted' authorization status='not_attempted‘
DENIED: Either 'deny' or 'exception' was matched in policy
server.response.code: 200
client.response.code: 403
application.name: CNN
application.operation: none
DSCP client outbound: 65
DSCP server outbound: 65
Transaction timing: total-transaction-time 125 ms
Checkpoint timings:
stop transaction
Highlight shows the total time to complete the transaction.

54. Policy troubleshooting
Trace Output
...
Transaction timing: total-transaction-time 108 ms
Checkpoint timings:
new-connection: start 1 elapsed 0 ms
client-in: start 1 elapsed 0 ms
scan-request-completed: start 1 elapsed 0 ms
server-out: start 1 elapsed 0 ms
server-in: start 107 elapsed 0 ms
client-out: start 107 elapsed 0 ms
access-logging: start 108 elapsed 0 ms
stop-transaction: start 108 elapsed 0 ms
Total Policy evaluation time: 0 ms
stop transaction
Highlight shows the end of the transaction marker.

55. Policy troubleshooting
Trace Output
...
Transaction timing: total-transaction-time 108 ms
url_categorization not completed
server connection: start 1
DNS Lookup: start 1 elapsed 66 ms
server connection: connected 86 first-byte 107 last_byte 108
client connection: first-response-byte 108 last-response-byte 108
Total time added: 0 ms
Total latency to first byte: 86 ms
Request latency: 0 ms
OCS connect time: 85 ms
Response latency (first byte): 1 ms
Response latency (last byte): 0 ms
stop transaction
Highlight shows the end of the transaction marker.

56. Policy troubleshooting
Trace Output
...
user: unauthenticated
authentication status='not_attempted' authorization status='not_attempted‘
DENIED: Either 'deny' or 'exception' was matched in policy
server.response.code: 200
client.response.code: 403
application.name: CNN
application.operation: none
DSCP client outbound: 65
DSCP server outbound: 65
Transaction timing: total-transaction-time 125 ms
Checkpoint timings:
stop transaction
Highlight shows the end of the transaction marker.

57. Policy troubleshooting
Additional Resources:
Policy Tracing
licytracetodebugaccessissues
Checkpoint Timing

58. Policy troubleshooting
Policy Coverage Statistics
Located at ip>:8082/Policy/Coverage
Statistics -> Advanced -> Policy -> Policy Coverage Statistics
Reset every time policy is pushed
Only reports rule matches, not specific objects in a list

59. Policy troubleshooting
Policy Coverage Output
...
40: <Proxy> condition=!__is_notify_internal (40)
1: DENY url.domain=//cnn.com/ (1)
39: ALLOW
: <ssl-intercept>
0: category="Financial Services" (0) ssl.forward_proxy(no)
37: ssl.forward_proxy(https)
Discuss what each item means:
The number is the count (number of times that policy object/rule has been matched).
There are lines for each rule and layer.
Objects and layer guards also have a coverage count in parenthesis.

60. Policy troubleshooting
SSL Troubleshooting
Policy Trace
Check Browser Warnings
Verify Encryption
Browsers Sunsetting Weak Encryption (AES-128 and weaker)
One or more certificates in the ProxySG chain aren’t strong enough
Solution: Certificates in the chain should be AES-256 or stronger
Example ProxySG SSL Error
Certificate Hostname Mismatch
DNS and Certificate CN don’t match
Solution: Align the URL/DNS/CN information on OCS
Workaround: Add an Ignore Hostname Mismatch rule for the site
Highlight a few of the more common errors seen with SSL and explain why these errors are seen and ways to address the underlying issue (or work around it, if the optimal solution cannot be implemented).

61. Additional resources SSL Deployment Guide ICAP Best Practices
oyment_Guide_6.5_later.pdf
ICAP Best Practices
egration.pdf
Policy Self-Help

62. Blue Coat Customer Forums
Community where you can learn from and share your valuable knowledge and experience with other Blue Coat customers
Research, post and reply to topics relevant to you at your own convenience
Blue Coat Moderator Team ready to offer guidance, answer questions, and help get you on the right track
Access at forums.bluecoat.com and register for an account today!

63. More technical training available
Practical Knowledge sessions on ProxySG Policy Optimization are scheduled September 21-25
WebEx based, complimentary training for Blue Coat customers
Login to BTO to sign up
Link to sign up in the follow-up you will receive following this webcast
Join Blue Coat senior technical instructor Keith Chomentowski for a more in-depth discussion on:
Policy Framework and Best Practice
Layer and rule ordering
Security best practice policy
 HTTPS/SSL Policy
Explicit vs. Transparent mode
SSL Intercept Layer Policy
SSL Access Layer Policy
 Policy Trace and Policy Statistics
Setup, analyze, explain trace components
Policy Coverage stats, Reference/Policy ID

64. Thank you for Joining Today!
Please provide feedback on this webcast and suggestions for future webcasts to:
Webcast replay and slide deck found here:
er-support-technical-webcasts
(requires BTO login)

65. **Submit using Webex Q/A**
Questions?
**Submit using Webex Q/A**