Terra security posture

Anton Kovalsky
  • Updated

Security Posture

An organization’s security approach is a combination of the way it understands the risks within which it operates, strategic choices about its business priorities, and any applicable regulations.  Collectively these define an organization’s Security Posture. The Broad Institute supports the medical research community as it deals with matters of public health, and thus 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.

 

Different groups have different roles and methods in influencing security. Government bodies typically write rules to codify expectations. This is necessary as they do not build the systems directly.  System builders document how well they comply with those standards, and with some level of verification, the government will then accept or reject the risk.  Essentially governments influence security by enforcing compliance.  

 

The system builder in turn can focus directly on security through design and engineering. This necessary difference in how organizations approach assurance leads to a model where we can  consider the differing needs of security and compliance as we design solutions to meet specific mission objectives and implement them in the required timelines.

 

In the case of Broad Institute’s Terra system (also known as FireCloud), we apply 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.

Relation to Best Practices

We aim to 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, a posture of continual assessment is also core. 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

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 well-regarded security engineering team. This platform has achieved FedRAMP authorization (Package ID FR1805751477).
  • The GCP environment enables extreme redundancy and the ability to recover from lost computing assets. 

Hardened Access Controls

  • Terra’s infrastructure and application use Google’s Access Control for both authentication and authorization, including 2-Factor Authentication. This leverages Google’s existing well-tested protections of this service, used for Google internal employees and external users (e.g., GMail).
  • 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 stacktraces 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 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. These methodologies are: 
    • 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 that software works and no significant bugs are introduced that affect functionality and data integrity.
    • Static Code Testing utilizing automated programs that read the code and look for patterns of insecurity such as places for SQL injection to occur.
    • Downstream library analysis -- 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 Dynamic Code testing on every code commit, we will 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.

Was this article helpful?

0 out of 0 found this helpful

Have more questions? Submit a request

Comments

0 comments

Please sign in to leave a comment.