App-ID Cloud Engine Processing and Usage
When the firewall downloads App-ID Cloud Engine (ACE) App-IDs, it’s important to understand how the firewall handles those App-IDs and how the firewall handles ACE App-IDs when there are also predefined content-based App-IDs for the same applications. The Palo Alto Networks content team develops predefined content-based App-IDs and updates them with modified and new App-IDs through application content updates (a valid support contract is required for updates).
ACE requires a SaaS Security Inline license. Firewalls that don’t support ACE have only predefined content-based App-IDs. The ACE App-ID catalog doesn’t contain content-based App-IDs.
You can only use ACE App-IDs in Security policy rules. You cannot use ACE App-IDs in any other type of policy rule.
- When the firewall first connects to the App-ID cloud engine, the firewall downloads a catalog of the available ACE App-IDs, and you can use those App-IDs in Security policy. It does not download the full signatures. The catalog enables you to use 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, web-browsing, unknown-tcp, or unknown udp and the firewall doesn’t have its signature, the firewall sends the payload to ACE. If ACE has an App-ID for the traffic, ACE sends the full signatures 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 the new App-ID in conjunction with the human content team and drops traffic that isn’t related to applications. 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 application from ACE for which it has an App-ID 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, web-browsing, unknown-tcp, or unknown-udp until it receives an App-ID from ACE and then continues to process the traffic in that way until you receive the new App-ID and use it in Security policy.
- When a firewall requests an App-ID from ACE, the firewall doesn’t hold the traffic, it continues to process the traffic as usual until it receives an App-ID from ACE.
- The firewall handles cloud App-IDs downloaded from ACE differently than it handles content-delivered App-IDs. You don’t have to examine how new ACE App-IDs affect Security policy before they are installed on the firewall because the firewall uses ACE App-IDs according to previously existing Security policy. Your existing Security policy rules control the new ACE App-IDs until you explicitly use ACE App-IDs in Security policy. For example:
If you don’t explicitly add new ACE App-IDs to Security policy rules, the firewall continues to control them with the same rules that controlled those applications before they had ACE App-IDs and were identified as ssl, web-browsing, unknown-tcp, or unknown-udp traffic. For example, if the firewall sees an application identified as unknown-tcp 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 unknown-tcp traffic—if you block unknown-tcp traffic, then the traffic is blocked, and if you allow unknown-tcp traffic, the traffic is allowed.
- 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.
- The firewall sees the ssl application and sends the payload to ACE.
- ACE identifies the actual application. If the application exists in the ACE database, then ACE sends that App-ID to the firewall. If it’s a new application for which ACE does not have an 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.
- 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, unknown-tcp, and unknown-udp continues to obey the Security policy rules that control those types of traffic until you use the ACE App-IDs in Security policy.)In contrast to ACE App-IDs, if the App-ID was a predefined, content-provided App-ID, then the rule that allows ssl traffic would not longer match the application. The firewall would block it if no Security policy rule explicitly allows it.The exception to this behavior is if another Security policy rule 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. 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.In this example, if you add the cloud App-ID for the application previously identified as “ssl” to an existing or cloned rule either directly or by using an Application Filter or an Application Group, that rule controls the application. The “ssl” rule no longer controls the application because the application is specifically identified in another rule.
- The firewall caches some information so that the firewall can check the cache and 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.
- 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:
- Custom App-IDs—These App-IDs take precedence over all other App-IDs and 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.
- Content-based, predefined App-IDs—These App-IDs take precedence over ACE cloud App-ID definitions.
- 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 on an ACE App-ID, you affect how Security policy handles that ACE App-ID because the firewall will take action based on the specific ACE App-ID instead of based on the application’s previous ssl, web-browsing, unknown-tcp, or unknown-udp App-ID:
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. Until you take one of these actions to control cloud-delivered App-IDs, the firewall uses existing ssl, web-browsing, unknown-tcp, or unknown-udp Security policy rules to control ACE applications.
- 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. In other words, Application Filters are your “Easy Button” for securing ACE App-IDs automatically to gain maximum application visibility and control with minimum effort.
- Use Policy Optimizer to add the 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 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 so they 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 connection to the ACE cloud and re-establish the connection if necessary so that the firewall can update its catalog.The operational CLI commandshow cloud-appid connection-to-cloudprovides 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 also use the CLI commanddebug cloud-appid cloud-manual-pull check-cloud-app-datato 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.
Recommended For You
Recommended videos not found.