Introduction
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.
1. Customer End User Account Management
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.
2. Endpoint Security
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.
3. Protect Data in Transit
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.
4. Enable Billing
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:
5. Automatic Inactivity Timeout
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.
6. Protect Your Data Using Terra’s Security Features
In order to ensure that only authorized Terra Users get access to a User’s Workspaces
or Data Repository datasets, 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.
7. Additional Responsibilities for Azure users
For customers concerned with their own sensitive data in their Terra on Azure,
Terra provides the ability to enable Azure Defender on the subscription(s) containing
the Terra Managed Resource Groups (MRGs) that hold such sensitive data. Customers
are responsible then for monitoring and logging all aspects of such data and
Broad has no responsibility for the safety and security of such data in customers’
Terra workspaces on Azure at this time.
