2014 NSF Summit Report Published

The Report of the 2014 NSF Cybersecurity Summit for Large Facilities and Cyberinfrastructure is available for download at http://trustedci.org/2014summit/. Many thanks to our colleagues who helped us document this community event and those who contributed white papers.

We'll be using the findings and recommendations, in part, to drive planning for the 2015 summit, to be held at the Westin Arlington Gateway, August 17 - 19.

Security for Software Cyberinfrastructure

NSF's CIF21 Software Vision (NSF 12-113) recognizes that "software is a critical and pervasive component of cyberinfrastructure for science, engineering, and education" and that cyberinfrastructure (CI) software "must be reliable, robust, and secure." What are community best practices for developing reliable, robust, and secure software, and what unique challenges do NSF CI software development projects face?

CTSC will be exploring this topic over the coming months by supplementing CTSC’s existing training materials on secure coding practices with guides that cover additional security topics throughout the software development lifecycle, such as:

• identifying security objectives and addressing security threats during the software design phase to avoid patching for security issues later in the process
• software release engineering to support the integrity and maintenance of deployed software, including security hygiene for developers to safeguard credentials and revoke credentials if compromised
• vulnerability handling processes and software update mechanisms to address software vulnerabilities when they occur
• software maintenance and dependency management for keeping up-to-date on security standards and fixes

We welcome your input and questions as we develop materials (and gather pointers to existing materials) on these topics. Please join the discussion on the CTSC Security Discussion email list.

Cybersecurity at SC14

CTSC team members will participating in a variety of activities at SC14 open to any attendee.

On Tuesday from 2-4pm in Von Welch is organizing a MAGIC meeting in room 204 focusing on international issues in identity management. Speakers include Ann West on “InCommon and International Interfederation”, Harold Teunissen providing an update on identity management in the EU, Tom Barton on “Federated Security Incident Response”, and Nick Jones providing an update on identity management in New Zealand.

On Tuesday from 4-4:30pm, Von Welch will be in the Indiana University booth (1339) presenting on "Cybersecurity for Science."

On Wednesday from 3-4pm and Thursday from 1-2pm, join Adam Slagell and Jim Basney in the NCSA booth (1621) for an informal discussion of cybersecurity at NCSA, including the activities of the Bro Network Security Monitor and CILogon federated identity management projects.

Feel free to contact any CTSC team member directly to chat as well.

New CTSC Cybersecurity Plan published

About a year ago, CTSC published it's own cybersecurity plan. As part of that plan, the plan itself receives an annual review. That review has been completed and version 2.0 of the plan and supporting documents have been published on CTSC's website. The supporting documents include an analysis via Attack Trees, a System Characterization, and a Threat Assessment.

While all these document receives some updates, the updates in the main version 2.9 Policies and Procedures document were:

• Minor changes for clarity.
• Added clause that Google accounts used to access Google drive are used exclusively by a CTSC staff member.
• Added Section 6 on Revocation of Access
• Changed “private” information to “engagement-related” information.
• Labeling of sensitive information only required “whenever feasible.”
• Removed requirement for encryption of sensitive data at rest due to complexity of implementation in a group setting.
• Added annual review of Google account and domain in which CTSC documents reside.

We've learned a lot about developing cybersecurity plans for NSF CI projects over the past two years and when we revise the plan again in 2015, we will use our Guide to Developing Cybersecurity Programs for NSF Science and Engineering Projects as the basis.

POODLE SSLv3 Vulnerability

The POODLE SSLv3 vulnerability [CVE-2014-3566] requires that an attacker already have the vantage point on a network to perform a man-in-the-middle (MITM) attack against a user.  For example, a public WiFi hotspot in a coffee shop or airport would give an attacker a MITM vantage point.

An attacker can then force a client's web browser to downgrade the encryption connection to SSLv3 or lower to exploit the vulnerability in these older versions of SSL.

An attacker will most likely use this vulnerability to steal session cookies to read a victim's email or access other Internet accounts.

Mitigations for system administrators

System administrators should configure their servers to not use SSLv3 or earlier.  Servers accessible from the Internet can be checked using Qualys' SSL Server Test.
https://www.ssllabs.com/ssltest/

Servers that still require SSLv3 to operate with legacy systems should implement the TLS_FALLBACK_SCSV feature to prevent unnecessary protocol downgrades from happening.
https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00

Mitigations for end-users

End-users should keep their web browsers up to date.  Patches will be available to disable SSLv3 or earlier soon.  End-users that don't want to wait for patches can configure their web browsers to disable SSLv3 and earlier as follows.

Chrome
Start the browser using the command-line flag:  --ssl-version-min=tls1

Firefox
Install the SSL Version Control extension:
https://addons.mozilla.org/en-US/firefox/addon/ssl-version-control/

or

Under about:config set security.tls.version.min to 1

Internet Explorer
Internet Explorer 6 does not support TLS.  Users of Internet Explorer 6 should update to the latest version possible on their operating system.

To change the default protocol version to be used for HTTPS requests, perform the following steps:

1. On the Internet Explorer Tools menu, click Internet Options.
2. In the Internet Options dialog box, click the Advanced tab.
3. In the Security category, uncheck Use SSL 3.0 and check Use TLS 1.0, Use TLS 1.1, and Use TLS 1.2 (if available).
4. Click OK.
5. Exit and restart Internet Explorer.

Safari
Unknown.

References

https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/
http://blog.erratasec.com/2014/10/some-poodle-notes.html
https://www.imperialviolet.org/2014/10/14/poodle.html
http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html
https://www.ssllabs.com/ssltest/
https://technet.microsoft.com/en-us/library/security/3009008.aspx
https://www.openssl.org/~bodo/ssl-poodle.pdf
https://access.redhat.com/articles/1232123

CTSC Year Two Report

CTSC's Year Two Project Report has been submitted to NSF and is available at http://trustedci.org/reports/ (along with the year one report). The Executive Summary follows.

The Center for Trustworthy Scientific Cyberinfrastructure (CTSC) is transforming and improving the practice of cybersecurity and hence the trustworthiness of NSF scientific cyberinfrastructure (CI). CTSC is providing the NSF CI community with cybersecurity leadership, expertise, training, and the nexus of a community for sharing experiences and lessons learned. The vision of CTSC is an NSF CI community in which each project knows where it fits in a coherent cybersecurity ecosystem, has access to the tools and expertise to enact a cybersecurity program, participates in the sharing of experiences and collaboration between projects and is greatly benefited by leveraging services from universities, regional and national networks (e.g., CIC, SURA, Internet2).

This report covers CTSC project year two, from October 2013 through September 2014, during which time CTSC engaged with seven NSF CI projects, re-invigorated the NSF CI cybersecurity community by organizing the 2013 and 2014 NSF Cybersecurity Summits for Large Facilities and Cyberinfrastructure, provided the community with a guide and templates for developing a cybersecurity program, and provided training in secure coding, incident response and developing a cybersecurity program.

Nearly 150 individuals, representing over 70 projects, attended one or both of the Summits. The 2014 Summit was particularly successful in building community around a call for participation that resulted in the broader community presenting two training sessions and four experience reports.

Through its first two years, CTSC has now engaged with 13 NSF projects, and trained over 130 CI professionals representing 30 projects. Those numbers include a significant impact on NSF Large Facilities, who comprised 4 CTSC engagees, 14 of the projects who have attended a Summit, and 9 of the projects benefitting from CTSC training.

Awareness of CTSC increased in its second year, with International Science Grid This Week publishing an article on CTSC’s work with LIGO, a NSF solicitation mentioning the CTSC-organized Summit, and CTSC’s blog and website receiving a significant number of views.

This report describes all CTSCs activities in detail, concluding with a set of lessons learned by CTSC over its first two years and the project’s plans for its third year.

V1 of “Guide to Developing Cybersecurity Programs for NSF Science and Engineering Projects” released by CTSC

At the 2013 NSF Cybersecurity Summit Bret Goodrich, Senior Software Engineer of the Daniel K Inouye Solar Telescope(DKIST)/National Solar Observatory(NSO) approached CTSC to discuss how to develop a cybersecurity program for cyberinfrastructure projects.
He was aware of the NIST special publications on conducting risk assessments, applying controls but asked if there was a framework designed to address the unique needs of NSF funded cyberinfrastructure (CI).

At the time, no such framework existed.  After further discussions, CTSC and DKIST began a six month process to create a guide for developing cybersecurity programs crafted to the NSF cyberinfrastructure community. At the completion of this effort the collaboration produced the most comprehensive set of security resources tailored specifically for the CI community.  The guide includes over 18 supporting documents that can be used to kickstart policy development, assisting with risk assessments, data classification and more. A shared goal is to establish a framework that can be adopted by all CI projects.

The latest version of this guide and supporting documents are available on a CTSC managed Google Drive directory, and are available at trustedci.org/guide.

We’re encouraging CI projects to review and support the cybersecurity planning guide by applying the framework to NSF funded projects.

CTSC is seeking comments, suggestions and other feedback to improve the development of these documents for future revisions.

More information about the cybersecurity planning guide or comments to provide feedback can be directed to ‘info@trustedci.org'.

IDM Best Practice: Self Service Password Reset

Self service password reset is an important capability for any scientific cyberinfrastructure (CI) providers that manage passwords for a large user community. Without it, providers risk being overwhelmed by support requests from users who forgot their password and risk being the victim of social engineering attacks against support staff following ad-hoc, manual password reset procedures.

We differentiate between password change and password reset. Password change is when the user enters both current and new passwords to update the password for an account. Password reset is when the user has forgotten the current password for the account and needs to establish a new password.

CI providers should avoid re-implementing the password reset workflow if possible. Using external identity providers (e.g., InCommon and/or Google) avoids the risks of managing passwords directly, enables users to log in via an account that they use regularly (so users are less likely to forget the password), benefits from available security features such as two factor authentication, and leverages the password recovery support of the external identity provider(s). Alternatively, CI providers could use an existing password reset workflow built-in to their web application framework (e.g., Joomla or Laravel) or identity management (IDM) platform.

However, in our experience CI providers still sometimes find the need to implement password reset in their unique environment. In this article, we provide an example email-based password reset workflow and discuss design choices and risks that CI providers should consider when implementing password reset. The workflow assumes that users have previously registered a contact email address that can be used for password resets.

Password Reset Workflow

The goal of the following workflow is to allow a registered user to reset their password without requiring assistance from support staff.

1. On the "Sign In" page, the user clicks the "Forgot Password?" link.
2. The user is prompted to enter their username or registered email address.
3. The user is prompted to "check your email for a password reset code to enter below".
4. The user enters the password reset code on the web form.
5. The user enters their newly chosen password.
6. The user can now sign in with the newly chosen password.

Behind the Scenes

To implement this workflow, the web application performs the following actions behind the scenes:

When the user enters a username or email address (step #2), the web application checks for a match with a valid user account. As with any input provided by the user, the web application sanitizes the username and email address values before querying back-end databases, to protect against injection attacks. In response to the user's submission, the web application does not indicate whether a match was found, to avoid disclosing the existence of registered accounts to unauthenticated users. Instead, whether a match was found or not, the web application displays, "Please check your email for a password reset code to enter below. If you do not receive an email message, please contact the help desk" (step #3). If the username or email address provided by the user does not match a valid account, no further action is taken.

If the web application finds a valid account matching the user's input, the next step is to generate the password reset code (for example, an 8 digit random number), store a salted hash of the reset code (for example, using bcrypt) with a timestamp and the user's account ID, and send the email message to the user's registered email address. The password reset code is a time-limited, one-time-use random "nonce" value to confirm that the user received the message at the registered email address. The web application removes stored reset code entries immediately after use or after the time limit (for example, 15 minutes) has elapsed.

Next, the user enters the password reset code from the email message on the web form (step #4). The web application hashes the entered reset code and searches for a match among the current stored values. If no match is found, the application displays an error and prompts the user to try again (for example, allowing up to 3 tries before aborting the process). If a match is found, the application prompts the user to enter a new password (twice for confirmation) (step #5) and checks that the new password is sufficiently strong. If it is, the application changes the user's password to the new value, removes the stored reset code entry, and sends a confirmation email to the user's registered email address. The user can now return to the standard "Sign In" page and proceed to log in with the new password (step #6).

Password Reset Email Messages

The above workflow sends two email messages to the user's registered email address: 1) the message containing the password reset code and 2) the message notifying the user that the password reset completed successfully. These messages should follow recommended practices for email communications, including a trustworthy From address (in the correct DNS domain) and no HTML content. The messages should also include instructions for contacting the help desk if the user did not initiate the password reset. The user's password should never be sent in email messages.

Logging and Monitoring

The password reset capability can be a target for attacks and a source of user support issues, so it is especially important to log all system activities related to password resets and monitor for unexpected behavior. Log messages should have accurate timestamps and should include the originating IP address for password reset requests.

Risks

The primary risk for the password reset process is the possibility that an attacker could reset a valid user's password and thereby obtain unauthorized access. Potential attack vectors include:

• Disclosure of reset code via email: Since the password reset code is sent over unsecured email, it could potentially be disclosed via email account compromise or network eavesdropping, allowing an attacker to use the code to change the user's password. Enforcing a short lifetime on the reset code limits the window of vulnerability against this attack.
• Network disclosure of passwords: The web application should follow HTTPS best practices to protect passwords against active and passive man-in-the-middle and phishing attacks.
• Exposure of reset code database: Storing reset codes in hashed (salted) form in the web application protects against disclosure of valid reset codes due to inadvertent disclosure of the reset code database.
• Brute force attacks on reset codes: Generating long, random reset codes, valid for only a short time, makes it infeasible for an attacker to successfully guess a reset code through brute force. Aborting the reset process after 3 failed reset code entries also protects against guessing attacks. However, beware making reset codes so long that they are inconvenient for users to input. (8 random digits is a reasonable length.)
• Compromise of the password reset front-end web application: In a system architecture with a back-end authentication system (LDAP, Kerberos, etc.) that may be shared across multiple front-end systems, enabling a front-end web application to reset passwords introduces the risk that an attacker who compromises the web application could reset many user passwords and gain further unauthorized access. Unlike password change (which requires knowledge of a current valid password prior to making password updates), password reset trusts the web application to update passwords without further validation by the back-end authentication system. Isolating the password reset functionality to a dedicated, well-secured front-end system can help to mitigate this risk, as well as logging and monitoring on the back-end system.

Examples

The "Forgot Password?" links on the XSEDE User Portal and on HUBzero provide illustrative examples of self service password reset functionality similar to what is described above.

Self Service and Exceptional Cases

If all goes well with the above workflow, the user is able to reset their password without assistance from help desk staff, hence "self service". However, the user may still need assistance if (for example) they lose access to a previously registered email address and therefore can not complete the self service workflow. It is important to have documented processes for handling these exceptional cases at the help desk without introducing new risks for social engineering attacks. A phone call from the help desk to a previously registered phone number can help re-establish account ownership. However, when in doubt as to the identity of the account holder, it may be better to ask the user to create a new account rather than risk improperly resetting the password on an existing account.

What do you think about self service password reset? Post your comments below.

For more about how CTSC helps NSF projects visit http://trustedci.org/howwehelp.

CTSC CyberCheckups

CyberCheckups are a new service that CTSC offers to NSF science and engineering projects. As a complement to CTSC's other activities, a CyberCheckup is a brief review by CTSC of a project's cybersecurity program. The review takes place over the course of a week, with materials delivered by the project to CTSC at the beginning of the week, CTSC staff having 2-3 days to review, a virtual (or physical if appropriate) meeting to discuss, and then a brief report written by CTSC that provides an overall cybersecurity program assessment with recommendations for improvements. A CyberCheckup can be a good method for identifying topics for a longer-term CTSC engagement.

In April, CTSC conducted a CyberCheckup for HUBzero. CTSC staff reviewed 6 HUBzero documents and produced a 2 page report for HUBzero staff within the one week CyberCheckup period. CTSC staff used a checklist of baseline controls and best practices to identify topics to cover during the CyberCheckup.

If you are interested in a CyberCheckup for your project, please contact us.

Seeking InCommon SPs that would benefit from more R&S particiation

The InCommon Research and Scholarship (R&S) category helps solve a key challenge with federated identity, in that all identity providers which participate automatically release attributes to service providers in the category. This greatly eases the normal process a service provider has to go through of working with individual identity providers to obtain such attribute release.

In order to try and increase participation in R&S,  I am building a list of InCommon service providers that would benefit from more IdPs participating in R&S.

If you are such an SP, please contact me.

Thank you,

Von Welch

Director, CTSC

Illicit Bitcoin Mining: Prevention, Detection, and Response

Bitcoin mining and NSF computational resources have been in the news lately with the NSF OIG report for March 2014 (p. 29-30) reporting on a user of NSF-funded supercomputers using them illicitly to mine for over $8,000 in bitcoins. A similar story emerged regarding a student at Harvard. Additionally, a report from Iowa State reports intruders using a computer illicitly for bitcoin mining. (For more details about bitcoin mining, see the NSF-funded research from UCSD.)

Assuming you have made the decision to disallow bitcoin mining, addressing unauthorized bitcoin mining is a multi-phase process.

Educating your users that bitcoin mining isn’t allowed is a good first step. Make sure you have a clear acceptable use policy (AUP) that states what computing systems can and cannot be used for. For example, the IceCube AUP states that their resources “are intended to provide computing resources for analysis, processing and filtering, and simulation activities for the IceCube project.” Another, stronger approach is to explicitly ban bitcoin and other crypto-currency mining (for example, see the Heroku AUP).

Second, your users may still misbehave, or you may have unauthorized users compromise your system, so consider implementing rules for an intrusion detection system to detect the mining. Since bitcoin mining requires network traffic, monitoring network traffic can be effective. For example, bro_bitcoin is a module for Bro to detect bitcoin mining on the network.

Finally, consider procedures for what happens if you detect bitcoin mining and successfully mined bitcoins. This is an emerging area and there are no standard practices yet. However, an incident response plan should support effective response to this case, including who should be notified and involved given the fungible nature of bitcoins.

(CVE-2014-0224) OpenSSL upgrade, urgent for certain circumstances

This morning a new OpenSSL advisory was announced: https://www.openssl.org/news/secadv_20140605.txt

After analysis, while there are no known exploits at this time, there seem to be some circumstances that lend themselves to such and CTSC urges those with the following circumstances to upgrade ASAP and everyone else to patch to the latest version of OpenSSL as soon as they can during normal business hours.

Circumstances dictating upgrade ASAP:

1. Deployments where both the server and client are using OpenSSL 1.0.1
2. Deployments using Datagram Transport Layer Security (DTLS)

Services that use SSL should be restarted after upgrading in order to load the new libraries.

Since web browsers in general don't use OpenSSL, the first case is most likely with other (e.g. command-line) applications. We expect the second case to be rare in the Grid community.

If your software is impacted, please let CTSC know so we can help communicate your fix.

Credits:

• XSEDE
• Globus: https://support.globus.org/entries/71973746
• Adam Langley: https://www.imperialviolet.org/2014/06/05/earlyccs.html
• ISC: https://isc.sans.edu/forums/diary/Critical+OpenSSL+Patch+Available+Patch+Now+/18211

TrueCrypt's Cryptic Disappearance

There's been a lot of speculation as to the reasons behind TrueCrypt's sudden deprecation by its development team. The main website was redirected to Sourceforge with a vague error message--"WARNING: Using TrueCrypt is not secure as it may contain unfixed security issues"--and without the public mailing list discussion or other early warnings that normally accompany the deprecation of an open source development project.

Silence, however, isn't itself cause for panic. An ongoing audit of TrueCrypt hasn't found anything major, and there is plenty of active interest in evaluating TrueCrypt's current state in the hope of moving it forward. In other words, there's no sign of an existing security problem, and plenty of eyes are looking out for one.

The future of TrueCrypt is yet to be seen.

In the mean time, those wanting to create new TrueCrypt installations should be careful where they get their software. With the TrueCrypt site deprecated, there are plenty copies floating around that nobody's checked for malware or back doors. Ideally, users have the ability to verify a new copy of TrueCrypt by means of digital signature or comparing the checksum against that of a known-good copy.  However, absent that, one's safest bet for acquiring TrueCrypt is to use the git archive maintained by the good folks spearheading the ongoing audit linked earlier in this post: https://github.com/DrWhax/truecrypt-archive

Deprecation of open source software projects happens every day. Some get picked up and continued by others, some vanish over time. While the TrueCrypt team's lack of communication with its community may be frustrating, it doesn't change the code, which has not raised red flags. More context may come to light in the long term, but in the mean time even the most cautious among us can afford to take a deep breath.

Call for Participation - Be heard at the 2014 NSF Cybersecurity Summit!

The 2014 NSF Cybersecurity Summit for Large Facilities and Cyberinfrastructure will take place Tuesday, August 26th through Thursday, August 28th, at the Westin Arlington Gateway near National Science Foundation Headquarters in Arlington, VA. On August 26th, the Summit will offer a full day of information security training. On August 27 and the morning of August 28, the event will follow a workshop format designed to identify both the key cybersecurity challenges facing our community and the most effective responses to those challenges.

Please consider submitting a brief (1-5 page) white paper on unmet cybersecurity challenges, lessons learned, best practices, and/or significant successes. The program committee will select a limited number of these papers for presentation at the Summit. All papers will be included in the Summit report. We are also soliciting proposals to provide security training, and applications for student scholarships to attend.

The submission deadline is June 28 and submissions are welcome from any member of the community. Submit directly to Craig Jackson at scjackso@indiana.edu. For more details on the CFP, visit http://trustedci.org/cfp2014.

For more on the summit in general, see http://trustedci.org/2014summit/.

The Summit is limited attendance, please contact Craig Jackson or one of the other organizers if you are interested an invitation.

We hope to hear from you.

Craig

On Behalf of the Organizers, Jim Marsteller, Von Welch, and Craig Jackson

New CTSC Email Lists for the NSF Cyberinfrastructure Community

Not too long ago, the Heartbleed OpenSSL vulnerability impacted the NSF cyberinfrastructure (CI) community along with many others. CTSC analyzed this vulnerability and published guidance to the community on how CI developers should respond, how users should respond and who was impacted. But we feel we could have done better with better established communication channels to the community.

Based on this experience, CTSC is announcing the creation of three email lists open to the NSF CI community:

• The CTSC Infrastructure Operators Announce List is an announcement-only list for infrastructure providers (e.g. system administrators, devops) who would like to receive updates about security issues that may impact the systems you run or how you provide services.  Traffic to this list is low and sporadic -- we'll only email you when there is something to tell you.
• Subscribe to the CTSC Infrastructure Announcement List

• The CTSC Software Developers Announcement List is an announcement-only list for software developers who would like to receive updates about security issues that may impact the tools or frameworks you use, or how you develop software. Traffic to this list is low and sporadic -- we'll only email you when we really have something to tell you.
• Subscribe to the CTSC Software Announcement List

• The CTSC Security Discussion List is for anyone in the community with questions about security or for discussions about cybersecurity (e.g. CTSC may discuss the severity of a vulnerability on this list before announcing it on the other two lists). Unlike the announcement lists, discussion is encouraged.  Traffic to this list is currently pretty low, but may change based on community interest and needs.
• Subscribe to the CTSC Discussion List
• To email the CTSC Discussion List, please send email to discuss@trustedci.org. (Posting is limited to subscribers to prevent SPAM.)

We hope to see you there!

For the latest information on these lists, please visit http://trustedci.org/ctsc-email-lists/

CTSC Creates Tutorial Series on Cybersecurity

The National Center for Supercomputing Applications (NCSA) security team has produced “Building a Cybersecurity Program”—a 19-part online video tutorial series—as part of the Center for Trustworthy Scientific Cyberinfrastructure’s (CTSC) continuing effort to improve the cybersecurity of NSF-funded computational science and engineering projects. CTSC is a collaborative effort bringing together expertise in cybersecurity from multiple internationally recognized institutions, including NCSA, Indiana University, the University of Wisconsin-Madison, the University of Wisconsin-Milwaukee, and the Pittsburgh Supercomputing Center (PSC).

Science and engineering increasingly rely on computing, digital data and interoperability for the success of their education, collaboration and research efforts. Collaboration across countries and between disciplines is characterized by its open nature, use of unique instruments, large and complex data sets, and rich ecosystems. Appropriate cybersecurity measures for scientific cyberinfrastructure (CI) can therefore look very different from those of commercial CI. Just evaluating and choosing technologies for identity management, authentication, authorization, and auditing are major challenges.

CTSC feels that cybersecurity should not dictate how science is done; rather, it should support and enable the workflows and technology choices made by science teams.

“CTSC grew from the understanding that these teams want to focus on their research endeavors and collaborate across campus and the across the country without having to worry about what might hinder them doing so freely and openly,” says Randy Butler, Deputy Director for CTSC, leader of CTSC Education, Outreach and Training, NCSA Director of the Cybersecurity Directorate and Chief Security Officer. To address that need, NCSA’s security team put together this series of video tutorials, giving an overview of what cybersecurity looks like for a scientific CI project and how to build it in. “We have outlined a specific process, carefully tailored to the science community’s needs. The new videos make that process easy to understand and enact,” continues Butler.

“Many research projects don’t have the dedicated information security expertise, time or resources to develop a comprehensive information security program,” adds James Marsteller, PSC Information Security Officer and member of the CTSC team. Marsteller was one of the authors who developed the class materials that served as the starting point for the video production process. “Researchers and the general public can be assured these training resources were developed by information security professionals who understand the needs of the scientific CI community’s unique needs.”

Patrick Duda, Research Programmer for NCSA Cybersecurity and producer of these CTSC video tutorials, says the team is now looking to expand this original “how to get started” idea into a full blown, one-stop resource for all things cybersecurity series, “It’s looking at the community that we are working with and saying ‘what is it that a lot of people are struggling with right now and focusing on those particular topics over time.”

Duda imagines that, from here, the team will begin to focus on writing and producing tutorials delving deeper into passwords and password management as well as identity management. They hope to have five new videos posted this summer.

Keep up on project happenings by following the CTSC blog and continue to be on the look out for new videos posted to the project’s online video tutorial space

May 28 IAM Online: Good Federation Citizenship

CTSC's Jim Basney will be one of the presenters at the Wednesday, May 28 IAM Online webinar on Good Federation Citizenship. The webinar will cover many recommended practices for participants in the InCommon federation.

Why is "good federation citizenship" especially important for scientific cyberinfrastructure (CI)? Often CI represents the "long tail" of federated services, with collaborating scientists from many institutions using federated identities to access CI. This widely distributed user community makes it particularly challenging to support consistent user experience, effective error handling, and appropriate security incident response.

Visit www.incommon.org/iamonline for more details on joining the webinar.

CTSC Advice on Cybersecurity for NSF IRNC Solicitation

NSF’s IRNC solicitation has the following special award condition:

The awardee is responsible for security of all equipment and information systems funded directly or indirectly by this award. The awardee may be required to present to the cognizant NSF Program Officer and Grants and Agreements Officer an IT security plan addressing policies and procedures for review and approval within 60 days of award. The plan should include evaluation criteria that will measure the successful implementation and deployment of the plans, policies and procedures.

CTSC has the following advice when crafting this security plan, some of which you may want to mention in your proposal:

1. When considering cybersecurity, consider the security of the network routing, monitoring and operations infrastructure, as well as the information security needs of the endpoint customers you are serving.
2. Review the outcomes of the Security at the Cyber Border workshop which discusses the shared cybersecurity responsibilities of link operators and the organizational endpoints they serve. The report also discusses challenges of making network data available to researchers.
3. When considering the cybersecurity of the network, take a risk-based approach as described by NIST and CTSC. CTSC has online training on developing a risk-based cybersecurity program.
4. For monitoring needs, consider Bro and the NSF-funded Bro Center of Expertise.

Finally, CTSC exists to help NSF project with cybersecurity challenges. We can give your plan a quick review for completeness, or collaboratively help you address challenges. Please feel free to contact us either before or after proposal submission.

Seeking CC-NIE projects for peer-to-peer cybersecurity reviews

Last week I had the opportunity to speak about cybersecurity for science at the NSF CC-NIE PI meeting.  As I mentioned in my presentation, CTSC is offering to facilitate cybersecurity peer reviews between CC-NIE PI projects. CTSC will provide a framework and guidance for the reviews, and facilitate them to make sure they complete successfully. We're excited about this process as it represents something that can both scale to the 80+ CC-NIE projects as well as help the projects share practices and build up expertise.

We've got one project already interested, if there are others, please let me know.

If you are a NSF project outside of the CC-NIE program and this sounds interesting, please let me know as we're interested in expanding this program if is proves successful.

OpenAuth 2.0/OpenID "Covert Redirect": Known issue

Today an security issue "Covert Redirect" with OAuth 2.0 and OpenID has been in the news[1][2].

This issue is not new and is discussed in Section 4.2.4 of the OpenAuth specification, which provides a discussion of countermeasures:

• Require clients to register any full redirect URIs (Section 5.2.3.5).
• Don't redirect to a redirect URI if the client identifier or redirect URI can't be verified (Section 5.2.3.5).

Statements from the CILogon developers on the sciencegatewaysecurity.org discuss email list indicate they do not believe it is vulnerable to these attacks.

Added at 4:09pm ET: Nice description of the attack by Jesper Jurcenoks
Added 5/5 10:42am ET: CSO Online article: "Covert Redirect isn't a vulnerability, and it's nothing like Heartbleed"

[1] http://tetraph.com/covert_redirect/oauth2_openid_covert_redirect.html
[2] http://www.cnet.com/news/serious-security-flaw-in-oauth-and-openid-discovered/

HTTPS Best Practices

Using HTTP Over TLS (HTTPS or Hypertext Transfer Protocol Secure) helps users ensure that they are connecting to the correct web site and that their communications are protected from eavesdropping and tampering in transit. Using HTTPS for banking and e-commerce web sites is an obvious requirement, but HTTPS is also valuable for scientific cyberinfrastructure (CI), where users log in to access valuable scientific resources and rely on the integrity of their research data. Always-On-SSL describes the recommended best practice of enabling HTTPS across an entire website, rather than only specific areas of the site, to protect the user's entire web session.

The first step to enable HTTPS on a web site is to obtain a certificate for the site. CI providers should use HTTPS certificates issued by certificate authorities that are well known to standard web browsers so users do not learn to click through security warnings for so-called self-signed certificates. In many cases, CI providers can obtain HTTPS certificates from their home campus' IT department, which may be participating in the InCommon Certificate Service program or have an established contract with another certificate provider.

Tools and guides are available to assist with maintaining a secure HTTPS configuration. The Qualys SSL Server Test tool analyzes a site's HTTPS configuration to identify problems and areas for improvement. Qualys updates their test tool to check for the latest HTTPS security issues (such as the recent Heartbleed bug), so using the tool periodically can help verify that a site's HTTPS configuration remains up-to-date. Comodo and DigiCert also provide HTTPS test tools. For up-to-date HTTPS server configuration recommendations and examples, see the guides provided and maintained by Mozilla and Qualys.

What are your HTTPS best practice questions or recommendations? Post your comments below.

For more about how CTSC helps NSF projects visit http://trustedci.org/howwehelp.

Secure Coding tutorial accepted at XSEDE'14

Prof. Bart Miller will present his Secure Coding tutorial at XSEDE'14 on July 14th. With the recent coding flaws found in OpenSSL, this subject has become even more timely.

Watch this blog or the CTSC Twitter feed for more details.

LIGO and CTSC Collaborate with InCommon to Advance International Identity Federations

(5/28/2014 Update: ISGTW has run an article on this collaboration.)

A significant collaboration effort between LIGO and CTSC bore fruit this week when InCommon signed the eduGain declaration, a significant step in connecting the main identity federation in the U.S. with peer identity federations worldwide. Such peering is key to enabling international research collaborations such as the LIGO Scientific Collaboration, which has members institutions in 22 nations on five continents.

The LIGO and CTSC collaboration helped launch InCommon’s current interfederation effort by bringing this key international research collaboration use case to InCommon. CTSC and LIGO personnel (Jim Basney and Warren Anderson) chaired InCommon’s Interfederation subcommittee from its inception until now. In this role they worked with InCommon staff, notably John Krienke, to determine the best policy and technical path forward for interfederation.

Federated identity allows science facilities to leverage existing user logins at campuses and research institutions, removing the password management burden from those facilities and eliminating the need for scientists to use separate passwords when accessing those facilities. Enabling federations to interoperate across national boundaries expands the utility of federated identity for international collaborations.

The products from the LIGO and CTSC engagement are:

• Final Report for LIGO Engagement
• A Study of Three Approaches to International Identity Federation for the LIGO Project 
• InCommon Membership in eduGAIN: the LIGO Perspective
• Presentation: INFED

CTSC Engagement: Helping IceCube enhance a well-established cybersecurity program

In the CTSC-IceCube engagement, personnel from both organizations worked together to assess IceCube’s current cybersecurity program, and identify areas for improvement.  As a result, CTSC proposed a cybersecurity improvement plan for IceCube’s cyberinfrastructure, which is available publicly at http://trustedci.org/icecube/.

The CTSC team found IceCube to have a relatively mature cybersecurity program in comparison to other CI projects of similar size.

The first step in the process was to conduct a risk assessment of the IceCube project to identify assets, risks, threats and vulnerabilities. The assessment included a review of existing IceCube security policies and procedures. Members of both CTSC and IceCube participated in the assessment process to categorize and weight identified risks.  This analysis was used to determine the best way resources can be applied to further strengthen IceCube’s cyberinfrastructure.  

We thank and acknowledge the IceCube team, particularly Steve Barnet, Gonzalo Merino, Paul Wisniewski, and Matt Newcomb, for the collaborative effort and for IceCube’s commitment to information security.

Which cyberinfrastructure components are impacted by Heartbleed?

This table captures Heartbleed vulnerability information about CI components that we are aware of. If you have information to add, please send email to info@trustedci.org

Direct link to Google Spreadsheet 

Changelog:

• 4/10 11:02am ET: Added GSI-OpenSSH and MyProxy. Clarified Globus includes GridFTP and GRAM.
• 4/10 12:17pm ET: Added specific links for MyProxy and GSI-OpenSSH
• 4/11 7:38am ET: Added HTCondor, changed to Google Spreadsheet
• 4/11 8:08am ET: Added Perfsonar
• 4/15 4:12pm ET: Added XSEDE User Portal (4:58pm replaced text with URL)
• 4/23 3:06pm ET: Added FutureGrid
• 4/25 8:38pm ET: Added HUBzero

Heartbleed: Should I change my password? (And when?)

Yesterday, news of the Heartbleed OpenSSL bug swept the Internet, and lots of web site administrators worked to update software and replace potentially compromised cryptographic keys. Estimates are this vulnerability affected over half a million websites and major sites such as Yahoo Mail were vulnerable.

Today people are starting to wonder what this bug means to them, specifically should they change their passwords? It’s possible as the news spread yesterday, websites could have been compromised before they were fixed. There is also the theory that someone could have exploited this bug secretly for two years.

It’s easy to say “Yes!” and this is always a good safe default, but if you’re like me you have 100s of passwords and changing them all is a major task. This post is meant to give you some guidance as to which passwords to change and which to change first.

First, figure out your most important passwords and start with those. Think about websites (good news for SSH users: SSH isn’t affected by Heartbleed, just OpenSSL) that would cause you real worry if the password was compromised. If you’re like me, it’s online banking and other important websites such as my university login and key projects I’m a part of.

Then, figure out if those websites you use were affected. This list of the top 1000 sites is a good place to start as well as this list from mashable.com. If you don't see a website listed in those places, look to their blog or other sources of support information. Failing that, it’s probably easiest just to assume they are compromised since it would take take more effort to figure out than change your password.

Then, and waiting may be hard, but there isn’t any point in changing your password until a website has fixed their software and changed their cryptographic keys. You can wait to hear from a website or you can test the website yourself. Once they’ve fixed their software and replaced their cryptographic keys, then it makes sense for you to change your password.

And while you’re going around changing all these passwords, take the opportunity to use a password manager and a different password for each site. Using a different password for each site is the most important thing you can do improve your security and obviously you can’t remember that many passwords, so using a password manager is the best way to do that.

Yes, this is no fun for anyone. Unfortunately security on the Internet is a shared responsibility and while websites do their best to minimize impact on us, sometimes things just don’t work out.

(Edited 4/10 to add link to mashable.com list.)