Security in Terra

Both data submitters and analysts need to understand Terra security policies, their persistence, and how they work in the Terra ecosystem to ensure compliance and protect sensitive data. 

Overview: Terra's security posture

An organization’s security posture is defined by a combination of

• the risks within which it operates
• strategic choices about its business priorities, and
• any applicable regulations.

Because the Broad Institute supports the medical research community as it deals with matters of public health, our security posture addresses the rights of the patients whose data make this work possible, as well as the needs and concerns of the researchers.

The Broad Institute’s Terra platform (also known as FireCloud) uses an iterative risk-based approach to implement security at all layers of the system.

• We leverage components from the NIST Risk Management Framework (NIST SP 800-39), the NIST Cybersecurity Framework, and the Security and Privacy Controls for Federal Information Systems and Organizations (NIST SP 800-53 r4).
• Based on the risk to the system and the data contained in the system, 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.
• We work with internal and 3rd party security experts to define the system and security needs of the system, to assess that security controls are implemented, to monitor that controls continue to be effective, and to respond appropriately to incidents or anomalies to address and resolve any issues.

This document focuses on our current security approach. We do not intend to put up a fence and walk away -- we intend for our fence to be continuously tested, probed, repaired, monitored, and improved.

Terra conforms to government standards for securityFISMA compliance is the process of adhering to the Federal Information Security Management Act (FISMA) to protect sensitive information in government systems. FISMA compliance is mandatory for federal agencies and their contractors, vendors, and service providers.

FedRAMP compliance is a government-wide program that ensures cloud services used by federal agencies are secure and meet the appropriate risk impact level.

Government versus system builder roles and methods in platform security

• Government bodies typically
  • write rules to codify expectations
  • accept or reject the risk with some level of verification
  • influence security by enforcing compliance
• System builders (i.e., Terra engineers)
  • Build systems to comply with government regulations
  • Focus directly on security through design and engineering
  • Document how well they comply with government-defined standards, and . Essentially governments .

These complementary roles allow us (the system builder) to address the distinct needs of security and compliance (established by the government) while designing solutions that meet specific mission objectives and timelines.

Relation to Best Practices

We adhere to information security best practices, making use of four proven design concepts

• Authenticate
  All components require authentication at every step, not just the perimeter.
• Authorize
  All data requires explicit authorization to access
• Audit
  All data access is logged (to a different system), with alerts for anomalous events.
• Encrypt
  All data-in-transit and all data-at-rest is encrypted.

By following this principled approach, combined with meeting the compliance requirements, we will implement the core data security functions of Identify, Protect, Detect, Respond, and Recover at all times.

In addition, continual assessment is core to security in Terra. That includes a variety of security automation in the “DevSecOps” mode of operation. This means the code is continually penetration tested, scanned, and tested.

FedRAMP Moderate Compliance

In addition to its FISMA Moderate authorizations, Broad has completed a System Accreditation for the Terra system following the NIST Guide for Applying the Risk Management Framework to Federal Information Systems (NIST SP 800-37) and has been authorized as a FedRAMP Moderate impact system. Under this framework, Terra is annually assessed by a 3rd party to validate continued compliance with the moderate baseline security controls in NIST-800-53, with a particular concentration on Continuous Monitoring and audit controls. It is our goal, using those controls and more, to Identify likely threat sources, Protect against those threats, Detect incoming attacks, Respond to those attacks, and Recover full integrity of all systems, including accurate event reporting.

Multiple Levels of Security (deeper dive)

We take a multi-layer defense-in-depth approach to security. Below are specifics on how we will, over the project lifetime, implement our various layers of security. 

Perimeter Security

• All external facing properties have signature- and non-signature-based intrusion detection and protection systems and will be scanned regularly for vulnerabilities.

Resilient Infrastructure

• Terra uses Google Cloud Platform (“GCP”), which is run and maintained by Google and protected by Google’s security engineering team. Google Cloud Platform has achieved FedRAMP authorization (Package ID FR1805751477.
• Terra leverages Microsoft Azure, including Azure’s B2C authentication module, which is run and maintained by Azure and protected by Azure’s well-regarded security engineering team. This platform has achieved FedRAMP authorization (Package ID F1209051525).
• The GCP and Azure environment senables extreme redundancy and the ability to recover from lost computing assets. 

Hardened Access Controls

• Terra’s infrastructure and application use Google and Microsoft’s Access Control for both authentication and authorization, including 2-factor Authentication. This leverages the cloud service providers’ existing well-tested protections of these services.
• Across applications and infrastructure, no user will be authorized to access data without human action to approve their access. Users will only have the lowest necessary access in adherence with the principle of least privilege. By default, authenticated users can see nothing (deny-by-default). They have to be explicitly authorized to access resources. All privilege escalations are, of course, logged.

Continuous Auditing and Monitoring

• We aggregate logs from all system components. Error and anomaly detection is forwarded to both visual dashboards and real-time alerting systems to support system health remediation and security assessments.
• Our systems are built on REST APIs, so all commands are essentially simple web requests. All of these requests, external and internal, will be logged. 
• Exceptions, errors, and stack traces bubble up to a specialized handler and alert proper personnel, since software failures are often a precursor to an attack.

Secure Deployment and DevOps (https://theagileadmin.com/what-is-devops/)

• Our components are created, destroyed, and deployed by automated code subject to our software development lifecycle. Direct interaction with resources will be minimized by utilizing repeatable, auditable, and remediable processes, which greatly reduces errors.

Code Testing Before Deployment

• Our components will use three testing methodologies to ensure that we don’t introduce insecurity.  
• Threat modeling every service that faces the outside world
• Traditional tests, such as unit testing, integration testing, and end-to-end regression testing. These tests ensure the software works and that no significant bugs are introduced that affect functionality and data integrity.
• Static Code Testing using automated programs that read the code and look for patterns of insecurity, such as places for SQL injection to occur.
• Downstream library analysis, such as looking for vulnerabilities in libraries (and the libraries they use).
• Dynamic Code Testing, such as automatically instantiating fully-functional environments and running attacks against an actual standing site. 

Continual Attacks

• In addition to code testing before deployment, we employ both automated and human-based penetration tests across all assets on a regular basis to look for problems and to ensure our detection systems are working as expected.