Understanding Policy Groups

introduction policy groups are at the core of the nile trust service they define how users, devices, and applications are logically segmented for access control by classifying endpoints based on identity, device type, or context, administrators can apply policies that align with the enterprise’s security posture without relying on traditional vlans or static segmentation policy groups a policy group represents a collection of endpoints that share common access requirements each endpoint belongs to exactly one policy group, ensuring that its access policies are clear and deterministic the trust engine automatically evaluates each user or device during onboarding and assigns it to the most appropriate group based on predefined classification rules group types user groups – endpoints tied to an authenticated user commonly used for employees, guests, contractors, students, and faculty device groups – endpoints such as printers, cameras, or iot devices not associated with user identities application groups – destination endpoints that represent private or public applications understanding user groups user groups identify user endpoints via some common match criteria as listed above when a user is on boarded onto the network using a device such as a laptop, phone, or tablet, the device associated with the user belongs to the user group, and is not associated with any of the device groups that might be defined for example, if a user group is defined based on idp group and the user is using a windows 10 device, the user’s device will belong to the user group and not the windows 10 device group when defining a user group, multiple values can be selected as match criteria for the different categories for example, an employee user group can be created by selecting all the relevant scim values learned from the idp sales, marketing, hr, etc it is not necessary to create a user group for each idp group value, if the members across these idp groups will be subject to common access policy, such as allowing all employees access to the printer device group nile also handles user devices that may be shared amongst different users when 2 users share the same resource, such as a pc or tablet, the device will be associated with whichever user identity is used during authentication, ensuring that the right user based access policies are applied to the device understanding device groups device groups are used to identify related devices that are not participating in a user group when a device connects to the zero trust fabric, it is first evaluated against user group definitions to see if there is a match if so, the device is associated with that user group if a device does not match any user group, then it is evaluated against the device policy group definitions for example, if a user group “employees” is defined based on a network segment such as the “employee” segment, any device that connects to that segment will be categorized in the employees user policy group multiple methods for defining device groups are supported,including identity based classification (using device fingerprinting) as well as administrative classification techniques like mac/oui or network segment device fingerprinting as one of the device policy group criteria, fingerprinting can be selected the device fingerprint provides the identity for a device and is based on the same fingerprinting that is used during device on boarding via mab the device fingerprint supports 3 levels of identity category e g , cameras, printers manufacturer e g , dell, hp device model e g , acme printer model abc when defining a device policy group, one of different levels of fingerprint hierarchy can be selected fingerprinting can range from broad categories such as printers down to specific manufacturer and model types multiple fingerprints can be combined into a single device group definition for operational reasons, it is recommended to group device types together into groups that have common security posture and administration requirements continuous device validation in support of the quarantine functionality described below, and continuous device validation can be optionally defined as part of the device policy group definition device validation uses active probing to iot/ot devices on a periodic basis to ensure that a device’s login credentials are valid and is used as a means to validate corporate ownership of the asset this helps prevent off the shelf iot rogue devices from being introduced into an enterprise environment device validation checking can be performed regularly with the following characteristics active probing using either snmpv3, http/https, or ssh configurable revalidation periodicity every 30min, 1hr, or 8hrs traffic associated with active probing is not considered east/west traffic and is not subject to the policy engine, as the device probing is performed directly by the zero trust fabric only one device validation rule can be defined per device policy group understanding application groups application groups are used to identify related application endpoints, whether public or private multiple methods for defining application groups are supported, and when combined with actions, facilitates granular access policies to any application employed by the enterprise applications most often refer to destinations external to the zero trust fabric (e g , saas applications, internet, dc hosted private applications), but in the event of a locally hosted application within the zero trust fabric, this will be treated as a “local” destination from a routing perspective application groups can be designated either as source or destination within a policy for user or device to application access control, an application group is used as a destination, but for application to device access control (e g , some legacy ot devices may have an external application that requests access to the ot system), the application group can be the source note any application traffic forwarded to the zero trust fabric from an upstream system by default is denied unless a policy exists to allow north to south traffic if the intent is to permit an inbound flow, a policy for that traffic must exist default application groups default application groups are auto created by nile and include intranet this group contains the customer defined enterprise rfc 1918 address space this represents the combination of internal zero trust fabric subnets, private applications/servers/workloads across the enterprise, and any internal subnets that are not associated with nile sites by default all rfc 1019 addresses are included customers should modify this definition accordingly internet this is defined as any address that is non rfc 1918 and represents general public internet and saas destinations policy group behavior policy group classification after a user or device obtains an ip address via the network on boarding process, the endpoint goes through a classification process in order to associate it to a suitable policy group endpoint classification into policy groups follows a strict ordering user policy groups are evaluated first if an endpoint does not match against any of the user policy groups, then device policy groups are evaluated next within each policy group type, policy groups are evaluated based on order of the policy group definitions, from top to bottom admins can order the policy groups by dragging and dropping the relative position of each group it is important to note that more specific policy groups should be placed ahead of more generalized policy groups this ensures that proper classification is achieved for example, if scim based user groups are being created, and it is desirable to distinguish between general employee group classification versus a more specific scim group such as sales or marketing, then it is important to create and sequence all the corporate department based scim groups ahead of the general employee group, as matching is done based on ordering the classification behavior matches users and devices to exactly one policy group this means in the example above, even though a sales employee could match to both sales and general employee policy group, the classification engine will only associate this specific sales employee to the sales policy group, based on group ordering exact matching to a singular group also implies that a complete set of access policies should be defined for each policy group endpoints do not match to multiple groups and each group stands independent of others policy group reclassification (recalibration) on occasion, it may be necessary to recalibrate an endpoint and match it to a different policy group recalibration is a continuous process as policy groups are created, deleted, or edited, endpoints are continuously reevaluated against the latest policy group definitions, including those clients in quarantine and unclassified groups nile’s trust engine performs recalibration of all endpoints in the tenant upon any such changes to the policy groups, including any changes in match criteria values for existing policy groups upon addition/deletion of a user or device group any change made to policy group ordering this ensures that unclassified and assigned endpoints are always consistent with the current policy group definitions recalibration can also occur when other types changes are made examples include unclassifying any manually classified endpoints will trigger the endpoint to be recalibrated an endpoint that disconnects and reconnects will be recalibrated modifying policy groups policy groups can be created with a specific classification type, but once created, it is important to note that the classification type cannot be changed policy groups and their category are create only constructs once created, admins can change specific aspects of the policy group, including updates to metadata changes in terms of match criteria values changes to the device validation / posture check functionality if a different match type or categorization is desired for a set of endpoints, then it is necessary to create a new policy group with the new classification category (e g , scim instead of segment), and to place it higher in the ordered list of policy groups when appropriate, the older policy group can be removed modifying device validation checks within a policy group when enabling device validation checking within a pre existing policy group, the changes will not immediately apply to pre existing endpoints the behavior for existing endpoints is as follows when device validation checking is enabled in an existing policy group, existing endpoints will be validated upon the next change in ip address, expiration of authentication credentials, or in the event of a disconnect for wired devices, authentication credentials expire after 24 hours, so device validation checking will be added to existing wired devices within that time period for wireless devices, device validation will occur during roaming when a reconnect event occurs or when a forced reauthentication event is triggered when disabling periodic device validation checking, endpoints that are currently quarantined will be recalibrated for potential classification into the updated policy group