Science DMZ Users

Practical Use of a Science DMZ

Many campuses that have invested significant time, effort, and money into the construction of a Science DMZ face a new challenge: encouraging adoption and defining a usage policy. There are many choices to consider, and like the design paradigm itself these will depend heavily on the implementation environment:

Identification of users that may be able to take advantage of the network infrastructure
Definitions of resources that may be connected
Policies governing the maintenance and upkeep of connected resources
How violations will be detected, and enforced
Ways feedback can be given on the operation, and future upgrades
Services that will be operated by individuals, or a central management body

The following sections will outline some of the possible approaches in this space. Note that these are suggestions, and all sites will need to carefully consider the implications of this new service. Buy in, at all levels, is just as important as the implementation of the technology.

Seeking out Tenants

The construction of a Science DMZ is a major commitment by a facility or University. The task of seeking out users can be broken into two stages:

Identification of broad scientific needs at an institutional level
Staged migration of specific resources/users from the broad classifications

Often the first step is undertaken before the Science DMZ is constructed. Campuses receiving Campus Cyberinfrastructure funding often create a "CI Plan" that outlines the technology, as well as the drivers for said technology. This exercise helps to learn about basic science users, patterns, and possible drivers for future expansion.

After construction of technology, it is helpful to establish an "onboarding" process to migrate users in an orderly process. For instance, migration of scientific resources (e.g. instruments, storage, processing capabilities) may be required if a dedicated facility is constructed. Alternatively, the application of new network homing or connections to non-moveable devices may be required.

Establishing a broad list of users is a good first step in the process, along with a possible ranking based on data usage potential, or impacts to operational methodology. The list should prescribe a pace at which things can be migrated, slow to start and faster as lessons are learned about the process. After initial adoption has started, ad-hoc conversion is possible for new users, or those that were previously not known.

The Role of Advisory Groups

Advisory councils server important roles for the Science DMZs construction, operation, and expansion. Groups are recommended that can address the following tasks:

Identify scientific users
Evaluate privacy concerns for services, hardware, software, and data
Evaluation of technology to implement the DMZ
Creating documentation to facilitate migration, use, and expansion

These committees should have membership comprised of facility leadership, technology operators, researchers, and external observers (if desired). The longevity of the committees is at the discretion of each institution, long lived committees could help with future needs without requiring a significant time investment.

Access Policy

A critical consideration for any Science DMZ is a definition of whom and what has access. There are many approaches to implementation, which color the longer term impacts of use:

Creation of a separate (logically or physical) network implies that resources must "opt in" to gain access to the Science DMZ
Using existing network elements and resources, but applying special policies to control access, implies that many users could be "on" by default

In our first example, a separate network substrate offers a unique environment. Operators and researchers alike can populate this network slowly, and enforce policy from the ground up. For instance, if there is a desire to prevent the use of HTTP protocols (e.g. clients fetching web pages, or servers offering web content), tools such as router ACLs and intrusion detection can be installed to prevent the behavior by default. Language in formal documentation can also spell out specifically what can, and cannot, run in this environment. Similarly, if there is a desire to ban all resources of a certain class (e.g. mobile devices, BYOD laptops, etc.) filtering can be installed to identify and block access.

In the later approach, reuse of existing network elements and resources, it may be the case that legacy systems are automatically "added" to the newly constructed DMZ. For example, a specific campus resource (a HPC facility, laboratory, or office) may be given access to a Science DMZ without use of additional network configuration. These facilities may contain any number of resources that could benefit from the access: clusters, instruments, storage arrays. Equally, there may also be a population of devices connected via wireless and wifi that should not be on this network: BYOD laptops, printers, IP phones, HVAC control systems, etc. This environment is more challenging for identifying good and bad use cases and may involve an ongoing exercise to identify stop, or block suspect services. The security infrastructure (implemented as intrusion detection systems, ACLs, or even firewalls) will work harder unless an audit is performed a priori.

Once defined, it is recommended that access policies be drafted into a document (living, or static) and given to all current and potential users.

Expectations for Researchers

There are several classes of expectation for users of the Science DMZ:

Technology that can be connected to the network
Services that can utilize the network
Remote locations that can be accessed

In accordance with the access policy, only certain classes of machine should be connected to the Science DMZ. For instance, it may be the case that only approved server class hardware, running certain scientific applications, are allowed to use this resource. Data mobility tools, workflow managers, or certain portals may be allowed. Web browsers, un-encrypted communication clients, or other un-approved applications could be banned.

Additionally, resources that are approved for use on the Science DMZ must be adequately maintained and monitored. This could include, but is not limited to:

Regular patching of operating system and application software
Host level protections (IP filters for IPv4 and IPv6) or intrusion detection
Mirroring of log files to a centralized log repository (e.g. splunk) that could be run by the central management group
Centrally managed authentication, or other mechanisms to control access (e.g. 2 factor)

If the site is filtering remote locations accessed, it may be the case that certain net blocks are not permitted to be accessed. A broad decision could be implemented to only allow access to other resources reachable by the R&E internet routing table (e.g. locations serviced by networks like ESnet, Internet2, or regional and NREN providers).

Expectations for Providers

Maintainers of the Science DMZ should outline operational expectations for users in the same manner that they will outline expected behavior:

Centralized services that will be offered
Security protections that will be implemented at the network level (e.g. filtering, intrusion detection, log aggregation)
Expectations for availability (e.g. "5 nines" of availability, etc.) and time required to address detected problems
Network failover planning
Backups of shared data repositories
A location (phone number, email address) that can be used to report problems

Violation of Policy

Users that violate the access policies, or expectations of use, should be subject to violation proceedings. This could be as simple as removal from the Science DMZ resource or as complicated as a review by the institution to check for other lapses. Users should be aware of these policies before agreeing to migrate network resources.

Centralized Services

In some cases the operation of a centralized service (e.g. Globus file transfer, VPN, credential management, etc.) could be beneficial to a large population of research users. Cataloging services that are available, as well as a procedure for requesting exploration of new services, is a suggested approach. By doing so, a centralized technology division can add value