Trusted CI Webinar April 23rd at 11am ET: Toward Security-Managed Virtual Science Networks

Duke University's Jeff Chase and RENCI's Paul Ruth are presenting the talk, "Toward Security-Managed Virtual Science Networks" on April 23rd at 11am (Eastern).

Please register here. Be sure to check spam/junk folder for registration confirmation email.

Data-intensive science collaborations increasingly provision dedicated network circuits to share and exchange datasets securely at high speed, leveraging national-footprint research fabrics such as ESnet or I2/AL2S.   This talk first gives an overview of new features to automate circuit interconnection of science resources across campuses and in network cloud testbeds, such as GENI (e.g., ExoGENI) and NSFCloud (e.g., Chameleon).    Taken together, these tools can enable science teams to deploy secure bandwidth-provisioned virtual science networks that link multiple campuses and/or virtual testbed slices, with integrated in-network processing on virtual cloud servers.

Next, we outline a software framework to address security issues arising in these virtual science networks.   We show how to deploy virtual science networks with integrated security management programmatically, using software-defined networking and network function virtualization (SDN/NFV).   As an example, we describe a prototype virtual Network Service Provider that implements SDX-like functionality for policy-based interconnection of its customers, and incorporates out-of-band monitoring of permitted flows using Bro intrusion detection instances hosted on cloud VMs.  We also describe how to use a new logical trust system called SAFE to express and enforce access policies for edge peering and permitted flows, and to validate IP prefix ownership and routing authority (modeling RPKI and BGPSEC protocols) in virtual science networks.

This material is based upon work supported by the National Science Foundation under Grants No. (ACI-1642140, ACI-1642142, CNS-1330659, CNS-1243315) and through the Global Environment for Network Innovations (GENI) program.  Any opinions, findings, and conclusions or recommendations do not necessarily reflect the views of NSF.

Jeffrey S. Chase is a Professor of Computer Science at Duke University.  He joined Duke in 1995 after receiving his PhD in Computer Science from the University of Washington (Seattle).    He was an early leader in automated management for cluster services, cloud hosting systems, and server energy management.   He served as an architect in NSF’s GENI project and is a principal of ExoGENI, a multi-campus networked cloud testbed.

Paul Ruth is a Senior Research Scientist at RENCI-UNC Chapel Hill.  He received his PhD in Computer Science from Purdue University in 2007.  He has been a primary contributor to the ExoGENI testbed since 2011 and is currently the networking lead for the NSF Chameleon testbed.

Join Trusted CI's announcements mailing list for information about upcoming events. To submit topics or requests to present, see our call for presentations. Archived presentations are available on our site under "Past Events."

CCoE Webinar Oct. 23rd 11am ET: Incident Response in an Open and Decentralized Network

Berkeley Labs' Aashish Sharma is presenting the talk " Incident Response in an Open and Decentralized Network" on October 23rd at 11am (Eastern).

Please register here. Be sure to check spam/junk folder for registration confirmation with attached calendar file.

This talk presents various aspects and challenges of monitoring and security of a big research network while keeping it open and usable. We focus on issues faced due to following attributes: 

1. decentralization
2. high Speed
3. BYOD policy
4. openness

We further provide insights into our detection and incident response process using some real world examples and how above attributes influence this process.

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, see our call for presentations. Archived presentations are available on our site under "Past Events."

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.

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.