Defined terms (indicated by initial capital letters) will have the meaning given in the Terms of Service. References to “we,” “us” and similar terms are to The Broad Institute or “Broad.”
Terra is a scalable and secure cloud-based platform for biomedical researchers to access data, run analysis tools, and collaborate. As further described in the Terra Security Posture, we implement controls from the NIST 800-53 Moderate baseline and select additional enhancing controls where needed using a “pure” information security perspective to prioritize best-of-breed security methods.
However, there are some aspects of these controls that Broad is not able to enforce without your help. Some controls are shared between us and the User while others are fully the User’s responsibility. These controls are called “Customer Responsibilities.” By using Terra, you acknowledge that you are responsible for adhering to these
Customer Responsibilities.
These Customer Responsibilities may be updated periodically. We will notify you of any material changes to this Privacy Notice by posting the revised Customer Security Requirements. You are advised to periodically review this page to ensure continuing familiarity with the most current version of our Customer Security Requirements. Any changes to our Customer Security Requirements will become effective upon our posting of the revised Customer Security Requirements. You will be able to determine when this Customer Security Requirements was last revised by checking the “Last Modified” information that appears at the top of this page.
Terra uses Cloud-native identity providers for authentication and requires that Terra users “bring their own” identities. This means that Terra does not create user credentials for you — rather, you tell us what your “Cloud Identity” is, and we give that Cloud Identity authorization to access Terra. This identity used to access Terra is also referred to as an “end user account.” Since each user brings their own Cloud Identity to Terra, we cannot enforce account management security controls on those accounts. It is therefore your responsibility to ensure
that your end user accounts meet the following requirements:
Deliver a Cloud Identity to be used for authentication in Terra. The User is responsible for procuring either a Microsoft Identity or a Google Identity that will be used to authenticate to Terra.
Implement multi-factor authentication (“MFA”) on all Customer end user accounts.
As Users bring their own Cloud Identity that is used to authenticate to Terra, Broad does not have the ability to enforce multi-factor authentication enrollment or requirements on these accounts. It is the User’s responsibility to ensure that you and each individual User, with respect to a company or other entity that is using Terra, (1) enrolls their Cloud Identity in multi-factor authentication, and (2) utilizes a second factor authenticator that is both separate from the device gaining access to Terra and either FIPS 140-2 validated or NSA approved.
Adhere to password requirements.
As Users bring their own Cloud Identity that is used to authenticate to Terra, Broad does not have the ability to enforce password requirements on user accounts. It is therefore the User’s responsibility to ensure that their users’ passwords meet the following requirements: (1) are at least 8 characters in length; (2) are rotated every 60 days; (3) have at least 1 character changed from the previous password; and (4) are not reused for at least 24 generations.
Suspend user accounts due to inactivity.
As Users bring their own Cloud Identity that is used to authenticate to Terra, Broad does not have the ability to suspend User accounts after a period of inactivity. It is therefore the Customer’s responsibility to ensure that their end users’ accounts are suspended if the User account has been inactive for 90 days.
Deprovision user accounts and offboard users.
As end users bring their own Google ID that is used to authenticate to Terra, Broad does not have the ability to deprovision user accounts or offboard Customer users. It is therefore your, the Customer’s, responsibility to ensure that these activities are done. Deprovisioning user accounts and offboarding users is a critical part of ensuring that your users who no longer should have access to Terra are, in fact, no longer able to access Terra or your data/Workspaces within Terra.
Audit and monitor end user accounts.
As Users bring their own Cloud Identity that is used to authenticate to Terra, Broad does not have the ability to audit and monitor User accounts. It is therefore your responsibility to collect logs for User account management events including creation, modification, enabling, disabling, removal, and successful and unsuccessful login attempts and to monitor these accounts.
Terra is a secure system but Users may access Terra from their own systems (desktop computers, laptops, etc.). It is therefore your responsibility to ensure that those User systems are appropriately secure.
Enable endpoint security.
Users are responsible for the security of endpoints (desktops, laptops). Subject to Section 5, endpoints must be configured to automatically lock the screen after no more than 30 minutes of inactivity and require User re-authentication to unlock, must have anti-virus/anti-malware software installed, hard drives must leverage encryption at rest that meets FiPS 140-2 compliance, and must be configured to automatically receive and install operating system updates on a weekly basis and updates to other applications when security updates are released.
Terra uses TLS 1.2 (or higher) to protect data in transit throughout the Terra system. However, Terra Users are able to remove information (such as derived data, aggregate statistics, graphical representations of data) from workspaces connected to Terra to fulfill their research needs. It is the User’s responsibility to ensure that a commensurate protocol is used to protect any information retrieved via Terra while in transit.
Use TLS 1.2 (or higher) to protect data in transit.
Users are responsible for protecting data retrieved from Terra in transit using TLS 1.2 (or higher) or a commensurate protocol.
Compute and storage costs associated with a User’s use of Terra incur costs. These costs are billed to the Terra User directly by their Cloud provider (Microsoft Azure or Google Cloud Platform). It is therefore the User’s responsibility to enable either a Microsoft Azure Subscription or a Google billing account to receive and pay for such charges as follows:
Using a Microsoft Azure Subscription: Cloud resources that run in a User’s Terra Workspace belong to the User’s Azure subscription and all expenses generated from these resources are billed directly against the subscription. Please refer to Microsoft’s documentation on Azure Subscriptions at
https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/resource-org-subscriptions.
Using a Google billing account: Expenses generated from the use of Google Cloud Platform resources for compute are the User’s responsibility. For guidance on how to create, modify, or close a Google Cloud billing account, please refer to Google’s documentation at https://cloud.google.com/billing/docs/how-to/manage-billing-account.
Terra offers optional automatic inactivity logout functionality to Terra Users upon request. This functionality is not offered to Terra Users by default but a User may request that this feature be made available.
Enroll in 15 minutes logout.
Terra enables automatic logout upon 15 minutes of inactivity for a subset of Users. This automatic logout is a hard logout that forces the User out of all Cloud Identities that the User may be logged into. The User is required to re-authenticate to any and all Cloud Identities to regain access to them, including the Cloud Identity that is used to authenticate to Terra. If a company or other entity that is a Terra User requires that their entity’s Users be enrolled in this 15 minute logout, such company or entity is responsible for notifying Broad of this requirement (https://support.terra.bio/hc/en-us/articles/360037598911-Security-logout-for-clinical-researchers) and appointing 1-2 individuals who will function as administrators of this functionality in the Terra end user interface. Broad will provision these administrators access to a Terra group that is enrolled in 15 minute timeout. This group may be managed through the Terra end user interface by administrators, who must be Terra Users, and who are responsible for adding other Terra Users within their entity-level purview to the group.
In order to ensure that only authorized Terra Users get access to a User’s Workspaces or Data Repository datasets hosted in Google Cloud Platform, Terra Users must use Terra’s security features as described below.
Set up and use Terra’s Authorization Domains on your Workspaces.
Terra has a security feature called Authorization Domains that Terra Users must use to strictly define and enforce Workspace permissions. Authorization Domains are like a badge associated with a workspace that allows access only to people with the same badge. They prevent accidentally sharing derived data because Authorization Domains stay with all copies of the original workspace: anyone who wants to access the copy has to be in the Authorization Domain.
If an Authorization Domain that includes only those consented to use the primary data is assigned to the original workspace with the primary data, you don’t need to worry about accidentally sharing sensitive data. If anyone tries to share the cloned workspace with a user who doesn’t have the right badge, they won’t be able to enter.
We have more information about Authorization Domains and guidance on how to set them up here. It is the Terra User’s responsibility to configure and enable Authorization Domains.
If using Terra’s APIs rather than the user interface, please note that Terra Users must, when making the API call to create a Workspace in Terra for a sensitive dataset, set the “enableFlowLogs” parameter to True.
Manage Authorization Domain membership.
Terra Users are also responsible for ensuring that Authorization Domain membership rosters are kept up to date. Terra Users are responsible for adding users to the Authorization Domain, for removing users from it when they no longer need to or are no longer authorized to view the data protected by the Authorization Domain (i.e., if their role within the organization changes, if they leave the organization, etc.), and for regularly auditing who is a member of the Authorization Domain to ensure that only the Users who are supposed to have access to the Workspace data have access to the data. Terra does not do this for you; only the Terra User knows who they have approved to access their data.
Guidance for how to manage an Authorization Domain is contained within the Authorization Domain set up instructions.
Enable Secure Monitoring on Data Repository Datasets
If using the Terra Data Repository service, Terra Users must enable Secure Monitoring on their datasets. To do this, when making the createDataset API call to create a Dataset in the Data Repository service, set the “enableSecureMonitoring” parameter to True. It is the Terra User’s responsibility to notify your Terra representative that they have this requirement; Broad will provide further instructions and/or support in configuring this.
Enroll in data egress protections
Terra is architected to support research. Researchers using the platform have an infallible business requirement to also remove research information from the platform. This business requirement means that Terra is unable to fully prevent data from leaving the platform. However, Terra has the capability to wrap certain datasets in data egress protections. While the data egress protections by design do not wholly prevent the exfiltration of data from Terra, they do provide monitoring of egress, egress rate limiting, and prevention of certain cloud-to-cloud egress pathways. A Customer must enroll a dataset in these protections if they wish to use Terra in a FedRAMP, FISMA, or HIPAA compliant manner, and it is the Terra User’s responsibility to contact their Terra representative with this requirement.
If you are working with controlled-access, PHI, or any sensitive data that requires additional security protections, there are additional steps you are responsible for taking in order to use Terra on Azure in a FedRAMP, FISMA, or HIPAA compliant manner. It is the Terra User’s responsibility to notify your Terra representative that they have this requirement; Broad will provide further instructions and/or support in configuring this.
For additional protections, Customers are recommended to enable Azure Defender for the collection of runtime security data from all cloud resources in their Azure subscription(s) and configure it to connect to Azure Sentinel. Broad, in its operations of Terra, will not have any capability to view or monitor the information gathered from your Azure Defender; it is your responsibility to monitor that information.
Terra is developed by the Broad Institute of MIT and Harvard in collaboration with Microsoft and Verily.
