Apr 17, 2015

Science DMZ as a Security Architecture

ESnet’s Michael Sinatra began his presentation (prepared by him and his colleague Nick Buraglio) by observing that many network engineers regard the Science DMZ architecture as a kind of “plug-and-play” solution to network security concerns – a belief that isn’t actually supported by the architecture model itself. However, the Science DMZ architecture as developed by ESnet and Software-Defined Networking (SDN) can give network engineers a new set of tools to use in the pursuit of trustworthy network security. In addressing this topic, Sinatra first described the architecture and then illustrated the ways in which it could be used to meet network security challenges.

After emphasizing that ESnet’s development of the Science DMZ architecture came as a result of codifying successful practices that were in place at various institutions into a coherent, replicable model, Sinatra then mentioned – and dismantled – one of the most common misconceptions about the Science DMZ: that its purpose is “to get around or avoid firewalls and other security controls.” While many of the issues that stymie big-data researchers are related to the security tools implemented on their institutional networks, getting around these preventive measures is certainly not the purpose of the Science DMZ, nor does the absence of a firewall mean that a network is, in fact, a Science DMZ (a belief that Sinatra has encountered). He would sooner see this characterized as matching security controls to what is being protected while maximizing the functionality of the network for those using it – in other words, enabling finer-grained security controls tailored to the risks present in different parts of the network.

Sinatra then described a variety of common network architectures, including those that use firewalls for security between the campus network and the outside world, and others that do not firewall at that point but instead distribute firewalls throughout various parts of the campus network (administrative, student networks, etc.). This permits security to be tailored to the needs of those using the individual components of the campus infrastructure – a model for security that dovetails well with the Science DMZ model.

He also emphasized that implementing a Science DMZ, contrary to common belief, does entail bidirectional traffic-blocking in the interests of protecting both the campus’s Science DMZ, the campus’s general network, and colleagues using networks beyond the campus. It also must be designed and implemented in a way that enables software patching to take place in the smoothest and most convenient manner, as patching is one of the most significant parts of ensuring a secure network.

Sinatra also treated host-level security tools like host-based firewalls and intrusion detection and stated that he was currently undertaking the development of best practices for them.

He then treated several other tools as well, all of which could (and should) be implemented in some manner on a Science DMZ. In Sinatra’s words, “What are your security best practices in other parts of your network? If you’re not doing that in other parts of your network, then why would you think the Science DMZ should be any different?” Science DMZ security, in other words, consists of more than the presence or absence of firewalls and is not so different from that on other parts of a campus’s network.

After treating the uses and utility of intrusion detection and black hole routing, Sinatra then underlined the importance of being familiar with a network’s typical behavior: “You want to make sure you know what your network looks like on a normal day, so that you know what an abnormal day is.”

He then mentioned the necessity of remaining aware of IPv6, citing instances where IPv6 throughput is better than that over IPv4 even when IPv6 queues were longer. The comparison he used was that of a TSA pre-check line in the airport, where the streamlined process provides higher throughput of “packets” – passengers in the case of the airport security line – even when the pre-check line is longer, because one need not disassemble and reassemble one’s possessions in order to pass through the pre-check line.

Sinatra then moved to the topic of Software-Defined Networking (SDN), also commonly believed to be the answer to network security concerns for Science DMZs. While SDN is not a “drop-in solution,” it definitely has applications to ensuring network security and performance, and he described such working implementations as well as cautioning attendees that these implementations are still not “fully baked” in his words and require “care and feeding.” In addition, by adding a layer of complexity to the Science DMZ, SDN-based tools also increase the number and complexity of possible problems and the pursuit of solutions. The drop-in security solution remains an elusive goal, SDN notwithstanding.

After this treatment of how a Science DMZ can be secured by use of tools, Sinatra then moved into how best practices can be used to secure networks connecting to scientific instruments and high-performance computing (HPC) resources. In other words, once a network engineer has implemented and installed the various tools needed to enhance security onto the components of a network, how should those components then be assembled? As a way of illustrating how deceptively complex such an issue can be, Sinatra mentioned one campus’s old but, as of 1999, still used mass spectrometer, which required connectivity to a MicroPDP-11 in order to function. (Other concerns exist as well, such as the use of outdated or unauthorized equipment in campus labs of which network engineers may be entirely unaware.)

Happily, Sinatra then illustrated a variety of far more secure and usable architectures for the connectivity of network-enabled scientific instruments to attendees – all of which can be found in his slides, along with helpful notes.

Related blog posts

CENIC AIR and Your Campus: From Concept to Connection

Learn more about how to get started thinking about how your campus can connect to and use the CENIC AI Resource.

CENIC Network Automation Update: New Network-Source-of-Truth Tool Implemented

CENIC has evaluated and worked with various DCIM platforms to meet this need and concluded that NetBox was the best fit for its environment as its Network Source of Truth.