SaaS Security Inline Administration
  • SaaS Security Inline Administration
  • SaaS Security Documentation
  • All Documentation
>
SaaS Policy Rule Recommendations
Focus
Download PDF
Focus
  1. Home
  2. SaaS Security
  3. Manage Policy for Unsanctioned SaaS Apps
  4. SaaS Policy Rule Recommendations
Download PDF
SaaS Security

SaaS Policy Rule Recommendations

Table of Contents

SaaS Policy Rule Recommendations

Learn about SaaS policy rule recommendations on SaaS Security Inline.
Where Can I Use This?What Do I Need?
  • NGFW (Managed by Panorama or Strata Cloud Manager)
  • SaaS Security Inline license
  • NGFW license
Or any of the following licenses that include the SaaS Security Inline license:
  • CASB-X
  • CASB-PA
The rapid proliferation of SaaS apps makes it difficult to assign all of them specific App-IDs, gain visibility into those apps, and control them. Security policy rules that allow SSL, web-browsing, or “any” app might allow unsanctioned SaaS apps that can introduce security risks to your network. To gain visibility into those apps and control them, SaaS Security administrators can recommend policy rules for specific SaaS apps to administrators who have the authority to import and commit (push) them to Security policy.
To import SaaS policy rule recommendations on the NGFW, a SaaS Security Inline license is required.
Security policy rules detect and take action on specific app traffic on your network. SaaS policy rule recommendations are based on a combination of apps, users and groups, categories, activities, device posture, and data profiles. For example, you might create a SaaS policy rule recommendation that blocks all HR and Finance employees from uploading assets to risky file sharing apps such as 4Shared and WeTransfer.
After you create a policy recommendation and set the rule action, you then submit the rule for review. The administrator with the authority to commit the rule evaluates the recommended rule and decides whether to implement it. If that administrator chooses to implement the rule, the administrator imports it and selects where to place the policy rule in the rulebase, creating all the required HIP profiles, tags, and Application Groups automatically.
The administrator with the authority to commit the rules is the same administrator who maintains the rulebase. If you update a policy rule recommendation, that recommendation needs to be reimported. If you delete a SaaS policy rule recommendation, the recommendation needs to be deleted from the Security policy rulebase.
You can define policy recommendations at the app level or, for some select apps, at the app tenant level.
  • Application-level policy recommendations, if committed on the NGFW, will affect all instances of the app. App-level policy recommendations support only the Block action. The Block action prevents network traffic for specified user activity in the app, such as upload or download activity.
  • Tenant-level policy recommendations, if committed on the NGFW, will affect only the app tenants that you identify. For example, you might create a SaaS policy rule recommendation to Block downloads from Box for one tenant only. You can select up to 30 individual tenants per policy recommendation.
    Tenant-level detection is supported for some apps, which all allow you to define policy recommendations to Block user activities on selected tenants. A subset of these apps support both Block and Allow actions. The Allow action explicitly permits network traffic for specified user activity on the tenants. Because permitting network traffic for the tenants is already the default behavior, defining a policy recommendation to explicitly Allow user activities on tenants is unnecessary on its own. We designed the explicit Allow action for you to use in a policy recommendation only when you also define another policy recommendation to Block activities for the remaining tenants. Pairing Allow and Block policy recommendations in this way is a convenient way to block activities on most tenants while allowing the activities on a smaller set of tenants.
    When the Allow action is supported for an app, you can also identify the affected tenants of a policy recommendation as Any. The Any specification acts as a wildcard to match all current and future tenants. On the NGFW, when an imported policy specifies Any tenant, the policy will apply to all tenants unless an earlier policy in the NGFW's evaluation order specifies a different action for a tenant. In this way, you can define one policy recommendation to Allow the actions for selected tenants and another to Block the actions for Any other tenants.
    When you create separate tenant-level Allow and Block policy recommendations to achieve particular results, your desired results will depend on the order in which the policy rules are evaluated on the NGFW. On the NGFW, when traffic matches a policy rule, the defined action is triggered and all subsequent policy rules are disregarded. So, if a policy to Block user actions for Any tenants is placed before a policy to Allow user actions for particular tenants, the Allow policy will be disregarded. When the NGFW administrator imports your policy recommendations, make sure that they place the more specific policy before the more generic one. In this case, the more specific policy to Allow user actions for particular tenants must be placed before the generic policy to Block user actions for Any tenant.
To understand when to define app-level and tenant-level policy recommendations, review the following table of common scenarios.
Desired NGFW BehaviorPolicy RecommendationsExample
Block one or more types of user activities for an app for all tenants.
Create an app-level policy recommendation to Block the actions. Because this policy recommendation is at the app level, all app tenants will be affected.
You want to prevent access to Box on all tenants.
To do this, you create an app-level policy recommendation to Block all user activity for Box.
Block one or more types of user activities for some of an app's tenants, but allow the activities for all other tenants.
Create a tenant-level policy recommendation to Block the activities for the tenants. By default, the activities are still allowed for all other tenants.
You want to prevent access to Box for personal tenants, but allow access for corporate tenants.
To do this, you create a tenant-level policy recommendation to Block any user activity for the personal tenants. By default, the user activities are still allowed for the corporate tenants.
Block one or more types of user activities for most of an app's tenants, but allow the activities for some tenants.
  1. Create a tenant-level policy recommendation to explicitly Allow the activities on certain tenants.
  2. Create a tenant-level policy recommendation to Block the activities for the rest of the tenants. In the policy recommendation, specify that the NGFW should block the specified actions for Any tenant.
  3. On the NGFW, make sure that the more specific Allow policy is evaluated before the general Block Any policy.
You want to prevent access to Box for most of your organization, but allow access to box on a single tenant.
To do this, you create two tenant-level policy recommendations.
  • The first policy recommendation identifies the single tenant that will have access to Box, and specifies that any user activity is allowed.
  • The second policy recommendation specifies that the NGFW should Block any user activity for Any tenant.
After you enable the policy recommendations, you make sure that the NGFW administrator understands that the first policy must be evaluated on the NGFW before the second policy.

Technical Documentation

Company

Legal Notices

© 2025 Palo Alto Networks, Inc. All rights reserved.