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

To allow or restrict access to devices and apps, you define policy rules. Policy rules can be configured to allow or restrict access based on user, device, 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 that have been 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.

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

• Authentication

• Device Add

Authentication transactions include rules to authenticate to web apps or SSO providers integrated with Beyond Identity. Device Add transactions include rules related to end users’ ability to add additional devices. Rules can be written for a specific transaction type as well as across transaction types.

Until a rule allowing access is defined, access is denied. Any number of rules can be added. A single rule can consist of any number of transaction-based attributes related to the following:

• User

• Device

• 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 restricted based on the criteria defined in the rule. No further searching 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 for allowing 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 policy for a specific transaction type, you can set policy that applies for 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