Rhino Client Security
The Rhino Client typically resides behind the institution firewall (in the case of installation in a VPC, the institution firewall is considered to be inclusive of the VPC).
The Rhino Client can be installed on a virtual machine (VM), physical server, or cloud instance provided by the institution, or it can be installed on a physical server provided to the institution by Rhino (a Rhino Box). With Rhino Boxes, Rhino has more control over the security measures that are defined at the hardware and OS level.
No Direct Server Access
The server on which the Rhino Client is installed does not allow any users to login locally or via SSH. The only users configured on the host OS are for copying data to the server using SFTP to specific directories within the server (e.g. to provide the Rhino Client access to cohort data that was prepared by someone at the institution), and for system maintenance.
Users of the Rhino Platform have no direct access to the server on which the Rhino Client is installed.
This security measure is enforced for ‘Rhino Boxes’, and is strongly recommended for VMs, servers, cloud instances provided to Rhino by an institution, but is ultimately defined by the institution IT.
No Inbound Ports
The Rhino Client does not require any inbound ports to be opened in the institution firewall. All communication is performed outbound from the Rhino Client to the Rhino Orchestrator.
Data Encrypted at Rest
The server on which the Rhino Client is installed has hard-drive encryption such that all data is encrypted at rest.
This security measure is enforced for ‘Rhino Boxes’, and is strongly recommended for VMs, servers, cloud instances provided to Rhino by an institution, but is ultimately defined by the institution IT.
Data Encrypted in Transit
All communication between the Rhino Client and the Rhino Orchestrator is encrypted using strong industry standard TLS based encryption methods.
Anti-Malware
Customers can apply the anti-malware solution of their choice to the Rhino Client, so long as it can be installed on the server that is hosting the Rhino Client (usually running Ubuntu Server 20.04 LTS or RHEL 8). Good general practice should be exercised to ensure there is minimal impact on the performance of the Rhino Client.
Code/Model Guardrails
The code (e.g. models or Generalized Compute code) run in the Rhino Client are run as docker containers that are tightly locked down. No communication is allowed, neither inbound or outbound, except for communication with the Federated Server for FL. This Federated Server is provisioned by Rhino for each FL training run and provided with SSL certificates to securely authorize the Federated Clients that are allowed to connect to it.
All inputs and outputs from the code/models are controlled by the Rhino Client and are all stored only within the Rhino Client except for: model weights shared during the FL process (see below for additional security measures used to prevent patient data from being exposed through model weights), and aggregate data from the resulting cohort/training results.
Rhino Orchestrator Security
The Rhino Orchestrator runs on AWS, utilizing many of the security capabilities provided by AWS (e.g. IAM, KMS, Secrets Manager, Shield, Network Firewall).
Data Encrypted at Rest
Databases and physical disks utilized in the Rhino Orchestrator are encrypted at rest.
Data Encrypted in Transit
All communication with the Rhino Orchestrator (both inbound and outbond) is encrypted using strong industry standard TLS based encryption methods.
All communication between the Rhino Web UI and the Rhino Orchestrator happens over HTTPS.
User Identity and Access Management
Accounts for new users of the Rhino Platform are provisioned by Rhino. Users are assigned specific roles in specific workgroups based on a list of users/roles provided by the institution. Role based permissions are applied in each project in which the user participates. User activity is logged within the system and major user actions like creating a new project, adding a collaborator to a project, importing cohort data, etc. are displayed in a visual log.
User Authentication
End user access to the Rhino Orchestrator is controlled using username/password with a secure policy:
- Users must change their passwords every 90 days without reusing recent passwords.
- Passwords must be at least 8 characters in length and must include at least one upper case letter, one lower case letter, one numeric character, and one special symbol.
- Two-Factor Authentication (2FA) can be enabled/required using any authentication app.
- The last 10 passwords cannot be reused.
- Repeated unsuccessful login attempts are logged and monitored. An incrementally longer backoff period is applied after every unsuccessful login attempt.
- Platform sessions timeout automatically after 12 hours.
It is also possible to use SSO to authenticate users with 3rd party authentication providers such as Google and Azure AD.
Role Based Permissions
Each project in the Rhino Platform defines a set of role based user permissions, usually defined by the project lead and agreed to by all participants. For example - which users are allowed to train a model, which users are allowed to view the results of model training, etc. These permissions are enforced in the Rhino Orchestrator such that each user only has access to data and actions that are allowed by the project permissions.
Project participants are allowed to opt-out of specific project permissions. For example - even if the project permissions define that aggregate data from cohorts will be sent from the Rhino Client to the Rhino Orchestrator , a participant can opt-out of this such that aggregate data from their cohorts will not be sent to the Rhino Orchestrator .
Users do not have any access to projects in which they are not a participant.
Data Schema Permissions
Each data schema in the Rhino Platform can include field-level permissions. For example - defining that a cohort field corresponding with a specific data schema field will never send aggregate data from the Rhino Client to the Rhino Orchestrator.
Event Logging
Rhino logs user actions within the system for security and auditability. Major actions like creating a new project, adding a collaborator to a project, importing cohort data, etc. are logged and displayed in a visual log. Security events like failed login attempts are logged and these logs are reviewed regularly by Rhino staff.
Cloud Server/Service Access
Access to the AWS servers and services on which the Rhino Orchestrator is run is controlled by AWS IAM roles with strict policies around authentication (password strength, 2FA, etc.) and is only provided to the Rhino employees who need access to maintain these services. These employees must use a VPN in order to connect to AWS.
Note that no patient data is ever stored in the cloud, so this only provides these Rhino employees with access to project config/metadata.
Intrusion Detection System (IDS)
The Rhino Orchestrator utilizes an Intrusion Detection System (Guard Duty) to identify suspicious activity on the Rhino Orchestrator and notify the Rhino admins.
Vulnerability Scanning and Penetration Testing
All Rhino servers are scanned for vulnerabilities using AWS Inspector on an ongoing basis. All container images used by Rhino and provided to Rhino by users are scanned for vulnerabilities using AWS Inspector on an ongoing basis.
In addition, vulnerability scans are performed regularly on the Rhino user interfaces
An external penetration test is performed periodically to identify any potential vulnerabilities.
Software Supply Chain Defense
The Rhino Platform’s code is hosted on Github where access is limited to the engineers developing the platform and MFA is required. 3rd party libraries are validated against specific signatures to prevent library injection attacks. The build process is executed on self-hosted runners, which helps protect against supply chain attacks on the build process.