Thursday, September 21, 2017

Ask CTSC: Questions for leadership to ask when considering handling regulated data.

We at CTSC field questions from the community about cybersecurity, either send directly to the team or via the email address. To better help a broader portion of the community, we're going to start posting our responses here on the blog so they are available. (Don't worry, if your question is sensitive in some way we'll either answer it privately or work with you to sanitize it). This represents the first of such answers. -Von

Yesterday we received the following question from a member of the community:
What are the key questions that research computing leadership or a VP/VC/Dean of research should be asking themselves if they are considering taking on regulated data?
The question came with "I need this by Friday" plea, so here's our admittedly quick answer. Please chime in with a comment if you have suggestions.

Questions for leadership to ask when considering handling regulated data.
  • How can you best be involved at the contract negotiation phase? A number of folks have success negotiating out regulated data terms from contracts.
  • How do you track demand and judge when is it time to take the compliance plunge? Sometimes it will be one large project that will justify the cost, other times it will be an aggregation of smaller requests and expectation of future need.
  • How do you track the actual need of the researchers? While we tend to think of compliance for infrastructure or projects, the real issue is around the workflows of the researchers from end-to-end. In general you want to implement your compliance infrastructure to satisfy as many workflows, hence projects, as possible.
  • When does outsourcing compliance make sense? At the 2017 NSF Cybersecurity Summit, we heard from three major cloud vendors with compliance solutions and it was clear that while they handle key parts of compliance, it is at most a partnership and responsibility still resides with the institution.
  • What formal processes and mechanisms will you need to institute to manage regulated data contracts?  Ideally, one would have the PI contact the Office of Research Administration, which will then work with the CISO/central IT/research computing/compliance to evaluate needs and provide resources and a security budget for the PI to include in the contract, and help PIs with reporting to the agency (e.g. for FISMA).

  • How will you develop regulatory expertise/training?  Many campuses with medical schools have HIPAA expertise, but other regulations which contracts will likely include going forward, e.g. CUI/NIST 800-171 and FISMA, have not been a concern in academia.

  • How will you manage third parties (e.g. business associates for HIPAA)?   This will require assessments of due diligence and possibly additional costs for services.

  • How will you handle breach notification?

Added based on follow-up questions since the original post:
  • How will you get buy-in from all the impacted parties? This will impact a number of groups on across campus. Some schools have used an initial task force composed of stakeholder to plan.
  • How will you resource ongoing effort? Expect ongoing leadership to take a significant fraction of a person, with additional contributions by many others. As it ramps up, a full-time leader is not uncommon.
Thank you to Anurag Shankar of IU CACR for contributing to this post.

Monday, September 11, 2017

DesignSafe-CI and CTSC Engage for Cyber-checkup

CTSC has initiated an engagement with DesignSafe-CI (DesignSafe) (NSF-1520817, NSF-1612144, NSF-1612843), a component of the Natural Hazards Engineering Research Infrastructure (NHERI) and funded by the NSF under a Cooperative Agreement through the Division Of Civil, Mechanical, & Manufacturing Innovation (CMMI) (NSF-1520817). The scope of the engagement is to perform a cyber-checkup -- a high-level review of the project’s cybersecurity program. The process tailored to DesignSafe’s needs will constitute a fact-finding exercise that delves into DesignSafe’s security processes, policies and protocols. Due to the maturity of DesignSafe’s existing security program, CTSC anticipates the engagement will be completed by November 2017.

CCoE Webinar Sept. 25th 11am ET: Demystifying Threat Intelligence

CERN's Romain Wartel is presenting the talk "Demystifying Threat Intelligence" on September 25th at 11am (Eastern).

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

Threat intelligence has become a very popular keyword among security professionals in the recent years. What is this all about? Is this a service for sale or rather an intangible asset resulting from a trust relationship? Every organization is seeking relevant and target intelligence, ideally at little to no cost and yielding no false-positives. What are the myths and realities? Is threat intelligence a worthy investment? Is it more suitable to favor local or global sources? Are there services or tools that can facilitate threat intelligence management. Beyond obtaining information, an often overlooked aspect are the challenges linked with building the ability to take promptly and effectively action based on specific intelligence. Making good use of threat intelligence is what makes its value, but this requires time and efforts. Yet, a well-designed threat intelligence management and flow may in fact be the only realistic and affordable strategy for our community to mitigate sophisticated threats or well-funded attackers on a daily basis.

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, see our call for presentations. Archived presentations are available on our site under "Past Events."

Tuesday, September 5, 2017

CTSC begins engagement with DKIST Data Center

The DKIST Data Center (NSF AST-0946422) is the operations data management and processing center for the Daniel K. Inouye Solar Telescope (DKIST), which at the time of its scheduled completion in 2019 will be the largest solar telescope in the world. The data center team has the challenge of managing the terabytes of data coming in daily from the summit in Haleakala, Maui, Hawaii to the data center facility in Boulder, Colorado. With assistance from CTSC, the DKIST Data Center team plans to develop a cybersecurity program that will help them focus appropriately on the Integrity, Availability and Confidentiality of the data and services in support of DKIST.

Tuesday, August 15, 2017

CCoE Webinar August 30th 3pm ET: An overview of CTSC Engagements and the Application Process

CTSC's Von Welch is presenting the talk "An overview of CTSC Engagements and the Application Process," on Wednesday August 30th at 3pm (Eastern). Note: The day and time for this event is not during our regular monthly series. Be sure to add it to your calendar.

Please register here. Registration includes a confirmation email with a calendar file (check your spam filters if you did not receive the email).
One of CTSC's core activities is conducting one-on-one engagements with NSF projects and facilities. CTSC has recently launched its call for applications for engagements in 2018, due October 2nd. This presentation will review the benefits and scope of CTSC engagements, as well as the application process. Webinar attendees are encouraged to attend live to ask questions about their project/application.
More information about engagements and the application can be found at:
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, see our call for presentations. Archived presentations are available on our site under "Past Events."

Monday, August 14, 2017

2017 NSF Community Cybersecurity Benchmarking Survey -- Please Respond

Please complete the 2017 NSF Community Cybersecurity Benchmarking Survey.  

The goal of the annual survey is to collect and aggregate information over time about the state of cybersecurity for NSF projects and facilities and produce a report that will help the community a richer understanding of the environment and norms, as well as track changes to the security of the scientific cyberinfrastructure. We want to ensure the survey report is of maximum utility to the NSF researchers, projects, and facilities, and encourage a high level of participation. Your responses will help us meet that goal. We have made minor changes from the 2016 survey to clarify both questions and answers. Participation in the 2017 survey is requested whether or not you responded to the 2016 survey. (See the 2016 survey report at

Each NSF project or facility should submit only a single response. Completing the survey may require input from the PI, the IT manager, and/or the person responsible for cybersecurity (if those separate areas of responsibility exist). While answering specific questions is optional, we strongly encourage you to take the time to respond as completely and accurately as possible. If you prefer not to respond or are unable to answer a question for some reason, we ask that you make that explicit (e.g., by using “other:” inputs) and provide your reason. Please note that we minimize the amount of project-identifying information we collect and will report responses only in the aggregate and CTSC will release results that we believe provide anonymity to the individual project or facility respondents.

The response period closes November 17, 2017.

CCoE Webinar August 28th 11am ET: Stronger Security for Password Authentication

UC Irvine's Stanislaw Jarecki is presenting the talk "Stronger Security for Password Authentication," on August 28th at 11am (Eastern).

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

Passwords are an infamous bottleneck of information security: The users choose them badly and then forget them, and the servers store (at best!) a table of password hashes which, in the all-too-common event that the server is hacked, allows the attacker to recover a large fraction of the passwords using the so-called Offline Dictionary Attack. At the same time, we seem to be stuck with passwords because they form the most user-friendly authentication mechanism we know. Our work in the CICI-sponsored project looks at the security vulnerabilities of current password authentication protocols, including Two-Factor authentication protocols, where the user's password is amended by the presence of an Auxiliary Authentication Device, e.g. a cell-phone capable of displaying a short one-time PIN which the user copies onto her terminal in order to authenticate to the server. We show that with modest changes to the authentication infrastructure, involving either the user's client, or the authentication server, or the Auxiliary Device software, we can make password authentication protocols which are as practical as currently used schemes but have much stroger security properties. Most importantly, the schemes we show eliminate the security vulnerability posed by the server storing password hashes, thus eliminating the possibility of the Offline Dictionary Attack in case of server compromise. In other properties, our schemes offer resistance to so-called phishing attacks and, more generally, failures in the Public Key Infrastructure, where the user misidentifies the public key of the authentication server and, which in current password authentication schemes leads to revealing the user's password to the adversary.
In this presentation we will present an overview of our work on strengthening password and two-factor schemes, published in NDSS'14, Asiacrypt'14, EuroSP'16, AsiaCCS'16, ACNS'17, ICDCS'17, as well as future directions.

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, see our call for presentations. Archived presentations are available on our site under "Past Events."

Thursday, August 3, 2017

UNH Research Computing Center and CTSC cap off high impact, innovative engagement

Campus research centers play an important role in enabling NSF-supported science projects of all sizes. A recently concluded engagement gave us the opportunity to impact open science at the University of New Hampshire, potentially for years to come.  

CTSC and the University of New Hampshire Research Computing Center (UNH RCC)(funded in part by the NSF CC*DNI program, Grant #1541430) have completed a successful engagement to assess and facilitate the reasonable maturation of UNH RCC’s information security program and positively impact the security of the cyberinfrastructure and trustworthiness of the science UNH RCC supports. Following a period of fact-finding, CTSC delivered a containing specific prioritized recommendations grounded in best practices for maturing the UNH RCC program. As a first time experiment, CTSC performed the site visit more than a month after delivering the report (rather than during fact-finding), giving time to plan and conduct a period of collaborative work in preparation for the site visit where meetings, training sessions, and other activities leveraged the report to build momentum, and maximize the its positive impact.

Patrick Messer, Director of the UNH Research Computing Center, states,

“The engagement process with CTSC has already had a direct impact on research computing at UNH. Senior level administrative discussions have led to the inclusion of RCC staff on UNH’s Information Security Services bi-weekly team meetings, bi-weekly leadership team meetings, and strategic retreats. Both the site visit and the report recommendations emphasized practical approaches to improving cybersecurity. UNH research computing now has a 12-month plan with realistic deliverables and efforts addressing the report recommendations are underway. The plan will be reviewed annually to address those CTSC recommendations that are longer term. Although the engagement focused on the cybersecurity of NSF projects, this effort can’t help but positively impact the entire UNH science community. I am grateful that UNH was able to participate in the engagement process.”

Engagement Process

CTSC and UNH RCC engaged in ten one-hour video conference calls in the course of the engagement. These calls were primarily in the fact-finding phase of the engagement and were key to clarifying the computing environment at both UNH and UNH RCC. While web searches provided information about the publicly documented environment, a number of additional documents and diagrams were made available to CTSC. The subsequent report comprised three key sections of recommendations. The first section, titled “Recommendations for Pivotal Actions”, contained two recommendations relating to strategic actions to consider about its approach to cybersecurity in the context of the UNH system. The second section, titled “Recommendations for actions best implemented at the university level, but may remain UNH RCC’s responsibility”, contained six recommendations for high impact actions for consideration if UNH RCC maintains the status quo of relative independence from UNH IT and responsibility for its own day-to-day security practices. These recommendations ranged from selecting a cybersecurity framework to patch management and network monitoring. The third and final section, titled “Recommendations best implemented at the research computing center level”, contained seven actions for consideration regardless of the disposition of the pivotal decisions. These recommendations ranged from asset inventory to change control and developing a core information security policy. Throughout the report we made frequent reference to The CIS Critical Security Controls for Effective Cyber Defense, Version 6.1 and also referenced the Australian Signals Directorate's Essential Eight.

UNH RCC organized and facilitated CTSC’s site visit. We met with a wide range of stakeholders, including the UNH SVP for Research and the UNH CIO, the faculty advisory committee (plus interested researchers), general counsel, and the UNH RCC software development team. Many meetings included not only the engagement team, but also representatives from the UNH IT cybersecurity team. Topics for the meetings included: addressing contractual requirements for protecting Controlled Unclassified Information; developing an Acceptable Use Policy; Freedom of Information Act considerations; and both overview presentations and detailed discussions of the recommendations in the report.  CTSC presented new material on selecting cybersecurity frameworks and control sets, and the group delved into implementation details of the Critical Security Controls.

In the wake of this site visit, UNH RCC has prepared a “summary of the plans for implementing cybersecurity recommendations that resulted from a UNH collaboration with the Center for Trustworthy Scientific Cyberinfrastructure (CTSC)”. In addition to meetings at the university level regarding funding and integration with UNH IT, the summary describes plans for implementation in six- and twelve-month timeframes to improve cybersecurity for the three categories of UNH RCC systems. CTSC will track progress via an evaluation questionnaire at those intervals.

Reflection & Acknowledgements

UNH RCC and the UNH information security demonstrated impressive commitment throughout the engagement. There were always 4 to 6 people from UNH on each and every of the ten conference calls. UNH RCC supported the use of Zoom for teleconferencing and of Box for sharing documents, technologies not used in prior CTSC engagements. UNH RCC maximized the effectiveness of the site visit of the CTSC team with meeting schedules with the engagement team plus others on each of the detailed recommendations, and with senior University officials to make the case for the pivotal recommendations.

CTSC wishes to explicitly acknowledge the UNH participants who made this engagement such a success:

  • CTSC/UNH Engagement Team - UNH Participants
    • Brian Dennis Gaon, UNH Information Security Officer
    • Patrick Messer, Director of the UNH Research Computing Center
    • Scott Valcourt, Director of UNH IT Strategic Technology
    • Tucker Hurton, UNH Research Computing Center Security Officer
    • Robert Anderson, Associate Director of the UNH Research Computing Center
    • Grace Wilson Caudill, UNH Cyberinfrastructure Engineer

  • Other Stakeholders - on-site visit:
    • Jan Nisbet, UNH Senior Vice Provost for Research
    • Stan Waddell, UNH CIO
    • Rori Boyce, UNH Information Security Compliance Officer
    • Tony Dumas, UNH Information Security Operations Engineer
    • Shelby Descoteaux, UNH Information Security Operations Technician
    • Louise Griffin, UNH Senior Director for Research & Sponsored Programs
    • Paul DeMello, UNH Director of Program and Project Management
    • Victor Sosa, UNH Director of Contracts and Export Controls
    • Melissa McGee, UNH Compliance Officer
    • Karyl Martin, USNH Associate General Counsel
    • Theresa Ridgeway, UNH Research Computing Center Program Manager
    • Allan Wright, UNH Manager Research Computing Center Software Development Group
      • Software development group
    • Thomas Baker, UNH Research Computing Center Systems Administrator
    • Jennifer Sorrell, UNH Research Computing Center Business Manager
    • Faculty Advisory Committee plus interested researchers

Monday, July 31, 2017

Apply for an Engagement with the NSF Cybersecurity Center of Excellence (applications due October 2)

Conducting one-on-one engagements with NSF projects and facilities is one of CTSC’s core activities.  To complete the application form and learn more about the process visit our site:

During CTSC’s first 5 years, we’ve conducted more than 20 one-on-one engagements with NSF-funded projects, Large Facilities, and major science service providers representing the full range of NSF science missions.  We support a variety of engagement types including: assistance in developing, improving, or evaluating an information security program; software assurance-focused efforts; identity management; technology or architectural evaluation; training for staff; and more.

Applications for engagements to be executed in January through June 2018 are due October 2nd, 2017. (Slots are limited, so this is a hard deadline!)

As the NSF Cybersecurity Center of Excellence, CTSC’s mission is to provide the NSF community a coherent understanding of cybersecurity’s role in producing trustworthy science and the information and know-how required to achieve and maintain effective cybersecurity programs.

Thursday, July 27, 2017

Call to Present at the CCoE Webinar

The CCoE webinar team is accepting requests to present in 2018. See our call for presentations below.

Do you have cybersecurity capabilities, lessons learned, tools, and/or research to share with the NSF cyberinfrastructure (CI) community? Are you looking for an opportunity to gain visibility for your work? Present your topic at a CCoE webinar! The CCoE webinar series provides monthly presentations on cybersecurity topics applicable to NSF CI. The webinars are open to the public, and the size of the live audience can vary from 20 to 100 or more. We archive the webinar videos to our Youtube channel for later viewing where they often get 100+ views. We invite your presentation proposals!

Potential topics for webinars may include (but are not limited to):
  • Experience deploying a new cybersecurity capability
  • Experience with a new security policy
  • Incident response lessons learned
  • Risk assessment results
  • Security guidelines and lessons learned when deploying a new CI capability (e.g., Science DMZ, Docker containers, software defined networks, etc.)
  • New cybersecurity research results ready for deployment
  • Experience with cybersecurity compliance (HIPAA, FISMA, etc.)
  • Software assurance tools/experiences
Webinar details:
  • Webinars are scheduled the 4th Monday of the month at 11am Eastern
  • Presentations are approximately 45 minutes long with 15 minutes for attendee questions
  • Webinars are recorded and archived for later use
  • Presentations by groups of up to 4 people are encouraged (e.g., a scientist presenting the motivating use case for a new capability, a security officer presenting the risk assessment, and a CI engineer presenting details on the implementation of the new capability)
Interested in presenting? Contact us here and provide the following information for us to use when advertising your presentation:
  • Topic abstract (less than 3000 characters)
  • Brief bio for speaker(s)
  • Related materials (e.g., links to slides or videos from prior presentations)
  • Photo/image of the project, technology, or speaker(s), to include in the event announcement
  • A project website or other URL for additional information
  • Any scheduling constraints (i.e., in which months are you available to present?)
For more information about the CCoE webinar series, including recordings from past presentations, see our webinar page.

Tuesday, July 25, 2017

CTSC presents half-day workshop at PEARC17

C:\Users\jzage\AppData\Local\Microsoft\Windows\INetCache\Content.Word\20170713_094244.jpgC:\Users\jzage\AppData\Local\Microsoft\Windows\INetCache\Content.Word\20170713_095725.jpgOn Thursday July 13th, CTSC held a workshop on trustworthy scientific cyberinfrastructure at PEARC 2017 in New Orleans. CTSC PI Von Welch Started the day with an overview of NSF Cybersecurity Center of Excellence, including CTSC’s mission, vision, and engagements. Co-PI James Marsteller introduced the cybersecurity challenges for smaller projects and its impact on science, followed by Co-PI Jim Basney presenting the key aspects that define a cybersecurity program.

C:\Users\jzage\AppData\Local\Microsoft\Windows\INetCache\Content.Word\20170713_094444.jpgC:\Users\jzage\AppData\Local\Microsoft\Windows\INetCache\Content.Word\20170713_102709.jpgIn the second session, XSEDE’s Nancy Wilkins-Diehr introduced the Science Gateways Community Institute (SGCI), which was established to provide solutions for sustaining science gateways. Von followed with a presentation on security for science gateways, concentrating on three key aspects: secure software development, identity and access control management, and operational cybersecurity. The remainder of the session was dedicated to lightning talks from workshop attendees. Internet2’s Florence Hudson presented on cybersecurity research transition to practice (TTP) acceleration; a concept aimed at accelerating transitions from NSF-funded late-stage cybersecurity research into research and education environments. Tom Barton (also of Internet2) discussed the globally federated system and what support is needed for research activities. He presented a summary of the current state of eduGAIN, which connects different national federation systems across the globe. And lastly, University of Pittsburgh’s Brian Stengel presented the NSF project Towards Security Assured Cyberinfrastructure in Pennsylvania (SAC-PA), which brings PA-based campus CI-practitioners, IT, and security professionals together to facilitate beneficial relationships in the region.
Slides from the workshop, as well as many more CTSC training materials, are available on our website.


Thursday, July 20, 2017

Lodging Deadline Approaching AND Registration Now Closed - 2017 NSF Cybersecurity Summit for Large Facilities and Cyberinfrastructure

This is a reminder that the room block for the 2017 NSF Cybersecurity Summit for Large Facilities and Cyberinfrastructure will close next week on July 28, 2017. In order to take advantage of the group rate, you must reserve your room prior to then. This can be done by following this link.

Additionally, due to overwhelming response, all available spots for the 2017 NSF Cybersecurity Summit for Large Facilities and Cyberinfrastructure have been filled. Therefore, registration has been closed.

The slides from each presentation and training will be posted to the Summit web site shortly after the Summit concludes.

If you have any questions regarding this announcement, please contact Amy Starzynski Coddens at:

Monday, July 17, 2017

Cal Poly Pomona Scholarship for Service Program Engagement

The Scholarship for Service (SFS) program is a partnership between the Department of Homeland Security and the NSF to grant 4-year colleges scholarship funds to encourage students to pursue cybersecurity as a career. Scholarship recipients agree to work for a qualifying federal or state government agency upon graduation as a means of returning the investment in their education with the additional benefit of strengthening critical government infrastructure. Cal Poly Pomona (CPP) received such a grant in 2015 and its program is headed by Professor Mohammad Husain.

Dr. Husain contacted CTSC to request an engagement to provide a hands-on experience in securing cyber infrastructure for the students in the CPP SFS program in the CPP PolySec Lab. After meeting to introduce one another and discuss engagement options, CTSC and CPP agreed to work together to conduct an on-site seminar at CPP for SFS students at CPP and other campuses that introduces the unique cybersecurity challenges of NSF cyberinfrastructure and provides practical training on cybersecurity topics in the areas of expertise of CTSC staff. CTSC staff will encourage the students to consider careers in trustworthy cyberinfrastructure. The seminar is scheduled to occur in mid-October.

We will announce more details about the seminar, and eligible students, as the information becomes available. To learn more about Cal Poly Pomona’s SFS program, see their site.

Wednesday, July 12, 2017

CTSC Completes Engagement With DataONE

CTSC engaged DataONE, an NSF funded project under a Cooperative Agreement through the Division of Advanced Cyberinfrastructure (ACI), in a cyber-checkup -- a high-level review by CTSC of that project’s cybersecurity program.  The engagement began with DataONE undertaking a risk-based survey designed to explore the current state of security within DataONE’s cyberinfrastructure (CI).  To accomplish this, DataONE utilized CTSC’s Risk Evaluation Spreadsheet.  CTSC and DataONE then focused on identifying key areas where DataONE could use its resources most efficiently to strengthen its CI.  Finally, CTSC presented DataONE with a list of opportunities that describe new or updated mechanisms and/or policies in the aforementioned areas such that DataONE could continue to strengthen and advance their cybersecurity posture.

Monday, July 10, 2017

CCoE Webinar July 24th 11am ET: Inaugural Security Program at Internet2

Internet2's Paul Howell is presenting the talk "Inaugural Security Program at Internet2," on July 24th at 11am (Eastern).

Please register here. Be sure to check spam/junk folder for registration confirmation with attached calendar file.
The presentation will cover the introduction of a security program to protect the national R&E network operated by Internet2. Discussed will the methodology to conduct a security risk assessment of the network, the findings from the assessment, and specific improvements undertaken
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."

Thursday, June 29, 2017

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.

Wednesday, June 28, 2017

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.

IMG_20170602_133217.jpgMark 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.

Wednesday, June 7, 2017

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.

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.

[2] Federal Information Security Management Act of 2002 (FISMA), Pub. L. No. 107-347, Title III, 116 Stat. 2899, (2002), available at
[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
[4] NIST SP 800-53 rev. 4, “Security and Privacy Controls for Federal Information Systems and Organizations,” (Apr. 2013), available at
[5] For more information on the HIPAA Security Rule, see, e.g., “Security Rule Guidance,” HHS,
[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, (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.
[12] The details of the marking requirement are laid out in 32 CFR 2002.20, available at For the various markings used, see
[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
[16] For an example of a more comprehensive set of security controls, see, e.g., CIS Critical Security Controls, SANS