Customer Security Requirements

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 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 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. Since each user brings their own Cloud Identity to Terra, we cannot enforce account management security controls on those accounts. This identity used to access terra, also referred to as an end user account, is the authentication mechanism for then accessing Terra.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 on all 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) 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 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.

  • Audit and monitor 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:
  • 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
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. 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.