UB Minimum Server Security and Hardening Standards

Category: Information Technology

Responsible Office: Enterprise Infrastructure Services

Responsible Executive: Vice President and Chief Information Officer (VPCIO)

Date Established: July 20, 2017

Date Last Updated: February 22, 2022

On this page:


1. Summary

In a memo dated April 25, 2017, UB Provost and Executive Vice President for Academic Affairs Charles F. Zukoski asked Vice President and Chief Information Officer Brice Bible to oversee an institution-wide effort to address Information Technology (IT) security and data privacy concerns in a coordinated approach in order to manage all sensitive data areas. Part of this effort includes establishing minimum IT server security standards.

This document codifies the minimal, required security standards for all servers residing on UB networks. For the purposes of this document, a server is defined as any physical or virtual computer, appliance, or device that is connected to a UB network and is configured to listen on at least one port for the intended purpose of providing a service to two or more clients. For the purposes of this document, a client is an individual person. System administrators of servers are responsible for ensuring compliance with these standards.

This document will address the following topics related to server security:

  • Server Provisioning
  • Server Configuration
  • Server Monitoring
  • Access Control
  • Server De-provisioning
  • Exception Cases
  • Definitions

2. Server Provisioning

Upon deployment of any server on a university network, the system administrator of the server must document and catalog the following:

  • Network identification, such as Domain Name Service (DNS) hostnames or associated CNames.
    • This could include multiple names if multiple Network Interface Cards (NICs) or Internet Protocol Address (IPs) are in use on a single server.
  • System administrators who will be responsible for maintaining the systems and managing their security controls.
  • Service information: What service does the server provide?
  • What data is stored on the server and its associated classification? The Data Risk Classification Policy can be found here: http://www.buffalo.edu/administrative-services/policy1/ub-policy-lib.html
  • A completed Server Security Compliance Checklist (see Appendix A).

System information and the security checklist documentation should be regularly updated whenever there is a change, addition or removal of a server by a system administrator.  

Server use cases should not be co-mingled with endpoint use cases.  (definitions below) If a device or virtual machine is to be used to provide server functionality, it cannot also be used a workstation or  endpoint.

Server hardware should be kept in a physically secured and environmentally controlled space, ideally equipped with redundant systems such as power and HVAC.  Data centers usually meet these needs.  If equipment can not be run out of a data center, the physical space used to house the server must be under some type of restricted access control.  Precautions should be taken to ensure environmental conditions stay with tolerable levels for server operation.  UBIT offers several secure hosting options for distributed IT staff.  More details on this can be found at http://www.buffalo.edu/ubit/information-for-it-staff/server-management-for-it-staff/departmental-server-hosting.html.

3. Server Configuration

All servers are assigned a primary function. A server must not be deployed and used for multiple purposes outside the scope of its primary function. For example, an application server must not also be used for file or print hosting.

A minimal, default Operating System (OS) configuration must be maintained with the necessary services, software components, and applications needed for the normal administration of the system or that might cause the system to become unstable if removed.

Servers must be scanned using a Security Benchmark tool such as CIS-CAT or similar tool upon deployment. Servers must be hardened appropriately according to scanning results.

3.1 Network Hardening and Access Controls

All servers must be configured with multiple levels of firewall protection:

Given the diversity of networked devices and varying levels of administrative boundaries at the University at Buffalo, UB’s entire block of IP ranges must NOT be considered trusted entities.

An “allow list” approach to firewall rules must be taken, whereby:

  • Inbound access to the server's hosted services is limited to the specific ports those services use and also limited to only those hosts or IP addresses for which access is required.

Firewall rules can grow stale quite quickly. Where possible group-based device policies must be employed, such as found in antivirus management consoles.

All firewall rules and configurations must be backed up and subject to configuration and change management auditing.

3.2 Network-based System Administration

All remote administration (non-physical-console) access must be secured with:

  • Encrypted protocols such as SSH, VPN, SSL/TLS, etc.
  • Disabling remote access using built-in system accounts such as root or Administrator

*While certain types of graphical console access exist, such as IP-enabled KVMs, serial consoling or VMware’s console, these methods all still transmit data across the network and must be considered network-based system administration.

All hosts (desktops, laptops, smart devices, etc.) used for system administration purposes must practice sound computer hygiene practices:

  • Secured with an initial password-protected log-on and authorization.
  • Whole disk encryption is required on portable devices.
  • Whole disk encryption is recommended on desktop workstations.
  • Anti-malware software with the most up-to-date malware database.
  • Separate local admin and user accounts.
  • Up to date VPN software.
  • Regular OS and software updates.

3.3 Operating System and Software Stack Hardening

Any bare-metal server or appliance procured from a hardware manufacturer, transferred from another department, or supplied directly by a solution vendor must be re-imaged with a new, appropriate operating system. This is to ensure that systems acquired from an external source do not pose a security risk to the university, computing resources, and sensitive/confidential information.

If additional services or software components are needed on the server, document the changes and update the system baseline (if any).

3.4 System Services and Software

In general, a minimalist or “allow list” approach must be taken when configuring system services, utilities, and other software installations. Tools like Applocker can be leveraged to manage application allowing in Windows. Superfluous services must be removed or disabled.

On Unix/Linux systems, remove additional compilers or development tools (which are not included with the default OS) that may be required to install a software component or library, unless compilers or development tools are required within the scope of an individual’s responsibilities.

Unbind or disable unnecessary network protocols and services if they cannot be removed. Potential threat vectors and vulnerability trails against a server are reduced when it is simply not capable of responding to or initiating particular communication channels.

Configure automated time synchronization. When all network hosts' system clocks and subsequent time-stamp entries of their logs are synchronized, not only does correlating security events across the network becomes easier in security incident investigations, but it also helps ensure accuracy and integrity of the collective evidence.

  • All non-domain controller Windows computers in UB Active Directory (UBAD) rely on the domain controllers as the Network Time Protocol (NTP) server(s) by default.
  • All other servers that are not joined to the UB Active Directory (UBAD) or non-Windows hosts must use tick.acsu.buffalo.edu and/or tock.acsu.buffalo.edu as the authoritative NTP source.

3.5 Patching

Install software updates and patches in a well-communicated, predictable manner either monthly or according the vendor’s patch release schedule. When possible, patch management tools such as SolarWinds should be leveraged to automate and streamline patching. 

3.6 Acceptable Encryption Standards

Encryption technologies must be FIPS 140-2 compliant. This federal standard reviews products and operating systems to ensure encryption is strong enough to withstand modern attacks. Both symmetric and asymmetric cryptosystem key lengths must be at least 2048 bits.

A notable exception is Microsoft's Remote Desktop Services (RDS), which offers native RDP encryption up to 128-bit cipher-strength. Although it is a proprietary encryption algorithm by definition, it appears on the FIPS 140-2 list of approved encryption methods and so it is an acceptable form of encrypted connections for internal administrative purposes.

3.7 Encryption Key Management

A private key used in public-private key pairs of asymmetric cryptography must only be available to the individual associated with the private key's identity or an operational group responsible for the service.

Private keys must only be readable by appropriately privileged accounts and only accessible to applications that require access to the key via the use of an appropriate access control mechanism.

The loss, theft, or potential unauthorized disclosure of any encryption key must be reported immediately to the area’s management, who will then work with the Information Security Office to take corrective measures as deemed appropriate.

3.8 Backups and Data Recovery

Backups of data must be retained per the requirements as communicated by the data owner or custodian. Recovery of data is sometimes critical in the aftermath of a security event.

4. Server Security Monitoring

Tools such as Tripwire, or other appropriate tool, must be used to monitor for any configuration or critical system file changes. 

4.1 Malware Protection

Windows-based servers must run Intrusion Detection and Prevention Systems (IDPS)/anti-malware software (such as SEP) with real-time and/or system event-triggered scanning and protection enabled. Issues reported by anti-malware and IDPS software must be addressed in an appropriate and timely manner. See Appendix B: Security and Configuration Management Tools for a list of approved anti-malware and IDPS tools. Any tools not on this list must be approved by the Information Security Office.

If anti-malware is not available for a server, this should be noted on Appendix A – Server Security Compliance Checklist

4.2 Log Monitoring

Logs must be collected and monitored for on-going security-related events and as part of regular business routines.

Logs must be replicated on a system other than the server generating the logs. This ensures the preservation of forensic information should a compromise of the server occur.

Minimal audit logging must be enabled to capture the execution of privileged operations such as local account creation, granting of privileges, alteration of system or audit settings, and the installation/removal of applications.

All security-related events of systems must be logged and reported to the Information Security Office. Audit trails of security-related events must be saved.

Server customizations will be needed to provide sufficient auditing telemetry:

  • Windows - Microsoft Sysmon should be installed, configured, and logged through Microsoft’s Event Log facility, to capture more detailed information about process creations, network connections, and changes to file creation attributes.
  • Linux – audit.d adjustments should be made to ensure sufficient logging of appropriate system calls, file access and specific audit record types.

Configurations will be provided to system administrators when integrations are made with log management services.

4.3 Vulnerability Scanning

All servers are required to be scanned for vulnerabilities upon deployment and then scanned on a weekly basis thereafter. UBIT provides access to Nexpose for vulnerability scanning and reporting purposes.

Security vulnerabilities reported by vulnerability scanning must be addressed in an appropriate and timely manner.

In addition to vulnerability scanning, penetration testing may be employed if contractually required or required by applicable standards, or upon the system administrator’s discretion.

5. Access Control

Where possible, access controls to files, data, and applications must follow some type of roles-based model, such as:

  • Role-Based Access Control (RBAC) - Permissions are assigned to pre-defined roles. Subjects (user identities) are then added into roles.
  • Mandatory Access Control (MAC) (AKA Bell-LaPadula model) - Categorizes both subjects (user identities) and objects (files and data) with multiple levels of classification (labels). Used in systems with very rich and overlapping data structures and permissions. Access is decided by the system (rather than the owner) by comparing access levels of the subject and the object.

In both of these models, roles and their requisite levels of authorization are established ahead of time. Various access controls are then added to groups (access control lists). User identities are then assigned to a role-based group rather than directly assigned permissions.

In instances where access is based on Active Directory (AD) domain security groups, exercise caution when nesting other security groups whose memberships are controlled by other departments or functional units.

5.1 Administrative and User Accounts

  • Remove or disable unneeded user accounts.
  • Administrators must practice good administrative account hygiene:
    • Separate accounts must be used for administrative versus “everyday” purposes.
    • Administrative accounts, when possible, must be linked to a single user (for auditing purposes).
    • Shared administrative accounts must have their passwords and use restricted and protected to the fullest extent possible.
    • Tools such as sudo or runas must be used to isolate and limit the duration of elevated user privileges.
  • Password/passphrase complexity rules (found on the UBIT password policy page) must be followed.
  • The default Windows Administrator account must be disabled, and a new Administrator account created.
  • Any default passwords for built-in accounts must be changed.
  • Where possible automatic idle time-out log-off of administrative users sessions must be set to 10 minutes.
  • Accounts that have no need for interactive (graphical or command line) logins must be limited through group policy or have their login shells set to an appropriate path.
  • Limit the number of failed login attempt to five. Upon five failed login attempts, the account will be locked out of the system for at least one hour.

5.2 External or Vendor Accounts

  • Restrict usage of user accounts by persons unaffiliated with UB (such as hired contractors and consultants) to a specific period of time required for the purposes of their engagement or support assistance. Only provide the necessary minimum level of access that is required for the task in which they have been contracted.
  • Consider a one-time password for an external contractor or consultant's user account where the hired party is supposed to work from time to time on a per-incident basis. After each work is completed for an incident, the password of the account must be reset. This ensures that the password knowledge, or a "gateway" into a UB system, cannot be easily shared among the external organization's employees and ex-employees. It also ensures that that password knowledge becomes immediately obsolete.

6. De-provisioning

Servers that are being disposed of must have data on their disk drives securely wiped, if possible. Disk drives must be removed and securely disposed of. UB Facilities provides secure disposal of disk drives upon request.

Steps must be taken to securely overwrite (wipe) the digital information on a drive that is being repurposed or being disposed of. For magnetic drive technologies, tools such as shred(1) or dban can be used to write successive passes or random bits to every sector of a drive. Seven passes of random bit along with a final “zeroing” pass must be sufficient to consider the drive forensically wiped. Note: this method does not produce the same results for Solid State Drives (SSD).

Due to architectural differences with SSD technology, secure overwrite methods are not sufficient to forensically wipe on SSD. The following methods can be employed to “destroy” the data on an SSD drive:

  • Leveraging Secure Erase commands built on to drive firmware.
  • Encrypting the drive and then disposing of the keys.
  • Vendor approved methods, sufficient to meet various levels of regulatory compliance.

SSD drives can look much different from classical disk drive technologies. Often SSDs are either fused or plugged into a socket directly on the system board. Care must be taken that the correct discrete storage chips are being extracted from the server for destruction.

7. Exception Cases

Under certain circumstances, a server may be granted an exception to adherence to the security standards defined in this document. Requests for exceptions must be submitted by the system administrator to the Information Security Office. Requests must include technical and business justifications as well as written approval of the Dean or Vice President of the unit requesting the exception. 

Any server that will be processing category 1 or category 2 restricted data (definitions below) will not be subject to the exception process and must meet all hardening standards.  

The exception form is available here: UB Minimum Server Security and Hardening Standards Exception Form (PDF) 71 KB.

7.1 Appliances and Devices

Networked appliances often offer limited controls available to administrators. In these cases it is often not possible to implement all the security controls described in this document and exception requests must be submitted to the Information Security Office. In such cases, firewalls must be used to control access to the appliances and vendor software updates must be applied in a timely manner as they become available. Appliances that are no longer supported by the manufacturer must be retired or replaced.

Network attached peripherals, such as printers or scanners, are not required to adhere to the above standards and are not required to be reported to the ISO if the following requirements are met:

  • The network attached peripheral is only connected to the “NAP VLAN.”
  • The network attached peripheral software is updated on a regular basis.

8. Definitions

Endpoint device: Desktop computer, laptop computer, or other mobile device used to access University at Buffalo data or information.  Use cases include interactive user sessions using standard applications or desktop tools including email, web browsing, desktop publishing, etc.

Restricted data: Data as classified by the University’s Data Risk Classification Policy.

Server: Any device that is configured to accept network connections and provide services to multiple, remote, users.

9. Applicability

The server security and hardening standards apply to servers that reside on the university networks. 

10. Compliance

Any server that does not meet the minimum security requirements outlined in this standard may be removed from the University at Buffalo’s network or disabled as appropriate until the server complies with this standard.

An employee or student who has substantially breached the confidentiality of restricted data will be subject to disciplinary action and/or sanctions, up to and including, discharge and dismissal in accordance with university policy and procedures.

11. Responsibility

System Administrators of servers are responsible for ensuring compliance with these standards.

12. Contact Information

Director, Enterprise Infrastructure Services (EIS)
Computing Center
Buffalo, NY 14260
Phone: 716-645-3031
Email: lps@buffalo.edu
Website: http://www.buffalo.edu/ubit.html

Information Security Officer (ISO)
Computing Center
Buffalo, NY 14260
Phone: 716-645-6997
Email: kpcleary@buffalo.edu
Website: http://www.buffalo.edu/ubit.html

Vice President and Chief Information Officer
517 Capen Hall          
Buffalo, NY 14260
Phone: 716-645-7979
Email: vpcio@buffalo.edu
Website: http://www.buffalo.edu/ubit.html

13. Additional Resources

UBIT Policies

Additional Resources

CISSP CBK Access Control

CISSP CBK Information Security Governance and Risk Management

CISSP CBK Legal, Regulations, Investigations, and Compliance

Guide to Enterprise Patch Management Technologies, NIST SP800-40 Rev. 3

Guide to General Server Security, NIST SP800-123

Guidelines on Firewalls and Firewall Policy, NIST SP800-41 Rev. 1

Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations, NIST SP 800-171

SANS Course: Hacker Techniques, Exploits and Incident Handling

FIPS 140-2 “Security Requirements For Cryptographic Modules” (PDF)