OIT Tech 32px
security header image

Security Standard for General Information Systems


In order to set a baseline for how systems should be configured when attached to the Ohio University Network, a working group was established in August of 2008 for the purpose of developing a standard to which all systems should comply.  This working group had a membership roster that included:

  • Kapil Bajaj
  • Jay Beam
  • Doug Bowie
  • Donner Davis
  • Matthew Dalton
  • Mike Elliot
  • Chris Hayes
  • Steve Hoffer
  • Sunil Narasimhan
  • Paul Schmittauer
  • Ron Yoakem

After reviewing several of the standards in existence, the group took the NIST 800-123 Guide to General Server Security (http://csrc.nist.gov/publications/nistpubs/800-123/SP800-123.pdf) as their template and modified it to more closely meet the environment of Ohio University.  In all cases, the group attempted to stay true to the following security concepts:

·         Defense in Depth – Simply stated, good security doesn’t rely on only one level of protection

·         Principle of Least Privilege – An individual, process or system should only have the minimum amount of rights, access or privilege required to get the job done.

·         Less is More – A system should only contain, or have running those files and functions necessary to get the job done – nothing more, nothing less.

3 Levels of Standard     

One change that the working group made to the standard was the recognition that not all systems are the same. Toward that end, the standard has been broken into three levels. The standard is cumulative - i.e. Moderate systems have to comply to both Moderate and Minimum, while Maximum must comply to all three. 

 Minimum  Minimum Standards apply to all general purpose computer environments (i.e. Windows, Mac, Linux, BSD, etc.)
 Moderate  All Servers are at least Moderate, and servres containing confidential data must meet the maximum requirement.
 Maximum  Maximum is required regardless of weather the system is "production" if it contains sensitive data. 


  • Create, document, and implement a patching process. (may be accomplished through WSUS, GPO, or auto patching)
  • Install permanent fixes (patches, upgrades, etc.) 
  •  Identify vulnerabilities and applicable patches. (unless automated)
  •  Mitigate vulnerabilities temporarily if needed and if feasible (until patches are available, tested, and installed). (depending on exploit available, or difficulty of the fix)

Server Deployment

  •  Keep the servers disconnected from networks or connect them only to an isolated "build" network until all patches have been transferred to the servers through out-of-band means (e.g., CDs) and installed, and the other configuration steps listed in this section have been performed. 
  • Place the servers on a virtual local area networl (VLAN) or other network segment that severly restricts what actions the hosts on it can perform and what communications can reach the hosts --- only allowing those events that are necessary for patching and configuring the hosts. Do not transfer the hosts to regular network segments until all the configuration steps listed in this section have been performed. 
  •  Administrators should generally not apply patches to production servers without first testing them on another identically configured server

Remove, Restrict or Disable Unnecessary or Unused Services, Applications, And Network Protocols