Navigating Endpoint Encryption Technologies Whitepaper November 2010 THIS WHITE PAPER IS FOR INFORMATIONAL PURPOSES ONLY, AND MAY CONTAIN TYPOGRAPHICAL ERRORS AND TECHNICAL INACCURACIES. THE CONTENT IS PROVIDED AS IS, WITHOUT EXPRESS OR IMPLIED WARRANTIES OF ANY KIND.
Introduction With so many options for endpoint encryption, which one is the right one for your organization? Understand the difference between the technologies to find the right solution for your environment and understand the benefits and drawbacks of each. Learn about Dell s new encryption solution, Dell Data Protection Encryption, that helps enable high levels of protection with low levels of impact on your infrastructure and processes. Most of today s endpoint encryption technologies can generally be divided into three categories: Software full disk encryption File and folder encryption Self-encrypting drives In this whitepaper, we ll explain, at a high level, how each of these technologies work and give you guidelines to evaluate encryption solutions so you understand which one may be right for your organization. Software full disk encryption Software full disk encryption (FDE) is a type of encryption that usually encrypts all sectors of a hard drive, except critical files required for boot processes. There are many versions of the technology, but the goal is to protect data from unauthorized users. Implementations of FDE all rely on one consistent boot method used since the introduction of the original IBM PC. In order to boot without a unique BIOS assisted method, there must be a master boot record (MBR) located at a defined side-track-sector on a designated active and bootable disk to initiate a traditional BIOS boot. This MBR (a 512-byte sector on the drive) is responsible for initiating the boot loader. Control is passed to the boot loader that loads a kernel to initiate the file system manager and activate a set of device drivers capable of communicating with basic boot and user interface devices. Implementations vary, but the earliest point at which encryption could begin is within the boot loader, meaning that the MBR remains unencrypted in most implementations of encryption. However, the amount of un-encrypted space on the boot drive varies by implementation. Typically, software FDE implementations load a Linux operating system as part of a real time operating system (RTOS) to enable a degree of customization in the boot process and a less vulnerable attack target. However, the boot method doesn t change. The master boot record of the user operating system is replaced by the encrypting operating system s master boot record and the requirements of the boot operating system s MBR are no different than the user operating system s MBR. The boot operating system then loads the encrypted user operating system. As the user operating system loads, the boot operating system may act as a filter for the user operating system storage transactions by intercepting storage device requests and encrypting or decrypting as required. Other implementations may install hooks on key user operating system APIs, kernel components and/or drivers during the installation of the product. Methods of accomplishing the initial encryption vary by implementation. Most occur as a background task and encrypt silently. Software FDE usually encrypts 100 percent of the drive, minus what is required for the boot process. Implementations are seldom partition aware. If multiple operating system support is required, ensure that the FDE solution supports both operating systems. Also, there is frequently an installation order requirement. While encryption is taking place, some FDE solutions have a small window of data corruption potential. A typical encryption sequence first builds a progress table. The encryption process then reads an unencrypted sector, encrypts the sector and writes it to the storage device, changes the file system link(s), updates the progress table and repeats until end of disk. If the system is in use, system requested sector reads and writes are compared against the progress mark for encryption requirements. Vendors corruption window will vary by the success of methods used to abate the corruption potential. A best 2
practice is to enable the encryption and schedule the initial encryption for a time when the system will be unused and allowed to complete in one session. Available solutions frequently include value-add features such as user authentication capabilities for fingerprint, smartcards, multi-factor, facial recognition and other technologies not commonly available from out-of-the-box operating systems. When choosing an FDE solution, authentication methods and management for authentication recovery and migration, forgotten passwords and lost access tokens must be considered. FDE solutions may make it difficult to manage the user operating system because the FDE software must be configured to enable management of the user operating system. The management interface for FDE is usually proprietary and requires a separate vendor console to manage it. Recovery and migration have unique implementations and requirements as there are no industry standards for FDE. Key management varies based on the implementation and may or may not support specific enterprise key management architectures. It is also recommended that customers defragment their hard drives and run Checkdisk several times to ensure smoother deployments. 1 File and folder encryption File and folder encryption differs from FDE in that only user files and folders are encrypted, while applications and the operating system are not encrypted. Though simple in concept, implementation can be daunting. Temporary files created by applications, file and folder copy and paste, print to file, screen copy and paste, back-up files and page and swap files must also be encrypted as these all contain user data. File and folder encryption is attractive in that it enables features not found in FDE solutions. Flexible key policies can be defined on a per folder, file type, base user or user basis. Keys are only required to remain in memory for as long as the file is open and are then discarded. When files are backed up to a secondary drive, those files can also be encrypted. Performance on a file and folder encrypted drive is typically higher than the performance of a software FDE solution. Management of the file and folder drive is simplified because there is no additional encryption of the operating system or applications to authenticate to and manage. Authentication in the file and folder solution is frequently native to the operating system and encryption is conducted as a background task. Unlike FDE, only sectors allocated to user files and data are encrypted so sectors that are never used for data storage will not be encrypted. Since the file system tables are not encrypted, the file and folder susceptibility to a corrupted file system is much smaller compared to FDE and can frequently be repaired without the user ever knowing there may have been a problem. With file-based encryption, it is also possible to protect removable media with the same solution you use to protect data on the system s main disk. Self-encrypting drives (SED) Self-encrypting drives represent a class of storage devices where encryption capability is internal to the device using an encryption accelerator that handles encryption processes. The standard interface for these devices is defined by the Trusted Computing Group s Opal Security Subsystem Class Specification 1.0. These devices support the standard SATA or Opal interface. If the encrypted mode is enabled, communicating with the drive requires a slightly different path initially, but once unlocked, the interface is standard SATA. Opal specifies either 128 or 256 bit AES encryption support and the encryption key is contained within the drive electronics and never released. 1 http://www.computerworld.com/s/article/print/9139733/full_disk_encryption_dos_and_don_ts 3
To enable SED, commands are sent to the drive to configure it for encrypted operation. A small partition on the drive is created or enabled to store the boot code, which authenticates the user to the drive. At set-up time, vendor-specific software is loaded that allows a remote or local management console to administer encryption policies and audit capabilities. The Opal specification does not define the interface to this boot code, only the interface between the code and the drive. During BIOS boot, communication is between the vendor SED boot code and BIOS, not BIOS and the operating system s master boot record. The boot code authenticates the user to the drive then transitions to normal boot operation. Typically, there is no performance degradation using SED drives as hardware encryption acceleration outperforms drive performance. Since the encryption key never leaves the drive, there is no key backup. Authentication back-up must be used in place of key backup and restore tools must be capable of restoring the SED authentication sequence. Restore tools, features, method, management and capabilities are specific to the SED management vendors. Also, SEDs currently command a hefty premium. Encryption auditing capabilities No matter which implementation of encryption your organization deploys, make sure that audit capability is part of the management console. As a requirement of governance law (Sarbanes-Oxley Act, Health Insurance Portability and Accountability Act and/or state and local requirements), special attention must be given to obtaining proof of data encryption for the purpose of exemption from breach disclosure notification. 2 The management console should have the capability to run a report against the database to determine whether or not a specific system s data was encrypted. Dell Data Protection Encryption Dell recently introduced Dell Data Protection Encryption (DDPE), a file-based encryption implementation that adds the best features of FDE and file and folder encryption. From the FDE solution, DDPE implements the richness of a Microsoft Windows authentication process without the overhead of a RTOS. DDPE does not encrypt the files necessary for booting the Windows environment, as with other encryption implementations. This means you don t have to manage a RTOS in addition to Windows administration processes. It also makes patch management easier and observes the Windows user/administrator rights and privileges hierarchy natively. The authentication of users prior to the boot process (outside of the Windows authentication environment), a self-encrypting drive feature, is accomplished using Dell s pre-boot authentication options that originate from within BIOS using Dell Security Manager. Dell has a rich solution space that not only enables passwords, but also token and biometric devices. Wizards available within the Windows environment will walk you through the set-up and enablement process or can be remotely managed. Token and biometric devices can be set up to log the user in from within a BIOS environment all the way through and into Windows. DDPE offers an interesting hybrid software FDE model of file based encryption. The model uses two set of encryption keys a common key for the operating system and unique key tied to the end user for data. It allows IT to authenticate to the common key for the OS to patch and repair any issues without exposing the user data. When the end user authenticates to a system, both keys are released giving that individual full access to their system and data. With this hybrid model, it is easier to manage the operating system or applications without unique encryption management requirements. When an encrypted drive is attached to a separate system as a secondary storage device, all data but the boot files are protected, same as the FDE environment. This provides a double layer of security, where if a possible attacker got through the common key, the user 2 http://www.trustedcomputinggroup.org/files/static_page_files/b1f59d21-1a4b-b294- D0B0998A3BDCF381/SED%20Solutions%20for%20Data%20Security_May192010.pdf 4
data is still protected with a key that is unique to the end user. The hybrid model is also capable of using different data keys for different users as determined at authentication. System performance for this hybrid model is similar to that of an FDE environment. The management console has advanced options that allow customers to create and enforce policies based on their needs. From a file and folder implementation, DDPE implements file encryption and there is no need to consume time and system resources encrypting empty sectors. As sectors are consumed, they are encrypted appropriately and deleted file data remains encrypted. You can choose to encrypt all data on the drive (minus the MBR) if that is the level of protection required using advanced template options within the management console. Factory recovery and diagnostics partitions are, by default, not encrypted. If needed, advanced options enable you to modify this implementation feature. The common misperception of file-based encryption is that there may be end user intervention required to encrypt data. With DDPE, there is no end user intervention required. DDPE implements a file system filter that interacts with Windows at the file system level and when Windows sends a request to either access or create a file (or data), it goes through the filter. That is the layer where policy is enforced. It encrypts all file types that contain data, including source files and temporary files created by applications, file and folder copy and paste, print to file, screen copy and paste, back-up files and page, and swap files. In addition to protecting the system disk, DDPE can also encrypt removable media, or basically any drive that Windows reads as a drive letter, including optical media. The implementation provides customers the capability to enforce policies for how removable media is handled: Enforce password and password strength for sharing Enforce number of times a password can be tried before locking it down Do not allow media sharing Scan media to enforce encryption Set read-only policies Audit encryption state Compliance is a top concern for customers and DDPE helps make it easy with templates that allow customers to quickly setup policies based on their needs. These are designed for customers that may have little or no IT resource and as a starting point for power users who can customize the templates further. The levels of protection include: Basic Protection for system, fixed and/or removable drives: Encrypt using a common key all or some of fixed drives and system drive with a prompt to encrypt removable media. Aggressive Protection for All Drives: Application and data are encrypted with a user key (vs. common key). HIPAA Targeted: Health Insurance Portability and Accountability Act (HIPAA) mandates that healthcare organizations implement a number of technical safeguards to protect the confidentiality and integrity of all individually identifiable health information. All Fixed Drives are protected using System Data Encryption (SDE) policies and Application and User Data are encrypted with a common Key. This template enables Removable Storage policies. Data Breach Regulatory Targeted: The Sarbanes-Oxley Act requires adequate controls for financial information. Because much of this information resides in electronic format, encryption is a key control point when this data is stored or transferred. The Gramm-Leach-Bliley (GLB) Act (also known as the Financial Services Modernization Act) guidelines do not require encryption. However, the Federal Financial Institutions Examination Council (FFIEC) recommends that, "Financial institutions should employ encryption to mitigate the risk of disclosure or alteration of sensitive information in storage and transit." California Senate Bill 1386 (California's Database Security Breach Notification Act) aims to protect California residents from identity theft by requiring organizations that have had computer security breaches to notify all affected individuals. The only way an organization can avoid notifying customers is to be able to prove all personal information was encrypted prior to a security breach. All Fixed Drives are protected 5
using System Data Encryption (SDE) policies. Application and User Data is encrypted with the Common Key. This template enables Removable Storage policies. PCI Data Security Standard Targeted: Payment Card Industry Data Security Standard (PCI DSS) is a multifaceted security standard that includes requirements for security management, policies, procedures, network architecture, software design, and other critical protective measures. This comprehensive standard is intended to help organizations proactively protect customer account data. All Fixed Drives are protected using System Data Encryption (SDE) policies. Application and User Data is encrypted with the Common Key. This template enables Removable Storage policies. The right solution for you Now that we have explored the various technologies you can use to protect your systems and removable media, which one is right for you? There are critical four factors to consider: Legacy system support: You need to consider what you have to support in your environment. FDE and file-and-folder encryption will work with new and legacy systems. SED requires more consideration because in medium-to-large environments there may not be 100 percent penetration of SEDs across the deployment. You may have to deploy a SED implementation and a different FDE or file and folder implementation with separate management consoles to support SED and non-sed drives. If you never deploy 100 percent SED, you may need to use two solutions indefinitely. Deployment: Also consider the ease of deployment. With FDE, most vendors recommend running Checkdisk and defrag to produce contiguous files where possible to prevent possible deployment stalls or system errors. With file-based solutions, like DDPE, you simply deploy an agent and enforce policy in a way that transparent to end users. Removable media: FDE and SED solutions may require a separate solution for protecting removable media so it is important to understand the risk that external storage poses to your organization. DDPE can provide a similar level of protection as FDEs and also provides protection for the system drive and removable media. Flexibility: Generally speaking, there is one choice for FDE and SED encryption policy enforcement encrypt or not. With file-based solutions, like DDPE, there are numerous options for handling policy enforcement based on user, data sensitivity, user groups and more. That same flexibility carries over to removable media as well. Management, audit and enforcement capability: Ensure that the tool you use has comprehensive management, reporting and enforcement capability so that you create a policy, detect devices, enforce the policy and audit encryption state of a device or data. Also make sure you evaluate the solution to find out if there are any alterations to the way you manage your assets today (patch management, authentication, etc.). There may be solutions that require a change to your current processes, so make sure you understand that aspect of the solution. With DDPE there may be no changes to the way you manage your current environment. By following the above guidelines, you should have a good idea of what solution will work best for your environment. 6