The Ohio State University
Critical Server Security Standard
Draft June 17,2008
Comments on this standard should be sent to ITSecurity@osu.edu
Link to Compensating Control & Exception Request page
Link to the Critical Server Registration Form
I. General Statement
The Ohio State University data network is a shared resource used by the entire university community and its affiliates in support of the university’s business practices and academic missions. Access to the data network is both an essential tool for university life and work and a valuable privilege. University units and community members must cooperate to protect the network by securing computer and network devices in order to preserve that access.
The Chief Information Officer (CIO) is responsible for the efficient, effective and secure operation of the university data network. Concurrently, academic, administrative and support units are responsible for the efficient, effective and secure operation of their local networks.
The Critical Server Security Standard (CSSS) establishes security requirements for servers that are critical to The Ohio State University and to help protect the university’s central and distributed telecommunications and computing environment from accidental or intentional damage. The standard is also intended to protect the university’s connected assets from alteration or theft of data while preserving university community members’ appropriate access and use.
The CSSS is one of four interrelated Standards, each of which addresses a different aspect of computer, network and data security. These include the Minimum Computer Security Standard, Database Computer Security Standard and Web Services Computer Security Standard and are available here.
II. Scope
This is a security standard for servers. Other standards and policies may set the security standards for non-server computers (laptops, desktops, etc.) These other standards and policies also may control the handling of restricted data on non-server devices.
This standard applies to servers that have been deemed 'critical' based on the criteria in section three of this standard, whether owned by the university, a university community member or a 3rd party organization, and that connect to the university data network or support infrastructure either directly or indirectly.
This standard outlines the responsibility of all university community members, including students, faculty, staff, agents, guests or employees of affiliated entities who connect a device, either directly or indirectly, to the university data network or support infrastructure.
Unit administrative and technical staff for the purpose of this standard is defined as anyone who installs, maintains or supports a critical server, or anyone who develops, deploys, or maintains an application that resides or runs on a critical server.
III. The Critical Server Security Standard
All servers that have been deemed 'critical' based on the following criteria:
A ‘critical’ computer meets at least one of the following criteria:
1. It serves restricted data, as defined in the “OSU Institutional Data Policy.”
2. Loss of service carries a significant financial liability, including grants and contracts.
3. Loss of service results in a significant negative impact(s) for the unit or for the reputation of the university.
4. Unit administration deems the server to be critical.
Requests to connect servers to the OSU network that are not owned by the university must be reviewed and approved by CIO Security prior to placing the server on the network. When equipment that is not owned by the university is placed on the network, the equipment owner consents to vulnerability scans of the equipment by CIO Security, departmental staff or both.
a. Standards Compliance
In some cases it may not be possible to bring a device into compliance. For example, older laboratory equipment software may not operate with current operating systems or security patches. In these cases operating units or individuals and their information technology staff must employ compensating controls. In rare cases an exception may be made if no compensating control is possible.
Units must internally document requested compensating controls and any exceptions. These must be reviewed, tested, and approved by the CIO Security Group and the operating unit or individual must retain the approved documentation for audit so long as the device is in operation.
b. Registration of Critical Servers
Units are required to register all critical servers with CIO Security. Technical staff must register all IP addresses and DNS host names and 24/7 contact information for the administrators who are responsible for the servers. Information identifying department or controlling unit is also required.
Units can register their critical server assets by filling out the form at this
link for each server and submitting the report to the IT Security Group. Units are expected to maintain local records of critical servers as well.
c. Physical Security
The physical security of servers deemed critical is just as important as the information and digital security of the contents of the servers.
Unit Administration MUST:
1. Provide an appropriately secured environment to house critical servers that will prevent unauthorized entry, access or theft.
Unit Administration SHOULD:
1. Consider providing levels of environmental protection and monitoring that are commensurate with the risks and consequences of server failure due to loss of power, overheating, theft and other physical risks.
d. Backup and Recovery
Ensuring the safety of data requires that units appropriately plan for disaster recovery and restoration of the data on servers that are deemed critical to the university.
Technical staff MUST:
1. Follow best practices for backing up critical servers.
2. Encrypt backup media including backup tapes that contain Restricted Data.
3. Securely store encryption keys necessary to decrypt the backups separately from the backup media.
4. Document key management procedures for decrypting backups and assure that they are available to more than one person and approved by the data custodian and data steward. (For role definitions, see the
OSU Institutional Data Policy).
e. Data Destruction
Proper disposal of server storage media containing critical data must be followed.
Technical staff MUST:
1. Sanitize media containing Restricted Data when the data are no longer needed according to Defense Security Service's “Clearing and Sanitization Matrix.”
2. Follow the surplus property rules for disposal of university equipment.
f. Intrusion Detection and Security Tools
Technical staff MUST:
1. Treat and investigate system changes as computer security incidents unless it can be determined conclusively that the changes were authorized
Technical staff SHOULD:
1. Implement host-based intrusion detection methods that incorporate baseline comparisons.
2. Install a file integrity monitoring system to monitor system changes.
g. Incident Response
Technical staff MUST:
1. Immediately report all computer security incidents on critical computers to CIO Security email
security@osu.edu.
2. Protect evidence pertaining to the incident. It is particularly important to preserve as much forensics data as possible.
Following these steps would greatly assist the Security group in its evidence gathering:
A. If the computer contains or is used to process Restricted Data, then unplug the network connection(s) to prevent data loss. You can remove network connectivity for other computers, but be aware that the intruders may have rigged things to damage the computer on loss of network connectivity.
B. Await instructions from CIO Security Group. If you do not receive a response within 2 hours contact us again at our pager (8-5650) and stress that this is a security incident related contact.
C. Do not kill running processes, disable running services; run anti-virus or anti-spyware scans, move, rename or delete files, or shut down, log into or reboot the system. Any changes you make to the system will obscure potentially valuable evidence.
h. Logging
Technical staff MUST:
1. Configure systems to capture appropriate levels of information. Do not reduce audit levels below the vendor defaults; increase audit levels above the default settings where possible.
2. Log all configuration or file changes, and system events in an audit log.
3. Retain all system logs for at least 90 days.
4. Copy logs (in real time if possible) to a separate log server which is properly secured. This specifically includes UNIX syslog, Windows event logs, any authentication logs, any separate application, web, email and database server logs, and DHCP logs. Also copy logs with specific utility in incident investigations* to the log server.
i. Accounts and Passwords
Technical staff MUST:
1. Provide accounts with system administration capabilities to as few individuals as is necessary.
2. Change all domain and local administrative passwords every 90 days.
3. Provide all users with their own non-administrative logon accounts.
4. Prohibit use of administrator/root level accounts as logon accounts except when absolutely necessary. Administrators should use their own personal accounts to logon and then elevate their privileges as needed to do work (using tools such as UNIX “sudo”, Windows “runas” or “winsudo”).
j. Internal Change Control Procedures
Technical staff MUST:
1. Adopt change control procedures appropriate for the unit’s Information technology and business environments.
k. Secure Software Design, Implementation and Testing Procedures
Unit Administration MUST:
1. Ensure that application developers receive training to design, implement, and test secure code.
2. Ensure that all code is reviewed to identify common mistakes and fix code flaws to ensure that similar code sections are fixed.
l. Network and Firewalls
Technical staff MUST:
1. Configure any remote access to critical servers from outside the DMZ or private network to use encrypted transport.
2. Log all access attempts to remote access end points (VPN concentrators, servers allowing Remote Desktop, Terminal Services, ssh, etc.).
3. Monitor remote access logs daily for unauthorized activity.
4. Restrict remote access to defined external clients or servers and monitor the system for unauthorized activity.
5. Segregate critical and non-critical servers LAN segments.
6. Configure critical servers to synchronize their clocks with an accurate time source at least once a day.
7. Place computers behind a network-based firewall that blocks all inbound traffic by default.
8. Limit service exposure through firewall rules and controls and monitor them for unauthorized activity.
Technical staff SHOULD:
1. Configure remote access to require strong authentication, either through one-time passwords, a 2-factor system or through TLS with client and server certificates.
2. Configure host-based firewalls to filter outbound traffic on the critical server using rules consistent with the department's business requirements.
IV. Enforcement
Either unit IT staff or CIO Security can enforce this standard; this includes the right of either group to scan equipment for compliance at any time.
At any time, central or distributed unit information technology staff may scan or examine critical servers for compliance and may disconnect or quarantine any noncompliant server from the university data network until the server is brought into compliance. Individual university community members who do not comply with this standard are in violation of the Policy on Responsible Use of University Computing and Network Resources.
In accordance with that policy, violators may be denied access to university computing resources and may be subject to other penalties and disciplinary action including university disciplinary procedures appropriate to their university status.
Equipment found to be in violation of this standard will have its network access suspended until the equipment is brought into compliance with the standard. In addition, appropriate administrators of the unit in which the violation occurred will be notified.
V. Appeal
Decisions or measures taken to implement this standard may be appealed to the Chief Information Officer through the CIO Office Director of Information Technology Policy and Services by sending an e-mail to ITPolicy@osu.edu.
VI. Definitions
Must: means that this control must be implemented unless an exception has been specifically requested and granted (typically with some sort of compensating control).
“Must ... if technically possible”:means that this control must be implemented if the product supports it. Locally developed software must be modified to provide necessary features in these cases. Performance issues can be considered in determining whether something is "technically possible", although it is better if systems can be engineered to provide adequate performance with the security controls in place.
Should: means that this control is a good security practice, but is not required for compliance with this policy. An exception does not need to be requested/granted in cases where you do not implement "Should" items.
Restricted Data: Specific data or data types defined in the OSU Institutional Data Policy as restricted in nature.
Security Incident: Computer security incidents occur when a security policy or standard has been violated. Examples include theft; virus, spyware and other malware infections; unauthorized logons; unauthorized access to restricted data; unauthorized changes to the system and other similar situations.
Remote Access: Access, usually administrative access, from outside administrative control – i.e. not the console or other directly connected device.
VII. References
VIII. Revision History
- Revised draft 1.7 SEM 5/6/07
- Revised draft 1.8 SR 5/8/07
- Revised draft 1.9 CM-J 7/31/07
- Revised draft 2.0 (major revision) CM-J 8/12/07
- Revised draft 2.1 CM-J 9/18/07
- Revised Draft 2.11 SES 4/7/08
- Revised Draft 2.12 SES/MA 4/13/08
Comments on this standard should be sent to ITSecurity@osu.edu
Return to the University Computer Security Standard Page
