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:

Core components			Protocol or encryption
Collector *	->	Engine	UDP encrypted
Collector *	<-->	Engine	TCP encrypted
Finder	<-->	Engine	TLS
Portal	<-->	Engine	HTTPS by default
Portal	<-->	Nexthink Central License Manager	HTTPS
Optional
Shell	<-->	Appliance (Engine or Portal)	SSH
API	<-->	Engine	REST HTTPS
Active directory	<-->	Engine	SSL
Cloud Intelligence / Enhance	<-->	Engine	HTTPS
Investigation Library	<-->	Portal	HTTP
Investigation Library	<-->	Finder	HTTP
DB backup	<-->	Engine	SMB
Email	<-->	Engine	SMTP
Nexthink updates	<-->	Finder, Appliance	HTTPS, HTTP
Nexthink customer improvement program	<-->	Finder	HTTPS

* Nexthink recommends using the TCP protocol for the Collector connectivity.

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:

Objects (represent real life items recognized by Nexthink)
User Device Package Application Executable Binary Port Destination Printer Domains
Activities (represent actions performed by Objects)
Installation Execution Connection Print job System boot User logon Web request
Events (are warning or errors)
Device warning Device error Execution warning Execution error

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:

Access rights	Description
Anonymous users, devices, destinations, and web domains	The names of users, devices, destinations, and web domains are not visible to the account
Anonymous users and devices	The names of users and devices are not visible to the account
Anonymous users	Only the names of users are not visible to the account
None (full access)	No restrictions: all names are visible

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

Data Privacy Level	Users	Devices	Destinations	Domains
None (full access)	Username Distinguished Name Full Name Nexthink UID	Computer name Windows SID IP address Nexthink UID	Destination name IP address Nexthink UID	Domain name Nexthink UID
Anonymous users	Anonymized users	Computer name Windows SID IP address Nexthink UID	Destination name IP address Nexthink UID	Domain name Nexthink UID
Anonymous users and devices	Anonymized users	Anonymized devices	Destination name IP address Nexthink UID	Domain name Nexthink UID
Anonymous users, devices, destinations and domains	Anonymized users	Anonymized devices	Anonymized destinations	Anonymized domains

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:

Nexthink administrator
He is the administrator of Nexthink products within the enterprise and therefore has full access rights.
User privileges Portal: Administrator: yes Reader: all domains Dashboard creation: public Finder: Allow access, allow edition	Anonymization Portal & Finder: none (full access)
CIO
He needs high level information. Therefore he will mainly use Portal as a Reader.
User privileges Portal: Administrator: no Reader: all domains Dashboard creation: public Finder: No access, No edition	Anonymization Portal & Finder: anonymous users
Privacy officer
He has the full access regarding data anonymization and can provide the User UID to other co-worker if needed.
User privileges Portal: Administrator: no Reader: all domains Dashboard creation: public Finder: Allow access, No edition	Anonymization Portal & Finder: none (full access)
Security engineer
He needs full access to all data such that he can investigate any issues.
User privileges Portal: Administrator: no Reader: all domains Dashboard creation: public Finder: Allow access, allow edition	Anonymization Portal & Finder: none (full access)
Network & system engineer
He needs access regarding connection and destination but does not need to access user information.
User privileges Portal: Administrator: no Reader: all domains Dashboard creation: personal Finder: No access, No edition	Anonymization Portal & Finder: anonymous users
Support engineer
He only needs to access user information when required and needs to ask the privacy officer for User UID.
User privileges Portal: Administrator: no Reader: all domains Dashboard creation: no Finder: Allow access, No edition	Anonymization Portal & Finder: anonymous users
IT project manager (transformation)
He is only accessing information related to a specific project and only needs anonymous information.
User privileges Portal: Administrator: yes Reader: limited domains Dashboard creation: personal Finder: Allow access, allow edition	Anonymization Portal & Finder: anonymous users, devices, destinations and domains

Storage policy

Database

The following databases are used in Nexthink product:

Engine	Portal
Database (in memory) Database backup Internal (automatic) External (not configured by default)	Database Database backup Internal (automatic) External (not configured by default)

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:

ignore_username	If this is set to true, engine will no longer store the user names and Finder will show 'Unknown' for all usernames.
user_interaction	If set to false, user interaction information will no longer be recorded (it will not be displayed in the device view and the "interaction time" aggregate will be always 0%).
ignore_windows_license	If set to true, windows license key will no longer be stored.
ignore_print_jobs	If set to true, all print jobs will be ignored.
ignore_external_ip	If set to true, destination IP address outside the specified internal networks are set to 0.0.0.0 in connections.
ignore_external_domains	If set to true, domains which are not part of the internal domains are not recorded; except for domains that are explicitly included in the definition of a web-based service.

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.

Web & Cloud storage policy	Use cases	Result
1	none	I don't want to store any information related to web domains.	Domains and web requests are discarded.
2	services only	+ I want to monitor internal or external web services like saleforce.com, office365.	Storage is discarded unless related to a configured web-based service. (*)
3	all	+ I want to discover all web applications used in my company. + I want to see if there are any security breach in my company	Every domain and web request is stored. But the visibility can be restricted and depends on user privileges. (*) (**)

(*) 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