Pt. 1: PC Containers – What are they good for?

The first in a three part blog series by Moka5 Chief Architect, Ian McWilton

Part one | Part two | Part three

Wouldn’t it be great if you could take your Windows Golden Image – stick it in a digital container and then let all your end-users automatically have it available on their laptops, notebooks, Macs, and PCs – no matter who owns the device and no matter where the device is located? And, wouldn’t be even better if that container was hermetically sealed so that the Windows Workspace never interacted with the host – only accessing memory and processing – thereby keeping it free from malware, intrusions, and data loss? And, wouldn’t it be even better that for the vast majority of end users could simply rejuvenate their containers back to its last known safe-state in the event of some infection or mishap – without having to call IT desktop support? And, what if best of all patches, updates, and revisions could be added to the Windows golden image and automatically propagated out to all your users without you ever having to look at a physical machine?

That reality is here today brought to you by Moka5. We deliver a fully containerized, locally executing Windows workspace that runs locally on PCs and Macs and managed centrally from a single console. We also provide a non-virtualized container that runs on mobile devices providing access to the same critical work files, internal portals/repositories, and applications without the need for VPN access. We believe – and our customers confirm - that Moka5 is simply the best way to manage, secure, and extend Windows workspaces in today’s enterprise, regardless of device types, device ownership, network types, or physical location. In short, Moka5 Enterprise AnyWare simply makes Windows work for today’s enterprise.

MANAGEMENT

Management can mean many different things. We see it as the deployment and updating of the Windows workspace.

As anyone who has ever managed Windows in a large company knows, on its own it is not simple, straightforward, or user friendly. However, using Moka5 as the foundation for managing Windows image creation, distribution, and deployment (for all your current versions of Windows) makes it a much more efficient and simpler proposition.

Here’s a sampling of some of the desktop management challenges Moka5 can solve, detailed further in this post:

• How do I make a single image that I can both anonymize, but make unique for each user?
• How can I setup so that my users can get the container on their machine without having to bring their machines into the office?
• How can I setup so that my users can get the container on their machine without having to have their host machines on the corporate network?
• How do I make sure updates get out to my estate?
• How do I fix it when it goes wrong?

SECURITY

As we’ve proven to many a Fortune 100 company CISO over the years, our security model supports compliance initiatives as well as full-on data security. When used in conjunction with host-based anti-malware and other security measures, containers add an extra level of data security that traditional security tools simply can’t match. Containerized workspaces are hermetically sealed from the host, eliminating such issues as data loss, data theft, malware infections, key-logging, intrusions, as well as so many other issues. Because the Moka5 container is fully encrypted and supports AES235 authentication, your critical data remains locked tight within.

Here’s a sampling of some of the desktop security challenges Moka5 can solve, detailed further in the post:

• Is the workspace protected at the end point?
• Can I continue to control access to the corporate workspace?
• What about other aspects of securing host and guest interaction?
• How do I make sure that the host machine is in a “good enough” security state to run the container and yet not rely on the host to be secure?

INFRASTRUCTURE & ENABLEMENT

Part of the challenge of running Windows in the enterprise is that it is not the most flexible and forgiving infrastructure to manage when dealing with many remote, roving, and intermittently connected clients. Moreover in the case of personally-owned devices, Windows does not provide a reasonable toolset for managing non-Windows clients, separating personal from corporate information on corporate devices, or even simplified system level patching and updating. The standard method for updating PCs is still done manually in many large enterprises – and this doesn’t even begin to deal with Macs and other platforms that may be in use. With new client computing initiatives such as BYOD/PC, remote workforce, contractor employee augmentation, and so many others, forcing Windows to accommodate new deployment models is vastly easier when done in a container. To the workspace itself, it appears to be functioning as a local install and not any kind of exotic configuration.

Here’s a sampling of some of the infrastructure enablement challenges Moka5 can solve, detailed further in this post:

• How do I deploy Windows workspaces out to my real estate across the globe?
• How do I do deployment in remote / poor network areas?
• Not just BYO Mac or windows machines? How do I use container for my corporate estate as well as BYOPC?
• What about beyond Windows hosts? How can customers install one solution across Windows, Mac, and mobile devices?

Because I just can’t contain myself and have written waaaay too much, I’m going to divide the answers up in to three parts. In Part I, below, I go in to more detail on managing Windows workspaces.

Q&A: Managing Windows Workspaces In A Secure Container

Q:: Containerizing my Windows image to enable users to run it on Mac and Windows systems sounds great, but how do I know that the unmanaged host won’t compromise the security of my Windows image within the container?

A:: The Moka5 design principle assumes an unsecured host, which is why the system will prevent the operation of the container on a compromised machine. With the Moka5 container separated from the host by virtualization and protected through encryption, the three types of host vulnerabilities (other than the user, of course) that can compromise data inside a Type 2 hypervisor are keyloggers, screenscrapers, and host memory access. The anti-malware scanners included in M5 Player (AVG for Windows, ClamAV for Macs) are compiled into the container - meaning they won’t interfere with any other AV tools on the host or included in the corporate workspace. These AV scanners check for trojans, viruses, and other malware before decrypting the pc container and allowing the user access to the corporate workspace. If malware is detected, the user is never even presented with the login screen, so there is no opportunity for a keylogger to capture a password. It can also be configured to run periodically throughout the session where it will shutdown the pc container as soon as a host infection is detected. If additional host compliance checks are required – like validating the presence of tools to protect host memory, presence and currency of anti-malware suites including a personal firewall, or compliance with company configuration and patch standards – custom host check scripts can also be invoked prior to access.

Q:: Hang on! If these hosts are un-trusted, how am I going to provision them on my network? I’m not letting an un-trusted, unmanaged host on my network. No sir!

A:: At Moka5 we completely agree. Container based Windows deployment is often used for non-corporate assets. Non- corporate assets are NOT trustable and so should never be allowed on the corporate network – that’s just madness! Sure, you could have a manual check where you inspect the machine and THEN allow it on the corporate network … but who wants to introduce more manual process into an already busy world? Moka5’s infrastructure is designed for the distribution of Workspaces both on and off network. Now – here’s where we start to see how windows containers are different from phone or tablet containers. Windows needs line of sight to Active Directory (AD). When you boot a Moka5 workspace for the first time off network, it is AD joined (see above) but it does not have line of sight to the AD controller. So that means that when I type in my AD username and password … the machine has no idea who I am. It tries to reach out … but as Windows in the container cannot see the AD … it simply tells me to go boil my head! At Moka5, we integrate the use of your VPN vendors PLAP or SBL functionality. This is where your VPN creates a tunnel into the corporate network from within the pc container BEFORE you authenticate to Windows for the first time. Now, when I type in my credentials I can be validated, get my GPO’s, etc. Now I can get provisioned from anywhere in the world with a full domain joined workspace – magic!

Q:: Surely if I have encryption, revoke and kill that’s really all I need. Do I need a bigger policy set?

A:: Moka5 offers over 130 security and management policies ranging from whether or not a user has to accept an update in a specified timeframe to locking the LivePC when the host sleeps/hibernates/suspends for better physical security to preventing the user from copying the entire container and workspace(s) to another device. These have clear security benefits, but management policies such as performance checks, allowing users to temporarily delay background downloads (in case they are on a metered connection), and letting the user control how much memory is allocated to the workspace all enhance user acceptance of a container solution, keeping them from attempting to circumvent the controls you’ve put in place.

Q:: In our current process, IT admins domain-join each machine before shipping it to the user – how can I enable first-time provisioning of the Windows workspace when users are off the corporate network on an un-trusted host?

A:: When you deploy a Moka5 workspace, it is already joined to the domain and has a unique computer name. We do this with a two step process. First is something that we call ‘packaging.’ Before a LivePC is copied up to the Moka5 Enterprise AnyWare infrastructure for distribution (more on that later) we make it anonymous – think of it as a Moka5 specific Sysprep. This means that the instance that gets distributed is in a vanilla state. But that’s not enough – we still need to make it unique to the person that is going to be executing it. We do this using a Moka5 concept called ‘AD packets.’ An AD packet is a small file that contains all the information needed to make the generic image into a domain joined machine (machine name, registry entries around the domain membership, machine GPO’s, machine certificates). These are created by the admin either through a wizard or via an API. They are then packaged and uploaded to the Moka5 infrastructure. When a user downloads a Moka5 VM they also ‘claim’ an AD packet before first launch is allowed. When launch happens, we then combine the generic image with the packet … and the user now has a generic … but domain joined machine.

Q:: How do I manage the Windows workspaces once users have self-provisioned?

A:: Your images are now out and about in the wild. But, now you need to update them. How do you do that? Well, Moka5 pioneered the layering concept. This means an admin runs the installers once on his golden image. We capture the disk level delta (essentially a snapshot) of the changes. We then upload and distribute this through our infrastructure. As you know, normally when you go to a snapshot you would lose any local data or applications. With Moka5 layering, the local changes have been put in a separate ‘layer’ (virtual drive) and we update the base or system layer. When the machine reboots the base/system has jumped forward in time … but we have preserved any end user changes in the user application and user data layers. This means 100% update effectiveness through the use of disk level deltas AND preserving local changes. Moka5 – is there nothing you can’t do?!

Q:: How do I fix it when it goes wrong?

A:: We’ve all done it. I go to a website to download something innocuous and before I know where I am – BOOM – my PC has a virus and is no longer usable. The usual process in this situation is to bring the machine into IT, IT mounts the drive and copies off the data, they then reformat the drive and copy the data back, and the user gets his machine back. This is a lengthy and painful process – often taking weeks! With Moka5 and layering this is not a problem. The user can simply hit the rejuvenate option and the system resets to the last known good image from corporate, but preserves your data. As viruses can exist in data we don’t see ourselves as a replacement for AV, but it sure is nice to have a silver bullet when the time comes!

Part one | Part two | Part three

Comments are closed.