Server Security

• Servers should be secured in locked racks or areas with restricted access.
• All non-removable media should be configured with file systems with access control enabled.
• Servers should be set up in an environment with appropriately restricted network access.
• Whenever possible, the server shall display a trespassing banner at login. Sample banner language may be found at Server Security Standard

• A documented maintenance process should be established to keep applications and operating systems at the latest practical patch levels.
• Vendor-supported patches should be available to RIT for operating systems and applications. Use of operating systems or applications that are no longer supported by the vendor or an open source community requires filing an exception request with the ISO.
• The maintenance process should include a reasonable timetable for routine application of patches and patch clusters (service packs and patch rollups).
• In order to maximize protection of servers from the exploitation of vulnerabilities, for systems supported by vendor patches, patch application should be integrated into an overall server maintenance process.
• In order to support effective incident response, there should be a means to inventory the current level of patches specific to the server.
• In order to reduce the exposure of unpatched servers and to reduce the efforts required to manage servers in a dynamic update environment, there should be a process for monitoring patch installation failures.

• In order to support the creation of an operational baseline for system, and service activities, and to detect and document access control violations, servers should be configured with appropriate real-time OS/application logging turned on.
• There should be a documented process for routine log monitoring and analysis.
• The systems administrator should review the logging process for effectiveness on a semi-annual basis or at a more frequent interval appropriate for the system.
• A log monitoring process should be done on an appropriate schedule.
• Where capabilities exist, logging should include at least 2 weeks of relevant OS/application information. Typically, logging should include the following elements:
  • All authentication
  • Privilege escalation
  • User additions and deletions
  • Access control changes
  • Job schedule start-up
  • System integrity information
  • Log entries should be time and date stamped
• Intentional logging of private information, such as passwords, etc., is prohibited.
• Logging should be mirrored in real time and stored on another secure server.

• To prevent and detect unauthorized programs from running, systems should be configured to restrict changes to start-up procedures.
• There should be a documented change control process for systems configuration.
• Risks should be mitigated by disabling all unused services.
• Up-to-date anti-virus software and definitions should be used where available.
• Servers should use a host firewall.
• Where available, host-based intrusion prevention system software should be enabled.
  • Host-based intrusion prevention (HIPS) software should be employed on authentication servers
  • A list of recommended host-based intrusion prevention software may be found at Technical Resources
• Hardware-based system integrity control should be enabled where available.

• A pre-production configuration or vulnerability assessment should be performed on all servers or services prior to moving them to production.
• Servers should be scanned using an ISO-approved vulnerability scanner before being moved to production, after being moved to production, and ISO-specified periods thereafter.
  • Acceptable vulnerability scanners are listed at Server Security Standard
• ITS is authorized to perform vulnerability scanning on any server on the network.
  • Explicit blacklisting or permanent whitelisting of the ITS vulnerability scanner is prohibited.
• A systems/server administrator is authorized to perform scans when approved by the system owner or ITS.
  • The systems/server administrator will inform ITS of upcoming scans.
• In order to facilitate effective investigations, a copy of the configuration and/or vulnerability assessment reports done at configuration time should be retained and provided to the Information Security Office on request.
• Vulnerability criticality measurements will use CVSS scores as measures of the severity of the vulnerability.
  • Announced vulnerabilities with a CVSS ≥7 should be evaluated for risk within one business day and patches or configuration changes applied appropriately after being announced and made available by the vendor.
  • If the patch would disable a production application or environment, then other steps should be taken to manage the risk of an unpatched vulnerability. The Information Security Officer and the Information Security Coordinator should be made aware of the risk within one business day of identifying the patch conflict.
  • If no CVSS applies to the vulnerability then the vulnerability should be evaluated for remote exploitation
• Only ISO-approved security assessment tools shall be used for scanning.
  • Acceptable security assessment tools are listed at Technical Resources

• All trust relationships will be identified and reviewed at appropriate intervals.
• All manufacturer and default passwords should be changed.
• Strong authentication is required for all users with root/administrator or system privileges.
  • Strong authentication practices are defined on the ISO web site.
• Access Control should be configured to allow only authorized, authenticated access to the system, application and data.
  • There should be a process for granting and removing authorized access.
  • Generic or persistent guest accounts allowing users interactive logins should be disabled.
  • Service accounts are excluded from this requirement.

Operationally Critical data should be backed up.

• All servers with Operationally Critical data should have documented back-up, system and application restoration (including configurations) and data restoration procedures to support business continuity and disaster recovery planning.
• Back-up procedures should be verified at least monthly, through automated verification, customer restores, or through trial restores.
• Backups shall not be stored solely in the same building where the Operationally Critical data is located.
• Backups should be readily accessible.
• Server backups shall be transmitted securely
• Back-up media should be handled according to the Portable Media Security Standard.

• The applications/module administrator is responsible for ensuring the security of their applications/modules.
  • For each application, the application owner should identify an application administrator and systems administrator. These administrators should be approved by their management.
• The application administrator is responsible for application-specific aspects including ensuring the application is in compliance with the server standard where applicable.

• When major modifications are made to services or servers, e.g., new installations, major software upgrade, hardware replacement, server replacement/retirement, the systems administrators and applications administrators should complete a security review/risk assessment.
• The security review shall typically include an architectural diagram, technical and process security controls, and a security checklist.
• The application owner is responsible for ensuring ITS acceptance of the security review.
• The Information Security Office may also conduct security reviews.
• Vendor Services
  • Any system or application administration contracts should be reviewed by purchasing for appropriate risk management clauses.

All servers with network access should be registered in the ITS centralized registration system.

All server storage media and devices that contain RIT Confidential Information should be degaussed or the data otherwise rendered unrecoverable.

• All computers used to administer servers should conform to all requirements for RIT-owned or leased computers as stated in the Desktop and Portable Computer Security Standard.
• Protocols Related to Server Administration
  • Only secure protocols may be used for administrative functions and/or the transmission of login credentials. A list of approved protocols may be found at Technical Resources
  • NTP and DNS require authoritative sources

Servers participating in High Performance/Distributed Computing/ grid computing should employ appropriate and documented safeguards to protect RIT Confidential information and access to RIT internal networks.