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: November 2, 2020
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:
Upon deployment of any server on a university network, the system administrator of the server must provide the following information to the Information Security Office:
System information and the security checklist are required to be updated for each server on an annual basis and re-submitted to the Information Security Office.
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 quite quickly. Where possible group-based device policies must be employed, such as found in Symantec Endpoint Protection’s (SEP’s) management console.
All firewall rules and configurations must be backed up and subject to configuration and change management auditing.
All remote administration (non-physical-console) access must be secured with:
*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:
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).
In general, a minimalist or “whitelist” approach must be taken when configuring system services, utilities, and other software installations. Tools like Applocker can be leveraged to manage application whitelisting 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 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 tool, 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.
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:
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 employed if 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 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.
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:
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.
The exception form is available here: UB Minimum Server Security and Hardening Standards Exception Form (PDF).
Networked appliances and are often “black boxes” with 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 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 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.
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
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
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)
