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

Serious OpenSSL 1.0.1 "Heartbleed" Bug

On Monday, April 7, 2014, the OpenSSL project announced the existence of a serious bug in OpenSSL 1.0.1 through 1.0.1f with the potential of leaking private keys and other sensitive information from affected SSL/TLS clients and servers. The bug is in the implementation of the TLS/DTLS heartbeat extension (RFC 6520) and therefore has been called the "Heartbleed Bug".

Administrators of systems running OpenSSL 1.0.1 through 1.0.1f should promptly install the vendor fix for their operating system (when available). Administrators of impacted HTTPS servers should obtain a new HTTPS certificate using a newly generated private key, after installing the OpenSSL fix, as the existing HTTPS private key is now suspected to be compromised due to this OpenSSL bug.

References:

• https://www.openssl.org/news/secadv_20140407.txt
• http://heartbleed.com/
• http://www.kb.cert.org/vuls/id/720951
• https://lists.incommon.org/sympa/arc/inc-ops-notifications/2014-04/msg00000.html

Outsourcing Identity Management

Identity Management (IdM) in scientific cyberinfrastructure is a means to an end: provide convenient and secure access to applications, data, instruments, and services so scientists can focus on the science. Implementing a custom IdM solution can be a significant drain on resources for science projects. Outsourcing IdM can help with managing user identities, credentials, groups, and profiles. Three IdM outsourcing options that we see used in US scientific cyberinfrastructure are Globus Nexus, Agave, and Google Apps for Education.

Globus Nexus provides identity, profile, and group management as part of the Globus Platform, which is designed to support data-intensive collaborative research. Multiple research projects have adopted Globus Nexus for identity management, including US ATLAS, OSG, and KBase. Globus Nexus supports federated identities via InCommon/CILogon and Google OpenID, as well as user-managed groups. US ATLAS and OSG use CI Connect to integrate with Globus Nexus. The KBase Authentication developer tutorial demonstrates KBase’s integration with Globus Nexus via an OAuth/REST API.

Agave is a science-as-a-service platform, designed to support science gateways, that was developed by the iPlant Collaborative. Agave provides hosted identity, profile, and group management via an OAuth/REST API. Science gateways can integrate with iPlant identities (hosted in the Agave platform), use Agave as a hosted OpenID Connect interface to their existing identity solutions, or leverage Agave’s identity-as-a-service offering. For example, the Bioextract Server and CIPRES science gateways now accept iPlant identities for login via Agave, the Arabidopsis Informatics Portal and VDJServer leverage Agave’s hosted identity service, and the Texas Advanced Computing Center uses Agave with their Active Directory to provide OAuth protection to their internal and external APIs.

The Google Apps for Education collaboration platform is widely used for smaller scientific collaborations, due to ease of setup and powerful collaboration tools (Docs, Forms, Groups, Chat, Hangouts, etc.) provided out-of-the-box . External applications can integrate with Google identities and Google+ profiles via OpenID Connect. Google Apps also supports SAML SSO for integration with campus identities. Google’s Directory API provides an OAuth/REST interface to Google Groups.

What do you think about science projects outsourcing identity management? Post your comments below.

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

Developing a Cybersecurity Plan for NSF Science and Engineering Projects: First Unit Released

A number of NSF projects have a requirement to develop a cybersecurity plan as part of their cooperative agreement with NSF [1]. Other want to do so because they consider it a best practice worth following.

As apart of CTSC's ongoing engagement with the Daniel K. Inouye Solar Telescope (DKIST) we are developing a guide for creating such a cybersecurity program. Our first unit in this guide is now available for comment. We are using the TrustedCI Forum to disseminate this unit and solicit feedback from the community. We encourage all members of the community to join the conversation and provide their insights into this important work.

[1] http://www.nsf.gov/pubs/policydocs/cafatc/cafatc_lf212.pdf (see item 56 on page 6)

CTSC DataONE engagement: identity management system review

In the CTSC-DataONE engagement, CTSC and DataONE staff worked together to perform an architectural review of DataONE's identity management system. DataONE (Data Observation Network for Earth) is "a distributed framework and sustainable cyberinfrastructure that meets the needs of science and society for open, persistent, robust, and secure access to well-described and easily discovered Earth observational data."

CTSC's overall assessment of the DataONE identity management system was positive. Strengths include support for authentication using federated identities, equivalence mapping of multiple identities for the same person, and a well-specified access policy language. CTSC made recommendations for improvements in the areas of system documentation, architecture, and operations. See the report at http://hdl.handle.net/2022/16926 for more details.

CTSC's engagements are inherently collaborative. Many thanks to the DataONE team, and specifically Ben Leinfelder, Bruce Wilson, and Dave Vieglais for the collaborative effort that made this engagement possible.

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