Next-Generation Firewall
Prevent Service Disruptions Using App-ID Update Safeguard
Table of Contents
Prevent Service Disruptions Using App-ID Update Safeguard
App-ID Update Safeguard ensures continuous service by enabling a Previous App-ID
attribute that references legacy application identities until new signatures are explicitly
configured.
| Where Can I Use This? | What Do I Need? |
|---|---|
|
This is a core Network Security feature for NGFWs and Prisma
Access; no prerequisites needed.
|
App-ID Update Safeguard is designed to prevent service disruptions and maintain
security posture when new App-ID content updates are installed. It acts as a
fail-safe mechanism, ensuring that traffic continues to be enforced according to
your original intent, even when Palo Alto Networks introduces new or modified
application signatures.
Security policies are typically built around the current state of App-ID. For
example, you might allow broad applications like ssl or
web-browsing while blocking unknown-tcp.
When a new Content Release update is installed, traffic that was previously
identified as ssl might be re-identified as a more specific
application, such as acme-app. If this new specific App-ID is not
explicitly added to your allow rules, the traffic could be unintentionally blocked
by the default deny rule, causing a service outage.
App-ID Update Safeguard prevents this by allowing the firewall to reference the
application’s history during policy enforcement. This is displayed at very points of
the interface with a content-defined attribute called Previous App-ID. This
attribute tracks the identity the traffic held in previous content versions. When
the feature is enabled, the NGFW utilizes a two-step policy lookup process
for new or modified applications. During the primary look up phase, the NGFW checks
for a new, specific App-ID that is explicitly configured in your security policy. If
a rule explicitly allows or blocks this specific App-ID, the rule is enforced
immediately. However, when App-ID update safeguard is enabled, a secondary lookup is
introduced, whereby the firewall performs a second lookup using the
Previous App-ID entries contained within an application.
If the Previous App-ID was allowed by your policy, the traffic is temporarily
allowed. If the Previous App-ID was blocked (or not allowed), the traffic remains
blocked.
App-ID Update Safeguard is intended to be used as a transitional tool to keep
your security policies operational, while retaining access to the latest App-ID
updates in the content releases. As a best practice, you should update your
security polices to use new App-IDs where applicable as soon as possible, and
before installation of the following content release, at the latest. The
subsequent content release refreshes the App-ID attribute associated with the
previous version, as such, the previous App-ID does not roll over, but gets
transitioned to the new App-ID, while new previous App-ID attributes are
added for upcoming new App-IDs.
Consider the following use-cases for App-ID Update Safeguard:
|
Use-Case
|
Behavior
|
Example
|
|---|---|---|
|
Preventing Service Outages for Currently Allowed
Traffic
|
preventing business-critical applications from being blocked when
a content update changes their App-ID. If a new App-ID is
introduced but not yet added to a security policy, the firewall
performs a second policy lookup using the application's previous
identities (e.g., SSL or web-browsing). If those previous
identities were allowed, the new App-ID is also allowed.
|
Palo Alto Networks releases a new App-ID for
acme-app. Previously, this traffic was
identified as ssl and web-browsing. The firewall interprets
acme-app as not explicitly allowed. It
checks the previous IDs (ssl and web-browsing). Since the policy
has a rule allowing SSL and web-browsing, the
acme-app traffic is allowed, preventing the
outage.
|
|
Maintaining Security
|
Ensures that App-ID Safeguard does not inadvertently open
security holes within your policy. For a new App-ID to be
allowed, all of its previous App-IDs must be allowed by
policy. If any previous App-ID is blocked (explicitly or via
default deny), the new App-ID remains blocked.
|
Traffic for acme-docs-editing has a list of
previous App-IDs that includes web-browsing, ssl, websocket, and
unknown-udp and the administrator follows best practices and
creates a rule to explicitly deny unknown traffic.
When the user tries to edit an ACME doc, the NGFW detects ACME
Docs Editing and checks the previous IDs. Because one of them
(unknown-udp) is explicitly denied by policy, the firewall
blocks the specific ACME Docs Editing traffic.
|
|
Explicit Policy Override
|
Explicit administrative actions always take precedence
over the App-ID Safeguard logic. If an administrator adds the
specific new App-ID to a rule, the firewall uses that rule
immediately during the first lookup.
|
The administrator proactively adds the new or updated
acme-docs-editing App-ID to a specific
allow security policy rule.
The traffic is allowed via the explicit allow rule based on the
current App-ID. The NGFW does not resort to using the
Previous App-ID logic.
|
|
Visibility and Transition Planning
|
Provides a transition period for administrators to update their
policies. By using the Application Command Center (ACC) and
logs, administrators can identify which applications are relying
on the safeguard and update their rules before the next content
update.
|
After an update, the administrator checks the ACC widget named
Rules allowing apps based on previous
App-ID.
If acme-app is currently being allowed only
because its previous IDs (ssl, web-browsing) are allowed. They
can use this information to create a new rule explicitly
allowing ACME App to ensure permanent access, independent of the
App-ID Safeguard feature.
|
- Verify that you have PAN-OS 12.1.5 or later installed.Log in to the PAN-OS web interface.Select and edit the settings.Enable or disable Enable App-ID Update Safeguard.
![]()
- This setting is disabled by default, as the secondary lookup used to reference the previous App-ID can result in a performance hit.
(IMPORTANT) App-ID Update Safeguard is a temporary tool to maintain connectivity while you transition to the latest signatures. As a best practice, make sure to review and update your security policies to the new App-IDs before the next content release, as previous attributes do not roll over once a new update is installed.(Recommended) Review App-ID applications based on their Previous App-ID attribute through the following entry points:- ACC—The Application Command Center (ACC) includes widgets such as Rules allowing apps based on previous App-ID. These help you quickly identify which policies need to be updated before the next content release. Refer to Monitor Impacted Rules and Applications for more information.When App-ID Safeguard is initially turned on, it is highly recommended that the administrator review the rules and applications being allowed by the Previous App-ID, and, if necessary, make changes to any impacted rules.
- Application Objects —When you click on a specific application to view its details, you will see a new attribute field named Previous App-ID listed alongside other standard attributes.
![]()
You can also search for applications based on this new attribute. The search bar in the Applications tab supports filtering by Previous App-ID, allowing you to find all applications that used to be identified as a specific legacy App-ID.![]()
- Log Viewer—Logs display the Application (App-ID) and the associated Rule, but also include the corresponding Previous App-ID, showing the specific attribute that allowed the traffic to pass.
![]()
- Review New App-IDs in a Content Release—Before installing a new content update, you can Review Apps, which includes New and Modified Applications since last installed content. The application preview window displays the Previous App-ID for a selected application.
