Establishing a privacy policy

Overview

Nexthink privacy is built around five pillars:

Security of information: The information is collected via encrypted channels and the access to all databases is restricted.

User privileges: The privileges of a user define the subset of the devices or locations that the user can access (view domains), the rights of the user to change the configuration (administration privileges), the creation of content (dashboards) and the access to external web domains and web requests.

Anonymization: Users, devices, destinations and web domains are anonymized by default. Users need special privileges to access identity information of these objects.

Storage policy: The full set of information is collected and stored by default. However, it is possible to remove and prevent collecting devices and other information from the dataset. There is also a special policy for Web & Cloud storage that can prevent the collection of web domains.

Audit trails: Every change in the configuration settings is audited, including account edition.

Security of information

Overview of communication channels

The following schema describes the communication architecture from a high level point of view.

The table describes the communication channels used to access or transport sensitive information:

All the channels that transport sensitive information are encrypted. All optional channels have to be activated or configured, apart from the shell that is set-up by default.

Collected data

Nexthink does not collect any information about the content of files, e-mail, web sites or any other content. Nexthink collects the following data:

User privileges

Accounts are based on profiles and roles.

Profiles determine the access rights of a user:

• Access to the Portal, possibly limited to a view domain, the right to create and publish dashboard content in the Portal, and administration rights (management of accounts, additional content, and system configuration).

• Access to the Finder, the rights to edit applications, objects tags, categories, services and global alerts.

• Access related to web domains (Web & Cloud visibility) in the Finder. By default, users can only see the web domains that are configured in web-based services.

Roles define the default content that is available to a user in the Finder and in the Portal. Roles are assigned to users either indirectly through their profiles or directly through the user account.

• For non-administrator users, roles limit the content that can be accessed in the Portal.

Limiting the view to a domain

Devices can be grouped along a hierarchical tree. For example, a tree with three levels: Department / Region / Entities.

View Domains

A View domain represents the set of data that a user has the right to see. It is defined by a node of the hierarchy and optionally by a limit in the depth. Based on the previous example, a view domain could limit the view to a specific Department and allow the user to drill-down to the underlying Region but prevent to see the details by Entities.

Creating and publishing dashboards in the Portal

Administrators can create, publish, and manage Portal modules, which are a construct that groups dashboards.

An administrator can see and manage the modules published by any other user, where managing means updating or deleting a published module.

Normal users, on the other hand, can only see a module created by an administrator if the module is included in their roles. The creation and publication of modules is also restricted for normal users. Normal users can create and publish Portal modules only if they have the following options checked in their profile, respectively:

• Allow creation of personal dashboards

• Allow publication of dashboards

Normal users can see the modules published by other normal users. A normal user with the permission to publish dashboards can manage the modules created by other normal users, but not by administrators.

Of course, normal users with the right to create dashboards can manage their own personal modules; that is, the modules that they have created or that they have copied to their personal content.

Privileges for users of Nexthink Finder

For users of the Finder, select their privileges when creating the user profiles (step 4).

The privileges are related to the edition and application of object tags, the modification of the system configuration (categories, metrics, campaigns, remote actions, etc.), and other features for system management.

Anonymization

Access rights to data

There are four levels of data privacy defined in the profile of the account, that specify the access rights of each account to particular pieces of information:

The following table enumerates the visible attributes of users, devices, destinations and domains for each data privacy level.

Display of anonymized UIDs

When the data privacy level enforces anonymous users, devices, destinations or domains, their UIDs are hidden from the results of an investigation as follows (example based on devices):

That is, the UID is displayed in the form anonymized object , where object is the type of retrieved object under anonymization.

Investigations using the name of the object are not possible. However, if an authorized Finder user provides the UID of an object, any user may refer to the object in an investigation through its UID.

Categories

Categories also support data privacy: a level can be set for a category so that only accounts with the same or a higher data privacy level will be able to see and use a given category. For example, if a category is created with a Data Privacy level set to "none (full access)", only Finder user accounts having a "none (full access)” level will be able to see and use this category. The privacy setting on categories applies only to the Finder.

Examples of user profiles

These are some examples of user profiles that can be configured with the current privacy features of Nexthink:

Storage policy

Database

The following databases are used in Nexthink product:

Ignoring fields

In addition to the anonymization of data, it is possible to configure the system to ignore certain data that is delivered by the collector. In this case, data are not recorded at all:

Retention time

By default, a device is removed automatically from the Engine Database after 3 months of no activity. The retention time can be configured.

Ignoring specific devices

For each device, it is possible to restrain the collected information at the level of the Engine. The possible settings are:

• Web requests, connections and executions (by default, everything is stored)

• Connections and executions

• Executions only

• None

• Remove

For the latter case, this means that the device will be removed from Engine database if there is no activity for more than one day (i.e. the Collector was uninstalled).

In the Finder, right-click a particular device in the list view results of an investigation or in the top-left icon of its own device view and select Edit... :

Ignoring specific application, executables, binaries and domains

The same is possible for applications, executables and binaries. The only difference is that it is not possible to remove them, but only to stop storing the related information.

Web & Cloud

Because Web & Cloud data has a significant impact on the data retention of the Engine, there are three different settings for the storage policy of domains and web requests that let you control how they are stored.

1. Log in to the Web Console as administrator.

2. Under the APPLIANCE tab, select Privacy from the left-hand side menu.

3. In the Web & Cloud section, select the desired Storage policy from the list.

(*) When a web-based service is created, its underlying web requests and domains are stored their visibility is unrestricted.

(**) If a web request does not belong to a defined service, its access is restricted.

Visibility for metrics

In the same way Finder users need special privileges to view web domains and web requests that are not part of a web-based service (see above), metrics have a similar setting that limits the web domains and web requests that are visible in the dashboards of the Portal.

From the Web Console, under the Web & Cloud section, select the Visibility for metrics from the list:

• full, to enable metrics the use of web data from any stored web request or domain (in accordance to the storage policy).

• restricted, to prevent metrics from using any web data that is not related to a web-based service.

Engine internal domains

Internal domains are never sent to Cloud Intelligence. To identify internal domains, the following rules apply:

• Domains with non-official TLD (top level domain)

• Domains with name corresponding to IP addresses belonging to Engine internal network.

• Domains with names matching custom rules (e.g. *.nexthink.com). These rules can be set up in the Web Console.

Excluded domains

For privacy reasons, you may want to avoid storing web requests to particular domains. For instance, a web application that collects opinions and complaints of employees about their peers and superiors requires the anonymity of the participants. However, with the right level of permissions, a user of the Finder can easily discover who connected to the application and when, just by investigating the web requests that are addressed to the domain of the web application. To make the system ignore web requests to specific domains, add the domains to the excluded domains list found in the Web Console.

To add a domain to the excluded domains list:

1. Log in to the Web Console as administrator.

2. Click to the Appliance tab at the top of the window.

3. Select Privacy from the left-hand side menu.

4. Under Web & Cloud, add the domain to the list Excluded domains:

   • Separate the names of the domains with a single space character (e.g. anonymize.nexthink.com *.example.com).

   • You can use wildcards in the names of the domains:

     • The question mark ? may be replaced by any single character.

     • The asterisk * may be replaced by any number of characters.

Audit trails

Auditing Nexthink is performed using the syslog framework. It captures actions performed with administrator rights that may impact the system. It is not a logging facility.

Only the action and who performs it is audited. The values that are set are not logged.

The complete list of audit point is available here.

Data sent to Nexthink

Nexthink Appliances automatically send non-personal data to Nexthink SA to provide value-added services to Nexthink customers. Learn how to enable or disable these services to select which data you send to Nexthink in the article about operational data sent to Nexthink.

RELATED TASKS

• Adding Users

• Specifying your internal networks and domains

RELATED CONCEPT

• Service

RELATED REFERENCES

• Operational data sent to Nexthink

• Data retention