Policy Matching & Evaluation

Policy Matching & Evaluation

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:

  1. Collaborator

  2. Object

  3. 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.

Match logic

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

Match login with Owner

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.

Object

An object is specified by the following values:

  1. One of Applications, App Instance, or Categories

  2. Content

  3. 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.

Applications
App Instances
Categories

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).

  1. Alert

  2. Revoke specific domain(s)

  3. Revoke org-wide sharing

  4. Restrict access to specific domains & collaborators

  5. Restrict access to internal collaborators

  6. Restrict access to owner

  7. Delete

  8. Quarantine

  9. Change owner to user

  10. 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.

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.

Share this Doc

Policy Matching & Evaluation

Or copy link

In this topic ...