Secure Computing

Due Diligence for Externally Hosted Systems and Applications

This section applies to systems / applications which are hosted externally (cloud, SaaS, PaaS, ASP or other hosting model).  Yale expects the vendor or other hosting organization to have its own internal policies that are designed to ensure that customer (Yale) data is not disclosed. As part of the Security Design Review process, Information Security, Policy and Compliance examines these policies and security practices. Below are examples of some of the general provisions that should be included in the vendor's onsite policies. These provisions may be attached as contractual provisions as well.

 

Statement on Standards for Attestation Engagements (SSAE) No. 16 (http://ssae16.com/SSAE16_overview.html), Reporting on Controls at a Service Organization Type II Report (SSAE-16 SOC 2, see http://ssae16.com/SSAE16_reports.html), or Statement on Auditing Standards No. 70 - SAS 70 type I & II reports (http://en.wikipedia.org/wiki/SAS_70; http://www.sas70.com/about.htm) may be substituted for some of the documentation below.

 

  1. Physical Security procedures for the Company data site (servers not accessible, data backed up and stored offsite, hard drives securely erased and disposed, paper records destroyed).
  2. Security Process controls (privileged access logged, production/test are separated, logs reviewed, patches applied, policies in place for intrusion and response, automatic lockouts on desktops, virus/worm software, regular vulnerability assessments, backup procedures tested, tested disaster recovery plan in place).
  3. Employee Security procedures (accounts removed at termination, employees trained and vetted, improper access logged and disciplined, very few employees with access to complete recordbase, strict exit procedures to prevent identity theft).
  4. Network Security controls (firewalls employed where appropriate, logs archived, designated staff to monitor security alerts and take action, intrusion detection mechanisms, "inside" hosts secured and not visible to public internet, company protected from wireless "snarfing" by onsite visitors or adjacent hackers).
  5. All session logs are maintained for an appropriate length of time to check for any hacking attempts that might come to Yale’s attention later.
  6. The organization must have processes and procedures to prevent and notify for any hacking attempts and that there is an escalation process.  Determine if the notification to Yale is acceptable.  Who is responsible for the researching of the logs to trace an attempt or event?  Will the vendor or organization only investigate if legal action is taken?

Confidential Information

  1. Even if there are contractual definitions developed by the vendor, use Yale University defined data classification (see Appendix A: University Draft Data Classification) to determine if there is data which the University is obligated to protect and treat as sensitive or restricted.  Data classification must be identified in all contexts (i.e., research, educational, business or clinical care). 
  2. Any vendor doing business with Yale is subject to notification and requirements of State of Connecticut law mandating compulsory notification in the event of data disclosure, regardless of their location.

Outsourced Web Applications

  1. If authentication is provided at Yale, session cookies cannot be transferred out to a non-Yale server without a notice to the client (end-user), and such transfer may not be permitted.
  2. If the vendor hosts a portion of an application where user data is collected, a Privacy Notice will be made available to the user at every visit, and text for the Privacy Notice will be provided and/or approved by Yale.
  3. The vendor privacy policy should clearly state (for the end-user) how the user’s data is going to be collected and used, and whether the vendor intends to sell this data for marketing purposes.

Disaster Recovery

  1. Is there any contractual definitions developed by the vendor, for the SLA on recovery in the event of a disaster?  Is the recovery time period acceptable for the criticality of the system? 
  2. Has the DR plan been tested?  Was Yale involved in the testing to validate the results? 

Third Parties

  1. Yale customer records will not be sold or provided to a third party or affiliate without Yale's explicit consent.
  2. The vendor cannot delegate processing to a third party without notifying Yale.
  3. The vendor cannot subcontract to other vendors without notifying Yale.

Security Events, Disclosure

Any disclosure of Yale's data to intrusion or internal malfeasance must be promptly reported to Yale's Legal Counsel.

Vendor Documentation

The vendor should address the topics below in their documentation.  Review the vendor documentation and note any omissions or areas where safeguards are weaker than you expect. 

Access control

  • Account management
  • Remote access

Security training and awareness

Audit & accountability

  • Auditable events – content of audit records
  • Audit monitoring and reporting
  • Time stamps
  • Audit record retention

Configuration Management & Change Control

Contingency Planning (including backup EMO and DRP)

User Identification and authentication

  • Identifier management
  • Authenticator management

Incident response handling, monitoring & reporting

System maintenance procedures

Media protection (access, labeling, storage, transportation, sanitation and disposal)

Physical and Environmental protection

  • Physical Access Authorizations
  • Physical Access Control

Personnel Security policies/procedures

Risk Assessment & Vulnerability Scanning

System and Services Acquisition

System and Communications Protection

System and Information Integrity