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:
|
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 Behavior | Policy Recommendations | Example |
|---|
|
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.
|
- Create a tenant-level policy recommendation to explicitly
Allow the activities on certain
tenants.
- 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.
- 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. |
