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
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:
Upon deployment of any server on a university network, the system administrator of the server must document and catalog the following:
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:
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:
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:
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.
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:
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:
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.
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.
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:
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:
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.
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)