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.

Define Private App Security Policies

1. Log in to Strata Cloud Manager.
2. 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

1. 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.
2. 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.
3. 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.
   • Policy Type—Custom, Bypass, or OWASP.
   • Action—Allow, Block.
   • Policy Priority—Priority of the policy.
   • Association—Tenants, application groups, applications, s.
   • 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.

4. 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.
5. 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.
6. Affected applications—Information about the applications affected by the policy.
7. 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

1. Go to ConfigurationApplication ServicesApplication SecurityAll Policies and select Add Policy.
2. Select Bypass, and complete the following information.
   1. Name—Provide a unique name for the policy.
   2. Policy Description (Optional)—Provide a policy description.
   3. 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.
   4. 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.
   5. Priority—Priority of the policy. This priority is relevant only within the Bypass policies priority pool.
   6. Trigger Response—Set requests that match policy criteria to Bypass or Not Bypass.
   7. 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.
   8. 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.
   9. Duration—How long the rule should be active in number of minutes.
   10. Save your changes.

Configure a Custom Policy

1. Go to ConfigurationApplication ServicesApplication SecurityAll Policies and select Add Policy.
2. Select Custom, and complete the following information.
   1. 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.
   2. Name—Provide a unique name for the policy.
   3. Policy Description (Optional)—Provide a policy description.
   4. 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.
   5. 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.
   6. Priority—Priority of the policy (with 1 being the highest priority).
   7. 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.
   8. Add Header
   9. Expression—Define the matching criteria for the requests.
   10. Enforce key name—When defining rate limits, the name of the key on which to enforce the rate limit.
   11. Enforce on key—Select the enforcement key on which you want to enforce the rate limit.
   12. Interval—Select the rate limit time interval, in seconds.
   13. Limit—Define the maximum number of requests enabled within the specified interval.
   14. Response Body—Response to return when the rule is blocked.
   15. Response Code (optional)
   16. Save your changes.

Configure an OWASP Policy

1. Go to ConfigurationApplication ServicesApplication SecurityAll Policies and select Add Policy.
2. Select OWASP, and complete the following information.
   1. Name—Provide a unique name for the policy.
   2. Policy Description (Optional)—Provide a policy description.
   3. 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.
3. Association Type—Add associations for the application.
   • Application Groups—Associate all applications in a selected application group.
   • Applications—Select individual applications to associate.
4. Add Association—Add association objects for the Private App Security rule.
5. Priority—Priority of the policy (1 is the highest priority). The policy with the highest priority evaluates WAF traffic, with other policies subsequently evaluating traffic according to their priority.
   Leave "buffer room" between priority levels by using values such as 100, 200, and 300. This ensures you can insert new policies with, for example, priorities of 110 or 125 later without having to adjust your established rankings.
6. Paranoia Level—Controls the aggressiveness of OWASP Core Rule Set (CRS) rule detection for the individual OWASP policy. A higher Paranoia level means that more rules are being evaluated, which often means a better detection but also a higher risk of false positives.
   • Basic (Default)—Only a very few essential rules match the traffic.
   • Elevated (Recommended)—Standard protection. We recommended this level be used.
   • High—Comprehensive coverage, with additional rules matching the traffic.
   • Paranoid—Maximum security blocks bad or suspicious traffic, providing users with the highest efficacy results.
7. Anomaly Score Threshold—Select Low, Medium, or High. The lower the threshold score, the higher the efficacy and sensitivity of the WAF policy. The higher the threshold, the fewer false positives.

8. Content Parser Settings—Manages potential false positives based on your application's specific needs. For example, if you expect the request BODY to contain code, disable WAF BODY Inspection while maintaining protection for headers, cookies, and other request components.
   By default, all settings are enabled.
   • BODY Inspection—Inspects the body of the request, not just the request header. By default, this setting is on, along with both JSON Inspection and XML Inspection settings.
     • If you toggle BODY Inspection off, both JSON Inspection and XML Inspection settings are automatically toggled off.
     • When BODY Inspection is toggled on, you can choose to enable either JSON Inspection or XML Inspection.
   • JSON Inspection—Inspects JSON payloads in the request body.
   • XML Inspection—Inspects XML in the request body.

9. Ignore Settings—Select Add to configure the following pattern types, which will apply to the WAF rule set categories you select.
   Add a regular expression (regex) pattern for each pattern type. You can add multiple pattern types, and you can configure up to 50 of each pattern type.
   • Request Cookie
   • Request Header
   • Query Argument
   WAF Rule Set Categories

   • Fine-tune your policy by selecting WAF rule set categories. You can Select All or explicitly choose individual categories.

10. Exceptions—Add Exception Patterns to choose attributes for the traffic request.
    • You can configure an exception pattern for a specific target field in a request, such as ARGS_POST.
    • Supports both literal and regex pattern matching.
    • You can configure a maximum of 1500 exception patterns for the entire Exception pattern settings.
    • Supports a maximum of 256 characters length for an exception pattern.
    1. Give the Exception a literal or regex name.
    2. Select the Category(ies) you want to apply to this exception.