PM845: Encryption of Confidential University of Connecticut Data Pilot

To view this page ensure that Adobe Flash Player version 9.0.124 or greater is installed.

Please login or register to make a comment!

...Description...... more. less.

pilot project 9s findings included: " The use of Full Disk Encryption on University computers did not pose a significant problem for participants nor did it negatively impact the usability of the participants 9 computers. " There were several (technical and procedural) issues uncovered during the pilot project. While most of the technical issues have been addressed, certain computer configurations may require special attention or troubleshooting in order to function with the Full Disk Encryption. " User password management with Full Disk Encryption can be problematic. Users who typically manage NetID passwords via the NetID web page ( http://netid.uconn.edu ) may find password management confusing. These issues may need to be addressed with additional support staff. " Users of Macintosh and Linux computers do not have many options for Full Disk Encryption. o For Macintosh users, no mature Full Disk Encryption Products exist for an enterprise environment; however, more options are expected in coming months. For Macintosh users, other means to protect data must be utilized until a practical Full Disk Encryption option is available. o For Linux users, there is no single Full Disk Encryption software which will service all types of Linux installations, and it does not appear that there will be one in the immediate future. For Linux users, long-term solutions for protecting data are needed. There are several recommendations made throughout this document in order to facilitate the planning for deployment of Full Disk Encryption software. These recommendations include: 1. Encrypt all desktop and notebook computers used to store or access University data. Other devices will be addressed outside of the scope of this initiative. 2. Develop and publish a policy related to protection of University data. 3. Develop a process for exemptions to the data encryption policy for computers which do not store or access University data (such as Lab computers) 4. Purchase all necessary SafeBoot licenses before the end of October 2008 to ensure that all Windows and Macintosh computers are supported (planning on SafeBoot encryption for Macintosh). 5. Develop a process to permit encryption of personally-owned devices 6. Develop a 14-month project plan to begin in November of 2008 and hire the resources required to deploy the encryption solution. 7. Develop a plan for ongoing support beyond the implementation plan 8. Address password issues associated with disparate systems storing passwords, and ensure that passwords are required to be complex. Page 1 Overview Many computers at the University of Connecticut contain sensitive or confidential data, the storing of which involves risk that sensitive information will be compromised as the result of unauthorized access, theft, or loss of a computer. Each year in the United States hundreds of incidents occur at higher education institutions which involve the loss or theft of computers used to access or store sensitive data. The University of Connecticut has had its own incidents involving lost and stolen equipment and the risk is high that additional equipment may be lost or stolen. The bottom line cost of such incidents must be taken into consideration, as well as the damage to the University 9s reputation. It is estimated that the cost of data lost to an institution like UConn is $197.00 per exposed record 1 . The cost to the University 9s reputation is difficult to measure, but certainly costly. The University must protect its data; data encryption provides this protection. The goal of the University Encryption of Confidential University of Connecticut Data Pilot Project (hereon referred to as the Data Encryption Pilot Project) was to select a group of individuals from various departments performing various functions to use Full Disk Encryption (FDE) products for Windows and Macintosh on laptops and desktops for the purposes of assessing the issues associated with using the products in the larger environment at UConn. The Data Encryption Pilot Project was chartered to meet the following goals: " University policy will be drafted to outline encryption requirements " The server solution will be assessed to determine if it can scale to support the entire University " Determine the number of central IT support staff for the initial deployment and ongoing support " Criteria, process, documentation, and support will be created " eDiscovery Standard Operating Procedures will be updated and implemented into production " A budget recommendation will be made for future purchases and maintenance of software In addition to these expected goals, additional outcomes of the pilot project included: " Determine possible deployment methods for the software " Determine the performance impact due to using encryption on University computers " Determine the time needed to install and configure the software in order to derive staffing estimates 1 Sources: 2007 Forrester Research: Study of 28 organizations with data breaches; 2007 Cost of a Data Breach, Vontu: Study of 31 organizations with data breaches Page 2 Project Findings The products chosen to be piloted throughout this pilot project were SafeBoot for Windows computers and PointSec for Macintosh computers. Over 30 departments were represented in the pilot; 78 Windows devices were encrypted; 2 Macintosh computers were encrypted. Overall, there were few technical issues with SafeBoot that were encountered during the pilot in over 2 month 9s time. Several issues were discovered, and most were resolved successfully. Appendix A details the issues encountered during the pilot. The FDE solutions protected the University 9s data without significant technical issues and validated the project 9s assumption that using FDE software is a viable option for the University. Overall, the time to install the FDE product on a user 9s computer is approximately 30 minutes per computer. Once complete, the operator of the computer must log into the computer before being presented with the Operating system (Windows) login; if this is not done, the computer is unable to boot. Depending on the user 9s environment this may mean that the user must log into the computer twice in order to begin using it 2 . Once the software is installed on a user 9s computer, the computer 9s functionality is not reduced in any way. Generally, after logging in, the computer behaves as it did prior to being encrypted and the FDE software is transparent to the computer 9s use. One impact of using FDE software is that users must be granted access to computers prior to using them. If a new user of a shared computer would like to log on to the computer, that user must be granted access to the computer by an encryption administrator. In production, this will require planning from computer users in requesting access to shared computers 3 . The pilot project also demonstrated that distributed administration is possible using a single FDE server environment (as opposed to several distributed FDE servers). During the pilot departments were given access to their area 9s computers and users in the FDE environment, providing IT administrators the ability to manage their own encryption environment for the departments, schools, and colleges which have dedicated IT resources. A central server configuration, with proper hardware specifications, could be used to handle all University departments. The pilot exhibited two areas of support which will require proper planning and procedures. The first situation is forgotten passwords. Generally, this should be handled within current processes and procedures in place in support centers today (both distributed and central). However, today some individuals may use no password at all to enter their computer. Installing FDE in this situation would require the user to remember a password that he or she is not currently required to remember, causing the potential for additional support that does not exist today. 2 SafeBoot has the ability to synchronize usernames and passwords automatically, allowing for single sign on to the computer. However, in order for this to function properly, the SafeBoot and computer usernames must be identical. If this is not the case, users will need to log on once to SafeBoot, then again to the Operating System. 3 This process does not replace or supersede the process for reassigning equipment, in which case a computer must be data-wiped before being reassigned. Page 3 The second situation that requires additional planning involves computers which require service in the field. With FDE installed these computers will require additional procedures and tools in order to recover data, if necessary, and provide the necessary service (See Appendix B for data recovery procedures). The University has a homogeneous computing environment, making a single approach to FDE software difficult. In most cases, the use of the software will provide the University with added security with no sacrifice to functionality or productivity. In situations where users log onto their computer with an ID which does not match their FDE username, users will be required to log onto a computer twice and remember and manage an additional password. The cause of these issues is the lack of a single University identity for all faculty and staff. However, these issues should be minimized by the use of the central UITS Active Directory and distributed Active Directory integration with the FDE solution. Data loss as a result of encrypting data with FDE is a concern of IT technicians and users of FDE software, and as such it is important to ensure that data is adequately backed up before being encrypted. During the pilot project, no data was lost as a result of encryption. However, despite the controls and recovery options put into place by the FDE software, pilot users were instructed to make secure backups of their data, which is good practice for all users of University computers. Users should be encouraged to routinely make secure backups of their data to ensure that data is not lost as a result of damaged hard drives, corrupt file systems, or computer loss or theft. In some cases, departmental backup services may be available. Computers should be configured to take advantage of these services to ensure a secure backup of data exists. Page 4 Project Recommendations Encryption Recommendation: Products Recommendation: Use SafeBoot Device Encryption for Full Disk Encryption of Windows Computers For Windows computers, it is recommended that SafeBoot be deployed. SafeBoot has been tested at the University of Connecticut on approximately 80 devices with minimal problems encountered. Furthermore, the University has established a relationship with the State of Connecticut Department of Information Technology (DoIT) and because of this the University can benefit from the experience and knowledge gained at the state where over 5,500 executive agency devices have been encrypted using SafeBoot. Additionally, the University of Connecticut Health Center is implementing SafeBoot on 5,000 computers in their own environment. The University and the Health Center may benefit from shared experiences and knowledge in implementing SafeBoot as well as a partnership with DoIT which allows for greater leverage in vendor negotiations and technical solutions. Recommendation: Purchase all necessary SafeBoot licenses before the end of October 2008 The University may purchase SafeBoot and other FDE software from the federal GSA SmartBUY contract (see http://www.gsa.gov/smartbuy for details) at a volume discount. Furthermore, SafeBoot had offered a deeper discount for institutions which purchased at least 1,000 seats of the software before the end of October of 2007. If this was done, the same discount would apply for purchases made up to October of 2008. Because DOIT purchased 5,000 licenses before the end of October 2007 the University was able to purchase its licenses from the same contract and received a deep discount on its current 1,000 licenses. The University may purchase additional licenses at the same discount if the purchase is made before the end of October of 2008. If the University fails to purchase licenses before this time and later decides that licenses are needed, the cost of those licenses will be 7 or 8 times the cost of what it can pay for the licenses today. Ongoing yearly maintenance of those licenses will also be at least 5 times as expensive if the University does not purchase before the end of October 2008. It is recommended that the University purchase licenses for SafeBoot software for all faculty and staff computers (University-owned and personally-owned) before the end of October 2008. SafeBoot licenses are needed for each device the software is installed on; the following estimates are provided: " An estimated 6,000 total licenses are needed for this initiative (total number of faculty and staff, special payroll employees, University affiliates and student employees) " The University currently owns 1,000 device licenses for SafeBoot " The University has received funding for 5,000 additional device licenses through DOIT. Therefore, there will be no additional cost to the University if it were to buy the necessary licenses before the end of October, 2008. Page 5 Recommendation: Wait for SafeBoot for Macintosh Macintosh encryption products (non-FDE products) were tested during the Data Encryption Pilot Project. These products included native encryption products available on every Macintosh system, as well as TrueCrypt, a free product available for Macintosh, Windows, and Linux computers. The free encryption products and native encryption capabilities do not meet the University 9s goals of protecting its data with the lowest impact to users, computers, and data; with low impact to support; and with manageability a component of the solution. Non-FDE Encryption for Macintosh The native encryption products for Macintosh allow users to encrypt data in two ways. First, with FileVault, users can enable encryption on their home drive, which will encrypt documents and personality, or preferences\settings files. However, FileVault does not encrypt anything outside of the users 9 home folder, which may expose data if either the user saves data outside of the home folder, or if a program uses temporary space on other parts of the hard drive to store data. Another potential issue with the native FileVault encryption for Macintosh is that is does allow for a Master password to be set in advance for cases where a user forgets their password. However, the master FileVault password must be set on each computer individually (or via computer image), and if more than one person supports a computer, the password must be shared (there is only one master password per computer). Lastly, if the computer 9s administrator doesn 9t know the master password, and the user of the FileVault-protected account has forgotten the login password, the home folder and its contents are lost 4 . Another native encryption capability in Macintosh operating systems exists with Disk Utility, which creates an encrypted container in which users are able to store information, protecting the data. This method allows only one password to be set, so if a user forgets the password, the data is not recoverable 5 . Additionally, a user must be cognizant of where files are being stored in order to protect them with encryption. If sensitive data is not stored in the encrypted file space, it is unprotected. TrueCrypt works in much the same way as Disk Utility in that it creates an encrypted container in which to store sensitive files. Besides the drawbacks already mentioned with this method of protecting data, another problem that is created with this solution is that for data that needs to be accessed without the computer operator present. This may exist in the case of employee termination, litigation scenarios, as well as computer investigations. Because the data is encrypted with a single password known only to the user, if the user is not present, the data is inaccessible. 4 Source: http://docs.info.apple.com/article.html?path=Mac/10.5/en/8739.html 5 Source: http://support.apple.com/kb/HT1578 Page 6 Because of the challenges that the native encryption tools present to the University, it is recommended that the University use a managed FDE solution for Macintosh computers as well. Managed FDE products allow the University to deal with such issues because several users may be given the right to unlock or decrypt a compute without sharing passwords. FDE Products for Macintosh When DoIT and the University began investigating FDE solutions in the summer of 2007 no product was compatible with Macintosh. As the University began its pilot project in June, still no product existed for Macintosh which provided managed FDE capabilities. In late June of 2008, a managed FDE product for Macintosh was released by CheckPoint Software Technologies. In September of 2008 another Macintosh product was released for Macintosh by PGP Corporation. Besides these two FDE products for Macintosh, no other products exist to provide this functionality. Because PointSec was released in the timeframe of the pilot project, it was tested by the project team. While the CheckPoint software is functional and protects data on Macintosh computers the recommendation is that the University not move forward with implementing the product at UConn due to the problems discovered in testing it. Although the software is available through the GSA SmartBUY contract (and therefore a contract should be easier to establish if the product is selected for use at the University), the problems found with the CheckPoint product were significant and may pose significant problems in implementation. The major shortcomings of the software found in the pilot are: " CheckPoint client communication with the server is blocked from off campus 6 so those working from off campus would not be able to communicate with the server and recovery data could not be saved to the server. If a user forgot their password and had changed it since the last time the software synced with the server, remote recovery would not be possible, potentially resulting in data loss. Macintosh users would be required to connect to the UConn VPN periodically to synchronize or manually transfer the needed files to an administrator via email or file sharing. " Installing the CheckPoint software is difficult and time consuming, and relied on custom scripts written by UConn technicians. Furthermore, once the software is installed it relies on a constant connection to a server, exposing the server share to users for browsing through CheckPoint data and creating files on the server (including potentially malicious files such as viruses). " If a user forgets their computer\FDE password, it is critical that an administrator be able to reset the password to ensure adequate support and user productivity. However, this functionality failed during the pilot using the server\client configuration provided by CheckPoint engineers. 6 The CheckPoint software uses Windows networking to communicate between server and client. Windows networking has been blocked from off campus at UConn for several years due to the security issues this poses for the UConn network and its computers. Page 7 It is expected that CheckPoint 9s software will improve over time making it a better candidate for use at the University. In addition, additional FDE products may become available for Macintosh. However, the issues of using an FDE product for Macintosh other than SafeBoot (assuming that SafeBoot will be used for Windows) are: " Maintaining two servers for different FDE products puts more pressure on technical support systems, budgets, and infrastructure since multiple, disparate FDE environments would need to be managed. " Using different FDE products could pose some serious issues for end users, especially for those who use both a Windows and Macintosh computer. " Supporting users with two different FDE environments in use is difficult since the environments are mutually exclusive. For instance, managing password resets at the Help Desk must be done in different environments, posing additional complexity in resolving issues SafeBoot for Macintosh Because of the shortcomings with native encryption and container-based encryption (such as TrueCrypt), it is recommended that the University wait for a SafeBoot FDE product to be released for Macintosh. Currently, SafeBoot does not have a client for Macintosh computers; however, according to the company, a SafeBoot for Macintosh client is expected in the first quarter of 2009. It is recommended that the software be put through full testing to ensure its compatibility. If it passes the tests it should be deployed to University Macintosh computers. If these tests fail, an alternate solution may be sought. An estimated 1600 Macintosh computers are in use on UConn 9s campus today. If SafeBoot can be deployed to a Macintosh in 30 minutes, and an estimated 30 computers can be deployed in a single day (150 in a given week) then the Macintosh deployment is estimated to last for 11 weeks. In order to ensure that an FDE product for Macintosh is deployed by the end of the projected deployment, a SafeBoot FDE product for Macintosh must be available by December of 2008. If this is not the case, it is recommended that alternative solutions be investigated since it may be necessary to perform an RFP in order to procure a Macintosh FDE product. Because protecting data on Macintosh computers from loss, theft, or unauthorized use is critical, it is recommended that the University require native encryption products on Macintosh in the meantime before SafeBoot releases a product for Macintosh. Although these products do not make a good long- term, enterprise-wide solution for protection of data, in the short-term, the products do provide adequate protection for the University 9s data. As always, if this method is used, users should be required to make secure backups of computer data and the University must ensure that users cannot encrypt data without an administrator 9s assistance in order to ensure that data is accessible in the cases of employee termination, litigation scenarios, and computer investigations. Page 8 Recommendation: Encryption for Linux computers SafeBoot software does not run on computers running Linux-based operating systems, and according to information from the company there are no plans to develop SafeBoot software for the Linux platform. There are some FDE products for Linux, such as CheckPoint Software 9s PointSec product; however, there is no single product that functions on all Linux distributions, many of which are in use at the University. Some University Linux computers may be research computers, and others are desktop computers which contain University data. In the School of Engineering over 300 Linux computers are used by faculty and staff. Because protecting data on Linux computers from loss, theft, or unauthorized use is critical, it is recommended that the University require encryption standards on Linux computers until a suitable FDE product is found. Products such as TrueCrypt and native encryption solutions for Linux computers do not make suitable long-term, enterprise-wide solution for protection of University data. However, in the absence of a complete managed solution, the products offer adequate protection. As with Macintosh users, if these encryption standards are employed, users must be required to make secure backups of computer data and the University must ensure that users cannot encrypt data without another administrator being able to access the data in order to ensure that data is accessible in the cases of employee termination, litigation scenarios, and computer investigations. Encryption Recommendation: Scope Recommendation: Encrypt all computer hard drives Because encryption provides the University with the greatest level of protection for its data, the recommendation is to encrypt all faculty and staff computers. Many University computers regularly store and access confidential data and those computers are at risk of being lost or stolen. The University has, in fact, been involved in several incidents involving both laptop computers and desktop computers which stored and accessed confidential information. These incidents were costly to the University and time consuming for University Executive leadership, illustrating the need for protecting data. The ultimate goal of the University should be for all faculty and staff laptops and desktops to have Full Disk Encryption installed. Furthermore, the SafeBoot licenses that will be purchased by the University will allow for use of the software on personal computers. If University data exists on personal computers it is important to protect the data there as well. However, requiring the encryption of personal computers heavily impacts University technical support (which today does not support personal equipment) and requiring encryption for personal devices is not enforceable. Therefore, the University should make the encryption software available for personal computers for those that need it, with the understanding that there may be risks involved if data is not backed up, due to the fact that University technical support staff may not support these computers. Page 9 Deployment Recommendation Recommendation: Encrypt the highest-risk data and devices first Departments which work with financial data, medical records, student records, employee data, or University proprietary information are handling data considered most sensitive. These areas should be targeted to be the first to be deployed with encryption software. It is recommended that a project team be formed to deploy the encryption software to departments, in which all desktops and laptops in a given department are encrypted before moving on to the next department. Because SafeBoot does not yet have a product for Macintosh, Windows computers should be encrypted first. When the University secures a Macintosh FDE product (either SafeBoot, if the Macintosh product passes University testing, or a different product chosen by the University) Macintosh computers will then need to be considered. The overall deployment strategy in this case would be to identify departments which are at the highest risk due to the type of data that the department works with. These departments should be prioritized by need, sensitivity, and risk. After prioritizing departments, a UITS project team would work with the department to identify all desktop and laptop computers in the department, determine an appropriate schedule and strategy, and work to install encryption before moving on to the next department. When a Macintosh FDE solution is in place the project team would then repeat the process with necessary departments to deploy SafeBoot to University desktop computers. Meeting with each department prior to deployment is critical in understanding the unique needs of each area. Only when these needs are understood can an encryption product be deployed to the department. In order for this to happen, a department liaison who understands the technology needs of the department will be required to meet with the project team prior to deployment. Personally-owned computers which store or access University data can be encrypted by providing software and instructions to individuals that need the software (See Appendix C for instructions on installing the software). Recommendation: Leverage Active Directory Active Directory provides the SafeBoot environment with advantages for both users and administrators. For administration, the Active Directory provides a means to automatically create new SafeBoot user accounts at the same time as a new employee is hired at UConn. As soon as the employee receives a NetID and email account, a SafeBoot account would be created through a feed from the UConn Active Directory. Also, when an employee separates from the University and his NetID is deactivated, so is his SafeBoot account, revoking access to University resources. This automation may be extremely important as employees enter and leave the environment. Doing this manually would be a large resource drain for University IT staff, who would be required to manage hundreds of changes each week. Page 10 For users to realize benefits of using Active Directory with SafeBoot computers must be configured to use the Active Directory and users must log into their computer using their Active Directory username. This is true for users of the centrally-supported UITS Active Directory as well as departmental Active Directories. SafeBoot has the ability to synchronize with multiple Active Directories (and Novell servers) so that it can handle user logins that exist in various distributed areas. This would allow UITS-supported computers to take advantage of the UITS Active Directory, while users in various departments, schools, or colleges which use their own Active Directory could do the same in those areas. Currently, most computers that UITS supports are not configured to use the UITS Active Directory; however, it is recommended that UITS configure computers it supports to use the UITS Active Directory as a means of workstation management and to realize the benefit of a single computer sign on with SafeBoot. It is recommended that Active Directory configuration for UITS-supported desktops and laptops be completed as part of the SafeBoot deployment. The benefit that Active Directory provides to users of SafeBoot is an integrated login to their computer if the SafeBoot username is the same as the computer or Active Directory username. In this case, users would log on to SafeBoot, and be automatically logged on to Windows, requiring the user to log on to the computer once. For UITS-supported computers the Active Directory username is based on something familiar and recognizable to faculty and staff who are regular users of the UConn NetID. This can help users adapt to the new system since they will not be required to remember an additional username. Some University schools, colleges, and departments at UConn are running decentralized Active Directory environments and do not use the NetID as a username. It is possible for a central SafeBoot environment to also synchronize with those Active Directories so that users in those departments will benefit from an integrated login as well. Staffing Recommendation: Encryption Rollout (Project Phase) The number of staff recommended to deploy encryption software and configure Active Directory on computers is as follows: " (1) 100% SafeBoot Consultant onsite for 2 weeks: SafeBoot is contracted to assist with server configuration, establish an appropriate environment and client configuration, and provide training for SafeBoot administrators. " (1) 50% Full Time Equivalent (FTE) staff for 14 months: A single project manager who would be responsible for managing the project schedule and tasks, reporting, and communication. " (1) 100% FTE for 14 months: A technical lead responsible for documentation, interfacing with department liaisons, scheduling, software installations, field lead, and SafeBoot server configuration and maintenance. Page 11 " (1) 50% FTE for 2 weeks: A Windows Server Support Group representative would be required to install servers, install the operating system, patch, configure backups and restores, configure firewall rules, and provide assistance during the SafeBoot onsite consultation. " (6) 100% FTE for 14 months: Six staff members responsible for installations of encryption software in departments, Active Directory migrations, troubleshooting, and documentation. " (1) 20% FTE for 2 weeks (per department): One department liaison from each department assigned to work with the Encryption project team, collect information, help schedule installations, report problems, and distribute information to the department. These recommendations are based on the following assumptions: " Faculty, staff, special payroll, student employees, and affiliates at the University: 6,000 " Number of laptops in use at the University: 1,700 (source: 28.38% of faculty, staff, and administrators as reported in Januar y 15, 2008 UConn survey on Mobile Device Usage . See Appendix D for details). " Number of faculty and staff desktops in use at the University: 9 ,000 (source: Number of faculty, staff, special payroll, affiliates, adjunct faculty, and student employees multiplied by 1.5 ) . " Total number of University-owned computers: 10,700 (Assumed UITS will install on all University-owned computes, including areas with dedicated IT staff) " Time to configure a computer for Active Directory: 1 hour (source: based on previous installations; not required for computers in departments that have their own Active Directories) " Total time to install SafeBoot software: 30 minutes (source: based on installations performed during the Data Encryption Pilot Project) " Number of computers a single person can configure with Active Directory and install SafeBoot in a given day: 5 (on average, depending on travel time) 7 " Total number of FTE required to complete Active Directory configuration and SafeBoot installation for UITS-supported computers: 7 (6 FTE and Technical Team Lead) In order to maintain the aggressive deployment schedule University Executive Administrators must communicate to the University faculty and staff the University 9s commitment to the encryption initiative. The expected deployment schedule should be determined by the University President 9s Office and communicated to the University as a significant initiative for the coming year. 7 Deploying encryption and Active Directory configurations at UConn regional campuses will involve travel time and expenses, including vehicle\gas and hotel. Page 12 Project Staffing Scenario #1: Hire a project team dedicated to deploying the SafeBoot software In this scenario, a current UITS staff member should be assigned as project manager for 50% time for 14 months. In addition to this, 6 full time staff members would be hired and dedicated to the project deployment. UITS currently has one staff member dedicated to the Encryption initiative, and this position could be considered the Encryption technical team lead. This position is a one-year end-dated position scheduled to expire in May of 2009. Assuming the Encryption deployment would begin January of 2009, the end-dated position would be required to be extended through February of 2010 (additional 9 months) to meet the timeline of this project. Project Staffing Scenario #2: Use of existing staff with supplemental Graduate Assistant staff In this scenario, a current UITS staff member should be assigned as project manager for 50% time for 14 months. The current UITS staff member dedicated to the Encryption initiative could be considered the Encryption technical team lead. This position is a one-year end-dated position scheduled to expire in May of 2009. Assuming the Encryption project would begin January of 2009, the end-dated position would be required to be extended through February of 2010 (additional 9 months) to meet the timeline of this project. To supplement the deployment team, Graduate Assistants should be hired to install encryption software and configure computers to use Active Directory. Eleven Graduate Assistants would be needed, ten dedicating 20 hours weekly and one dedicating 10 hours weekly to the project through beginning in January 2009 through February 2010. Staffing Recommendation: Support of Encryption (Production Phase) Once encryption is in place, there will be an impact to staffing roles, responsibilities, and workload in order to sufficiently provide support for the product. The following is expected: " (1) 20% FTE ongoing (UITS CS&R Help Center): During the pilot project UITS received 7 support calls in almost 3 months of use with approximately 80 users. This projects to an additional 2100 support calls per year (or 8 calls per day) if the entire University faculty and staff (6,000 users) are using the software. The type of support requests is expected to be password resets. " Extended Help Center Hours: Because FDE affects how users log into their computers, there may be an increased need for extended hours of support from the UITS Help Center. In general, the support model that presents itself with FDE is that this should not be required since it is not expected today. However, this is something that should be monitored to ensure that the support needs of the University are not ignored as the product is being deployed. " (1) 3% FTE weekly ongoing (UITS CS&R Accounts): The SafeBoot application should be managed by the UITS Customer Support and Relations staff in order for the group to continue to provide timely service and support to customers. Once the Active Directory connections are made (during the project) application maintenance estimated at 3% FTE is based on the Pilot Project. Page 13 " (1)100% FTE ongoing (UITS CS&R TSS): Due to staff shortages realized by the UITS TSS group over the past 2 years, data encryption would place additional demands on the TSS staff, making it difficult, or impossible, to provide timely service and technical support to UITS customers. With the need of image impact testing, application troubleshooting, data recovery, and the additional expected overhead onto traditional support, the UITS TSS group will require an additional 1 FTE to meet the demand. This may be met with the addition of a staff member, or retaining 2 GA positions after the project deployment phase ends. " (1) 2.5% FTE monthly ongoing (UITS SSG-Windows): The SafeBoot server will require management of the Windows Operating System and server hardware. The UITS Server Support Group would need to manage an additional 2 Windows servers (see next section) for monthly patch upgrades, backup and restoring of data, hardware issues, etc. " Distributed IT support staff will also be impacted by the need to continue to provide timely service and support in their departments. Because the impact of FDE on the distributed support areas is similar to the impacts on UITS service and support (password resets, image impact testing, application troubleshooting, data recovery, and the additional expected overhead onto traditional support), it may be necessary to provide additional resources to distributed IT areas as well. Staffing Recommendation: Turnover to production In order to properly support the SafeBoot encryption initiative, the following are resource recommendations for moving the service into production: " (4) 25% - 50% FTE for 3 weeks: Staff at the UITS accounts desk should be assigned to learn the process of managing SafeBoot, including user provisioning, password resets, and providing and revoking access to computers. In addition, a SafeBoot server administrator and a backup administrator should be appointed in the UITS TSS area to support the SafeBoot application in production (SafeBoot application management and upgrades). These individuals must be present during the SafeBoot onsite consultation to learn about the product and receive knowledge transfer. Additionally, at the conclusion of the project, the administrators should be available for 1 week for knowledge transfer with the Encryption Project Technical Team leader. " (9) 50% FTE for one day: UITS should plan on Help Center staff learning the process of handling SafeBoot password reset functions. Learning the process should take one half of one day per Help Center Analyst and should be completed at the start of the project. " (5) 50% FTE for one day: UITS should plan on TSS staff to learn how to interact with the SafeBoot product, recover data, and work with images. This is estimated to take one half of a day for all TSS staff and should be completed at the start of the Encryption project. Page 14 " Distributed IT staff intending to act as SafeBoot administrators may attend a 2-day training session with the SafeBoot onsite consultants. At the conclusion of this training, attendees are certified SafeBoot administrators and are better able to provide support for the product in their own departments. UITS should plan on making that training available to all distributed administrators through a computer classroom environment at UConn 9s Storrs campus. An additional class may be held for branch campus IT administrators and can be held at a conveniently-located branch campus. Server Environment Recommendation: Purchase dedicated physical servers for SafeBoot use Because SafeBoot will be a critical service, availability will be extremely important, and performance cannot suffer. During the pilot a single VMWare server was used to service 80 people. Because the server was configured to synchronize Active Directory accounts, approximately 3,000 user accounts exist, but only 80 are in use. For the pilot project, the VMWare server was adequate and served its purpose in providing a server environment for the pilot group. Despite the success in using VMWare in the pilot phase of the project, discussions with SafeBoot and DoIT staff have revealed that physical servers are required for the number of users that we expect to service with a central SafeBoot system. It is recommended that UTIS purchases 3 servers for this initiative: one primary server, one backup server, and one test server. Recommendation: Synchronize Active Directory groups by department The UConn Active Directory environment is configured to mirror the University structure as outlined by the University Master University Department (MUD) table, which is organized by Executive, Unit, and Department levels. During the pilot project the SafeBoot server was configured to synchronize with departmental-level groups. It is recommended that this practice continue for the following reasons: " Organizing SafeBoot users by department provides flexibility in managing users and devices and providing access control. The granular level that the department-level provides allows the SafeBoot administrator to provide and revoke access to resources by entire groups of departmental users. " Distributed administration of University departments is facilitated since the department groups mirror the makeup of the University 9s structure. Distributed administrators can be given access to a single group of users, or several, depending on the environment. Synchronizing with departments enables this distributed administration. Page 15 Some items to consider with Active Directory synchronization with SafeBoot are: " University departments frequently change. If the SafeBoot groups are set up to synchronize with Active Directory the SafeBoot connection will need to be adjusted each time a University department changes in the MUD table. Department changes may happen without notice, and therefore UITS will need to establish proactive procedures for dealing with this issue, most likely with the SafeBoot application manager. It is recommended that the UITS Accounts desk be notified of MUD table changes (notification available through an email distribution list) and reconfigure the Active Directory synchronization, as needed. These changes happen periodically, and estimates for this activity are included in the 3% ongoing support required for the product. " Active Directory accounts which are marked as deactivated (as opposed to deleted) are deactivated in SafeBoot. Generally, when faculty and staff separate from the University, Active Directory accounts remain for up to 60 days. It is recommended that this process be adjusted to disable or delete NetID accounts in a timelier manner, which will ensure that as faculty and staff separate from the University their SafeBoot accounts will be disabled. " Because the SafeBoot license allows for the use of the software on personally-owned computers there must be a process to handle staff separations when SafeBoot is installed on personal computers. A process must be put into place at HR during the exit interview process to include the identification of SafeBoot users and removal of the software from personal computers. Exemptions Recommendation: Develop criteria and process for exemptions Because of the nature of the University 9s work, there will some instances where FDE should not be required. These cases should be considered for exemption based on the role of the computer and the type of data that is stored on the hard drive. The criteria for exemption must be based on empirical proof that no data must exist on the computer hard drive in the instance where it is lost or stolen. If this can be proven, an exemption should be granted. It is important that the process for exemptions to the data encryption requirement not create excessive process and overhead, however, the process must be auditable, and all computers must be accounted for in some way: either through being encrypted, or via documented exemption. Passwords and Access Control Recommendation: Revisit enterprise password syncing and password complexity requirements The Data Encryption Pilot Project was a driver in configuring computers in the Active Directory to allow users to change passwords from a host computer. However, it was brought to light that the Active Directory is currently not enforcing password complexity requirements, allowing for weak passwords. It is recommended that this be remedied in the near term and that the enterprise Active Directory be configured to enforce password complexity. Page 16 Future Recommendation: Investigate the use of hardware tokens FDE software allows the University to secure its data, however, the use of hardware tokens provide an additional level of security in that users must not only know a password, but must also be in possession of a physical device in order to access a system. It is recommended that UITS investigate the use of hardware tokens in the future to be used along with SafeBoot in order to enhance the level of security of University devices. PDA 9s and USB drives Future Recommendation: Investigate the use of PDA and USB encryption software The SafeBoot software suite has components which allow organizations to encrypt PDA 9s, USB drives, and other types of data (such as data on a server shared drive). Providing FDE to University computers gives the University protection of data residing on computer hard drives; however, there remains significant risk with other portable storage devices such as PDA 9s (such as Palm devices and SmartPhones) as well as external USB drives (such as USB flash drives). The University should consider the SafeBoot Content Encryption product after encrypting laptops and desktops with FDE. Servers Future Recommendation: SafeBoot Content Encryption Although FDE software may function on servers, it is not part of the scope of this initiative to include servers in the requirement for encryption. It may be used with servers if desirable, however the threat against servers should be looked at as unauthorized access via incorrectly applied permissions, or through network-based attacks. FDE will not provide protection in either of these scenarios. For file servers, it is recommended that SafeBoot Content Encryption be employed to protect data outside of encrypted hard drive. With Content Encryption, files are protected if stored on servers as well as other mediums, as encryption is being applied at the file layer. However, the permissions for accessing encrypted files in this model is managed similar to managing FDE, allowing for multiple users and administrators to access data in the event that the original owner cannot access it. Page A-1 Appendix A 3 Issues encountered during the Data Encryption Pilot Project ISSUE Fix or Workaround USB keyboard and mouse connected to monitors do not always work for a SafeBoot login. 1. Plug keyboard directly into USB port on computer (workaround) USB keyboard and mouse connected to a laptop dock do not always work for a SafeBoot login 1. Plug keyboard directly into USB port on computer, boot, then dock the laptop (workaround) 2. Change SafeBoot settings to allow computer to manage USB devices (fix) Laptops with BlueTooth or wireless keyboard and mouse connected to dock. Devices did not work for SafeBoot authentication. SafeBoot does not support authentication with BlueTooth keyboard and mouse 1. Plug keyboard directly into USB port on computer, boot, then dock the laptop (workaround) 2. Use a wired keyboard and mouse (workaround) Computer with USB KVM switch: keyboard or mouse access do not function properly on boot-up; Unable to log into SafeBoot Keyboard and mouse do not function properly in the BIOS without SafeBoot installed. 1. Another KVM switch may function properly (workaround) Attempting to boot into Safe Mode following SafeBoot authentication, keyboard was not functional when boot options menu was presented. 1. Uncheck property cAlways enable preboot USB support d on SafeBoot configuration (fix). Vista computers do not set SafeBoot password to match Active Directory password. Must manually change SafeBoot password. 1. Manually change SafeBoot Password (workaround) 2. Manually lock and unlock computer (workaround) 3. Install latest version of SafeBoot (fix) If a USB flash drive is plugged in the computer hangs after SafeBoot login and Windows boot 1. Remove USB Flash Drive (workaround) 2. Change SafeBoot settings to allow computer to manage USB devices (fix) Page A-2 ISSUE Fix or Workaround The latest version of SafeBoot does not include support for computers with RAID hard drives. Many new Dell desktop computers are available with RAID hard drives. No resolution. Problem has been reported to McAfee for integration into future client releases. Configure computer to use 2 hard drives rather than 2 hard drives configured as a single RAID drive (workaround) SafeBoot remembers password and domain for users. If the same user has multiple machines and logs in to one with a local account, then installs onto another machine, SafeBoot attempts to use that machine name as the 8logon from 9 on the next computer and login fails. Turn off single sign on (workaround) SafeBoot password synchronization did not work for an XP machine logging in through Novell. Turn off single sign on (workaround) User typed password incorrectly twice when first installed, and was then blocked from booting. Use SafeBoot recovery options: Challenge\Response for password recovery and\or system boot. SafeBoot installed on laptop, would not boot after SafeBoot login One instance of this problem occurred. Problem was eventually resolved with the software and system was then bootable Page B-1 Appendix B: SafeBoot File Recovery using BartPE Overview Because SafeBoot encrypts the hard drive of protected computers, normal bootable tools used to recover data from a failed computer will be unable to read the drives. SafeBoot provides plug-ins that can be added to a BartPE bootable CD. These tools allow an authorized user to authenticate and then view and copy data from the encrypted drive. Injecting SafeBoot plug into your BartPE ISO image " Use a tool that can modify your BartPE ISO without extracting it (UITS used MagicISO). " Add the SafeBoot files to the proper locations. " Add the menu items. " More detailed instructions and files are available to system administrators by request through the UITS Help Center. SafeBoot supplied BartPE ISO image " An ISO image of a SafeBoot built BartPE is available. It contains the plug-ins but will not be able to perform network connections so files would need to be copied to a USB drive. " This ISO image is available to administrators by request through the UITS Help Center. Using BartPE with the SafeBoot plug-in " Insert the BartPE CD into the drive of the system from which files are to be recovered. " Plug in any required USB drives. " If the system is not set to boot from the CD before the HDD, use F12 to obtain a one time boot menu and choose the CD drive " If using the UTIS multi-boot CD select the option for BartPE with SafeBoot. This selection is not necessary using the SafeBoot supplied CD. " BartPE will boot " From the GO menu, choose Programs SafeBoot Wintech " A screen titled 8Authorise 9 will appear. Normally an authorization code is unnecessary. Click Cancel. " SafeTech for Windows will open " Click the SafeBoot tab at the top of the screen; choose 8Authenticate From SBFS. 9 " Highlight 8Password Only Token 9 and click OK. " A SafeBoot authentication screen will open. " Enter a SafeBoot ID and password for a user authorized to access this computer. " After authentication, the contents of the encrypted drive will be available to normal BarPE utilities and can be copied to USB drives or network locations if a network is available. Page C-1 Appendix C: SafeBoot Windows Client Installation Know Your ID 9s UConn NetID: ___________________________________________ Windows login ID: ___________________________________________ SafeBoot ID _________( matches your UConn Net ID )___________ Pre-installation Prior to installing SafeBoot perform a check-disk operation on all local hard drives. 1. From cMy Computer d, right click on Local Disk (C:) and select Properties 2. Go to the cTools d tab 3. Click on cCheck Now d in the cError-checking d box. 4. Select both options and click Start. 5. You will be prompted that a restart is necessary to accomplish this check. 6. Repeat steps 1 3 5 for any remaining hard disk drives with a type of cLocal Disk d. 7. Reboot the computer. Disk checking usually requires 15 3 30 minutes depending on the size and number of drives being checked. Installation 1. Unplug any external hard drives that you do not want encrypted. 2. If your computer has a zip drive, be sure that it contains no media. 3. Unplug any USB flash drives. 4. Run the SafeBoot installation file that has been provided by your SafeBoot administrator 5. SafeBoot setup will complete in less than 5 minutes. You will be prompted to restart your computer. 6. Click 8Finish 9 to restart your computer. 7. When your computer restarts, log on. 8. After Windows starts, you will see a SafeBoot icon in the system tray at the lower right side of your screen (grey computer with padlock). 9. Right click the SafeBoot tray icon and select 8Show Status 9. 10. The SafeBoot Client Status window will open. SafeBoot Page C-2 11. Click the cSynchronize d button. 12. You should see cSynchronization complete d (12-a) near the bottom of the log area, and Encryption 8in Progress d (12-b) in the encryption status area. a. Drive encryption may take 2 or more hours per hard drive to complete. b. Your system performance will be impacted during this process. 13. Close the SafeBoot Client Status window and restart the computer. You do not need to wait for encryption to complete. Logging in After SafeBoot Installation SafeBoot Login When your computer restarts, you will need to log in to SafeBoot using your SafeBoot ID. (SafeBoot Login Screen) 12-a 12-b Page C-3 " The first time you log in to SafeBoot, your SafeBoot password will be 12345. " If you have previously logged in to SafeBoot, even on a different computer, your SafeBoot password will match what was set for your prior SafeBoot login. " After you log in to SafeBoot, it will start Windows. Windows Login Scenarios Scenario 1: SafeBoot ID ` Windows login ID " SafeBoot will start Windows but will not log in. " You will need to log in using your Windows ID and password. Scenario 2: SafeBoot ID = Windows login ID " SafeBoot will start Windows and attempt to log in. o If your SafeBoot password is not the same as your Windows password the automatic login will fail. o You will need to log in using your Windows ID and password. o SafeBoot will synchronize its password to match your Windows password. o The next time you restart your computer SafeBoot and Windows passwords will be the same and the automated login will succeed. Changing your Password If your SafeBoot ID, your Windows login ID, and your UConn NetID are the same, and SafeBoot automatically logs in to Windows, your machine should be set to enable password change when you press the Ctrl + Alt + Delete keys. Page C-4 To maintain synchronization between your SafeBoot password and your Windows password, you should use this mechanism to initiate a password change. If you change your password using UConn 9s NetID web site https://netid.uconn.edu/NetIDHome/ : " Your Windows and UConn NetID passwords will be updated, " Your SafeBoot password will not be updated. " On your next restart, you would need to log in to SafeBoot using your old password and then to Windows using your new password. SafeBoot will then resynchronize its password.

less