Relativity Server Security

Relativity Server Security
Version 2022, December 15, 2022

Table of Contents
Introduction ................................................................................................................................................. 5
Relativity Infrastructure Configuration ...................................................................................................... 5
Backups and Maintenance ..................................................................................................................................... 5
SQL Server ............................................................................................................................................................. 5
File Server............................................................................................................................................................... 6
Virtual Machine ....................................................................................................................................................... 6
Disaster Recovery .................................................................................................................................................. 6
High Availability ...................................................................................................................................................... 6
Multiple Servers ...................................................................................................................................................... 6
Load Balancing ....................................................................................................................................................... 6
Clustering ................................................................................................................................................................ 7
IIS Security ............................................................................................................................................................. 7
HTTP Strict Transport Security............................................................................................................................... 7
X-Frame-Options .................................................................................................................................................... 7
Referrer-Policy ........................................................................................................................................................ 7
X-Content-Type-Options ......................................................................................................................................... 8
X-Xss-Protection ..................................................................................................................................................... 8
Slim Down IIS Headers........................................................................................................................................... 8
HTTP Verbs .......................................................................................................................................................... 11
Enable Custom Errors .......................................................................................................................................... 12
Disable Directory Browsing .................................................................................................................................. 12
Remove the HTMLArea Application ..................................................................................................................... 12
Encryption ............................................................................................................................................................. 13
SQL Server ........................................................................................................................................................... 13
File Server............................................................................................................................................................. 14
Web Server ........................................................................................................................................................... 14
Analytics Server .................................................................................................................................................... 14
Conversion Agent/Service Bus Server ................................................................................................................. 15
Service Host Manager Service ............................................................................................................................. 15
Network Firewall ................................................................................................................................................... 15
Lock Down Unused Ports ..................................................................................................................................... 15
Take a Network Baseline ...................................................................................................................................... 15
Use a Firewall to Create a DMZ ........................................................................................................................... 15
Disable the SMBv1 Protocol on all Servers.......................................................................................................... 15
Data Grid Security ................................................................................................................................................ 16
RabbitMQ Security................................................................................................................................................ 16
Using Antivirus on Relativity Servers ................................................................................................................... 16
Exclusions ............................................................................................................................................................. 16
© Relativity. All rights reserved. 2

Scan all New Relativity Data ................................................................................................................................ 16
Server Access Control .......................................................................................................................................... 16
Relativity Servers .................................................................................................................................................. 16
SQL Servers ......................................................................................................................................................... 16
Microsoft Windows and Relativity upgrades......................................................................................................... 17
Relativity Secret Store .......................................................................................................................................... 17
OutsideIn............................................................................................................................................................... 18
Relativity Front-end Configuration ........................................................................................................... 19
Change Default Relativity Administrator Passwords ............................................................................................ 19
Configure Instance Settings ................................................................................................................................. 19
AuditingEnabled .................................................................................................................................................... 19
CookieSecure ....................................................................................................................................................... 19
CookieHTTPOnly .................................................................................................................................................. 20
CookieDuration ..................................................................................................................................................... 20
EnforceHTTPS ...................................................................................................................................................... 20
KeplerServicesUri ................................................................................................................................................. 20
KeplerServicesUriForAgents ................................................................................................................................ 21
ApplicationRestrictedFileTypes ............................................................................................................................ 21
RestrictedFileTypes .............................................................................................................................................. 21
RestrictedNativeFileTypes .................................................................................................................................... 21
ShowStackTraceOnError ...................................................................................................................................... 22
MOTDTextOnly ..................................................................................................................................................... 22
SanitizeHTMLOutput ............................................................................................................................................ 22
HTMLSanitizerWhitelist ........................................................................................................................................ 22
TreatHtmlAndXmlAsText ...................................................................................................................................... 22
AllowHtmlVisible ................................................................................................................................................... 23
IgnoreCertificateErrors.......................................................................................................................................... 23
MaximumPasswordAgeDefault ............................................................................................................................ 23
MaximumPasswordHistory ................................................................................................................................... 23
AllowAddOrEditScripts.......................................................................................................................................... 23
DeveloperMode .................................................................................................................................................... 24
AdminsCanSetPasswords .................................................................................................................................... 24
ReplaceCaseNameWithArtifactID ........................................................................................................................ 24
ReplaceApplicationNameWithArtifactID ............................................................................................................... 24
AdditionalWorkFactorDefault ................................................................................................................................ 24
MaximumAdditionalWorkFactorRestriction .......................................................................................................... 25
MaxInvalidLoginAttemptsDefault .......................................................................................................................... 25
PasswordResetEmailExpirationInMinutes ............................................................................................................ 25
AccessTokenExtraLifetime ................................................................................................................................... 26
InvitationLinkLifetimeInMin ................................................................................................................................... 26

ReplaceUserNameWithHashValue ...................................................................................................................... 26
ExportEscapedFormulasFromItemListDefault...................................................................................................... 26
SMTPSSLisRequired ............................................................................................................................................ 26
RestrictReferentialFileLinksOnImport ................................................................................................................... 27
Configure Instance and Workspace Security ....................................................................................................... 27
Configure Authentication ...................................................................................................................................... 27
Transparent Data Encryption (TDE) ......................................................................................................... 27
Introduction ........................................................................................................................................................... 27
Transparent Data Encryption Architecture ........................................................................................................... 27
Considerations before enabling TDE ................................................................................................................... 27
Enabling SQL Server Transparent Data Encryption (TDE) on the Primary SQL Server ..................................... 28
Create Master Key ................................................................................................................................................ 28
Create Certificate .................................................................................................................................................. 28
Backup the Certificate and the Private Key .......................................................................................................... 29
Encrypt the Database ........................................................................................................................................... 29
Backup the Database ........................................................................................................................................... 30
Enabling SQL Server Transparent Data Encryption (TDE) on the Distributed SQL Server ................................ 30
Create Master Key ................................................................................................................................................ 30
Transfer the Certificate from the Source SQL Server .......................................................................................... 31
Disable Encryption on a Database ....................................................................................................................... 31
Disable Encryption ................................................................................................................................................ 31
Drop the Encryption Key ....................................................................................................................................... 32
Remove Encryption Certificates and the Master Key ........................................................................................... 33
Check the Certificates on the SQL Server ........................................................................................................... 33
Drop the Certificate ............................................................................................................................................... 33
Drop the Master Key ............................................................................................................................................. 33
TLS Setup in Relativity.............................................................................................................................. 33
How TLS Works .................................................................................................................................................... 33
Overview ............................................................................................................................................................... 33
Certificates ............................................................................................................................................................ 33
When to Use TLS ................................................................................................................................................. 35
TLS Deployment Scenarios – Supported Topologies .......................................................................................... 35
Private Network (no TLS) ..................................................................................................................................... 35
Front-end TLS ....................................................................................................................................................... 36
TLS Offloading at Load Balancer ......................................................................................................................... 37
End-to-End TLS .................................................................................................................................................... 38
Certificate Authorities............................................................................................................................................ 39
Why Run Your Own CA? ...................................................................................................................................... 39
Options for Creating a CA .................................................................................................................................... 39
Federal Information Processing Standard Compliance........................................................................................ 40

FIPS Compliance Overview .................................................................................................................................. 40
Configuring Relativity for FIPS ............................................................................................................................. 40
Appendix.................................................................................................................................................... 40
Recommended IIS Crypto Settings ...................................................................................................................... 40
Transparent Data Encryption (TDE) Architecture ................................................................................................ 41
Update Relativity Identity Server Certificate ......................................................................................................... 41
Introduction
Security is essential when it comes to protecting data in an e-discovery software such as Relativity.
This document covers recommendations for securing Relativity through its infrastructure configuration and
front-end configuration.
If you have any questions about the content in this document, contact support via
https://community.relativity.com/s/contactsupport .
Relativity Infrastructure Configuration

This section details recommendations to secure the back-end infrastructure of a Relativity environment.
Backups and Maintenance

This section details recommendations for backing up SQL server, file server, and virtual machine.
SQL Server
Performing regular SQL Server backups and maintenance is extremely important for ensuring optimization
of the server, redundancy of data, and consistency of data. We highly recommend taking the following
maintenance steps on every Relativity database:
• Perform Full and Transaction Log Backups on a schedule consistent with your company’s Recovery
Point Objective (RPO) and Recovery Time Objective (RTO).
• Regularly test both your backup and restore procedures to ensure you can meet your RPO and RTO.
• Perform DBCC CHECKDB Consistency Checks weekly or more often.
• Run the Relativity Index Optimize script nightly. This script is available in the Customer Community.
For more information on SQL Server maintenance, please read the following pages on our Documentation
site:
• Selecting a backup approach

• Identifying data to back up

• Backup and data management best practices
• Assessing risk and cost concerns
• Managing your Relativity environment
File Server
It’s important to take regular backups of anything stored on a File Server to ensure the redundancy of
Relativity data. These backups could include Natives and Images, the Cache, SQL Backups, dtSearch or
Analytics indexes, etc.
For more information on File Server backups, please read the following pages on our Documentation site:
• Identifying data to back up

• Backup and data management best practices
• Assessing risk and cost concerns
Virtual Machine
Work with your Virtual Machine vendor to find the best maintenance approach for backing up or
snapshotting your brand of software.
Disaster Recovery
Reference the following documents in the Customer Community for an up-to-date summary of Relativity’s
Disaster Recovery options:
• Relativity – Configuring Relativity After a Disaster Recovery Failover

• Installing Relativity in a Failover Cluster
We suggest that all customers conduct regular tests to ensure their Disaster Recovery plans work as
intended.
High Availability
It’s important to make sure Relativity has constant uptime, so users always have consistent access.
Multiple Servers
Use multiple servers where appropriate to help with maintaining uptime. For example, we recommend
having at least two web servers in each Relativity environment in case one fails. You can read more about
server requirements and recommendations on the System Requirements page of our Documentation Site.
Load Balancing
Relativity supports different methods of web load balancing and the ability to distribute user sessions across
multiple servers. You can read more about this in the Expanding your Relativity environment page on our
Documentation Site.

Clustering
SQL Server clustering ensures high availability and provides protection in case of hardware failure. You can
read more about this in the Expanding your Relativity environment page on our Documentation Site and the
‘Relativity – Installing Relativity in a Failover Cluster’ document in the Customer Community.
IIS Security
To harden your web servers, it’s important to consider IIS Security.
HTTP Strict Transport Security

Help to protect websites against protocol downgrade attacks and cookie hijacking. It allows web servers to
declare that web browsers (or other complying user agents) should only interact with it using secure HTTPS
connections, and never via the insecure HTTP protocol. Update the following:
1. Open IIS.
2. Select the root site labeled as Default Website
3. Select the option HTTP Response Headers
4. Choose Add and enter the following entry in the dialog prompt:
a. IIS - Name “Strict-Transport-Security”; Value “max-age=31536000; includeSubdomains”
5. Repeat the steps above for the IIS site Relativity if applicable.
X-Frame-Options
Help to protect web application against clickjacking. It instructs the browser whether the content can be
displayed within frames. The Relativity web site in IIS sets to SameOrigin by default. We require SameOrigin
on the Relativity site because some Relativity resources use iframes.
instead of HTTP. Update the following:
1. Open IIS.
a. IIS - Name “X-Frame-Options”; Value "SAMEORIGIN”
5. Repeat the steps above for the IIS site Relativity if applicable. iisreset is required for the changes to
take effect
Referrer-Policy
Governs which referrer information, sent in the Referrer header, should be included with requests made. If
misconfigured can allow information leakage about the browsing session. Update the following:
1. Open IIS.
2. Select the root site labeled as Default Website.
3. Select the option HTTP Response Headers.

a. IIS – Name “Referrer-Policy”; Value “no-referrer”.
5. Repeat the steps above for the IIS Site Relativity if applicable.
X-Content-Type-Options
Prevent browsers from interpreting files as a different MIME type to what is specified in the Content-Type
HTTP header (e.g. treating text/plan as text/css). Update the following:
1. Open IIS.
a. IIS - Name “X-Content-Type-Options”; Value “nosniff”
5. Repeat the steps above for the IIS site Relativity if applicable. iisreset is required for the changes to
take effect
X-Xss-Protection
The X-XSS-Protection header is currently deprecated and not supported by most major browsers.
Slim Down IIS Headers

HTTP response headers can show information that experienced attackers can use to infiltrate an
environment. Use the following steps to decrease the response header information for X-Power-By, X-
AspNet-Version and Server headers:
Removing X-Power-By header
1. Open IIS.
2. Navigate to the Default Website.
3. Double click on the HTTP Headers feature.
4. Select the ASP.NET X-Powered-By header.
5. Select Remove in the Actions pane.
Removing X-AspNet-Version header
1. Open the web.config file located in the C:\Program Files\kCura Corporation\Relativity\EDDS

location. Response
2. Locate the <system.web> section
In the <system.web> section

3. Add the enableVersionHeader="false" variable within the <httpRuntime> tags. See the below figure
as an
example.
Removing Server header
Follow below steps to remove Server header:
1. Open IIS Manager.
3. Double click on the HTTP Response Headers feature.
4. Select the Server header.
5. Select Remove in the Actions pane.
Repeat the steps above for the site Relativity.

If 'Server' header is not found in the HTTP Response Headers feature, follow the below steps to Rewrite the
Server header:
6. Open IIS Manager
7. Navigate to Default Web Site
8. Click on 'URL Rewrite'
9. On the right pane, double-click on 'View Server Variables...' and click 'Add'
10. Add server variable RESPONSE_SERVER
11. Click Ok
12. Navigate back to Default Web Site and again click on 'URL Rewrite'
13. On the right pane, double-click on 'Add Rule (s)..' and double-click on Blank rule under Outbound
rules

14. Edit the rule as shown below in Match section and leave others by default. Finally click 'Apply'
15. iisreset is required for the changes to take effect

NOTE: With the above steps, we created the rule for all of the applications. If there are some
applications, especially third-party applications, that may require the Server header, so you may
need to remove this rule for those applications. We suggest referencing the vendor's documentation
for how to add it if it is required.
HTTP Verbs
The following methods should be enabled to support business requirements.
• GET
• POST
• PUT
• DELETE
• PATCH
Other methods can be disabled:
• OPTIONS
• HEAD
• CONNECT
• TRACE
Disable HTTP methods:
1. Open IIS Manager.

2. Select the name of the machine to configure this globally.
3. Double click on "Request Filtering".
4. Change to the HTTP Verbs tab.
5. From the Actions pane, select "Deny Verb".
6. Insert the method that will be disabled in the Verb, and press OK to save changes.

Other methods can be used to support business requirements.
For guidance on the implementation, please review the following page on our Documentation site: here
Enable Custom Errors

The following steps will ensure no server file paths are shown to users:
1. On each web server, edit the C:\Program Files\kCura Corporation\Relativity\EDDS\web.config file.

2. Change the customError attribute to the following:
a. <customErrors mode="On" defaultRedirect="~/Error/Redirect.aspx" />
Disable Directory Browsing

Directory Browsing should be disabled so users cannot display the contents of directories in a webpage.
1. Open IIS.
3. Double click on the Directory Browsing feature.
4. Select Disable in the Actions pane.
Remove the HTMLArea Application

Relativity Web servers don’t require the HTMLArea Application/Virtual Directory.
5. Open IIS.
6. Navigate to the HTMLArea website under Default Website.
7. Right click on HTMLArea and choose Remove.

Encryption
This section details recommendations for encrypting your SQL server, file server, and virtual machine.
SQL Server
Relativity doesn't encrypt SQL data by default, so we recommend using Transparent Data Encryption (TDE)
to achieve this. Please read more about TDE in section 4 of this document.
Microsoft SQL Server can be configured to use SSL encryption to encrypt data in transit to other
applications.
Enabling the encryption is done by using the SQL Server Configuration Manager.
If you have several members of your team that use SQL Server Management Studio (SSMS) from different
locations, Microsoft also provides the ability to encrypt the connection of SSMS to the SQL Service.
For more information on SQL Server SSL encryption please click here.
Be aware that this type of encryption can slow down performance. It is recommended to
test the throughput and response time of a known workload with and without SSL
encryption.
If you are using a failover cluster for SQL, the certificate must have a fully qualified
domain name and installed on all nodes.

Please follow the instructions here if you are using this type of encryption and also using
Relativity Analytics.
File Server
Some Relativity clients have chosen to leverage vendor-specific methods for Self-Encrypting Drives (SED)
or Whole Disk Encryption (WDE). Examples of these technologies include the SED SAN, which will
automatically perform full disk encryption when a write completes, and NetApp Storage Encryption (NSE).
Web Server
We recommend securing all Relativity web traffic with HTTPS. The HTTP binding can be completely
disabled and can force all users into accessing Relativity over HTTPS by setting the CookieSecure Instance
Setting to a value of True. The web server should also be configured to only use secure encryption
techniques, cipher suites, and key exchange mechanisms. Accomplish this by using the IIS Crypto tool.
Please refer to section 6.1 Recommended IIS Crypto Settings in the Appendix. For a more in-depth
description of TLS and its setup in Relativity, please refer to section 5 TLS Setup in Relativity in this
document.
Analytics Server
Relativity requires a trusted certificate for all HTTPS traffic on the Analytics server unless the Instance
Setting IgnoreCertificateErrors is set to False. When the CAAT service installs for the first time, however, it
runs over an untrusted SSL/TLS certificate. You can find the steps for replacing this certificate on
the Upgrading or installing your Analytics server page on the Documentation Site.
It’s also important to disable unsafe protocols and cipher suites that may be used by the CAAT service.
Follow these instructions to do this:
1. Open C:\CAAT\jetty\etc\jetty-ssl.xml on the Analytics server.

2. Insert the <Setname="ExcludeProtocols"> element in the config file as shown below.
In the image below, TLSv1 and TLSv1.1 are in the ExcludeProtocols tag because they are considered
unsafe and outdated.
Relativity supports the following TLS 1.2 cipher suites:
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Conversion Agent/Service Bus Server

Please note the Windows service bus for message broker is officially end of life and no longer receiving
security updates. Due to this, it is highly recommended to upgrade to RabbitMQ. See Upgrading your
Relativity service bus. Below only applies to the Windows service bus.
A certificate for TLS is required by Microsoft when Windows Service Bus is first installed. Find more
information on the certificate requirements for Service Bus in the Service Bus for Windows Server section of
the Pre-Installation page on the Documentation Site.
Ensure version of Service Bus listed below is installed to enable TLS 1.2.
Service Host Manager Service

Find instructions for securing Service Host Manger service traffic on the Service Host Manager page on the
Documentation Site.
Network Firewall
The following section covers properly locking down unused ports, taking a baseline, creating a DMZ, and
disable the server message block protocol.
Lock Down Unused Ports

Find a copy of the most recent Relativity Ports Diagram in the Relativity Community. Unused ports on all
Relativity servers should be locked down.
Take a Network Baseline

Measure and log the performance and activity of your Relativity network regularly to keep a baseline. This
information can be used to diagnose unusual behavior or assist your organization in determining when to
upgrade parts of the network.
Use a Firewall to Create a DMZ

If your Relativity environment is accessible by the internet, we recommend setting up a DMZ (Demilitarized
Zone) that uses a firewall to separate your internal network from your internet-facing network.
Disable the SMBv1 Protocol on all Servers

The SMB (Server Message Block) protocol is for network sharing in Microsoft systems. SMBv1 should be
disabled because it’s vulnerable to remote code execution.

Data Grid Security
The Data Grid data store relies on Elasticsearch as its underlying architecture. Please refer to this blog
post on Elasticsearch security.
RabbitMQ Security
RabbitMQ is an alternative message broker to Service Bus for Windows Server. We recommend deleting
the guest user after installation of RabbitMQ. This can be done through the following steps.
1. Log in to the RabbitMQ server.

2. Open a browser and navigate to http://localhost:15672/.
3. Log In with an admin account that is not the guest account.
4. Click the Admin tab at the top of the page.
5. Select the guest user from the Users dropdown.
6. Click the Delete User button at the bottom of the page.
7. Accept the confirmation that the user should be deleted.
Using Antivirus on Relativity Servers

You may run antivirus software on Relativity servers, but keep the following in mind:
Exclusions
Antivirus runs on Relativity servers should be configured to exclude specific programs and directories, so it
doesn’t interfere with Relativity. A list of these exclusions can be found on the Configuring the Windows
Server page on the Documentation site.
Scan all New Relativity Data

All new data should be scanned by Antivirus software before being imported into Relativity or placed on a
Relativity server. This scanned data includes load files, Processing Source Location files, Natives/Images,
etc.
Server Access Control

We recommend that each organization limit access on their Relativity Servers to those who absolutely need
it.
Relativity Servers
The only Windows accounts necessary for Relativity to function are the Local Administrator Relativity
Service Account and a Local Administrator account on each SQL Server to run the SQL Services. Your
organization should decide what other accounts are necessary and try to limit access as much as possible.
SQL Servers
The only SQL Server accounts necessary for Relativity to function are the System Admin account, the
EDDSDBO account, the RelativityScriptLogin account, and an ARM system admin account if installing the
ARM application. Your organization should decide what other accounts are necessary and try to limit access

as much as possible. Also, make sure to change the default password of the original out-of-the-box SA
account.
Microsoft Windows and Relativity upgrades

We recommend staying up to date with Microsoft Windows updates and Relativity upgrades to take
advantage of security patches and bug fixes. Find Relativity updates in the Relativity Community.
Ensure you have the latest Microsoft Windows Server and .NET Service Pack (for .NET 4.6.2) installed on
all Relativity servers. Install any smaller security patches, Windows updates, etc. at your discretion.
Relativity only tests major service packs, but not every Microsoft update. Deploy any updates to your test
instance of Relativity first and ensure that a rollback plan is in place if any issues arise during deployment.
Ensure the option to Install updates automatically on all Relativity servers has been
disabled. Apply any required updates during a planned maintenance window.
Relativity Secret Store

In Relativity 9.6, we introduced Relativity Secret Store. The Secret Store is a required component that
provides secure, auditable storage for Relativity secrets. For more information about Relativity Secret Store,
please see the Secret Store documentation on our Documentation site.
To ensure Secret Store is used securely, follow best practices listed below:
1. Install Secret Store on its own machine

a. Secret Store’s memory contains sensitive information. Running it alongside other software
increases the risk that the sensitive information will be read by a rogue process.
2. Do not save the unseal key beside the Secret Store.
a. Storing the unseal key next to the secret store is like leaving your keys in the lock at home.
b. Instead, store the unseal key in a secure location:
i. A Secret Management solution (like Thycotic Secret Store, Azure Key Vault, or AWS
Key Management Service).
ii. On disk on a server that is left powered off when not in use.
iii. Printed out on paper and left in a safe.
3. Disable PowerShell command history when unsealing Secret Store.
a. If you don’t disable command history, then PowerShell will save the unseal key in the
command history file when unsealing Secret Store.
b. To disable this feature, run `Set-PSReadlineOption -HistorySaveStyle SaveNothing`
c. You must run this at the start of every PowerShell session.
4. Back up your Secret Store database.
a. While the contents of the Secret Store database are not vulnerable to disclosure, they are
vulnerable to deletion. Back up the database to eliminate this risk.
5. Visualization for the Secret Store key hierarchy:

OutsideIn
We recommend implementing the hardening steps described below to mitigate the possibility of remote code
execution.
Running OutsideIn process as non-privileged Windows user
1. Create a non-privileged windows user with restricted permissions as described here.
2. In Relativity Create instance settings ViewerFactoryWindowsUserId and

ViewerFactoryWindowsPassword with the following value (Instance setting documentation is here.):
i. ViewerFactoryWindowsUserId:
1. Name: ViewerFactoryWindowsUserId
2. Section: outsidein.api
3. Value Type: Text
4. Encrypt: Yes
5. Value: <Your windows username from Step 1>
ii. ViewerFactoryWindowsPassword:
1. Name: ViewerFactoryWindowsPassword
2. Section: outsidein.api
3. Value Type: Text

4. Encrypt: Yes
5. Value: <Your windows password from Step 1>

3. For Invariant, set RESTRICTEDUSERNAME and RESTRICTEDUSERPASSWORD in
invariantResponse.txt as described here.
Note: Conversion Agent uses Windows service account in Relativity Server 2021. Starting with Relativity
Server 2022, Conversion Agent will be using restricted user as configured above.
We recommend implementing monitoring for unusual processes started by the Relativity Service account
and non-privileged Windows users.
Relativity Front-end Configuration

This section details recommendations to secure the front-end of a Relativity environment.
Change Default Relativity Administrator Passwords

By default, Relativity installs with two accounts that have administrator access. These
are Relativity.Admin@relativity.com and Relativity.ServiceAccount@relativity.com. Change the default
passwords for both accounts, but DO NOT change the email address or username associated with these
accounts. Also, DO NOT delete these accounts.
Configure Instance Settings

In Relativity, Instance Settings are used to control the configuration of Relativity and controlled by an
Administrator in the Instance Settings tab. Configure several Instance Settings in Relativity with the
following values for optimal security:
AuditingEnabled
Summary - This setting controls enabling auditing throughout Relativity. Setting this value to True enables
auditing. Setting this value to False disables auditing.
Recommendation - Set the value to TRUE.
Reasoning - Keeping detailed logs of all actions that take place in Relativity can protect your organization if
there is ever a need to troubleshoot an issue, investigate the actions of a particular user, etc.
CookieSecure
Summary - This setting controls how the web browser sends session information. If set to True, this
instance setting forces a web browser to send session information over HTTPS only. This flag is designed to
attach to sensitive cookies such as the session cookie ASP.NET_SessionId. When set to True, users cannot
log in to Relativity over HTTP.
Reasoning - If this setting is enabled, cookies, including sessions cookies, are encrypted over a secure
SSL/TLS channel instead of being sent in cleartext. Once set to TRUE, users must always access Relativity
over HTTPS instead of HTTP.

CookieHTTPOnly
Summary - This setting controls access to cookies. If set to True, this instance setting prevents access to
cookies by JavaScript and other client-side elements. This flag is designed to attach to sensitive cookies
such as the session cookie ASP.NET_SessionId.
Recommendation - Set the value to TRUE unless you plan to use Windows Media Player to review media
files.
Reasoning - This prevents Relativity cookies from being susceptible to theft by cross-site scripting by
setting the HttpOnly flag on the cookies.
CookieDuration
Summary - This setting sets the number of minutes that the authentication cookie is valid. This value
controls the length of time that the users are logged in to Relativity before the system automatically logs
them off and requires them to re-authenticate. This configuration value supports a maximum setting of 1440
minutes (or 24 hours), and a minimum setting of 240 (or 4 hours). You must reset IIS for these changes to
take effect.
Recommendation - Default unless your organization wants to further limit the amount of time one user’s
Relativity session will last.
Reasoning - Limiting this value decreases the chance an attacker could compromise the authentication
cookie.
EnforceHTTPS
Summary - This setting controls how Relativity Service Host handles HTTP/HTTPS traffic. Values include
On, Off, and Warn. If set to On, this instance setting forces Service Host to use HTTPS only. If set to Off,
HTTP traffic is allowed. If Warn, the browser and all API endpoints will allow any traffic but will log a warning.
The default value is Warn.
Recommendation - Set the value to ON. Make sure to add a certificate to the Personal certificate store of
the Computer Account on all web and agent servers. If the certificate is self-signed, you must add it to both
the Personal and the Trusted Root Certification Authorities certificate stores for the Computer Account on all
web and agent servers. It is also a requirement that you edit the value of the KeplerServicesUri instance
setting and the KeplerServicesUriForAgents instance setting to reflect HTTPS. These instance settings are
detailed later in this document. For more information about setting up Relativity Service Host, please see
the Service Host Manager documentation on our Documentation site.
Reasoning - This requires Service Host traffic to be encrypted with SSL/TLS in order to not send in
cleartext.
KeplerServicesUri
Summary - This setting specifies the URL at which Relativity custom pages and event handlers can access
the Services API Kepler services using API helpers. The URL must end in a forward slash.
Recommendation - Change the link so it says ‘https’ instead of ‘http’.
Example:
http://localhost/Relativity.Rest/API/ becomes https://localhost/Relativity.Rest/API/

Reasoning - We recommend that EnforceHTTPS is set to True, this value needs to be updated so it has
HTTPS instead of HTTP.
KeplerServicesUriForAgents
Summary - This setting specifies the URL at which Relativity agents can access local Services API Kepler
services using API helpers. The default port number (8990) can be changed if there is a port conflict with
some other server application. Secure connections are not supported at this time, but Relativity doesn't
secure connections at this time, but normal Relativity authentication protects the services.
Recommendation - Change the link so it says ‘https’ instead of ‘http’.
Example:
http://127.0.0.1:8990/Kepler becomes https://127.0.0.1:8990/Kepler
Reasoning - We recommend setting EnforceHTTPS to True, this value needs to be updated so it has
HTTPS instead of HTTP.
ApplicationRestrictedFileTypes
Summary - This setting contains a semicolon-delimited list of file extensions (including dots) indicating file
types that users are prohibited from uploading as custom pages or resource files. Examples
include: .exe, .com, and .bat.
Recommendation - Use the default values plus any other file extensions your organization deems
necessary.
Reasoning - Add any file extensions to the list that your organization deems unsafe.
RestrictedFileTypes
Summary - This setting contains a semicolon-delimited list of file extensions, including dots, that prohibits
users from uploading to file fields (excluding Custom Pages). For example: .exe;.html
necessary.
Reasoning - Certain types of files could contain malicious scripts.
RestrictedNativeFileTypes
Summary - This setting contains a semicolon-delimited list of file types that prohibits users from uploading
to file fields (excluding Custom Pages). These values are regular expression enabled, so custom validation
behavior is also supported.
necessary.
Reasoning - Certain types of files could contain malicious scripts.

ShowStackTraceOnError
Summary - This setting controls whether full stack traces appear to users when an error occurs. If set to
True, full stack traces appear to users when an error occurs. If set to False, full stack traces don't appear to
users when an error occurs.
Recommendation - Set the value to FALSE unless you want all users with access to the Errors tab to see
full stack traces for errors. Set to TRUE for active troubleshooting situations.
Reasoning - It is more secure to hide the details of error messages, so users cannot see more information
than is necessary. Without hiding this information, software and server details could be revealed.
MOTDTextOnly
Summary - This setting controls how the Message of the Day (MOTD) is entered and displayed when a
user logs into Relativity. If set to True, the MOTD can only be entered and displayed as plain text. If set to
False, the MOTD can be entered and displayed using the full HTML editor.
Recommendation - Set the value to TRUE unless you want the ability to use JavaScript in this field.
Reasoning - By only allowing text in the Message of the Day box, cross-site scripting and cross-frame
scripting can be prevented.
SanitizeHTMLOutput
Summary - This setting controls sanitization fields with HTML on page render. If set to True, fields with
HTML are sanitized. If set to False, fields with HTML aren't sanitized.
Reasoning - All HTML input will be validated to prevent cross-site scripting and other types of malicious
attacks.
HTMLSanitizerWhitelist
Summary - This setting specifies strips all JavaScript. Strips HTML attributes that do not meet the approved
HTML markup. Setting the SanitizeHTMLOutput instance setting’s value to True invokes the
HTMLSantizierWhitelist. Recommendation - Remove more HTML markup from the list as necessary with
the assistance of Relativity Support. Contact support for help via
https://community.relativity.com/s/contactsupport .
Reasoning - Remove any HTML markup from the list that your organization doesn’t want users to use in
HTML fields.
TreatHtmlAndXmlAsText
Summary - This setting controls the content-type header returned by files with HTM or HTML extensions
from Relativity.Distributed. If set to True, the content-type is text/plain. If set to False, the content-type is
text/html. The default value is True. The net effect of setting this to True is that the Native radio button in the
review tool displays the raw markup of HTML files instead of rendering the content.

Reasoning - Setting this value to true can help prevent malicious code from executing when a Native
document is viewed in the Viewer because it’s not automatically rendered. The content of the content-type
header for the native files is unknown and, therefore, untrusted.
AllowHtmlVisible
Summary - This setting controls the accessibility of the Allow HTML property on Field objects. If set to
False, the Allow HTML property is hidden from the New Field page, and its value defaults to No. The Edit
Field page displays the property only if the field being edited already has the property's value set to Yes. If
set to True, there is unrestricted access to the Allow HTML field property.
Recommendation - Set this value to FALSE.
Reasoning - This prevents administrators from allowing HTML as inputs into fields. By doing this, attackers
cannot input malicious HTML or scripts.
IgnoreCertificateErrors
Summary - This setting determines whether Relativity must validate the chain of trust of certificates when
running over HTTPs. Setting the value to True is a security vulnerability and should only be done in testing
environments. Recommended value is False.
Recommendation - Set the value to FALSE.
Reasoning - It is not secure to ignore certificate errors in Relativity.
MaximumPasswordAgeDefault
Summary - This setting determines the default value for the maximum password age when creating
password authentication providers.
Recommendation - Set this value to a number greater than zero so users are encouraged to change their
passwords after a certain number of days.
Reasoning - Password rotation can protect Relativity against passwords that may have been
compromised.
MaximumPasswordHistory
Summary - This setting determines how many password changes Relativity examines for duplicate
passwords. Setting this to a large value could prevent a user from ever using the same password twice.
Recommendation - Determine if your organization wants to limit users from reusing the same passwords
they have used in the past.
Reasoning - This can protect the Relativity environment from a previously compromised password.
AllowAddOrEditScripts
Summary - This setting determines whether create/edit is enabled for Relativity Scripts. The recommended
setting is False.

Reasoning - Setting this to false limits the number of users who can create and edit Relativity scripts.
Running a badly written script could potentially affect the entire site.
DeveloperMode
Summary - This setting controls developer mode options within an instance of Relativity. Setting this value
to True enables developer mode options. Setting this value to False disables developer mode options.
These options include disabling the cross-site request forgery (CSRF) header requirement in the API and
returning detailed error messages such as stack traces. Enable this setting only in a development
environment.
Reasoning - Setting this value to false will cause Relativity to enforce the cross-site request forgery (CSRF)
header requirement in the API and stop sending detailed error messages like stack traces.
AdminsCanSetPasswords
Summary - This setting sets the system admin's ability to create passwords for users. If True, they can
create the password. If False, they can't. You must manually create this instance setting because of it not
being installed by default.
Reasoning - This means only the user knows his or her password.
ReplaceCaseNameWithArtifactID
Summary - This setting controls whether the Case ArtifactID replaces the Case Name in the billing statistics
report. If set to True, the Application ArtifactID replaces the Application Name in the billing statistics scripts.
By default, the value is set to False, and the Case Name is displayed.
Reasoning - The case name reveals less information about the design of the software.
ReplaceApplicationNameWithArtifactID
Summary - This setting controls if the Applications ArtificatID replaces the Application Name in the billing
statistics report. If set to True, the Application ArtifactID replaces the Application Name in the billing statistics
scripts. By default, the value is set to False, and the Application Name is displayed.
Reasoning - The application name reveals less information about the design of the software.
AdditionalWorkFactorDefault
Summary - This setting sets the default value for the AdditionalWorkFactor setting in the Authentication
Provider Settings section of the Authentication Provider tab. It allows you to control the number of encryption
hashes. Relativity already provides several built-in hash levels represented by the default zero value.
Changing this value to 1, 2, or 3 adds additional encryption protection but may significantly increase login
time.

Recommendation - Use the default setting unless your organization decides more hashing is necessary.
Reasoning - More hashing means better encryption, but increasing this value should be tested prior to
making the change in Production in case it increases login times.
MaximumAdditionalWorkFactorRestriction
Summary - This setting sets the maximum additional work factor that can be selected for the Password
Provider on the Authentication Provider Settings section of the Authentication Provider tab. It allows you to
control the max number of encryption hashes. Relativity already provides several built-in hash levels
represented by the default zero value. Changing this value to 1, 2, or 3 adds additional encryption protection
but may significantly increase login time.
Recommendation - Use the default setting unless your organization decides more hashing is necessary.
Reasoning - More hashing means better encryption, but increasing this value should be tested prior to
making the change in Production in case it increases login times.
MaxInvalidLoginAttemptsDefault
Summary - This setting determines the maximum number of login attempts a user can make with a given
username before Relativity locks that username.
Recommendation - Your organization should limit the number of login attempts that users have for
accessing Relativity.
Reasoning - It is more secure to have fewer attempts allowed, but too few attempts can be inconvenient for
users who forget their passwords.
PasswordResetEmailExpirationInMinutes
Summary - This setting defines how long (in minutes) password reset links remain valid after the email is
sent. Please note that it doesn’t affect links that have already been sent.
Recommendation - Your organization should limit the time the password reset link remains valid.
Reasoning - The longer the link remains active, the more risk it will be compromised by an attacker.

AccessTokenExtraLifetime
Summary - This setting determines the number of additional minutes the authentication token remains valid
after the authentication cookie has expired. Because this token has a longer lifetime than a session cookie,
you can use it to access Relativity APIs, which may execute long-running processes requiring tokens. This
instance setting supports a maximum value of 600 minutes (or 10 hours) and a minimum value of 240
minutes. You must reset the IIS for these changes to take effect.
Recommendation - Use the default setting.
Reasoning - It is more secure to limit the life of this token.
InvitationLinkLifetimeInMin
Summary - This setting determines the number of minutes the link sent in the Invitation Email remains
valid.
Recommendation - Determine how much time your organization is comfortable having links remain valid
before sending a new email.
Reasoning - The longer the link remains viable, the more chance it could be compromised.
ReplaceUserNameWithHashValue
Summary - This setting controls whether Relativity replaces the username portions of user email addresses
with hash values in billing information sent manually or sent automatically through the SMTP server. If set to
True, Relativity replaces all text preceding the @ symbol in each user email address with a unique hash
value. Domains remain unencrypted. If set to False, entire user email addresses appear. If you manually run
the billing script, the value you select in the interface overrides this instance setting.
Reasoning - This will hide the usernames and case names in Billing Data sent through the SMTP server.
ExportEscapedFormulasFromItemListDefault
Summary - This setting controls whether Excel macro syntax starting with the characters, [@=+-$], are
escaped. If set to Yes, Excel macro syntax starting characters, [@=+-$], are escaped. If set to No, Excel
macro syntax starting with the characters, [@=+-$], are not escaped.
Recommendation - Set the value to YES.
Reasoning - This will ensure Excel macro syntax starting with [@=+-$] are always escaped.
SMTPSSLisRequired
Summary - If set to True, this instance setting forces all SMTP communication over SSL.
Reasoning - This will ensure SMTP server sends encrypted emails.

RestrictReferentialFileLinksOnImport
Summary - Controls whether non-system administrators can import documents, objects, images, and
productions using referential links for files already in a valid, Relativity-accessible location. When set to True,
non-system administrators can import only by uploading files. When set to False, all users can import using
referential links.
Reasoning - This ensures users cannot import files from workspaces they have no access to another.
Configure Instance and Workspace Security

You can manage varying levels of security for users, system admins, and individual objects such as views,
tabs, and fields, across your instance of Relativity and in each workspace. You can quickly edit security for
several users simultaneously by assigning permissions at the group level. After configuring a group's access
permissions, you can preview the effective security rights by impersonating a general member of the group
or a specific user in your environment. Read more about this on the Security and Permissions page of our
Documentation site.
Configure Authentication
Relativity uses several industry-standard technologies that enable versatile authentication options. It
supports local (such as password related) or external (such as smart card, or external identification provider)
authentication methods. You can add and enable each type individually and assign multiple authentication
methods to each user. Find more information about our supported forms of authentication in
our Authentication documentation on the Documentation site.
Transparent Data Encryption (TDE)

Introduction
Transparent Data Encryption (TDE) is a form of database encryption that is supported by SQL Server 2008
R2 Enterprise edition and higher.
TDE is used to encrypt and decrypt the operations of SQL data and log files. A Database Encryption Key
(DEK) is used to encrypt and decrypt the data. The SQL server creates a certificate, and this certificate
signs the DEK. TDE allows developers to encrypt data using AES or 3DES encryption algorithms.
Ensure the proper SQL database backups are in place prior to moving forward with this procedure.
Transparent Data Encryption Architecture

See section 6.2 Transparent Data Encryption (TDE) Architecture for a diagram of the TDE architecture. You
can also read more about it here.
Considerations before enabling TDE

Only experienced SQL users should execute the procedure. Be sure you understand how Transparent Data
Encryption (TDE) works and how it will affect your environment before you enable it.

Consider database backup compression when using TDE. There is a high possibility that, when using TDE
and performing database backup compression, the size of the backup might not be reduced.
A database encrypted with TDE may see increases in the time it takes to compress backups and CPU
utilization with no guaranteed reduction in database size. Read more about his here.
Please note that databases enabled for Transparent Data Encryption (TDE) cannot take advantage of
Instant File Initialization, therefore, databases enabled for TDE should be set to auto-grow by 4096MB
instead of the default 10%. This is because large databases need to auto-grow by 10% without taking
advantage of Instant File Initialization. Leaving the default value can result in application timeouts during
each auto-grow.
Backups and backup plans of the databases that have Transparent Data Encryption
(TDE) enabled must be handled with caution to avoid corrupting the database.
When enabling TDE on a database, you must first back up the database before TDE is disabled on that
database. Otherwise, there is a chance of corruption. You cannot restore a backup of a database on another
instance of SQL Server if you disable TDE before you create the backup in SQL Server.
To create a case on a distributed SQL server or migrate a case that has TDE enabled, you must first disable
TDE on the database or transfer the security certificate used for the encryption from the server on which
TDE was enabled to the target SQL server on which the case is to be created.
Refer to the following MSDN article linked here.
Enabling SQL Server Transparent Data Encryption (TDE) on the Primary

SQL Server
This section contains recommendations on creating and backing up a master key and certificate.
Create Master Key

The server master key is created to protect the private keys for the certificate. The private key and certificate
are created later in this document. The master key is encrypted using AES_256 and a user password.
-- Symmetric key information

Select * from sys.symmetric_keys
-- Create server master key
USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'EnterPasswordHere';
Go
Create Certificate
The certificate secures the databases. A certificate can be loaded from a file or assembly. This statement
can generate a key pair and a self-signed certificate.
--Create certificate which is protected by the master key

CREATE CERTIFICATE RelativityTDE WITH SUBJECT = 'Relativity DEK certificate';
go
-- View the certificate

Select * from sys.certificates
where name = 'RelativityTDE' --Subject Name
Backup the Certificate and the Private Key

The certificate, the private key, and the master key must be backed up immediately after after their creation.
If the private key and the certificate have been misplaced or have become unavailable, there will be no way
to open the database when restoring or attaching to a different server.
Store these certificates or private key backups even if Transparent Data Encryption is not enabled. The
previously encrypted database may still have some needed information from the certificate and the key for
some operations.
The file must be encrypted if the private key is to be backed up to a file.
The password that is used for the certificate backup is not the same password used to
encrypt the private key of the certificate.
--This is to open the master key, in case the certificate is locked because it
was not backed up when created
Open Master Key Decryption by Password = 'EnterPasswordHere'
-- Backup the certificate.
Backup Certificate RelativityTDE to File = '\\Path\Path\BackupFileName.bak'
With private key (
File = '\\Path\Path\ BackupFileName.pkbak',
Encryption by password = 'EnterPasswordHere')
go
When encryption is enabled on a database, that database must first be backed up before
encryption is to be removed. If TDE is enabled on a database and then disabled on that
same database before the database is backed up, there is a chance of corruption on the
database.
A certificate that has expired can still be used to encrypt and decrypt databases.
Encrypt the Database

Database encryption is done at the database page level. Pages are encrypted prior to writes to disk and are
encrypted again when read into RAM.
-- Select the database that you are planning to encrypt.

Use EDDS#######
Go
-- A database encryption key is required before a database can be encrypted.
This key is protected by the certificate.
Create Database Encryption Key
/*AES is specified with block and key size that may be any multiple of 32
bits, both with a minimum of 128 and a maximum of 256 bits.
The Advanced Encryption Standard (AES) is a specification for the encryption
of electronic data established by the U.S. National Institute of Standards and
Technology (NIST) in 2002.

In the United States, AES was announced by the NIST as U.S. FIPS PUB 197 (FIPS
197) on November 26, 2001.*/
With Algorithm = AES_128
Encryption by Server Certificate RelativityTDE
Go
--Enable TDE on database
Use Master
Alter Database EDDS#######
Set Encryption On
--Check database to verify encryption. Value should be 1.
Select name, is_encrypted from sys.databases where name = 'EDDS#######'
Go
Consider database backup compression when using TDE. There is a high possibility that,
when using TDE and performing database backup compression, the size of the backup
might not be reduced.
A database encrypted with TDE may see increases in the time it takes to compress
backups and CPU utilization with no guaranteed reduction in database size.
Backup the Database

Create a database backup after enabling encryption on the database. After enabling TDE on a database,
you must backup that database before disabling TDE to avoid corruption.
You cannot restore a backup of a database on another instance of SQL Server if you disable TDE before
creating the backup.
Backup files of databases that have TDE enabled are also encrypted using the database encryption key. As
a result, when you restore these backups, the certificate protecting the database encryption key must be
available. This means that in addition to backing up the database, you must make sure that you maintain
backups of the server certificates to prevent data loss.
Enabling SQL Server Transparent Data Encryption (TDE) on the Distributed

SQL Server
To create a workspace on a distributed server using a template that has TDE enabled, the TDE certificate
from the source SQL server must be transferred to the distributed SQL server.
Create Master Key

The server master key is created to protect the private keys for the certificate. The private key and certificate
are created later in this document. The master key is encrypted using AES_256 and a user password.
-- Symmetric key information

Select * from sys.symmetric_keys
-- Create server master key
USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'EnterPasswordhere';
Go

Transfer the Certificate from the Source SQL Server
This is the certificate and private key that were backed up in step 4.2.3.
The databases being migrated must use the certificate created on the server where they were encrypted in
order for the SQL server to decrypt the databases.
--This will transfer the certificate from the Source SQL server. The source
SQL server is the primary SQL server where the database that is being restored
was originally encrypted.
Create Certificate RelativityTDE
From File = '\\KIE01\TDE Certificate\TDEcertificate.bak'
With Private Key (
File = '\\KIE01\TDE Certificate\TDEcertificate.pkbak',
Decryption by Password = 'Relativity1!')
Go
Disable Encryption on a Database

The following content will assist in disabling Transparent Data Encryption (TDE).
When encryption is enabled on a database, that database must first be backed up before
encryption is removed. If TDE is enabled on a database and then disabled on that same
database before the database is backed up, there is a chance of corruption on the
database.
Disable Encryption
First encryption must be removed from the database before removing the encryption key.
When decrypting the database, it is important to wait for the decryption to complete before removing the
database encryption key.
--This will return information about the database encryption.

select * from sys.dm_database_encryption_keys
/*
Please see below for encryption states.
0 = No database encryption key present, no encryption
1 = Unencrypted
2 = Encryption in progress
3 = Encrypted
4 = Key change in progress
5 = Decryption in progress
6 = Protection change in progress (The certificate or asymmetric key that is encrypting
the database encryption key is being changed.)
*/
--Remove encryption from the target database
Use master
Go
ALTER DATABASE EDDS1405441 SET ENCRYPTION OFF
Go

Drop the Encryption Key
This will assist with dropping a database encryption key used in TDE.
--Drop the encryption key from the target database

Use EDDS1405441
Go
Drop database encryption key
Go
--Check database to verify that it is not encrypted
SELECT name, is_encrypted
FROM sys.databases
Where name = 'EDDS1405441'
Go

Remove Encryption Certificates and the Master Key
The following section will assist in removing certificates and the master key.
Check the Certificates on the SQL Server

The following query will show the certificates on the SQL server.
--Check the system certificates to choose the certificate to delete

SELECT name, pvt_key_encryption_type_desc
FROM sys.certificates
Drop the Certificate

Certificates can only be dropped if no entities are associated with them.
--Drop the choosen certificate

Drop Certificate RelativityTDE
Go
Drop the Master Key

If desired, you can drop the master key.
--You have the option of dropping the master key is it is not required for any
other certificate or database
Drop Master Key
Go
TLS Setup in Relativity

How TLS Works
Overview
TLS is used when a client machine wants to securely communicate with a server. The type of
communication does not matter because TLS can be used with any TCP-based protocol such as web traffic,
e-mail, and VPN. The TLS protocol provides three important protections for the conversation between client
and server:
• Authentication - The client knows it is communicating with the intended server.

• Privacy - The communication stream can only be read by the client and the server.
• Message Integrity - The client and server know that messages have not been altered by a third party
during transit.
These protections are enabled using X.509 Certificates.
Certificates
A certificate is a cryptographic document that contains metadata about an entity. Although there are different
types of entities in the X.509 world, this discussion will focus on network services such as a web server. The

certificate contains metadata about a server that allows a client (such as a browser) to communicate
securely with that server.
X.509 certificates are complex documents with many different attributes. Fortunately, there are a few key
attributes to focus on:
• Subject - The domain name(s) the certificate can protect.

• Issuer - The Certificate Authority that issued the certificate.
• Public Key - The cryptographic public key that enables secure communication.
• Key Algorithm - The algorithm used for the public key.
• Validity Dates - The date range over which this certificate is valid.
Certificates rely on the concept of public/private key pairs. When a certificate is generated, two keys are
created. These keys are mathematically related, which allows them to be used for encryption protocols. The
public key becomes part of the certificate and is shared publicly. Thus, X.509 Certificates are public
documents that can be shared freely. The private key is kept on the server and is never shared with
anyone.
Each certificate must specify the subject or the list of DNS hostnames for which the certificate is valid. There
are several ways to specify the subject: a single domain name (www.relativity.com), NetBIOS name
(server01), multiple domain names (www.relativity.com, relativity.com), or using a wildcard (*.relativity.com).
Wildcard certificates are a popular option to protect multiple subdomains with a single certificate.
A Certificate must have an Issuer, which is the Certificate Authority that vouches for the certificate. The
Certificate Authority (CA) digitally signs the server certificate and the client validates that signature. This
establishes a chain of trust between the server, the client, and the Certificate Authority. The client only trusts
a specific list of CAs and the CA vouches for the server's certificate; through the chain of trust, the client will
then trust the server's certificate.
There are well-known Certificate Authorities such as Digicert and Lets Encrypt. These companies issue
certificates for publicly accessible websites. Administrators can also maintain an internal CA for use in
private networks.
Most people are familiar with the "Untrusted Certificate" message in web browsers. For a client (such as a
web browser) to trust a server certificate, several validation checks are performed including:
• Does the certificate subject match the server host name?

• Is the certificate within the specified date range?
• Is the certificate signed by a trusted Certificate Authority (based on the list of trusted CAs on this client)?
If any of these validation checks fail, the TLS connection is aborted. There are ways to ignore certificate
validation errors, but, as a best practice, Relativity does not ignore these errors. Therefore, it is important
that all certificates used in Relativity contain the proper subject and validity dates and are signed by a
trusted CA.
Once the client validates the server's certificate, a secure connection is negotiated. The client uses the
server's public key to send an encrypted message to the server. The server then decrypts the message
using its private key. This is an oversimplification because the TLS handshake contains many different steps
that are beyond the scope of this document, but the concept holds true. The public and private keys allow
the server and client to exchange private messages and negotiate a secure connection over an insecure
network such as the internet. After establishing the TLS session, the main data transfer can proceed.

When to Use TLS
TLS must be used when communicating over an untrusted network. The definition of a trusted network
depends on the security policy for the organization. There are, however, some absolutes and guidelines on
how to define this term.
Communication between the end user's browser and the Relativity web server is the most critical area to
secure. If your Relativity instance is exposed directly to the internet, meaning any public host can reach the
Relativity login page, then TLS is mandatory. Failure to secure internet-facing traffic will put an organization
at high risk for a security breach.
Even if Relativity is not exposed to the internet, we recommend that traffic between the browser and the web
server be secured via TLS. The Relativity authentication system requires TLS to provide security for the
login page. Therefore, TLS is appropriate and strongly recommended for corporate networks.
Once the traffic between the browser and the Relativity web server is secured, an organization has to decide
if the Relativity back-end must be secured. Some organizations consider the Relativity back-end to be a
trusted network, which means that TLS is not required. For this strategy to work, all back-end servers must
reside behind a firewall. The only network service that should be exposed through the firewall is the
Relativity web server; all back-end traffic should be blocked off. This approach limits Relativity's attack
surface from outside the firewall.
Increasingly, companies take the perspective that all networks are fundamentally untrusted. In this model,
security threats are expected to come not just from the outside but also from within the network. Attacks can
originate from another machine on the network that is compromised or from a malicious employee. Because
the internal network is considered untrusted, all front-end and back-end traffic must be secured. This
security model takes significantly more effort to maintain for an organization’s IT personnel. However, the
benefit is increased security at all layers of the infrastructure.
Ultimately, organizations need to decide about their security policy. The decision should be approached
thoughtfully based on these guidelines:
• Always secure public internet traffic with TLS. This is not optional.
• Strongly consider TLS for internal corporate networks.
• Based on your company's security policy and comfort level with TLS, consider securing Relativity's back-
end traffic as well.
TLS Deployment Scenarios – Supported Topologies

Because Relativity supports a range of deployment scenarios, there is no single set of instructions for
configuring TLS. An administrator must first identify the target topology for the Relativity environment. The
topology will determine the specific steps needed to configure TLS.
Relativity administrators must ultimately choose the appropriate security model for their organization. Many
factors influence this decision including network topology, organizational policy, and desire to maintain a
certificate infrastructure.
Private Network (no TLS)

The Private Network represents any Relativity installation where TLS is not used to protect the network
traffic. All communication happens in the clear which means all front-end and back-end traffic can be
inspected and modified. In this scenario the network is considered trusted, eliminating the need for securing

the Relativity network traffic. Note that the internet is fundamentally untrusted, so this topology only applies
to Relativity instances that are not exposed to the internet.
Private Networks do not require any X.509 certificates, except for the Service Bus certificate discussed
earlier. Common use cases include test and development instances of Relativity as well as completely
disconnected from the internet, air-gapped networks. This topology is the simplest to configure, but it
provides no network-level security.
Front-end TLS
The Front-end TLS topology divides the architecture into two zones: trusted and untrusted. All traffic flowing
through an untrusted zone is encrypted using TLS.
The Relativity web servers straddle both zones. All front-end traffic to IIS is encrypted with TLS. Traffic to
Relativity back-end servers is not encrypted. The Relativity back-end is maintained by the administrator and
is typically protected by a firewall that puts it into the trusted zone.
Front-end TLS networks require a single certificate to be installed on every web server. If Relativity is
exposed to the internet, the certificate should be requested from a well-known certificate provider such as
Verisign. Self-signed certificates that are not trusted by the browser are not recommended.

This configuration is appropriate for smaller Relativity networks that need to communicate over an untrusted
network such as the internet. If there are multiple web servers, perform all load balancing via the Relativity
User Load Balancing feature (this is because each user must stay on the same server for the duration of
their login session). Because of the load balancing limitation, this topology is typically reserved for smaller
Relativity instances.
TLS Offloading at Load Balancer

A common strategy is to modify the Front-end TLS topology by introducing a load balancer. The load
balancer communicates with the browser over TLS, and the request is forwarded to the Relativity web server
over unencrypted HTTP. In this topology the Relativity web server is considered part of the trusted network
and the load balancer straddles both the trusted and untrusted network.

TLS Termination is common in production environments and provides several benefits over the Front-end
TLS approach. Front-end X.509 certificates only need to be configured at the load balancer instead of every
web server, and it should be for Relativity’s public DNS name. In addition, the introduction of a load balancer
provides more flexible options for distributing traffic to the web servers.
To set up TLS Termination, you need to configure your load balancer to send the X-Forwarded-Proto header
and the X-Forwarded-For header to Relativity. It also must configure it to set the secure flag for all cookies
returned by Relativity.
End-to-End TLS
At the high end of the security spectrum lies End-to-End TLS. The principle behind this topology is to regard
the entire network as untrusted. As a result, all communication between any Relativity component should be
secured with TLS.
As in the TLS Termination approach, the load balancer handles the TLS communication with the browser.
When the load balancer forwards the traffic to Relativity, a separate TLS connection is established with the
web server. Likewise, when the Relativity web server needs to communicate with an API or the database,
that communication is encrypted with another TLS session. This pattern of encrypting each communication
hop continues throughout the infrastructure so that all network traffic is secured.

Out of all the options presented, End-to-End TLS requires the greatest commitment from administrators. A
certificate must be generated and installed on every machine in the infrastructure. Components such as
SQL Server, Data Grid and Content Analyst must be individually configured with workflows specific to that
server. End-to-End TLS gives administrators a high degree of security, but, because of the complexity,
deliberate preparation is required for success.
Certificate Authorities
As part of running Relativity, you may use a Certificate Authority that can generate certificates. This is
separate from a public CA such as Verisign or Thawte.
Why Run Your Own CA?

Websites accessible to the public use certificates issued by a well-known provider such as Verisign. This is
necessary because web browsers such as Internet Explorer, FireFox, and Chrome only trust certain CAs by
default. Obtaining a certificate from a trusted CA is important if the website will be accessed from machines
on the public internet.
By contrast, private server networks are controlled environments. Using a public CA is costly, impractical,
and unnecessary in these circumstances. Administrators can easily create an internal Certificate Authority,
which gives complete control over certificates for the internal network.
A Relativity instance that is exposed to the internet will use both approaches:
• A public CA to secure the Relativity web servers

• A private CA to issue certificates for the back-end.
Options for Creating a CA

There are multiple options for running an internal Certificate Authority:

• OpenSSL - This command-line tool is the de facto standard for certificate management in Linux, and it’s
also available for Windows. OpenSSL can handle all aspects of CA and certificate generation.
Administrators who maintain both Windows and Linux may prefer OpenSSL.
• Active Directory Certificate Services - This is a Role that can be installed on Windows Server.
Installing Certificate Server creates a web portal for managing certificates on the Windows network. This
approach has higher infrastructure requirements because it is a service on the network, runs as an NT
Service, and must be backed up.
There are other solutions for managing certificates on a network. For example, some environments issue
certificates from a dedicated appliance connected to a Hardware Security Module. If your organization
already has a Certificate Authority solution in place, you should use that existing toolset if possible.
Otherwise, we recommend Makecert. This is a standard Windows command-line tool for generating X.509
certificates that is included with every modern Windows Server operating system.
Federal Information Processing Standard Compliance

Federal Information Processing Standard (FIPS) Compliance is an optional mode for Relativity, which is
used by some government agencies and companies that are subject to special regulations regarding
computer security.
FIPS Compliance Overview

FIPS is a collection of standards for data and network security. The FIPS standard defines, among other
things, a list of cryptographic algorithms that are permitted on compliant networks. As a government
standard, FIPS is very specific on which algorithms can be used, and the list of algorithms is not updated
very often. Relativity, however, by default uses more recent protocols that are considered best practice by
the security community.
Relativity only recommends FIPS when mandated by existing corporate or government policies. All other
environments should turn off FIPS (the default for Windows Server).
Configuring Relativity for FIPS

Windows Server has an OS-level setting to control FIPS. When FIPS is turned on for a Windows server,
typically configured using Group Policy, all Relativity processes running on that server will detect the setting
and automatically use FIPS-compliant algorithms.
Appendix
Recommended IIS Crypto Settings
1. We recommend enabling following Ciphers:
a. TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
b. TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
2. We recommend enabling following protocols
a. Enable:
i. TLS 1.2
b. Disabled:

i. TLS 1.1
ii. TLS 1.0
iii. SSL
Transparent Data Encryption (TDE) Architecture
Update Identity Server Signing Certificate

Relativity recommends rotating the Relativity Server Singing's Certificate periodically, it is used to create
authentication tokens for the Server instance. Compromising this certificate allows an attacker to forge
authentication tokens for the Server Instance. Please follow the instructions given here.

Relativity Server Security - 2022

Uploaded by

Copyright:

Available Formats

You might also like

Relativity Server Security - 2022

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Relativity Server Security - 2022

Uploaded by

Copyright:

Available Formats

Version 2022, December 15, 2022

© Relativity. All rights reserved. 2

© Relativity. All rights reserved. 3

© Relativity. All rights reserved. 4

Relativity Infrastructure Configuration

Backups and Maintenance

• Selecting a backup approach

© Relativity. All rights reserved. 5

• Identifying data to back up

• Relativity – Configuring Relativity After a Disaster Recovery Failover

© Relativity. All rights reserved. 6

HTTP Strict Transport Security

instead of HTTP. Update the following:

2. Select the root site labeled as Default Website

3. Select the option HTTP Response Headers

© Relativity. All rights reserved. 7

Slim Down IIS Headers

Removing X-Power-By header

Removing X-AspNet-Version header

1. Open the web.config file located in the C:\Program Files\kCura Corporation\Relativity\EDDS

© Relativity. All rights reserved. 8

Removing Server header

Follow below steps to remove Server header:

1. Open IIS Manager.

2. Navigate to the Default Website.

3. Double click on the HTTP Response Headers feature.

4. Select the Server header.

5. Select Remove in the Actions pane.

Repeat the steps above for the site Relativity.

© Relativity. All rights reserved. 9

6. Open IIS Manager

7. Navigate to Default Web Site

8. Click on 'URL Rewrite'

10. Add server variable RESPONSE_SERVER

© Relativity. All rights reserved. 10

15. iisreset is required for the changes to take effect

1. Open IIS Manager.

© Relativity. All rights reserved. 11

Enable Custom Errors

1. On each web server, edit the C:\Program Files\kCura Corporation\Relativity\EDDS\web.config file.

Disable Directory Browsing

Remove the HTMLArea Application

© Relativity. All rights reserved. 12

© Relativity. All rights reserved. 13

1. Open C:\CAAT\jetty\etc\jetty-ssl.xml on the Analytics server.

Relativity supports the following TLS 1.2 cipher suites:

© Relativity. All rights reserved. 14

Conversion Agent/Service Bus Server

Service Host Manager Service

Lock Down Unused Ports

Take a Network Baseline

Use a Firewall to Create a DMZ

Disable the SMBv1 Protocol on all Servers

© Relativity. All rights reserved. 15

1. Log in to the RabbitMQ server.

Using Antivirus on Relativity Servers

Scan all New Relativity Data

Server Access Control