App-ID Cloud Engine Processing and Policy Usage

• When the firewall first connects to ACE, the firewall downloads a catalog of the available ACE App-IDs and you can use those App-IDs in Security policy. The firewall does not download the full application signatures, only the catalog. The catalog enables you to specify ACE App-IDs in Security policy even if the applications have never been seen on the firewall. ACE pushes catalog updates to firewalls regularly so that firewalls have access to the latest ACE App-IDs.
  If an application arrives at the firewall that is identified as ssl or web-browsing and the firewall doesn’t have its signature, the firewall sends the payload to ACE. If ACE has a matching App-ID, then ACE sends the full signature back to the firewall. If the traffic doesn’t match any ACE signatures, then ACE sends the payload to the Machine Learning (ML) engine. The ML engine analyzes the payload and develops a new App-ID in conjunction with the human content team. The ML engine sends the new App-ID to ACE and requesting firewalls can download it and use it in Security policy.
  Because it can take several minutes to retrieve an App-ID from ACE and longer if a new App-ID must be developed, cloud application detection is not inline on the firewall. The firewall does not wait for a verdict to process the application traffic. The firewall processes the traffic as ssl or web-browsing until it receives an App-ID from ACE.
• When a firewall requests an App-ID from ACE, the firewall continues to process the traffic against the current rulebase until it receives an App-ID from ACE and the App-ID is applied in Security policy.
• The firewall handles ACE App-IDs differently than it handles App-IDs delivered by content updates. You don’t have to examine how new ACE App-IDs affect Security policy before they are installed on the firewall because the firewall handles new ACE App-IDs according to your existing Security policy. Your existing Security policy rules control new ACE App-IDs until you explicitly use ACE App-IDs in Security policy. For example:
  1. An application is identified only as “ssl” and you have a Security policy rule that allows SSL traffic, so the ssl rule allows that application.
  2. The firewall sees an application identified as ssl and sends the payload to ACE.
  3. ACE identifies the actual application. If the application exists in the ACE database, then ACE sends its App-ID to the firewall. If it’s a new application without an ACE App-ID, then ACE forwards the payload to the ML Engine. The firewall does not receive the App-ID until the ML Engine and the human content team assign an App-ID and send it to ACE.
  4. The rule that allows ssl traffic still allows the newly-identified application, even though its App-ID is no longer “ssl”. (However, if you use the new ACE App-ID in Security policy, that policy controls the traffic. Similarly, traffic previously identified as web-browsing continues to obey the Security policy rules that control web browsing traffic until you use the ACE App-IDs in Security policy.)
     The exception to this behavior is if another Security policy rule already specifies the App-ID given to the traffic by ACE. The Security policy rule with the specific App-ID takes precedence over the rule with the less specific ssl App-ID. For example, if the firewall identifies an application as ssl and sends the payload to ACE to obtain the granular App-ID. ACE returns the App-ID “app-abc”. The firewall already has a Security policy rule that allows the App-ID “app-abc”, so the application’s traffic now matches that rule.
     If the rule that specifies the actual App-ID is a block rule, the application is blocked even though there is a rule that allows ssl traffic. The rule with the more specific (granular) App-ID is the one the firewall acts on.
  Until you explicitly add new ACE App-IDs to Security policy rules, the firewall controls them with the same rules that controlled those applications before they had ACE App-IDs and were identified as ssl or web-browsing traffic. For example, if the firewall sees an application identified as web-browsing and then receives an ACE App-ID for the traffic, but you don’t use that ACE App-ID in a Security policy rule, then the firewall still controls that traffic using the rule that controls web-browsing traffic—if you block web-browsing traffic, then the traffic is blocked, and if you allow web-browsing traffic, the traffic is allowed.
• The firewall caches some information so that the firewall can avoid repeatedly sending data to the cloud and requesting verdicts. If the firewall is waiting for a verdict from ACE, the firewall doesn’t forward the same application data twice.
• On the firewall, a particular container app and its functional applications are either all cloud-based App-IDs or all content-based App-IDs. One App-ID delivery method defines a container app and all of its functional apps.
• If cloud-based, content-provided, and user-defined custom App-ID names overlap, the order of precedence is:
  1. Custom App-IDs—These App-IDs take precedence over all other App-IDs. If the firewall attempts to download an ACE application with the same App-ID, the commit fails because two applications on the same firewall cannot have the same App-ID.
     In this case, you can rename the custom application, or if the custom application is the same application as the ACE application, you can delete the custom application and use the ACE application.
  2. Content-based, predefined App-IDs—These App-IDs take precedence over ACE cloud App-ID definitions.
  3. ACE cloud App-IDs—Custom and content-based App-IDs take precedence over ACE App-ID definitions.
• If an App-ID matches a container app, the firewall downloads the container app’s App-ID and all of its functional apps. For example, if the firewall retrieves the facebook container app, it also retrieves facebook-base, facebook-chat, facebook-post, etc.
• When you take any of the following actions to add ACE App-IDs to Security policy rules, the firewall no longer matches the application traffic to the ssl or web-browsing rule, it matches the application traffic to the rule that controls the specific App-ID:
  • Create Application Filters to automate adding ACE App-IDs to Security policy.
    Use Application Filters to automate adding ACE App-IDs to Security policy rules. When a new App-ID matches an Application Filter, the firewall automatically adds it to the filter. When you use that Application Filter in a Security policy rule, the rule controls the application traffic for the new App-IDs that were automatically added to the filter. Application Filters are your “Easy Button” for securing ACE App-IDs automatically to gain maximum application visibility and control with minimum effort.
  • Add ACE App-IDs to Application Groups.
  • Use Policy Optimizer to add ACE App-IDs to a cloned rule or to an existing rule, or to an existing Application Filter or Application Group. You can use Policy Optimizer to create new Application Filters and Application Groups directly from within the Policy Optimizer tool. Use Policy Optimizer’s sorting and filtering tools to prioritize the rules to work on and to assess how many ACE App-IDs match those rules.
  • Add an ACE App-ID directly to a new or existing Security policy rule.
  When you add a cloud App-ID to a Security policy rule directly or by using an Application Filter or an Application Group, that rule controls the application.
• When you create Application Filters, exclude ssl and web-browsing from the filters. Together, ssl and web-browsing match all browser-based cloud applications, so an Application Filter that includes ssl and web-browsing matches all browser-based cloud applications.
• Active/Passive High Availability:
  • The Active firewall syncs the ACE catalog to the passive firewall so that they have identical catalogs.
  • The Passive firewall does not initiate connections to ACE until it becomes the Active firewall.
• Active/Active High Availability: Each device fetches catalogs and signatures separately, so the catalogs and signatures are not synced. However, commits fail if the catalog is out-of-sync on peers and ACE App-IDs are referenced in Security policy rules. If the catalogs of peer HA firewalls are out-of-sync, wait a few minutes for the updates to reach the devices and become in-sync again.
• A Panorama commit all/push failure to managed firewalls occurs if:
  • Managed firewalls do not have a valid SaaS Security Inline license and therefore do not have the ACE catalog. In this case, remove the ACE objects from the pushed configuration and try again.
  • The connection between a managed firewall and ACE goes down and the pushed configuration includes applications that are not in the ACE catalog on the firewall. In this case, check the firewall connection to the ACE cloud and re-establish the connection if necessary so that the firewall can update its catalog.
    The operational CLI command show cloud-appid connection-to-cloud provides the cloud connection status and the ACE cloud server URL.
  • The ACE catalog on Panorama and the ACE catalog on managed firewalls is out-of-sync, which results in pushed configurations that include ACE apps that are not in the firewall’s catalog. If the connection between the firewall and ACE is up, the outdated catalog will update in the next few minutes automatically and resolve the issue. (Wait five minutes and try again.)
    You can use the CLI command debug cloud-appid cloud-manual-pull check-cloud-app-data to update the catalog manually.
• Some Security profiles such as the File Blocking, Antivirus, WildFire, and DLP profiles can specify applications as part of the profile. Only content-provided App-IDs are supported in Security profiles. ACE App-IDs are not supported in Security profiles. ACE App-IDs are intended for use in Security policy rules only.
• Because ACE App-IDs are supported only for Security policy, they are not supported in Application Override, Policy-Based Forwarding (PBF), QoS, or SD-WAN policy rules.
  You cannot see ACE App-IDs in Application Override or PBF rule configuration. However, ACE App-IDs are visible (able to be selected) in QoS and SD-WAN policy rule configuration and may be present in Application Groups or Application Filters applied to a rule. If you use ACE App-IDs in these rules, the policy doesn’t control the application traffic and there is no effect on the application traffic—the rules do not apply to the ACE App-ID traffic even though ACE App-IDs were added to the rule.