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:
- 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 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:
-
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 |
Comments
0 comments
Please sign in to leave a comment.