Skip to main content

RedCap VMs: Adding application secure VM support to tiCrypt

· 6 min read
Alin Dobra
Alin Dobra
CEO & Co-founder

REDCap is a widely used platform for building and managing online surveys and databases. It serves two fundamentally different roles:

  1. Data collection: REDCap collects responses from patients, research participants, or other users through its survey interface, storing submissions in a secure database.
  2. Data management and analysis: Authorized users access the REDCap server and database directly to clean, analyze, and report on collected data, often exporting it to other tools for further processing.

This article focuses on enabling external data collection while securing the REDCap server and database with tiCrypt. Data management and analysis are straightforward since authorized users can work inside secure VMs in tiCrypt. The overarching goal is to achieve CMMC Level 2 compliance with reasonable effort and no security or compliance risks.

Possible Solutions​

tiCrypt's secure VM model places virtual machines in lockdown: all communication passes through the tiCrypt proxy (WebSocket-proxied connections or TLS tunnels), so only authorized users, those who can provide correct digital signatures to the tiCrypt VM controller, can access the VMs.

This security model prevents certain use cases, most notably running a publicly accessible server like REDCap. REDCap requires patients to access the survey interface to submit health data. These patients are not tiCrypt users, have no access rights within the system, and their interaction is restricted entirely by REDCap itself.

Three approaches were considered to incorporate REDCap into tiCrypt-based workflows:

  1. Standalone external REDCap: REDCap hosted on a separate server outside tiCrypt, the most familiar setup for REDCap admins, compatible with existing instances. Drawbacks:
    • Full CMMC Level 2 compliance would need to be applied to the external REDCap server, a large effort with significant uncertainty and risk.
    • Secure VMs in tiCrypt would need to reach the external REDCap server, creating a data exfiltration path with security and compliance implications.
  2. REDCap in a secure VM: REDCap hosted in a tiCrypt secure VM, accessible only to authorized users. While this fully secures the server, it blocks patients from accessing the survey interface, a critical use case. No changes to tiCrypt would be required.
  3. REDCap in a secure VM with application support: A new tiCrypt feature allows applications like REDCap to be hosted inside secure VMs while permitting strictly controlled external access.

Only the third solution is viable. This article describes its design and implementation. We call it Application Secure VM Support and refer to VMs using this feature as Application Secure VMs. The solution is designed to be generic enough for a variety of applications, though the design is driven by the REDCap use case.

Technical Requirements​

Implementing Application Secure VM support requires solving three problems:

  1. External pathway for data collection: The REDCap survey interface must be reachable from outside, despite tiCrypt's default of locking down all VM network access.
  2. Restricted access via external pathway: The external pathway must be limited strictly to the REDCap survey interface. REDCap alone does not provide CMMC Level 2-strength access controls, making this restriction essential.
  3. Secure VM hosting of REDCap: REDCap must run inside a tiCrypt secure VM to benefit from encrypted drives, controlled access, strong authentication, and strict access controls.

Technical Solution​

The following features are added to tiCrypt to meet the above requirements:

  1. Application port support: The tiCrypt VM controller's automatic firewall is extended to allow access to a designated port on the VM. REDCap uses this port to expose the survey interface to external traffic.
  2. Fixed IP addresses for VMs: Application Secure VMs require a fixed IP address so that Nginx and firewall rules can be configured reliably.
  3. DNS names for application VMs: Fixed DNS names are required to issue TLS certificates securely.

Changes to the VM Controller​

The VM controller is modified to:

  • Open the application port for the VM (typically port 443 for TLS). Traffic on this port is restricted to connections from the tiCrypt backend server.
  • Generate a self-signed TLS certificate for external connections. This certificate is registered with the tiCrypt backend for Nginx integration and the external pathway.

Application Secure VM Feature​

A new management table in the tiCrypt frontend allows the Super Admin to designate VMs as Application Secure VMs and configure their external access. The following fields are managed:

  • VM name: used for DNS and TLS certificate management.
  • VM MAC address: used to pin the VM to a specific IP address.
  • VM configuration: tracks which VM is associated with this entry.
  • VM IP address: used for firewall rules and Nginx configuration.
  • Open ports: the ports exposed for external access (for REDCap, the survey interface port).

Integration with dnsmasq​

  1. MAC-to-IP mappings are added to the dnsmasq configuration for the secure network. The tiCrypt backend manages /etc/ticrypt/secure-hosts, which contains entries of the form:
# MAC address, IP address
00:11:22:33:44:55, 192.168.128.20

IP addresses are allocated from a reserved pool at the start of the secure network address range. MAC addresses pin each VM to its assigned IP.

  1. The backend server's IP on the secure network is mapped to the external DNS name of the REDCap server. This allows the VM itself to reach the REDCap interface via Nginx, enabling TLS certificate validation for internal access.

Setting the External Pathway and Nginx​

Enabling external access to the REDCap survey interface requires the following steps:

  1. An external pathway from a public IP address to the tiCrypt backend server, restricted exclusively to the REDCap survey port. A dedicated port, such as 4443, is preferred to avoid sharing with the tiCrypt backend.
  2. An external DNS name and a corresponding TLS certificate configured in Nginx to enable secure external access to the survey interface.
  3. An Nginx configuration that binds the external port to the external pathway, applies the TLS certificate for the external DNS name, and forwards traffic to the Application Secure VM's IP using the self-signed TLS certificate generated by the VM controller.
  4. URL path restrictions in Nginx based on the request source IP. Only requests from the public internet are permitted to access the REDCap survey interface. All other paths are blocked. Requests originating from the secure network are unrestricted.

Security and Compliance Implications​

This solution significantly strengthens REDCap security by hosting it inside a tiCrypt secure VM. The external pathway is tightly scoped to the survey interface only, and TLS certificates with Nginx configuration secure all traffic across that pathway.