Overview

Beyond Identity's Policy engine is a powerful, rule-based decision engine that allows you to customize access decisions based on various attributes from various sources, such as user, device, event, and third-party integrations.

You define policy rules to allow or restrict access to devices and apps. Policy rules can be configured to allow or deny access based on user, group, device, installed applications, running processes, and event behavior.

The Policy engine ensures that users attempting a specific transaction, such as authenticating to web apps or adding a device, must meet the policy rule requirements defined to gain access. 

The policy engine can be leveraged for a variety of use cases. For example, a company may enforce a policy that requires a firewall turned on, management software installed, or a specific operating system installed on devices to authenticate and allow access.

Transaction types

The Policy engine supports creating rules for the following types of transactions:

• Authentication

• Add Device

• GPG Key Creation

Authentication transactions define rules to authenticate to web apps or SSO providers integrated with Beyond Identity.

Device Add transactions define rules related to end users’ ability to add the passkey to additional devices.

GPG Key Creation transactions define rules related to users' ability to create keys to sign code commits.

The rules can be set for a specific transaction type, or across transaction types to apply all transaction types with the same rule.

Rule types

The policy engine has three different kinds of rules.

• Monitor
• Allow
• Deny

The monitor type rule doesn't stop processing the rules. It enables the administrator to define a policy and observe how it works before enforcing it using allow or deny.

The allow type rule will stop processing the rules. It will allow the transaction to complete. Optionally, you can define a toast message displayed for the end user when the authentication is successful.

The deny type rule will stop processing the rules. It will deny the transaction. It is a good practice to write a descriptive message for the user why they were denied. For example, if the policy checks for disk encryption, indicating that the disk must be required would explain why the authentication was denied.

Rule operators

The policy rules have many different options for the operators, depending on which item is configured. Many of them are easy to follow, but the explicit IS and IS NOT operators can be slightly misleading in some cases.

For example, using Kandji MDM integration and making a policy rule that is intended to catch all the "happy days scenarios" to allow authentication, could look something like this:

• The device must be a Mac
• The firewall must be enabled
• The disk encryption must be enabled
• Kandji connection must be available (meaning that Beyond Identity can make the API call to Kandji's services)
• The device must be managed by Kandi

If the intention is to have a check for the computer being managed, and deny user's authentication when they are using non-managed computer, one could configure a rule where the check is:

• Kandji connection must be available (meaning that Beyond Identity can make the API call to Kandji's services)
• The device must be not managed by Kandi

If Kandji reports that the computer is not found, it cannot tell if it is managed or not.

Instead of changing the true/false option, changing the check to is to is not will flip the check and explicitly checks that the computer isn't managed.

Note! All of these combinations are different, and when looking from a programmatic perspective:

• Something == true (something is explicitly true)
• Something == false (something is explicitly false)
• Something != true (something is explicitly not true)
• Something != false (something is explicitly not false)

Using monitor rules to define a policy rule that works as intended is the best method to identify the desired behavior before implementing them for all users.

Rule evaluation

The policy rules are evaluated sequentially until a allow/deny rule is matched. The processing of rules stops once a matching rule has been hit. Even the monitor rules that follow a matched rule will be ignored.

Until a rule allowing access is defined, access is denied. Any number of rules can be added. The last rule is built-in default deny all rule. If none of the policy allow/deny rules are hit, the default will deny the transaction.

Planning rule sets

To define rules, the recommended way is to put all monitor-type rules before any allow or deny rules. This is how an administrator can ensure that all monitor rules are evaluated, giving the needed information.

To define an explicit allow rule, for example, allow authentication transaction for macOS with disk encrypted and firewall enabled. Followed by a rule that explicitly checks for authentication for macOS with an unencrypted disk and denies it with the message "Disk encryption required for macOS authentication." Second, deny rule would then check explicitly for the firewall is off and denies the authentication with the message "Firewall must be enabled for macOS authentication."

As a rule of thumb: Configuring a deny rule before the explicit allow rule is not recommended.

Setting up a break-glass rule in the policy rules would be a good idea for a specific group of admin users so they cannot lock themselves out from the system.

Defining the policies

A single policy rule can consist of any number of transaction-based attributes related to the following:

• User

• Device

• Device and Application Attributes

• Integration

• Authentication version

When a transaction is initiated, the policy engine evaluates each defined rule in numerical order. Once an exact rule is found, access is allowed or denied based on the criteria defined in the rule. No further processing through the remaining rules is necessary. If a match is not found after searching through all rules, the default 'deny rule' is matched, and access is denied.

For example, a rule has been defined as allowing access when authenticating from a macOS device with a firewall turned on. The Policy engine searches through the rules starting with Rule 1, and when it finds a match, it stops searching and allows access. In this example, a match is found in Rule 3. The Policy engine does not need to continue searching through the remainder of the rules.

Creating Rules

To create a rule:

1. Log in to the Admin console, and from the Home screen, select the Policy tab. The Policy page displays a list of current rules that have been configured.
   
2. Click + Add Rule. The Add Rule dialog is displayed.
   

The Add Rule dialog provides various attributes for setting policy related to:

• The type of transaction

• The user attempting to authenticate

• The platform on the device

• The type of integration

• The Beyond Identity Authentication version installed

Note: The user, device platform, and integration attributes can be defined with additional sub-attributes.

Keep the following points in mind when creating rules:

• Policy rules can be edited and deleted; however, the last remaining policy rule in a set cannot be deleted. It can only be edited.

• The default rule denying authentication and device add cannot be deleted.

• Only attributes and options applicable to the specific item you select are available. For example, Android attributes and options are not available when you are defining a rule for a Mac device.

The following sections provide examples for creating:

• Rules that apply to a specific transaction type

• Rules that apply to all transaction types

More details regarding CrowdStrike-specific policies.

Transaction-Specific Rules

The following section provides examples for writing:

• An authentication transaction rule

• A device transaction rule

Example 1: Creating an Authentication Transaction Rule

This example creates a rule to allow access to users that are part of the Admin Group and are authenticating from an Android device that is registered with Intune and running an Authenticator version greater than version 2.34.0.

1. After logging into the Admin console and opening the Add Rule dialog, select the attributes that are required for authentication for your organization. In this example, we are selecting the following attributes to allow authentication:

• The Transaction type is Authentication.

• The user is the Admin Group in the user group.

• The device platform is Android.

• The device integration type is registered with Intune.

• The Authentication version is greater than 2.34.0.

To select the attributes, click the +Add button associated with the desired attribute and select or type in a value as follows:

• For transaction, select Authentication from the drop-down menu.

• For user, select is in user group and Admin from the drop-down menus.

• For device platform, select Android from the drop-down menu.

• For integration, select Intune Registration is Registered from the drop-down menus.

• For authenticator version, type in 2.34.0.

2. Leave the default Allow setting.

3. Click Add when done. The rule is added to the Policy Rules list.

Note: For the rule to be preserved upon exiting the Admin Console, the rule must be published. See Publishing Rules below. Multiple rules can be defined before publishing them.

Example 2: Creating a Device Transaction Rule

This example creates a rule that allows a non-jailbroken iOS device that is connected using JAMF to add other devices.

To create a device transaction rule:

1. After logging into the Admin console and opening the Add Rule dialog, select the attributes that are required to allow users to add devices. In this example, we are selecting the following attributes:

• The Transaction type is Device.

• The user is any user.

• The device platform is iOS with Device Jailbreak set to Not Detected.

• The integration is JAMFConnection set to Available.

• The Authentication version is greater than or equal to 2.34.0.

To select the attributes, click the +Add button associated with the desired attribute and select or type in a value as follows:

a. For transaction, select Add Device from the drop-down menu.

b. For user, leave the default setting. (Defaults to any user)

c. For device platform:

i. Select iOS from the drop-down menu.

ii. Click + Add and select Device Jailbreak is and Not Detected from the drop-down menus.

d. For integration, select JAMF, Connection is, and Available from the drop-down menus.

e. For authenticator version:

i. Select is greater than or equal to from the drop-down menu.

ii. Type in 2.34.0.

2. Leave the default Allow setting.

3. Click Add when done. The rule is added to the Policy Rules list.

Note: For the rule to be preserved upon exiting the Admin Console, the rule must be published. See Publishing Rules below. Multiple rules can be defined before publishing them.

All Transaction Type Rules

In addition to setting a policy for a specific transaction type, you can set a policy that applies to all transaction types. The following provides an example that writes a policy that denies authentication for any transaction type that matches the criteria set in the policy.

Example: Creating a Rule to Deny Authentication

This example creates a rule that denies users from the QA Group attempting to authenticate or add a device that is installed with an Authenticator version less than 2.40.0.

1. After logging into the Admin console and opening the Add Rule dialog, select the attributes that deny authentication or the ability to add devices that match your requirements. In this example, we are selecting the following attributes::

• The Transaction type is Any. (Does not need to be specified. The default value of Any is implied.)

• The user is in the QA Group.

• The Authentication version is less than 2.40.0.

To select the attributes, click the +Add button associated with the desired attribute and select or type in a value as follows:

a. For transaction, select Add Device from the drop-down menu.

b. For user, select QA Group from the drop-down menu.

c. For authenticator version:

i: Select is less than from the drop-down menu.

ii: Type in 2.40.0.

2. For Then, select Deny from the drop-down menu.

3. Add an optional message in the Customized notification box that is displayed to inform the user why the authentication or device add function was denied. For example, Please update your Authenticator to version 2.40.0 or greater.”

4. Click Add when done. The rule is added to the Policy Rules list.

Note: For the rule to be preserved upon exiting the Admin Console, the rule must be published. See Publishing Rules below. Multiple rules can be defined before publishing them.

Publishing Rules

For a rule to be permanently saved, it must be published. Rules can be published individually or in groups. Once rules are published, they are saved when you exit the Admin Console.

To publish a rule, click Publish changes, located in the upper-right corner of the Edit Policy page.

The rules list is updated with the latest set of rules.

In addition to the current set of rules, you can view a list of all previously saved sets of rules, and restore one as the current set. See Viewing and Restoring Previous Policy Rules below.

Viewing and Restoring Previous Policy Rules

You can view a list of all previously published rules and also restore a specific set of rules. When a set of rules is restored, those rules become the current set and immediately take effect.

To view a list of all previously published rule sets:

1. Click the Last published link at the top page.
   
   A list of all previously created rules, as well as the current rule set, is displayed on the right of the page, along with the date they were last published.
   

2. Clicking on any of the previous rule sets will display those rules on the page. For example, clicking on the previous rule set directly beneath the current rule set will display the policy rules defined for that set.
   

To restore this rule set as the current set of rules:

1. Click I want to restore this version located in the upper-right corner of the page.
   

2. The set of rules is previewed on the Edit Policy page. Click Restore. 
   

3. A prompt is displayed asking if you want to publish this set of rules and update the policy. Click Yes, publish changes.
   

This set of policy rules is now in effect.

Attributes

The following table lists the attributes and options available when writing policy rules.

Type	Platform	Name	Options	Source
User	-	User Group	Dynamic	SCIM Groups API
User	-	Has Registered Device(s)	=, <, <=, >, >=	BI Cloud
Device	-	Platform	Android, iOS, MacOS, Windows, Linux	-
Device	All	IP Address
Device	Android	Device Has Authentication	Enabled, Disabled	Android KeyguardManager API
Device	Android	Authentication Method Enabled	Biometric, PIN or Password	Android BiometricManager API
Device	Android	Device Root Is	Detected, Not Detected	Querying files and packages that would indicate a root
Device	iOS	Device Has Authentication	Enabled, Disabled	Apple canEvaluatePolicy API
Device	iOS	Authentication Method Enabled	Biometric, PIN, Biometric and PIN	Apple canEvaluatePolicy API
Device	iOS	Device Jailbreak Is	Detected, Not Detected	Checks for a jailbreak.txt file and whether the device can access cydia or the shell
Device	MacOS	Version Is	String Input	Apple operatingSystemVersionString API
Device	MacOS	App Installed Contains	String Input	OSQuery
Device	MacOS	Antivirus Is	On / Off	Queries XProtect plist file
Device	MacOS	Installed Security Software Is	Crowdstrike, Tenable, Jamf, McAfee, Kaspersky	Queries files for specific apps
Device	MacOS	Process Running	String Input	OSQuery
Device	MacOS	File Exists	String Input	OSQuery
Device	MacOS	Plist Key Value Contains	Path, Key, Subkey, Number/String, Value	OSQuery
Device	MacOS	Firewall Is	On / Off	Queries firewall plist file
Device	MacOS	User FileVault Is	On / Off	Queries FDE status
Device	Windows	Antivirus Is	On / Off	Microsoft Windows Security Center API
Device	Windows	System Disks BitLocker Is	Enabled / Disabled	Microsoft BitLocker API
Device	Windows	Version Is	String Input	Microsoft Environment API
Device	Windows	Application Installed Contains	String Input	OSQuery
Device	Windows	Service Installed Contains	String Input	OSQuery
Device	Windows	Service Running Contains	String Input	OSQuery
Device	Windows	Process Running Contains	String Input	OSQuery
Device	Windows	Registry Key Exists	String Input	OSQuery
Device	Windows	Registry Key Value	2 String Input	OSQuery
Device	Windows	File Exists	String Input	OSQuery
Device	Windows	Firewall Is	On / Off	Microsoft Windows Security Center API
Device	Windows	Installed Security Software Is	CrowdStrike, Tenable, Jamf, McAfee, Kaspersky	Microsoft Windows Security Center API
Device	Windows	Domain Name Contains	String Input	Microsoft Net Workstation API
Version	-	If Authenticator Version Is	=, <, <=, >, >=	BI Authenticator
Integration	Intune	Intune	Registration, Connection	Microsoft Graph API
Integration	Intune	Registration	Is / Is Not	Microsoft Graph API
Integration	Intune	Registration Is / Is Not	Registered, Not Registered, Revoked, Key Conflict, Pending Approval, Certificate Reset, Not Registered Pending Enrollment, Unknown	Microsoft Graph API
Integration	Intune	Connection Is	Available, Not Available	Microsoft Graph API
Integration	JAMF	JAMF	Connection Is, Managed State Is	Jamf Pro API
Integration	JAMF	Connection Is	Available, Not Available	Jamf Pro API
Integration	JAMF	Managed State Is	Managed, Not Managed	Jamf Pro API
Integration	Workspace ONE	Workspace ONE	Connection Is, UEM Is	VMWare AirWatch API
Integration	Workspace ONE	Connection Is	Available, Not Available	VMWare AirWatch API
Integration	Workspace ONE	UEM Is	Enrolled, Not Enrolled	VMWare AirWatch API
Integration	CrowdStrike	CrowdStrike Falcon ZTA Score	=, <, <=, >, >=	Crowdstrike Host API
Integration	Kandi	Connection Is	Available, Not Available	Kandji API
Integration	Kandi	MDM Enabled	Is True Is Not True Is False Is Not False	Kandji API