May 2015 Encryption Deadline

The School of Medicine's top priority remains ensuring that all devices used by individuals with access to High Risk (previously Restricted or Prohibited) data be encrypted with Stanford Whole Disk Encryption (SWDE) and managed with BigFix.  Our next step had a deadline of May 31, 2015: encrypt ALL Stanford-owned and personally-owned laptops and desktops used for Stanford work. Because of our previous encryption efforts, in the School of Medicine, this primarily impacts devices used by individuals without access to or use of High Risk data.

Whole disk encryption protects the data stored on your laptop and desktop computers in the event the device is lost or stolen.  The University has established the goal of verifiably encrypting all computers used to access Stanford data on the Stanford network.  Devices used by individuals who have attested "No" to accessing High Risk (previously Restricted or Prohibited) data were not previously required to be encrypted. 

You can review the University management's most recent communication regarding data security requirements here.

School of Medicine data security policy applies to all faculty, staff, postdocs, graduate and medical school students, residents, and fellows.  Many individuals in clinician populations such as clinical educators and adjunct clinical faculty are also being included in our population, based on the extent of their potential involvement with Stanford ePHI.

After the May 2015 deadline, the University will implement technical controls to restrict all unencrypted devices from connecting to the regular Stanford network.  Below are the areas of concern for the security deadlines, with more information about current and in-progress solutions.

 

1)  BigFix or University Device Enrollment

As many devices as possible should be enrolled in BigFix.  In addition to managing and reporting a user's compliance status, BigFix also provides the capability to automate patch management and OS updates for critical releases.

All devices that cannot be in BigFix should run the University Device Enrollment app.  This is a one-time, two-minute process to collect specific information regarding computer ownership and access to Restricted/Prohibited data.  This information is required to reach the May deadline and is the same information we collected through BigFix "Fixlet 1".  Individual users can complete the Device Enrollment app by going to https://itservices.stanford.edu/service/enrollment and selecting either Windows or Mac.

 

2) CrashPlan and Backups

Please be sure to back up your device before proceeding with encryption.  While CrashPlan is not required, some form of backup is strongly recommended.  The risk of hard drive failure or malfunction during the encryption process is small, but problems have occurred in the past.  

The School of Medicine's instance of CrashPlan is available to all SoM faculty, staff and students at no cost.  It backs up automatically to a remote, secure server managed by IRT Data Center Services.  Another advantage of using SoM CrashPlan (as opposed to non-CrashPlan options) is that your backup status can be reported to BigFix.  We have implemented reporting methods to help identify problems (for backups that aren't working) and to clean up old copies of backups (in the case where computers are replaced).  We are also reporting on backups that can be eliminated, and give you the opportunity to create an archive copy in encrypted storage before it is purged from the CrashPlan server.  The Data Security Program provides instructions for installing CrashPlan.  Inactive archives will be flagged at 90 days and eliminated at 120 days.

To address personal privacy concerns, we have implemented an optional feature to add a personal password on a CrashPlan backup.  While Stanford IT access to an individual's CrashPlan backup is severely limited (and controlled and logged), there may be clients who still want to create a second password for additional privacy.  The main risk of a second password is that if the client forgets or loses their password, there is no option for IT to assist them with recovery.

If you utilize a backup method other than CrashPlan, it is critical that any Stanford data is backed up to encrypted storage.  If you choose not to encrypt your personal data backup, that is up to you.

 

3) Encryption

According to the official requirements, users who attest "Yes" to accessing High Risk (previously Restricted or Prohibited) data are required to be SWDE-encrypted (which includes BigFix).  Users attesting "No" to accessing High Risk (Restricted or Prohibited) data are not required to use SWDE/BigFix but must still be "verifiably encrypted" (see the VLRE option below).  

SWDE

As per the original data security mandates, users attesting "Yes" to High Risk (Restricted or Prohibited) data must be SWDE-encrypted.  The Data Security Program page has SWDE encryption instructions for Mac and Windows.

Users attesting "No" to High Risk (Restricted or Prohibited) data are not required to use SWDE, although it is recommended.  While not required to use BigFix, these users will eventually need to report on encryption status, either via BigFix or by a second utility currently being developed.

Although SWDE automatically initiates encryption, the user must still acknowledge they understand the need to be backed up before proceeding. 

VLRE

For users who attest "No" to accessing High Risk (Restricted or Prohibited) data, VLRE is the code name for a tool that will assist in encryption and report on a device's encryption status, without enabling other features in BigFix such as patch management, system updates, etc.  We still recommend SWDE, but VLRE is also available for qualified users. The downside to this tool is that it is limited: it does not allow for automatic updates, remote management or regular AMIE (or compliance database) updates.

Installing VLRE requires either Mac OS X 10.9 or later; Windows 7 Enterprise or Ultimate or Windows 8/8.1  Pro or Enterprise (TPM chip required for Windows 8.0 and below). For more information and installation instructions, visit: http://vlre.stanford.edu.

 

4) AMIE updates

We will update AMIE reporting so that users who attest "No" to High Risk (Restricted or Prohibited) data can check on their own encryption status; currently, AMIE just reports "Not Required".  We may also introduce an option for users to self-attest to their encryption status.

 

5) Targeted approach to computers

We are working to make the encryption process as automated and built-in as possible:

a) Macs in BigFix that have an operating system version of 10.8 and above can have the encryption process pushed out automatically via BigFix.  Encryption in operating system version 10.7 must be manually implemented.

b) PCs that use BigFix will be able to have encryption automatically completed after a new release (available soon).  

c) Machines that are not in BigFix will need to have the encryption process started manually.

 

6) Communications

a) Stanford will be keeping track of departments' devices, reporting those that are unlikely to be able to meet the data security standards.

(1) System requirements for SWDE encryption:

    - Macs:  OS X 10.8 (10.7) or above

    - PCs: Windows 7 + TPM -or- Windows 8 (Enterprise or Ultimate)

    - Device must have been purchased after January 2010

(2) Your department may want to make plans to replace devices that do not meet these requirements, and therefore cannot meet the data security requirements

b) We will provide links for recommended Dell and Apple new purchases.

c) We will contact your department to determine the department's overall status and identify assistance that may be required.

d) We will be sending out updates on a periodic basis.

 

7) Exceptions

Devices that cannot meet security requirements but which are used for special scientific purposes (equipment or applications) must apply for a data security exception.  We will implement compensating controls to reduce the risk to and from these devices on the network and will work with your groups directly to provide enhanced security for these devices while ensuring ongoing work can be continued.