Granite is a new secure research environment that allows researchers to securely access and analyze data on an encrypted platform.
Purpose of this platform:
This tool provides a common computer platform (Windows or Linux) upon which researchers across Dartmouth Health and Dartmouth College can collaborate to view, analyze, and store sensitive data for active research projects. Beyond being a secured research environment, this platform leverages a variety of analytic packages available including SAS, Stata, SPSS, R, Python, and several more. The data security configuration meets and exceeds standards typically required for research using protected health information (PHI). Planning to store and analyze your data in Granite may decrease IRB and DH Privacy review time, given the highly secured nature of the system.
How does it work?
After your project is IRB approved, you and your research team will request an account, and one of the DH Honest Data Brokers will connect individuals with a project and walk you through how to log on. Once your data query is completed the data broker will import the data into your project on a Virtual Machine (VM) and those listed in the IRB study team will have shared access to the data as well as the analytic tools. A Virtual Machine (VM) is a secured project-specific space that has access to various analytic packages but access is limited to the research team for this project. Users may be able to import data but the ability to export data will be limited to the Primary Investigator. For example, this will allow medical students to participate in research projects initiated by DH PIs as they will have a secure space to access and analyze data.
Why should I use Granite?
When using PHI for research and sharing it across DH and Dartmouth College, or for a Dartmouth
College-only projects, Granite is the preferred secure research platform. Studies planning to use Granite
will require less review from the IRB and the DH privacy office, given the high-security standards of the
platform.
When should I request a Granite account?
Requests to use Granite should be initiated once the IRB protocol is approved. The administrator will assess the size of the project’s data, the number of team members and their roles, and what analytic software packages will be required. Contact research.computing@dartmouth.edu once you are ready to request access.
Is Granite connected to the Internet?
A Granite virtual machine is not connected to the Internet by design. Granite does not contain all possible statistical packages though there is some possibility of gaining access to non-standard packages. This may take additional effort and time for the Granite infrastructure team to assess and develop.
Which projects do not belong in Granite?
Granite is designed for research projects containing PHI, particularly when data needs to be shared across DH and Dartmouth College. De-identified data may be better stored in a different tool as it does not require the same protections as PHI. In addition, if there is a DH-only research project that can be analyzed on protected DH locations, it may not need to be sent to Granite.
How do I access Granite?
After a project is setup in Granite on behalf of the PI by the Granite Support team, Granite can be accessed using your institution's Single Sign-On (SSO). External collaborators must be setup with a temporary account sponsored by the project PI.
How much does Granite cost?
Note: Between March 2024 and July 2024, we are sending out $0 informational invoices.
Granite is billed monthly based on resource usage. As of July 1, 2024, Granite resources cost the following
| Resource unit costs |
Per year |
Per month |
| CPU |
$256.59 |
$21.38 |
| GB memory |
$128.29 |
$10.69 |
| A40 GPU |
$1,750.00 |
$145.83 |
| TB storage |
$335.53 |
$27.96 |
Note that 1 CPU = 1 core. For comparison, the following table shows typical costs for small, medium, and large VMs
|
Example VMs |
CPUs |
Memory (GB) |
Storage (TB) |
Per year |
Per month |
| Small |
2 |
4 |
1 |
$1,361.88 |
$113.49 |
| Medium |
6 |
24 |
4 |
$5,960.68 |
$496.72 |
| Large |
8 |
64 |
10 |
$13,618.76 |
$1,134.90 |
At the end of a project, how is data destroyed?
At the end of a project we will request approval from the PI and/or all parties involved to permanently delete all data associated with the project from Granite. If the project was requested to be backed up, those backups will be retained for up to 60 days following the deleting of the data within Granite. We do not have a way to selectively delete backup data so if this data should not persist past a certain date then you must request that we disable backups at least 60 days prior to that date. The permanent and irreversible destruction of this data is done in accordance with meeting NIST 800-88 compliance.
How should I describe Granite for my grant application?
## Granite Security Overview
The Granite system is a secure computing environment, located at Dartmouth College, Hanover, NH, providing support for projects that require compliance with the controls in NIST 800-171 and 800-53 Moderate.
Granite is self-contained with a minimum of connections to other systems. All connections are rigorously controlled. Data is encrypted at rest and in transit and is processed inside isolated Secure Virtual Machines (SVM). Projects are configured to limit data export to authorized individuals responsible for compliance with project-specific requirements. Data stored within Granite is isolated from the end-user computing devices using the tiCrypt client, which provides remote desktop access to interact with SVMs.
Granite is designed to enable research for a multitude of secure, isolated projects, while keeping the confidentiality, integrity, and availability of information protected at the appropriate level. Configuration security also segregates project information to prevent unauthorized disclosure or sharing of information. Granite provides the necessary infrastructure to enable research partnerships with federal agencies and other organizations for which research projects, data, and technical processes must adhere to specific security guidelines per applicable regulations or contractual requirements. All research projects are completely segregated from other projects.
The environment involves the use of an encrypted (FIPS 140-2 compliant) storage, network, and processing infrastructure for all of the physical servers, virtual servers running on the physical servers, client virtual desktop infrastructure, as well as all of the databases for the information system. The client's computer is not trusted to hold ePHI or other sensitive data. Users can access Granite only through a secure TLS network connection only after user authentication. All traffic will be carried encrypted to the Granite gateway system overall traversed networks. The gateway system provides further authentication through a secret key created for each user upon first use of the Granite system. The Granite gateway then establishes a secure, high-performance virtual desktop session. The system ensures that the researcher can use applications to analyze authorized data.
Granite is managed using the processes and procedures that meet or exceed the mandates of the FISMA acts of 2002 and 2014 for systems owned by and/or operated for the Federal Government:
* Data processed by projects set up in Granite is classified following FIPS-199.
* Granite is classified according to FIPS-200 to meet data requirements classified at the “moderate” impact level for Confidentiality, Integrity, and/or Availability.
* Controls are implemented and maintained for Granite as specified in 800-53 Moderate and 800-171.
* A system security plan (SSP) with Plan of Actions and Milestones (POAM) is maintained for Granite according to NIST 800-18.
* Approval to operate is obtained by the system owner and operator from the appropriate university official.
## Software Layer Details
With tiCrypt being the software layer of the system, client machines connect to the Granite server system via an application called tiCrypt Connect. tiCrypt Connect helps establish secure VM connections and ensures that all traffic is authenticated, locking down sessions if unauthenticated. In addition, software within tiCrypt will secure the VM during the start-up and creation sequence by managing all account passwords and blocking any ports except for port 22 and ports used for licensing servers. For security reasons, virtual machines in tiCrypt cannot be accessed using any of the traditional methods. In particular, direct connections to the VM console, SSH logins, or other remote server technology are not allowed since these items can be controlled by the admins, and thus by hackers impersonating them. The only means of communication is through a secure channel that only the owner of the VM can establish via proxy within tiCrypt. When a VM starts, it gets the public key of the owner. During secure channel setup, the VM and the user co-authenticate each other using the respective public and private keys. A secret channel key is negotiated (Diffie-Helman protocol) and used to communicate. As a result, a secure VM has been created.
System permissions are assigned and managed via a system administrator in Research Computing, acting in coordination with, but independent of, the research team. Upon account creation, users are placed in "teams" by the system administrator. Teams are isolated groups of users. Only members in the same team can interact and share data with each other, and only within the Granite system. Users who wish to download files off the system (for instance, summary tables and graphs) must request that an authorized individual responsible for compliance with project-specific requirements, download the file for them.
## User System Login and Lockouts
The user first enters the password to decrypt the private key stored on their computer. The public-private key-pair used for crypto verification and secure sharing and login is created upon account registration. Next, the private key is used to sign a challenge generated by the server. Finally, the server checks the signature against the user's public key on the server. If it is a match, the user has proven that they hold the private key and thus authenticated. The private key is never cached in the browser and requires to be added each time a user initiates a session in Granite.
The Granite system utilizes session locks. Every 5 minutes, the decrypted private key is wiped from memory. Once the key is wiped, any action results in a locked screen for the Granite session. As a result, the user will need to enter the correct password to re-decrypt the key whenever you take your next action in the system (ex: viewing a file, sharing a file, connecting to VM, etc.). After 15 min, the session becomes expired. This results in the invalidation of the user's session so no requests to the backend can be made until the user successfully re-logins into the system.
## Encrypted Drives
In order for the VM to perform efficient computation, it needs access to fast, secure storage. This is provided in the form of encrypted drives. The drive encryption keys are generated and manipulated in the same manner as the file keys. The user-VM encrypted channel is used to transmit such keys to the VM during the start-up sequence.
The disk encryption happens inside the VM, under the control of the user who owns the VM, not the system administrators. The Controller utilizes widely available and tested disk encryption solutions, like BitLocker and LUKS, to handle the disk-level encryption.
## VM Anti-virus
Files are scanned by anti-virus software in the secure VMs when imported into the encrypted virtual drives and upon read or write by users. Anti-Virus definition file updates are made to Virtual Machine (VM) images on a monthly basis. Linux-level server storage is scanned daily to detect and eradicate malicious code. Malware discovered by scanners is deleted or quarantined, depending on the characteristics of the malware and the capability of the anti-virus software. Detection of malware is logged and reviewed monthly by the Research Computing staff. False-positive detections of malware are documented and tracked, with the ability to roll back malware definitions that create availability problems.
In addition, the VM images are immutable, meaning they boot each time from the frozen VM template each time. This ensures that any bad-actor modifications within the VM are never persistent.
## Password Policies and Practice
Granite password policy is based on the zxcvbn password library created by Dropbox to calculate the password's strength. There are four levels of strength and Granite utilizes the highest level (4) for password security.
zxcvbn works in the following way:
1. It provides a simple API that takes a password as input and returns a score from 0 to 4 as the output to indicate the strength of a password (0 - weakest, 4 - strongest).
2. It estimates a realistic strength of the password, by detecting all the possible overlapping patterns and then matches it against several English dictionaries, common passwords, keyboard patterns and repetitions. This strength is represented in a metered bar for visualization. If the password does not meet the required strength, the user will have to pick a new password.
When logging into Granite, the user is allowed 5 failed attempts prior to lockout. After 5 failed attempts, the account's status is set to inactive. Any attempt to login into a fixed account will fail until a Granite System Administrator unlocks the account by selecting the status to active.
## Workstation Storage
As noted above, user workstations are not trusted to hold sensitive data, and as such the Granite system prevents users from moving any files from Granite to the desktop, or vice versa. The exception is the person with the role of Data Manager, who has the ability to move data on and off Granite.