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, Terra is a FedRAMP authorized system as a Moderate impact system; 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 Terra is unable to enforce without your help. Some controls are shared between Terra and the Customer while others are fully the Customer’s responsibility. These controls are called “Customer Responsibilities.”
By using the Terra system, you acknowledge that you are responsible for adhering to these Customer Responsibilities if you are required to or intend to use Terra in a FedRAMP, FISMA, or HIPAA-compliant manner. All items below are your responsibility unless explicitly stated to be Optional.
As a Terra Customer, you must bring your own Google Identity to Terra. Terra uses Google Authentication, so you need a valid Google Identity in order to register for and authenticate (“log in”) to Terra. Terra does not provision Google Identities for Customer end users to use in order to register for or access the platform. Your users are required to use a Google Identity associated with their corporate/organizational email address.
If your organization does not use Google Identities, you can set up a Google Workspace domain that you administer. From your Google Workspace domain, you will set requirements for all your user accounts as described further in this document. You are also responsible for both provisioning and deprovisioning user accounts, so you’ll have to write some SOPs and dedicate some time/effort to these operational tasks.
As you may have surmised from the above, since each user brings their own Google Identity to the Terra system, Terra cannot enforce account management security controls on those accounts. It is therefore your, the Terra customer’s, responsibility to ensure that your end user accounts meet all Customer End User Account Management requirements.
Implement multi-factor authentication (“MFA”) on all Customer end user accounts.
You must technically enforce that all of the accounts within your Google Workspace domain use MFA. Do this by following the “Turn on Enforcement” steps as described by Google.
But don’t just require MFA; you must also make sure your users are using an approved second factor authenticator.
It is also the Customer’s responsibility to ensure that their users utilize a second factor authenticator that is both (1) separate from the device gaining access to Terra and (2) either FIPS 140-2 validated or NSA approved. We highly recommend the use of hardware tokens, like the FIPS 140-2 validated Yubikeys. We aren’t paid to say this and have no affiliation with Yubico; you can use whatever type of second factor you prefer, as long as it meets these requirements.
Adhere to password requirements.
As end users bring their own Google ID that is used to authenticate to Terra, Broad does not have the ability to enforce password requirements on user accounts. It is therefore the Customer’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.
If your Terra users are provisioned a Google Identity in a Workspace domain that you administer, you are able to technically enforce password strength and rotation requirements on the accounts within that domain. Do this by following the “Enforce and monitor password requirements for users” steps as described by Google! Note that Google refers to password rotation as password expiration. The end result is the same.
Suspend user accounts due to inactivity.
As end users bring their own Google ID 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. Through your Google Workspace administration, you are able to get information on account activity, including inactivity, and take actions based on that information. Google provides guidance on how to “Suspend an individual user” though you may ultimately want to script this activity.
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 to able to access Terra or your data/Workspaces within Terra.
You should have operational SOPs for how to offboard a user.
Through your Google Workspace administration, you should have and follow a documented process for deprovisioning their user account when the user (1) leaves your organization, (2) transfers to another role within your organization that does not have a business requirement to access Terra and/or your data/Workspaces within Terra, or (3) violates information security or privacy policies. Google provides guidance on how to “Suspend an individual user” and how to “Manage or delete Google Workspace users in Google domains.”
Audit and monitor end user accounts.
As end users bring their own Google ID that is used to authenticate to Terra, Broad does not have the ability to audit and monitor end user accounts. It is therefore the Customer’s 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. Through your Google Workspaces administration, you can configure your domain to capture logs for all of these events. Google provides information on “Available audit logs.”
The Terra platform is free for Customers to use but the use of Google Cloud Platform resources for compute and storage do incur costs. These costs are billed to the Terra end user directly from Google Cloud Platform. It is therefore your, the customer’s, responsibility to enable a Google billing account to receive and pay for such charges. 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. We also have a great Terra Support article describing how to set up billing in Terra once you have that Google Cloud billing account.
Great! Now your users are in Terra. There’s still some work you need to do to make sure that only authorized Terra users get access to your Workspaces or Data Repository datasets. First, let’s explain what these concepts are.
Workspaces are dedicated spaces where you and your collaborators can access and organize the same data and tools and run analyses together in Terra. Since Workspaces can be collaborative, Workspace owners or others who have been granted appropriate permissions on a Workspace may invite other Terra users to access the Workspace. Users with appropriate permissions on a Workspace may also be able to clone (make a copy of) that Workspace, which means the data included in that Workspace’s storage bucket would be made available to the new Workspace. We have more information about Workspaces here.
Data Repository datasets are containers holding a set of related data within Terra’s Data Repository, a service that is designed to support complex data schemas and to support the sharing of different cross sections of data. Since full datasets or cross sections of data can be shared, Data Repository dataset Custodians control which other Terra users are granted access to a data resource. We have more information about the Data Repository, including information about datasets within the Data Repository and the user roles within the Data Repository, here.
Set up and use Terra’s Authorization Domains on your Workspaces.
Terra has a security feature called Authorization Domains that Terra Customers should 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 your, the Customer’s, responsibility to configure and enable Authorization Domains in order to use Terra Workspaces in a FedRAMP, FISMA, or HIPAA-compliant manner.
If you use Terra’s APIs rather than our user interface, please note that you 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.
You, as the Terra Customer, are also responsible for ensuring that you keep your Authorization Domain membership roster up to date. You 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 your Authorization Domain to ensure that only the folks who are supposed to have access to your data, have access to your data. Terra does not do this for you; only you (or your organization) know who you have approved to access your 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 security.
If using the Terra Data Repository service, please note that you must enable Secure Monitoring on your datasets in order to use the service in a FedRAMP, FISMA, or HIPAA-compliant manner. 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 your, the Customer’s, responsibility to contact your Terra representative with this requirement; we will give you further instructions and/or support in configuring this.
Enroll in data egress protections Monitoring on Data Repository Datasets security.
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 your, the Customer’s, responsibility to contact your Terra representative with this requirement.
Terra is a secure system but users may access Terra from their own systems (desktop computers, laptops, etc.). It is therefore the customer’s responsibility to ensure that those end user systems are appropriately secure.
Enable endpoint security.
You, the Terra Customer, are responsible for the security of endpoints (desktops, laptops) for your users. 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 Terra to fulfill their research needs. It is your responsibility as the Terra Customer to ensure that you use TLS 1.2+ or a commensurate protocol to protect any information retrieved from Terra while data is in transit.
Terra offers automatic inactivity logout functionality to Terra users upon request. This functionality is not offered to Terra end users by default but it is required that Terra Customers wishing to use our system in a FedRAMP, FISMA, or HIPAA-compliant manner enroll their user base in this feature. Other users may also request that this feature be made available to their user base. Contact your Terra representative for further guidance on how to set up this automatic inactivity timeout for your users.
Enroll in 15 minutes logout.
Terra enables automatic user 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 Google Identities that the user may be logged into. The user is required to re-authenticate to any and all Google Identities to regain access to them, including the Google Identity that is used to authenticate to Terra. If a Customer requires that their users be enrolled in this 15 minute logout, it is the Customer’s responsibility to notify Broad of this requirement and appoint 1-2 individuals who will function as Administrators of this functionality in the Terra 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 User Interface by Administrators, who must be Terra users, and who are responsible for adding other Terra users within the Customer’s purview to the group.
Some Customers are also partners with whom Broad works to develop custom experiences that leverage the Terra system infrastructure. These features are optional Customer Responsibilities but are available for your use if you should require them. If you are interested in such a partnership, please contact your Terra representative. As a partner, depending on the partnership and need, you may have additional Customer Responsibilities as described below.
Provide a user whitelist so that Customer can authorize users based on criteria that are not configurable in Terra.
If a Customer wishes to authorize Terra user access to datasets of which they are the owner, it is the Customer’s responsibility to provide a whitelist of authorized Terra users. This whitelist can be systematically generated through use of a secondary authentication mechanism (account) that is linked to a user’s Terra account through a handshake between Terra and the secondary authentication system.
Enabling PIV authentication.
Terra’s primary authentication mechanism is through Google, leveraging Google’s Oauth 2.0. If a Customer wishes to use PIV credentials to authenticate to Terra, it is the Customer’s responsibility to identify a secondary authentication credential that accepts PIV credentials and that can be linked to the user’s Terra user account. The Customer must inform Broad that use of this linked secondary credential is required for their users and secure approval for Broad to implement a handshake with that authentication mechanism.
Branded portal system use notification.
If a Customer requires that Terra host a branded web portal, it is the Customer’s responsibility to define whether or not a System Use Notification is required to be presented at the login page of the branded portal.
“Acceptable Use Policy” means this legally binding Acceptable Use Policy, as may be amended by us from time to time.
“Broad” means The Broad Institute, Inc., located at 415 Main Street, Cambridge, MA 02142.
“Customer” or “you” means any person who accesses Terra, or who is otherwise subject to the Acceptable Use Policy. If you are accessing or using Terra in your individual capacity, all references to “you” reference you as an individual. If you are accessing or using Terra on behalf of a company or other entity all references to “you” reference both you as an individual and that entity.
“Google Identity” or “Google ID” means a Gmail account, an organizationally-managed GSuite identity, or a Google Apps identity.
“Terra” means the Terra platform, including all associated websites (including terra.bio) and Content uploaded to the platform (other than your Content).
“We” means The Broad Institute, Microsoft, Verily (and any third party operating Terra on behalf of The Broad Institute, Microsoft, or Verily).
Terra is developed by the Broad Institute of MIT and Harvard
in collaboration with Microsoft and Verily.
Terra is developed by the
Broad Institute of MIT and Harvard in collaboration with Microsoft and
Verily Life Sciences.
