Private App Security has its own set of policies, separate from the regular
Prisma Access Security policies. Prisma Access Security policies are evaluated first,
and Private App Security policies are evaluated next. Private App Security policies
inspect traffic that:
is destined for private applications (hosted behind a service
connection or ZTNA Connector)
and
is enabled by the Prisma Access Security policies.
Private App Security Policy Types
Private App Security policies are evaluated in the following order, with
each policy having its own priority pool:
Bypass—These policies exempt certain traffic from any other
Private App Security checks (for example, exempt a test tool running
specific tools against the application). Configure these policies for a
defined time window to avoid creating permanent holes in the Private App
Security posture.
Custom—Custom policies enable admins to:
Drop requests, or add or update certain headers based on specific
matching criteria (CEL rules) or
Ban or throttle traffic that’s breaching a certain threshold of requests
per second (rate limiters)
OWASP—These policies provide protection against Top 10 OWASP
attacks (such as cross-site scripting and local file inclusion).
At a minimum, we recommend that every application is
protected by the OWASP best practices policies.
Currently, Private App Security does not inspect mTLS
traffic or connections initiated without the SNI field. To ensure all traffic to
private applications is evaluated by Private App Security policies, customers can
use regular TLS and mandate the presence of the SNI field. This can be enforced on
the web application server itself.
Policy Status
A common concern admins have when enabling Private App Security policies is
about unexpected outcomes, such as affecting the application's functionality. To
enable admins to take data-driven decisions and ensure the outcome of a certain
policy is the one intended, Private App Security provides the ability to set a
policy status to Recommended, Enforced, or Preview.
Recommended Policies
Recommended policies are policies that are automatically generated by the Private
App Security Behavioral Analysis function, once it has a high confidence that a
suspicious activity is attempted against the application. Private App Security
automatically "learns" the behavior of each application that is front-ended.
Once this baseline is achieved (variable depending on the amount and type of
application traffic), Private App Security is able to detect anomalies and, at
the same time, generate policy recommendation to mitigate these attacks. In the
Recommended state, the policies are not evaluated—they need to be vetted by the
admin and set into either Preview or Enforced state.
Private App Security Behavioral Analysis automatically generates recommended
policies once it gains high confidence that a suspicious activity is targeting
the application. Private App Security automatically learns the behavior of each
application it front-ends. Once the system achieves this baseline (which varies
depending on the amount and type of application traffic), Private App Security
detects anomalies and simultaneously generates policy recommendations to
mitigate these attacks. Policies in the Recommended state do not run; the admin
must vet them and set them into either a Preview or Enforced state.
Note that admins can suppress policy recommendations when they determine that an
anomaly is actually expected behavior (such as a random test, a specific user
role's activity, and so on).
A specific policy can be muted—This policy recommendation will be hidden
for 30 days, even if new anomalies that would normally trigger it
continue to occur.
A specific application can be muted—This disables all behavioral
intelligence for the entire application, and no further recommendations
will be generated.
Previewed Policies
Managing application security can be a complex task for administrators. They
often have to enforce a large number of policies, and these policies must be
constantly updated to keep pace with the applications they protect, which are
also frequently evolving. However, updating security policies can be risky.
Administrators worry that a new policy might unintentionally disrupt an
application's functionality or accessibility.
To help administrators mitigate these risks, you can set new or updated policies
to the Previewed state. This provides a detailed overview
of the policy's potential effects, such as which users or applications might be
affected and the geographical distribution of potential attack sources. This
way, you can see the potential impact before fully enforcing the policy.
Enforced Policies
In the Enforced state, the policy takes action; for example,
dropping matching traffic, updating headers, and blocking attacks.
Define Private App Security Policies
After you enable the Private App Security license, you define Private App Security
policies.
Log in to Strata Cloud Manager.
Go to ConfigurationApplication ServicesApplication SecurityAll Policies to view all of the applications that are accessed and used in
your environment, as well as the amount of data transferred to these
applications. This data includes applications you have protected, or
provisioned, with security policies.
View Security Policies
View details about your security policies.
Select Recommended, Previewed, or
Enforced policies, which are then listed at the left
side of the screen. You can sort your policies by number of
Anomalies or policy Name.
Use drop-downs to Add Filters as desired. Default filters
are Date Range, Locations,
Sources, and Applications. You
can also choose to filter by Source Country,
Destination Country, Destination
Port, Destination IP, and
Domains.
Policy Details—Highlight a policy on the left to see its
details on the right.
Last Update—The last time the policy was
updated.
Created Date—The date the policy was
created.
Impacted Users—Number of users affected by
anomalies this policy protects against.
Impacted Apps—Number of applications affected by
the policy.
Anomalies—A graph detailing when anomalies
occurred.
Matching Expression—The matching expression uses
Common Expression Language (CEL) and can perform checks against requests
attributes such as the ones below:
Field
Type
Field Description
request.ip
String
The client's internal IP, 10.x.x.x
request.external_ip
String
The client's external IP
request.headers
Map
A string-to-string map of the HTTP
request headers. If a header contains multiple
values, the value in this map is a comma-separated
string of all header values. The keys in this map
are all lowercase.
We recommend that you first check for
availability using has(), such as
has(request.headers['header-key']) &&
request.headers['header-key'] !=
'header-value'.
request.cookies
Map
A string-to-string map of the HTTP
request cookie headers. If a header contains
multiple values, the value in this map is a
comma-separated string of all header values. The
keys in this map are all lowercase.
request.method
String
The HTTP request method, such as GET or
POST.
request.path
String
The requested HTTP URL path.
request.query
String
The HTTP URL query in the format of
name1=value&name2=value2, as it appears in the
first line of the HTTP request. No decoding is
performed.
request.region_code
String
The unicode country code that is
associated with the origin IP, such as US.
request.user
String
Palo Alto Networks authenticated user.
Enforcement Impact—Map view of the impacted users and
applications this policy affects. Click on the map locations for information to
help determine whether or not you want to use this recommended policy.
Anomaly Requests—See information about the anomalies this
policy addresses, such as when it occurred, source IP, user, attacked app and
policy type. Select View under Request
Details for more information.
Affected applications—Information about the applications
affected by the policy.
You can select Edit to modify the policy. If you like
a policy but want to test it, move the policy to
Preview. Select Enforce to
enable the policy. You can also simply review any policy and choose not to
take action.
Configure a Bypass Policy
A Bypass policy disables Private App Security for a specific
user or application. Use these steps to configure a Bypass
policy manually.
Go to ConfigurationApplication ServicesApplication SecurityAll Policies and select Add Policy.
Select Bypass, and complete the following information.
Name—Provide a unique name for the policy.
Policy Description (Optional)—Provide a policy
description.
Policy Status—Select
Preview or Enforce.
Preview—Enables you to preview, test, and
modify your policy before enforcing it on your applications.
Enforce—When you're satisfied with how
the policy functions in Preview mode, set
it to Enforce.
Add Association—Choose the association type from
the drop-down.
Tenants—Associate all applications in the
selected tenant.
Application Groups—Associate all
applications in a selected application group.
Applications—Select individual
applications to associate.
FQDNs—Select individual FQDNs to
associate.
Priority—Priority of the policy. This priority is
relevant only within the Bypass policies priority pool.
Trigger Response—Set requests that match policy
criteria to Bypass or Not
Bypass.
Expression—Add a logical expression to define the
matching criteria for the rule.
CEL
expressions can be complex and challenging to write. To help admins
craft expressions for particular use cases, we provide the option
for the admin to Generate CEL Expression
and describe the use case in normal language. When the admin clicks
generate again, a draft of the CEL expression is automatically
created; review the formula and tune it manually if needed: CEL expression
formula.
Start Time in PDT (Date/HH/MM)—The start time for
the moment the policy starts being evaluated.
We recommend avoiding permanent Bypass policies, because they can
become a risk. For this reason, you can set Start Time and Duration
for Bypass policies.
Duration—How long the rule should be active in
number of minutes.
Save your changes.
Configure a Custom Policy
In a Custom policy, you can apply custom rules to your
Security policy. Use these steps to create a custom policy.
Go to ConfigurationApplication ServicesApplication SecurityAll Policies and select Add Policy.
Select Custom, and complete the following information.
Under Type, select CEL or
Rate Limiter.
CEL—Common Expression Language (CEL)
policies can block specific traffic defined by the matching
expression or add or update certain headers for the requests
defined by the matching expression.
Rate Limiter—Prevents volumetric DDoS
attacks against the application by limiting the permitted number
of requests per second.
Throttle—Enforces a maximum limit
per second by throttling the requests to a
user-configured threshold.
Ban—A rate-based ban applies a
rate limit to requests that meet a specific rule for
each client, followed by a temporary ban for those
clients if they surpass a user-defined threshold, for a
set duration.
Name—Provide a unique name for the policy.
Policy Description (Optional)—Provide a policy
description.
Policy Status—Select
Preview or Enforce.
Preview—Enables you to preview, test, and
modify your policy before enforcing it on your applications.
Enforce—When you're satisfied with how
the policy functions in Preview mode, set
it to Enforce.
Add Association—Add association type from the
drop-down.
Tenants—Apply this policy to the whole
tenant (all applications defined in Private App Security)
Application Groups—Apply this policy to
one or more application groups.
Applications—Apply this policy to one or
more applications defined in Private App Security.
FQDNs—Apply this policy to one or more
FQDNs.
Priority—Priority of the policy (with 1 being the
highest priority).
Trigger Response—Define the action handling the
request.
Allow—The system enables requests that
match the expression and does not evaluate any other custom
policies. If matched, the requests are still checked against the
OWASP policies.
Block—Requests matching the expression
are blocked.
Continue—The requests matching the
expression are allowed, but the rest of the custom policies are
evaluated. This action is useful when it's necessary to edit
certain request headers; however, the requests still need to be
evaluated against the other policies.
Add Header
Expression—Define the matching criteria for the
requests.
Enforce key name—When defining rate limits, the
name of the key on which to enforce the rate limit.
Enforce on key—Select the enforcement key on
which you want to enforce the rate limit.
Interval—Select the rate limit time interval, in
seconds.
Limit—Define the maximum number of requests
enabled within the specified interval.
Response Body—Response to return when the rule is
blocked.
Response Code (optional)
Save your changes.
Configure an OWASP Policy
Open Web App Security Project (OWASP) policies offer protection against the Top 10
OWASP risks and common web application vulnerabilities, including issues such as
injection attacks, broken authentication, and sensitive data exposure.
Go to ConfigurationApplication ServicesApplication SecurityAll Policies and select Add Policy.
Select OWASP, and complete the following information.
Name—Provide a unique name for the policy.
Policy Description (Optional)—Provide a policy
description.
Policy Status—Select
Preview or Enforce.
Preview—Enables you to preview, test, and
modify your policy before enforcing it on your applications.
Enforce—When you're satisfied with how
the policy functions in Preview mode, set
it to Enforce.
Association Type—Add associations for the application.
Application Groups—Associate all applications in
a selected application group.
Applications—Select individual applications to
associate.
FQDNs—Select individual FQDNs to associate.
Add Association—Add association objects for the Private
App Security rule.
Priority—Priority of the policy (1 is the highest
priority)
WAF Rule Configuration—WAF rules consist of commonly used
open-source OWASP Top 10 protection rules. From the Rule Set
Name drop-down, select a preconfigured rule set.