Menu
Home » Science DMZ » Practices and Policy » Drafting User Policy
Science DMZ

Drafting User Policy

Once a science DMZ is constructed, it behooves sites to draft policy regarding onboarding and acceptable use.  These documents can drive customers to the resource, and ensure it is protected from risk. In particular, the following items are of interest:

  • Inbound and outbound traffic policy. Does the site wish to use a "deny all" policy, and allow traffic in selectively? Is there a desire to use ACLs?  Are private peerings employed?
  • A listing of the tools/protocols allowed, or ones that are specifically disallowed
  • The policy for the monitoring of performance and security
  • If the use of institutional DTNs will be encouraged or mandated.  Ways a private DTN could be connected. 
  • The policy for on-boarding and compliance to the resource
  • If there is a policy for ongoing review and improvement, possibly based on user feedback

Minimum Security Baseline

Most approaches to a minimum security baseline are based on:

  • Define the data policy for the institution (this may be already defined)
  • An attempt to find and catalog data of different types
  • The process to identify the devices/locations of sensitive data
  • Describing how to protect access to devices and resources, as well as how to protect their use
  • Drafting a policy for use, misuse, and remediation

Examples:

  1. Penn State
  2. Wisconsin

User MOU

The purpose of this process is to outline the behavior of users on the research/science dmz network.  This is done to:

  • Identify who runs which resources, and who has responsibility (network, servers, services, etc.)
  • Identify and safeguard critical assets
  • Describe how to connect, and how to be trained
  • Describe acceptable behavior
  • Describe unacceptable behavior
  • Document use cases, or discover new ones
  • Prescribe actions for violation

Optionally, it can also be used to describe:

  • Aspects of construction
  • Services provided
  • Operational Aspects
  • Methods to physically connect
  • Methods to improve the process, as well as validate and remediate assumptions
  • Some considerations for this document include:

Onboarding

  • The process how a user "asks" to get on
  • Notification that they will be subjected to a security and use case review
  • Questions regarding if they will allow their resources to be managed centrally, or the process for doing it personally
  • Notification that they are subject to compliance monitoring

Security

  • Identification of the use case (e.g. the ports, locations, protocols, tools)
  • Subjected to an initial security scanning and correction
  • Subjected to an initial data and risk identification exercise
  • Agreeing to continuous monitoring
  • Review of the data and resource access policy

Remote Access

  • If this is needed or not.  Why is it needed.  Who will need it?
  • Notification that they will be subjected to monitoring

Operational Oversight

  • Who has control over the network resources at each stage of the process
  • Who has control over and access to devices.  Both those that are centrally and privately managed
  • The process for reviewing and changing the MOU

Monitoring

  • Which tools and metrics are used in performance monitoring
  • Which tools and metrics are used in connectivity monitoring
  • Which tools and metrics are used in security monitoring