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? |
|---|
Prisma Access Next-Generation Firewall
|
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. The Previous App-ID
attribute appears at various points within the interface. 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:
App-ID Update Safeguard Use-Cases
|
Use-Case
|
Behavior
|
Example
|
|
Preventing Service Outages for Currently Allowed
Traffic
|
Prevent business-critical applications from getting blocked when
a content update changes the App-ID value. 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.
|
