Introduction

Rampiva Automate is secure by design. We’ve made fundamental design choices to protect the data processed through Automate, which we highlight in this article:

• Authentication and Trust

• Access Control

• Encryption

• Openness

Authentication and Trust

Users

Requests from the user browsers to the Automate platform requires a pre-existing authentication. The authentication mechanisms available and their settings are configured in the Scheduler service and can be one or a combination of the following:

• Azure Active Directory (AD);

• OpenID Connect Provider (e.g. Google Account, OKTA).

• Local Active Directory over LDAP

• Nuix User Management Service (UMS);

Open

Authentication with Azure AD or OIDC

Open

Username and password authentication with Nuix UMS or LDAP

The security requirements of the user authentication mechanism, such as password complexity, password history, password failed attempts, account lockout duration, multi-factor authentication, etc., are configured with the authentication provider and are outside the scope of this document.

Single-Sign On (SSO)

When using the local Active Directory over LDAP authentication service, it is possible to configure this service with the SSO option. When this option is enabled, users who are custodians of Legal Hold matters that are also configured to use the SSO option, will receive an email whenever they need to respond to a Legal Hold Notice, containing a link that will automatically log the user into Rampiva.

The link can only be used to authenticate into Rampiva once, and is only valid for the duration specified in the authentication service. If the user attempts to navigate to Rampiva with a link that was previously used or a link that expired, the user will be presented with the option to request a new refreshed link by email. The email will be sent to the same email address associated with the original Notice.

The link contains the user unique identifier in Rampiva and is signed.

Infrastructure

A typical Automate deployment involves multiple servers, including:

• One Scheduler server which is responsible for managing the environment, issuing jobs to Engines and interfacing with other systems;

• One or multiple Engine servers, on which the data processing jobs run;

• Optionally, one or multiple Proxy servers, which can be used to offload data transfer and some computation tasks from the Scheduler server.

• Third-party servers supporting services such as Nuix ECC, Nuix UMS, etc.

The root of trust in an Automate deployment is the Scheduler server. All requests are initiated from the Scheduler to query and send commands to the Engine servers or the third-party servers, with one exception: the Proxy.

When a new Engine server is added to the Automate deployment, the Scheduler and the Engine mutually authenticate using the shared API secret and negotiate an exchange key. This key is used by the Engine server to authenticate subsequent commands from the Scheduler.

The Proxy server authenticates to the Scheduler server using a key derived from the shared API secret and negotiate an exchange key. This key is used by the Proxy server to retrieve configuration settings and supported features from the Scheduler server. However, the requests from the user browser to the Proxy server are passed-through to Scheduler without the Proxy server performing additional authentication. It is the responsibility of the Scheduler server to authenticate the end-user, similarly to how this would be performed if users accessed the Scheduler directly and not through the Proxy server.

Requests from the Scheduler to to third-party services are authenticated with the mechanism provided by the service in question. Access to Data Repositories from the Scheduler and Engine services is authenticated using the built-in Windows mechanism for accessing File Shares, using the domain account configured to run the Scheduler and Engine services.

In addition to the authentication mechanisms that occur at the application level and which were described in this section, the communication between the Automate components is encrypted over TLS; the server receiving the request can be further authenticated by configuring certificate pinning.

Integration With Third-Party Solutions

Rampiva Automate can integrate with third-party solutions such as business process automation, or low-code automation solutions by using the Rampiva API. The API is bidirectional.

Calls to Automate can be made using the REST API - these requests are authenticated with an API key which is created by the user configuring the integration. Multiple keys can be created by a user, for example, for integrating with multiple third-party solutions. All actions performed with an API key created by a user will be performed under the identity of that user, and will inherit the security permissions of the users. API keys expire after a duration predefined at creation, and can be explicitly disabled or deleted.

Calls from Automate to third-party solutions can be triggered automatically when an event occurs in Automate, by using the Webhooks mechanism. The webhook call from Automate is signed using a signature key. This key is only provided to the user at the time when the webhook is configured, and cannot be retrieved at a later point. The third-party service can be authenticated by pinning the TLS certificate.

Access Control

The access of users in the Automate platform is configured using the Security Policies. A policy has 3 elements:

• Principal: the users or groups which are allowed to perform the action;

• Permission: the action that can be performed;

• Scope: the target on which the action can be performed.

When applied to a compound scope, for example a Client, the security policy is inherited by all members of the scope, in this example all Matters of that Client.

For additional information on Security Policies, please see the product documentation https://downloads.rampiva.com/automate/release/guides/en_US/user-guide.html#_security_policies

Encryption

Data in Transit

All communication between the user browser and Automate, including data uploaded to a repository, as well as the communication between the Automate components, is performed using the HTTP protocol. By default, this communication is encrypted using TLS v1.2 and requires one of the following ciphers:

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256;

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384.

The TLS settings, including the supported protocol version, the ciphers and the certificates can be updated in the Automate configuration.

Additionally, for the communication between Automate components, and the communication from Automate components to third-party services over HTTP, the TLS certificates can be pinned by supplying the SHA-256 hash of the trusted certificate.

The access between the Scheduler and Engine services to the Data Repository is performed using the standard Windows File Share mechanism, which supports encryption in transit. However, this mechanism is configured at the operating system level, and is outside the scope of this document.

Data at Rest

Sensitive data stored in the Automate database, such as passwords, API keys, and protected parameters, is encrypted in storage. When Automate is deployed on the Microsoft Windows operating system, this data is encrypted using the Microsoft Data Protection API (DPAPI), with the encryption scope Current User. This means that the data can only be decrypted by the service account under which the Rampiva services run. On Linux, this data is encrypted using a data encryption key generated when the application is installed.

Data uploaded by users to Data Repositories is stored using the underlying operating systems mechanism, for example File Shares on Microsoft Windows. The encryption of this data is not controlled by Rampiva and is typically handled using a Full-Disk Encryption solution.

Protected Parameters

Parameters with the name ending in _protected or _password are protected. These parameters should be either filled out by the user when submitting a Job, or stored in the Execution Profile. Rampiva has several security measures built-in for protected parameters:

• Protected parameters submitted to Scheduler in the Execution Profile or in the Job submission, or configured in Workflow Designer in the Options pane, are encrypted before storage in the Automate database, as described in the Data at Rest section.

• Protected parameter values are masked in the logs.

• Protected parameter values are not stored in the Utilization database.

• Protected parameter values are not returned to the user by Scheduler.

• Protected parameters can only be used in Rampiva Operations in the fields expecting a passwords or secret key.

• When creating a Workflow with the Workflow Designer, the user is not allowed to type a default value for protected parameters because the Workflow file is saved in clear text and doing so would expose the protected value.

Masked parameters (i.e. parameters with names ending in _masked) are masked in the Execution Log but do not have the same security measures applied to them as protected parameters. Masked parameters can be evaluated in any place where a regular parameter can be used, including in scripts.

Diagnostics Data

In order to enforce the Rampiva license and to gain an understanding of how our clients use the platform so that we can continually improve it, the Automate platform transmits diagnostics data to the Rampiva License Server. When configuring the platform, the user has the option to select one of 4 diagnostic levels:

• None - no diagnostic data is collected (only available with an offline license, in air-gapped environments)

• Required - send information about the platform utilization.

• Enhanced - send information about the platform configuration and utilization, including statistical data.

• Optional - send information about the platform configuration and utilization, including statistical data and encrypted named objects.

For more details an the diagnostics levels and sample data transmitted at each level, please see the Automate - Diagnostics and Provide article available at https://rampiva.atlassian.net/wiki/spaces/KB/pages/472449088/Automate+-+Diagnostics+and+Privacy.

Openness

A secure platform should be subject to public scrutiny If the security of the platform depends on certain aspects of the design being kept secret, then those aspects become liabilities. This section describes our effort to open up the Automate platform to expert and external security review.

Open API

The Automate user interface is built on top the Rampiva REST API. All actions that can be performed on the Automate platform by users can also be performed using the API. The API, including the endpoints, the data expected and the responses provided is documented in the OpenAPI v3 specification, which is accessible at https://downloads.rampiva.com/scheduler-for-nuix/release/openapi/index.html, or from an Automate deployment, under the Settings → User Resources section.

Additionally, the installation manual, user guides and change logs for the Automate platform are publicly available for download at https://downloads.rampiva.com/automate/release/index.html

Security Penetration Testing

We perform regular security penetration testing on the Automate platform. If you are a Rampiva client and would like to receive a copy of the most recent Penetration Test report, please contact us using the regular support channels.

If you have a security concern, please contact Support.