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 at 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.
Terra uses Google authentication and requires that each Terra end user “bring their own” Google Identity. This means that Terra does not create user credentials for you — rather, you tell us what your Google Identity is and we give that Google Identity authorization to access Terra. The user’s Google Identity is required to register for access to Terra. Since each user brings their own Google 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 Google Identity to be used for authentication in Terra.
It is the Customer’s responsibility to procure a Google Identity that will be used to authenticate to the Terra system.
Implement multi-factor authentication on all Customer 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 enforce multifactor authentication enrollment or requirements on these accounts. Customers may choose to use their own GSuite domain to centrally enforce multi-factor authentication on all Google IDs within that domain. Otherwise, it is the Customer’s responsibility to ensure that each individual user enrolls their Google ID in multi-factor authentication. It is also the Customer’s responsibility to ensure that their users utilize 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 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.
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.
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.
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.
Customers are responsible for the security of endpoints (desktops, laptops) for their users. 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 Terra to fulfill their research needs. It is the Customer’s responsibility to ensure that a commensurate protocol is used to protect any information retrieved from Terra while in transit.
Use TLS 1.2+ (or higher) to protect data in transit.
Customers are responsible for protection data retrieved from Terra in transit using TLS 1.2 (or higher) or a commensurate protocol.
Terra is offered to its users free of charge. However, compute and storage costs associated with an end user’s use of Terra incur costs. These costs are billed to the Terra end user directly from Google Cloud Platform. It is therefore the Customer’s responsibility to enable a Google billing account to receive and pay for such charges.
Enable a Google billing account. Terra is free for Customers to use but expenses generated from the use of Google Cloud Platform resources for compute are the Customer’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 end users upon request. This functionality is not offered to Terra end users by default but a Customer may request that this feature be made available to their end users.
Enroll in 15 minutes logout. Terra enables automatic user logout upon 15 minutes of inactivity
for a subset of end users. This automatic logout is a hard logout that forces the end user out of all Google Identities that the end user may be logged into. The end 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 end 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 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 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. 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.
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. If a Customer wishes to enroll a dataset in these protections, it is the Customer’s responsibility to contact their Terra representative with this requirement.
“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 Life Sciences.
Terra is developed by the
Broad Institute of MIT and Harvard in collaboration with Microsoft and
Verily Life Sciences.
