The Server Standard provides requirements for server configuration and use at RIT.
A list of ISO-approved security assessment tools, HIPS programs, secure protocols, and a sample trespassing banner can be found in the Technical Resources
This standard applies to all servers (including production, training, test, and development servers) and the operating system, applications, and databases (unless explicitly excluded) defined by this standard that provide services to the RIT community.
This standard applies to administrators and information trustees of all servers that are connected to the Institute network.
The following security controls should be applied to, enabled, and running on all servers that connect to (or access) the Institute network no later than August 1, 2009, and all times thereafter. If products are not available from reputable commercial or reliable open source communities for a specific requirement, then the specific requirement is waived until an appropriate solution is available. When the term “appropriate” is used, systems administrators are expected to use their professional judgment in managing risks to the information and systems they support.
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:
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.
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.
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.
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.
Any system or application administration contracts should be reviewed by purchasing for appropriate risk management clauses.
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.
What does the standard apply to?
All servers (including production, training, test, and development) and the operating systems, applications, and databases as defined by this standard.
The standard does not apply to individual student-owned servers or faculty-assigned student servers for projects; however, administrators of these servers are encouraged to meet the Server Standard.
Recommended Strong Authentication Practices
The RIT Information Security Office recommends that all systems requiring strong authentication
comply with RIT's password and authentication standard (REQUIRED)
use a complex password of 12 or more characters. Fifteen or more characters are preferred.
use multi-factor authentication such as:
certificate-based authentication (PKI)
one-time passwords (OTP)
challenge / response systems
Approved Vulnerability Scanners
Nessus, Nexpose, and NMap are approved for scanning servers at RIT. For information on the scanning conducted by the RIT Information Security Office see the Vulnerability Management Program at RIT.