Yale NetID password must be changed at least once per calendar year to a different password. Each year's password must be unique -- don't recycle previous year's passwords. Read the strong password guide.
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.
- 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).
- 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).
- 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).
- 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).
- 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.
- 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?
- 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).
- 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
- 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.
- 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.
- 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?
- Has the DR plan been tested? Was Yale involved in the testing to validate the results?
- Yale customer records will not be sold or provided to a third party or affiliate without Yale's explicit consent.
- The vendor cannot delegate processing to a third party without notifying Yale.
- 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.
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.
- 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