Xprotect groups

In Xprotect, you can group the hosts managed from an Xprotect instance and the users who log into the hosts and use the applications and processes on the hosts. Xprotect groups can greatly simplify the security management and monitoring operations you perform from the Xprotect UI. The Two types of groups in Xprotect are Host groups and User groups.

Typically, Xprotect groups are created by the Line of Business (LoB), geography, business unit/department, expected threat levels, or internal security policies and regulations. The preferred rationale to create groups may differ by your Policy control requirements and/or the structure of your business/organization.

Host groups

Host groups are logical groupings of the hosts managed from an instance. Grouping hosts by the desired rationale is usually the first step after installing Xprotect agents on the hosts. Grouping hosts allows you to push custom Xprotect Host policies to the hosts and later push User policies if needed.

Here are some of the guidelines around which Host groups are designed in Xprotect.

• OS-agnostic - a Host group can contain hosts from all Three supported OS families.  

• One-to-one association with host - a host cannot be associated with more than One Host group.  

• One-to-one association with an OS-based Host policy - only One OS-based Host policy (per OS) can be assigned to a Host group. When creating a Host group, the Three Default Xprotect policies (One each for an OS family) are assigned to the Host group. You can protect the hosts using the Default policies until you create and push custom Host policies and User policies.

• Default Host group - Xprotect instances come with a default Host group, default-group. All newly added hosts (to the instance) are automatically added to the default Host group after successfully registering with the instance. You cannot delete the default Host group from the instance.

• Automatic policy updates when hosts are added or moved across Host groups - Xprotect pushes the assigned policies to the hosts when you start adding hosts to the Host groups. If you move hosts across Host groups, Xprotect pushes the new policies (assigned/pushed to the target Host group) to the newly added hosts. 

• Optional availability to be associated with User groups - you can optionally enable a Host group to be associated with User groups. Enabling the availability to associate with User groups helps you push User policies to the hosts. If disabled, the Host group is not applicable to use User policies. 

User groups

User groups are logical groupings of the users fetched from the Active Directory (AD) integrated with the instance. Integrating an AD with instance and creating User groups help you enforce Xprotect User policies (identity-based policies) to the users in the groups.

Here are some of the guidelines around which User groups are designed in Xprotect.

• Linked to AD groups or AD departments - a User group is a group of hosts belonging to either One or more AD groups or One or more AD departments. For example, a User group Tech Support with users from Two AD groups, L1 Support, and L2 Support.

• Linked to Host groups - a User group can be associated with One or more Xprotect Host groups. For example, the User group Tech Support is associated with Two Host groups Office1-Floor1 and Office2-Floor2.

• Many-to-one association with Host group - multiple User groups can be associated with a common Host group. For example, Two User groups, Tech Support and Outbound sales, can be associated with the Host group Office1-Floor1. This means, Two users, One from Tech Support and another from Outbound Sales, can use the same host to get identity-differentiated access to applications and processes on the host.

• One-to-one association with an OS-based User policy - only One OS-based User policy (per OS) can be assigned to a Host group.

• User policy and Host policy coexist - both Host policy and User policy can be applied to a host. If the policies contain rules for the same process, application, or file, the most restrictive action is taken. For example, if the Host policy allows notepad.exe and the User policy is set to kill notepad.exe, an applicable user cannot use the notepad application.

• Policy settings inherited from Host policy - User groups use Xprotect User policies. Xprotect User policies are not designed to use Policy settings. So, when both Host policy and User policy are applied to a host, the User policy inherits the Policy settings from the Host policy.

Next steps

• Create Host groups to group hosts based on a preferred rationale.

• Add the hosts in the instance to the relevant Host groups.

• Create User groups to group users fetched from an AD based on a preferred rationale.