I’m in the process of working with a customer who is running Gazzang zNcrypt on their database server. This customer’s business has nearly doubled in size in just a few months. While that’s great for the organization, it puts a strain on IT. For example, their production database is now twice as large as it used to be and is quickly running out of space.

This customer reached out to us to make sure their encrypted files remain secure, as they’re transferred to an area with more disc space. Read on to see how we helped them out:

First let’s look at a typical server with a data directory encrypted with zNcrypt. When you encrypt your data with zNcrypt, the data is moved to the Gazzang folders, encrypted as it is written there and a symbolic link is put in place at the original location of the data.

ubuntu@ip-10-202-47-92:~$ ls -l /var/lib/mongodb
lrwxrwxrwx 1 root root 51 2012-07-19 20:35 /var/lib/mongodb -> /var/lib/ezncrypt /ezncrypted/mongo//var/lib/mongodb

The default location for the zNcrypt folders is in /var/lib/ezncrypt where we have 2 directories, as you can see below. /ezncrypted is a virtual folder used to facilitate our process-based access controls. Finally, /storage is where the physical encrypted files are stored.

ubuntu@ip-10-202-47-92:~$ ls -l /var/lib/ezncrypt
total 8
drwxr-xr-x 3 root root 4096 2012-07-19 20:30 ezncrypted
drwxr-xr-x 4 root root 4096 2012-05-11 03:29 storage

Our goal was to relocate the /var/lib/ezncrypt directory to a new location with enough space to allow the database to continue to grow with the business.

Below is a list of the several steps we needed to follow to ensure everything would function properly after relocating the directory.

The steps are:

1. Stop the “trusted process” defined in your ACL Rules (I am using MongoDB in this example).

ubuntu@ip-10-202-47-92:~$ sudo service mongodb stop
mongodb stop/waiting

2. Stop the zNcrypt service.

ubuntu@ip-10-202-47-92:/var/lib$ sudo ezncrypt-service stop
  ezncrypt | Checking system dependencies
  ezncrypt | WARNING: ezncrypt service will be stopped.
           | Continue? (y/N) y 
           | Are you sure? (y/N) y
  ezncrypt | stopping service
           | done!
       log | File: /var/log/ezncrypt/ezncrypt-service.log

3. Edit the /etc/ezncrypt/ezncrypt.conf file to reflect the new mountpoints for the virtual directory where ezncryptfs & ecryptfs are mounted, DIR_VIRTUAL, and private directories where data is stored encrypted & unencrypted, DIR_PRIVATE_ENCRYPTED and DIR_PRIVATE_NONENCRYPTED.
   
   **Below shows the 3 lines inside ezncrypt.conf that need to reflect the new location for your /ezncrypt directories.

ubuntu@ip-10-202-47-92:~$ sudo vi /etc/ezncrypt/ezncrypt.conf

#
# Example of ezncrypt.conf
# 
.
.
.

# virtual directory where ezncryptfs & ecryptfs are mounted
DIR_VIRTUAL=/newdisk/ezncrypt/ezncrypted

# private directories where data is stored encrypted & unencrypted
DIR_PRIVATE_ENCRYPTED=/newdisk/ezncrypt/storage/encrypted_private
DIR_PRIVATE_NONENCRYPTED=/newdisk/ezncrypt/storage/unencrypted_private

# encryptiong algorithm used by eCryptfs
CIPHER=aes_256

4. Move the entire /ezncrypt directory from it’s current location to the new disk.

ubuntu@ip-10-202-47-92:/var/lib$ sudo mv ezncrypt /newdisk
ubuntu@ip-10-202-47-92:/var/lib$ cd /newdisk
ubuntu@ip-10-202-47-92:/newdisk$ ls -l
total 4
drwxr-xr-x 4 root root 4096 2012-05-11 03:29 ezncrypt

5. Delete the old symlink that zNcrypt was using and create a new link pointing to the new location of the directory. Below shows the OLD symlink and creating the new link for our server.

drwxr-xr-x  2 root      root    4096 2012-09-26 06:25 mlocate
lrwxrwxrwx  1 root      root      51 2012-07-19 20:35 mongodb -> /var/lib/ezncrypt/ezncrypted/mongo//var/lib/mongodb
drwx------  5 mysql     mysql   4096 2012-09-26 17:53 mysql
drwxr-xr-x  2 root      root    4096 2011-03-10 21:16 ntpdate   

First delete the old link seen above:
ubuntu@ip-10-202-47-92:/var/lib$ sudo rm mongodb

Then recreate the symlink pointing to the new directory:
ubuntu@ip-10-202-47-92:/var/lib$ sudo ln -s /newdisk/ezncrypt
/ezncrypted/mongo/var/lib/mongodb

6. Finally, restart zNcrypt first, then start your “trusted process” defined in the ACL Rules. (see below)

ubuntu@ip-10-202-47-92:/var/lib$ sudo ezncrypt-service start
  ezncrypt | Checking system dependencies
  ezncrypt | checking encryption directories
    keymgr | Retrieving key from KSS
           |  > Encryption password retrieved from KSS
  ezncrypt | starting service
           |  > using "aes_256" cipher algorithm
           | done!
    access | Loading access control list
           | done!
  ezncrypt | Thank you for using ezncrypt.
       log | File: /var/log/ezncrypt/ezncrypt-service.log   


**Start the “trusted process”**
ubuntu@ip-10-202-47-92:/var/lib$ sudo service mongodb start
mongodb start/running, process 2937

I hope this tutorial was helpful. For more information on Gazzang data security solutions, please email us at info@gazzang.com.

In my last blog, I posed a common question that we get from our customers and prospects. “How do I rotate my Master Encryption Key in Gazzang zNcrypt if an admin leaves the company, or because our company key rotation policy?”

The most common way to rotate your Master Encryption Key is by using the “Passphrase Method.” Administration is simply using this technique, and there is no “file” that has to be managed. But as I mentioned in part one, to change the passphrase in zNcrypt, you must first decrypt all your data, then change the passphrase before re-encrypting with the new passphrase. This is not the most desirable method if you have a policy that requires regular key rotation.

So what do you do if you have to change the key in some way, but don’t want to decrypt / re-encrypt? In this blog, I’m going to show you how to use the RSA Key file method for your Master Encryption Key in zNcrypt.

Before setting up zNcrypt with the RSA Key file method, you need to have a key file ready to designate as your Master Encryption Key. Here’s a way to easily generate an RSA Key file:

bitnami@ip-10-110-221-104:~$ ssh-keygen -t rsa -f zncrypt-key.pem
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): Enter same passphrase again: 
Your identification has been saved in zncrypt-key.pem.
Your public key has been saved in zncrypt-key.pem.pub.

The key generation command above, highlighted in yellow, will generate a 2048-bit RSA Key pair. zNcrypt only needs the “.pem” file where your identification has been saved.

Note that we don’t use the public key in this scenario, as your zNcrypt client and the Gazzang KSS will manage the authentication process during the times these two systems communicate.

I highlighted (in blue font) the step where you enter an “overlay passphrase” for the RSA Key file. I will explain the advantages of this configuration shortly.

One of the last steps during the zNcrypt configuration and activation process is to create your Master Encryption Key for the server. Choosing option 2) RSA, will generate a prompt similar to what you see below and will ask you to provide the .pem file as your Master Key.

           |  Key options available
           |  1) passphrase
           |  2) RSA
           | option: 2
           | type RSA private key file: /home/bitnami/zncrypt.pem
           | 
           | RECORD AND STORE THE FOLLOWING PASSPHRASE/SALT IN A SAFE PLACE
           | 
           | Passphrase: YazpSU4tyu697KBZYBCFEptJUw1BhFf
           | Salt:       d0C70956k79CF0D4
           | 
           | Press ENTER to continue
       RSA | wrapping encryption/decryption key
           | enter RSA passphrase: 

Let’s run through the process on my server, an instance on the Amazon EC2 Cloud where I am running a single MongoDB node. Currently, my MongoDB data folder is fully encrypted, and I’m using the RSA Key file method for my Master Encryption Key. It is set to the original key file that I set up on this system a month or two ago.

STEP 1 – The first step for the RSA Key file method is different than what we did for the Passphrase method discussed in my previous blog. An advantage of the RSA Key file method is you do not have to decrypt all your data before making a change. The reason this works is you can simply rotate the “overlay passphrase” you created when assigning the RSA Key file as your Master Encryption Key.

Run the ezncrypt-change-key command as seen here. Then follow the prompts to change the overlay password:

bitnami@ip-10-110-221-104:~$ ssh-keygen -t rsa -f zncrypt-key.pem 
Enter old passphrase: Key has comment 'zncrypt.pem' 
Enter new passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved with the new passphrase.

STEP 2 – There aren’t any other steps! You can easily change the RSA overlay passphrase when needed, but you don’t have to change the underlying encryption. In other words, you do NOT need to decrypt/re-encrypt if you only change the passphrase.

If you have any other install or configuration questions, send us an email at info@gazzang.com.

How and where we work is rapidly changing. Gone are the days where employee access was tied primarily to the corporate network. Instead logins are happening far more frequently outside the corporate firewall making access controls more difficult to protect.

Each of these servers or services requires a login, and each of those logins represents an opportunity for a hacker, cybercriminal or enemy nation. It happens all the time, and not just to user IDs and passwords but also to private key files that may provide login entry and access to sensitive information.

One effective method for battling malware, rootkits and other forms of cyber attack is two-factor (or multifactor) or dynamic authentication. Traditionally, two factor refers to something you know (your password) and something you have (a smart card). A drawback of smart cards, however, is they typically serve a limited purpose; usually to log into your corporate network. On top of that they are generally a hassle to keep track of and replace. Simply put, they’re not flexible enough to serve as a two-factor solution outside the corporate environment since so many other logins lack smart card integration.

Fortunately, there’s a better way to implement two- and even multi-factor authentication. In this blog, we’ll explore how Gazzang zTrustee can provide multifactor authentication for a Linux server. For any Linux server that's in the cloud or in your enterprise, typically the login uses SSH (secure shell) as it provides a secure channel. Current login methods involve a user providing a username and then either a password or a private RSA or DSA key. That’s one factor and fulfills the “something you know” requirement.

To improve on that, zTrustee can provide multifactor, by blocking that login until a second factor is provided. In this case, the second factor is a “trustee,” a person – or in some cases an application – that can authorize or deny the login access, through the release of an added key, without ever having access to the key.

Adding a trustee as a second factor onto a Linux systems login process is simple and straightforward. An additional benefit is that it also incorporates a notification and audit trail. For example, let’s say a hacker somehow steals my credentials and attempts to log in as me. The zTrustee server will automatically notify the trustees (of which I am one) that access is being requested. I am notified to provide the second factor. Now, not only can I block the request, but I know about the attempted breach and can take steps to remedy it.

Think about how this can help you manage and control access by consultants or other partners to your systems. I can make myself the second factor for a consultant’s login. So I would get an alert whenever they login, and I can call them to make sure this is a legitimate session and then approve it via my cell phone. I can create multiple approval policies and even add trustees in case I’m unavailable to authorize (or deny) a session.

Taking this a security layer further, on a Linux system, users can login and escalate their privileges using “sudo”. zTrustee can add a second level of authentication when “sudo” is run - requiring trustee approval before users enter privileged status.

Cybercrime is a very serious problem. At the very least, it’s an incredible inconvenience. Just one extra barrier could stop a catastrophic breach. Gazzang zTrustee makes multifactor authentication a snap.

Tokenization is a process by which a value (usually something that needs to be kept private, secure, or anonymous) is replaced with another unique “surrogate” value called a ―token. And de-tokenization is the just the opposite – providing the token and receiving back the associated “actual” value.

Tokenized systems store and use these tokens in their main databases. Access to the tokens can be allowed broadly – so if your main DBA, developer, analyst, or even a hacker gets possession of the token – it’s of no value. That’s because the original value is stored in a highly secure, encrypted, access controlled vault with highly restrictive controls and workflows. Tokenization allows data to be manipulated, used and analyzed in a natural easy to use format, while providing a highly secured environment – via this data anonymity.

The PCI Information Supplement: PCI DSS Tokenization Guidelines refers to the use of tokenization for the protection of PANs (Primary Account Numbers) – your Credit Cards. “Tokenization is a process by which the primary account number (PAN) is replaced with a surrogate value. De-tokenization is the reverse process of redeeming a token for its associated PAN value.”

I want to show you how Gazzang zTrustee™ could act as a PCI tokenization solution. The PCI Information Supplement section 2.1.1 talks goes into a great bit of detail on Token Generation. Using zTrustee, there are at least 2 ways to create/generate tokens:

1. Generate the token yourself and pass this along with the PAN using the zTrustee “put” – the “put” stores the information in zTrustee Server which severs as the “Card Data Vault” to use PCI terminology.
2. Use the zTrustee UUID returned by the PUT. The UUID is a 43 characters [A-Za-z0-9]. 

Note: Gazzang’s zTrustee creates the UUID by reading 43 characters [A-Za-z0-9] from a secure random device. Those 43 characters represent a little over 1.18261x10⁷⁷ unique tokens that are guaranteed to be unique.  This represents what the PCI Tokenization guide refers to as “a one-way non-reversible cryptographic function”

Which method you use is up to you and likely depends on your data model and application.

The second bullet meets the guide’s criteria that “whichever generation method is used, the recovery of the original PAN must not be computationally feasible knowing only the token or a number of tokens.”

Token mapping is the process of assigning a token to the original PAN value. The key is to make that mapping highly restricted especially in regard to retrieving the original PAN value. As the guide states “The ability to retrieve a PAN in exchange for its associated token should be restricted to authorized individuals, applications, and/or systems.”

Gazzang zTrustee provides several ways to meet this “secure retrieval” requirement. When a token and PAN value is “put” (stored) into zTrustee you will specify policies related to that “put”.

There are many policies that are supported. The two you would likely use are:

1. Define the “zTrustee client(s)” that could retrieve the PAN. As shown in the diagram in the PCI tokenization doc, I can put the token from Client A (the POS (Point of Sale) application). By only defining Client B (another secure system/application for retrieving the PAN) in zTrustee you perform a PUT using the policy “–clients <Bs identifier>” – which means only Client B (not the POS but another system) could GET the token. Any request from another system is immediately rejected

1. Hackers or criminals that might get into the POS system have no method to request and retrieve a PAN from there.

2. Define a zTrustee “trustee” or set of “trustees” for the PAN. Any request for a PAN using a Token would require “votes” from one or more persons (the trustees), depending on how many votes you require. The more trustees, and the higher the number of votes, the more secure.

1. Even if hackers or criminals get on client B, which is unlikely, the trustees will “DENY” access.
2. Trustees are often actual people, but they can also be processes that inspect a request and “vote” to allow or deny, or a combination of both.

As you can see, zTrustee provides a clean tokenization solution that fits within PCI guidelines. The solution supports far more than tokenization, however. If you’d like to know more, please visit www.gazzang.com/products/ztrustee.

And keep an eye out for a follow-up blog with more details related to PCI and broader tokenization.

When I’m talking to customers (and future customers) about zNcrypt, a common question I get is, “How do I rotate my Master Encryption Key if an admin leaves the company, or because our company security policy says we must rotate encryption keys every quarter?”

Well, there are two answers to this question, and in this blog, I will give you the first answer. The second answer will follow in another blog very soon, so check back here often!

Most customers use the “Passphrase Method” for the zNcrypt Master Encryption Key. In zNcrypt, our passphrase is a 15 to 32 character password that is typed in during the initial configuration of the zNcrypt client on your server.

Because this passphrase IS the Master Encryption Key (and is what we store on the Gazzang KSS, our separate Key Storage System for your zNcrypt keys), the key change process does require a decryption and re-encryption of the data being protected.

Let’s run through the process on my server, an instance on the Amazon EC2 Cloud where I’m just running a single MongoDB server. Currently, my MongoDB data folder is fully encrypted and my passphrase is set to the original passphrase that I installed with when I built this server a few months ago.

STEP 1 – Decrypt the data before changing the Master Encryption Key (passphrase). Since the data is being used by the mongod process, I will stop MongoDB before decrypting. This is to ensure that no one is connected to my application or database. After stopping MongoDB, it’s time to decrypt the files. Here is what you will see:

bitnami@ip-10-244-51-139:~$sudo ezncrypt --decrypt @mongo /var/lib/mongodb
  ezncrypt | Checking system dependencies
           | getting information about location
           |   > path: /var/lib/ezncrypt/ezncrypted/mongo
  ezncrypt | Checking encryption status
           | done!
       key | Type your encryption/decryption key
           | type passphrase: 
           | type salt: 
           | generating keys	
           | done!
  ezncrypt | decrypting files
           |  > checking disk space
           |  > decrypting /var/lib/mongodb
           | done!
  ezncrypt | congratulations. you have decrypted your Files!!
       log | File: /var/log/ezncrypt/ezncrypt.log

STEP 2 – After decrypting the data, now you can run the ezncrypt-change-key command, which will walk you through the changing of the passphrase. You will be prompted to stop the zNcrypt service. Take the default “YES”.

bitnami@ip-10-244-51-139:~$ sudo ezncrypt-change-key
  ezncrypt | Checking system dependencies
  ezncrypt | Checking ezncrypt status
           | ezncrypt service is already running.
           | ezncrypt needs to be stopped in order to apply changes.
           | Do you want to stop the service? [Y/n]

zNcrypt will stop the service, then as an authentication step, you must type in the “old” passphrase to prove you’re an authorized user for zNcrypt. Enter your old passphrase (and optional salt).

 | Do you want to stop the service? [Y/n] 
           | Stopping ezncrypt service... Ok
  ezncrypt | Enter OLD key
       key | Type your encryption/decryption key
           | type passphrase: 
           | type salt: 
           | decrypting access control list

STEP 3 – Now it’s time to create your new Master Encryption Key. First select either 1) passphrase or 2)RSA. For the sake of this blog, I will stick with my original method, the passphrase. Enter the passphrase, re-type to verify, if you do not want the “Split Security” leave the salt blank , and you have now successfully changed your zNcrypt Master Encryption Key.

ezncrypt | Enter NEW key
       key | Type your encryption/decryption key
           | Key options available
           |  1) passphrase
           |  2) RSA
           | option: 1
           | type passphrase: 
           | re-type passphrase: 
           | type salt: 
  ezncrypt | Applying changes
           | Encrypting access control list... Ok
           | Changing passphrase... Ok
           | Starting ezncrypt service... Ok
  ezncrypt | Finished. Your encryption key has been changed.

All that remains now is to re-encrypt your sensitive data. You will use the exact same encryption command you used originally (this will also be very similar to the decrypt command used above.

SIDE NOTE: You can use the –n option in your encryption command (I did not use it this time). This is for “No Backup”, which means the encryption process will skip backing up the unencrypted files. If there are other means for restoring the data if something were to happen during the encryption process v, having zNcrypt make the backup file is not necessary.

bitnami@ip-10-244-51-139:~$ sudo ezncrypt --encrypt @mongo /var/lib/mongodb 
  ezncrypt | Checking system dependencies
           | Verifying ezncrypt license
           | getting information about location
           |   > path: /var/lib/ezncrypt/ezncrypted/mongo
  ezncrypt | Checking encryption status
           | done!
    keymgr | Retrieving key from KSS
           |  > Encryption password retrieved from KSS
           | generating keys	
           | done!
    backup | backing up data
           | This can take a while. Please be patient
           |  > backing up /var/lib/mongodb
           |  > File: /opt/ezncrypt/backup/2012-07-18/mongodb.tar.gz
           | done!
  ezncrypt | encrypting files
           |  > checking disk space
           |  > encrypting /var/lib/mongodb
           | done!
  ezncrypt | congratulations. you have encrypted your Files!!
       log | File: /var/log/ezncrypt/ezncrypt.log

That is all you have to do to change your “Master Encryption Key” when using the passphrase method.

Watch for my next blog where I will walk through the second method for changing your Master Encryption Key. Next time we’ll use the RSA Key File.

There’s a great Wall Street Journal blog by Rachael King on the increase in cyber attacks targeting privileged accounts. A recent survey she sites suggest 64% of IT administrators “believe that the majority of recent security attacks involved the exploitation of so-called privileged accounts.” These are access points built into devices by the manufacturer that make it easer for IT to manage the network. 

I’m a big proponent of multi-layer security that includes security controls not singularly tied to user identity or some proxy user identity method. This is particularly problematic at the OS level but certainly at the database and other levels as well.

In previous roles, I’ve worked with a number of developers and architects who believed OS-level file access controls granted to a user were good enough; that layered security wasn’t always necessary. I realize writing good crypto, key management, and other security code, or finding folks who can, is tough and expensive, but that’s not an excuse for failing to implement multiple levels of security.

There’s a reason your bank locks its doors, and then they lock the safe, and then they lock the safe deposit boxes. Security is about layers, and with virtualization, cloud, big data, and more, building out these layers becomes even more important.

Gazzang is focused on helping organizations secure big data in the cloud.  Our bread and butter is Unified Transparent Encryption through Gazzang zNcrypt. This solution encrypts sensitive data in Linux on the fly as it’s written to disc.  Access to that data is managed by our key storage system and process-based access control lists. We designed the system to limit OS and root privileges, preventing data from being stolen via “privilege escalation.” 

Speaking of layered security, I want to wrap up this blog with some additional thoughts on Gazzang zTrustee, which we announced earlier this week. Our chief architect, Dustin Kirkland, touched on this some yesterday, but fundamentally zTrustee focuses on securing and providing access to those keys, certificates, tokens and other “opaque objects” that act as the gatekeepers to sensitive information about your IT DNA.

This data, if it were to fall into the wrong hands through privileged accounts or other form of attack, could be disastrous to your organization. It’s not unusual to have robust policies governing access to keys, certs, tokens and passphrases, but what about some of the more obscure files or file directories like those containing ACLs or connection strings?

An interesting method of protecting this data is with the concept of a “trustee.” A trustee – often a person or group of persons but could just as well be a service or a combination of the two – control the release of keys and prevent “privilege escalation.”

As we bring zTrustee to market, I’m certain we’ll discover more use cases and continue to innovate on the trustee concept. If you’re interested in learning more, sign up for our free trial.

Backup is a very important component of data that is way too often misunderstood or ignored altogether. At least that's been my experience for several years now. From a security standpoint a backup – especially transportable “export/import” type backups that all databases offer in some form or another – presents an easy target for data theft.  Often that theft goes unnoticed or unreported. 

Just as many open source products, databases and data stores fail to offer transparent data encryption (TDE) to protect all the data in the database, so too do backups. “Unified Transparent Encryption” with Gazzang zNcrypt provides effective data encryption and key management for backup and recovery.

Last October, I wrote a blog called, Running a Secure (Encrypted) MySQL Backup Using mysqldump on Linux. The idea was to help zNcrypt users take some simple steps to protect their mysqldump jobs – securing the user/password credentials and the back files as well.  The blog grabbed the attention of MySQL guru and Oracle ACE Director Ronald Bradford, who wrote about it his latest book, MySQL Backup and Recovery Essentials.

Most often, a combination of backup types are needed to fully provide the high availability and disaster recovery needs. Fortunately, the benefits of Unified Transparent Encryption go beyond export/import or other native database backup utilities. Its also applicable to operating system and file-oriented methods.  With zNcrypt in place, applications read and write data in the same format as always – that’s the transparent encryption part. This is provided by a stack virtual filesystem.  The OS users can see these files, which are encrypted and secure.  Those files can safely be copied (backed up) and restored on another system. If that system has zNcrypt installed and the same key is configured, that data can once again be accessed via transparent encryption.

With this, data can be transferred in its encrypted form safely.  From enterprise to cloud, cloud to cloud, cloud to enterprise.  We’ve provided an example of this in prior blog. A number of Gazzang customers use this method via Zmanda based backups.

Taking this a step further, with something like DRDB or R1soft backup products that backup and synchronize at the block level, all the blocks are encrypted, the data is protected and as long as zNcrypt is installed with the same key on backup and recovery servers, it all works. 

Unified Transparent Encryption is very popular with Gazzang customers running big data. Value, flexibility, and ease of use are important for those big data architectures or search solutions like SolR where the same challenges exist. We’ll save those details for another blog, but certainly reach out if you need is imminent and we can share the secure data lifecycle as well with you.

Again, sensitive data is at risk anywhere it’s stored, backed up, exported, or imported.  Proper IT security involves mapping your data’s lifecycle and finding and remediating risks .  Encryption is a great security tool, but it can be hard to code and create on your own. Gazzang’s zNcrypt customers use the product day in day out to solve these challenges with simple and elegant Unified Encryption. If you’ve got a challenge that’s got you stumped, I’d be happy to have a look. Its amazing what Unified TDE can do.

The other day I was doing some research for this blog and ran across an article in SC Magazine from a few years ago. The title is “Securing data in motion vs. data at rest? It’s the wrong question!”In the article, he defines the following terms:

Data at rest refers to all data in computer storage. He then gives examples like employee’s hard drives, file copies stored on backup tapes (on site and off site), and files on network storage like SAN, NAS and file servers.

Data in motion refers to the transfer of that data between all these copies and versions of the original file, such as data traversing the Internet.

The author then goes into more detail on “data classification” and makes the point that if the data needs to be protected, and it doesn’t matter whether it is “at rest” or “in motion”. (I’m paraphrasing).

What I’d like show, is how you can protect your data at rest and in motion using Gazzang’s ezncrypt - without mind numbing complexity - by using Transparent Encryption and Key management. This solution creates encrypted files that are portable to any other machine just by running ezNcrypt with identical Passphrases/Salts or RSA Key Files on the 2 servers. In this example I even move data from across from Server A - Ubuntu – 10.04 32bit to Server B – Ubuntu 11.04 64 bit.

BTW - The method used to transfer the files from machine A to B is your choice – to keep this example simple– I just remote copy a tar file.

Here is how I was able to encrypt files on “Machine-A” and successfully “put those files in motion” - moving the encrypted directory over to “Machine-B”. We are going to using vi – as the example “trusted” - application only because its very easy to demonstrate this way. We know you won’t do this typically but its an easy what to show that we can have an application that only gets “transparently encrypted” access to certain files and those files are encrypted to all others users or processes. These could be mysql backup files for instance (for example see our blog on mysqldump) and we are moving them to another standby server.

1. On both machine A and B - Install ezNcrypt
   1. Request a download for ezncrypt here.
   2. Install ezncrypt
   # sudo install.sh

– for an example on installing go

here

.

1. Use matching Passphrases or RSA Key Files.
   1. For Passphrase – you simply enter the passphrase and salt during installation.
   OR

1. For RSA Key – (Note – do this before running install.sh)
   1. Create an RSA Key:
      1. # openssl genrsa 2048 > ./key-file-name.pem
   2. Copy this key-file-name.pem file to Machine B and used it for my installation there as well.

1. On Machine-A - Create a directory with some test files for this
   1. Create folders a
      1. # cd ~
      2. # mkdir code
      3. # cd code
      4. # mkdir myscripts
      5. # cp ./myscripts
I just used some the sql scripts from the mysql example database sakila and untared into the myscripts directory

1. On Machine-A - Encrypt that Directory – to “protect my scripts”
   1. Encrypted the myscripts folder
      1. # cd ~/code
      (Here mine is is in /home/mfrank/code and the directory is called myscripts so I #cd /home/mfrank/code)

1. # /usr/sbin/ezncrypt –encrypt @securescripts myscripts

1. On Machine-A - Create an ezNcrypt Rule
This rule enables me to encrypt files and where only the “vi” text editor can get key access and thus used to read their content – this is Transparent Encryption.
1. # sudo /usr/sbin/ezncrypt-access-control –a “ALLOW @secscripts * /usr/bin/vim.tiny”

1. On Machine-A - Test
   1. # vi myscripts/sakila-db/sakila-schema.sql
      This works as it should because vim.tiny is trusted
   2. # cat myscripts/sakila-db/sakila-schema.sql
   3. This fails because cat is not trusted. You can try other applications as well and they will fail.

1. On Machine-A - lets prepare to move the encrypted files – we will just tar, “remote” copy, and untar
   1. Copy the encrypted files –
      1. Create tar file of encrypted directory and its AES-256 encrypted files
      **creating a tarball file is just a very simple way to move a compressed archive of the original files – you might use scp or other method **
   
   
   Note the location - /var/lib is the ezncrypt default location– if you changed this during you installation use your location.
   1. # cd /var/lib/ezncrypt/.encrypted_private
   2. # tar -cvf myscripts.tar ./securescripts
   3. Remote copy myscripts.tar to Machine-B
   
   

   Note: All the files within the tar are AES-256 encrypted.

2. On Machine-B - ONLY if using RSA Keys – SKIP if using passphrase and salt.
3. 1. Shutdown ezncrypt
   #sudo /usr/sbin/ezncrypt-service stop
   
   
   1. # cd /var/lib/ezncrypt/.encrypted_private/
   2. # sudo rm .sigcache.ez
   3. From machine A
      1. copy/var/lib/ezncrypt/.encrypted_private/.wrap.ez
      and over-write the same file on Machine B /var/lib/ezncrypt/.encrypted_private/.wrap.ez
   
   
   1. Start ezncrypt
   #sudo /usr/sbin/ezncrypt-service start
4. On Machine-B - Untar the encrypted files from Machine A
5. 1. # cd /var/lib/ezncrypt/.encrypted_private/
   2. # tar -xvf backup.tar
6. On Machine-B - Create matching ezNcrypt Rule **just like in step 2 above, creating this ACL will set up the TDE (Transparent Data Encryption) for “secscripts” on Machine-B.**
7. # /usr/sbin/ezncrypt-access-control –a “ALLOW @secscripts * /usr/bin/vim.tiny”
   
   
8. On Machine-B - Test
9. # vi ~/code/myscripts/sakila-db/sakila-schema.sql

From here you can just continue to copy files from A to B – or from B to A. All the files are encrypted by AES-256 so they are protected. This method can be used whether servers A and B are in the same cloud or one is in your enterprise and the other is in a cloud, or any number of other possibilities. The files could be backup files or transaction logs for replay or could have any number of uses. They would be protected with AES-256 with no need to alter applications and nor locked in to any particular cloud. This method could help protect files with credit card, personal health information, or code that has user id and passwords - the options are endless.

Again - this was intentionally a very, very simple example. The intent was to demonstrate both how strong security can be simple. With Gazzang’s ezNcrypt Flex Edition, not only can you encrypt your sensitive data at rest, but in certain circumstances, you can continue protecting this same data while in motion. There are many ways the implement remote copying files from one server to another, from one cloud server to another or even across clouds or from your enterprise to and from the cloud, and needless to say there are just as many uses for moving files around securely.

With the Hospitality Financial and Technology Professionals annual conference in Austin, Texas this week, we thought the findings of the Verizon Business 2011 Data Breach Investigations Report were quite timely.

As it turns out, the Hospitality industry has become one of the focal points of hackers. At first glance this might surprise you. Financial Services and Healthcare (Healthcare has 1% of hacks) get all the regulations and are therefore leading the charge of information protection. The stats don’t lie; Hospitality is apparently behind the curve when it comes to information security. Criminals have become wise to this. As penalties for being caught increase, hackers are focusing on places they know have large amounts of valuable information. By stealing only small amounts of data (and thus staying under the radar), they can still end up with extremely valuable information. If you can hack into a hotel system, just think of the information you can obtain. The obvious…credit card information, names, addresses, and email. But you also get dates of the hotel stay. How many people watch their credit card statement while on vacation? From a hacker’s point of view, this is basically gives you the day and time for your shopping spree.

This blog is a call for action. With the HFTP assembled in one place this week, what better time to raise the bar with regard to information security. The PCI Council’s Bob Russo did in his talk at HITEC. It is more than just securing the “most important” stuff; anything a customer entrusts you with is important – even a simple name or email address. With the average cost of a data breach reaching $7.2 million, who can afford not to take all available precautions to protect the data? As a last line of defense the industry should consider encrypting all data, before it is written to the disk, so that even if hackers infiltrate the system any information they steal is worthless. With advances in technology, the age old argument of encryption processes taxing your system too heavily is dead. There is absolutely no reason to not encrypt entire data sets in this day and age of organized hacker groups and multi-million dollar liabilities.

Following up on proposed efforts expressed by the President and newly-appointed Federal CIO, Steven VanRoekel, the Department of Energy is the first government agency to shut down a website in regards to this initiative. There are currently more than 20,000 independent government website, so this is just a first step, but appears to be the right direction. The specific action broke down their energy news service site, Energyempowers.gov, and integrated it into their flagship site – which has also been revamped and moved to the Amazon public cloud. This integration and transition to the cloud is projected to save the department more than $10 million annually.

Though there has been some quiet criticism that site consolidation is not a strong enough effort in these times of austerity, the move has been praised by some, including Sen. Thomas Carper (D-Del.) who had declared the recent actions of the DoE as “an important first step toward making our government more nimble and efficient.” In these initial efforts, the DoE has not just closed down one website, but “it’s also started tallying how much money these efforts will save taxpayers.” The agency has estimated that by moving to the cloud and building new sites as sub-domains as opposed to standalone sites, they look to save $150,000 per year, per site. Even if the government only consolidated half of the current websites, this effort could save taxpayers approximately $1.5 billion annually.

Some detractors have negatively critiqued these estimates and argue the difficulty of tracking the cost of sites. Lisa Welchman, a Web strategy adviser to government agencies and corporations, credits them for actually trying to quantify and erase excess costs, stating "most agencies don't even attempt to do that. And it looks as if they've done a good job of revamping the site, giving it a consolidated look and feel. So, I say, more power to them."

To read more on the DoE and their recent cyber efforts, check out:

http://www.nextgov.com/nextgov/ng_20110815_6690.php?oref=topstory

http://thehill.com/blogs/hillicon-valley/technology/177091-doe-among-the-first-to-cut-website