A+ Certification / Beginners

Database Encryption

Database encryption has quickly become an essential security issue as organizations realize how much damage and loss can occur due to a breach of a mission-critical database. It is also the case that many regulations and contracts now require organizations to implement database encryption in order to stay in compliance. However, database security is not as straightforward and simple as file or disk encryption. The main difficulty with database encryption is implementing the proper key management solution.

The interactions with a database by users and applications within an organizational network are quite complex, much more so than those of a shared file system on a network share. This complexity causes serious complications when it comes to managing encryption keys. If the encryption is done incorrectly, the keys might be inaccessible to authorized users or might become accessible to unauthorized entities, neither of which is a desirable outcome. Often a centralized key management system is needed. This could be a software-only solution or could involve various HSMs (Hardware Security Modules) to support large-scale key management.

It is important to ensure that the encryption keys used to protect any data, but especially data stored in a database, are not stored alongside or in an obvious place relative to the data. A separate key storage and key management system is essential. The practice of comingling secured data with its encryption keys is the equivalent of locking your front door and then hiding the key under the doormat. Usually, a distinct key storage database will provide a much more reliable means of key retention.

Database encryption can range from individual cell encryption to full table encryption, as well as any other intermediary division (such as rows or columns). When the encryption is on a table or database level, there are many fewer keys to manage than when each individual data cell has its own unique key. Often, choosing a less granular key assignment scheme makes key management more streamlined.

As mentioned previously, encryption is not a substitute for backups. This is equally true in relation to encrypted databases. However, it is important to encrypt the backups as well as the original data. Failing to encrypt and protect the backups of a database will simply shift the focus of breaches and compromises towards those backups. Always assume that the backups and the originals are equally vulnerable to intended or accidental compromise.

Another potential and common problem with database encryption is using out-of-date encryption technologies and algorithms. Many organizations invest decades in their DBMSs (database management systems). Although a DBMS from the previous decade might be sufficient for storing and organizing the data of the database, often the encryption from the previous decade is not strong enough to withstand modern attacks. Be sure to update or supplement the encryption scheme of older databases with modern solutions.

Individual file encryption

The encryption of individual files is implemented in a completely different fashion than full-disk encryption. The main distinction between individual file encryption and full-disk encryption is that each individual file can be encrypted by using its own unique encryption key. This is definitely the case for native file encryption features such as EFS (Encryption File System), which is part of the Windows NTFS file system. EFS, instead of storing and managing an increasingly large number of encryption keys in some form of master key-ring mechanism, stores each encryption key on the file it encrypts. This is implemented by using a public key cryptosystem in which the public key of the user is employed to envelop or encrypt the file's symmetric encryption key. This enveloped key is then stored on (or with) the encrypted file. When the user needs to regain access to the file, he or she returns with his or her private key to unlock the public key envelope and regain access to the symmetric key, which in turn is used to decrypt the file. Each time a file is decrypted by using this process, when the file is closed or saved back to the disk, a new randomly selected symmetric encryption key is selected and used to encrypt the file, and then that new symmetric key is enveloped by the user's public key for storage. This system allows the user to keep track of just a single private key rather than a growing number of symmetric keys. Not all individual file system implementations use this specific technique.

This process might seem complicated, but can be broken down in to a series of steps:

  1. A random symmetric key (K1) is selected for the target file.
  2. K1 is used to encrypt the target file.
  3. The user's public key (Pu) is used to encrypt (envelop) the file's symmetric key (K1) and then is stored on or with the encrypted file. At this point, the file is secured.
  4. When the user returns to gain access, the user's private key (Pr) is used to decrypt the envelope that is encrypted with the public key (Pu) to extract the symmetric key (K1).
  5. The symmetric key (K1) is used to decrypt the file.
  6. When the user closes or resaves the file, a new symmetric key is generated (K2), and the process is repeated.

There are a few concerns related to individual file encryption. First, this type of encryption does not protect metadata or temporary copies of open files. Only the original file itself is secured by individual file encryption. The other data created by the operating system or applications that interact with the file might expose the content to disclosure. Second, if the user's private key is ever lost or corrupted, this would prevent the user from decrypting files. A mechanism known as the KRA (key recovery agent) could be used to provide an alternate access path to the encrypted files.

A key recovery agent is a trusted administrator or group of administrators who can be called upon to decrypt files when the user's private key is lost or corrupted. This is made possible by storing additional copies of the file's encryption key in encryption envelopes made by using a key recovery agent's public key. Thus, the key recovery agent's private key can be used to access the additional stored copy of the file's symmetric key. The key recovery agent mechanism creates an additional recovery strategy not available when only the individual's public key enveloping is used. However, the use of a KRA should be considered carefully, because it creates a backdoor that a malicious user might take advantage of.

Tip:
Though the name KRA might imply that these agents recover lost keys and can restore them to the user, they actually recover their own stored version of the file's symmetric encryption key and, after it is used to decrypt the file, return a plaintext copy of the file back to the affected user.

File encryption can often be used on folders as well as files . Using file encryption on a folder would effectively "archive" the folder's contents into a container that is encrypted. In order to access any of the folder's contents, a user would have to decrypt the whole folder.

Individual file encryption might not always be the best choice for protecting data., because only those files that are intentionally encrypted have any protection, and then only the original files, not their metadata, are secured. Users of file encryption often only encrypt important files and not mundane files. Thus, hackers know to focus their efforts on the encrypted files because they contain the most useful or valuable information.

An often-overlooked benefit of individual file encryption is that files from multiple users can be stored on the same shared network storage device without conflict. Each user would only be able to decrypt his or her own files using his or her own private key. When full-disk encryption is used on shared storage devices, each user is given a copy of the single master key. Although this retains protection against outsider access, it does not differentiate access between those with possession of the master encryption key.

Removable media

Removable media presents its own set of risks and threats to an IT infrastructure. The two main risks related to removable and portable media are data leakage and loss, as well as malware infection. Removable media includes a wide range of technologies and devices, including:

  • USB flash drives
  • Portable hard drives
  • Optical discs, such as CDs, DVDs, and Blu-ray disks
  • Tapes
  • Memory cards, such as SD cards
  • Floppy disks

USB flash drives seem to be the most prolific in terms of causing problems for organizations-so much so that many have banned their use on company equipment and might even outlaw their presence on company property. This type of security policy and company stance reduces the risk of removable media by not allowing these drives in or out of the organization. Though this policy could be considered an extreme measure, it is often a justified measure.

Users are notorious for leaving important files on removable and portable media. This often occurs when a user uses a portable drive to move files between computers, and then after the files are copied to the destination computer, forgets that the files remain on the portable drive. If users fail to maintain respect for the files and the drive, they will often drop the drive into a drawer, leave it on a desk, drop it in their pocket, or allow other workers to borrow it. This situation leaves the drive open to being misplaced, lost, or stolen. If that occurs, whoever gains access to the drive in the future will now have access to those important files copied onto the drive. This is an all-too-common data loss scenario that can be prevented.

The primary means by which this form of data loss or data leakage can be prevented is through on-device encryption. This can be accomplished by using one of several currently available encryption technologies, such as individual file encryption, full-disk encryption, or on-device hardware encryption. The first two options would be applied to the removable media by encryption software on the computer. Thus, the same encryption software would need to be present on any other computer that the drive will need to connect to. The third option is encryption provided by the portable drive itself. This is only available if the specific make and model of portable device provides this feature. There are several manufacturers that offer encrypted USB drives. These drives are usually more expensive than the nonencrypted versions, but the additional security provided by the drives might be worth the extra expense in some situations.

ENCRYPTED USB DRIVES:
To find out what encrypted USB drives are currently available, search the Internet for "encrypted USB drive." This will reveal a plethora of options. Be sure to consider capacity and speed when making your selections. Also, look for USB 3.0 versions before making a final choice. USB 3.0-based encrypted drives are just starting to be available and provide some level of future-proofing.

For the best protection, automated or forced encryption is better than encryption that you have to remember to implement. Hardware-provided encryption or full-disk encryption automatically encrypts anything copied to the portable device. Individual file encryption does not usually encrypt new files automatically, so you will have to remember to manually trigger the protection. Also, don't forget that metadata and temporary file copies will not be protected by individual file encryption.

Another risk of removable media is that of malware infection. When portable media devices are allowed to exit the building, they are exposed to compromise in the outside world. If a compromised portable medium is then returned into the organization, it can be a vector for malware infection. Additionally, even "new" portable devices can be vectors of infection. Just because a media device is sealed up by the manufacturer does not guarantee that it was not infected at the manufacturer's own facility. This has occurred and will probably occur again. This, in fact, has own name: the shrink wrap attack.

It is even more likely that any media device that is "found" will be a means by which malware infests an organization. Hackers often use the social engineering trick of planting USB drives in public places, such as parking lots, waiting rooms, bathrooms, or break rooms. Such a planted storage device might seem like a windfall to a worker who does not realize that it is a trick to get the user to plug the device into his or her work machine, where auto-launching malicious apps can grant hackers access to the network.

Although using encryption will not fully eliminate the risk of malware infection from a removable media device, it will significantly reduce it. If storage device is secured, only when it is unlocked will there be an opportunity for malware to gain access to it. Cautious users who know that this window of opportunity exists will be careful about their use of these devices. And if the organization only allows encrypted removable media, those devices brought in from outside that don't meet the security requirements will not be used on the network.

For this latter statement to be fully enforced, organizations cannot depend exclusively upon users to abide by the written policy. Instead, they should use technology to enforce the approved-devices-only rule. This can potentially be accomplished by the setting the CMOS and BIOS settings on motherboards to either fully disable all USBs or just disable the connection of storage devices. For a more flexible solution, many operating systems now offer the ability to block the class of general portable storage devices while allowing specific devices by serial number or model number. Thus, only the approved, encrypted storage devices will be allowed to connect, while all other devices will be automatically disabled and ignored because the operating system will not allow their relevant device driver to load.

A few other good security practices in relation to removable media are:

  • Don't leave removable media attached to a computer; instead, remove them as soon as their use is completed.
  • Check computers for attached removable media before every startup or restart process.
  • After using a removable media device to transfer files, perform a media sanitization process to delete and scrub the drive clean of all data remnants.
  • Use a precleaning process (a "sheep dip") to "verify" new removable media devices before allowing them to be used in the organization.
Tip:
The term sheep dip is sometimes used to describe a stand-alone anti-malware scanning system that is intended to be used as a precleaning tool for removable media devices before they are connected to the production environment. A sheep dip system needs to have scanner updates manually transferred to it daily. The use of this precleaning methodology will reduce malware infections via removable media.

Removable media, portable media, and external storage devices are neither perfectly safe nor unable to be secured. However, it does take considerable effort to establish a security policy, and it requires user practice to improve the security around removable media devices and reduce the risks they pose against an organization.

Mobile devices

Mobile device encryption is another important tool in the toolbox of the security manager whose job it is to protect an organization against data loss and security breaches. Many of the security issues related to mobile devices, including mobile device encryption. For clarity, we have reframed the encryption discussion for this tutorial.

What are mobile devices? Generally, the phrase is used to refer to smart phones, feature phones, and other forms of mobile phones. But the term is not strictly related to phone devices. The exploding category of tablets is also included in the concept of a mobile device. And to be thorough, don't forget about audio players, digital still and video cameras, mobile hotspots, portable projectors, and media sharing devices. Those devices that might be considered miniature computers, such as smart phones and tablets, are often exposed to the same risks as traditional computers. Other less powerful, less capable, or less flexible forms of mobile devices might not have as many threats against them, but such a device can be just as big of a threat against individual computers or an organization's network.

One of the big issues with mobile devices of all types is that they can often be connected to a computer by a USB cable, via Bluetooth technology, or through a wireless network, and they appear on the computer as storage devices. This requires security professionals to treat mobile devices like removable media, as discussed in the previous section. Any mobile device that has any form of data storage ability can be used to perform intentional or accidental data leaks, data loss, and/or malware distribution. Thus, precautions must be taken to avoid and when possible eliminate this risk.

One option is to implement an organization-wide ban on mobile devices. However, this is a challenge to implement due to the popularity and convenience of these devices. Plus, even with a restrictive policy on mobile devices, users will sometimes accidentally or intentionally bring them into the workplace. So mobile device prohibition will not be effective without other security measures.

A second option is to implement a BYOD (bring your own device) policy. This sets up a bit of freedom for users to bring in their own devices but establishes minimum security feature requirements that users will have to comply with in order to use their own devices on or with the company's IT infrastructure. Some BYOD policies even list specific makes and models of devices that are allowed, and ban all others not on the list. Such policies should focus on encouraging employees to use mobile devices with security features and set up and configure those features properly, and the organization should provide user training to assist in reducing risky activities and behaviors.

Tip:
Bring your own device policies do not always work, because the wide range of devices that are available and the fact that the user/owner retains administrative control renders this solution somewhat suspect. Some BYOD endeavors are implemented to reduce the liability or cost of providing workers with company-owned devices, which end up being damaged or lost frequently because workers might not respect the devices as much when they are not responsible for their replacement or repair.

One of the most important on-device features to be recommended for mobile devices is encryption. On-device encryption for mobile devices has only recently become a fairly standard feature. However, most devices that support on-device encryption do not have the feature enabled by default. So it is important to not only select devices that support encryption but to actually implement the feature.

When selecting a device with encryption features, be sure to take note of what type of data is and is not encrypted by the device. Some devices only encrypt the native software and not user data, some encrypt only user data and not native software, and still others might encrypt everything stored on the device. Some devices will encrypt the built-in storage but not encrypt expanded storage, such as that provided by memory cards.

For mobile phones supporting encryption, the screen lock feature should be enabled with a password or other secure credential in combination with device encryption. This will prevent a hacker from being able to use a connected cable to access the contents of the mobile phone when the screen is locked. Only when the screen is unlocked is access granted through the USB port to the storage volumes of the mobile phone.

If a mobile device does not provide native or on-device encryption and if the device can be mapped as a storage device on a computer, it might be possible to implement individual file encryption or full-disk encryption on the device. However, this could also prevent the device from working normally when it is not connected to the computer hosting the encryption software. Perform testing before making this a standard practice. If you only encrypt the user data on such devices and avoid encrypting any system files, this should not cause a problem for normal device operation.

It is important to reiterate that encryption is only a partial solution to data loss or malware distribution. Many other security elements must be implemented both in policy, on the device, and in user practice.

[Previous] [Contents] [Next]

In this tutorial:

  1. Data Security
  2. Data Encryption
  3. Database Encryption
  4. Hardware-based Encryption Devices