Which is the encryption method performed on removable data drives?

Encryption Methods for Data at Rest

Disk encryption software can be broken down into three high-level categories:

File- or folder-level encryption

Full disk encryption

Database encryption

Let's examine the advantages and disadvantages of each as you consider how and where they might fit into your program for protecting cardholder data.

Full-Disk Encryption

Full-disk encryption (FDE) or “whole disk” encryption methods encrypt every file stored on the drive (or drives), including the operating system/file system. This is usually done on a sector-by-sector basis. A filter driver that is loaded into memory at boot encrypts every file as it is written to disk and decrypts any file that is moved off of the disk. This happens transparently to the end user or the application generating the files.

Advantages:

■

Everything on the drive (or drives) is encrypted, including temporary files and swap space, increasing security of all your data, not just card data. If deployed on all in-scope systems, the card data would be guaranteed encrypted.

■

Encryption of data is enforced on end user, alleviating decisions on what or what not to encrypt.

■

Encryption/decryption is transparent. When information needs to be accessed, it can be saved off the system and is automatically decrypted. If a processing application is installed on the system, the use of encrypted data is also easy.4

■

Since all data on the drive is encrypted, even if an alternative boot medium is used against an encrypted system, the data on the drive is unreadable and therefore useless to the thief. Thus, card data is protected even when the system is turned off.

Disadvantages:

■

Some FDE programs can cause an increase in data access times. Slight delays in writing and reading data can occur, especially with very large files and high transaction volumes.

■

System password management and key management processes have to be defined and put into place. If a user loses his password that grants access to the encrypted system, he has no access to his data at all. Key management procedures defined in Requirement 3.5 are more critical for full-disk encryption. By the way, as per 3.4.1, “Decryption keys must not be tied to user accounts!”

FDE is more suited to protecting data on workstations and mobile devices, whereas file-level encryption is more useful as a method on large-volume storage devices. The much publicized cases of database managers or analysts putting thousands of clients at risk because a laptop was stolen that had been used to download large volumes of sensitive data from a storage device only serve to demonstrate this fact.

Figure 6.3 illustrates the difference in architecture between file-level encryption and FDE.

Figure 6.3. File-based Encryption versus Full-disk Encryption

BitLocker Drive Encryption, included with the newer Microsoft operation systems Windows Visa and Windows 7, is the primary example of such technology. Additional encryption products can be used as well. For example, TrueCrypt is a free, open-source disk encryption software for Windows, Linux, and even MacOS, which can perform full-disk encryption. It can be found at www.truecrypt.org. The latest PGP Whole Disk Encryption (www.pgp.com) is not free but is found in frequent use.

Tools

Before you reach out for the encryption tools, remember and repeat the mantra: “Do I need to keep this data?”

Free notable encryption file and disk tools are as follows:

■

The most popular and widely used tool GnuPG from Free Software Foundation can be found at www.gnupg.org. It performs efficient file encryption using symmetric and public key cryptography and works on Windows and Unix operating systems.

■

TrueCrypt is another free open-source disk encryption software for Windows, Linux, and even MacOS. It can be found at www.truecrypt.org. It can perform file, folder, and full-disk encryption.

Locked Computers

Considering that whole disk encryption is employed with high-tech suspects, and that entire cases depend upon seizing computers in an unencrypted state, the window of opportunity to successfully seize the systems in unencrypted states is small. Even when a computer is being used by the suspect, such as in a library, the odds that the suspect will detect surveillance and activate antiforensic methods such as encryption or locked screens are great. A computer system can be locked with a keystroke or set of keystrokes in less than a second, and in that second, the entirety of threads of communications in chat logs, e-mails, and other electronic evidence can be locked, encrypted, or wiped.

Just as investigators gauge their actions by predicting the reactions of suspects, the opposite is also true. Suspects plan their reactions based on their predictions about investigators. Some examples include the obvious measures of entering a set of preplanned keystrokes to lock or shutdown a computer (even pressing the power button), or ejecting the operating system if running on a DVD such as Tails when confronted by law enforcement. Ejecting an operating system on CD/DVD will usually cause a crash or automatic shutdown of the system, with some systems able to wipe the live memory to prevent capture as evidence as it shuts down. The takeaway here is that the suspect’s hands must not touch the system or mouse at all, regardless of any promise to provide passwords later.

Antiforensic methods to encrypt or lock the computer can also be inadvertently set in motion by investigators during seizure. One example is a laptop without a battery. Laptop users routinely use laptops without power cords because of long-lasting batteries. However, if a laptop battery has been removed by the suspect and the power cord is disconnected during seizure by investigators, whole disk encryption effectively has been activated by the investigator when unplugged, either intentionally or accidently.

Another antiforensic method or locking computers is using a USB device that is required to be connected to a computer for the computer to be unlocked. One such device is Predator (http://www.predator-usb.com/predator/en/index.php). Predator is a USB access control device that, once unplugged from a computer, results in the computer screen being locked. Similar USB devices can be used to automatically shut down the computer or start wiping the hard drive if removed. Again, this can be intentionally initiated by the suspect or unintentionally by investigators. Even pulling a suspect away from a computer to prevent any keystrokes could result in pulling out a USB device that has been attached to the suspect with a string or wire used as a safety measure by the suspect. In the case with Ross Ulbricht, had he used a USB protection device while at the library, the agent grabbing his laptop could have inadvertently activated antiforensics if such a USB device had been there and pulled out.

Whole-Disk Encryption

☑

BitLocker provides whole-disk encryption features for Windows Vista’s boot drive.

BitLocker with TPM enabled provides protection based on the Static Root of Trust Measurement, to prevent out-of-OS modification of boot components.

BitLocker’s command prompt control script, manage-bde.wsf, allows whole-disk encryption of partitions other than the system partition (which should never be encrypted).

You can store BitLocker’s recovery password in a number of ways: to Active Directory Domain Services, printed, stored to a network folder, or saved to a USB key.

Starting an OS on an Encrypted Volume

When implementing a full volume/disk encryption solution, you face a dilemma: an operating system on an encrypted volume cannot boot until its boot files are decrypted; so, the key has to be available before the OS loads a user interface. Obviously, that key cannot be stored on the encrypted disk itself; that would be like locking your car keys inside your vehicle to keep them safe. And you do not want to store it on an unencrypted partition on the hard disk; that would make it available to unauthorized persons and negate the purpose of encryption.

The solution is to store the key externally. There are several approaches: If the computer has a TPM, the key can be stored there. Because the TPM is embedded in the motherboard, this means that if someone removes the hard drive from the computer and puts it in another one, they cannot decrypt the disk without the key. The down side of this is that if the motherboard/TPM should experience hardware failure, you might not be able to decrypt the disk—unless you have another recovery key stored elsewhere. If you move an encrypted drive to a new computer, install a new motherboard (with a new TPM), disable the TPM, or make changes to the boot configuration settings or the BIOS/EUFI; the TPM may see this as a failure of the integrity check and your drive will not be decrypted.

If the computer does not have a TPM, or even if it does, another place that you can store the decryption key for FVE is on an external removable drive such as a USB flash drive. Other alternatives that may be implemented by some FVE programs include storing the key on a smart card (which, of course, requires a smart card reader), a biometric authentication mechanism (which requires a fingerprint scanner or other bio reader device), or retrieving the key over the network during the Preboot Execution Environment (PXE) process.

BitLocker allows you to use a TPM and/or an external USB device. You can set a PIN on the TPM so that, in combination with the USB flash drive, you have multifactor authentication. Note that although you can use BitLocker without a TPM, you will not get the added security of verification of system integrity prior to startup. If the integrity check fails, BitLocker is placed in recovery mode, where you can use a recovery key to decrypt the volume.

Disk Encryption

Disk encryption prevents a disk drive, such as a hard drive in a laptop computer or a portable USB storage device, from booting up unless the user inputs valid authentication data. The standard process for booting up an operating system is that the first section of the disk, called the master boot record, instructs the system where to read the first file that begins the instructions for loading the operating system. There are then no special instructions needed for interpreting the contents of the disk—files are in plaintext by default. Installing a disk encryption technology modifies this process.

When disk encryption is installed, the contents of the disk—except the master boot record and a small system that it loads—are encrypted using any suitable modern symmetric cipher by a secret key. The master boot record is modified to first load this small system, which can validate authentication information from the user. If the user authenticates successfully, the encryption key is unlocked. This small system, which varies per implementation, contains the master key for the device encrypted to one or more keys based on the authentication information, which can be a password, a fingerprint scan, a public key–based token, etc. When the valid authentication information is read, it can decrypt the master key. This master key then remains in the computer’s memory for the duration of power-on so that the operating system can first read itself from the disk to boot up, and then any other disk contents the user requests during operation of the computer.

There are a variety of implementations of whole disk encryption. One open-source implementation is Linux Unified Key Setup-on-disk-format (LUKS; http://code.google.com/p/cryptsetup/), which is the standard for most flavors of the Linux operating system. Hardware-based disk encryption technologies also exist, in which the disk drive itself contains the small authentication system as part of its firmware or device driver [27]. Software solutions such as LUKS are flexible and allow the defender to encrypt existing disks that are not specially built. Intuitively, there seems to be greater possibility for user misconfiguration of software solutions because of this added flexibility, which is a potential problem. But in general, there are two weak points of disk encryption solutions:

If the computer is powered on, including in sleep mode, the disk encryption keys are available to an adversary who can access system memory.

It is only as strong as the authentication method used, and human users are known to select poor passwords if they are permitted to do so.

These weak points are not serious. They simply demonstrate that full disk encryption, like any other security strategy, is not sufficient in itself to protect data. Other strategies can be used in coordination with disk encryption to provide a more comprehensive strategy. In particular, file encryption as discussed earlier and strong user authentication as discussed in Chapter 7 directly address these two weak points and help to formulate a comprehensive resistance strategy.

Disk Encryption

Another endpoint security product found with increasing regularity is disk encryption software. Organizations have often been mandating the use of whole disk encryption products that help to prevent the compromise of any sensitive data on hard disks that fall into unauthorized hands, especially on mobile devices, which have a greater risk of being stolen.

Full Disk Encryption (FDE), also called Whole Disk Encryption, encrypts an entire disk. This is superior to partially encrypted solutions, such as encrypted volumes, directories, folders or files. The problem with the latter approach is the risk of leaving sensitive data on an unencrypted area of the disk. Dragging and dropping a file from an unencrypted to encrypted directory may leave unencrypted data as unallocated data, for example.

Disk Encryption

A number of encryption programs are available that provide whole disk encryption, a common one being PGP from PGP Corp. These types of encryption programs encrypt all the data on the hard drive and are generally transparent to the user; meaning that one password in the startup sequence “unlocks” the contents for viewing and editing. Of course, the Windows Vista operating system incorporates BitLocker Drive Encryption tied to the Trusted Platform Module (TPM) cryptographic chip in the higher-end versions of the operating system.

Whole disk encryption has some serious implications for law enforcement when performing seizures. First, if a whole disk encryption is enabled on a running computer, and the computer is shut down or the power is removed, there is a very good chance that the data on the drives will be unrecoverable without the proper key. Responders may need to determine whether a whole disk encryption program is enabled before shutting down/pulling the plug on a computer during seizure. If one is present, bringing the computer back to the lab for analysis may be futile. One of the best chances to retrieve the evidentiary information is when the machine is running and the user has access to the files. Second, the implementation of the TPM chip may lock the drive so that the data may become available on only a specific machine. This would prevent an image of the drive from being booted in another computer or viewed with a computer forensic program. The use of disk encryption is forcing law enforcement to have other data seizure options available beyond the seizure of physical hardware.

6.1 Adjusting Needs

As at the end of the first round of live testing, it is common to find that this process uncovered additional needs that you didn’t know you had. If the needs are at a fairly high level, such as finding out that availability is much more important than you had thought, simply adjust the weighting of the more important variables to account for this. Then check your first run and make sure that the vendors that made it onto the short list are still the right ones. You may have to go back and do some more deep tests to make sure.

If your situation is more complex, you will probably need to adjust your scenarios and revisit previously tested systems. This may require increasing your testing time for all deep-tested vendors and adding new vendors to the list. If so, this is the point where you can throw the time-bound testing out the window as, at this point, it’s pretty hard to get value from that sort of restricted fairness.

If you were using scoresheets, you may need to update the scenarios and run your people through another round of limited testing. If you were using surveys, be careful that the update process doesn’t purge your previous data. It may be best to just create a new survey and combine the results later.

In the end, you should be able to look at your data and score it the same way you did in round one. Once scored, everyone on the team should be able to look at the resulting score and agree that it’s fair. Make sure this is true before proceeding. If any member of the team disagrees with the resulting score, go back to through the data and identify where the discrepancy came from. Avoid the lure of adjusting the weights to make the results turn out the way you want. Instead, if anything needs to be adjusted, have a frank discussion about what was missed and why. If the team agrees that it is important enough to go through a third round of Deep Testing, go the third round. If it is not, it is best to let the results stand as is. To do otherwise is to wind up with a solution that does not meet your needs.

Success at this point is as much social and political as it is technological. If, for example, most of the team prefers Vendor A but the operations manager prefers Vendor B and the selected tool is critical to that team, the issues had better be worked out before anything is purchased and implemented. Otherwise you risk investing a lot of money and time into a solution that could be passive–aggressively killed after implementation.

Examples of situations in which items may be missed include:

You are assessing a disk encryption technology on your existing hardware, but at the same time, the corporate contracts team is exploring replacing laptops with Android tablet devices. This should shift the project to testing encryption on another operating system.

You are assessing a new organization-wide printer refresh, but management is exploring document imaging. This would require a complete pivot of the project, as there could be substantial reduction in the features needed on any new printers.

You are assessing a new document management system to streamline processes for Human Resources (HR) but had forgotten to include a member of the recruitment team in the process, relying instead on the opinions of the HR Director. Because that person will not be using the system, your tests of Utility were incomplete and must be redone.

You are assessing accounting systems based on your current needs but have forgotten to include the needs of a recent acquisition who bills in advance of services rendered as opposed to after. This would require your accounting system to handle both modes of operation and, more importantly, prevent double-billing as a result of human error from individuals confused between the two systems.

1.1.1 Identifying Vendorspaces

Vendors tend to create spaces for themselves in markets. This makes it easier for prospects to find them, but it also restricts the way in which you think about them. A vendor solidly branded in one “vendorspace” is less likely to be considered outside of it, regardless of how well they may fit other needs. This is made worse by analysis firms who like to say things such as “Vendor X should pick a market and dominate it instead of trying to be everything to everybody.” So, while vendorspaces can be very useful in identifying candidates, keep in mind that the goal in selecting a vendor is to meet a business need, not to pick the “best” candidate on someone else’s list.

In most cases, you will be searching within a well-known vendorspace, such as “disk encryption vendors” or “intrusion prevention vendors.” However, vendorspaces have life spans. For example, text-based word processing tools were once incredibly popular, however, that vendorspace has contracted and the winners, Microsoft Word and WordPerfect, were migrated into graphical user interfaces. Along the way, tools like AppleWorks and WordStar died out. Thus, if you are exploring a vendorspace that is near the beginning or end of its life cycle, your choices within that space will be more limited and you may need to look further afield to solve your problem. Knowing this will help you identify when you have a reasonably complete list of candidates.

Vendorspaces near their end are fairly easy to identify. Any technology that is referred to as “old school,” “legacy,” or “dead” likely reflects a contracting vendorspace. This isn’t necessarily bad; after all, there are still a lot of people using legacy mainframe technology. However, there will likely be few newcomers in those spaces, so you can shortcut this phase of the process as there will be less discovery involved.

Vendorspaces near the beginning of their rise are harder to work with. Not only are there not many vendors in them, but there will be significant disagreement between vendors as to whether or not they are in the space and whether that space even exists. At the time of this writing, the Unified Threat Management (UTM) and Next Generation FireWall (NGFW) vendorspaces have effectively merged and a new “Intelligent Threat Management” (ITM) vendorspace may be beginning to emerge. This means that while vendors such as Fortinet, Sophos, Watchguard, and PaloAlto fight with one another for dominance over the merged UTM/NGFW vendorspace, other vendors such as Barrier1 and MetaFlows choose not to compete there and instead are creating the new ITM vendorspace. This happens because, as these firms provide innovative approaches to problems, they are not exactly NGFWs or UTMs and may look fairly rough when compared to polished examples from those vendorspaces. However, because their own vendorspace hasn’t fully materialized yet, their new capabilities aren’t truly understood by prospective customers.

The primary rule in vendor assessment and selection is to always keep your needs first in mind. Then, if one vendorspace doesn’t clearly solve your problems, you will have to consider several and look to the overlap. Before you can start exploring, you’ll need a map. To make this map, consider all ways that your problem can be solved and build a list of possible solution types. This will help guide you to specific vendorspaces, so you can decide which ones you will be focusing upon.

Privacy and Authentication

Two important questions concerning assets are whether the asset is private and whether it has to be intact. For example, many disk encryption users apply the tool to their entire system drive. Many system files are universally accessible as part of the install media. They are in no way private assets, and applying cryptography to them is a waste of resources. Worse, most systems rarely apply authentication tools to the files on disk (EncFS is a rare exception to the lack of authentication rule. http://encfs.sourceforge.net/), meaning that many files, including applications, that are user accessible can be modified. Usually, the worse they can accomplish is a denial of service (DoS) attack on the system, but it is entirely possible to modify a working program in a manner such that the alterations introduce flaws to the system. With authentication, the file is either readable or it is not. Alterations are simply not accepted.

Usually, if information is not meant to be public it is probably a good idea to authenticate it. This provides users with two forms of protection around their assets. Seeing this as an emerging trend, NIST and IEEE have both gone as far as to recommend combined modes (CCM and GCM, respectively) that actually perform both encryption and authentication. The modes are also of theoretical interest, as they formally reduce to the security of their inherited primitives (usually the AES block cipher). From a performance point of view, these modes are less efficient than just encryption or authentication alone. However, that is offset by the stability they offer the user.