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 10, 2023

All university owned devices, regardless of funding source (ex: State, UBF, RF, grants, etc.), must be procured and setup by departmental/node IT staff. Servers should be administered, procured and setup by the designated IT unit. 

This standard codifies the minimum required security standards for all servers residing on UB networks and provides a coordinated approach to Information Technology (IT) security and data privacy. It directly supports the university's Data Access Policy.

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
  

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?
  
• A completed Server Security Compliance Checklist (Login required: IT Staff only).

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.  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 cannot 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.   

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.

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

• Host based – controlling traffic egress and ingress at the host level
• Network perimeter based – controlling traffic at the network/subnet perimeter or gateway. This is usually accomplished by UB Departmental Firewalls (Login required: IT Staff only).
  

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 are also limited to only those hosts or IP addresses for which access is required.

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

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

All remote access for administrative activities must be done over encrypted protocols, including:

• SSH, RDP, VPN, SSL/TLS, etc. using non-administrative connections to gain remote access. VNC is not considered a secure protocol. Non-console administrative remote access should be disabled for protocols such as SMB, RPC, RDP and SSSH.
  Remote access using the protocols should be disabled for built-in system and/or administrative accounts such as root or Administrator. This also includes any administrative domain accounts that are part of a system's local administrators' group.
• Administrative activities should be accomplished via:
  • Secured console sessions such as:
    • IP-enabled KVMs or serial consoling on secure or non-routable network segments
    • VMware console
  • Using a non-privileged exception account to:
    • Remotely access a system using SSH, RDP or other secure, encrypted remote access protocol
    • Leverage technologies such as "run as," "MakeMeAdmin," or "sudo" to temporarily elevate account privileges to that of a privileged account.
      

Privileged accounts should have their ability to remotely log in limited by adjusting GPO or SSHD/PAM settings. More details on privileged account management and changes and hygiene can be found in the "Privileged Access Management with Administrative and User Accounts."

Interactive use of administrative or system/service accounts should NOT be directly used for remote administration of a system using protocols such as SSH or RDP logins.

All administrator endpoints must comply with Endpoint Hardening standards for high-risk endpoints.

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, changes should be documented and the system baseline updated.

Where possible, egress (outbound blocking) rules should be employed such that only minimum necessary TCP/IP ports communicate outside of UB or local networks.

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.

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

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.

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.

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.

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

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 (Login required: IT Staff only). 

Logs must be collected and monitored for ongoing 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.

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 contractually required or required by applicable standards, or upon the system administrator’s discretion.

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 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.

• Remove or disable unneeded user accounts.
• Administrators must practice good administrative account hygiene:
  
  • Separate ITORG exception accounts, protected by MFA,  must be used for system administrative purposes.
  • Administrative accounts, when possible, must be linked to a single user (for auditing purposes).
  • Administrative accounts must have their passwords and use restricted and protected to the fullest extent possible.
  • Tools such as sudo, MakeMeAdmin or runas must be used to isolate and limit the duration of elevated user privileges.
  • Tools such as Local Administrator Password Solution (LAPS) must be used to manage local administrative accounts.
    
• Passphrases should be complex and at least 16 characters in length.
  
• The default Windows Administrator account must be disabled, and a new 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, such as system or service accounts, must be limited through group policy or have their login shells set to an appropriate path.
• Limit the ability of a local administrator account to log in from a local interactive session (e.g., Deny access to this computer from the network) and prevent access via an RDP session.
  
  • In Windows this can be accomplished by setting the following in a GPO to target the built-in administrators' group
    • "Deny logon through Remote Desktop Services"
    • "Deny access to this computer from the network" GPOs to
      
• 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.

System administrators should report any signs or suspicions of compromise to the Information Security Office (ISO) as soon as possible.  The ISO can help assess scope/impact and aid in determining response plans.

• Third party or volunteer exception accounts with access to UB systems and data should be configured with MFA.
  
• 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.

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 re-purposed 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.

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 will not be subject to the exception process and must meet all hardening standards.  

The exception form is available at:

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.

Category 1 Data: Restricted Data as classified by the University's Data Risk Classification Policy.

Category 2 Data: Private Data as classified by the University's Data Risk Classification Policy.

Client: An individual person or user.

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.

Server: 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.  

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

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 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.

Individuals who suspect a misuse of this standard must report their concerns to the ISO.

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

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

Assistant Vice President and Chief Information Security Officer (ISO)
Computing Center
Buffalo, NY 14260
Phone: 716-645-4767
Email: jgrupp@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

Computing and Network Use Policy

Data Risk Classification Policy

Additional Resources

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

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 Rev. 2

SANS Course: Hacker Techniques, Exploits and Incident Handling

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