Locked History Actions

HostingStandards

HelpdeskDocsTemplate/logo.png HelpdeskDocsTemplate/UTS.png

Outsourcing, Hosting, Software as a Service, and Application Service Provider Security Standards


Topic: Outsourcing, Hosting, Software as a Service Security Standards
Audience: Faculty and Staff
Creation Date: June 29, 2009
Last Revision Date: June 7, 2013
Author: Theresa Rowe

1.0 Overview

This document should be completed by a vendor or service provider, hereafter called "Company", if the University intends to purchase or contract for an outsourced, hosted, software as a service, or application service provider application, web site, or similar services. An editable document is available from the Purchasing Department or by sending a request to uts@oakland.edu .

The document defines the minimum security and operational criteria that Company, Inc. (“Company”) must meet in order to be a Service Provider (“SP”) or to otherwise provide hosting services for Oakland University (“University”). Company must respond in writing to EVERY statement and question in all categories and comply with those for which particular standard or security protocols are identified. Such compliance shall continue for the duration of the Agreement (“Agreement”) to which this document is attached as an Exhibit. University Technology Services department (“UTS”) will closely review Company’s responses, and will suggest remediation measures in any areas falling short of minimum security criteria. University Technology Services will accept vendor security documentation created by the Company as long as it addresses the material and protocols described in this document.

2.0 Scope

This document can be provided to Service Providers that are either being considered for use by University, or have already been selected for use. These vendors have been selected because:

  • University data will be transmitted to the vendor for storage or processing; or

  • Data collected, transmitted, processed or stored by the vendor meets the university standard definition as “confidential data” or "operation critical" as described by university policy #860 Information Security; or

  • Credit card or payment card processing will be used by the vendor as a revenue collection agent for the university.

3.0 Responding to These Standards

COMPANY must complete and submit section 4.0. UTS is looking for explicitly detailed, technical responses to the statements and questions appearing in the Standards section of this document. Company should complete and submit its responses directly beneath the Standards (both questions and requirements) listed below. Please replace the word “COMPANY” with the vendor name.

Most sections require a descriptive answer; in some cases, a statement of compliance may suffice. In addition, please include any security whitepapers, technical documents, or policies that may be in place.

Answers such as “Will furnish on request” are not acceptable; this document is the request for additional information.

  • Answers to each Guideline should be specific and avoid generalities, e.g.:

Examples:

  • Bad: "We have hardened our hosts against attack."
    Good: "We have applied all security patches for Windows Server as of 8/31/2012 to our servers. Our Administrator is tasked with keeping up-to-date on current vulnerabilities that may affect our environment, and our policy is to apply new patches during our maintenance period (2300 hrs, Saturday) every week. Critical updates are implemented within 24 hours. A complete list of applied patches is available to Oakland University."

    Bad: "We use encryption."
    Good: "All communications between our site and Oakland University will be protected by IPSec ESP Tunnel mode using 168-bit TripleDES encryption, SHA-1 authentication. We exchange authentication material via either out-of-band shared secret, or PKI certificates."

    Bad: "We use Java."
    Good: "We use Oracle JDK 1.7.0_21 and utilize Spring Framework 3.2.3."

4.0 Standards

Please complete all sections - 4.1, 4.2, 4.3, 4.4, 4.5, 4.6, 4.7, 4.8 and 4.9.

4.1 General Security

  1. Please describe support for the following statements: The University reserves the right to periodically audit, or to request an audit, of the University application infrastructure to ensure compliance with its policies and these Standards. Company commits to engage in an annual security audit, sharing the results of the audit with the University upon request. The University will request that vulnerabilities identified in the audit be fixed or mitigated within 90 days of the audit report. The Company may submit either of the following as an alternative:
    1. Compliance with Payment Card Industry Data Security Standards https://www.pcisecuritystandards.org/ Required for vendor solutions that involve payment card processing.

    2. Certification of the product by Common Criteria http://www.commoncriteriaportal.org/

    3. Certification of privacy for web applications from TrustE http://www.truste.org/about/index.php

  2. Company must provide a proposed architecture document that includes a full network diagram of the University Application Environment, illustrating the relationship between the Environment and any other relevant networks, with a full data flowchart that details where University data reside, the applications that manipulate data, and the security thereof. Please attach flowchart.
  3. Company must be able to immediately disable all or part of the functionality of the application should a security issue be identified. Describe how this is handled.
  4. Company agrees to comply with all state and federal privacy and security legislation within 60 days of enactment. Describe how this is handled.
  5. Company must present evidence of network security, cyber liability and errors and omissions insurance. Insurance limits for a project are determined in consultation with the Office of Risk Management. Typical limits are not less than $1 million per occurrence and $1 million in aggregate, and usually are more. Please attach documentation.
  6. Company agrees to comply with all necessary requirements needed to maintain compliance with any standards relevant to the University application environment. Please describe.

4.2 Physical Security

  1. The equipment hosting the application for University must be located in a physically secure and access controlled facility off University property, described by address and location approved in advance of use. Please describe.
  2. The infrastructure (hosts, network equipment, etc.) hosting the University’s application must be located in a locked cage-type environment, locked rack or other secure facility. Please describe the security of the equipment within the room.
  3. The University shall have final say on who is authorized to enter the locked physical environment, as well as access the University Application Infrastructure. Please describe accessibility and process to gain access.
  4. The physical environment must be covered by 24-hour surveillance video of evidentiary quality. Please describe.
  5. Physical access logs must be maintained and must include who entered the room, time of entry and time of exit. Please describe.
  6. Company must disclose the job titles (not personal identities) among their personnel who will have access to the environment hosting the application for the University.

  7. The University requires that Company disclose their personnel criminal background check procedures and results prior to UTS granting approval for use. Employees with access to the designated must meet current University employment standards for security and background checks. Please describe compliance.

  8. Physical access to facilities where data are stored will be limited and controlled. Any damage or unauthorized access to facilities will be reported to the University within 24 hours of occurrence. Please describe notification process.

4.3 Network Security

  1. Network hosting of the application should be segregated from any other network or customer that Company may have, unless prior approval is given by the University. Please describe this infrastructure and architecture accordingly.

4.4 Host Security

  1. Company must disclose how and to what extent the hosts (Unix, Windows, etc.) comprising the University application infrastructure have been hardened against attack. If Company has hardening documentation for the infrastructure, provide that as well.
  2. Company must provide a listing of all software in use, including operating system, web server, database management system, and the current release number for each software component. Also include current patches on hosts, including host OS patches, web servers, databases, and any other material application.
  3. Information on how and when security patches will be applied must be provided. How does Company keep up on security vulnerabilities, and what is the policy for applying security patches?
  4. Company must disclose their processes for monitoring the integrity and availability of those hosts.
  5. Company must provide information on their password policy for the University application infrastructure, including minimum password length, password generation guidelines, and how often passwords are changed.
  6. Company must provide information on system default and system administration passwords, including installation and set-up procedures with default installation passwords and the system administration password policy.
  7. The University will not provide a customized data feed of usernames/passwords for account generation. With that restriction, how will Company authenticate users? (e.g., LDAP, CAS, Netegrity, Client certificates.) For example, CAS can be used by the Company to obtain the username after the user authenticates successfully and the company is authorized by the University to connect to the University CAS server. CAS is the University's preferred method of authentication.
  8. Company must provide information on the account generation, maintenance and termination process, for both systems maintenance as well as user accounts. Include information as to how an account is created, how account information is transmitted back to the user, and how accounts are terminated when no longer needed.

4.5 Web Security

  1. Please disclose whether, and where, the application uses Java, Javascript, PHP, .Net, Python, Ruby, C, C++, or C#, and include the version used.
  2. What language is used for the application back-end?
  3. Please describe Company’s process for doing security Quality Assurance testing for the application. For example, describe testing of authentication, authorization, and accounting functions, as well as any other activity designed to validate the security architecture.
  4. Please describe the application development security standards employed for development, such as adherence to the Open Web Application Security Project (www.owasp.org). Describe development standards related to security, including any external body of standards enforced in development.
  5. Has Company done web code review for the explicit purposes of finding and remediating security vulnerabilities? If so, who did the review, what were the results, and what remediation activity has taken place? If not, when is such an activity planned?
  6. Please confirm that web sites are implemented utilizing Secure Socket Layer (SSL) with a certificate from an independent authority.

4.6 Cryptography

  1. The University application infrastructure cannot utilize any "homegrown" cryptography – any symmetric, asymmetric or hashing algorithm utilized by the University application infrastructure must utilize algorithms that have been published and evaluated by the general cryptographic community. Please describe utilized cryptography, including any implementation of SSL.
  2. Please specify where and how cryptography is used in the application environment. Please describe methods for data encrypted in transit and at rest, detailing such items as traffic flows using SSL termination and the use of full disk or file level encryption.

4.7 System Performance, Disaster Recovery and Business Continuity

  1. What are the disaster recovery and business continuity plans?
    1. Consider: Daily backups of systems, files and data will be done on a cyclical basis, so that any restore of the system will not result in more than 24 hours of data loss.
    2. Vendor guarantees that a disaster recovery plan exists, including off-site storage of data in a secure location. The University must approve the off-site storage of the data, and the University retains the right to reject the location for security reasons and to recommend another location.
    3. System up time is guaranteed to 99.9% (Consider: 365 days a year, 24 hours a day = 8,760 hours x 99.9% up time = 8,751.24 hours. That means that there would be roughly 1 full day of system unavailability every year.) Fully describe the system availability service agreement.
  2. Describe an acceptable performance standard (response time) for standard application queries and standard application updates.
  3. Describe contact procedures for standard problem reports, critical problem reports, and the problem escalation procedure.
  4. Describe the contact return call window (i.e., reports of critical problems will be responded to within 4 hours).
  5. Describe vendor hours of operations, helpdesk hours of operation, and time zone.

4.8 Data Controls

  1. Who will have access to the data?
    1. Data access will be limited to those with a "need to know" and controlled by specific individual. Vendor will have procedures and solutions implemented to prevent unauthorized access, and the procedures will be documented and submitted for University review.
    2. Those allowed to send data and receive data to and from the vendor must be identified by job title, as defined within this process.
  2. How will data be transferred between University and the Company? The university may require that files are encrypted both at rest and during transmission, depending on the type of data involved. Please describe the following in detail:
    1. The specific data elements that will be transmitted from the University to the Company.
    2. The specific data elements that will be transmitted from the Company to the University.
    3. The encryption standard that will be used to encrypt transmitted data.
    4. The transmission protocol proposed for data exchange.
  3. The procedure for notification in the event of accidental data exposure must be identified. Accidental exposures of data to unauthorized persons will result in the vendor notifying OU within 4 hours of discovery, and no notification to those whose data have been exposed will occur without prior discussion with the University.
  4. Standard non-disclosure language must be included, with protection to keep information and data private and confidential, and to treat information and data confidentially except as specifically provided for in the contract. Data cannot be shared or sold with or to third parties.
  5. Standards for data quality are established by the University and enforced by the Company. The Company must meet the University standards for the quality and integrity of the data. The University retains the right to approve the quality of data displayed on web sites (or the data will be removed). Processes that gather, edit, modify, calculate or otherwise manipulate data must meet University standards for data quality. The university must approve the sources of data and the data maintenance method. Please describe compliance.
  6. If confidential data are involved in this process, as defined by University policy #860 Information Security, review and compliance specific to those data are required. Describe any confidential data involved in this agreement.

  7. The university standard form for Mutual Non-Disclosure of information must be signed.
  8. PCI Only: Please describe your ability to limit Oakland University's access to a subset of data. In particular, Oakland University should not be granted full access to credit card or cardholder data, including plain text or obfuscated credit card and ccv numbers. Please describe how you would facilitate granular access that would prevent data exposure.

4.9 Contract Termination

  1. Data will be retained only for the period of this agreement and only for a retention period approved by the University, and will be returned to the University or destroyed using a standard approved by the University upon termination of this agreement.
  2. The University retains the right to terminate the contract with 7 days notice for any reason related to the security items listed in the contract.
  3. The University aggressively protects copyrighted material, and all University logos, emblems, images, and gif files must be used only with University approval, and must be destroyed at the end of the agreement.


For further help, please email <<MailTo(uts@oakland.edu)>>.