CSE Laptop Pre-Encryption Guide
The Ohio State University Policy on Institutional Data requires all OSU owned devices containing restricted data to be encrypted. Restricted data includes any of the following items:
· Social Security Numbers and other personally identifiable information such as driver’s license, state identification card, etc.
· Bank account information
· Credit card information
· Student record information that is linked to an individual student by name such as grads/transcripts, class enrollment information, student financial aid, grants and loans, etc.
· Patient health information
The list of restricted data is subject to modification over time. More information can be found in the Restricted Data FAQ.
Desktop encryption in the CSE department has been handled through the Microsoft Windows Vista desktop deployments for faculty and staff. Graduate student desktops outside of research have been encrypted with TrueCrypt until they can be replaced with Vista installations. In general, research systems have not demonstrated a need for encryption, but any that do will also be encrypted through our continued work in Minimum Computer Security Standard (MCSS) compliance.
The College of Engineering has adopted the following policy on laptop encryption:
· If the device has restricted data, it must be encrypted.
· If the device and user can meet the following requirements, the device does not need to be encrypted:
o The device does not contain restricted data.
o The device will not contain restricted data in the future.
§ If it does need to store restricted data in the future, we will change its status and make sure the device is encrypted to meet the restricted data handling requirements.
o The user responsible for the device is willing to sign a document to this effect and ensure that (a) and (b) are met now and in the future.
§ This document is not ready yet. For now, email responses to me will suffice.
This document outlines the steps that must be performed before a laptop can be encrypted by the CSE computing staff. These required steps are detailed in subsequent sections. The “CSE Laptop Encryption Guide” is the second document detailing how to use the encryption software and its operation.
The CSE computing staff has evaluated various encryption solutions for different operating system platforms. The plan is to deploy the following solutions on each platform:
· Microsoft Windows Vista
o BitLocker
§ BitLocker is part of certain Vista operating system versions. Laptops purchased that are capable of running Vista can be installed with a version of Vista that contains BitLocker technology.
· Microsoft Windows (non-Vista)
o SafeBoot
· Linux
o TrueCrypt
§ Some distributions also include a dm-crypt solution that works in essentially the same way and also meets the encryption requirement.
· Mac OS X
o FileVault
Before the CSE computing staff can encrypt a laptop device it must be MCSS compliant. This allows use of the csecs administrative account to perform the encryption process. Due to the nature of laptop devices, it might be impossible to follow all of the steps required for Microsoft Windows MCSS compliance while not connected to the research subnet. In the Windows case, the laptop must get to the point where it is joined to the research Active Directory as outlined in the Windows instructions (the Initial Setup section). In addition, please run all updates to get all of the latest Windows patches installed before dropping the laptop off. Linux systems should be able to perform all MCSS compliance steps. Mac OS X laptops will be dealt with individually. The MCSS compliance instructions are located in the following locations:
Dual boot systems will require both partitions to be MCSS compliant. Both operating systems will require encryption.
The MCSS requires all OSU owned devices to have access controls with robust passwords. As part of MCSS compliance, all laptop devices must use a username and password that meets the robustness requirement. MCSS compliance itself will take care of this, but in the non-Vista Microsoft Windows case using SafeBoot, we also plan on using the Single Sign On (SSO) feature. This allows a single login at the boot stage to automatically log the user into their Windows session. Most systems meet this definition and will be encrypted with SafeBoot. SafeBoot requires the creation of a SafeBoot account that is tied to the local account used on the laptop itself, thus both the laptop user account and the SafeBoot user account must meet the same minimum password robustness requirements, specifically that the password contains 3 out of 4 of the following types of data:
· Lower case letters
· Upper case letters
· Numbers
· Symbols (special characters)
The other solutions require a password that is separate from the laptop local accounts, except for Vista’s BitLocker using a TPM, though for simplicity it is advisable to use the same password for the encryption and primary user account in those cases when possible. SafeBoot does not require SSO, and using SSO does not limit use of the laptop to one account, but using SSO it is much more convenient for the main login account. All encryption solutions require some type of initial authentication before the device can be booted however, otherwise there is no protection.
In the case of multiple laptop devices tied to the same SafeBoot account, either the same local account needs to be used on all laptop devices or the SSO feature needs to be disabled for that SafeBoot account. Any specific cases where this applies can be discussed prior to encryption.
After the laptop is configured to meet the minimum requirements for encryption, a time should be scheduled to drop the device off with the CSE computing staff. Encryption should take approximately one business day. Before the encryption process begins the device will be fully backed up to an external USB disk. This data will be retained until it is determined that the encryption process was successful and the data can be accessed after the process is complete. When the laptop is dropped off for encryption, any non-Windows operating system installations will require the creation of the csecs administrative account. Additionally, the CSE computing staff will need to know certain details about the device before the encryption procedure:
· What operating system is installed on the device?
· Is the device dual boot?
o If the device is dual boot, what other operating systems are installed.
· Are there any particular hardware or software issues to be concerned about?
o If the device is known to crash periodically, this is a potential issue with respect to the initial encryption procedure.
We will require the laptop power supply in addition to the laptop itself. This is necessary because the encryption process will take a long time.
When the laptop is picked up after the encryption procedure, a couple of additional steps will be done with each user individually to ensure the password is working as expected and synchronized with the SSO account in the case of SafeBoot installations.
Please note the device must meet the MCSS requirements as previously outlined or we will be unable to perform the encryption process. This will require scheduling encryption a second time because we do not have administrative access on the device until it is MCSS compliant in most cases. For non-Windows cases, we will create the csecs administrative account when the machine is dropped off.
In an effort to improve the security of our CSE department Domain Name Servers (DNS), CSE computing staff will disable recursive DNS queries from outside of the CSE network at some point in the near future. Most operating system resolver libraries only support recursive DNS queries. This means it will not be possible to configure a computer off of the CSE network to use the CSE DNS servers. Hosts on the CSE network will not be affected. This change will announced beforehand once a plan is implemented, but since laptop encryption is the perfect time to fix the DNS resolver library settings on laptops which will likely be off the CSE network at various times, the CSE computing staff will change any systems configured to use CSE DNS servers to instead use the freely available OpenDNS DNS servers. This only applies to systems which have been configured to use CSE DNS servers explicitly.