The Ohio State University
Database 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
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 Database Server Security Standard (DSSS) establishes security requirements to help protect the university’s critical database utilizing servers from accidental or intentional damage and from alteration or theft of data while preserving university community members’ appropriate access and use.
The DSSS is one of four interrelated Standards, each of which addresses a different aspect of computer, network and data security. These include the Critical Computer Security Standard, Minimum Computer Security Standard and Web Services Computer Security Standard and are available here.
II. Scope
This standard applies to all database servers utilized by units, faculty and staff of The Ohio State University that contain data classified as restricted by Ohio state law, Federal law, and OSU's Data Classification Policy whether owned by the university, a university community member or a 3rd party organization, that connect to the university data network or support infrastructure either directly or indirectly.
This standard applies to servers that have been deemed 'critical' based on the criteria in section III 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 installs, maintains or supports a critical server, or anyone who develops, deploys, or maintains an application that resides or runs on a critical server..
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 Database Server Security Standard
a. Standards Compliance
All servers that host databases, database services or database applications and that have been deemed 'critical' based on the criteria in section III of the
OSU Critical Server Security Standards (CSSS) must comply with this standard. These criteria are repeated here for the reader's convenience:
“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.
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 document compensating controls and any exception. 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. Network and Firewalls
Special considerations are required when configuring network and host based firewalls to protect database servers, which go beyond the requirements specified in the CSSS. These are:
Technical staff MUST:
1. Configure network/host based firewall rules to restrict access to the database server as much as possible. In particular, access should be restricted to OSU address space, or if applicable only to those servers which access the database. Off campus access should be done through a VPN or similar encrypted remote access strategy.
2. Ensure that database connectivity APIs such as ODBC or JDBC do not store their connection information (especially account names and passwords) unencrypted, if technically possible. Where technically possible, disable or configure tracing functions so that they do not capture authentication information in their logs.
Technical staff SHOULD:
1. Encrypt the network session or use an encrypted or one-time authentication system to protect the database server from sniffing and replay attacks.
c. Installation and Configuration
Since often database servers exist as applications on a host operating system, those that meet the requirements of this standard also require special considerations during the configuration and installation phase of deployment.
Technical staff MUST:
1. Ensure that database servers are not hosted on the same server as the associated web server with their associated web servers.
2. Install and configure database software in accordance with vendor security recommendations
3. Ensure that only database administrators and system administrators will have operating system login access on the database server.
4. Run database servers under accounts without administrative or root privileges whenever technically possible.
5. Use a version of database software that is currently supported by the vendor or open source project, as required by the OSU Minimum Computer Security Standard.
6. Disable and remove unused software components and all unnecessary features, if technically possible.
Technical staff SHOULD:
1. Run only database server application scripts supported and controlled by the database or system administrators.
c. Accounts, Passwords and Privileges
Database servers that fall under this standard require special consideration when identifying access configuration. Database servers that contain restricted data are required to meet the following account access, password and privilege configurations:
Technical staff MUST:
1. Provide database and system administrators with their own OS accounts. No group accounts are permitted.
2. Login to the server using their own accounts rather than logging in as root or Administrator.
3. Create separate accounts for running automated tasks (backups, replication, etc.) that do not allow direct logins. Administrators must not use these accounts for other tasks.
4. Ensure that the OS account that the database server runs under does not allow direct logins.
5. Provide individuals who need direct database access with their own accounts. Applications that do their own authentication do not need to use separate database accounts for each user.
6. Provide each application (including web applications and automated processes) with its own database account.
7. Use the principle of least privilege when assigning access rights to operating system and database accounts. This is especially important for application accounts - these must only have access to the parts of the database that are needed.
8. Use strong passwords for all accounts (see the Critical Computer Security Standard for details).
9. Configure database accounts to lock for 15 minutes after 5 failed connection attempts, if technically possible.
10. Audit accounts and associated privileges monthly and remove or disable accounts and privileges when they are no longer needed.
Technical staff SHOULD:
1. Manage database permissions through roles or groups rather than for each separate account.
e. Restricted Data
Sometimes restricted data must be stored in database servers for use in search or other functions. All database servers under this standard must take appropriate steps to safeguard any restricted data maintained within them and meet the following requirements:
Technical staff MUST:
2. Prevent the use of "real" restricted data in testing or development environments. If this cannot be done, then ensure that the testing or development environments conform to the Critical Computer Security Standard and this Database Security Standard.
3. Use a redacted version of restricted data if technically possible.
4. Use encryption to protect restricted data if technically possible.
Technical staff SHOULD:
1. Hash restricted data if it is only used for searches.
f. Auditing and Monitoring
Database servers that meet the requirements of this standard or contain restricted data and as a result administrators are responsible for knowing what data is located on their servers. Administrators must implement and utilize practices that allow for the audit and monitoring of database systems containing this data by:
Technical staff MUST:
1. Log the creation, alteration or deletion of database accounts, storage structures, objects, and tables.
2. Log enabling and disabling of and any changes to audit functionality.
3. Log granting and revoking of access rights.
4. Log all connection failures. Where technically possible, audit all successful and unsuccessful connection attempts.
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 database 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 ITSecurity@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.
VII. Reference
VIII. Revision History
- Revised draft 1.6 SEM 5/6/07
- Revised draft 1.7 SR 5/8/07
- Revised draft 1.8 CM-J 8/1/07
- Revised draft 1.9 SR 8/14/07
- Revised draft 1.10 SR 8/16/07
- Revised draft 1.11 SR 8/31/07
- Revised draft 2.0 CM-J 9/6/07
- Revised draft 2.01 SES 6/4/2008
- Revised draft 2.02 SES 6/13/2008
Comments on this standard should be sent to ITSecurity@osu.edu
Return to the University Computer Security Standard Page
