Higher Education Regulated Research Workshop Series: A Collective Perspective

Regulated research data is a growing challenge for NSF funded organizations in research and academia, with little guidance on how to tackle regulated research institutionally. Trusted CI would like to bring the community’s attention to an important report released today by the organizers of a recent, NSF-sponsored* Higher Education Regulated Research Workshop Series that distills the input of 155 participants from 84 Higher Education institutions. Motivated by the Higher Ed community’s desire to standardize strategies and practices, the facilitated** workshop sought to find efficient ways for institutions large and small to manage regulated research data and smooth the path to compliance. It identified six main pillars of a successful research cybersecurity compliance program, namely Ownership and Roles, Financials and Cost, Training and Education, Auditing, Clarity of Controls, and Scoping. The report presents each pillar as a chapter, complete with best practices, challenges, and recommendations for research enablers on campus. While it focuses on Department of Defense (DOD) funded research, Controlled Unclassified Information (CUI), and health research, the report offers ideas and guidance on how to stand up a well managed campus program that applies to all regulated research data. It represents a depth and breadth of community collaboration and institutional experience never before compiled in a single place.

Organized by Purdue University with co-organizers from Duke University, University of Florida, and Indiana University, the workshop comprised six virtual sessions between November 2020 and June 2021. Participants ranged from research computing directors, information security officers, compliance professionals, research administration officers, and personnel who support and train researchers.

The full report is available at the EDUCAUSE Cybersecurity Resources page at https://library.educause.edu/resources/2021/7/higher-education-regulated-research-workshop-series-a-collective-perspective. It was co-authored by contributors from Purdue University, Duke University, University of Florida, Indiana University, Case Western Reserve University, University of Central Florida, Clemson University, Georgia Institute of Technology, and University of South Carolina.

See https://www.trustedci.org/compliance-programs for additional materials from Trusted CI on the topic of compliance programs.

* NSF Grant #1840043, “Supporting Controlled Unclassified Information with a Campus Awareness and Risk Management Framework”, awarded to Purdue University
** by Knowinnovation

PEARC20: Another successful workshop and training at PEARC

Trusted CI had another successful exhibition at PEARC20.

We hosted our Fourth Workshop on Trustworthy Scientific Cyberinfrastructure for our largest audience to date. The topics covered during the year's workshop were:

• Community Survey Results from the Trustworthy Data Working Group (slides) 
• Presenters: Jim Basney, NCSA / Trusted CI; Jeannette Dopheide, NCSA / Trusted CI; Kay Avila, NCSA / Trusted CI; Florence Hudson, Northeast Big Data Innovation Hub / Trusted CI
  
• Characterization and Modeling of Error Resilience in HPC Applications (slides)
• Presenter: Luanzheng Guo, University of California-Merced 
  
• Trusted CI Fellows Panel (slides)
• Moderator: Dana Brunson, Internet2
• Panelists: Jerry Perez, University of Texas at Dallas; Laura Christopherson, Renaissance Computing Institute; Luanzheng Guo, University of California, Merced; Songjie Wang, University of Missouri; Smriti Bhatt, Texas A&M University - San Antonio; Tonya Davis, Alabama A&M University
• Analysis of attacks targeting remote workers and scientific computing infrastructure during the COVID19 pandemic at NCSA/UIUC (slides)
• Presenters: Phuong Cao, NCSA / University of Illinois at Urbana-Champaign; Yuming Wu, Coordinated Science Laboratory / University of Illinois at Urbana-Champaign; Satvik Kulkarni, University of Illinois at Urbana-Champaign; Alex Withers, NCSA / University of Illinois at Urbana-Champaign; Chris Clausen, NCSA / University of Illinois at Urbana-Champaign
• Regulated Data Security and Privacy: DFARS/CUI, CMMC, HIPAA, and GDPR (slides)
• Presenters: Erik Deumens, University of Florida; Gabriella Perez, University of Iowa;  Anurag Shankar, Indiana University
• Securing Science Gateways with Custos Services (slides)
• Presenters: Marlon Pierce, Indiana University; Enis Afgan, Johns Hopkins University; Suresh Marru, Indiana University; Isuru Ranawaka, Indiana University; Juleen Graham, Johns Hopkins University
  

We will post links to the recordings when they are made public.

In addition to the workshop, Trusted CI team member Kay Avila co-presented a Jupyter security tutorial titled “The Streetwise Guide to Jupyter Security” (event page) with Rick Wagner.  This presentation was based on the “Jupyter Security” training developed by Rick Wagner, Matthias Bussonnier, and Trusted CI’s Ishan Abhinit and Mark Krenz for the 2019 NSF Cybersecurity Summit.

Trusted CI Completes a Highly Successful Engagement with UC Berkeley

Handling regulated data is becoming a key requirement for supporting research, especially for high performance computing (HPC) service providers who have not previously been subject to rules and regulations.  While the list of institutions with research cyberinfrastructure approved for critical data such as protected health information (PHI) or Controlled Unclassified Information (CUI) is growing, it still remains woefully short.  Any major university effort to accommodate researchers with regulated data adds to the pool of research enablers, while simultaneously protecting sensitive research data.

For HPC service providers that support research sponsored by the NSF,  pursuing compliance also diverts resources, potentially affecting this support.  External help can be invaluable in reducing the impact, especially for providers tackling compliance for the first time.  

Trusted CI recently concluded a highly successful engagement with UC Berkeley that both validated and bolstered UC Berkeley’s nascent regulated data effort, namely a “Secure Research Data and Compute” (SRDC) platform.   The SRDC platform is expected to have a significant impact on UC Berkeley’s ability to enable and empower a wide range of researchers to conduct research with data subject to rules and regulations in scientific fields as diverse as biology, engineering, computer science, and a broad spectrum of social sciences and professional schools such as business, public health, and law.

According to Ken Lutz, Director of Research Information Technology at UC Berkeley: 

“Our engagement with Trusted CI has been very successful and has been an important part of preparing for the launch of our SRDC Platform. While we had already obtained a commitment by senior leadership to develop the platform, the perspective and expertise provided by the Trusted CI team helped us build trust across our complex network of stakeholders. Our UC Berkeley team especially appreciated the broader higher education experience that the Trusted CI team brought to the engagement. Based on this engagement, we feel confident that we are developing a platform and service that will enable our research community to pursue high impact research involving highly sensitive data.”

Initial engagement objectives included a review of SRDC’s design, security and compliance goals and future vision, a comparison of SRDC security against best practices at peer institutions, gap identification, and recommendations on how to fill those gaps.

The engagement spanned eleven 1-hour meetings and an all-day virtual campus visit. The meetings, submitted artifacts, and other input from UC Berkeley enabled Trusted CI to assess the SRDC security architecture, workflows, and current policies and procedures, evaluate and validate the cybersecurity framework UC Berkeley is developing with help from a commercial third party, and gauge UC Berkeley’s approach to regulated data against what peer institutions are doing.

During the virtual campus visit, Trusted CI met many of the other SRDC stakeholders on campus (including the CISO) and did a presentation for a group of these stakeholders that detailed current regulated research data approaches nationally and how UC Berkeley’s effort fits in.

The final product of the engagement was a 21-page report containing specific, prioritized recommendations on how to address the security gaps identified during the engagement (including HIPAA gaps), adopt best practices, and avoid pitfalls while maintaining a healthy balance between usability and security.  Trusted CI also provided policy templates and guidance on how best to leverage the cybersecurity framework recommended by the third party.

Trusted CI benefited from this engagement as well from working alongside a commercial third party and learning about their approach to compliance, and from the addition of another institution that Trusted CI can refer future seekers of compliance to for guidance and counsel.

The success of this engagement is noteworthy in light of the challenges COVID-19 introduced in the midst of the engagement, including the cancellation of a campus visit and face to face interaction, both of which are typically important to the success of highly collaborative projects.

PEARC20: Join us at the Fourth Workshop on Trustworthy Scientific Cyberinfrastructure

Join us at the Fourth Workshop on Trustworthy Scientific Cyberinfrastructure at PEARC20 on Monday July 27th, 8:00am - 12:00pm Pacific Time (11:00am - 3:00pm Eastern Time / 15:00 - 19:00 UTC). The workshop provides an opportunity for sharing experiences, recommendations, and solutions for addressing cybersecurity challenges in research computing. It also provides a forum for information sharing and discussion among a broad range of attendees, including cyberinfrastructure operators, developers, and users.

The workshop is organized according to the following goals:

• Increase awareness of activities and resources that support the research computing community's cybersecurity needs. 
• Share information about cybersecurity challenges, opportunities, and solutions among a broad range of participants in the research computing community.
• Identify shared cybersecurity approaches and priorities among workshop participants through interactive discussions.
  

Schedule

See our workshop page for the full presentation abstracts. The order of presentations is subject to change and will be posted to the workshop page. 

• 8:00 am Pacific / 11:00 am Eastern 
• Community Survey Results from the Trustworthy Data Working Group   
• Presenters: Jim Basney, NCSA / Trusted CI
  Jeannette Dopheide, NCSA / Trusted CI
  Kay Avila, NCSA / Trusted CI
  Florence Hudson, Northeast Big Data Innovation Hub / Trusted CI
• 8:30 am Pacific / 11:30 am Eastern 
• Characterization and Modeling of Error Resilience in HPC Applications 
• Presenter: Luanzheng Guo, University of California-Merced
• 9:00 am Pacific / 12:00 pm Eastern
• Trusted CI Fellows Panel
• Moderator: Dana Brunson, Internet2 
• Panelists: Jerry Perez, University of Texas at Dallas
  Laura Christopherson, Renaissance Computing Institute
  Luanzheng Guo, University of California, Merced
  Songjie Wang, University of Missouri
  Smriti Bhatt, Texas A&M University - San Antonio
  Tonya Davis, Alabama A&M University
  
• 9:30 - 10:30 am Pacific / 12:30 pm - 1:30 pm Eastern ***Break/Lunch***
• 10:30 am Pacific / 1:30 pm Eastern
• Analysis of attacks targeting remote workers and scientific computing infrastructure during the COVID19 pandemic at NCSA/UIUC
• Presenters: Phuong Cao, NCSA/U of Illinois at Urbana-Champaign
  Yuming Wu, Coordinated Science Lab/UIUC
  Satvik Kulkarni, U of Illinois at Urbana-Champaign
  Alex Withers, NCSA/U of Illinois at Urbana-Champaign
  Chris Clausen, NCSA/U of Illinois at Urbana-Champaign
• 11:00 am Pacific / 2:00 pm Eastern
• Regulated Data Security and Privacy: DFARS/CUI, CMMC, HIPAA, and GDPR
• Presenters: Erik Deumens, University of Florida
  Gabriella Perez, University of Iowa
  Anurag Shankar, Indiana University
• 11:30 am Pacific / 2:30 pm Eastern
• Securing Science Gateways with Custos Services
• Presenters: Marlon Pierce, Indiana University
  Enis Afgan, Johns Hopkins University
  Suresh Marru, Indiana University
  Isuru Ranawaka, Indiana University
  Juleen Graham, Johns Hopkins University

For any questions regarding this workshop, please contact workshop-cfp@trustedci.org.

NSF releases JASON report on research security with CUI finding

NSF recently released the JASON report on research security. Quoting Wikipedia, “JASON is an independent group of elite scientists which advises the United States government on matters of science and technology, mostly of a sensitive nature.“

Much of this report focuses on research integrity, that is the “objectivity, honesty, openness, fairness, accountability, and stewardship” of research. For research with confidentiality needs, cybersecurity has a role to play in research integrity, by protecting research such as intellectual property from being unfairly accessed. For open research, cybersecurity still has a large role in assuring data integrity: “
the assurance of the accuracy and consistency of data over its entire life-cycle” which is a small, but critical, part of research integrity and reproducibility.

In that context, this report contains a finding and discussion on CUI and research security:

8. Universities have mechanisms to handle Controlled Unclassified Information (CUI) under existing categories, such as HIPAA, FERPA, Export control, and Title XIII. CUI protection is difficult, but suited to these tasks, however it is ill-suited to the protection of fundamental research areas.

This finding is further discussed in Section 4.2, which concludes with the following statement:

Given the current state of affairs, JASON cannot recommend adoption of a CUI mechanism to secure additional categories of information generated by U.S. universities, beyond those currently covered by applicable laws designed to protect personal information (e.g., HIPAA, GINA, FERPA, Title 13, etc.). Rather, the general principle of creating high walls, i.e., classification, around narrowly defined areas should be adhered to, minimizing conflicts that might adversely affect U.S. open science practices.

A challenge we know many in the community face is internal pressure for all of research cybersecurity to shift to CUI. Trusted CI believes careful consideration is needed to select appropriate cybersecurity based on science mission, and agrees with the JASON report that CUI is not suitable for all research, including a fair amount of NSF-funded research. Trusted CI suggests approaches such as Trusted CI’s Guide to Developing Cybersecurity Programs for NSF Science and Engineering Projects and the emerging Trusted CI Framework are better suited.  We hope this report provides valuable input for ongoing discussions some of you may be having.

Trusted CI Completes REED+ Engagement

The Research Ecosystem for Encumbered Data (REED+) at Purdue University (https://www.rcac.purdue.edu/compute/reed), funded under the Office of Advanced Cyberinfrastructure (OAC #1840043), is a vision to implement a cost-effective ecosystem to manage regulated data. Researchers at Purdue, led by Preston Smith, Director of Research Services and Support, developed a strategic framework to address the compliance requirements for Controlled Unclassified Information (CUI) which is appearing in research sectors, e.g., defense and aerospace.

The foundation of the REED+ framework integrates NIST SP 800-171 and other related publications, including NIST’s Cybersecurity Framework (CSF) and the Big Ten Academic Alliance guidelines. It is intended to serve as a standard for campus IT to align with security regulations and best practices. Leveraging the framework, a single process for intake and contracting can be followed by the university’s Sponsored Programs Office (SPS), Human Research Protection Program (which oversees the IRB), Export Controls and Research Information Assurance (EC/IAO), and Information Technology at Purdue (ITaP) Research Computing division (formally the Rosen Center for Advanced Computing, or RCAC). Moreover, the framework also facilitates a tractable mapping of controlled research to cyberinfrastructure (CI) resources. The overarching goal of the REED+ framework is to enable researchers, administrators, and campus IT to better understand complicated data security regulations affecting research projects.

To assist in developing the framework, Trusted CI engaged with the REED+ team at Purdue from January through June of 2019. The initial step in the engagement was a review of existing documents and processes, followed by exploring proposed policies. Trusted CI found the flow of REED+ framework sound, and soon switched to working with Preston’s team in focusing on specific aspects of the process, e.g., providing controlled research ‘use cases’. The engagement proved especially rewarding, as both the REED+ researchers and Trusted CI came away from the engagement with a greater understanding in the nascent and vanguard processes involved in handling CUI compliance in the domain of research and education.

Trusted CI at the 2019 annual Great Plains Networks All-Hands Meeting May 21-23

Ishan Abhinit conducting log analysis exercise at GPN AHM 2019

Following on the successful workshops Trusted CI staff provided at the 2017 Great Plains Network All-Hands Meeting, The Trusted CI staff was invited back to the event in 2019 by GPN staff. Five members of the Trusted CI staff presented a series of three workshops from May 21st - 23rd at the 2019 Great Plains Networks All-Hands Meeting. The workshops covered log analysis, risk management for regulated data, and developing information security programs for research projects and facilities.

Building a NIST Risk Management Framework for HIPAA and FISMA Compliance - Wednesday, May 22 (Anurag Shankar & Ryan Kiser)
Anurag Shankar and Ryan Kiser led a workshop to prepare attendees to effectively leverage NIST’s risk management guidelines as a tool to address the increasingly heavy demands of regulated data on research workflows. They provided an overview of the requirements for handling different types of regulated data such as PHI and CUI as well as a unified risk-based methodology for adhering to these requirements.

Security Log Analysis - Wednesday, May 22 (Mark Krenz & Ishan Abhinit)
Mark Krenz and Ishan Abhinit presented a half day workshop on Security Log Analysis including a 45 minute exercise developed by fellow Trusted CI colleague Kay Avila. The hands on exercise involved performing analysis on an Apache web server log file to find attacks at 6 levels of difficulty. The workshop also covered important aspects of collecting, organizing and analyzing log files as well as provided specific techniques for finding different types of attacks. Real time polling was utilized as a method of helping enguage with attendees as well as gaining insight into community practices.


A Practical Cybersecurity Framework for Open Science Projects and Facilities- Thursday, May 23 (Bob Cowles)
Bob conducted a workshop to give attendees a foundation in what it means to have a basic, competent cybersecurity program for open science projects. In addition to lively discussion from the participants, the four pillars of the Trusted CI Framework were presented along with the sixteen “musts” that compose the core framework requirements. Participants were provided with the tools for building a cybersecurity program and encouraged to use a set of rational, evidence-based controls as a component of their program.

Left to right: Bob, Anurag, Ishan, Michael, Mark, Ryan

Attending the conference also allowed Trusted CI staff to meeting and provide less formalized cybersecurity discussion and consultation during social events at the conference. While visiting Kansas City, the Trusted CI team also had the opportunity to meet with Michael Grobe, who is a member of the distributed computing community and co-developer of Lynx, one of the first popular web browsers.

The materials presented by Trusted CI at the conference as well as others can be found on the Trusted CI website.

Trusted CI Begins Engagement with REED+

The Research Ecosystem for Encumbered Data (REED+) at Purdue University (https://www.rcac.purdue.edu/compute/reed), funded under the Office of Advanced Cyberinfrastructure (OAC #1840043), has the vision to implement a cost-effective ecosystem to manage regulated data that meets the compliance requirements found in a campus environment, e.g., protecting Controlled Unclassified Information (CUI).

REED+’s approach will integrate NIST SP 800-171 and other related NIST publications into its foundation. This will serve as a standard for campus IT to align with security regulations and best practices. The goal is to create a single process for intake and contracting, and to facilitate easy mapping of controlled research to cyberinfrastructure (CI) resources for the sponsored programs office, human subjects office, and export control office.

With the use of student-developed training materials and instruction, the approach will enable researchers, administrators, and campus IT to better understand previously complicated data security regulations affecting research projects. The goal is that the ecosystem developed from REED+ will enable new partnerships with government agencies and industry partners from the defense, aerospace, and life science sectors.

Trusted CI will engage with REED+ to review its strategic vision in providing CUI compliance across their institution’s CI. To achieve this, Trusted CI and REED+ will first inventory proposed components. Trusted CI will then analyze the components, assess them against other implementations, and provide recommendations. Finally, Trusted CI and REED+ will explore appropriate solutions for security awareness that can facilitate the plan.

The engagement began January, 2019 is scheduled to run to the end of June, 2019.

NIST SP 800-171 and its potential impact on NSF science

By: Grayson Harbour, Scott Russell, Craig Jackson, and Bob Cowles

CTSC has recently seen an uptick in conversations in the community concerning NIST Special Publication 800-171 (SP 800-171) [1] and “Controlled Unclassified Information,” or CUI. In this post, we explain what CUI is, what SP 800-171 is, when and where SP 800-171 applies, and the impact it might have on the NSF science community. As will be elaborated in this post, we are concerned that the requirements of SP 800-171 may evolve into a general purpose set of security requirements that is applied to a wide range of non-federal entities, something SP 800-171 was not intended to do and for which it is not a good fit.  The NSF science community should keep SP 800-171’s limitations in perspective, particularly considering its focus on confidentiality-oriented controls, as opposed to the availability and integrity protections so critical to the science mission and of growing importance in context of ransomware.

Background

NIST SP 800-171 and CUI both fall under the umbrella of federal cybersecurity. The primary federal cybersecurity law is FISMA, [2] which requires federal agencies to implement security controls for their systems commensurate to those systems’ risks. (This process is outlined in detail in the NIST Risk Management Framework, [3] and the controls used are compiled in NIST SP 800-53.[4]) Agencies also have more narrow security requirements arising from other statutes, such as HIPAA. [5] These requirements are typically vague, though, resulting in a hodgepodge of different control sets based on varying agency interpretations of what each law requires. And this system only becomes more complex when agencies try to extend their specific requirements to third parties.

The specific security requirements imposed on federal entities don’t directly affect anyone who isn’t a federal entity. [6] However these regulations can be (and are) imposed indirectly through binding agreements, like procurement contracts, grants, and cooperative agreements. The logic of this is fairly intuitive: data doesn’t suddenly stop needing protection when passed to a contractor. Although we normally associate these requirements with classified data, the same principle applies to unclassified data too. Which brings us to CUI . . .

What is CUI?

Controlled Unclassified Information, or CUI, is exactly what its name suggests: it is (1) unclassified information, that (2) is subject to federal regulatory control. So CUI quite simply is unclassified information that a federal law, regulation, or policy says needs to be protected in some way. But there’s a catch: since we’re in the world of federal cybersecurity, CUI only includes information that is made by or for the federal government. [7] Information non-federal entities make entirely on their own isn’t included, even if there is a law regulating that type of data. [8] This distinction will be important when we discuss scenarios where SP 800-171 could potentially apply.

What is the CUI program?

Before 2010, CUI was handled in different ways by different agencies; DoE, HHS, DoJ: they each applied their own cybersecurity standards. In 2010, the White House decided that the federal government needed to standardize how it handled CUI, so it issued executive order 13556, creating the Controlled Unclassified Information program. The goal here was to create a uniform minimum set of requirements for all CUI handled by the federal government. Rather than the prior hodgepodge, every federal agency would follow the same federal regulation, codified in 32 CFR 2002. [9]

What is SP 800-171?

NIST SP 800-171 is a corollary to the CUI program and 32 CFR 2002, designed to help federal agencies apply the new, uniform CUI standards to non-federal entities that may handle their CUI. It is intended to serve as a point of reference for the terms of binding agreements between federal entities and non-federal entities that receive CUI. Put simply, SP 800-171 is a guidance document; it has no independent regulatory force. This makes sense in context: CUI is by definition information that federal entities have to protect, and the requirement to protect CUI doesn’t disappear when the federal entities hand the CUI to a third party. So federal entities are supposed to incorporate SP 800-171 adherence into their binding agreements with the third parties to ensure those third parties apply the same protections the federal entity is obligated to apply.

In case the preceding paragraph didn’t make sense, it may help to understand how federal regulations work when applied to non-federal entities. Unlike Congress, which can legislate on almost anything, the executive branch can only regulate how executive branch agencies behave, (or enforce powers given to them by Congress). But the executive branch can regulate those third parties indirectly through binding federal agreements (contracts, grants, etc.). It's not the law of the land, but if you want to do business with the federal government, you have to follow their rules. This is why SP 800-171 isn’t just “the law” or “not the law”: it all comes down to what you’ve agreed to.

Ok, but what is SP 800-171?

Now that you know why it exists, what exactly does SP 800-171 require? Quite frankly, SP 800-171 is a list of security controls taken straight from the control requirements for protecting confidentiality in NIST SP 800-53. [10] Although frequently analogized as SP 800-53’s little sibling, this is somewhat misleading: SP 800-171 is focused on confidentiality, and doesn’t include controls whose purpose is primarily integrity or availability. This actually makes perfect sense in context, since the CUI program is mostly standardizing the implementation of federal laws, (most of which are privacy laws), whose primary concern is typically confidentiality.

That being said, not all CUI is made the same, and under the federal CUI program, some CUI has slightly higher requirements than others. For federal agencies, this is boiled down to “CUI-Basic” and “CUI-Specified.” Essentially, CUI-Basic is the floor which no one can pass below, whereas CUI-Specified means that some requirements will be heightened. If this all sounds potentially confusing, don’t worry, the categorization of CUI is laid out in the CUI Registry [11], which helpfully tells you both whether information is CUI, and whether it is CUI-Basic or CUI-Specified. If it isn’t in the CUI Registry, it isn’t CUI. (However, as will be discussed below, the specific terms of your agreement will always be the most important consideration.)

Now here’s where things get tricky, the CUI-Basic/CUI-Specified distinction and the CUI Registry all apply to federal entities, not non-federal entities. Naturally, the intended effect is that they should apply to non-federal entities transitively through binding agreements, but it’s easy to imagine some wires getting crossed in this process. So how will you know what to do?

How do I know if SP 800-171 applies to my project?

Despite all of the potential for confusion, application of SP 800-171 is very simple. If SP 800-171 makes its way into your binding agreement, do SP 800-171. Otherwise, you are not directly obligated to adhere to SP 800-171. As stated above, SP 800-171 is a guidance document, it is not mandatory for non-federal entities unless incorporated as a requirement through some binding legal agreement. So while the terms of this discussion often feel very broad, (both “Controlled Unclassified Information” and “Non-federal Entity” enjoy enormously broad definitions), this is because they are just building blocks for agencies to use when drafting contracts and other binding agreements.

That being said, we’re glazing over a lot of details. For instance, CUI is subject to marking requirements [12],so it is unlikely that you could unwittingly receive CUI. Similarly, there are provisions for challenging the designation of information as CUI if you believe that certain data shouldn’t be covered. But the broader point that must always be emphasized is that this will ultimately depend on what you agree to in your binding agreement. If an organization agrees to meet SP 800-171 for all of their systems, (not just those that handle CUI), they may well be held to this standard. The CUI program is intended only for CUI, but the standards it uses could be applied more broadly.

How might the CUI Program affect the science community?

Putting aside the strict question of “am I bound,” the potentially more salient question is “will I be bound in the future?” This is much harder to answer, but a quick perusal of the CUI Registry should give some indication of whether SP 800-171 might eventually apply to NSF science projects and facilities. The CUI Registry lists several categories of information that a researcher might encounter, store, and subsequently need to protect under the CUI program: student records, export-controlled research, critical infrastructure data, and controlled technical information [13] are all CUI. And as the CUI program continues to expand, the CUI Registry is expected to have more categories added.

There are two basic ways you could imagine the CUI program impacting a researcher: (1) you receive CUI from the federal government specifically for research purposes, or (2) your grant or cooperative agreement incorporates the requirements of SP 800-171 in some form. [14] The first is fairly uncontroversial, but also very limited. The second, however, would be an enormous shift in the research community, and probably a bad one.

Would SP 800-171 be a good thing for the NSF science community?

To put it bluntly: no. SP 800-171 was not designed to advance the science community’s mission, and the requirements it puts in place impose a substantial burden without any evidence of a corresponding benefit. [15] Apart from this basic mismatch in scope and capabilities, we’re also concerned that the approach of SP 800-171 reinforces a checklist mentality toward security (notoriously common in FISMA/NIST RMF environments, despite their lip service to risk management), where problems are solved by predetermined lists of controls. This incorrectly assumes that security is a solved problem, and doesn’t allow for effective risk management. Also troubling is that SP 800-171’s focus on controls may lead organizations to view security as an add-on: something that is slapped onto existing systems to manage their problems, rather than as a core component of system design. Much of our community is designing and building new technology. More troubling still is that SP 800-171 is likely to be quite expensive to implement. After all, SP 800-171 is not a comprehensive information security framework [16]; it is simply a collection of confidentiality requirements arising from federal privacy laws. So it is certainly not tailored for scientific research given its notable lack of focus integrity and availability, two critical concerns for science, despite its high cost.

Ultimately, our biggest concern is that SP 800-171 will come to be seen as a sort of RMF-light: something that is regularly applied as a security baseline to any project or entity that has an agreement in place with a federal entity. As stated above, SP 800-171 was not drafted as a comprehensive security framework for anyone, let alone the science community, and its goals and structure are not in line with the needs and capabilities of the science community. So, although some are beginning to recommend preemptively implementing standards like SP 800-171 as a form of future-proofing against possible federal regulation, we certainly would not go that far. However, considering the possibility that these requirements might find their way into grants and cooperative agreements, the science community should be aware of SP 800-171, its structure, limitations, and burdens, and be prepared to negotiate reasonable confidentiality provisions, perhaps like those controls already in place to protect confidential information at your facility or institution. Increasingly, the science community needs to show that it has effective, efficient approaches to cybersecurity tailored to its mission and the actual risks it faces.

---

[1] http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-171.pdf.

[2] Federal Information Security Management Act of 2002 (FISMA), Pub. L. No. 107-347, Title III, 116 Stat. 2899, (2002), available at http://csrc.nist.gov/drivers/documents/FISMA-final.pdf.

[3] For an overview of the NIST Risk Management Framework, see, e.g., NIST SP 800-37 rev. 1, “Guide for Applying the Risk Management Framework to Federal Information Systems,” (Feb. 2010), available at http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-37r1.pdf.

[4] NIST SP 800-53 rev. 4, “Security and Privacy Controls for Federal Information Systems and Organizations,” (Apr. 2013), available at http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf.

[5] For more information on the HIPAA Security Rule, see, e.g., “Security Rule Guidance,” HHS,  https://www.hhs.gov/hipaa/for-professionals/security/guidance/index.html?language=es.

[6] Certain laws, like HIPAA, regulate both federal and non-federal entities. Our discussion is limited to the ways these laws regulate federal entities.

[7] 32 CFR 2002.4(h) available at https://www.federalregister.gov/d/2016-21665/p-124, (defining “Controlled Unclassified Information” to include only “information the Government creates or possesses, or that an entity creates or possesses for or on behalf of the Government” (emphasis added)).

[8] Although it may not be CUI, the data may still be subject to security regulations, as with HIPAA and the HIPAA Security Rule.

[9] https://www.federalregister.gov/documents/2016/09/14/2016-21665/controlled-unclassified-information.

[10] The specific controls selected are largely equivalent to SP 800-53 Moderate - Confidentiality, but SP 800-171 does omit a select few security controls that are: (1) entirely federal (and therefore wouldn’t make sense to apply to non-federal entities), (2) not directly related to the protection of CUI, or (3) assumed to be implemented by third parties already.

[11] https://www.archives.gov/cui/registry/category-list

[12] The details of the marking requirement are laid out in 32 CFR 2002.20, available at https://www.federalregister.gov/d/2016-21665/p-303. For the various markings used, see https://www.archives.gov/cui/registry/category-marking-list.

[13] “Controlled Technical Information” means “technical information with military or space application that is subject to controls on the access, use, reproduction, modification, performance, display, release, disclosure, or dissemination.”

[14]  Although the definition of CUI only includes data that is made by or for the federal government, there is potentially a great deal of leeway in exactly what data is made “for the federal government,” which may allow for SP 800-171 to creep into a wide range of government agreements. But since this would be a new addition, such a broad interpretation of CUI could be resisted by the third party.

[15] For a discussion of the application and implementation of SP 800-171 in higher education institutions, see “An Introduction to NIST Special Publication 800-171 For Higher Education Institutions,” HEISC, (Oct. 2016), available at https://library.educause.edu/~/media/files/library/2016/4/nist800.pdf.

[16] For an example of a more comprehensive set of security controls, see, e.g., CIS Critical Security Controls, SANS https://www.cisecurity.org/controls/.