Default System Groups

7 min

Introduction

Nile automatically creates several predefined groups to simplify configuration:

Local: All endpoints inside the Nile Service Block.

External: All endpoints outside the Service Block.

Intranet: The enterprise’s private address space defined by RFC 1918.

Internet: Public destinations outside the Intranet.

Unclassified: Endpoints that do not match any defined group.

Quarantine: Devices that fail validation or posture checks.

These groups are recognized across the Trust Service and can be used as sources or destinations in policy definitions.

Local & External System Groups

In addition to Internet and Intranet, Nile defines other default system groups that are used in default system policies. These groups are not user-selectable when defining new policies.

Local: the Local group is a collective reference to any endpoint within the local Zero Trust Fabric, and is not specific to endpoint type. It can include users, devices, or apps that are local to the Zero Trust Fabric.

External: the External group is the inverse of Local, and refers to any endpoint that is outside of the Local Zero Trust Fabric.

By default, the implicit “Deny all” posture of the Zero Trust Fabric implies that no endpoint can talk to any other endpoint without an explicit policy in place. This implicit “Deny all” policy does not appear in the UI, as it is an immutable property of the Zero Trust Fabric. Additionally, there is a default policy that is visible that explicitly denis any inbound communication from outside (i.e., External) of the Zero Trust Fabric. Any communication that is to be allowed inbound to a policy group within the Zero Trust Fabric must be explicitly defined in a policy.

Unclassified Groups

Nile pre-creates two default policy groups that are used for specific purposes:

Unclassified User & Device Groups: any user or device that does not match with any of the customer-defined policy groups will be categorized as “Unclassified” and will be placed into an Unclassified Users group or Unclassified Devices group. This is a category of users/devices for which no matching policy group can be found, and includes devices that are unknown (i.e., may be lacking a fingerprint and which do not match with any other defined device groups).

The unclassified users and devices will appear together as a single list in the NIle Control Center. Administrators with access to this group can manually classify these endpoints into existing groups, or they can create new groups on the fly and assign endpoints to a new group. Similarly, administrators can unassign a user or device from their current group and return them to the Unclassified group.

By default, and in alignment with zero trust principles, members of the Unclassified User and Device groups will not be permitted to access any destinations other than necessary network infrastructure services. If it is desired to allow Unclassified Users or Deivces to access the Internet, an explicit policy needs to be added to the Global Policy Set to permit this.

Important Note: whether a user’s device ends up as an Unclassified Device or Unclassified User will depend on whether there is any user context available associated with that device. If there are no user attributes available associated to the device (eg, if segment-based User groups were used instead of IdP Group), then the user’s device will appear as an Unclassified Device if there are no matching user or device groups.

Manual Device Assignment & Unassignment

In addition to manual assignment of endpoints to target policy groups, the Trust Engine also supports unassignment from current policy groups. This enables customers to override the previous endpoint classification (whether automated by the Trust Engine or manually assigned) and returns the endpoint to the Unclassified group, where it then can be reassigned. Dynamic reassignment will occur at the next recalibration event, whereas manual reassignment can be done at any time.

Quarantine Group

Nile pre-creates the Quarantine policy group for supporting quarantining of devices that fail continuous device validation. This form of quarantine provides stronger security posture compared to traditiona VLAN-based qaurantine, and additionally does not require any network moves or re-IP of the device.

The Quarantine Group and continuous device validation are supported for device policy groups that use either OUI/MAC or fingerprint based classification, and is well sutied for IoT/OT. When continuous device validation is enabled for a device group, periodic creentials-based checks on devices are made, using either:

HTTP/HTTPS

SNMPv3

Custom access policies for the Quarantine group can be configured. By default, devices in the Quarantine group have a “deny access to internet” policy. If customers intend to leverage quarantining functionality it is important to modify the policy that can permit quarantined devices to access specific remediation services or applications.

Additionally, by default, no endpoint can access devices in the Quarantine group. Permission to allow IT admins to access devices in Quarantine must be defined as an explicit policy and added to the Global Policy Set.

Moving Devices out of the Quarantine Group

Once a quarantined device has been properly remediated, there are 4 ways for a device to be moved out of Quarantine group

For device groups with periodic posture checking, those devices that are in the Quarantine group will be periodically checked.

Manual disconnect/reconnect the device from the Clients details page will trigger revalidation.

If the device is a wired device, then there is a forced reauthentication that occurs daily. During the reauthentication event, the quarantined device will be checked and if it succeeds, it will be moved out of the Quarantine group.

If the IP address is changed for a quarantined device, as a result of moving it to a different AP or physical port, then this will trigger revalidation of the device.

Unclassified & Quarantine Group Behavior

The Unclassified and Quarantine groups are operational states and are transient in nature. It is recommended that admins pay attention to endpoints that appear in these groups as they warrant some sort of remediation before they can be reclassified to their intended policy group. A summary of transitions and actions for devices and users in these groups is summarized below:

Current Group	Recalibrated Group	Supported	Support / Notes
Quarantine	Intended Policy Group	Yes	quarantined devices that are provisioned/remediated such that they pass device validation can be recalibrated to their intended policy group
Quarantine	Unclassified	No	a device in quarantine means it has already matched to an intended group, but the device validation failed. Once the device in quarantine is remediated, it will transition to its intended policy group.
Unclassified	Quarantine	Yes	a device that was Unclassified may be manually assigned to an existing (or new) policy group. If that policy group has a device validation specification, and the device fails, it can end up in quarantine.
Unclassified	Intended Policy Group	Yes	a user or device in Unclassified group can be manually assigned to an existing (or newly defined) policy group.
Active Policy Group	Unclassified	Yes	an admin can unassign a device or user from the current policy group. This places the endpoint back into the Unclassified group and is available for reassignment.
Active Policy Group	Quarantine	Yes	As part of continuous validation, it is possible for an active device to fail the continuous validation check. In this case, it can be placed back into the Quarantine group.