Wednesday, June 18, 2014

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.

Tuesday, June 17, 2014

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

Monday, June 16, 2014

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.

Thursday, June 5, 2014

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

This morning a new OpenSSL advisory was announced:

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.


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:

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.

Wednesday, June 4, 2014

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 For more details on the CFP, visit

For more on the summit in general, see

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.


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

Monday, June 2, 2014

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.

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

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

We hope to see you there!

For the latest information on these lists, please visit