App-ID Cloud Engine Best Practices

Understand how ACE App-IDs work on the firewall before you enable ACE.
Read ACE processing and policy usage to learn how the firewall handles ACE App-IDs, including:
How and when the firewall downloads ACE App-IDs.
The differences between ACE App-IDs and content-delivered App-IDs.
How the firewall resolves conflicts between ACE App-IDs, content-delivered App-IDs, and custom App-IDs, including container applications (e.g., facebook) and their functional applications (e.g., facebook-post, facebook-download, etc.).
HA behavior.
Panorama behavior when committing or pushing.
ACE identifies specific SaaS applications that the firewall previously identified as ssl or web browsing traffic. When you enable ACE:
If you have a Security policy rule that allows ssl and web browsing traffic, downloaded ACE App-IDs match that rule unless they match an application filter used in a rule. ACE App-IDs match an application filter based on the filter’s criteria, including tags, just like content-delivered App-IDs. If an ACE App-ID matches an application filter in a rule, the application is added implicitly to the rule. That rule controls the ACE application instead of the ssl/web browsing rule, including the rule’s action (allow or deny), the users who can access the application, the sources and destinations, and how the application is inspected and logged.
Until you add an ACE App-ID explicitly to a rule or an ACE App-ID matches an application filter that implicitly adds it to a rule, an ACE application continues to match the ssl/web browsing allow rule, the same as before enabling ACE.
If you have no rule that allows ssl and web browsing traffic, follow the advice in Step 3 to discover and control ACE App-IDs.
When you use an ACE App-ID explicitly in policy, the firewall treats the application the same way it treats content-delivered applications.
Review your Security policy rulebase to find rules that use application filters before you enable ACE.
Application filters allow applications based on matching filter criteria, including tags, so they automatically add applications to rules and you have to examine those rules to see which specific applications each filter allows and who has access to those applications. When an ACE App-ID matches an application filter in a rule, that rule may not allow the same users as the ssl and web browsing rule. Users who had access to the application in the ssl and web browsing rule may lose access to the application because it no longer matches that rule and those users aren’t specified in the explicit rule.
It’s critical to understand who needs to use which applications for business purposes, especially in environments with many rules, applications, and user groups. For example, if you use the
Web Apps
tag in an application group in a rule, the tag implicitly adds matching ACE applications to the rule. Those ACE applications don’t match the ssl and web browsing rule and only the users specified in the
Web Apps
rule can access them.
If no rules have application filters, there is no risk that ACE applications will automatically match existing rules after you enable ACE because you haven’t added any ACE applications explicitly to rules yet.
If you use application filters in Security policy rules, when you enable ACE:
For deny rules, ACE applications that match the rule are blocked, which is exactly what you intend to do with applications that match the deny rule. The rule is more effective because you now block unsanctioned SaaS applications that the firewall couldn’t identify without ACE.
For allow rules, closely monitor the applications the rule allows. Implicitly adding applications with a filter is based on criteria, not on an administrator purposefully adding specific applications. The most impacted rules are rules with filters based on broad tags such as
Web App
, which applies to the majority of both ACE and content-delivered App-IDs.
In existing deployments, keep in mind that if you have a rule that allows ssl and web browsing traffic, then you were allowing all of the applications that ACE now identifies. Use application filters to block the types of traffic you know you don’t want and continue to allow the rest of the applications while you evaluate what you want to sanction and what you want to block.
Step 3, step 4, and step 5 show you how to use application filters to add ACE App-IDs to rules safely.
Explicitly allow ACE applications using application filters so you can evaluate the applications in a controlled manner.
Creating application filters to allow application types that you want on your network is easier than periodically reviewing all the new ACE applications to determine which specific applications to allow. Application filters enable you to examine the same types of applications side-by-side and determine which ones you want to allow for business purposes.
Create an application filter based on the
App-ID Cloud Engine
tag, which matches all ACE App-IDs (applications that were identified as ssl or web browsing before ACE). Attach the filter to a Security policy rule with the appropriate Security profiles and logging, and place the rule at the bottom of the Security policy rulebase. This ensures that the rule matches and allows all new and existing ACE App-IDs unless they are specified in an earlier rule. It also ensures that the firewall block rules take effect before the firewall compares traffic to the ACE allow rule.
As you become more familiar with ACE applications, create more specific application filter rules based on subcategories, tags, risk, and characteristics to match smaller groups of applications. Place these allow rules directly above the general ACE allow rule based on the
App-ID Cloud Engine
tag. Narrowing down the applications that match a filter enables you to examine the more similar applications side-by-side and determine which ones you want to allow for business purposes.
Review the New App Viewer in Policy Optimizer frequently to see which downloaded ACE App-IDs match Security policy rules and to gain greater visibility into those applications. Evaluate the applications and determine whether to allow or block them.
Do not add users to rules that have application filters to broaden them because that allows more access than necessary to applications. Over-provisioning user access increases risk and goes against Zero Trust Network Access principles. Allow only users who need access for business purposes.
Use application filters to block application types that you don’t want on your network based on subcategories, tags, and characteristics. Don’t use risk as blocking filter criteria (risk is an assessment of relative risk within a category or subcategory, not necessarily of malicious usage). Use risk to determine how to inspect, log, and control the traffic appropriately.
Blocking based on application filters is easier than periodically reviewing all the new ACE applications to determine what you do and don’t want on your network. Using application filters means the firewall immediately blocks new applications that you know you don’t want.
Determine ACE application types that you don’t want on your network. Create block rules based on those application types and place them above the catch-all rules.
Determine if there are specific applications within those types that you want to allow on your network. If you want to allow some of the applications:
Clone the block rule.
Change the
Action
to
Allow
.
Remove all applications from the rule except the applications you want to allow.
Specify the users who need access to the allowed applications, add the appropriate Security profiles, and configure logging.
Place the new allow rule directly above the block rule to create exceptions to the block rule.
Monitor the block rule to see if there are any other specific applications that you want to allow and either add them to an existing allow rule or create a new allow rule to make those exceptions.
For example, file sharing applications can be particularly risky. Allow only file sharing applications you use for business purposes, only for the necessary users, and inspect and log the traffic. In the next rule in the Security policy rulebase, use an application filter based on the
file-sharing
subcategory to block all file sharing applications that you don’t explicitly, purposefully allow. Monitor the block rule to ensure that it doesn’t block file sharing applications you want to allow.
Convert broad rules based on application filters into narrow rules based on application groups.
Rule Usage statistics show how rules are used in your environment. Use Policy Optimizer to add applications to application groups (PAN-OS 10.1 and later) or add applications to application groups manually to create tighter rules.
The end goal is to allow only the applications you sanction instead of allowing a broader range of applications that match an application filter. Use application filters to discover applications on your network and use application groups to specify the exact applications you want to allow. To use Policy Optimizer to convert application filter based rules into application group based rules:
Examine the applications that match rules based on application filters and decide which applications you want to allow.
For each rule based on an application filter, select the applications to allow and add the applications to an application group in a cloned or existing rule.
After you move applications to rules based on application groups, select the original application filter based rules in Policy Optimizer and
Reset Rule Hit Counter
. This resets the
Days with no new apps
counter so you can see when new applications match the application filter based rules.
Monitor rules based on application filters to see when the
Days with no new apps
counter reaches a threshold that indicates that a rule is no longer seeing new applications. The threshold depends on your environment and the types of applications the application filter matches. Take into account applications used only at certain periods, such as quarterly or annual events, and leave the filter in place long enough to see those applications. If the application filter rule matches no applications that you want on your network, disable or delete the rule, depending on your enterprise’s policy.
Keep the rule based on the
App-ID Cloud Engine
tag at the bottom of the rulebase as a catch-all rule to allow new ACE applications. After you move from application filter based rules to application group based rules, all new ACE App-IDs match the catch-all rule. Periodically examine the rule to determine which applications to add to existing rules and application groups, which applications require new rules, and which applications you want to block.
Check the
New App Viewer
frequently to gain visibility into and explicit control of new ACE App-IDs that were previously identified as ssl or web browsing applications. Use the new ACE App-IDs explicitly in policy instead of as ssl or web browsing applications.
Review new ACE App-IDs that the firewall downloads regularly in Policy Optimizer’s New App Viewer. Use Policy Optimizer to add applications to existing and new application groups or to add applications directly to existing Security policy rules. Continue to use Policy Optimizer to convert application filters to application groups.