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.
[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.
[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.
[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.
