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 |
<--> | 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) |
|
Activities (represent actions performed by Objects) |
|
Events (are warning or errors) |
|
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:
Finder:
| Anonymization Portal & Finder:
|
CIO | |
He needs high level information. Therefore he will mainly use Portal as a Reader. | |
User privileges Portal:
Finder:
| Anonymization Portal & Finder:
|
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:
Finder:
| Anonymization Portal & Finder:
|
Security engineer | |
He needs full access to all data such that he can investigate any issues. | |
User privileges Portal:
Finder:
| Anonymization Portal & Finder:
|
Network & system engineer | |
He needs access regarding connection and destination but does not need to access user information. | |
User privileges Portal:
Finder:
| Anonymization Portal & Finder:
|
Support engineer | |
He only needs to access user information when required and needs to ask the privacy officer for User UID. | |
User privileges Portal:
Finder:
| Anonymization Portal & Finder:
|
IT project manager (transformation) | |
He is only accessing information related to a specific project and only needs anonymous information. | |
User privileges Portal:
Finder:
| Anonymization Portal & Finder:
|
Storage policy
Database
The following databases are used in Nexthink product:
Engine | Portal |
Database (in memory) Database backup
| Database Database backup
|
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.
Log in to the Web Console as administrator.
Under the APPLIANCE tab, select Privacy from the left-hand side menu.
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:
Log in to the Web Console as administrator.
Click to the Appliance tab at the top of the window.
Select Privacy from the left-hand side menu.
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
RELATED CONCEPT
RELATED REFERENCES
Last updated
