Default System Groups

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 ssh 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 true 93,96 71186440677965,77 03230100275091,286 2558345904695left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type p