Engagement Completed with IRNC TransPAC Project

CTSC is happy to announce we have completed our engagement with the IRNC TransPAC project (NSF Award #1450904). The TransPAC project developed a cybersecurity plan using CTSC’s Guide to Developing Cybersecurity Programs for NSF Science and Engineering Projects and CTSC assisted them through the process by answering questions and providing advice.  The engagement started with TransPAC’s Master Information Security Policy and Procedures document, in which insight and clarifications were provided to TransPAC through collaborative editing and discussions.  The engagement proceeded on to secondary documents, including: Information Asset Inventory, Information Classification Policy, Network Data Privacy Policy, and Network Acceptable Use Policy.  The result of this engagement was an enhancement to TransPAC’s ability to publish clear and relevant policy documentation regarding its CI for both its members and its peers.

CTSC Staff Present One-Day Training at GPN-GWLA All Hands Meeting

On June 2nd, CTSC’s Warren Raquel and Mark Krenz presented a one-day training workshop at the Great Plains Network & Greater Western Library Alliance annual All Hands Meeting in Kansas City. The training was a two-part presentation on Computer Incident Response and Security Log Analysis. The training was at the request of GPN, and we welcome such invitations in the future.

Warren began the training with a presentation on Computer Incident Response. He walked the attendees through the steps to take when preparing for security incident, how to detect and analyze the incident, and finally how to contain, eradicate, and recover machines and data. He ended the presentation by applying these steps to four different case studies of real security incidents. Warren said the case studies really helped reinforce the main points he wanted the attendees to learn and apply to their IR programs.

Mark presented the afternoon session on Security Log Analysis. He began with the security log analysis life cycle (collection, event management, analysis, and response) and provided examples of real attacks using Bro logs, Apache, Postfix, and more. The presentation gave the attendees ideas on how to improve their security, learn real command-line examples to apply at their organizations, as well as new methods to connect events across logs. Mark said the open Q&A format of the presentation was very rewarding. In one example, the group discussed their shared frustrations with a well known Wordpress plugin vulnerability that allows file systems to be “walked”. Mark then demonstrated a command (shown below) that could be used to detect these attempts to walk the filesystem in Bro and Apache logs.

grep -E "wp-admin.*\.\./.*\” 200 " access_log

While In Kansas City, Mark also had a chance to meet up with followers of his Command Line Magic (@climagic) Twitter account.

Mark’s and Warren’s presentations, as well as many more training materials, can be found on CTSC’s website. To contact us about presenting a training at your event, submit a request to our contact form.

About the GPN & GWLA

The GPN is a non-profit consortium of networks in the Midwest and Great Plains for the purpose of collaboration, cyberinfrastructure, and research. The GWLA is a non-profit consortium of libraries across the central and western US for the purpose of sharing technologies and programs related to scholarly communication and information sciences.

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

CCoE Webinar June 19th 11am ET: Using the Blockchain to Secure Provenance Meta-Data

Dr. Richard Brooks and Dr. Tony Skjellum are presenting the talk "Using the Blockchain to Secure Provenance Meta-Data," on June 19th at 11am (Eastern). Note: Due to a CTSC conflict this presentation is being held a week earlier than our normal schedule.

Please register here. Be sure to check spam/junk folder for registration confirmation with attached calendar file.

Provenance meta-data, also known as data pedigree, is a set of data that explains how information was derived. A number of provenance systems exist. They are useful for finding the sources of errors; allowing system users to have confidence in the materials; and potentially providing legal justification for decisions. An open issue has been how to properly secure this meta-data, in a manner that extends beyond trusting the information providers. Blockchain technology provides a universally accessible ledger of transactions that is the basis of the current generation of crypto-currencies. The blockchain structure provides guarantees of system integrity that make it exceedingly difficult for malicious insiders to tamper with data. Our project adapts blockchain concepts to securing provenance meta-data. The talk we present will include the following topics: 

• A brief survey of provenance systems that discusses security needs; 
• The presentation of three illustrative use-cases that motivate the development of a provenance security framework; • A short tutorial on the structure of the blockchain; 
• A brief overview of the current generation of crypto-currencies; 
• An explanation of what aspects of crypto-currencies are ill-suited to our application; 
• An overview of our system architecture, emphasizing two important points:
• Our ability to integrate existing tools, and 
• The portions of the system that we are developing; 
• A discussion of our current status; and 
• Plans for the next phase.

More information about this presentation is on the event page.

Presentations are recorded and include time for questions with the audience.

Join CTSC's discuss mailing list for information about upcoming events. To submit topics or requests to present, contact us here. Archived presentations are available on our site under "Past Events."