Why Encryption Might Not Stop Data Theft

Several high-profile data exfiltrations have been in the news. Some examples are RSA Security (SecurID), Sony, and Epsilon. In each case, hundreds of thousands to hundreds of millions of personally identifiable information (PII) records were stolen. I’m guessing that a whole lot of CIOs and CSOs are sitting back and thinking, “My data is encrypted so I don’t have to worry about this happening to me.” Well, it’s time to wake up and smell the coffee, since data encryption may not protect your data from theft or disclosure. Let’s look at the places where data encryption can be implemented and the protection that they offer. I am only going to address two different encryption injection points in this post. A more extensive treatment of this topic appeared in the December 2009 issue of The Connection, a journal for the HP business technology community .

• Full disk encryption (FDE) at the hardware or storage array level only protects data when the disks are powered off. As soon as the disks are powered up by an authorized user, the data on them is decrypted and available to anyone that can connect to the volume. FDE ensures that your data is protected if the drives are shipped from one location to another, sent back to the manufacturer for spare or upgrade exchange, or when the drives are sold or repurposed. FDE also acts as a backstop in case higher level encryption is not enabled either by accident or on purpose. When the drives are powered on, anyone that can gain access to them via the storage network or any attached computers has unfettered access to the information on them. This is also true of laptop FDE implementations; unless the laptop is powered off, the data is not protected. How often do you actually power off your laptop versus putting it in a sleeping or hibernating state? Macintosh computers offer FileVault which uses encrypted file systems that are mounted and unmounted when the user logs into or out of the system. This protects a user’s home folder as long as the user is logged off, even if the machine is not powered off.
• NAS or SAN encryption adds additional protection because data is encrypted from the time it hits the first network switch. Depending on the functionality of the solution that you choose, administrators may be able to use unique encryption keys and enforce policies at the LUN, client, department, group, and user level; and at the server instance and share level. This means that data can be isolated to specific computers and users. Your data is a lot safer than it would be with FDE as long as the proper separation of duties are in place, and this is the topic of today’s post.

NAS and SAN Encryption Versus FDE

The most secure encryption system in the world is totally useless if a hacker can get to the data as an authorized user. While I don’t know the inside stories when it comes to any of the recent hack attempts, a plausable attack scenario runs goes something like this:

1. A hack point is found into a targeted organization’s network through targeted probing or an advanced persistent threat (APT).
2. The attacker gains access to one or more accounts on one or more computers on the network and uses this access to determine which computer or storage module has access the data he is interested in.
3. The attacker gains escalated privileges on the computer and now has access to the targeted files.
4. The files are exfiltrated and the attack is over.

Remembering that FDE drives are decrypted as soon as they are powered up, the attacker may be able to stop at step 2 since he does not need to target a specific system, but can use any system that has access to the disks holding the data he is interested in.

For information that is NAS or SAN encrypted, the attack can be much more difficult since specific data can be encrypted and secured to specific accounts and computers. That is, only a specific account on a specific computer has the ability to view the decrypted data. Now the attacker not only needs to find out which computer has access to the data he wants, he also needs to find out which account(s) have access to the data. If proper separation of duties is implemented, gaining elevated privileges may not help the attacker.

Separation of Duties

Proper separation of duties includes the following:

• The Root or superuser account should be locked away and never used except in case of dire emergency
  • The root account should be prevented from logging on to any other account without using a password or changing the password of any other user
• One or more security administrator accounts should be created, each with specific, limited authority
  • The administrator who can create, roll, and alter security logs has no other system access
  • The administrator who can modify security subsystem settings cannot access the logs, nor modify user settings
  • The administrator who can modify user security settings cannot alter the security subsystem nor access the logs
• System, backup, and application accounts should all be separated.
  • The administrator who can back up and restore files and databases should not be able to read and write them
  • The administrator who can start and stop applications and databases should not be able to access them
  • Applications and databases should be owned by “frozen” accounts. This will help prevent anyone from logging on to this account where they might have full access to an application or database.

Through the judicious use of separation of duties along with a dose of protecting your files and databases by encrypting and securing them to specific users and computers, you have created an environment that provides defense in depth to your critical applications and data. These settings will make access to applications and data much more difficult for a attacker because they shouldn’t be able to login to the accounts that own the applications and databases.

And to increase the overall security of your encryption, ask if the keys are generated and stored  and if the encryption is performed in FIPS 140-2 Level 3 validated hardware. I have an article on this topic pending publication and will post it as soon as I know where it can be accessed.