SaaS Security
SaaS Policy Rule Recommendations
Table of Contents
Expand All
|
Collapse All
SaaS Security Docs
SaaS Policy Rule Recommendations
Learn about SaaS policy rule recommendations on SaaS Security Inline.
| Where Can I Use This? | What Do I Need? |
|---|---|
|
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.
|
| 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.
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. |