Establishing a privacy policy

Contents

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
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
Application Library <--> 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

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.

Hierarchy.png

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):

DeviceAnonUIDs.png

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.

Category privacy.jpg

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:

EnginePortal

Database (in memory)

Database

  • 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_usernameIf this is set to true, engine will no longer store the user names and Finder will show 'Unknown' for all usernames.
user_interactionIf 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_licenseIf set to true, windows license key will no longer be stored.
ignore_print_jobsIf set to true, all print jobs will be ignored.
ignore_external_ipIf set to true, destination IP address in connections will be set to 0.0.0.0
ignore_external_domainsIf set to true, domains that are external will not be recorded.

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 every device, it is possible to restrain the collected information at the level of the engine. The possible settings are:

  • By default, everything is stored
  • 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... :

Edit device.jpg

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

There are three storage policies, that can be applied to every engine and that applies to all domains and web requests. This can be set up in the Web Console:

Web & Cloud storage policy Use casesWeb domains
1 None

I don't want to store any information related to web domains.

Domains and web requests is 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. (*)

3All

+ 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 domains and web requests are stored.

But the visibility can be restricted and depends on user privileges. (*) (**)

(*) If a web service is created, the underlying web request and domains are stored and there are no restriction on visibility.

(**) If a web request is NOT defined in a service, its access will be restricted.

Portal account visibility

Finder users need special privileges to view web domains and web requests that are not part of a web-based service (see here above). The same setting is available for the Portal account. If the visibility is "restricted" it will prevent Widget to show data that are not part of a web-based service. This can be set up in the Web Console.

Engine internal domains

Internal domains are never sent to the Application Library. 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.

Customer improvement program

The Nexthink Customer Experience Improvement Program will deliver benefits to the customers by allowing us to understand how customers use Nexthink software, so that continuous enhancement can be provided. The program is voluntary and anonymous and can also be disabled by default for all users.

Find out more

Nexthink library

Nexthink Library is a cloud-based knowledge database that gives customers access to a large set of ready-to-use predefined investigations, reports, templates and application information. The Nexthink Library is not mandatory and its access has to be enabled.

When enabled, anonymized data are collected and send to the library. This enables the tagging of binaries with threat level and categorization, and hardware and software compatibility assessment.

The details of collected attributes are described in a dedicated document available on the partner portal.

Related tasks