Server Security Standard
This standard applies to servers procured through, operated or contracted by Loyola University Chicago that house or interact with Loyola Protected data per the Data Classification Policy.
The purpose of this document is to establish standards for the base configuration of servers. Effective implementation of this standard will minimize security incidents involving University resources.
Ownership and Responsibilities
All servers deployed at the University must be owned by an operational group that is responsible for system administration. Approved server configuration guides must be established and maintained by each operational group, based on business needs and approved by the Information Security Officer. Each operational group must establish a process for changing the configuration guides, which includes review and approval by the Information Security Team.
- Servers must be inventoried by each operational group. At a minimum, the following information is required to positively identify the point of contact:
- Server contact(s) and location, and a backup contact
- Operating System, Version and Service Pack level
- Main functions and applications, if applicable
- Server inventories must be kept up-to-date on a semi-annual basis.
- Configuration changes for production servers must follow the Change Management System Procedures.
Servers that store, process or transmit Loyola Protected data are classified as high security servers. Additionally, administrators may request that a server which does not store, process, or transmit Loyola Protected data be classified as a high security server. All high security servers must physically reside within secured ITS data centers.
If the high security server stores Protected data it must be segmented into the High Security (Internal) network security zone, per the ITS Network Firewall Policy.
If the high security server interacts with other high security servers, and is required to publish content outside of the High Security network security zones, per the ITS Network Firewall Policy, then it must be segmented into the High Security DMZ network security zone.
General Configuration Guidelines
- Operating System configuration should be in accordance with approved Information Security guidelines, as defined in the References section of this document.
- A server housed in a High Security network security zone may not have more than one primary function. Core services (DHCP, DNS, NTP) may be housed on the same server in a High Security network security zone. If you are unsure of the number of functions on your server, contact the Information Security Team.
- Disable all unnecessary and insecure services and applications.
- System access and security logging shall abide by the ITS Log Management Standard.
- Per PCI Standard 6.2, all servers within the high security environment must have the most recent OS and application security patches installed on the server within thirty days of its release.
- Trust relationships between systems are a security risk, and their use should be avoided. Do not use a trust relationship when some other method of communication will do. Contact the Information Security Team if you are unaware of alternatives to using trust relationships.
- All administrative access will be accomplished per the ITS Access Control Policy and Privileged Access Policy
- If a methodology for secure channel connection is available (i.e., technically feasible), privileged access must be performed over secure channels, (e.g., encrypted network connections using SSH or IPSec).
- Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network. This applies to ALL default passwords, including but not limited to those used by operating systems, software that provides security services, application and system accounts, point-of-sale (POS) terminals, Simple Network Management Protocol (SNMP) community strings, etc.).
- All security-related events on high security servers must be logged, saved and sent to the SIEM.
- All high security backups will be backed up to a separate tape pool. The list of items will be complied with
- Daily incremental backup will be retained for 30 days, and Items that are deleted will be retained for 400 days.
- An inventory of this media will be maintained by the backup administrators
- No media moves outside of the secured data center
- Any backup tapes that become decommissioned will be degaussed
- Security-related events will be reported to the Information Security Team, Corrective measures and information disclosure will be prescribed as needed, as per the ITS Incident Response Handbook. Security-related events include, but are not limited to:
- Port-scan attacks
- Evidence of unauthorized access to privileged accounts
- Anomalous occurrences that are not related to specific applications on the host.
- Audits will be performed on a yearly basis at a minimum by authorized Information Security Team members within the University.
- Audits will be managed by the Information Security Team. The Information Security Team will filter findings not related to a specific operational group and then present the findings to the appropriate support staff for remediation or justification.
- In accordance with the ITS Vulnerability Assessment Policy, every effort will be made to prevent audits from causing operational failures or disruptions.
Exceptions to this policy will be handled in accordance with the ITS Security Policy.
This policy will be maintained in accordance with the ITS Security Policy.
In emergency cases, actions may be taken by the Incident Response Team in accordance with the procedures in the ITS Incident Response Handbook. These actions may include rendering systems inaccessible.
- Data Classification Policy
- Change Management Policy
- ITS Access Control Policy
- ITS Incident Response Plan
- ITS Log Management Standard
- Privileged Access Policy
- ITS Vulnerability Assessment Policy
- ITS Security Policy
- RFC 1918
- The latest applicable CIS Benchmark
- January 24, 2011: Initial Policy
- October 22, 2012: Corrected links, Removed vendor specific references
- July 12, 2013: Corrected Links
- August 7, 2014: Added section to comply with PCI-DSS v3.0 Req. 2.1
- June 23, 2015: Annual review for PCI Compliance
- April 15, 2016: Updated reference, annual review for PCI compliance
- June 7, 2017: Annual review for PCI Compliance
- July 12, 2018: Modified backup section, Annual review for PCI Compliance
- June 5, 2019: Annual review for PCI Compliance