Policy Matching & Evaluation - Netskope Technical Documentation

This section describes the matching logic of Next Generation API Data Protection policies. The description here assumes a familiarity with Classic API Data Protection policies and the Next Generation API Data Protection platform.

Policy Wizard

There is a new UI to create policies for Next Generation API Data Protection. The policy matching criteria currently supported are:

Collaborator
Object
Profile & Action (DLP & Threat Protection)

Policy Match Logic

A policy match is achieved through the conjunction (AND logic) of collaborator (owner, exposure), object, and DLP/malware criteria. The matching of each criterion is determined by aggregating the outcomes of matching its individual components. The logic is depicted below.

The owner criteria is presently only available for certain apps (Gmail & Outlook). It is logically combined (AND logic) with the exposure criteria.

Collaborator

Owner

The owner is the outcome of combining the following values using the OR logic:

The owner match is determined by the following formula:

match 
(
User OR User Geo OR User Group OR User Profile OR Domain OR Domain Profile
)

Owner Types

User: This matches entities whose owner is at least one of the specified users.
User Group: This matches entities whose owner is in at least one of the specified AD groups.
User Profile: This matches entities whose owner is in at least one of the specified profiles.
Domain, Domain Profile: This matches entities whose owner’s email domain is in at least one of the specified domains or domain profiles.

Exposure

Exposure is the result of combining the following values using the logical OR operation:

The exposure match is determined by the following formula:

match 
(
Internal/External OR User Geo OR User Group OR User Profile OR Domain OR Domain Profile
)
OR
satisfy 
(
number of internal collaborators
)

Exposure Types

Internal/External: This matches entities with the specified exposure.
User Geo: This matches entities flagged as originating from a particular region (Microsoft 365 only).
User Group: This matches entities that are accessible by at least one member in the specified AD group.
User Profile: This matches entities that are accessible by at least one user listed on the specified profile.
Domain, Domain Profile: This matches entities that are accessible by at least one domain in the domain list or profile. The domains with access are calculated from the emails of the users with access.

Exclusion

Criteria that excludes an entity take precedence over criteria that match an entity and prevent a policy hit when fulfilled. Exclusion criteria are combined using the logical OR operation. An entity will be excluded if any of the exclusion criteria are met.

If an entity matches both; match and exclusion criteria, the entity is matched and not excluded.

Exposure

At least one matching user in User Profiles or at least one matching member in User Groups will result in an exclusion. This is the same as how matching criteria work as noted in previous sections.

However, Internal/External, User Geo, Domain, and Domain Profiles exclusions work differently. They require matching all exposure values for the exclusion to occur. In other words, these exposures result in exclusion only for the specified values and no other.

Example

In this example, the exclusion criteria is set and is evaluated as,

match("600 user profile" AND NOT ("test1-1" OR "test2"))
OR 
match("Finance" AND NOT ("BreslinTest" OR "Outlook"))

The exclusion criteria come into play only when the match criteria of the corresponding filter do not match, as indicated by the “AND NOT” condition mentioned earlier. If an entity is accessible to users included in both the “600 user profile” and the “test1-1” profile, it will not be excluded based on the user profile criteria.

If the exclusion criteria is not matched, then the rest of the criteria is matched as usual,

match(test1-1 OR test2 OR Internal Domains OR BreslinTest OR Outlook)

It is important to note that to match the “600 user profile,” at least one user with access to the entity must be included in the profile. However, to match the “Finance” domain profile, the domains from the emails of all users with access to the entity must be included in the profile.

Domain Match Logic in Next Generation vs Classic

The domain matching logic varies between Next Generation and Classic API Data Protection. Unlike Next Generation, Classic API Data Protection implicitly ignores internal domains when conducting exclusion checks. To mimic Classic’s behavior, the policy needs to exclude the predefined profile “All Internal Domains” alongside the desired domains. This ensures that the tenant’s Internal Domains setting is included in the check as if it were a domain profile.

If a file is shared with any domain that is not on the exclusion list, the file will still be scanned. Make sure to include internal domains in the exclusion list as well.

For a file to be excluded from scanning, all shared domains must be part of the exclusion list. If the file is shared with even one domain outside the exclusion list, it will be scanned.

Object

An object is specified by the following values:

One of Applications, App Instance, or Categories
Content
File Types

Within each type, multiple values can be chosen and are combined using the logical OR operation. The match result from each type is then combined using the logical AND operation. Refer to the match logic screenshot.

Applications

You can select All Applications:

All Applications: Apply the policy to all SaaS apps and instances.
Applications: Apply the policy to the specific SaaS app(s) you select. On selecting this option, all app instances of a specific SaaS app gets included for policy scanning.
App Instances: Apply this policy to the respective SaaS app instance(s) you select.
Categories: Apply the policy based on the type of SaaS app solution. If you select a category, all the corresponding SaaS app and instances are included for policy scanning. Examples: Collaboration, Cloud Storage, Webmail, HR, etc.

Content

Content is intended for defining a specific resource or entity within the SaaS application. For instance, in the case of OneDrive, content refers to a file or folder item ID. When a folder ID is specified and a file is under evaluation, the matching logic will traverse the file’s ancestor chain in an attempt to match the folder ID.

Since these IDs are specific to an app+instance, a value must be set in the Specify App Instance drop-down.

Then, under Scan Content, select Specific resources.

The resource IDs can be obtained from the API-enabled Protection > CASB API (NEXT GEN) > Inventory page, then click Content > File drop-down. For example, the value of the File ID is the the resource ID of a file:

In case of a folder, the resource ID can be obtained by searching for the folder by navigating to the API-enabled Protection > CASB API (NEXT GEN) > Inventory page, then click the Content Collection > Folder drop-down. The resource ID for a folder is the value of Folder ID as indicated in the screenshot below.

Similarly, you can get the resource ID for:

Comment: Navigate to Content > Comment, click a comment name, under details, look for Comment ID.
Email: Navigate to Content > Email, click a sender email, under details, look for Email ID.
Message: Navigate to Content > Message, click a sender email, under details, look for Sender ID, Message ID, or Channel ID.
Page: Navigate to Content > Page, click a page name, under details, look for Page ID.

File Type

Apply the policy for a specific file type category. A few file type category examples are audio, image, word processor, presentation, video, etc. The file type criterion will only be matched against files. Other non-file resources will ignore this criteria.

Profile & Action (DLP & Threat Protection)

Policy Action

Currently supported actions are mentioned below. If many policies match, the policy actions are executed in the following priority order (starting with the highest priority 1).

Threat quarantine
Alert
Disable print & download
Restrict access to specific domains
Revoke specific domains
Configure public access to expire
Restrict sharing to view
Revoke public sharing
SharePoint/OneDrive: revoke EEEU sharing
Revoke org-wide sharing
Legal hold
Apply sensitivity label
Restrict access to specific domains and collaborators
Restrict access to specific users
Revoke specific users
Restrict access to internal collaborators
Restrict access to owner’s domain
Restrict access to owner
Delete
DLP quarantine
Revoke users added at the file level
Change owner to user
Change owner to admin

Threat Protection Action

The Threat Scan Service (TSS) is enabled by selecting the Threat Protection profile. Only the predefined “Default Malware Scan” profile is supported at this time. You can configure a severity-based remediation action – low, medium, and high. For each severity, you can define an action. A threat protection policy defines the severity based action executed in case of a policy match and a password to protect the quarantined content.

Next Generation API Data Protection follows the same long-standing behavior as Classic API Data Protection when handling malicious files. If a SaaS application detects and blocks malware, Netskope does not execute any configured remediation actions. Instead, the threat protection engine generates an alert to notify the customer, without applying policy-based remediation actions.

Frequently Asked Questions

Where do I set the application or instance in a Next Generation policy?

You do not have to. Unlike Classic, Next Generation policies are applicable to all instances by default. This allows you to have fewer policies to manage. You do have the choice to restrict policies to a particular app category, a particular app and a particular instance. This is done by configuring the Object criteria picker explained more here.

I have one Classic policy per DLP profile. Is there a better way in Next Generation?

Yes. In a Next Generation policy, you can specify several DLP profiles so you don’t have to create a policy for each profile that you’re interested in. This can help reduce the number of policies you need to manage. Any one matching DLP profile will result in the policy to match (assuming other policy criteria match as well).

Is the Settings > Threat Protection > API-enabled Protection page supported?

This page is not supported and applies to Classic API Data Protection only. For Next Generation API Data Protection, malware scanning happens using the Threat Protection profile selected in Next Generation API Data Protection policies.

Is the Endpoint Detection and Response (EDR) feature supported?

The EDR feature is not supported. It is deprecated in favor of the Cloud Exchange (CE) platform.