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:
- 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.
- 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:
-
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. - 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:
-
Click I want to restore this version located in the upper-right corner of the page.
-
The set of rules is previewed on the Edit Policy page. Click Restore.
- 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 |
Comments
0 comments
Please sign in to leave a comment.