Yesterday Bromium released vSentry 1.1, adding support for Windows Server while also claiming to now support Windows XP, 32-bit Windows 7, and VDI desktops. In truth, the only new feature added is support for Windows Server 2008 R2, which ultimately means that you can now publish vSentry-secured applications to users running any OS. To that end, Bromium could just as easily say they support Android, iOS, Linux, Windows CE, and Wyse Blazer. I'm mentioning this at the top of the article not to take anything away from what is really awesome technology, but because I feel like we need to level set exactly what's going on. Now let's break it down...
I'm a fan of vSentry's approach to security, but I wish it could work on all desktops in all situations, not just Windows 7 x64 physical desktops in an organization that has an Office KMS server (that's a long story, but according to Bromium it's required to comply with MS licensing). That said, this is advanced technology that requires advanced hardware and a surplus of memory to function well, so it's understandable that there are limitations. The licensing complications are, sadly, more or less expected at this point. (I'm looking at you again, Microsoft)
Because of those limitations, a lot of systems are left off the compatibility list. VDI virtual machines, for example, can't take advantage of vSentry because it's not possible to virtualize the VT extensions that vSentry leverages to create its micro-VMs. For the same reason (lack of VT), older physical desktops are also left in the dark. It also means that 32-bit machines aren't included because of the limited amount of memory. *(While it is possible to pass VT through to VMs, vSentry requires ownership of VT, which can only be held by one entity. In a virtualized environment, that's the hypervisor. Thanks David Stafford and Icelus for pointing it out/clearing it up!)
Windows Server 2008 support, and RDS support specifically, can help deal with those challenges. On one hand, just being able to use vSentry on a datacenter hosted desktop is a leap forwards. There are far more RDS desktop and application users in the world than there are VDI users, and this technology now gives IT the ability to secure browsers (IE for now, more in the future) accessed via RDS. In the RDS world, where one bad user can screw over hundreds of other users and a downed server can throw off the balance in a farm, that's a big deal.
As I mentioned before, vSentry on an RDS server is how Bromium can tout the ability to secure Windows XP, 32-bit Windows 7, and VDI. Rather than running IE locally on those desktops, you can now "secure" them by accessing IE running in an RDS session that is also running vSentry. Make no mistake, though, this release of vSentry does not add native support for microkernel virtualization to those OSes. It just means that users can now connect to vSentry-secured browsers on terminal servers. Obviously, I’d prefer a native solution, but this can be useful.
There's one thing, though, that's causing me to think twice about this. The lack of VT virtualization means that to run vSentry on a server, that server must be a physical server with direct access to the VT extensions, despite the fact that the vast majority of terminal servers in the world today are virtualized. That means that in order to get vSentry-secured browsing on incompatible machines, you'll need to stand up a farm of physical terminal servers. Odds are that's a change in philosophy for you, and there is a cost associated with that. (But hey, you found a way to use all that rack space you freed up when your virtualized!)
So, does this change the value vSentry if I have to add physical servers to support incompatible machines? The answer, I think, comes down to how much you value security. In other words, you have to be willing to put up with a solution that’s limited to specific, physical hardware in order to get the level of security that vSentry offers. The underlying technology remains unchanged, and its capabilities remain impressive, but at the end of the day we're still talking about securing physical devices as opposed to virtual ones. I'm not certain that there's an easy solution to expand the technology beyond that. If there were, Bromium would have gone that route as opposed to this one.
(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.