User Entity Controls

As a cloud service provider, ThousandEyes shares the responsibility for security with its customers. Review the information below to understand your role in the implementation of security controls and operational activities.

Identity and Access Management

  • Account Setup

    Initially, ThousandEyes creates a single account group and assigns the designated permitted user with the customer's built-in admin role.

  • User Roles Definition

    The customer configures groups and users using role-based access controls (RBAC) to ensure that only authorized users can access or view sensitive data (including personal information). Note that ThousandEyes allows masking, through RBAC, permissions to certain personal information that the Endpoint Agent collects.

  • User Creation

    The customer creates users and accounts with appropriate roles (the use of SCIM API is supported for automation). There is no charge associated with user accounts on the ThousandEyes platform.

  • User Removal

    Permitted users with management permissions can remove permitted users from account groups in which they have management permissions. The customer is responsible for promptly removing permitted users’ access to the ThousandEyes application, when appropriate.

    Customers with a SAML2-compliant identity provider system can configure the ThousandEyes application to require permitted users to be authenticated using single sign-on (SSO).

  • Passwords. If local authentication is in use, passwords are required to be at least eight (8) characters long and require at least one digit, uppercase or non-alphanumeric character.

    • Forgotten Passwords

      If a permitted user has more than ten (10) failed login attempts to access the application, the permitted user's account will be suspended and will require a password reset via the forgotten-password facility.

    • Password Requirements

      Use appropriate password policies that enforce complexity and maximum password age. The use of shared logins should be avoided at all times.

    • API Authentication

      Authentication for access through the API occurs via an authentication token that the application generates randomly upon your first login. This token does not expire and is revocable at any point in time either by the user who owns the authentication token, or by a user with management permissions in the context of the user’s account group. Once the token is revoked, any API access attempts using the revoked authentication token will be blocked.

    • Passwords for Appliances

      When using ThousandEyes appliances (virtual and physical), the customer’s admins must change the password of the virtual appliance as part of the initial setup process.

  • Access Control Audit

    The customer must periodically review access to the ThousandEyes application to make sure only authorized workers have access, with proper access levels.

Infrastructure Protection Services

Customers must ensure the security of their endpoints (end-user computers) and connectivity. If Enterprise Agents are in use, it is the customer’s responsibility to protect the underlying physical infrastructure, virtualization, and containerization (if present). If the Enterprise Agent is delivered as a Linux application, the customer must also secure the underlying Linux server.

If an end-user asset leaves the customer’s operational ownership, it is recommended that they uninstall the ThousandEyes Endpoint Agent from the system. For all uninstalled or retired systems with an Endpoint Agent, ThousandEyes recommends you remove the Endpoint Agent entry from the ThousandEyes Endpoint Agent inventory, as these are not removed automatically.

Key and Certificate Management

If desired, the customer is also responsible for replacement of a self-signed SSL certificate for the ThousandEyes Virtual Appliance management interface with an SSL certificate of their choice and to make sure all required DNS entries are created in their DNS management system (forward and/or reverse zones).

Logging and Monitoring

The customer configures an audit log ("Activity Log") for download into their log-management solution via the ThousandEyes API (or via a CSV file).

Session Management

The customer assigns the "Keep session alive on auto-update" permission only for those roles containing users who need to have it (such as a NOC user). The ThousandEyes application has a 30-minute session timeout that does not apply when the user has any of the following views open in their browser:

  • Dashboards

  • Alerts > Alert List

  • Cloud & Enterprise Agents > Agent Settings

The views listed above implement automatic content refreshing that happens periodically (the alerts list refreshes every two minutes; dashboards refresh every minute; agent settings refresh every minute). These content-refresh events also reset the session timer, preventing an inactive user's browser session from timing out.

The automatic session prolongation described above requires that the "Keep session alive on auto-update" permission be enabled for the user. For more details about user roles and permissions, see the article on role-based access control.

Policies and Standards

In relation to the ThousandEyes SaaS application, the most important steps for the customer to execute as part of the “Policies and Standards” domain management are to

  • Classify data stored and processed by ThousandEyes.

  • Establish a worker awareness and training program.

  • Comply with Data Subject Access Requests requirements (ThousandEyes will redirect data subjects to your administrators).

  • Review and understand data retention policies and consider the use of API for export or archival.

Other Security Improvements to Consider

  • The customer can request from ThousandEyes Support the removal of access permissions from ThousandEyes personnel. This permission is enabled by default to facilitate support and other activities related to the operation of the ThousandEyes application.

  • The customer should carefully consider who in their organization should have the ability to perform snapshot sharing. This functionality allows internal users to share network events with the customer’s third parties (such as service providers) in a way that allows this data to be accessed anonymously.

  • ThousandEyes currently uses a credentials repository to store and manage credentials for web transaction tests, with future plans to make this repository write-only. The customer should make sure that only authorized personnel have access to this repository.

  • If Enterprise Agents are deployed in the customer’s network, the customer should consider changing Enterprise Agent NTP settings by pointing to their authorized NTP servers (otherwise, the defaults for their operating systems are used).

  • The customer should make sure their users are refreshing their API tokens according to the company's policy.

Additional Information

If a customer has deployed a ThousandEyes Enterprise Agent Virtual Appliance (TEVA) and has configured it to use a proxy that requires authentication, due to a limitation of the underlying Linux platform, those credentials will be stored on the appliance in clear text.