As announced in a recent press release, the Broad Institute has been awarded the high profile “FedRAMP Moderate” security authorization for the operation of the Terra platform. In this guest blog post, David Bernick, Chief Information Security Officer at the Broad Institute, gives us insight into the FedRAMP program and explains what this means for researchers using Terra to access, analyze and share sensitive data.
A core piece of our mission is to serve science by enabling secure data sharing at scale, and make possible the federated data analyses that will catalyze the next generation of breakthroughs in biomedical science. Yet for all the sophisticated machinery involved, the success of this entire enterprise relies on something fundamentally human: acts of trust, by individuals and institutions who choose to entrust us with their most personal data, such as genomes and phenotypes.
Part of how we earn that trust is by communicating clearly how we keep data secure, and by having credible third parties affirm our procedures. To that end, the Federal Risk and Authorization Management Program (FedRAMP) is an incredibly valuable framework. FedRAMP Authorization means that multiple auditors (who themselves are audited by the US Federal Government) have looked at every security control we have, as well as the quality of security around each of those controls, and affirmed them.
Importantly, FedRAMP is not a “moment in time” authorization, but rather, evidence that security is an ongoing, growing, real effort. This is critical because the threat landscape is complex and always changing, with bad actors ranging from nation states and state-sponsored attackers pursuing geopolitical agendas, to hackers and criminal enterprises seeking profit such as opportunistic crypto-currency miners looking for spare CPU cycles anywhere. In such a context, information security is about much more than merely stomping out each threat as it appears, like some game of “whack-a-mole”. Abiding by FedRAMP involves having a security program that is flexible and dynamic enough to keep up with these challenges.
A federal standard for excellence in information security
The Federal Risk and Authorization Management Program (FedRAMP) is a US government program that is designed to standardize how federal agencies evaluate the security of cloud-based products and services, while recognizing that certain agencies may have distinct security requirements due to the nature of the functions they perform and of the data they handle and their own levels of risk tolerance.
The program is based on a information security framework called NIST-800-53, developed by the National Institute of Standards and Technologies (NIST), that spells out a set of security and privacy controls designed to protect data on computer systems. Incidentally, those of you in the genomics space might recognize the NIST acronym — yes, it’s the same NIST that is behind the Genome In A Bottle benchmarking framework.
Any organization applying for FedRAMP authorization for a cloud-based product or service has to demonstrate that their security program implements all relevant security controls prescribed in the NIST-800-53 framework. This is done through a series of audits conducted by an authorized third party assessor, called a Third Party Assessment Organization (3PAO), who systematically reviews and tests every security control, and reports their findings to the FedRAMP Program Management Office (PMO). If the third party assessor finds any gaps or issues with the security controls, the applicant has to remediate them, or provide a plan for doing so, within a specific timeframe. The FedRAMP PMO then reviews the findings and audits THOSE findings and remediations. All of this typically involves a lot of back and forth, which can take quite some time; the discussions are both deeply technical and deeply process-driven.
Process diagram for Agency Authorization, Section 4.2 the FedRAMP CSP Authorization Playbook. The System Security Plan (SSP) and Security Assessment Plan (SAP) are developed by the Third Party Assessment Organization (3PAO).
The end result is the coveted “Authority To Operate” or ATO, which is granted to the applicant for the specific service that was subjected to this process. The ATO is delivered with a qualifier that can be “Low”, “Moderate” or “High”, which is based on the type of data that will be handled by the service, and, crucially, how severe the consequences would be if a security breach were to occur. The highest rating is reserved for use cases where a breach could lead to serious material or strategic damages and potential loss of life.
While the ATO process is sponsored by a specific federal agency within the US government who declares that they want to use the service, achieving ATO means that any federal agency can then use that service. Other agencies still have to do their due-diligence, but the process is much faster when a product has ATO. The evaluation and risk assessment steps typically happen much faster, because all the previous documentation, audits, and reports are available for other agencies to use, and they can quickly determine whether the FedRAMP office has affirmed that the service under review operates at or above the level of security they require.
You can see all this reflected in the FedRAMP Marketplace, which lists the number of active authorizations granted to each product or service, with the relevant impact level rating.
Composite screenshot from the FedRAMP Marketplace website showing the entries for Terra, Microsoft Azure and Google Cloud Platform. Any platform that Terra relies on for its operation must have its own FedRAMP ATO.
In our case, Broad Institute is the service provider; the federal agency who sponsored the ATO is the National Heart, Lung and Blood Institute (NHLBI) under the National Institutes of Health (NIH) which is itself under the Department of Health and Human Services (HHS); and Terra is the service for which we received the ATO, rated at the “Moderate” level. Following the logic described above, if another agency, say the Food and Drug Administration or the Veterans Administration, wants to use Terra we’ll be able to leverage all the work we did to get the ATO for NHLBI, and those organizations can re-use all of those assessments and documents. While a FedRAMP ATO isn’t a “rubber-stamp” of approval, it sets a high level of trust for government entities and makes approval processes faster.
Our journey to receiving the FedRAMP Moderate ATO for Terra
This was not our first experience with federal security compliance. We received our first federal ATO under the Federal Information Security Modernization Act (FISMA) for FireCloud, Terra’s precursor, which we originally developed under the Cloud Pilots program of the National Cancer Institute (NCI) to host cancer genomics datasets such as TCGA and TARGET. Like FedRAMP, the FISMA program is based on the NIST-800-53 framework, but it is an earlier implementation that is more dataset-centric. When the original FireCloud platform evolved into Terra, the FISMA ATO still applied for the use of the NCI datasets.
Meanwhile, more NIH institutes and centers were beginning to show interest in using Terra, which gave rise to the vision of combining datasets from multiple federal programs in novel ways to allow for joint analysis in a secure multi-tenant enclave. We could — and did — pursue FISMA ATO for additional federal projects, but we determined that, as we continued to mature our information security program, it would be more logical to pursue FedRAMP ATO.
And so we did; and here we are. This moment is the culmination of 18 months of hard work (in the middle of a pandemic!) by our Information Security and DevOps teams, driven by Sarah Tahiri, Senior Information Security Program Manager in the Broad’s Data Sciences Platform. Sarah’s team wrangled all the teams together to work with each other to ensure all security controls passed review, as well as making sure we had meaningful procedures and policies in place across the board.
It’s difficult to convey adequately how much work this represents. Compared to FISMA, FedRAMP requires additional security controls related to authentication, system development, and operation, as well as increased audits and frequent third-party penetration tests. And of course, the multi-day audit of EVERY security control and sub-control by the third-party auditors with their strict timelines for addressing findings, which is perhaps the most intense part of the process.
In case this sounds like a whole lot of paperwork, well, it is, but it’s also something more: a detailed examination of every part of the system, with live tests to demonstrate that they are real, effective, and function as described. It’s not just an exercise in checking the boxes; you have to prove that you’re able to operate securely and that you have a sustainable program to maintain and evolve that security over time in the face of unknown future threats.
We are immensely proud of our Information Security and DevOps teams for rising to the challenge, and credit Sarah Tahiri’s leadership and dedication for bringing this momentous effort to fruition.
Beyond FedRAMP
Due to the stringency of the FedRAMP risk assessment process, a FedRAMP ATO is widely recognized as a mark of high quality and demonstrable security. Currently, the only other platform in our industry to boast a FedRAMP ATO is DNAnexus; we’re thrilled to join this very exclusive club!
Yet, as the recent executive order from the Biden administration states regarding the necessity to improve the information security of federal government networks, there’s more work to be done. FedRAMP is an incredibly thorough and meaningful program, but in our practice, we aim to go beyond its baseline requirements, which do not fully account for some recent technology developments.
For example, the NIST-800-53 specification does not fully address modern Application Security. Accordingly and of our own initiative, we have implemented certain security controls in Terra that we consider to be critical for application security, such as in-house penetration tests that take into account the context and code of the application, threat modeling as part of our software development process for ALL new features, advanced threat detection methods, and detailed inspections of our software supply chain to ferret out vulnerabilities in third party software that we depend upon.
As daunting as all this additional work may seem, this is something we’re very comfortable with as an organization. It is part of our culture to view baseline requirements as just that, a minimum; to be exceeded, not settled on.
You can read more about our overall security approach here. If you’d like to contact our compliance team, please email infosec@broadinstitute.org.
