Secure Server Standard

Standard Number: IT.1.11.2.2.2
Category: Information Security
Owner: Information Technology Services
Effective: October 5, 2021
Revision History: Originally effective August 21, 2012
Review Date: October 4, 2024

1. PURPOSE, SCOPE AND RESPONSIBILITIES

   1. Pursuant to the Information Security Policy, the University will protect its technology resources by establishing Baseline Configurations for physical or virtual host servers owned by the University that provides one or more services for other hosts over the Campus Network (“University Servers”).
   2. The purpose of this Standard is to designate the minimum level of administrative, technical, and physical security requirements for securing University Servers. This Standard is based on the recommendations in NIST Special Publication 800-123: Guide to General Server Security.
   3. All University Servers managed by faculty, staff, students, or other Authorized Individuals must meet this Standard, regardless of manufacturer or function of the system.
   4. The Chief Information Officer, supported by the Chief Information Security Officer, is responsible for the enforcement of this Standard.
   5. Pursuant to the Data Center Security Policy, Data Center Coordinators are responsible for maintaining an inventory of all the University Servers within the University Data Centers they oversee. Such inventories should identify a Server Administrator responsible for system administration of the server.
   6. Academic and administrative IT directors are responsible for maintaining an inventory of all the University Servers operated within any server rooms they manage. Such inventories should identify a Server Administrator responsible for system administration of the server.
   7. Server Administrators are responsible for maintaining an inventory of the University Servers they manage, ensuring all University Servers they manage meet or exceed the requirements within this Standard, and identifying any out-of-date or unsupported software on University Servers they manage.
   8. Information Security Services (“ISS”) is responsible for conducting scans of the University Campus Network to identify security vulnerabilities on University Servers.

2. Administrative Controls

   1. The Server Administrator must maintain an inventory of all University Servers in production they manage. The inventory must contain the following information:
      1. The purpose of the University Server (e.g., mail server, web application server, database server, server that hosts multiple servers);
      2. Supported Operating System;
      3. VM Cluster (if appropriate);
      4. Hostname, IP address, and/or subnet information;
      5. Physical location of the server (if appropriate) or virtual infrastructure;
      6. The network services provided on the University Server (e.g., HTTP, FTP, SMTP, NFS) and the protocols used for each service (e.g., IPv6, IPv4);
      7. Classification of University Data stored on the server. See Data Classification Policy (interim);
      8. Criticality of the server (e.g., Mission Critical, Business Critical, Fixed Asset, Federally-Owned); and,
      9. How the University Server will be managed (e.g., locally, remotely from the internal network, remotely from external networks).
   2. ISS will conduct an authenticated vulnerability assessment of all University Servers that provide direct access outside campus network prior to production. Critical and external high vulnerabilities must be remediated before the server is deployed to production.
   3. All efforts must be made not to utilize University Servers that are out of warranty.
   4. University Servers must be sanitized according to the Data Destruction and Media Sanitization Standard prior to being reused within the department or college to prevent unauthorized access to University Data or University-licensed software.
   5. University Servers must be returned to the academic or administrative IT staff when no longer being used. Discarding University Servers directly through the Surplus Redistribution Center is strictly prohibited.
   6. University Servers that are identified as Fixed Assets or Federally-Owned Asset must be reported to Property Management by the asset owner or academic and/or administrative IT units prior to disposal.

3. Technical Controls

   1. University Servers must run a Supported Operating System. Use of out-of-date operating systems that are not being actively updated to address new security concerns is prohibited.
   2. Software Patch Updates must be deployed to University Servers as soon as practically possible but not longer than ninety (90) calendar days after the patch becomes available. Patches should be tested on development systems prior to being rolled out to production, where possible. Out of date software or software that is no longer supported by the vendor is strongly discouraged.
   3. All physical University Servers must be on a dedicated, single-purpose host (e.g., a file server provides file sharing services, a database server provides database services for web applications on web servers).
   4. Services, application, and network protocols (e.g., system development tools, language compilers and libraries, SMTP, SNMP, LDAP, FTP, NFS, Telnet, NIS, wireless networking services, SMB, web services) deemed unnecessary to the server’s purpose must be removed.
   5. Track implementation, use, and modifications of TCP and UDP ports to ensure that only essential services are implemented. Annually, audit open ports to identify unused ports and determine if they can be closed.
   6. University Servers operating system and software user authentication must be configured in accordance with the Password Standard and Identity and Authentication Management Standard, including removing or disabling unneeded default accounts, using Enterprise Directory Services (“EDS”) for authentication when possible, and authenticating via an identity provider that enables single sign-on (“SSO”).
   7. University Server operating system and software access controls must be configured with the principle of Least Privilege in mind (e.g., limit access to application software and configuration, password hash, and log and system audit files; allow service processes to run only as a user with limited privileges, not running as root or administrator, or equivalent).
   8. The following security safeguards must be installed, configured, and kept up to date on University Servers:
      1. Anti-Virus. Must run Real-Time Scanning and/or scan the University Server regularly to prevent, detect, and remove malware, when possible. If running Real-Time Scanning drastically impacts use of the service, Server Administrators must run regularly scheduled scans during off-peak usage hours.
      2. Host-based or Virtual Firewall. Enable and configure to block all inbound traffic that is not explicitly required for the intended use of the University Server. Use of a network-based Firewall does not remove the need for the host-based Firewalls.
      3. Patching. Windows Servers must be able to communicate with managed services (e.g., SCCM, Ansible).
   9. University Servers not housed within a University Data Center must be encrypted with whole disk encryption (e.g., BitLocker, SecureDoc, FileVault).
   10. The following must be removed or disabled on University Servers:
       1. All services installed by the University Server application but not required (e.g., gopher, FTP, HTTP, remote administration);
       2. All unneeded default user accounts created by the University Server installation;
       3. All example or test files from the server, including sample content, scripts, and executable code, with best efforts; and,
       4. All unneeded compilers.
   11. Apply the appropriate industry-standard security template or hardening script to the University Server depending on the data classification and/or compliance regulations of the data stored on the server.
   12. For external-facing University Servers, service banners must be reconfigured not to report the server and OS type and version.
   13. Resource constraints must be implemented on University Servers, when possible, to mitigate against Denial of Service (“DoS”) attacks that attempt to fill the file system on the server OS with extraneous and incorrect information causing the server to crash. Examples of resource constraints include: installing server content on a different hard drive or logical platform than the OS and server software; placing a limit on the amount of hard drive space that is dedicated for uploads; ensuring uploads are not readable by the server until after automated or manual review processes is used to screen them; configuring maximum number of server processes and/or network connections that the server should allow.
   14. A dedicated physical disk or logical partition (separate from operating system and server application) must be created for University Server data, if applicable.
   15. University Servers storing or transmitting Sensitive Data and/or Mission Critical Services must be configured to send all logs to a central log repository (e.g., Splunk).
   16. A test or development server must be maintained for University Servers storing or transmitting Sensitive Data or that house Critical/Core Services. Ideally, this server should have hardware and software identical to the production University Server. When possible, the test or development server should be located on an internal network segment (intranet) where it can be fully protected by the perimeter network defenses.
   17. University Servers must be configured to allow ISS to scan them for potential vulnerabilities. Scans and identified vulnerabilities will be handled according to the Vulnerability Management Standard.
   18. A security assessment, in coordination with ISS, must be performed on University Servers housing Sensitive Data and/or Critical/Core Services upon purchase and/or renewal of software contract. Security assessments may also be conducted upon request.
   19. Administration of a University Server is considered Privileged Access. Remote administration of a University Server is only allowed pursuant to the Remote Access Standard.

4. Physical Controls

   1. University Servers must be configured to lock and require an Authorized Individual to re-authenticate if left unattended for more than 15 minutes.
   2. Physical University Servers storing or transmitting Sensitive Data must be located in a University Data Center and meet the requirements outlined in the Data Center Security Standard. Otherwise, the University Server must be housed in a room or closet with the following controls:
      1. A lock mechanism. This can be accomplished with electronic, mechanical, or prevalent door locks;
      2. Doors that remain locked at all times;
      3. Adequate temperature and humidity levels to maintain the continuous operation of equipment according to manufacturers’ recommendation;
      4. At least one Class BC Fire Extinguisher that is inspected annually; and,
      5. Free from food, drinks, liquids of any kind, and tobacco.

5. Exceptions

   1. This Standard does not include University-Owned Devices, Internet of Things (“IoT”) devices (e.g., smart TVs), or audio-visual equipment (e.g., monitors, projectors). Minimum security requirements for University-Owned Devices can be found in the University-Owned Device Standard.
   2. University Servers used for research purposes may be subject to specific data protections (e.g., federal regulations, data use agreements, NDAs) that require exceeding the requirements identified within this Standard due to the sensitivity of the data associated with the server.
   3. University Servers used for research purposes may not have the ability to meet the requirements identified in this Standard because they are operating highly specialized equipment. Researchers and IT directors must work with ITS to determine the appropriate compensating security controls for such servers. Should a server be identified as High-Risk to the University Campus Network, it must be removed.
   4. The use of out-of-date software or software no longer supported by the vendor must be approved for use via a compliance exception request to the appropriate academic and/or administrative IT unit.

6. DEFINITIONS

   1. “Authorized Individuals” means faculty, staff, students, and others who have assigned WVU Login credentials which provides them approved access to University Servers such as retirees, consultants, presenters, camp attendees, or vendors. “Authorized Individual” means a person with approved access to a University Server or University Server room/closet.
   2. “Class BC Fire Extinguisher” means a portable, regular dry chemical fire extinguisher that meets the requirements set forth by the U.S. Department of Labor Occupational Safety and Health Administration to handle a range of fires caused by Energized Electrical Equipment or flammable liquids, greases, or gases.
   3. “Enterprise Directory Services” means the shared information gathered from authoritative sources on campus that provides the comprehensive picture of an individual’s relationship with the University by merging identification and role information. The technical components that work in whole, or in part, to verify the authenticity of a personal identity or a resource include Active Directory (AD), Active Directory Federation Services (ADFS), Shibboleth, and Central Authentication Service (CAS).
   4. “Federally-Owned Asset” means assets purchased with federally sponsored award funds. Title to such assets generally remains with the federal sponsor; however, may be transferred to WVU in some situations.
   5. “Fixed Asset” means computer equipment where the total unit cost incurred to fabricate the equipment is $5,000 or more.
   6. “Least Privilege” means granting the minimum system resources and authorizations needed to perform its function or restricting access privileges of Authorized Individuals to the minimum functions necessary to perform their job.
   7. “Mission Critical Services” means a service required to conduct essential, mission-oriented University operations. Unplanned interruptions in service have an immediate and widespread impact.
   8. “Privileged Access” means the ability to perform a privileged function on a given University Server. Privileged functions must be defined for each University Server, but generally include any function that is above and beyond that which a “normal” user can perform. Examples include, but are not limited to, the ability to install software, manage user accounts, manager user permissions, and change system configurations.
   9. “Real-Time Scanning” means anti-malware software that analyzes files and programs as they are copied to a system to prevent the user from unknowingly becoming infected.
   10. “SCCM” means the Microsoft System Center Configuration Manager, which is a product that enables ITS to manage the deployment and security of Windows devices and applications across the University enterprise.
   11. “SecureDoc” means a WinMagic product that provides full-disk encryption for Windows machines.
   12. “Server Administrator” means the individual who has overall control of the server responsible for designing, installing, administering, and optimizing performance and condition of the server.
   13. “Software Patch Updates” means a solution for fixing vulnerabilities in an OS or software that are provided by the entity supporting the OS or software.
   14. “Supported Operating System” means that the entity providing the OS, be it a vendor, open source, or an individual, is actively and routinely providing and deploying patches and security updates for the OS.
   15. “University Data” means data created, received, maintained, or transmitted by or on behalf of the University through the course of its academic, administrative, research, or outreach activities.
   16. "University Data Center" means a facility, or portion of a facility, with the primary function to house data processing equipment and features N+1 Fault Tolerance, provides at least 72-hour power outage protection, has no more than 1.6 hours of downtime per year, and can undergo routine maintenance without affecting operations; however, unplanned maintenance and emergencies may affect operations. Exhibit A of the Data Center Security Policy identifies all University Data Centers.

7. Related Documents

   1. Acceptable Use of Data and Technology Resources Policy
   2. Data Center Security Policy
   3. Data Center Security Standard
   4. Enterprise Infrastructure Server Backup and Data Protection Standard
   5. Information Security Policy
   6. University-Owned Device Standard
   7. Sensitive Data Policy
   8. Data Destruction and Media Sanitization Standard
   9. NIST Special Publication 800-123: Guide to General Server Security
   10. Data Classification Policy
   11. Capitalization Policy
   12. Compliance Exception Management Standard