Cisco WSA Best Practice

[Mandeep singh5]

Hello Community,

I've gone through the Cisco WSA best practice document & I saw that 20 or less than 20 access policies configured in WSA are considered medium complexity & best practice. 

I just want to confirm that this number (20) varies from model to model.

If I have an S195 appliance & S695 then this best practice consideration is for both or for lower series appliances only?

Thanks, everyone in advance who will gonna guide me on this!!

[Ken Stieers]

That is a very loose rule... with a 695, you can get away with more, but it does depend upon how much traffic you have.  Heavy traffic and many rules will of course cause issues... I'm not sure about a 195, but I know that we had issues with a 190, it was just too small(300 users) and our ruleset was only 5 or 6 policies. 

Its a balancing act, and you won't know until you get it in... which makes the virtual option so great... you can spin up as many as you need, using whatever size you need, using the same user count based license.

[fw_mon]

Hello @Mandeep singh5 

interestingly, if you carefully read the the best practices document, you'll see it doesn't mention any model variance at all, this means the limits are of internal nature like (spin)locks, mutex, syncronizations between processes and so on - something that cannot be scaled up just by adding CPUs.

This describes an impact of high complexity policy: "When a configuration becomes too complex, the first symptoms usually include slow response in the web interface and CLI. There may not be a significant impact to users at first. But the more complex the configuration is, the more time the proxy process must spend in user mode. Because of this, checking the percentage of time spent in this mode can be a useful way to diagnose an overly complex configuration as the cause of a slow WSA."

and:

"The way in which policies are configured has a direct impact on resource usage and the overall health and performance of
the WSA. An overly complex or poorly designed set of policies can cause instability and slow responsiveness from
the appliance."

Also checks suggestions how to handle high complexity configurations (usually migrations from BlueCoat Proxy SG or similar policy-based proxies):  "A common misconception for administrators is that there must be a unique ID profile and corresponding
decryption policy and access policy. This is an inefficient strategy for policy configuration. When possible,
policies should be “collapsed” so that a single ID profile can be associated with multiple decryption and access
policies. This is possible because all of the criteria in a given policy must match in order for traffic to match the
policy. Being more general in the authentication policy and more specific in the resulting policies allows for fewer
policies as a whole."

Setup a monitoring of prox_track and SHD logs to have a deep understanding of the impact of the policy complexity on performance of WSA/SWA.

Google for BRKSEC-3303 to read about prox_trac monitoring. There is also a free Splunk App to setup a prox_track monitoring.

[Mandeep singh5]

Hello @fw_mon 

Currently, the case is that I'm engaged in a project in which I need to migrate from bluecoat SG proxy to Cisco WSA S695.

If we talk about the existing policy which is configured in Bluecoat then it is around 480. Firstly, I documented all those web access policies and then I optimized it by merging the policies which have the same source or destination. After merging the policies now it is around 370. 

First of all this number 370 is high as per my research on best practices.

Secondly, There were around 100+ rules in which on source there is just a single IP address of a host. As per the Cisco best practices document, It is also not recommended to define just a single IP on the identification profile rather it is recommended to define the range or subnet.

As per the client's perspective, They just want to allow a few URLs for those hosts.

[fw_mon]

Hello @Mandeep singh5 

for ProxySG, 480 is a rather modest number of policies, I saw five-digits number of policies and objects. What is also important is a number of layers (especially web access layers), if combined objects exist, what is the default action (allow or deny) and which actions are used (there are several block actions: deny, force_deny, force_exceptions etc., and also several allow actions: OK, ALLOW etc.). If you have just a deny actions, then a rule in one of the following layers can overwrite an action in a previous layer - this policy is very difficult to migrate to a policy based logic like WSA where the "first match wins" concept is used, the policy must be radically simplified.

Regarding hunderts of src->dest policies you can combine all "good" sources with all "good" destinations and put them in one policy. Any of these sources will have access many destinations, but all of them are "good" destinations, so there are no security concerns.

The WSA works differently and has a policy based logic, and proxysg has a rule-based multi-layer logic, that cannot be mapped 1:1 with WSA.