. .

The Ohio State University
Web Service 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 Web Service Security Standard (WSSS) establishes security requirements for web applications, web services and web 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 and from alteration or theft of data while preserving university community members’ appropriate access and use.

The WSSS 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 , Critical Server Security Standard, Database Computer Security Standard and are available here.

II. Scope

This standard applies to servers that host web servers, web services or web applications and that have been deemed 'critical' based on the criteria in section III of the OSU Critical Server Security Standards - 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.

Compliance with the standard is 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.

Technical staff, which for the purpose of this standard is anyone who maintains or supports a web server, or anyone who develops, deploys, or maintains a web application or other web content.

III. The Web Server Security Standard

a. Standards Compliance
The server hosting the web server, web service, or web application must comply with the OSU Minimum Computer Security Standard and the OSU Critical Server Security Standard.
All servers that host web servers, web services or web applications and that have been deemed 'critical' based on the criteria in section III of the OSU Critical Server Security Standards 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. Installation and Configuration
Since often web servers exist as applications on a host operating system, they require special considerations during the configuration and installation phase of deployment.
Technical staff MUST:
1. Configure web services in accordance with vendor security recommendations.
2. Ensure that only those web services or applications specifically needed should be enabled. Web services, applications, and sample content which is not needed should be disabled.
3. Patch Web server software and web applications to all current security patches, as required by the OSU Critical Server Security Standard. Software developed by vendors or developers unresponsive to patching security vulnerabilities should be replaced with alternative software. If alternative software is not available, a responsible party may assume patching responsibility, or compensating controls must be put into place.
4. Configure the web server to allow access only to data that is meant to be publicly available. Configure a robots.txt file to properly protect content from automatic collection by web crawlers. "Obscure" or "secret" file or directory names must NOT be used to protect content.
5.Monitor comments on blogs and other forums if anonymous posting is allowed. This responsibility may be delegated to non-technical staff as deemed appropriate by the department or unit.
6. Prohibit web servers and web applications to run with elevated privileges (e.g. “root” or “Administrator”).
7. Use secure mechanisms to allow developers to install new or update existing content. Traditional FTP or other unencrypted password-based systems must not be used. Alternative protocols that provide encryption and secure authentication (e.g. SSH/SCP, SFTP, and rsync/SSH) must be used.
Technical staff SHOULD:
1. Store content uploaded through web applications outside of the document root.
2. Limit the ability of web server and web application user accounts to modify other programs, logs, or system configuration files by limiting account privileges.
c. Logs
Technical staff MUST:
1. Develop or configure web servers and applications to write logs that are adequate for incident response and security investigations. Useful log information includes, but is not limited to: Failed and successful login attempts, Account privilege changes and Timestamp information. Logs must contain the URLs as requested by the client. Logs must be retained for a minimum of 90 days, as with CSSS.''
2. Keep discrete log files for each virtual web server If there are multiple virtual web servers hosted on a single server instance.
3. Copy web service logs to a separate secure log server for retention.
c. Encryption
Technical staff MUST:
1. Use SSL/TLS encryption when transferring all restricted data (as defined by the OSU Interim Policy on Institutional Data).
2. Use commercially signed or authorized certificates for web services outside of the department or unit.
3. Renew certificates before their expiration date.
d. Secure Software Design, Implementation and Testing Procedures
Unit administrative staff SHOULD:
1. Train those who develop web applications in secure code design, implementation, and testing procedures.
2. Review code to identify and correct common mistakes where possible or appropriate before deployment.
Technical staff SHOULD:
1. Prevent the error messages from underlying systems and processes from being publicly available to the web browser.
2. Only use active client-side and server-side content when absolutely necessary, and then with extreme caution.
3. Frequently and regularly scan web services for vulnerabilities (e.g. SQL injection flaws, cross-site scripting).

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 ITSecurity@osu.edu.

VI. Definitions

Interactive Content: All content excluding static files that would be directly served by the web server. Interactive content examples include but are not limited to: PHP, ASP, Cold Fusion, Java, and files using server side includes.

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.
Non-interactive Content: Content includes: static HTML files, images, text, video, and audio.
Web Application/Web Service: An application that has an interface accessible through a web browser.
Web Server: Anything that is intended to serve content to an Internet browser using the Hypertext Transfer Protocol (HTTP), including but not limited to: Apache HTTP Server, Microsoft IIS.

VI. References

VII. Revision History

  • Revised draft 1.6 SEM 5/6/07
  • Revised draft 1.7 SR 5/8/07
  • Revised draft 1.8 CM-J 7/31/07
  • Revised draft 1.9 SWH 8/3/07
  • Revised draft 1.10 SWH 8/13/07
  • Revised draft 1.11 SWH 8/17/07
  • Revised draft 1.12 CJS 8/23/07
  • Revised draft 1.13 CJS 8/27/07
  • Revised draft 1.14 CJS 8/28/07
  • Revised draft 2.00 CM-J 8/31/07
  • Revised draft 2.02 SES/MA 6/14/08

Comments on this standard should be sent to ITSecurity@osu.edu
Return to the University Computer Security Standard Page