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.

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.


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

Monday, June 5, 2017

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

Friday, May 26, 2017

Workshop on Trustworthy Scientific Cyberinfrastructure at PEARC17

Please join us for CTSC's Workshop on Trustworthy Scientific Cyberinfrastructure the morning of Thursday, July 13 at PEARC17 in New Orleans. The workshop will have the following schedule:

Time Content
9:00-9:30 Update from the NSF Cybersecurity Center of Excellence (CCoE)
9:30-10:30 Cybersecurity for Small and Medium Science Projects
10:30-11:00 Refreshment Break
11:00-11:30 Security for Science Gateways
11:30-12:30 Community Forum

The workshop concludes with a Community Forum where attendees can share cybersecurity challenges and success stories in an informal setting. CTSC representatives will be on hand to lead the discussion and answer questions. We invite community members to present short lightning talks during the Community Forum. Contact jbasney@illinois.edu to register your lightning talk topic.

View the PEARC17 Schedule for more details on the workshop and other PEARC17 sessions. PEARC17 Registration rates increase on June 1, so register early!

Tuesday, May 23, 2017

CTSC’s Situational Awareness Expanding Collaborations

In an attempt to improve on the security alert service CTSC offers, the Situational Awareness (SA) group within CTSC has recently expanded its monitoring streams and collaborations to include Open Science Grid (OSG) and the European Grid Infrastructure’s Software Vulnerability Group (EGI: SVG). These entities join CTSC’s current collaborations with REN-ISAC and XSEDE in mutually sharing advisories. The immediate benefit of this effort is that CTSC and its collaborators have increased their monitoring channels, enabling a larger window to survey for potential threats to science cyberinfrastructure. This improvement in shared knowledge will better position us, as well as our new partners, to pass on the important alerts to our communities.

To register for CTSC SA advisories, see https://trustedci.org/situational-awareness.

If you're a member of a trust community that would like to share alerts with CTSC, please contact us at alerts@trustedci.org.

Monday, May 8, 2017

CCoE Webinar May 22nd 11am ET: Cybersecurity Research: Transition To Practice (TTP)

Emily Nichols and Dr. Alec Yasinsac are presenting the two-part talk "Cybersecurity Research: Transition To Practice (TTP)," on May 22nd at 11am (Eastern).

Please register here. Be sure to check spam/junk folder for registration confirmation with attached calendar file.
The U.S. National Science Foundation Transition To Practice (TTP) program is critical to the successful deployment and realization of value for NSF-funded cybersecurity research. Transition to Practice has been named a priority by the National Science and Technology Council’s subcommittee on Network and Information Technology Research Development (NITRD), since 2011, as the participating agencies recognize the need to see funded research adopted by the operational community and ultimately make a positive impact on society. Currently, a chasm exists between the output of the academic cybersecurity research community, and the operational Information Technology (IT) community, which acquires system prototypes that often result from later stage academic research components and implements them in operational environments as either proofs of concept or in operations. The goal of the NSF TTP program is to enable NSF-funded cybersecurity research to cross this chasm and become an operationalized asset to add value in our nation’s cybersecurity efforts.
Internet2 Collaborative Innovation Community (CINC UP): Cybersecurity Research Transition to Practice Acceleration Opportunities (Emily Nichols)
Internet2 is leading an NSF funded EAGER project to benefit members as together we develop a comprehensive TTP program with the goal of enabling as many NSF cybersecurity grants as possible to transition to practice in an accelerated fashion. 
Please join us to discuss how together the Internet2 community of NSF funded cybersecurity researchers, IT operations, and institutions including universities, labs, industry members and affiliates can work together to enable the application of cybersecurity research. 
NSF's SATC TTP Ecosystem (Dr. Alec Yasinsac)
NSF is offering substantial resources to support TTP efforts, including TTP training for PIs, match-making services, mentoring services, a best-practices repository, and software development resources. 
A key resource is the SaTC (Secure and Trustworthy Cyberspace) TTP designation. PIs that have mature research results can apply for three year awards up to $500k or four year projects up to $1.2m exclusively to conduct TTP activities. 
In this presentation, we will present the case for TTP, identify the unique aspects of the TTP Designation in the SaTC Solicitation, and will describe elements of the anticipated TTP ecosystem. This talk is relevant for academics of all rank, to research scientists in government and academic laboratories, and industry members that are interested in harvesting NSF-funded cybersecurity research
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."

Monday, May 1, 2017

2016 NSF Community Cybersecurity Benchmarking Survey Report

The 2016 NSF Community Cybersecurity Benchmarking Survey Report is now available:  

https://hdl.handle.net/2022/21355

Benchmarking information is frequently used to develop a common understanding of cybersecurity’s status and norms within a community. The purpose of this survey project was to collect, analyze, and publish useful baseline benchmarking information about the NSF science community’s cybersecurity programs, practices, challenges, and concerns. We received 27 responses to the survey including 16 responses from respondents with annual budgets greater than $1M (including 9 responses from the ~25 NSF Large Facilities).

We hope the results and analysis provide some benchmarking insight and inspire discussion.

Thursday, April 27, 2017

OSiRIS Engagement Summary

OSiRIS (Open Storage Research Infrastructure, NSF award #1541335) is a multi-institutional project aimed a providing a distributed storage infrastructure that allows researchers to manage and share data from their home computing facilities with other partner locations. The University of Michigan, Michigan State, Wayne State, and Indiana University are working together to develop the transparent, high-performance storage infrastructure which will be available to connected locations on participating campuses. The project will provide data sharing, archiving, security, and life-cycle management, all implemented and managed with a single distributed service.

In October 2016, CTSC began an analysis of the new OSiRIS Access Assertions (OAA) design. CTSC and OSiRIS staff worked together via a series of weekly phone calls to review the design of the authentication and authorization framework for OSiRIS. As OSiRIS is an open-source project, all design documentation and related code for OAA is available on GitHub.

Since the OAA design was at an early stage, CTSC asked OSiRIS staff to document the various use-case scenarios which would be addressed by OAA. This resulted in a set of requirements needed by scientists (end-users), system administrators, and network administrators.

Next, CTSC began the review of the core OAA system. It was discovered that OAA borrows concepts from OAuth 2.0 (RFC 6749), including JSON Web Tokens (RFC 7519) and the practice of issuing short-lived access tokens and long-lived refresh tokens. The resemblance of OAA to OAuth 2.0 inspired the team to use the OAuth 2.0 Threat Model and Security Considerations (RFC 6819) as an evaluation framework for the OAA system. Over the course of several weeks, the OSiRIS team used recommendations from the OAuth 2.0 Threat Model to make modifications to the evolving OAA design, as noted in the final engagement report.

The above swim lane diagram, produced by the OSiRIS team during the engagement, helped the CTSC team understand the OSiRIS Access Assertions (OAA) design.

After the review of the core OAA design, the review shifted to the integration of OAA with other OSiRIS components including Ceph and NMAL/perfSONAR. As the integration is still in an early phase, CTSC staff reviewed the integration design for potential issues drawing on knowledge of similar analyses in the past.

OSiRIS is using COmanage Registry for managing groups and roles for researchers and administrators. CTSC staff has significant experience with COmanage, so several conference calls were of the question-and-answer variety where OSiRIS staff were able to ask detailed questions about COmanage and how to best leverage the power of the software for their particular scenarios.

CTSC's involvement early in the design and implementation phase enabled the OSiRIS developers to incorporate several security recommendations before development had proceeded to a point where change would have been painful. CTSC identified no significant weaknesses in the resulting design. CTSC encouraged OSiRIS to apply for a follow-on engagement after implementation is complete, to review design changes that may have occurred during implementation and initial deployment.

Edited to add: See also the OSiRIS blog post on our engagement.

Tuesday, April 11, 2017

Announcing: 2017 NSF Cybersecurity Summit Call for Participation and Student Program

It is our great pleasure to announce the 2017 NSF Cybersecurity Summit for Large Facilities and Cyberinfrastructure. The event will take place Tuesday, August 15th through Thursday, August 17th at the Westin Arlington Gateway near the National Science Foundation Headquarters in Arlington, VA. Attendees will include cybersecurity practitioners, technical leaders, and risk owners from within  the NSF Large Facilities and CI community, as well as key stakeholders and thought leaders from the broader scientific and cybersecurity communities.

Call for Participation (CFP) - Now Open
Program content for the summit is driven by our community. We invite proposals for presentations, breakout and training sessions as well as nominations for student scholarships. The deadline for CFP submissions is June 5th. To learn more about the CFP, please visit: http://trustedci.org/2017-nsf-cfp/

Student Program - Now Open
Each year, the summit organizers invite several students to attend the summit. Students who are interested in complex cybersecurity needs around and new, efficient, effective ways to protect information assets while supporting science will benefit most from attending. Students may self-nominate or be nominated by a mentor or a teacher. To learn more about the Student Program, please visit: http://trustedci.org/students2017/

Monday, April 10, 2017

CCoE Webinar April 24th 11am EDT: HIPAA and FISMA: Computing with Regulated Data



Susan Ramsey and Anurag Shankar are presenting the talk "HIPAA and FISMA: Computing with Regulated Data," on April 24th at 11am (Eastern).

Please register here. Be sure to check spam/junk folder for registration confirmation with attached calendar file.
With cyberattacks and breaches rising exponentially, there is increasing pressure on federally funded scientific and academic institutions to protect regulated data, including identifiable patient data protected by the Health Insurance Portability and Accountability Act (HIPAA), and data collected or processed on behalf of the government, which is subject to the Federal Information Security Modernization Act (FISMA).  Each comes with its own set of cybersecurity requirements, including physical, administrative, technical controls, to be applied using a risk-centric approach.  FISMA specifies the risk methodology to use, namely the National Institute of Standards and Technology (NIST) Risk Management Framework (RMF), but still provides considerable latitude in how it can be deployed.  HIPAA leaves the choice entirely to the practitioner. Organizations are also allowed by both regulations to tailor implementation to fit their size, budget, risk tolerance, etc.  This provides great flexibility, but the flexibility comes at a cost. Without prescriptive checklists and tools from the government, interpreting the regulations can be a nightmare, especially for the newly initiated.  Commercial expertise comes at a premium, and may even be beyond reach due to budget. Fortunately, the news is not all bad.  Cybersecurity has seen great improvements in the scientific and academic community in recent years, with a majority of required controls in place already.  Remaining obstacles generally are policies and procedures, risk assessment, mitigation, and, most of all, documentation. While these take time and effort, the bulk is limited to initial implementation, with considerable gains in security and efficiency.  To illustrate this, this webinar will feature two institutions, the National Center for Atmospheric Research (NCAR) and Indiana University (IU).  They will share their stories of how they faced and overcame the FISMA and HIPAA challenges in their research computing environments, and benefited. The webinar will also touch upon the basics of HIPAA and FISMA, the NIST RMF, and how it can be leveraged for HIPAA and FISMA and other types of cyber compliance.
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."

CTSC helps CC*DNI awardee tune its cybersecurity practices

CTSC helps CC*DNI awardee tune its cybersecurity practices

The University of New Hampshire Research Computing Center’s (UNH RCC’s) mission is to provide information technology (IT) support for the sponsored research community at UNH and collaborate with higher education, industry, and government to create innovative technologies designed to address important social, environmental, and economic needs. UNH RCC is supported in part by CC*DNI NSF CISE Grant #1541430. CTSC and UNH RCC are conducting an engagement looking at UNH RCC’s existing cybersecurity practices in relation to UNH and the scientists it serves. The engagement has the following related objectives:
  • Produce a report within the next month assessing the current state of UNH RCC’s information security program and make specific prioritized recommendations. 
  • Plan and conduct a period of collaborative work culminating in a 2-4 day CTSC site visit at UNH in early June.  During the site visit, meetings, training sessions, and other activities will leverage the report to build momentum for UNH to implement and sustain the plan's prioritized recommendations. 
This engagement is an opportunity for CTSC to work with a program at an institutional level and positively impact the security of the cyberinfrastructure and trustworthiness of the science it supports.


Thursday, April 6, 2017

CTSC Training at GPN/GWLA Annual Meeting

The Great Plains Network and the Greater Western Library Alliance Annual Meeting will be held in Kansas City on May 31st through June 2nd. CTSC will be providing an Incident Response and Log Analysis workshop during the conference. For more information on the conference please refer to the link below. Details for the workshop are on the Schedule page.

http://conferences.k-state.edu/gpn-gwla/

Monday, April 3, 2017

Open Science Cyber Risk Profile Published

In a culmination of efforts, the Center for Trustworthy Scientific Cyberinfrastructurethe NSF Cybersecurity Center of Excellence, and the Department  of Energy’s Energy Sciences Network (ESnet), along with research and education community leaders have published version 1.2 of the Open Science Cyber Risk Profile (OSCRP) -- a living document designed to help principal investigators and their supporting information technology professionals assess cybersecurity risks related to open science projects. A PDF of the OSCRP can be found at https://scholarworks.iu.edu/dspace/handle/2022/21259.

Tuesday, March 14, 2017

2017 NSF Cybersecurity Summit - Save the Date

Save the Date!

Please mark your calendar for the NSF Cybersecurity Summit for Large Research Facilities, planned for August 15-17, 2017, in Arlington, Virginia.  

Stay tuned for more information by following the CTSC Blog (http://blog.trustedci.org/), Twitter feed (https://twitter.com/TrustedCI),  and joining the Trusted CI Forum (https://trustedci.groupsite.com/join/)

Information on prior summits is available at http://trustedci.org/summit/.


Sunday, March 12, 2017

CCoE Webinar March 27th 11am EDT: SDN and IAM Integration at Duke



Duke University's Richard Biever and Charley Kneifel are presenting the talk "SDN and IAM Integration at Duke," on March 27th at 11am (Eastern).

Please register here. Be sure to check spam/junk folder for registration confirmation with attached calendar file.
Over the past 4 years, Duke has established SDN bypass networks, an SDN mediated Science DMZ, and other services that rely on identity data about the users and the equipment at Duke.   One such service is the Protected Research and Data Network (PRDN), which makes use of our Identity Management (IDM) services both for Duke researchers and their collaborators at other institutions. 
In this presentation we will discuss the path that Duke took to implement our network, link the various pieces together and the security model used to protect the network and detect unusual activity.  Web based access to services provided inside of our PRDN allow for simple implementation of multi-factor authentication and we will present some novel methods for providing access to both Windows and Linux services inside of a browser.  We will also discuss Plexus, our Ryu based SDN controller, and our plans around the firewall/proxy management application, Locutus, that allows us to support multiple controllers in different spaces of our network (alternative to flow space firewall).  A short discussion of our ability to integrate with GENI/exoGENI sevices, AL2S, and our regional SDN project will be included.
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."

Wednesday, February 22, 2017

CCoE and OSG kick off engagement to assess HTCondor-CE


The Open Science Grid (OSG) facilitates access to distributed high throughput computing for research across the US, delivering more than 1.2 billion CPU hours to researchers across a wide variety of projects over the last 12 months. The OSG and CTSC are collaborating to assess the security of HTCondor-CE (Compute Element). The HTCondor-CE is the next-generation gateway software for the Open Science Grid (OSG) and is responsible for providing a network service which authorizes remote users and provides a resource provisioning service. Based on the HTCondor software, this CE is a highly-specialized configuration of HTCondor and relies on less-common components, e.g., blahp, the focus of this engagement. HTCondor-CE was developed and adopted to provide the OSG with a more flexible, scalable, and easier-to-manage gateway software.

The primary goal of the CTSC-OSG engagement is to review blahp (pronounced “blop”), part of HTCondor-CE, and to help ensure its design and implementation are secure - that is, it is free of design errors and will function as intended in the face of malicious entities attempting to coerce it to do otherwise.

Monday, February 13, 2017

CCoE Webinar Feb. 27th 11am EST: Practical Cybersecurity Program for (Smaller) Science Programs

Members of the CTSC team are presenting the talk "Practical Cybersecurity Program for (Smaller) Science Programs," on February 27th at 11am (EDT). Our presenters are Susan Sons, Craig Jackson, and Bob Cowles (speaker info).

Please register here. Be sure to check spam/junk folder for registration confirmation with attached calendar file.
Based on CTSC’s cybersecurity program development guide (see trustedci.org/guide), this webinar addresses practical information security tasks for small and medium science projects. The NSF CCoE’s work spans the full range of NSF-funded projects and facilities, and cybersecurity is certainly *not* a one-size-fits-all endeavor.

Some of the topics covered include:
  • Cybersecurity’s relevance to science projects.
  • The complexity and scope of cybersecurity, and how cybersecurity programs can help you cope with that complexity (and protect your science).
  • A handful of “must-do” (and doable!) action items.
This session is appropriate for principal investigators, program officers, IT professionals in research and higher education, research facility managers, and security professionals interested in information security approaches tailored to particular communities. It is not a detailed technical training. There will be significant opportunities for Q&A.
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."

Science Node article on Open Science Cyber Risk Profile

Last week, Science Node published an article on the Open Science Cyber Risk Profile: "Mind the gap: Speaking like a cybersecurity pro."  Dr. Karen Stocks, director of the Geological Data Center at the Scripps Institution of Oceanography at the University of California San Diego, is quoted in the article:
“It is critical that our scientific infrastructure be reliable and trusted,” says Stocks. “The OSCRP provides the most accessible, focused, and practical guidance I know of for a scientist needing to evaluate and assess their cybersecurity.”
Please see the article for more from Dr. Stocks, as well as others involved in the profile.

Thursday, February 2, 2017

The Report of the 2016 NSF Cybersecurity Summit and Request to Select Dates for the 2017 NSF Cybersecurity Summit!


CTSC is pleased to present the report of the 2016 NSF Cybersecurity Summit to the community. The report outlines progress the community has made based on recommendations from the previous year, attendee details and survey results for both the plenary and training portions of the Summit. The report in its entirety can be reviewed here: http://hdl.handle.net/2022/21161

Additionally, we are currently preparing to kick off planning for the 2017 NSF Cybersecurity Summit for Large Facilities and Cyberinfrastructure. One of our first steps will be selecting a date for this year’s summit, and we would like to hear from you, the community regarding the best dates to meet. The summit will be held in Arlington, VA again this year, at the Westin Arlington Gateway. Please follow the below link to the survey containing the dates we have identified as being available and not conflicting with other conferences in the industry, and enter your choices no later than Friday February 10, 2017: https://www.surveymonkey.com/r/FZBH2H7

Friday, January 27, 2017

Apply for an Engagement with the NSF Cybersecurity Center of Excellence (applications due March 17)

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: https://trustedci.org/application/
In its first 4 years, we have 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 your information security program; software assurance-focused efforts; technology or architectural evaluation; training for staff; and more. Applications for engagements to be executed in July - December 2017 are due March 17, 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.

Wednesday, January 11, 2017

2016 Security Awareness Retrospective

As we enter the new year it’s a good time to reflect on what has happened in the last year and the lessons we should be learning from them. The general goal of our situational awareness mission is to inform on threats to the cyberinfrastructure (CI) of research and education centers. With most alerts it can sometimes be hard to identify overall threats not only to CI but also to you as an individual. We try our best to provide information to help you identify where these vulnerabilities may affect your infrastructure. We translate the issue into a more understandable format so you can make better assessments for how it may affect you, how you can detect it and how it can be resolved.


If you have been taking advantage of this service let us know how it’s been going. We would really appreciate your feedback to help us prepare for our annual report to the NSF as well as to improve the Situational Awareness program. Here is the link to the survey:




In the last year we have provided a number of different alerts for core software like OpenSSH and OpenSSL. We announced vulnerabilities for content management systems WordPress and Joomla. There have been alerts for vulnerabilities in the Linux kernel as well. We have even provided some guidance for named vulnerabilities like Badlock, DirtyCOW and HTTPoxy.


Many of these issues we’ve seen in the last year can be identified, mitigated and/or resolved quickly by taking a few extra steps. If you don’t have the time or expertise on site to manage a service, use professionally hosted services that can provide security mitigation and patching quickly. Use regularly scheduled vulnerability scanning services to identify vulnerabilities in your infrastructure such as unpatched systems or exposed services that you’re unaware of. Protect against compromised passwords by enabling multi-factor authentication. Taking these extra steps can go a long way to protect your infrastructure from pending vulnerabilities.


Back in October we posted about Ransomware and ensuring that you are backing up your data. Every year Ransomware attacks have been increasing in number and complexity. We’ve seen this increase in the last year and expect to see another increase in the next year. If you haven’t already invested in a backup solution for your data this is something you should put effort in as soon as possible.


This last year has also seen the rise of a new compromise vector in small internet devices known as the Internet of Things (IoT). These are embedded devices of everyday things that are connected to the internet. These give you the ability to turn lights on and off, adjust your thermostat, open doors, even cook your food all from your phone. These simple devices are not as complex as a desktop computer and are usually designed for ease of use and not for security. Attackers have taken advantage of this lack of security using the ‘Mirai’ malware to build up an impressively destructive botnet. Because these devices are usually not designed to be upgraded remotely it’s likely this botnet will not disappear soon. In the next year we expect to see increased activity from and growth of this botnet.


The ease at which many of these devices can be added to any network can make this a very real threat for your CI. You may also see devices that show up in offices or on your wireless network. The most likely source of IoT devices will be networks for personal living spaces like dorm networks. The introduction of these devices to your network may create unintended vectors for access to your network. In large enough numbers they can potentially cripple your network if they’re compromised and being used in a DDoS attack. This post from Internet2 has a number of options for mitigating DDoS attacks on your infrastructure.


One of the other things we’ve noticed a lot of in the last year are compromised accounts. Yahoo recently announced the compromise of over 1 billion accounts from as far back as 2013. While large public sites like Yahoo often get mentioned in the news, we do still see lists of compromised accounts for organizations like Universities and small businesses. Also we continue to see re-use of passwords across systems, where a password compromise at a commercial service like Yahoo can lead to compromise of a CI account using the same password. To counteract this many sites and organizations have started to roll out multi-factor authentication solutions to protect their users and systems. The introduction of multi-factor authentication is something we’ll likely be seeing more of in the next year and beyond.

Whatever the new year brings we hope our service will help you navigate through them. If you haven’t already signed up for our mailing lists you can find them here. Security alerts are sent to the CTSC Infrastructure Operators Announce List for issues affecting CI. Alerts that affect software development are sent to the CTSC Software Developers Announcement List. We hope this next year is a safe and secure one.

Monday, January 9, 2017

CCoE Webinar Jan. 23rd 11am EST: Open Science Cyber Risk Profile

Our first webinar for the year will be a team presentation on the Open Science Cyber Risk Profile (OSCRP), on January 23rd at 11am (EST) by Von Welch and Sean Peisert.

Please register here. Be sure to check spam/junk folder for registration confirmation with attached calendar file. 
The Open Science Cyber Risk Profile (OSCRP) is a joint project of the Center for Trustworthy Scientific Cyberinfrastructure, the NSF Cybersecurity Center of Excellence, and the Department of Energy’s Energy Sciences Network (ESnet). Over the course of 2016, the CTSC and ESnet organized a working group of research and education community leaders to develop a risk profile for open science. The risk profile is a categorization of scientific assets and their common risks to science to greatly expedite risk management for open science projects and improve their cybersecurity. The working group released the a draft of the OSCRP for public comment in late 2016.
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."

 

Other upcoming webinar(s) of potential interest

  • XSEDE Science Gateway webinar on January 11th at 1pm EST. 
    • Topic: An overview of SGCI services, see original post for more information
  •  NSF's WATCH webcast on August 18th at 12pm EDT
    • Topic: Mapping Interconnection Connectivity and Congestion, see event page for more information