Use Temporary Rules to Tune the Whitelist

Although the end-goal of a best-practice application-based policy is to use positive enforcement to safely enable your whitelist applications, the initial rulebase requires some additional rules designed to ensure that you have full visibility into all applications in use on your network so that you can properly tune it. The initial rulebase you create will have the following types of rules:
  • Whitelist rules for the applications you officially sanction and deploy.
  • Whitelist rules for safely enabling access to general types of applications you want to allow per your acceptable use policy.
  • Blacklist rules that block applications that have no legitimate use case. You need these rules so that the temporary rules that “catch” applications that haven’t yet been accounted for in your policy don’t let anything bad onto your network.
  • Temporary allow rules to give you visibility into all of the applications running on your network so that you can tune the rulebase.
The temporary rules are a very important part of the initial best practice rulebase. Not only will they give you visibility into applications you weren’t aware were running on your network (and prevent legitimate applications you didn’t know about from breaking), but they will also help you identify things such as unknown users and applications running on non-standard ports. Because attackers commonly use standard applications on non-standard ports as an evasion technique, allowing applications on any port opens the door for malicious content. Therefore, you must identify any legitimate applications running on non-standard ports (for example, internally developed applications) so that you can either modify what ports are used or create custom applications to enable them.
If you have existing Application Override policies that you created solely to define custom session timeouts for a set a of ports, convert the existing Application Override policies to application-based policies by configuring service-based session timeouts to maintain the custom timeout for each application and then migrating the rule the an application-based rule. Application Override policies are port-based. When you use Application Override policies to maintain custom session timeouts for a set of ports, you lose application visibility into those flows, so you neither know nor control which applications use the ports. Service-based session timeouts achieve custom timeouts while also maintaining application visibility.

Related Documentation