Analyzing authentication events

Part of CTSC's mission is to help educate the NSF community about tools and processes related to cybersecurity. For example, our software assurance team offers tutorials on static analysis tools and to test those tools, they provide benchmark datasets (code). In this article, we describe tools (Python modules) and a benchmark dataset for analyzing authentication data. However, the tools are sufficiently general that they could apply to other types of data related to cybersecurity, e.g. network traffic or more general data flows.

I recently had the pleasure of attending the SIAM Workshop on Network Science where I presented our poster on the analysis of a rather large authentication¹ dataset. The public dataset was made available from Los Alamos National Laboratory (LANL) and represented over 700 million anonymized authentication events over a nine-month period.[1][2]

Our poster submission demonstrated the use of Python to analyze and visualize the data. Since our scripts relied on various Python modules not found in the standard library, we recommended using the Anaconda Python distribution (3.x) which contained those modules (and a lot more). One key module that we used, to perform some of the network analysis, was NetworkX. Another module, to plot results, was matplotlib. We also demonstrated how one could use the IPython Notebook in a browser.

An authentication event was represented as a simple entry: "time,user,computer", where "time" was in seconds offset from the beginning, and "user, computer" were anonymized entries with unique numeric identifiers (e.g. U214,C148). We preprocessed the dataset to generate two files: one containing just the time values, another representing the user-computer information as a global, static graph. This type of graph, with two disjoint sets of nodes (users and computers), is known as a bipartite graph. Since the second file, containing the graph, took about 8 hours to generate, we made it publicly available in case others wanted to experiment. (Generating the first file, with only time values, just took a few minutes using one of our scripts.)

Our first step was to perform a sanity check on the time values for the authentication events. Fig. 1 is a histogram plot of all events over the nine-month period. Using the matplotlib module, we can interactively select a region to zoom into and see general daily and weekly usage patterns. The script to generate this histogram is parameterized so that a user can see more detailed (or coarse) plots.

Fig. 1: A histogram, over time, of all authentication events (top); zooming into a 2 week window (bottom)

Next, we use the NetworkX module to plot the graph and zoom in on particular nodes that seem to be hubs in the network. In the following two figures, the User nodes are colored red and Computer nodes are colored white. Fig. 2 shows C148 as a hub with numerous User nodes connected to it. Fig. 3, in contrast, shows U12 connecting to numerous computers. Obviously, if we had more information about the authentication events, we might be able to determine that certain User hubs were, for example, just the result of system administrators performing maintenance. On the other hand, it may be an indication of questionable user behavior.

Fig. 2: Node C148 as a hub.

Fig. 3: Node U12 as a hub.

In addition to visually inspecting the graph, we can programmatically analyze it to discover certain features, e.g., hubs or connected components. These techniques can be found in our poster and scripts.

Discussing results with LANL's Hagberg (left)

According to LANL's Aric Hagberg, there will likely be another dataset coming sometime this year that will have more metadata.

Our abstract, poster, Python scripts, and additional documentation can be found at https://github.com/rheiland/authpy.

We welcome your comments.

^{1. Authentication, in this context, is the process of verifying the identity of a person connecting to, e.g. logging into, a computer.}

---

[1] A. Hagberg, A. Kent, N. Lemons, and J. Neil. Credential hopping in authentication graphs. In 2014 International Conference on Signal-Image Technology Internet-Based Systems (SITIS). IEEE Computer Society, Nov. 2014.

[2] A. D. Kent, L. M. Liebrock, and J. C. Neil. Authentication graphs: Analyzing user behavior within an enterprise network. Computers & Security, 48:150-166, 2015.

Soliciting input on federated identity/InCommon needs

Hello, Von Welch, CTSC Director and PI here.

 I've recently accepted a one-year advisory term on the InCommon Steering committee. In that role, I will work to see the needs of NSF CI projects and similar research service providers (SPs) are addressed.

 The first thing I'd like to work on is getting all universities of interest to NSF projects to streamline scientific collaboration by sending those projects a user's name and email address when the user authenticates to the project using InCommon federated authentication. The InCommon Research and Scholarship (R&S) program includes only 100 universities that agree to send name and email address, and some of the largest research universities do not participate in the R&S program.

 We would like to change that. The InCommon Steering Committee plans to contact the CIOs at these universities to request their support. Knowing more about NSF funded projects that could benefit from outsourcing authentication to InCommon allows me to prioritize and strengthen those requests. As a starting point, if there is benefit to your project from specific universities supporting federated authentication and releasing a user's name and email address, please let me know who they are. 

 Going forward, I've created the CTSC Federated Identity Discussion List for further discussions around NSF CI projects and InCommon and federated identity. I won't be sending you any more emails directly, please join the list to be included in further discussions. You can find details at http://trustedci.org/ctsc-email-lists/

I welcome hearing any other concerns or suggestions you have about InCommon, now or in the future.

Regards,

Von 
--
Von Welch Director, Director and PI, Center for Trustworthy Scientific Cyberinfrastructure

Globus and CTSC engagement: data sharing

CTSC and Globus recently completed an engagement in which CTSC took a close look at the Globus data sharing feature. As many in the NSF community already know, Globus provides both services and applications that try to make it easier for scientists to focus on their science. One key Globus service is data management, especially the movement of files between two endpoints, e.g. between two users’ personal computers, between a user’s computer and a large institutional storage site, or between two other endpoints. In addition to an explicit data copy between endpoints, Globus also has a data sharing feature in which a user can make an entire folder accessible (read/write) to other Globus users. CTSC performed an assessment of this particular feature of Globus. The assessment covered a review of the design, architecture, and high-level implementation of the sharing feature. It was not a code review; however, the CTSC team did perform a source code installation of a Globus Connect Server, with the sharing feature enabled, and analyzed how credentials were being handled and how log files were being generated. While the assessment did not reveal any high security risks for the data sharing feature, CTSC did make a number of recommendations to address low-to-medium risks. These recommendations included improving the documentation, for both system administrators and users, and improving the logging and monitoring of sharing activity.
An ongoing challenge in such assessments of software features is the lack of clear process for doing the assessment, as the question is more one of “is this doing the right thing” without clear definition of what “the right thing” is (a challenge we also tackled in our engagement with Pegasus WMS). For this engagement we utilized a modified set of principles originally put forth by Saltzer and Schroeder in 1975 on the protection of information systems, to help guide our assessment. We think utilizing the principles helped significantly and plan to continue exploring their use in future engagements.
For more information, please see the Globus-CTSC Engagement final report, available at http://hdl.handle.net/2022/19165.
We want to thank the Globus team, especially Rachana Ananthakrishnan, Mike Link, and Steve Tuecke, for their helpful collaboration on this engagement.
See how CTSC might engage with you and your NSF project at http://trustedci.org/howwehelp/.

Join CTSC! Analyst position open at IU CACR

IU/CACR has a position open for a analyst to join the CTSC team. This is an opportunity to join a team of smart, talented folks working on securing NSF computational science. Please apply via the prior link or contact Von Welch if interested.

Shutting down trustedci.groupsite.com June 1st, 2015

For the past couple of years, we've operated trustedci.groupsite.com as forum for conversations and announcements about CTSC and cybersecurity for CI.  Based on the feedback we've gotten, it seems trustedci.groupsite.com isn't clicking with people as a way for communication. Since creating it, we've also established a set of email lists for discussions about cybersecurity and CI at http://trustedci.org/ctsc-email-lists/.

Since it's costing a small, but non-trivial amount of money to operate the trustedci.groupsite.com service, we're going to shut it down on June 1, 2015.

We hope you'll subscribe to one or more of the email lists at http://trustedci.org/ctsc-email-lists/. If you have other suggestions for how you'd like to communicate with CTSC or your peers working on cybersecurity for CI, please let us know.

Von, for the CTSC team

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.