OSU Navigation Bar

Web Service Security Standard

Original Draft June 17, 2008 / Revised July 1, 2012

Date of Enforcement: January 1, 2011

Comments on this standard should be sent to ITSecurity@osu.edu

Tools

Web Service Security Standard Evaluation Checklist PDF

I. Informal Overview

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 Server Security Standard (WSSS) establishes security requirements for web servers, web applications, and web services that are critical to The Ohio State University.  The standard is intended 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 WSSS is one of the interrelated IT Security Policy supporting standards, each of which addresses a different aspect of computer, network and data security. These include the Client Computer Security Standard, Critical Server Security Standard, Database Computer Security Standard and are available here.

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.

This standard outlines the responsibility of all university community members, including students, faculty, staff, agents, guests, or employees of affiliated entities.  This includes (a) individuals who connect a device, either directly or indirectly, to the university data network or support infrastructure, (b) individuals who install, maintain, or support a critical server, (c) individuals who develop, deploy, or maintain an application that resides or runs on a critical server, and (d) individuals who maintain or support a web server, or anyone who develops, deploys, or maintains a web application or other web content.

II. Implementation Guidance

Since the scope of the WSSS encompasses an audience that does not necessarily include those well versed in information technology and might include other general users, the following section is meant to outline not just the intent but also some platform specific guidance to aid in meeting the requirement of the standard. This implementation guidance can be found in supporting documents on this site or in the Web Service Security Standard FAQ.

III. The Web Service Security Standard

The server hosting the web server, web service, or web application must comply with the OSU Client 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. A portion of those criteria are repeated here for the reader's convenience:

A 'critical' computer meets at least one of the following criteria:

  1. It contains or 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.

a. 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.

b. 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.

d. Encryption

Technical staff MUST:

  1. Use SSL/TLS encryption when transferring all Restricted Data (as defined by the OSU 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.

e. 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. Compliance

a. Standards Compliance

All designated critical devices must comply with the OSU Critical Server Security Standard.

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 OCIO Enterprise Security 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 OCIO Enterprise 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 OCIO Enterprise Security. Units are expected to maintain local records of critical servers as well.

c. Role of Units, IT staff, and others

The user’s department/unit is responsible for ensuring compliance with the WSSS, though departmental/organization IT staff may perform the actual implementation on university owned equipment.

The user is responsible for compliance on personally owned equipment. Users granted responsibility for administration on university equipment will share responsibility for compliance with local IT staff (i.e., local administrator rights, users granted access via a local administrative privilege standard policy).

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.

Units are required to register all critical servers with OCIO Enterprise 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 OCIO Enterprise Security. Units are expected to maintain local records of critical servers as well.

d. Role of OCIO Enterprise Security

OCIO Enterprise Security is tasked with the responsibility of maintaining the university security standard and ensuring that this document is kept current with threats and technologies going forward. OCIO Enterprise Security will include community feedback and do publicity for any changes to the document.

OCIO Enterprise Security is recognized as the enterprise subject matter experts on information security practice and policy and in that role can be asked to perform security assessments or consultations with university units.

e. Compliance Mechanisms

Compliance with the standard can be accomplished using a variety of technological or practical tools. Units that have the capability to perform automated detection of patches and vulnerabilities (such as Altiris, LANdesk, Cisco Clean Access, Juniper NAC, etc.) should use these tools to do regular inspection of their networks to gather information regarding the state of compliance.

Those units that do not have the capability to run automated tools to gather compliance information are encouraged to consider purchasing/acquiring these tools but may elect to use a manual process such as spot inspection of computers to determine overall compliance.

NOTE: Units must conduct a compliance inventory on all university-managed devices on no less than a quarterly basis.

The OCIO Enterprise Security may conduct an inspection of unit resources in cooperation with the unit leadership and IT staff to determine overall WSSS compliance. These spot inspections are required if a unit is confirmed through investigation to have been involved in a WSSS related data breach.

Devices found not to be in compliance must be quarantined from the general network and the compliance issue must be addressed before it may be restored to normal operation. If the device cannot be made compliant the unit may implement a compensating control or request an exception. Upon approval of the exception request the device may be restored to normal operation.

V. Compliance Reporting

Units are expected to report to the Office of the Chief Information Officer on the details of WSSS compliance. Registered critical server information will be validated and maintained in a current status. Units are required to certify the accuracy of these registrations on a quarterly basis using the web based reporting tool maintained by OCIO Enterprise Security.

This information will be used for audit and compliance checking by OCIO Enterprise Security during required and random checks. These numbers are also reported up to the Board of Trustees. Units are encouraged to add comments using the web form when special circumstances surrounding compliance with the WSSS are identified. These comments will also help the university identify areas where compliance concerns exist and discussion of general technology solutions or security advice can be offered.

Designated members of each unit should file reports though colleges and larger departments may be asked to roll up report numbers to simplify the process of analysis. One administrative designee as well as at least one IT professional should be assigned the task of collecting and reporting this information.

VI. Review

The Office of the Chief Information Officer must review this document and must update or modify the standard requirements as necessary on at least a biannual cycle.

VII. Glossary

  • anti-malware – software designed to combat malware software by protecting computers from attack, neutralization or removal of the offensive programs.
  • compensating controls – a method of addressing the risk associated with a standard requirement by using alternative techniques to mitigate the risk.
  • computer - a desktop or mobile device (including smart phones, PDA, etc.) that is used primarily for normal desktop application work. With regards to the CCSS computer does not include computing devices with a dedicated use like building control systems or dedicated appliances that perform only a dedicated function. This definition does not exclude desktop systems traditionally used for desktop purposes that are re-tasked for use in non-traditional roles. (i.e. lab instrument control)
  • data network – a group of interconnected computers managed by The Ohio State University
  • device – for the purposes of this standard, device is an interchangeable term with the above definition of computer.
  • firewall software – a part of a data network that is designed to block unauthorized access while permitting authorized communication. Firewalls can be software or dedicated computers that are configured to control computer traffic between different computer networks based upon a set of rules and other criteria.
  • 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.
  • manually – updated through a manual process, this process can include some automated tools but is generally accomplished using manpower resources and monitored directly by employees.
  • non-compliant – a device that does not meet the requirements of the standard.
  • operating system - The most important program that runs on a computer. Every general-purpose computer must have an operating system to run other programs.
  • OSUNet – the Ohio State University data network.
  • password - a sequence of characters that one must input to gain access to a file, application, or computer system.
  • quarantine – to isolate the device from other connected devices in a way that protects the device from exposure and prevents the device from potentially affecting the other resources on the data network.
  • supported – software and hardware that is currently receiving security updates by the manufacturer.
  • university-managed devices – devices purchased, owned, gifted, granted and maintained by university employees. University-owned devices can include supported computer systems and devices purchased through any of the various funding models including but not limited to grants, endowment, direct purchase, etc.
  • user name – a specific log in identity keyed to an individual user. User names are typically used to gain access to a computer operating system or application.
  • viruses, spyware or adware – a group of computer programs classified as “bad” or malware. Viruses, spyware and adware often exploit flaws in computer programs and operating systems to extract information or attack the integrity of a data network.
  • web browser - a computer program used for accessing sites or information on a network (such as the World Wide Web)
  • "It contains or serves Restricted Data" - Servers that contain or serve Restricted Data and servers that have significant risk of exposing Restricted Data. Obvious cases include web, file, mail and database servers that either contain Restricted Data or which provide access to Restricted Data. These present a higher risk to the University since exploitation of vulnerabilities in the network services that they provide could lead to exposure of Restricted Data. There are non-obvious cases as well.
    For example, web servers that have applications which access database servers that contain Restricted Data are also high risk, since the Restricted Data could inadvertently be exposed through attacks against the web applications (such as SQL injection attacks), even though the web server doesn't intentionally provide access to Restricted Data and doesn't itself contain Restricted Data.
  • 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. 
  • Non-interactive Content - Content includes: static HTML files, images, text, video, and audio.
  • 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.
  • 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.

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 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
  • Revised draft 2.03 SES 10/7/2010
  • Revised Final 2.1 SES 09/27/2011
  • Revised Final 2.2 CRS 07/01/2012

IX. References