by
Brian Madden
Back at Citrix Synergy 2010 this past May, Citrix announced a client plug-in for encrypted data. (Remember that Citrix's client components are modular, so Citrix and third parties can write plug-in components to extend the capabilities of the client.) The purpose of the encrypted data plug-in is to provide a space to store files or virtual applications locally on a client device that are protected via a centrally-managed encryption scheme.
Yesterday Citrix announced that the encrypted data plug-in will be branded as "XenVault" and available in late September.
What I really like about the encrypted data plug-in that was previewed is that (1) it can encrypt just certain areas the Citrix client has access to—regardless of whether the device is corporate controlled or a user's personal laptop, and (2) admins deploying software and managing data can set policies based on this encryption. (e.g. maybe a user could only stream a corporate app to run locally on their client if the Citrix client software can verify that it's encrypted.)
I would imagine in the future this will be tied into Intel vPro-based clients with TxT to absolutely verify the device and the encryption. (And again, I assume that would be policy-based, so you could maybe configure all client-side components to be encrypted, but maybe some sensitive apps would only be available on the client if the client device also had vPro with TxT.)
Those of you who saw my opening keynote at BriForum 2010 remember that I told a story about my first days at TechTarget. When I learned that the only corporate-supported file sharing option for Gabe and me was a network share (which required client-scanning VPN access and Internet connectivity to use), I quickly said "Screw that!" and setup a DropBox account. Now Gabe and I use DropBox for everything. The problem is that DropBox just puts regular files on each of our laptops, so if we lose a laptop then someone could mount the drive in another system and have full 100% access to everything we share.
We address this by using disk encryption, but the only reason Gabe and I encrypt anything is because we're smart enough to know the risks and to know how to configure the encryption. But what about normal users in some other company who want to use their non-corporate-controlled (BYOPC or whatever) laptops? Will they have the wherewithal to take the initiative to encrypt their own laptops? Of course not!
This is where Citrix XenVault comes in. Citrix's Joe Nord wrote a great technical blog post explaining the under-the-hood workings of XenVault, while their desktop CTO Harry Labana wrote a bit more about what this means for stodgy IT departments.
More on XenVault (from the press release):
- Protects and Isolates User Data – The new XenVault technology automatically and transparently saves any user data created by corporate apps into an encrypted folder, ensuring that it is protected at all times from unauthorized users.
- Ideal for Contractors and BYOC – Because XenVault supports both virtual and physical desktops, it is an ideal solution for contractors and employee-owned laptops where users don’t want IT installing software on their personal laptops. When a contract is over, an employee terminates, or the laptop is lost or stolen, corporate data remains secure, and can even be wiped remotely.
- Supports XenApp and App-V – XenVault automatically encrypts data created by any corporate app that is delivered by Citrix XenApp™ (or the XenApp feature of XenDesktop) or Microsoft App-V.
To me this seems pretty huge and a key component of a complete application delivery solution.
XenVault will be a released a free plug-in for the Citrix receiver, available as part of Feature Pack 2 for XenDesktop 4 which is expected to ship in late September. It will be available for all editions of XenDesktop. It will also work with XenApp, although I don't know whether there will be a new Feature Pack for that as well or whether it will just be a free update. Citrix plans to demo XenVault at VMworld next week.
(Note: You must be logged in to post a comment.)
If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.