Setup Guide for Nile Trust Service

overview this guide explains how to set up nile trust service, nile’s micro segmentation capability for controlling both east–west and north–south traffic key terminology uni (unidirectional) traffic flows in one direction only bi (bidirectional) traffic flows in both directions segments layer 3 construct that maps to a subnet (replaces vlans in traditional networks) policy types nile trust service supports three approaches to creating trust policies identity based policies (nile recommends using identity based policies when doing a greenfield deployment) subnet/segment based policies (traditional approach) hybrid policies (mix of identity and subnet) nile recommendation use identity based policies combined with nile's built in host based segmentation (segment of one) this approach allows all users and devices to exist on a single large subnet, simplifying network setup without compromising security prerequisites before beginning any migration, complete the following review technical documentation read the https //docs nilesecure com/nile trust service to understand key concepts and constructs contact nile support confirm your system release version enable feature flags request nile support to enable the micro segmentation 1 6 feature flag check site readiness confirm that the target site is already onboarded to nile access service ensure that segments are created and mapped to their respective dhcp pools in the nile ecosystem , there are no vlans nile has a construct called segments a segment is an l3 construct that maps to a subnet so, if your existing network has 10 vlans, in nile that would equate to 10 segments step 1 create policy group definitions 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 for its identity 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 please note that policy group ordering determines which policies apply to an endpoint each user or device is classified into exactly one policy group, based on the first group it matches in the ordered list (user groups are evaluated first, followed by device groups) for example, consider two scim user groups hr admins (listed first) and employees (listed second) if a user belongs to both idp groups, trust service classifies the user into hr admins only and does not evaluate the employees group as a result, when the user accesses the payroll app, the system applies only the policy with hr admins as the source group (for example, “all ports/protocols to payroll app”) any policy using employees as the source (such as “https only to payroll app”) is ignored if the group order is reversed so employees appear first, the same user is classified as employees, and only the employees → payroll app policy applies admin user group create an admin user group using the steps below and select idp group as the match criteria this assumes that admins use sso ssid or wired sso to access the network (note radius based groups will be supported in the future ) scim will return the groups a user belongs to, which will be used to distinguish admins from employees ensure the admin group is configured with the highest priority/order log in to the nile portal in the left navigation, select security > trust engine > policy groups > user groups click the + icon to create a new user group in enter group name , type a descriptive name for the group (for example, admin) in group description , add an optional description (for example, admin group) from select match criteria , choose how users are matched into this group (for example, idp group ) in enter values , type or select the corresponding identity provider value(s) for this group (for example, it admins), then confirm the selection click create to save the user group if no idp is available for identity based policy creation, you can instead create an admin user group that matches on the nile segment, as described in the steps below make sure this admin group is configured with the highest priority/order log in to the nile portal in the left navigation, select security > policy groups > user groups click the + icon to create a new user group in enter group name , type a descriptive name for the group (for example, admin) in group description , add an optional description (for example, admin group) from select match criteria , choose segment in enter values , type or select the segment value that represents your admin users (for example, admin), then confirm the selection click create to save the user group employee user group similarly, create an employee user group and choose idp group as the criteria this assumes employees will be doing sso to access the network the scim protocol will return the groups the user belongs to, and that will be used to differentiate between admin and employee alternatively, if no idp is available (for identity based policy creation), create an employee user group and set the nile segment as the criteria please note that radius based groups will be available in the future guest user group create a guest user group and choose the nile segment as the criterion printer device groups create a printer group using the following steps and choose fingerprint as the criteria ensure this has the highest priority log in to the nile portal in the left navigation, select security > policy groups > device groups click the + icon to create a new user group in enter group name , type a descriptive name for the group (for example, admin) in group description , add an optional description (for example, admin group) from select match criteria , choose fingerprint in enter values , type or select the type of printer that matches your physical one(for example, hp printer), then confirm the selection click create to save the device group for device groups, nile can continuously verify that devices are healthy and behave as expected by using device check the device check button enables protocol based validation against devices in a device group (for example, https, snmpv3, or ssh probes) if validation succeeds , the device remains in its intended device group (such as printers , cameras , or bms ) if validation fails consistently, the device can be automatically moved to the quarantine group, where a more restrictive policy set applies nile recommends enabling device check for high value or high risk infrastructure devices (for example, printers, cameras, nvrs, building systems) to reduce the risk of spoofing, misconfiguration, or compromised firmware camera device group create a camera group and choose fingerprint as the criteria zoom rooms device group create a zoom rooms group based on segments usually, there are multiple types of devices, so a fingerprint may not be an optimal solution dvr app groups create a dvr group and use the ip address or subnet as the criterion in this example, the dvr app group is not connected to nile log in to the nile portal in the left navigation, select security > policy groups > app groups click the + icon to create a new user group in enter group name , type a descriptive name for the group (for example, admin) in group description , add an optional description (for example, admin group) from select match criteria , choose ip/subnet in enter values , type or select one or more entries that represent your dvr network (for example, a single ip address such as 172 16 20 10 or a subnet such as 172 16 20 0/24) then confirm the selection you can also add multiple entries of ip or subent and separate them with commas click create to save the app group call manager app groups similarly, create a call manager group and use the ip address as the criterion in this example, the call manager is not connected to nile system defined policy groups in addition to custom user, device, and app groups, nile trust service provides several system defined policy groups these groups are always present and can be referenced directly in policies unclassified the unclassified group contains endpoints that do not match any explicit user, device, or app group traffic from unclassified endpoints should be treated as untrusted and given only minimal or onboarding access nile recommends that you allow only essential connectivity (for example, onboarding portals or remediation services) deny access to internal resources until the endpoint is classified into an appropriate policy group quarantine the quarantine group is used for endpoints that have failed security checks or have been explicitly placed into an isolated posture by an administrator quarantined endpoints are typically restricted to a small set of remediation services (for example, update servers, ticketing portals) policies for quarantine should follow strict least privilege principles and deny access to production applications and user resources internet the internet app group represents all public internet destinations ( non–rfc1918 address space) use the internet as the destination when defining policies such as employee → internet or guest → internet combine this group with a restrictive service profile (for example, https only) to enforce least privilege web access intranet the intranet app group represents private enterprise networks and internal applications that are reachable through upstream firewalls, data centers, or wan links use the internet as the destination when allowing users or devices to access internal applications that are not directly hosted inside the nile service block typical examples include line of business apps, on prem data centers, and internal portals external the external app group represents upstream or third party enforcement points, such as next generation firewalls, sse gateways, or partner networks use external as the destination for policies that intentionally steer traffic to these enforcement points (for example, local → external with a “forward to firewall” action) this allows you to maintain existing security stacks while nile trust service controls which flows are sent upstream step 2 create service profiles service profiles define which protocols and ports are permitted when traffic between policy groups is allowed they ensure communication adheres to least privilege principles by restricting flows to only what is necessary service profiles are mandatory for any policy configured to allow or forward traffic, consistent with zero trust principles rules within a service profile are ordered, and the default rule is to exclude any port and any protocol (i e , "deny all ports/protocols") printing service profile create a service profile that allows access to tcp 9100 only using the steps below log in to the nile portal in the left navigation, go to security > service profiles click the + icon to create a new service profile in enter service profile name , type printing service in enter service profile description, type printing service click the + icon in the table to add a rule for printing traffic set name to tcp 9100 set protocol to tcp set port to 9100 set action to include save the rule add a second rule to deny all other traffic set name to deny all set protocol to any set port to any set action to exclude save the rule confirm the service profile shows both rules in order (allow tcp 9100 first, then deny all), and save the service profile use this service profile to allow employees to communicate with and administer the printer printing administration service profile create a service profile that allows access to tcp 9100 https (tcp 443) ssh (tcp 22) use this service profile to allow admins to communicate with and administer the printer internet service profile create a service profile that allows access to https use this service profile to allow employees and guests to access the internet only via https all service profile this is a system defined service profile that allows all ports and protocols step 3 create policies a policy set is a collection of policies that together define how access is managed within the network each policy specifies a source, destination, service profile, and action in this step, you use the user, device, and app policy groups from step 1 together with the service profiles from step 2 to define which traffic is allowed, denied, or forwarded each policy references • a source policy group (for example, employee user group) • a destination policy group (for example, printer device group or internet app group) • a service profile (for example, printing service or internet service ) • an action (allow, deny, or forward to firewall) source service profile destination direction action admin printing administration printer uni allow admin all zoom rooms uni allow admin all dvr uni allow admin all voip uni allow admin all call manager uni allow admin all internet uni allow employee printing printer uni allow employee internet internet uni allow guest internet internet uni allow camera all dvr bi allow voip all voip bi allow voip all call manager bi allow zoom rooms all zoom rooms bi allow zoom rooms https internet uni allow in the above table, admin refers to the admin user group created in “admin user group” employee refers to the employee user group created in “employee user group” guest refers to the guest user group created in “guest user group” printer, camera, zoom rooms, voip refer to the device groups created in the previous section dvr, call manager, internet refer to the app groups created earlier printing service, internet service, all refer to the service profiles created in step 2 configure these policies in a global policy set (example employee to printer ) using the following steps log in to the nile portal in the left navigation, go to security > trust engine> policy groups > policy sets click the global default policy set to open it in the policies section, click the + icon to create a new policy in step 1 enter the following details in policy name, enter employee to printer in description, enter employee to printer services click next in step 2 enter source & destination under source, select user group and choose employee from select source under destination, select device group and choose printer from select destination click next in step 3 add action & service profile under action, select allow to permit traffic between employee and printer in the matching service profile, select printing service confirm the visual chain shows source employee → service profile printing service → destination printer click next in step 4 review and save review the policy summary to ensure the name, source group, service profile, and destination group are correct click create (or save) to add the policy to the global policy set back on the global default policy set page, confirm that the new employee → printer policy appears in the policies list with action = allow and the correct source policy group, service profile, and destination policy group use the same workflow to create the remaining policies listed in the table above you can also leverage system defined groups to support dmz and upstream security use cases for example, consider a clearpass server that lives in a dmz subnet behind an upstream firewall and provides a web portal for guests guest endpoints are placed in the guest user group, while the clearpass server—because it sits in a private dmz subnet—can be modeled either as its own app group or treated as part of the intranet system group you then use intranet as the destination for policies that permit guest https traffic from the guest group to clearpass, while the internet system group remains the destination for general guest web access after authentication if you want nile to steer specific flows to an upstream firewall or sse stack in front of the dmz policy actions each trust engine policy defines an action that determines how matching traffic is handled in addition to allow and deny , nile supports forwarding traffic to upstream enforcement points allow permits traffic between the defined source and destination groups according to the selected service profile typically used for flows that should remain within the nile service block (local east–west or site local access) deny blocks all traffic matching the policy nile follows a default deny posture, so any flow that does not match an explicit allow or forward policy is denied forward to firewall (upstream enforcement) the forward to firewall action sends matching traffic to an upstream enforcement system, such as a next generation firewall or sse platform, for additional inspection and policy enforcement use forward to firewall when you are in a brownfield migration and want nile to control which flows are allowed, while retaining existing firewall/sse capabilities for ids/ips, content filtering, or compliance reporting specific flows must always traverse an upstream security stack—for example, intranet → internet , traffic to a cloud security gateway, or regulated applications that require central inspection you want to separate local east–west enforcement (handled by nile) from north–south inspection (handled by your firewall/sse) as a guideline use allow for traffic that should be fully enforced and contained within the nile service block use forward to firewall when traffic must leave the nile fabric and be inspected or logged by your existing upstream security infrastructure global policy matrix – policy creation guide policies in a global policy set can also be created and reviewed using the matrix view the sections below explain how to use matrix specific options, including hiding system default groups and filtering for selected groups open the global policy set in matrix view log in to the nile portal in the left navigation, go to security > policy groups > policy sets click the relevant global policy set (for example, global default policy set ) in the policies section, click matrix to switch from list view to the matrix view the matrix shows source policy groups on the left and destination policy groups across the top create a policy from a matrix cell in the matrix, identify the source row and destination column you want to create a policy for (for example, employee → internet ) click the + icon in the intersecting cell this opens the create policy wizard at step 1 – basic information , with source and destination already derived from the matrix selection step 1 – policy name in policy name , enter a name that reflects the traffic flow (for example, employee internet) (optional) add a description confirm that source is set to employee and destination is set to internet (auto populated from the matrix) click next step 2 – source & destination , the fields are populated based on the matrix cell you clicked for the employee → internet example source type user group select source employee destination type app group select destination internet you usually only need to review these values and click next to continue step 3 – action & service policy , select the desired behavior allow – permit traffic between the defined source and destination deny – block all traffic from the source to the destination forward – redirect traffic upstream for an allow policy, ensure allow is selected in matching service profile , choose the appropriate service profile (for example, an internet service profile) confirm the visual chain shows source employee service profile (your selected profile) destination internet click next step 4 – review and save review the policy summary, including policy name source group destination group action service profile if everything is correct, click create to add the policy you are returned to the matrix, where the selected cell now reflects the policy status (for example, a green check for an allow policy) please note that using the matrix flow is typically faster and more convenient because step 2 – source & destination and much of step 3 – action & service profile are auto populated from the matrix selection matrix display and filter options hide system default groups at the top right of the matrix, you can simplify the grid by hiding built in policy groups use the hide system default groups toggle to show or hide system default groups from the matrix when the toggle is on , only your custom user, device, and app groups are shown, making it easier to focus on tenant‑specific policies filter the matrix by specific groups you can further narrow the matrix to only the groups that matter for the policy design you are working on in the matrix header, click the filter icon in the filters panel, choose a category on the left user groups device groups app groups system default groups in the middle column, select one or more groups to focus on (for example, finance , engineering , it admin , employee ) click apply to update the matrix only the selected groups will be shown on the source and destination axes to reset to the full view, click reset (and then apply if required) these options make the matrix an efficient way to both visualize and configure policies, especially in larger environments with many groups and flows policy logs and validation policy logs are critical for validating policies and troubleshooting unexpected behavior after creating or modifying policies, always use the logs to confirm that traffic is being evaluated and enforced as intended where to view policy logs from the nile portal, open the security / trust engine area and navigate to the policy logs view this view shows each evaluated flow along with source/destination policy groups (user, device, app, system groups such as internet, intranet, external) service profile matched (for example, printing service , internet service ) action taken ( allow , deny , or forward to firewall ) direction (east–west or north–south) and basic flow metadata (ips, ports, timestamp) troubleshooting with policy logs when users report access issues locate the corresponding flow in the policy logs check which source/destination group , service profile , and action were applied adjust the relevant policy group membership, service profile, or policy action (allow vs forward vs deny), then re test and re verify via logs regularly reviewing policy logs during and after migration helps ensure that the new trust service policies match your intended access model and that the default deny posture does not introduce unexpected outages