tiCrypt Installation checklist

The required preparation steps fall into several categories:

• Server preparation
• DNS mappings
• TLS certificates
• Firewall setup

After an introduction to key tiCrypt components, we indicate recommended preparation steps for each of the categories.

tiCrypt components

tiCrypt services are grouped into three categories. Each category has different considerations in terms of deployment.

tiCrypt Backend

The main tiCrypt infrastructure is provided by the tiCrypt backend. It consists of 11 services that cooperate to implement the functionality. Depending on the functionality required, some of the components might not be installed in a particular installation. A short explanation of the role of each component is:

• tiCrypt-auth: is responsible for authentication, some auxiliary responsibility, and keeping all other services together.
• tiCrypt-rest: is the HTTPS entry point
• tiCrypt-vm: offers virtual machine functionality
• tiCrypt-file-manager: is responsible for files and directories in the vault
• tiCrypt-storage: is responsible for file content storage
• tiCrypt-logger: is responsible for logging
• tiCrypt-maintenance: is responsible for regular maintenance tasks
• tiCrypt-notifications: is responsible for the notification facility (informing users of various actions affecting them)
• tiCrypt-proxy: is responsible for bridging connections between user desktops and their VMs
• tiCrypt-stats: is responsible for statistic gathering
• tiCrypt-backup: coordinates backup activities

Most tiCrypt installations should run all 11 services on a single server. Only for very large installations, it is recommended to split the services on multiple servers.

tiCrypt Audit (tiAudit)

tiCrypt Audit component processes the logs, extracts alerts, can create reports and allows execution of forensic queries. It consists of 3 sub-components

• log-streamer: loads the log live from a tiCrypt backend (the tiCrypt-logger service)
• log-uploader: loads historical logs from raw tiCrypt logs
• audit: provides a web-based interface to view alerts, run reports and queries.

The tiAudit components can run on the same server as tiCrypt backend or on a different server. Multiple independent tiAudit installation can be supported.

tiCrypt data aquisition sevices

To mediate data acquisition, 3 independent services can be used:

• tiCrypt-mailbox: Allows file transfers from external users into the Vault using a web interface.
• tiCrypt-sftp: Allows file transfers from external users using SFTP protocol
• tiCrypt-forms: Allows form submission (either via designed surveys or raw form data)

These services are typically deployed on public-facing servers to allow users not part of the organization to interact with tiCrypt users. All 3 services can be hosted on a single (virtual) server.

Server preparation

For deploying either tiCrypt backend, audit, or data acquisition services, we recommend the (virtual) servers are prepared in the following manner:

1. RedHat Enterprise 7 or 8 or equivalent (Centos, Springdale) is installed
2. Only root accounts are created. No regular users should be allowed on these servers
3. Adequate storage is provisioned depending on the intended use
4. CPU and RAM minimum requirements are met:
   • backend: 8 CORES, 32GB RAM
   • audit: 4 CORE, 16GB RAM
   • data: 1 CORE, 4GB RAM
5. IP addresses and service names (internal and external)

DNS mappings and TLS certificates

The main mechanism of communication in tiCrypt is HTTPS based. In order to consolidate functionality, extensive use of host virtualization should be used. Specifically, multiple names should map to the same physical server via DNS mappings.

The specific mappings needed and their visibility are:

• tiCrypt-rest: A name for the backend entry point, e.g. backend.ticrypt.myunv.edu visible to the intended tiCrypt users pointing to the server running the tiCrypt backend
• tiCrypt-audit: A name for the tiAudit instance, e.g. audit.ticrypt.myunv.edu, pointing to the server running the audit components (might be the same as tiCrypt backend)
• data services: three names for the three data services, e.g. mailbox.ticrypt.myunv.edu, sftp.ticrypt.myunv.edu and forms.ticrypt.umyunv.edu pointing to the server hosting the data services.

All of the above-mentioned DNS names must have matching TLS certificates. We strongly suggest the user of multi-certificates for the data services (i.e. a single certificate for all three names).

Firewall Setup

In order for the various services to be able to talk to each other and for users to be able to use the functionality, the following ports need to be opened (with specified visibility):

• tiCrypt-backend:
  • 443(https) visible to all tiCrypt users (can be protected by institution firewall), VM hosts, and data servers (mailbox, sftp and forms).
  • 6000-6100(proxy) visible to all tiCrypt users. This port range is used by the tiCrypt-proxy to provide access to user virtual machines.
• VM hosts: visible exclusively to tiCrypt backend
  • 6000-6255: used to proxy connections to user VMs.
  • 22(ssh): used for LibVirt management and maintenance
• tiAudit:
  • 443(https): visible to all users that have access to the audit facility (not necessarily tiCrypt users).
  • 25000: visible to the tiCrypt backend server (used to publish new logs)
• data services:
  • 443(https): visible to the entire world (placing this behind institutional firewall diminishes usefulness)
  • 22(ssh): visible to the entire world. Used by the tiCrypt-sftp service. Does not provide access to the underlying OS.
  • 2022(ssh): for management purposes, the real SSH server should be bound to this port. Visibility should be restricted to admins.

Note on VM Hosts

The user VMs run on VM Hosts and pose the largest security risk. The VM Hosts need to be protected by a separate firewall making them visible only to the tiCrypt backend server and never to any direct user communication. Only administrator and service accounts should be created on these servers (no regular user accounts).