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:
ubuntu@ip-10-202-47-92:~$ sudo service mongodb stop mongodb stop/waiting
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
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
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
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
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 firstname.lastname@example.org.
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 email@example.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:
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.18261x1077 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
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.
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
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.
Note: All the files within the tar are AES-256 encrypted.
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: